Self-scan your IPv6 ports

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

http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi

Direct link for well known ports:

http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi?includeexisting=1&customport0=&customport1=&customport2=&customport3=

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

http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi?includeexisting=1&customport0=12345&customport1=&customport2=&customport3=

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.
sander@toverdoos:~$ 


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

http://badipv6.test.ipv6friday.org/
http://badipv4.test.ipv6friday.org/

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:~$ 

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
sander@R540:~$

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