Monday, December 23, 2013

TU Delft on IPv6 ... loving their IPv4 addresses

The TU Delft (Delft University of Technology) webserver is on IPv6:

$ host has address has IPv6 address 2001:610:908:112:131:180:77:102

Ah, apparently they love their IPv4 address scheme, as they have put their IPv4 address into their IPv6 address: 2001:610:908:112:131:180:77:102

(Thank you @Whreq)

Wednesday, December 11, 2013

Use curl to read your Sitecom WLR-4100 X4 N300 (and X6)

If you want to read out your Sitecom WLR-4100 X4 N300 (and X6) from the command line, here's how to do that with curl (alas Sitecom seems to have no SNMP nor telnet).

Assuming your Sitecom is on , make sure you can log in on the Sitecom router with your favorite webbrowser: username is 'admin', password is on a sticker on the bottom of your Sitecom at "WPA2 password". In the examples below I use the password '8BT5J5Y6AAAA'

If that works, first test that a plain curl login works:

curl --user admin:8BT5J5Y6AAAA ''

That should give some HTML garbage, but not "401 Unauthorized". If you get "401 Unauthorized" recheck your password.

If it works, you can proceed:

Get your public IPv4 address:

$ curl --silent --user admin:8BT5J5Y6AAAA '' | grep -i sta_ip:

var st2={sta_ip:"",sta_mac:"64:D1:A3:07:20:AA",sta_mask:"",sta_dns1:",",sta_gw:""};

So my public IPv4 address is

Get an overview of the traffic (alas in packets, not in bytes):

$ curl --silent --user admin:8BT5J5YAAAA '' | grep -i wRxNum:

var st={wlDev:"1",wlTxNum:"  15406",wlRxNum:"  30387",lTxNum:"   1031",lRxNum:"    562",wTxNum:"   4133",wRxNum:"   7482"};

You need to parse that output to get what you want. Here's the Sent Packets and Receive Packets (so: not bytes) on your Ethernet WAN interface you could feed into MRTG:

$ curl --silent --user admin:8BT5J5Y6AAAA '' | grep -i wRxNum: | awk -F "[^0-9]*"  '{ print $(NF-2) "\n" $(NF-1) "\n\n" }'


Looks good. Warning: these are packets ...not bytes. Multiply with the typical packet size in Send resp Received direction (so 50 resp 1200?) to get bytes. Example:

$ curl --silent --user admin:8BT5J5Y6AAAA '' | grep -i wRxNum: | awk -F "[^0-9]*"  '{ print 90*$(NF-2) "\n" 1200*$(NF-1) "\n\n" }'


Note: you have to change (NF-2) and (NF-1) to get the right Up and Down

As this is an IPv6 blog, here is some IPv6 stuff:

$ curl --silent --user admin:8BT5J5Y6AAA ''   | grep -i fe80

var ipv6_wan_linklocal = 'fe80::66d1:a3ff:fe07:aaaa/64';
var ipv6_linklocal = 'fe80::66d1:a3ff:fe07:aaaa/64';

Happy curling!

(Met dank aan Rob voor de Sitecom)

Monday, September 23, 2013

apt-get not happy eyeball-ed ... ugly workaround

The tool 'apt-get' has no "happy eyeball" (RFC 6555) features. That means that a bad IPv6 connection can cause long delays: a plain "sudo apt-get update" took 18 minutes on my already uptodate machine. :-(

Cause: apt-get tries each server and it takes a long time to time-out:

0% [Connecting to (2001:67c:1562::13)]    
0% [Connecting to (2001:67c:1360:8c01::18)]
0% [Connecting to (2001:67c:1562::15)]    

As long as apt-get has no happy eyeball built in, there is a ugly work around:

Create a file /etc/apt/apt.conf.d/99timeout with these contents

Acquire::http::Timeout "2";
Acquire::ftp::Timeout "2";

Now the time-out on non-reachable (IPv6) servers only takes two seconds.

Monday, September 16, 2013

Install Git version of arp-scan on Ubuntu and Raspbian

If you need the newest arp-scan (for example because of it's uptodate MAC address list), here is how to install the Git version of arp-scan on Ubuntu and Raspberry's Raspbian (and probably Debian).

Disclaimer: no IPv6 involved.

Here's the set of commands:

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install automake libpcap-dev

git clone
cd arp-scan/

autoreconf -i
sudo ./arp-scan --localnet --interface=wlan0

That should work: it should give the MAC addresses visible via interface wlan0. Change to eth0 if you're system is connected via eth0.

To install the new arp-scan unto your system:

sudo make install
sudo arp-scan --localnet --interface=wlan0

Check the version:

sander@flappie:~/git/arp-scan$ sudo ./arp-scan --version
arp-scan 1.9.2

Copyright (C) 2005-2013 Roy Hills, NTA Monitor Ltd.
arp-scan comes with NO WARRANTY to the extent permitted by law.
You may redistribute copies of arp-scan under the terms of the GNU
General Public License.
For more information about these matters, see the file named COPYING.

libpcap version 1.3.0

That's it. Happy arp-scanning!

Sunday, August 11, 2013

Scan ARP MAC addresses of other devices on the LAN

(Disclaimer: this is not IPv6 related. Just plain IPv4)

It can be useful to see which other devices are connected to a LAN, and then check the MAC address to get some kind identification. This way you can see - for example - if a smartphone is there, so thus guess if a certain person is there.

There is an easy tool for that: "arp-scan". It's available on Ubuntu Linux 13.04 after installing it "sudo apt-get install arp-scan". You have to run it as root:

$ sudo arp-scan --localnet --interface=wlan0
Interface: wlan0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.8.1 with 256 hosts ( 64:d1:a3:03:8a:01 Sitecom Europe BV 00:06:dc:44:57:f3 Syabas Technology (Amquest) 04:46:65:7a:9d:55 (Unknown) 00:1f:e1:9f:eb:d2 Hon Hai Precision Ind. Co., Ltd. f0:5a:09:35:ff:42 (Unknown) 04:46:65:7a:9d:55 (Unknown) (DUP: 2) 00:37:6d:01:ed:9a (Unknown) (DUP: 1)

7 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.8.1: 256 hosts scanned in 1.336 seconds (191.62 hosts/sec). 7 responded

It works, but some MAC addresses are unknown. If you want the newer version, get it from and compile it. Result:

$ sudo ./arp-scan --localnet --interface=wlan0
Interface: wlan0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts ( 64:d1:a3:03:8a:01 Sitecom Europe BV 00:06:dc:44:57:f3 Syabas Technology (Amquest) 00:37:6d:01:ed:9a Murata Manufacturing Co., Ltd. f0:5a:09:35:ff:42 Samsung Electronics Co.,Ltd 00:1f:e1:9f:eb:d2 Hon Hai Precision Ind. Co., Ltd. 04:46:65:7a:9d:55 Murata Manufacturing Co., Ltd.

6 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9: 256 hosts scanned in 1.981 seconds (129.23 hosts/sec). 6 responded

So the f0:5a:09:35:ff:42 is my Samsung Android smartphone. That means I'm at home (or I left my phone at home ;-) )

Tip: run arp-scan a few times; sometimes it shows more lines that other times.

Thursday, June 13, 2013

Measure IPv4 versus IPv6 traffic with netstat on Linux

There appears to be an easy way to measure IPv4 versus IPv6 traffic on Linux:

sander@hapee:~$ netstat -s  | grep -i octet | grep -vi cast
    InOctets: 242397362
    OutOctets: 76157803
sander@hapee:~$ netstat -s -6 | grep -i octet | grep -vi cast
    Ip6InOctets: 105884560
    Ip6OutOctets: 21024110

For those who don't know: an octet is an 8-bit byte.

Be aware that that the netstat counter apparantly is 32-bit, and two's complement, so the value will go from 0 to 2^31, and then to -2^31. So the value can be negative:

sander@hapee:~$ netstat -s  | grep -i octet | grep -vi cast
    InOctets: -249959401
    OutOctets: 72041351

If you use MRTG, MRTG can take care of these rollovers


The current git version of net-tools / netstat solves the roll-over. Installation using git:

git clone git://
cd net-tools/
make config
sudo make install


$ netstat -s | grep -i octet | grep -vi cast
    InOctets: 44243555321
    OutOctets: 216954870

So counter is at 44GB, well above 4.2GB. No more rollover. :-)

A one-liner to show traffic in GB:

$ ./netstat -s | grep -i octet | grep -vi cast | awk '{ print $2/(1024*1024*1024) " GB" }'
65.0086 GB
1.51142 GB

$ ./netstat -s -6 | grep -i octet | grep -vi cast | awk '{ print $2/(1024*1024*1024) " GB" }'
5.0461111 GB
0.7176651 GB

Monday, June 3, 2013

Use netstat to show IPv4 versus IPv6 traffic

If you wonder how much IPv6 versus IPv4 traffic your system does, there is an nice estimation: use "netstat -s" to show the amount of inbound packets. Packets is not the same as bytes, but assuming the IPv4 packets have the same mean size as IPv6 packets, you're fine. The exact commands are:

netstat -s | grep "total packets" | awk '{ print $1 }'
netstat -s -6 | grep "total packets" | awk '{ print $1 }'

which will show the packets for IPv4 resp IPv6

Please note that the first command will only show IPv4 packets, and not the total of IP packets. See the below test for proof

sander@hapee:~$ netstat -s | grep "total packets" | awk '{ print $1 }'
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'

sander@hapee:~$ wget -4 -O /dev/null

sander@hapee:~$ netstat -s | grep "total packets" | awk '{ print $1 }'
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'

sander@hapee:~$ wget -6 -O /dev/null

sander@hapee:~$ netstat -s | grep "total packets" | awk '{ print $1 }'
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'

In the above output you'll see the IPv4-download only rises the first counter (meaning it only measures IPv4), and the IPv6-download only rises the second counter (IPv6 traffic).
I'm writing a tool to put this info into MRTG graphs

Saturday, April 20, 2013

IPv6 only bittorrent with Transmission

You can make Tranmission share torrent files via IPv6 only quite easily: just add as the blocklist via Transmission: Edit -> Preferences -> Privacy.

Result: IPv6 only peers:

Download speeds is around 24 Mbps, so quite reasonable:

Friday, April 19, 2013

A lot of bittorrent IPv6 peers ...

wget with IPv6 on Windows

If you need wget with IPv6 on Windows: it is here:

Tip: use the option "-6" to force IPv6.

C:\>wget -6

Setting up a Sitecom X6 router with a HE IPv6 tunnel

Here's an instruction how to setup the Sitecom WLR-6100 X6 N900 router with a Hurricane Electric IPv6 Tunnel. It will probably also work with other Sitecom routers, like the X4.

The trick is to use a Routed /48 tunnel.

In short: Request a tunnel with routed /48 from Hurricane Electric and use just three parameters to set up 6RD IPv6 in your Sitecom.

The longer description:

  1. Upgrade your Sitecom router to firmware 2.4 (or higher)
  2. Make sure your Sitecom is ping-able from Internet
  3. Create an account on
  4. Request a tunnel on . Choose a tunnel provider near you
  5. On that tunnel page, request the “Routed /48”
  6. From the tunnel page, the following items are relevant:
    1. Server IPv4 Address
    2. Client IPv4 Addres (=your own public IPv4 address)
    3. Routed /48
  7. In the Sitecom, click on "Internet Settings", then "IPv6 Settings". Choose "6RD" in the firs drop down option
  8. Then fill out the Sitecom form as in the screendump below

It should now work. So, with your laptop/PC, go to to see if you have IPv6 connectivity. That site should say something like "Your IPv6 address on the public Internet appears to be 2001:470:... (HURRICANE - Hurricane Electric, Inc.)".

Screendump (click for larger image):

The throughput over Wifi is quite impressive: I get 11,3 MB/s, thus about 113 Mbps. (on my 300/300 Mbps Internet connection). See this output:

sander@flappie:~$ wget -6 -O /dev/null
--2013-04-19 16:32:06--
Resolving ( 2001:6a8:3c80:2::21
Connecting to (|2001:6a8:3c80:2::21|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 726970368 (693M) [application/x-iso9660-image]
Saving to: ‘/dev/null’

 6% [==>                                                ] 49.882.045  11,5MB/s  eta 61s    
28% [=============>                                     ] 206.782.525 11,5MB/s  eta 45s    
71% [===================================>               ] 520.086.461 11,2MB/s  eta 18s    
100%[==================================================>] 726.970.368 11,3MB/s   in 61s    

2013-04-19 16:33:08 (11,3 MB/s) - ‘/dev/null’ saved [726970368/726970368]


I can't test the IPv6 speed of wired ethernet as the Sitecom becomes completely unreachable with 3 seconds when do that. So I would say that's a bug in the Sitecom.

Update: with another laptop (HP with Windows7, instead of Samsung with Ubuntu), IPv6 over wired ethernet does not lock up the Sitecom, and the speed is impressive:

C:\>wget-1.14.exe -6
--2013-04-19 16:57:58--
Resolving ( 2001:6a8:3c80:2::21
Connecting to (|2001:6a8:3c80:2::21|:80... connected
HTTP request sent, awaiting response... 200 OK
Length: 726970368 (693M) [application/x-iso9660-image]
Saving to: 'ubuntu-12.04.2-desktop-i386.iso.1'

100%[======================================>] 726,970,368 24.1MB/s   in 29s

2013-04-19 16:58:27 (24.1 MB/s) - 'ubuntu-12.04.2-desktop-i386.iso.1' saved [726970368/726970368]


So ... that's 24.1 MB/s, or 241 Mbps...! FWIW: tested on a 300/300 Mbps Caiway FttH connection.

Update 2: with the same laptop (HP) with Ubuntu, the speed is even higher: 34.1 MB/s, or 341 Mbps. Kudo's to the Sitecom router for handling the IPv6 at this great speed.

ubuntu@ubuntu:~$ wget -6 -O /dev/null
--2013-04-19 18:24:42--
Resolving ( 2001:6a8:3c80:2::21
Connecting to (|2001:6a8:3c80:2::21|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 726970368 (693M) [application/x-iso9660-image]
Saving to: ‘/dev/null’

39% [==============> ] 289,894,144 36.7MB/s eta 13s
79% [=============================> ] 577,715,328 37.2MB/s eta 5s
100%[======================================>] 726,970,368 27.6MB/s in 20s

2013-04-19 18:25:02 (34.1 MB/s) - ‘/dev/null’ saved [726970368/726970368]


    Monday, March 18, 2013

    IPv6 MTU discovery

    Thanks to it looks like it's easy to discover the IPv6 MTU (Maximum Transmission Unit):

    $ ping6 -c1 -M do -s 10000  | grep mtu | awk '{ print $NF }' 


    So the IPv6 MTU to is 1500.

    From another system, the MTU is 1480:

    $ ping6 -c1 -M do -s 10000  | grep mtu | awk '{ print $NF }'


    Easy, isn't it?

    For old-skool IPv4, the output of ping is a bit different, so the awk parsing is a bit different:

    $ ping -c1 -M do -s 10000 | grep mtu | awk '{ print $NF }' | sed -e s/\)//



    Sunday, March 10, 2013

    Dutch ISP Telfort introduces IPv6

    After conducting an IPv6 pre-pilot (see, Dutch ISP pilot Telfort has silently introduced IPv6 for all its DSL (VDSL and ADSL) customers. I don't know about its FttH customers. And mobile customers probably have to wait.

    Telfort's IPv6 is opt-in; you have to enable it in your Zyxel modem. This is how:

    • Log in on your Zyxel modem at 
    • Go to Network Setting -> Broadband. At the top of that page, check which connection is used: VDSL or ADSL. Then find that entry in the table below, and click on the corresponding "Modify" icon on the far right
    • In the windows that pops up, at "IPv6/IPv4 DualStack" click enable. More below, enable "6to4 Tunneling" and check "6RD Enable". Then click the Apply button
    • Final check: the column IPv6 should now be on "enable" at your VDSL or ADSL line.

    That's it. You should now have IPv6. Check via or If not, reboot your  modem and computer once.

    Technology used is 6RD. Address prefix is 2A00:CD8::/32

    Telfort's mother company KPN yet has to introduce IPv6.

    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 '' | 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:

    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 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 > /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 > /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. :-(

    Saturday, January 5, 2013

    1% of Google visitors use IPv6

    Interesting: Google measures the availability of IPv6 connectivity among Google users. At the beginning of 2012 it was 0.4%, at the end of 2012 it was 1%. So it multiplied with a factor 2.5. That would mean 2.5% IPv6 Google users at the end of 2013. Not bad.

    Oh, Teredo usage dropped from 0.1% to 0.01%. I had not expected that.