The TU Delft (Delft University of Technology) webserver is on IPv6:
$ host www.tudelft.nl
www.tudelft.nl has address 131.180.77.102
www.tudelft.nl 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)
Monday, December 23, 2013
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 http://192.168.0.1/ , 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 'http://192.168.0.1/index.htm'
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 'http://192.168.0.1/stanet.htm' | grep -i sta_ip:
var st2={sta_ip:"83.128.180.11",sta_mac:"64:D1:A3:07:20:AA",sta_mask:"255.255.252.0",sta_dns1:"62.45.45.45,62.45.46.46",sta_gw:"83.128.180.1"};
So my public IPv4 address is 83.128.180.11
Get an overview of the traffic (alas in packets, not in bytes):
$ curl --silent --user admin:8BT5J5YAAAA 'http://192.168.0.1/stats.htm' | grep -i wRxNum:
var st={wlDev:"1",wlTxNum:" 15406",wlRxNum:" 30387",lTxNum:" 1031",lRxNum:" 562",wTxNum:" 4133",wRxNum:" 7482"};
(Met dank aan Rob voor de Sitecom)
Assuming your Sitecom is on http://192.168.0.1/ , 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 'http://192.168.0.1/index.htm'
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 'http://192.168.0.1/stanet.htm' | grep -i sta_ip:
var st2={sta_ip:"83.128.180.11",sta_mac:"64:D1:A3:07:20:AA",sta_mask:"255.255.252.0",sta_dns1:"62.45.45.45,62.45.46.46",sta_gw:"83.128.180.1"};
So my public IPv4 address is 83.128.180.11
Get an overview of the traffic (alas in packets, not in bytes):
$ curl --silent --user admin:8BT5J5YAAAA 'http://192.168.0.1/stats.htm' | 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 'http://192.168.0.1/stats.htm' | grep -i wRxNum: | awk -F "[^0-9]*" '{ print $(NF-2) "\n" $(NF-1) "\n\n" }'
13689485
38296365
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 'http://192.168.0.1/stats.htm' | grep -i wRxNum: | awk -F "[^0-9]*" '{ print 90*$(NF-2) "\n" 1200*$(NF-1) "\n\n" }'
1253322450
46662481200
Note: you have to change (NF-2) and (NF-1) to get the right Up and Down
$ curl --silent --user admin:8BT5J5Y6AAAA 'http://192.168.0.1/stats.htm' | grep -i wRxNum: | awk -F "[^0-9]*" '{ print $(NF-2) "\n" $(NF-1) "\n\n" }'
13689485
38296365
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 'http://192.168.0.1/stats.htm' | grep -i wRxNum: | awk -F "[^0-9]*" '{ print 90*$(NF-2) "\n" 1200*$(NF-1) "\n\n" }'
1253322450
46662481200
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 'http://192.168.0.1/ipv6_stainfo.htm' | 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 security.ubuntu.com (2001:67c:1562::13)]
0% [Connecting to security.ubuntu.com (2001:67c:1360:8c01::18)]
0% [Connecting to security.ubuntu.com (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 https://github.com/royhills/arp-scan.git
cd arp-scan/
aclocal
autoheader
autoreconf -i
automake
autoconf
./configure
make
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
sander@flappie:~/git/arp-scan$
That's it. Happy arp-scanning!
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 https://github.com/royhills/arp-scan.git
cd arp-scan/
aclocal
autoheader
autoreconf -i
automake
autoconf
./configure
make
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
sander@flappie:~/git/arp-scan$
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 (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1 64:d1:a3:03:8a:01 Sitecom Europe BV
192.168.0.113 00:06:dc:44:57:f3 Syabas Technology (Amquest)
192.168.0.102 04:46:65:7a:9d:55 (Unknown)
192.168.0.108 00:1f:e1:9f:eb:d2 Hon Hai Precision Ind. Co., Ltd.
192.168.0.109 f0:5a:09:35:ff:42 (Unknown)
192.168.0.102 04:46:65:7a:9d:55 (Unknown) (DUP: 2)
192.168.0.104 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 http://www.nta-monitor.com/tools-resources/security-tools/arp-scan and compile it. Result:
$ sudo ./arp-scan --localnet --interface=wlan0
Interface: wlan0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1 64:d1:a3:03:8a:01 Sitecom Europe BV
192.168.0.113 00:06:dc:44:57:f3 Syabas Technology (Amquest)
192.168.0.104 00:37:6d:01:ed:9a Murata Manufacturing Co., Ltd.
192.168.0.109 f0:5a:09:35:ff:42 Samsung Electronics Co.,Ltd
192.168.0.108 00:1f:e1:9f:eb:d2 Hon Hai Precision Ind. Co., Ltd.
192.168.0.102 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
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 (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1 64:d1:a3:03:8a:01 Sitecom Europe BV
192.168.0.113 00:06:dc:44:57:f3 Syabas Technology (Amquest)
192.168.0.102 04:46:65:7a:9d:55 (Unknown)
192.168.0.108 00:1f:e1:9f:eb:d2 Hon Hai Precision Ind. Co., Ltd.
192.168.0.109 f0:5a:09:35:ff:42 (Unknown)
192.168.0.102 04:46:65:7a:9d:55 (Unknown) (DUP: 2)
192.168.0.104 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 http://www.nta-monitor.com/tools-resources/security-tools/arp-scan and compile it. Result:
$ sudo ./arp-scan --localnet --interface=wlan0
Interface: wlan0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1 64:d1:a3:03:8a:01 Sitecom Europe BV
192.168.0.113 00:06:dc:44:57:f3 Syabas Technology (Amquest)
192.168.0.104 00:37:6d:01:ed:9a Murata Manufacturing Co., Ltd.
192.168.0.109 f0:5a:09:35:ff:42 Samsung Electronics Co.,Ltd
192.168.0.108 00:1f:e1:9f:eb:d2 Hon Hai Precision Ind. Co., Ltd.
192.168.0.102 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
sander@hapee:~$
Result:
$ netstat -s | grep -i octet | grep -vi cast
InOctets: 44243555321
OutOctets: 216954870
$
So counter is at 44GB, well above 4.2GB. No more rollover. :-)
EDIT:
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
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
sander@hapee:~$
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
UPDATE:
The current git version of net-tools / netstat solves the roll-over. Installation using git:
git clone git://net-tools.git.sourceforge.net/gitroot/net-tools/net-tools
cd net-tools/
make config
make
UPDATE:
The current git version of net-tools / netstat solves the roll-over. Installation using git:
git clone git://net-tools.git.sourceforge.net/gitroot/net-tools/net-tools
cd net-tools/
make config
make
sudo make install
Result:
$ netstat -s | grep -i octet | grep -vi cast
InOctets: 44243555321
OutOctets: 216954870
$
So counter is at 44GB, well above 4.2GB. No more rollover. :-)
EDIT:
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 }'
32688526
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'
178028250
sander@hapee:~$
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
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 }'
32648268
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'
177887898
32648268
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'
177887898
sander@hapee:~$ wget -4 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso -O /dev/null
sander@hapee:~$ netstat -s | grep "total packets" | awk '{ print $1 }'
32688502
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'
177887937
32688502
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'
177887937
sander@hapee:~$ wget -6 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso -O /dev/null
sander@hapee:~$ netstat -s | grep "total packets" | awk '{ print $1 }'
32688526
sander@hapee:~$ netstat -s -6 | grep "total packets" | awk '{ print $1 }'
178028250
sander@hapee:~$
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 http://www.appelboor.com/dump/blocklist.txt 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
wget with IPv6 on Windows
If you need wget with IPv6 on Windows: it is here: https://code.google.com/p/osspack32/downloads/detail?name=wget-1.14.exe&can=2&q=
Tip: use the option "-6" to force IPv6.
C:\>wget -6 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Tip: use the option "-6" to force IPv6.
C:\>wget -6 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
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:
- Upgrade your Sitecom router to firmware 2.4 (or higher)
- Make sure your Sitecom is ping-able from Internet
- Create an account on http://www.tunnelbroker.net/
- On that tunnel page, request the “Routed /48”
- From the tunnel page, the following items are relevant:
- Server IPv4 Address
- Client IPv4 Addres (=your own public IPv4 address)
- Routed /48
- In the Sitecom, click on "Internet Settings", then "IPv6 Settings". Choose "6RD" in the firs drop down option
- Then fill out the Sitecom form as in the screendump below
It should now work. So, with your laptop/PC, go to http://test-ipv6.com/ 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):
sander@flappie:~$ wget -6 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso -O /dev/null
--2013-04-19 16:32:06-- http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|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]
sander@flappie:~$
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 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
--2013-04-19 16:57:58-- http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|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]
C:\>
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 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso -O /dev/null
--2013-04-19 18:24:42-- http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|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]
ubuntu@ubuntu:~$
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 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso -O /dev/null
--2013-04-19 18:24:42-- http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|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]
ubuntu@ubuntu:~$
Monday, March 18, 2013
IPv6 MTU discovery
Thanks to http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu-size-with-icmp-pings it looks like it's easy to discover the IPv6 MTU (Maximum Transmission Unit):
$ ping6 -c1 -M do -s 10000 www.google.com | grep mtu | awk '{ print $NF }'
mtu=1500
$ ping6 -c1 -M do -s 10000 www.google.com | grep mtu | awk '{ print $NF }'
mtu=1500
So the IPv6 MTU to www.google.com is 1500.
From another system, the MTU is 1480:
$ ping6 -c1 -M do -s 10000 www.google.com | grep mtu | awk '{ print $NF }'
mtu=1480
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 www.google.com | grep mtu | awk '{ print $NF }' | sed -e s/\)//
1500
HTH
Sunday, March 10, 2013
Dutch ISP Telfort introduces IPv6
After conducting an IPv6 pre-pilot (see http://ipv6-or-no-ipv6.blogspot.nl/2012/01/dutch-isp-telfort-conducting-ipv6-pre.html), 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:
That's it. You should now have IPv6. Check via http://ip6.nl/ or http://test-ipv6.com/. 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.
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 http://192.168.1.254/
- 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 http://ip6.nl/ or http://test-ipv6.com/. 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:
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.
IPv6: wlan0: IPv6 duplicate address 2a00:cd8:
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.
Please note: if you use wired ethernet eth0, you should do something like this:
sudo sysctl net.ipv6.
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. :-(
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.
Subscribe to:
Posts (Atom)