Tuesday, February 26, 2013

Self-scan your IPv6 ports

This is nice site to scan well known ports on your IPv6 system:


Direct link for well known ports:


Direct link for well known ports, plus custom port 12345:


As far as I know, default behaviour of IPv6 enabled modems and Windows is to drop unknown incoming IPv6 sessions (and thus the above port scan); Windows thus mimics NAT behaviour

You can also use lynx to see OPEN ports:

sander@toverdoos:~$ lynx --dump 'http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi?includeexisting=1&customport0=12345&customport1=&customport2=&customport3=' | grep OPEN

   Port 53 = OPEN   Port 79 = RFSD    Port 80 = OPEN
   OPEN An IPv6 TCP connection was successfully established to this port.

So port 53 and 80 are open on this system.

"IPv6 duplicate address" in Linux

My Linux system (Ubuntu 12.10) was suddenly having problems with IPv6, and dmesg said:

IPv6: wlan0: IPv6 duplicate address 2a00:cd8:blabla:1af4:6aff:fe9c:ced4 detected!
IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support

The workaround was to disable Duplicate Address Detection (DAD) for the IPv6 privacy extensions on my Wifi interface wlan0:

sudo sysctl net.ipv6.conf.wlan0.accept_dad=0

Please note: if you use wired ethernet eth0, you should do something like this:

sudo sysctl net.ipv6.conf.eth0.accept_dad=0

It is unclear to me where the problem is: in Linux itself , or in my modem, or in the interaction between Linux and my modem.
The problem also occurs in OpenSuSE 12.2 on the same LAN, so it's not a Ubuntu-only problem.

Bug report is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1120617

Update: it seems to be related to Wifi; it does not happen with wired ethernet.

Easy Happy Eyeballs Testing

Easy Happy Eyeballs Testing

Nice article on http://ipv6friday.org/blog/2012/11/happy-testing/ how to test your application against Happy Eyeballs. In short, "Happy Eyeballs" (RFC 6555) means choosing the most fast (or fast enough) connection on dual-stack systems (IPv4 and IPv6).

And the testing is easy: use the URLs below in your applications (wget, curl, chrome, firefox, etc) to test your application's behaviour


A 'good' (= Happy Eyeballed) application should NOT get a slow time-out, but should connect with a second or so.

Example: curl (version 7.27.0) is not Happy-Eyeballed:

sander@R540:~$ time curl http://badipv4.test.ipv6friday.org/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   226  100   226    0     0   2054      0 --:--:-- --:--:-- --:--:--  4520

real 0m0.124s
user 0m0.012s
sys 0m0.004s

sander@R540:~$ time curl http://badipv6.test.ipv6friday.org/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   226  100   226    0     0      3      0  0:01:15  0:01:03  0:00:12    54

real 1m3.227s
user 0m0.020s
sys 0m0.008s

Explanation: the second URL takes more than one minute (!), so curl 7.27.0 waits for a loooong timeout. :-(