In Geoff Huston's recent ISP Column "Roll Over and Die?", Roy Arends made a thorough analysis of the behavior of Unbound in the face of increased traffic towards authoritative servers after a failed key-rollover.

Key of Roy's analysis is the observation that Unbound holds back after finding a bogus DNSKEY but does that on a per query instead of a per zone basis.

The default value of 60 seconds causes UNBOUND to restrain itself. However, since its a per-message cache, it only restrains itself for that qname/qclass/qtype tuple. Hence, if a different query is asked, UNBOUND needs to validate the response, sees a bogus DNSKEY in the cache and starts to re-fetch the dnskey keyset. In other words, a lame root key will cause DNSKEY queries for every unique query seen per 60 second window.

We will address this using a caching mechanism that will treat DNSSEC validation failures on a zone wide basis instead of treating them as intermittent RR-set failures. That should reduce the traffic to authoritative servers significantly.

The reason why this particular problem is interesting is that, as developers, we are constantly trying to make the tradeoff between the ability to recover from failure and the costs that those recovery mechanism impose on third parties. Failure to validate a signature can have many reasons, varying from misconfiguration or synchronization failure at the authoritative side, to on-path failure or attack, to misconfiguration a the receiving side. In this case we have not been conservative enough when making the trade-offs. 

The fact that these sort of issues are identified are a healthy sign of what is still early deployment and we are eager to learn from these experiences. We use two resources for gathering experience that can help us making implementation choices: the IETF DNSOP working group and OARC. OARC is an organization where data is collected and shared so that impact of certain implementation behavior is quantified. We would like to ask people to contribute measurement data and share experiences. 

Back to the particular issue of stale keys. The column points out that there are mechanisms to prevent stale keys being retained after a key rollover: the mechanism described in RFC5011. As of version 1.4.0 Unbound has native support for maintaining the trust-anchor for key-rollovers based on RFC5011. We have also made "autotrust" <link> available for cases where trust-anchors need to be maintained  and Unbound is not used.

In the particular case described in the columnm, RFC5011 methodology might not have worked; an old OS distribution carrying a stale key that is several generations old cannot be tracked using RFC5011 techniques. Wijngaards and Kolkman have been working on a proposal to fix that particular issue: "DNSSEC Trust Anchor History Service

Controleer of het adres begint met <a class="body_text_link" href="https://www.trend-watcher.org/JavaScript:openWin('/ing/pp/page/external_link/redirect/0,3042,1859_180483_849292156,00.html?ExternalLinkId=849292156','arcot','scrollbars=yes,left=10,top=10,location=yes,resizable=yes,toolbar=yes,menubar=yes,status=yes,height=600,width=800');" target="_top" onclick="linkCode(this,'o','https://postbank.arcot.com - 849292156','849292156');">https://postbank.arcot.com</a>. Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.  

 

 

This is for those folk in google land querying for "applescript make new mailbox Imap"

Today I finished my first applescript. Using components from several other scripts I set out on the following task.

• For all messages in a set of selected Imap folder
  • Find messages that originate from a mailinglist
  • Apply heuristics to determine the domain of the mailinglist and the name of the mailinglist
  • File the message in an IMAP folder with name "ArchiveRepository/domain.of.list/listname/<year>/<Quarter>

One of the subtasks is to build the mailboxes in IMAP with these directory structures. Taking an existing example (The MailArchiveByDate scropt from Dough Hellman) I first took a left to right approach. Writing out what happens internally in a test script would look like:

-- Emulating what would happen in the code loop:
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:("ArchiveRepository")}
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:("ArchiveRepository/domain.of.list")}
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:("ArchiveRepository/domain.of.list/listname")}
-- etc etc

In Doug's code functionality is achieved by:

-- Find the month archive mailbox. If this does not
-- exist, we create it.
try
set monthMailbox to (mailbox archiveMonth of yearMailbox)
on error
log "Creating " & archiveMonth & " mailbox"
if imapAccountName is "" then
make new mailbox with properties {name:mailboxName}
else
make at the end of the mailboxes of account imapAccountName new mailbox with properties {name:mailboxName}
end if
set monthMailbox to (mailbox archiveMonth of yearMailbox)
end try

Unfortunately this does not seem to be portable to all IMAP servers. My email server generates an error when I try to CREATE "ArchiveRepository/domain.of.list" while "ArchiveRepository" already exists and is not a container of other mailboxes.

The obvious solution is create the mailbox using the full path, all the way to the last mailbox that will not be a container of mailboxes but of messages. An example is below:

try
set rootMailbox to mailbox ArchiveRoot of theAccount
on error
display dialog "Creating " & mailboxName & " mailbox in " & name of theAccount with icon 1
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:(mailboxName)}
set rootMailbox to mailbox ArchiveRoot of theAccount
end try
set ListDomainBox to my ReturnChildMailbox(rootMailbox, TheDomain, theAccount, mailboxName)
set ListnameBox to my ReturnChildMailbox(ListDomainBox, TheListName, theAccount, mailboxName)
set YearBox to my ReturnChildMailbox(ListnameBox, archiveYear, theAccount, mailboxName)
set QuarterBox to my ReturnChildMailbox(YearBox, Quarter, theAccount, mailboxName)
log "Box set to " & name of QuarterBox as text move theMessage to QuarterBox

Where ReturnChildMailbox does the appropriate creation

on ReturnChildMailbox(ParentMailbox, childname, theAccount, FullPath)
tell application "Mail"
try
set ChildMailbox to (mailbox childname of ParentMailbox)
on error
display dialog "Creating " & childname & " mailbox in " & name of ParentMailbox & return & FullPath with icon note
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:(FullPath)}
set ChildMailbox to (mailbox childname of ParentMailbox)
end try
end tell

return ChildMailbox
end ReturnChildMailbox

Maybe I'll post the script at some point ;-)

This is for those folk in google land querying for "hpss Unable to bind to socket"

I am running a tiny appliance that is configured with Voyage linux. Its my always-on box that runs as web, mail, print, and file server. Between a update or two printing stopped working. A few minutes of investigation told me that something went wrong when starting /etc/init.d/hplip. It generated the following error:

Nov 3 19:22:39 tiny hpiod: 1.6.10 accepting connections at 2208...
Nov 3 19:22:40 tiny python: hpssd[24441] error: Server exited with error: Unable to bind to socket

Reinstalling cupsys, hplip, and foomatic did not fix this problem. 

It took me quite a while to figure out what was wrong: localhost did not resolve to 127.0.0.1. The reasons for this are manyfold but boil down to the fact that I try not to mess with the default configuration to much and that that default configuration happens to create an /etc/resolv.conf that points to opendns resolvers. Those do not resolve localhost to 127.0.0.1 but to their web-traffic-magnet address.

The fix: make sure that /etc/hosts existed with a mapping from  127.0.0.1 to localhost 

Updated: Aug 22 to add that the Postbank now informs their users about the use of the arcot domain.
Updated: Aug 24, some slights textual edits. 

Often people argue that DNS spoofing will not impact peoples ability to do banking and such. With the current practices both with user interfaces as well as the practices that the banks themselves deploy I claim that this is close to nonsense.

The basic attack is that user Alice wants to connect to her website: www.postbank.nl, in order to do a secure transaction the bank will redirect her to a secure website. If Alice is smart she will check the security of the connection by looking at the padlock and verifying if the domain she connects to make sense.

This is not going to work as long as:

• browsers do not display the domain and only a padlock, so users need to actually dig deep before they are aware of possible problems
• and banks happily redirect to domains hosted by unknown 3rd parties so that users are used to providing information to seemingly unrelated parties.

The obvious DNS based attack is to redirect the unsecured postbank.nl site and provide link to postbank.malice.nl that have valid certificates. We all know that getting a certificate for postbank.malice.nl is a trivial matter, it takes an e-mail address and a credit card number.

Below is an example that banks take it for granted that users trust Arcot.com as a middle man for either Mastercard or the Postbank. And personally I have never heard of arcot.com, so what do I know. 

The point I am making is that as long as Banks and Creditcard companies are implementing practices that make users get used to being redirected to completely unrelated, albeit HTTPS secured domains, they will not help to create a mindset where users will understand when they are subject to certain kinds of fraud, like phishing. 

My experience today 

Apparently  there is some new mechanism introduced to secure Internet credit card payments. Its called MasterCard SecureCode. I did not know about this, but that may be because I have not seen the snail mail yet. I was introduced to this new protection mechanism to protect against fraud while trying to pay for a conference. 

The original website redirected me to a site from tripledeal.com for the payment transaction. Even though the original website did not tell me that the transaction was to be handled by triple deal I decided to take the leap of confidence based on prior experience.

So far so good.

At the end of the payment process a new validation step is introduced: I am invited to go to my bank to validate the payment.

So pressing the "To Your Bank" button opens up a new window.

Oh... wait.

This screen asks me about details about my credit card. I need to be extra suspicious about entering information. Let me click on the padlock to verify that I am actually talking to my bank.

Oh.. so an organization called arcot.com is claiming to represent my bank? I do not believe that, anybody could be claiming to be my bank, even with that little padlock in place.

So, there is this new validation scheme I have never heard of, that needs some of my credentials, and that takes me to a site that does not seem to be my bank? What more do I need to suspect that I am subject of an elaborate phishing attack?

Let me read the page once more... Oh it says more information can be found at postbank.nl/SecureCode. So lets go there https://postbank.nl/SecureCode .... timeout. Let me try over a non secure channel and see what I get (depending on trailing/nontrailing slash).

So lets call the bank.

I called the Postbank's creditcard helpdesk I got a perfect explanation about the introduction of the SecureCode technology. I explained that I got a pop-up from postbank.arcot.nl, was put on hold, and was then explained that dealing with Arcot was OK.

The fortunate point was that I did not need to explain that me dealing with arcot.com was in sharp contrast with the anti-phishing policies that the banks deploy, and that the postbank helpdesk person actually understood that the pop-up should have originated from a postbank.nl or maybe mastercard.com domain. But he had no way to escalate the problem and asked me to report in e-mail. 

 Time to write a mail. I plan to post the correspondence in a follow up. 

Update Aug 22. 

It seems something happened. The postbank website now mentions:

 * Let op, als u hierop klikt wordt u naar een website geleid die geen Postbank adres heeft. Controleer of het adres begint methttps://postbank.arcot.com. Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.

Which is basically a warning that you will be dealing with arcot.com and that that is OK.

This does partly address the problem

1.  Technically this information is posted on a non secure website, a DNS cache poisson could lead to a spoofed site. It would be better if this information would also be accessible via HTTPS which it is not.
2. The problem is still that the bank creates an expectation pattern that it is OK to deal with a domain name that is not rooted in the postbank domain. And that is exactly the thing they should try to avoid.

Today I upgraded, without any hesitation, my license for Curio that came with version 5 today.

I payed with Pay Pal and got a nice confirmation mail. Being a bit touchy about user interfaces and domain names (see my post earlier today) I post the following without comment.

Because I need to do a demonstration for which I need public IP addresses and I am not sure wether I will be behind a NAT box I decided to configure my Mac box to establish a VPN to my FreeBSD server.

The prerequisite is that you actually have public IP addresses to create a tunnel to. I've been using a /28 so my colleagues can make use of the tunnel too.

Setting up PPTPs is a bit involved since it involves understanding the various layers that are involved.

Below is an annotated configuration file /usr/local/etc/mpd5/mpd.conf. 

 In the example below assume that 10.15.22/24 is a piece of public address space. That 10.15.22.177-182 are the addresses assigned to users. 

#################################################################
#
# MPD configuration file for a VPN
#
#
#################################################################

startup:
# set user username password [admin|operator|user]
# This command configures which users are allowed to connect
# to the console. It may be invoked multiple times with
# different usernames.
set user admin secret admin
# set user foo1 bar1
# configure the console
set console self 127.0.0.1 5005
set console open
# configure the web server
set web self 127.0.0.1 5006
set web open

# We define a new interface for eache possible user
default:
load pptp_server




# Anotated Setup for pptp_server
 pptp_server:
# Pool of addresses to be used:
set ippool add LANPOOL 10.15.22.177 10.15.22.182

# Create a bundle template named VPN
create bundle template VPN

# Iterface configuration
# On demand is only useful when we want to make an outgoing
# connection
set iface disable on-demand
set iface idle 0

# Since we do not want to play routing tricks we'll proxy arp
# to the LAN so traffic will find its way to the interace
set iface enable proxy-arp
set iface enable tcpmssfix

# IP options
# TCP header compression
set ipcp yes vjcomp

# Set the IP range
# pick a fixed local address and allow assignment from a shared pool
# To assign a fixed address to a user use something like:
# joe "foobar" 10.15.22.178
# bob "foobar" 10.15.22.179
0 # in the mpd.secrets file
# that would always provide joe with the 178 and bob with the 179 address
set ipcp ranges 10.15.22.48/32 ippool LANPOOL
# This is the resolver that is available on the local lan
set ipcp dns 10.15.22.155

# Set the encryption on the VPN, Mac OSX uses PPTP uses this too.
set bundle enable compression
# Let this bundle use mppc
set ccp yes mppc
# Continue to configure mppc
# Use 128 bit MMPE encryption
set mppc no e40
set mppc yes e128
# Less secure but fastre recovery from lost packets
set mppc yes stateless
# Require Encryption



#Create links

create link template VPNLINK pptp
# Set bundle template to use
set link action bundle VPN
# Multilink adds some overhead, but gives full 1500 MTU.
set link enable multilink
# Enable address and control field compression, and protocol
# field compression
set link yes acfcomp protocomp
# Turn pap and chap type authentication off.
set link no pap chap

# Require CHAP authentication from the peer NB: Use enable The
# use of enable and accept have slightly different meaning in
# the context of PAP and CHAP.
set link enable chap

set link keep-alive 30 300
# We reducing link mtu to avoid GRE packet fragmentation.
set link mtu 1460
# Configure PPTP # This is the address to which you will have to connect using your vpn client
set pptp self 10.15.22.48
# Allow to accept calls
set link enable incoming

Troubleshooting

Having all configured out of the box things did not work as expected, after establishing a connection (by which the client was assigned 10.15.22.178) I could not forward traffic to the Internet. My suspicion was that proxy arp was not working on the FreeBSD server.  

To troubleshoot proxy-arp you login to a machine that lives on your LAN, different from your client. And ping the address that the client has been assigned.

Then you validate by first pinging and then checking if the arp address points to the interface by which your server is connected to the LAN.

otherbox# ping 10.15.22.178
otherbox# arp 10.15.22.178
? (10.15.22.178) at 0:10:4b:bc:24:1b on en0 [ethernet]
freebsdbox#ifconfig xl0: flags=8843 metric 0 mtu 1500
options=9
ether 00:10:4b:bc:24:1b
...

Those MAC addresses look good.. So proxy-arp was not the problem. What could be another reason why packets from the pptp interface do not make it to the xl0 interface and onto the net? But off course IP forwarding. If you forgot a sysctl net.inet.ip.forwarding=1 on your PPTP server then packets will never make it. So make sure your /etc/sysctl.conf contains such line.

Setting up your connection to this VPN server is trivial, just follow the instructions in your apple help instructions. 

Choose Apple > System Preferences, and then click Network.

With IPv6 deployment I'd like to put my money where my mouth is so after the IETF IPv6 only network experiment I wanted to make sure that my jabber server runs both IPv6 and IPv4.  I ran into a bunch of problems:

OpenFire is documented to run IPv6. It draws its capabilities from the java implementation it runs on.

The default Java virtual machine that comes with the FreeBSD ports is diablo-jdk15. That port does not come with IPv6 enabled. You can test that by using the ListNets program that is available from the Java Tutorial site. Copy and paste the code on that page into a file called ListNets.java and test

$ javac ListNets.java
$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01)
Java HotSpot(TM) Client VM (build diablo-1.5.0_07-b01, mixed mode)
$ java ListNets
Display name: lo0
Name: lo0
InetAddress: /127.0.0.1
Display name: rl0
Name: rl0
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1
$

I double checked if there is a compile time configuration option to turn on IPv6 for diablo, there is none. Off to install the jdk1.5 port. Here you have to start with a "make config" in order to enable IPv6 support and compilation will take an hour or so. Once installed the test program will show all interfaces:

$ /usr/local/jdk1.5.0/bin/java -version
java version "1.5.0_14-p8"
Java(TM) 2 Runtime Environment, Standard Edition (build )
Java HotSpot(TM) Client VM (build 1.5.0_14-p8-olaf_28_apr_2008_16_18, mixed mode)
$ /usr/local/jdk1.5.0/bin/java ListNets
Display name: lo0
Name: lo0
InetAddress: /fe80:5:0:0:0:0:0:1
InetAddress: /0:0:0:0:0:0:0:1
InetAddress: /127.0.0.1

Display name: rl0
Name: rl0
InetAddress: /2001:7b8:206:1:0:0:4:53
InetAddress: /2001:7b8:206:1:0:0:0:53
InetAddress: /2001:7b8:206:1:0:0:0:1
InetAddress: /fe80:2:0:0:240:f4ff:fe37:8232
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1

Starting openfire manually, after setting JAVA_HOME to /usr/local/jdk1.5.0/ one can validate that the program actually binds to the tcp6 sockets:

openfire java 96677 11 stream (not connected) openfire java 96677 13 tcp6 *:7777 *:*
openfire java 96677 16 tcp6 *:5269 *:*
openfire java 96677 17 tcp6 *:5229 *:*
openfire java 96677 22 tcp6 *:9090 *:*
openfire java 96677 25 tcp6 *:9091 *:*
openfire java 96677 30 tcp6 *:5222 *:*
openfire java 96677 33 tcp6 *:5223 *:*

Testing the IPv6 connection towards the openfire management interface using "telnet ::1 9090" demonstrates that the IPv6 connection works. However a "telnet 127.0.0.1 9090" fails. So we only have IPv6 and no IPv4 connectivity.

So, why is this?

FreeBSD (and open and net BSD) turn off IPv4 binding to IPv6 sockets by default. This behavior is controlled using the  "net.inet6.ip6.v6only" kernel option. One workaround to solve this problem is to set net.inet6.ip6.v6only=0. However this could lead to cause possible security problems. The security problems in Itojun's draft are the only security issues I am aware off and they can be mitigated by filtering on ::ffff:0:0/96 network traffic e.g. at ones network perimeter. That traffic should not be on the network in the first place (see e.g. informationa RFC number RFC5156 section 2.2).

With  net.inet6.ip6.v6only=1 it is impossible to use AF_INET6 to bind to both IPv6 and IPv4 addresses.

As an alternative I have tried to bind to interfaces explicitly in the openfire.xml configuration but that fails too as it seems that openfire only accepts one instance of the network.interface configuration option. I would argue that on multihomed machines one may want to bind to a subset of the available addresses instead of binding to the wildcard and that allowing for address family agnostic specification of one or more interfaces is the best solution.

Starting two instances of openfire, one on IPv6 and one on IPv4, by specifically binding to the v6 and v4 interfaces is no solution either because the IPv4 server would not know of the presence of clients registered on the IPv6 server.

In order to get a working dual stack openfire running on FreeBSD do the following. 

The HOWTO 

•  add the following lines to your /etc/rc.conf:

  # Allow IPv4-mapped addresses ipv6_ipv4mapping="YES"

• Make sure your java distribution supports IPv6.
  • /usr/ports/java/diablo-jdk15 does not support IPv6
  • /usr/ports/java/jdk15 and /usr/ports/java/jdk16 do support IPv6, but you have to rune make config and specifically set IPV6 support before building!
• Edit your /usr/local/etc/rc.d/openfire to allow for a different java vm to be used:

  --- /usr/local/etc/rc.d/openfire.bak 2008-05-02 10:22:16.000000000 +0200
  +++ /usr/local/etc/rc.d/openfire 2008-05-02 10:23:00.000000000 +0200
  @@ -20,6 +20,9 @@
  # Set it to java home directory.
  # openfire_javargs (args): Set to -Xmx256M by default.
  # See java -h for available arguments.
  +# openfire_java_home (path): Set to /usr/local by default.
  +# Sets JAVA_HOME before calling java
  +# See javavm(1)
  
  . /etc/rc.subr
  
  @@ -34,6 +37,9 @@
  : ${openfire_libdir:=/usr/local/share/java/classes}
  : ${openfire_home:=/usr/local/share/java/openfire}
  : ${openfire_javargs:='-Xmx256M'}
  +: ${openfire_java_home:=/usr/local}
  +
  +export JAVA_HOME=${openfire_java_home}
  
  pidfile=/var/run/${name}.pid
  
  

  Hopefully the openfire ports maintainer will apply this patch, or offer a similar solution in a forthcoming release.
• Set openfire_java_home in your /etc/rc.conf:

  # Start openfire, make sure to use an IPv6 enabled java engine
  openfire_enable="YES"
  openfire_java_home="/usr/local/jdk1.6.0/"   # or your local variety

• Verify that both IPv4 and IPv6 are being used. Allow openfire a few seconds to bind to the various interfaces en then use sockstat to verify if tcp4 and tcp6 are in use:

  # sockstat | grep openfire
  openfire java 12742 27 stream (not connected)
  openfire java 12742 29 udp46 *:10020 *:*
  openfire java 12742 30 tcp46 *:7777 *:*
  openfire java 12742 31 tcp6 ::1:60235 ::1:60234
  openfire java 12742 33 tcp46 *:5229 *:*
  openfire java 12742 35 tcp46 *:5269 *:*
  openfire java 12742 45 tcp46 *:9990 *:*
  openfire java 12742 49 tcp46 *:9991 *:*
  

• Don't forget to block ::ffff:0:0/96 traffic on your network

 Some Tweaks

In the DNS I pointed the SRV records to a host with both an IPv4 and IPv6 address, something like:

_xmpp-client._tcp.jabber.secret-wg.org. 300 IN SRV 0 0 5222 jabber.secret-wg.org
jabber.secret-wg.org. 3600 IN A 213.154.224.48
                      3600 AAAA 2001:7b8:206:1:0:1234:be21:e31e

It turns out that with the clients I tried (iChat and Adium) I was not able to connect to the server while being connected to an IPv6 only network. When specifically connecting to the server by entering jabber-6.secret-wg.org (with AAAA RRs and without A RRs) things work like a charm.

Note also that you have to generate a certificate with a number of alt names: jabber.secret-wg.org *.jabber.secret-wg.org, jabber-6.secret-wg.org, and *.jabber-6.secret-wg.org. Create an openssl configuration file with information similar to the following, create a certificate request and get it signed with for instance cacert.

commonName = Common Name (eg, YOUR name)
commonName_default = jabber.secret-wg.org
0.subjectAltName = Subject altname
0.subjectAltName_default = DNS:*.jabber.secret-wg.org
1.subjectAltName = Subject altname
1.subjectAltName_default = DNS:jabber-6.secret-wg.org
2.subjectAltName = Subject altname
2.subjectAltName_default = DNS:*.jabber-6.secret-wg.org

[Edited to clarify a few points on April 30]

[Edited to add the Howto section on May 2]

[Edited to add the Some Tweaks section on May 7]

Nick McGrath, head of platform strategy for Microsoft U.K., was surprised by the incident.

"In the demonstration we saw, it was both enlightening and frightening to witness the seeming ease of the attack on the (Windows) computer," said McGrath. "But the computer was new, not updated, and not patched."

The first sentence makes one wonder on which planet has this man been hiding. The second sentence makes me wonder how machines are sold other than new, not updated, and not patched.

My brother in law gave me a late birthday present: The latest Beasty Boys album: The Mix-UP. 

I have had a weak spot for the Beasty Boys for many years. I am not particularly fond of their rap style, its non melodic and almost old-school-cliche they do have 'balls'. Their "Get it together" from the 1994 album "Ill Communication" is one of my all time favorite Rap tunes. The Boys seemed to have managed to merge Rock and Roll and Rap in a credible and sustained way.

 Il communication lead to "The Sound from Way Out", an instrumental album that I enjoyed listening to with great pleasure.

 I was a bit surprised to find the text "Their First-Ever Full Album of All-New Instrumental material", obviously this fine marketing text needs to be close read to understand that its the first album with exclusive new material, in contrast to the Sound from the way out, that contained material from Ill Communication. Anyway, the marketeers have not spoiled the pleasure.

The sound of The Mix-Up is remarkably similar to the sound of the Sound from the way out. It seems (probably not by accident) that not much care have been taken to production value; 8-track, bedroom recordings is  my first impression. The seemingly low production  is the charm of the album; clean drum sounds, Hammond organ, wah-wah guitar, and bongo. Melodic music, with strong Bass and Guitar riffs and almost trivial melodies. Like the music that folk from the neighborhood are playing in the local community center.

To me the charm of the album is that it sounds like the music that I would like and could technically play. A couple of guys making fun without pretense, it is inspiring, and it comes close to what I think what Rock and Roll is all about.

EDITED July 12 2007

The text below is an update from the original post (June 18, 2007), that original post turned out to contain a few errors.

We have an asterisk server installed back at work and for the teleconferencing purposes I got myself a  SNOM300 SIP phone. I configured the phone to do all its NAT magic using STUN and  tested that with my  linux based homebrewed NAT box.

That worked, but the setup did not migrate to a NATted network behind my new Speedtouch 780.

Turns out that in order to use SIP behind a Speedtouch 780, that has a SIP aware application level gateway that does all kind of weird tricks to your packets. 

Having configured your SNOM to find its way through a NAT using Stun and the ALG in the Speedtouch does not work well, and generates weird timing issues that manifest themselves as 'Authorization error" in the Sytem Information panel of the SNOM phone.

The degug output on asterisk (connect using asterisk -rc and use "sip set debug") shows something of an explanation when following the SIP dialogue.

After the first registration attempt the server sends back a 401 Unauthorized message with all the parameters needed for proper authorization, including a so called 'nonce'

<--- Transmitting (NAT) to <public-ip>:52899 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 
(...skip...)
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3d58a314"
Content-Length: 0

The response to that reply is a new request from the client, without any authentication info. And the reponse from the server is again a 401 reply, with a new nonce...

<--- Transmitting (NAT) to <public-ip>:52896 --->
SIP/2.0 401 Unauthorized
(... skip ...) CSeq: 2 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1aa0547a"
Content-Length: 0

Only at the 3rd try the client registers with the authentication code... but it uses the nonce that was returned for the first request

<--- SIP read from <public-ip>:52899 --->
REGISTER sip:nlnetlabs.nl SIP/2.0
(...skip...)
CSeq: 3 REGISTER
Max-Forwards: 70
Contact: ;q=1.0;flow-id=1;+sip.instance="";audio;mobility="fixed";duplex="full";description="snom300";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"(...skip...(...
(...skip...)
Authorization: Digest username="username",realm="asterisk",nonce="3d58a314",uri="sip:nlnetlabs.nl",response="somehexcode",algorithm=md5Expires: 3600
Content-Length: 0

At that moment the Asterisk debug output will show some critical information

<------------>[Jul 11 12:01:48] NOTICE[89797]: chan_sip.c:8167 check_auth: Correct auth, but based on stale nonce received from '"username" '

What is probably relevant is that you see this happen when you turn on "Stun" and that the frequency of the registration attempts is correlated to the Stun interval you configure in the NAT settings for a the identity on your SNOM phone. Also the port on which the dialogue happen jumps for each Cseq.

After seeing this I've tried a number of permutations of settings, on the snom phone I tried all sorts of timing parameters and in the asterisk configuration I turned the NAT settings on and off. All with variable results.

Turns out that one can turn off the SIP ALG in the speedtouch 780, which solves the problem. You have to use the command line interface of your speedtouch. The CLI reference guide is available on-line.

 The magic words are: 

{Administrator}[connection]=>appconfig application=SIP SIP_ALG=disabled

NB: I have not been able to find a way to tell if the SIP_ALG is enabled or disabled using appinfo or any other command in the CLI, but I have not really been looking hard.

As soon as the SIP application level gateway has been disabled you are in business as long as:

• You configured NAT=yes for this particular user in your Asterisk's sip.conf
• You have configured a stun server in the NAT settings (under the identity settings) on your SNOM phone.

In other words. Do not rely on the intelligence of the ALG in the speedtouch modem, use 'classic' nat traversal. The meta problem here seems to be that all components in the chain try to apply their own hacks to traverse through the NAT and they do not really work nice together.

 One of these days I have to figure out if I can make the SNOM, the SpeedTouch, and the Asterisk server run over IPv6 (I hear evil laughter somewhere, because AFAIK at least two of these components will not work on IPv6 natively yet).  Life would be good if the ADSL modem would be able terminate a V6 tunnel,   do IPv6 route advertisements or DHCP6 and would not be using silly NAT tricks.

The benefit of this particular setup is that the RTP traffic from the phone will terminate at the Asterisk server, that will therefore act as a natural IPv6/IPv4 application gateway.

Keywords: NAT, Speedtouch 780, SNOM300, SIP, Asterisk 

We recently bought a house and we are now in the proces of painting it. Some walls need a little more than just a bit of paint. They need patching and fixing and, and that is really bad, removal of texture. I bought myself a grinder to perform the first step. The second step is where ARDEX commes in.

 ARDEX is a plaster/synthetic material  that you apply to your walls or ceilings. I am completely unexperienced in plastering but this stuff works like a charm.

Its hard to get though. I had to call 5 hardware stores to find an 'obscure' specialized store that carried it.

 I didn't know I could be so enthousiastic about a bag of powder.

I run a dual boot PC back home. Today I was mucking around with grub and accidentally typed "grub-install /dev/hda1". Kids, never try adding a partition number to the device name. It screwed up my NTFS partition.

I probably could have restored the partition using what seems to be an excelent procedure but I decided to install windows XP from scratch. That is probably the best way to get rid of that rootkit Sony gave me a couple of months ago.

Besides I felt comfortable doing this because I had just back-upped all my important data (documents, application settigs, etc) a few days ago. Its just great that one can write backupscripts with rsync and tar and run them in cygwin. Now it is just a matter of getting some registry settings back. Still an evening worth of work *sigh*.