Netflix and tunneled IPv6

Suddenly my Netflix was only showing English as language/subtitles option, and no more Dutch.

I contacted Netflix via chat, and 'Jeremy' asked me "are you using a proxy, because we see you coming from the US".

Hmmm. I use Hurricane Electric's IPv6 tunnel, and as netflix.com has AAAA addresses, it could be my Netflix was flowing through IPv6, and because of HE's location, it was considered to be coming from the US. And thus no more Dutch language.

I couldn't find how to disable IPv6 in Chrome, so I started Firefox and disabled IPv6 via about:config. And ... tada ... the Dutch language was back.

So tunneled IPv6 has it's disadvantages.

TU Delft on IPv6 ... loving their IPv4 addresses

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)

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"};

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

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)

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.

Thanks to http://askubuntu.com/questions/141513/how-to-lower-wait-time-for-repository-updates

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!

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

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.

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

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

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