|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Unlike most folks, I value first-hop latency on residential networks over gobs of bandwidth. Why? It's likely to have a larger impact to my web browsing experience than bandwidth, in many cases.
I've got 50 Mbps downstream and 10 Mbps upstream at home via Comcast Business, at the moment. Unfortunately, I pay a bit for it because I have a static IPv4 /29 prefix. Anyway, the 50 Mbps downstream is good enough for streaming and downloading most content (20 Mbps would work, too, I guess). The 10 Mbps is mildly sufficient for me but gets a little painful when uploading videos or transferring large files via rsync over SSH.
If I could pay $5 or $10 more per month for 100 Mbps downstream, I probably wouldn't bother. Excluding video-rich sites, I don't see more than 4-5 Mbps at peak when loading web pages and browsing the web.
However, I'd pay more to reduce the first-hop latency since most web content is coming from CDN nodes that are nearby. Lower latency impacts the initial stages of TCP significantly and can have a large impact on transferring web content quickly over short-lived connections.
Comcast's got an Akamai CDN node on-net, which is about 10 ms from me:
(valen:12:31)% mtr --report --report-cycles=10 --report-wide www.akamai.com. Start: Tue Nov 17 12:31:34 2015 HOST: valen Loss% Snt Last Avg Best Wrst StDev 1.|-- 2001:558:4082:48::1 10.0% 10 8.3 24.3 8.3 133.6 41.0 2.|-- te-0-2-0-5-sur03.burien.wa.seattle.comcast.net 0.0% 10 13.6 10.6 7.8 13.6 1.7 3.|-- be-21-ar01.seattle.wa.seattle.comcast.net 0.0% 10 10.0 10.8 9.2 13.8 1.5 4.|-- be-33650-cr02.seattle.wa.ibone.comcast.net 60.0% 10 14.2 12.6 11.3 14.2 1.0 5.|-- hu-0-11-0-0-pe04.seattle.wa.ibone.comcast.net 0.0% 10 10.3 11.3 9.1 16.6 2.1 6.|-- as20940-2-c.seattle.wa.ibone.comcast.net 0.0% 10 9.7 11.5 9.7 14.4 1.3 7.|-- 2600:1409:a:1a0::22d9 0.0% 10 9.6 13.3 9.1 24.9 5.0
While I live in West Seattle, apparently the CMTS I use is down south in Burien, WA, likely due to the geography of the region. It takes about ~7-8 ms to get to the CMTS. This is my first hop latency (hop 1 is my Comcast modem since it's in L3 mode for the static IPv4 assignment). As you can see above, the bulk of my latency to the Akamai cache is due to the first hop. DOCSIS has a request/grant system (see slide 16 in this PDF) for accessing upstream bandwidth, which adds an extra "round trip" to the communication from my cable modem to the CMTS. If that were somehow lowered to 1 ms or so (GPON?), I'm sure most of the web would "feel" faster since my latency to the cache would be around 2-3 ms.
As another example, Google doesn't have a cache on Comcast's network but they aren't too far away:
(valen:12:31)% mtr --report --report-cycles=10 --report-wide www.google.com. Start: Tue Nov 17 12:32:08 2015 HOST: valen Loss% Snt Last Avg Best Wrst StDev 1.|-- 2001:558:4082:48::1 30.0% 10 27.5 13.4 9.2 27.5 6.5 2.|-- te-0-2-0-5-sur02.burien.wa.seattle.comcast.net 0.0% 10 8.1 9.8 8.1 11.6 0.8 3.|-- be-21-ar01.burien.wa.seattle.comcast.net 0.0% 10 9.3 9.2 8.0 10.2 0.6 4.|-- he-0-13-0-0-ar01.seattle.wa.seattle.comcast.net 0.0% 10 11.2 10.3 8.7 14.6 1.6 5.|-- be-33650-cr02.seattle.wa.ibone.comcast.net 70.0% 10 13.6 12.5 10.5 13.6 1.6 6.|-- 2001:558:0:f510::2 60.0% 10 13.3 12.0 9.8 13.3 1.4 7.|-- 2001:559::cfa 0.0% 10 9.4 11.7 8.6 28.9 6.1 8.|-- 2001:4860::1:0:9aa5 0.0% 10 9.7 11.0 8.8 14.0 1.8 9.|-- 2001:4860::8:0:6999 0.0% 10 10.2 16.4 9.3 50.7 12.6 10.|-- 2001:4860::8:0:61e1 0.0% 10 14.4 17.0 12.7 44.6 9.7 11.|-- 2001:4860::8:0:924a 0.0% 10 16.1 17.0 15.0 20.8 1.5 12.|-- 2001:4860::2:0:90fe 0.0% 10 16.3 17.6 15.7 22.0 1.8 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- pb-in-x93.1e100.net 0.0% 10 28.1 18.8 14.9 28.1 4.6
That 15 ms to the Google content node could be reduced to around 7-8 ms if my first-hop latency went away, too!
It just so happens that I graph my first-hop latency to the CMTS using SmokePing. Here's a graph over the last year:
It doesn't change too much. I'm curious what happened in June to drop my latency by what looks to be 1-1.5 ms, but only Comcast would really know. The heightened latency in January and February were due to a memory leak in my cable modem, I think.
Also, low latency is obviously good for gaming, which doesn't really apply to me, and other interactive applications like SSH. vimdiff(1), for example, is pretty painful on a high latency connection due to the way if repaints the entire terminal window.
To compare my Comcast connection with other residential technologies, here's what I've seen for first hop latencies:
Obviously, the lowest latency is going to come from an Ethernet-based service, something like wave G (formerly condointernet). I'm fairly sure it's limited to apartments and condiminiums in major metropolitan areas like downtown Seattle.
So, in a nutshell, that's why I'm not impressed with 300 Mbps vs. 50 Mbps DOCSIS service, a 50 Mbps Ethernet DIA service might be appealing.
Comcast Business decided to give me some IPv6 lovin' a week or two ago on my DOCSIS connection. Unfortunately, it still seems to be a work in progress.
The above is the IPv6 configuration screen on my (well, Comcast Business') NETGEAR CG3000DCR. I've got a /56 that I suspect was obtained via DHCPv6-PD on the DOCSIS interface. The LAN interface has a /64 out of that /56 and supports DHCPv6-PD as well. It's also got RAs enabled with RDNSS:
21:08:16.491207 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::c604:15ff:febe:e634 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 120 hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s source link-address option (1), length 8 (1): c4:04:15:be:e6:34 0x0000: c404 15be e634 prefix info option (3), length 32 (4): 2601:8:a401:4c00::/64, Flags [onlink, auto], valid time 345600s, pref. time 345600s 0x0000: 40c0 0005 4600 0005 4600 0000 0000 2601 0x0010: 0008 a401 4c00 0000 0000 0000 0000 unknown option (24), length 24 (3): 0x0000: 3800 0005 4600 2601 0008 a401 4c00 0000 0x0010: 0000 0000 0000 rdnss option (25), length 40 (5): lifetime 60s, addr: 2001:558:feed::1 addr: 2001:558:feed::2 0x0000: 0000 0000 003c 2001 0558 feed 0000 0000 0x0010: 0000 0000 0001 2001 0558 feed 0000 0000 0x0020: 0000 0000 0002
The RDNSS allows IPv6 clients that have not yet embraced DHCPv6 to mostly work without IPv4, which is nice (although I still think it's a hack).
I was puzzled by the other options on the configuration screen, though. The "Enable Unicast" and "Enable Rapid Commit" initially meant nothing to me and I assumed the "Enable EUI-64 Addressing" toggled the "A" flag in the RA. I individually toggled all of the options and compared the results, which required a few reboots, unfortunately. From what I can tell the "Enable Rapid Commit" and "Enable EUI-64 Addressing" options do absolutely nothing to the RA messages. However, "Enable Unicast" removes all the flags and all but one option in the RA:
20:59:52.178671 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::c604:15ff:febe:e634 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
hop limit 64, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): c4:04:15:be:e6:34
0x0000: c404 15be e634
I'm not sure why that option isn't labeled appropriately or why enabling "unicast" would result in such a configuration. Silly consumer networking equipment.
Anyway, I threw a host on the link and, of course, started running some traceroutes. I expected to see the LAN interface of the CG3000DCR as the first hop, but I didn't:
HOST: rpi Loss% Snt Last Avg Best Wrst StDev 1.|-- 2001:558:4082:48::1 0.0% 1 10.8 10.8 10.8 10.8 0.0 2.|-- te-0-2-0-5-ur07.burien.wa.seattle.comcast.net 0.0% 1 9.0 9.0 9.0 9.0 0.0 3.|-- ae-21-0-ar03.burien.wa.seattle.comcast.net 0.0% 1 8.7 8.7 8.7 8.7 0.0 4.|-- be-1-sur03.ferndale.wa.seattle.comcast.net 0.0% 1 11.8 11.8 11.8 11.8 0.0 5.|-- he-1-3-0-0-10-cr01.seattle.wa.ibone.comcast.net 0.0% 1 10.9 10.9 10.9 10.9 0.0 6.|-- pos-2-14-0-0-cr01.seattle.wa.ibone.comcast.net 0.0% 1 26.2 26.2 26.2 26.2 0.0 7.|-- be-10-pe02.111eighthave.ny.ibone.comcast.net 0.0% 1 27.0 27.0 27.0 27.0 0.0 8.|-- 10gigabitethernet1-1-3.switch1.sjc2.he.net 0.0% 1 29.3 29.3 29.3 29.3 0.0 9.|-- 10ge1-1.core1.fmt1.he.net 0.0% 1 81.8 81.8 81.8 81.8 0.0 10.|-- he.net 0.0% 1 37.3 37.3 37.3 37.3 0.0
Other than the bad PTR on hop #7, the first hop was unexpected. Is it, instead, the DOCSIS interface address that's being used in the ICMPv6 response?
(rpi:21:45)% mtr -rwc1 2001:558:4082:48::1 Start: Fri Dec 5 21:46:21 2014 HOST: rpi Loss% Snt Last Avg Best Wrst StDev 1.|-- 2001:558:4082:48::1 0.0% 1 9.1 9.1 9.1 9.1 0.0
Maybe. But when I traceroute to my host from the outside, why do I see 2001:558:a2:f3::2, instead?
HOST: netflix01.ring.nlnog.net Loss% Snt Last Avg Best Wrst StDev 1.|-- 2a00:86c0:ff0a:2906::1 0.0% 2 1.0 1.0 1.0 1.0 0.0 2.|-- 2a00:86c0:26c::9 0.0% 1 0.3 0.3 0.3 0.3 0.0 3.|-- 2001:559::ca1 0.0% 1 0.9 0.9 0.9 0.9 0.0 4.|-- be-17-cr01.56marietta.ga.ibone.comcast.net 0.0% 1 1.6 1.6 1.6 1.6 0.0 5.|-- 2001:558:0:f747::2 0.0% 1 19.2 19.2 19.2 19.2 0.0 6.|-- be-21-ur07.burien.wa.seattle.comcast.net 0.0% 1 20.4 20.4 20.4 20.4 0.0 7.|-- 2001:558:a2:f3::2 0.0% 1 18.8 18.8 18.8 18.8 0.0 8.|-- 2601:8:a401:4c00:ba27:ebff:fe8f:7486 0.0% 1 28.4 28.4 28.4 28.4 0.0
This appears to be an anomaly when an ICMPv6-based traceroute is used. A UDP one works as expected:
(rpi:21:49)% mtr -u -rwc1 he.net. Start: Fri Dec 5 21:49:35 2014 HOST: rpi Loss% Snt Last Avg Best Wrst StDev 1.|-- 2601:8:a401:4c00:c604:15ff:feee:e634 0.0% 1 0.9 0.9 0.9 0.9 0.0 2.|-- 2001:558:4082:48::1 0.0% 1 16.2 16.2 16.2 16.2 0.0 3.|-- te-0-2-0-5-ur07.burien.wa.seattle.comcast.net 0.0% 1 8.9 8.9 8.9 8.9 0.0 4.|-- ae-21-0-ar03.burien.wa.seattle.comcast.net 0.0% 1 13.0 13.0 13.0 13.0 0.0 5.|-- be-1-sur03.ferndale.wa.seattle.comcast.net 0.0% 1 12.5 12.5 12.5 12.5 0.0 6.|-- he-1-3-0-0-10-cr01.seattle.wa.ibone.comcast.net 0.0% 1 11.1 11.1 11.1 11.1 0.0 7.|-- pos-2-14-0-0-cr01.seattle.wa.ibone.comcast.net 0.0% 1 28.2 28.2 28.2 28.2 0.0 8.|-- be-10-pe02.111eighthave.ny.ibone.comcast.net 0.0% 1 26.7 26.7 26.7 26.7 0.0 9.|-- 10gigabitethernet1-1-3.switch1.sjc2.he.net 0.0% 1 31.8 31.8 31.8 31.8 0.0 10.|-- 10ge1-1.core1.fmt1.he.net 0.0% 1 38.2 38.2 38.2 38.2 0.0 11.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
2001:558:4082:48::1 is obviously the CMTS.
Now that we've got the initial exploring out of the way, I figured I would try the "static route" feature on the CG3000DCR to see if it worked with IPv6 at all:
This was a complete fail. I tried adding a /64 static route to a static host I have on the link with a subnet mask of "64" and then one of "ffff:ffff:ffff:ffff::" but both failed.
As far as the permanency of this rather useless /56 I'm given, a quick look around on the support forums made me conclude that the current prefixes are dynamic and static prefixes will be rolled out in the future. I suppose that answers the question about reverse DNS delegation, too. I can't imagine that being a possibility at all without static assignments. I also sure do hope that they provide an option for delegation instead of just adding individual records like they do for IPv4 (and, poorly, I may add, since it must be done via a phone call).
I guess I'm not ready to dump my tunnels, yet. I'd like a static assignment and reverse DNS. Otherwise, the sweetness of native IPv6 still feels like a downgrade.
It occurred to me that I haven't blogged in quite some time. So, here you go!
I moved into my townhouse in West Seattle about a month ago. The house itself is about eight (8) years old so there's not much I'm going to change or replace right off the bat. My fiancée has one or two things to say about the color schemes in some of the rooms, though, so there will be painting in the future. It's in the High Point community, which is still expanding rapidly and there are lots of new townhouses and single family houses being built. Unpacking took awhile but I'm more or less settled, now. I do need to buy some more furniture in the future since I have roughly 450 more square footage than I did in Charlotte.
I managed to get lucky with the cabling. All of the rooms in the house are wired for Cat5e and are already punched down in a central Leviton telecom panel in the closet of the master bedroom:
There's also a second port in several rooms that is wired for Cat5e but all of those ports are wired together. I ended up connecting my old Linksys PAP2T to those ports for analog phone compatibility, which I've actually used a bit. I ended up putting my Juniper EX2200-C and ALIX box in the closet, as well:
I haven't turned up my lab yet, since I was told I shouldn't be putting any loud things in the bedroom closet.
Ah, Comcast. I started off with xfinity 50/10 HSD and basic cable, which seemed fine until I realized I couldn't get more than one public IPv4 address. Back in Charlotte I was able to get the CPE limit increased to three (3) so I could have two firewalls as well as a Linux box connected to the Internet. After a long call with a fairly clueful CSR, he informed me that they no longer are able to increase the CPE limits for residential HSD and I'd have to get business class, which I did.
I got the same 50/10 service from Comcast Business but with a static /29. They wouldn't let me use my own modem because I was getting a static assignment so they gave me a Comcast-branded NETGEAR CG3000DCR. I suspect this is because of how they inject the /29 into their network, which is probably via RIP. The speed is fine and the latency to the CMTS isn't too bad, although it seems to bounce around a bit:
Here's a traceroute showing that nice paid peering between Comcast and Netflix:
Start: Thu May 8 20:34:26 2014 HOST: starfire Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.1.10.1 0.0% 8 0.4 0.4 0.4 0.6 0.0 2.|-- 73.98.180.1 0.0% 8 8.7 8.5 7.2 10.0 0.7 3.|-- te-0-2-0-5-ur07.burien.wa.seattle.comcast.net 0.0% 8 9.7 9.5 7.6 11.1 0.9 4.|-- be-1-ur08.burien.wa.seattle.comcast.net 0.0% 8 9.5 9.5 8.2 10.6 0.5 5.|-- ae-1-0-ar03.seattle.wa.seattle.comcast.net 0.0% 8 9.7 9.6 8.5 10.9 0.7 6.|-- he-1-3-0-0-10-cr01.seattle.wa.ibone.comcast.net 0.0% 8 10.3 11.7 9.3 18.2 2.8 7.|-- he-0-13-0-0-cr01.sanjose.ca.ibone.comcast.net 0.0% 8 29.4 28.9 26.8 31.8 1.9 8.|-- he-0-11-0-0-pe03.11greatoaks.ca.ibone.comcast.net 0.0% 8 27.0 37.1 26.9 103.8 27.0 9.|-- as2906-c-0.sanjose.ibone.comcast.net 0.0% 8 69.0 68.4 61.2 79.2 5.3 10.|-- 198.45.56.12 0.0% 8 69.3 67.8 63.8 70.3 2.2
They also let me set my own PTR records, which is nice, although they offer no self-service way of doing this. I had to call them up. Oh.. and I must say there is a night & day difference between residential and commercial phone support.
Unfortunately, while Comcast does support IPv6 on the xfinity side of the house they do not yet support it for their commercial offering, so I'm still tunneling.
That being said, I had a bit of a headache when I tried to cancel the HSD portion of my xfinity residential service. At first when I canceled the service everything seemed fine. However, the CableCARD tied to my account (connected to the ATI DCT on my Windows Media Center PC) magically stopped working around the same time. I had to call them bad and they admitted they "made a mistake" when they were canceling my HSD account. That's fine. However, a few days later after I sold my old Motorola SB6141 to someone at work, I come to find out that the cable modem is still tied to my account. Again I had to call them and tell them to take it off my account. Surprisingly, my CableCARD and Motorola HD box didn't break this time.
The commute from West Seattle isn't as bad as everyone had warned. If I leave at around 07:00 I can be in the parking garage in around 18 minutes. From there it's a short 5-6 minute walk to the office and I can be at my desk by 07:30. I haven't quite figured out the best time to leave the office but it seems to take me anywhere from 25 to 30 minutes from the parking deck to my garage. Regardless, nothing as infuriating as I-485 back in Charlotte!
Work is fairly challenging and my first project is almost done. Amazon sure puts the wireless industry to shame with the sheer number of acronyms, nicknames, and proprietary lingo that is used for various things. I'm certainly having fun, so far! Yes, we are still hiring.
The first two warm days were last week and it got up to 29.4°C before I opened up the windows and cooled it down. I'm going to try the first summer without any air conditioning and then figure out if I need to get central AC or a portable unit for next year.
Anyway, the spring is fairly nice out here! It's nice and green, now:
The pollen is practically nonexistant compared to Charlotte. In fact, I haven't noticed any of it and, as a result, I've managed to skip my seasonal allergies completely, which is nice.
I think there's a bug in Mutt 1.5.23. Ever since I upgraded from 1.5.21 I've noticed doing a full-text message search is horribly slow. I think it may have to do with Debian bug 745532.
Let the flogging begin! Yep, I'm using IPv6 NAT+PAT on GNU/Linux.
Sure, for awhile it's been possible to do this in other operating systems (Junos, ScreenOS, IOS, FreeBSD, OpenBSD, etc.).. but not GNU/Linux.
The ip6tables MASQUERADE target was introduced in kernel 3.7 as ip6t_MASQUERADE.ko. Since I have a setup at home that involves using a Verizon Wireless LTE USB stick for backup Internet access (see this and this on the struggles I had to undertake to get it to work with GNU/Linux), this is a requirement for me if I want my IPv6 Internet traffic to use the connection as well. Verizon Wireless has supported native IPv6 on their LTE network since it launched, back in December of 2010.
I had to roll a vanilla kernel from kernel.org and use the deb-pkg target since the latest kernel in Debian is based on 3.2. I also had to grab iptables 1.4.17, build it, and install it from scratch, too. The three configuration options I enabled in the kernel were the following:
CONFIG_NF_NAT_IPV6=m CONFIG_IP6_NF_TARGET_MASQUERADE=m CONFIG_IP6_NF_TARGET_NPT=m
I'm not using NPTv6, yet, but I might try that out in the future. Once built and installed, I added the following familiar line to my iptables configuration script to enable MASQUERADE functionality for IPv6 on the upstream interface:
ip6tables -t nat -A POSTROUTING -s $VOXELV6 -o $EXT -j MASQUERADE
Since my internal network is numbered out of my IPv6 block from Voxel dot net (now Internap) that is usually tunneled to a server I have with them, $VOXELV6 is defined as 2001:48c8:1:100::/56. $EXT is wwan0, which is the USB stick. A very simplified diagram of this setup is shown below:
Normally, IPv6 traffic flows through the tunnel between starfire and dax. When the Road Runner connection fails or is otherwise manually depreferenced on starfire (this will also bring down the OpenVPN tunnel to dax), IBGP moves IPv4 and IPv6 connectivity over to evolution where formerly only IPv4 NAT took place.
Now, both IPv4 and IPv6 NAT+PAT is done on evolution. It works fairly well:
(evolution:17:44)% sudo ip6tables -t nat -S POSTROUTING -P POSTROUTING ACCEPT -A POSTROUTING -s 2001:48c8:1:100::/56 -o wwan0 -j MASQUERADE (destiny:17:30)% mtr --report --report-cycles=32 -w 2001:4860:4860::8888 HOST: destiny Loss% Snt Last Avg Best Wrst StDev 1.|-- et3.starfire.prolixium.net 0.0% 32 0.2 0.3 0.2 0.4 0.0 2.|-- et0.evolution.prolixium.net 0.0% 32 0.5 0.5 0.5 0.6 0.0 3.|-- 2600:1004:b01d:66b7:0:4a:d1a7:7f40 0.0% 32 34.7 44.7 32.1 68.8 8.0 4.|-- 2001:4888:0:1000:201:200:: 0.0% 32 49.0 45.3 31.4 100.3 12.5 5.|-- 2001:4888:20:2010:201:25:: 0.0% 32 83.2 47.3 32.9 83.2 12.5 6.|-- 2001:4888:20:2000:201:1:0:1 3.1% 32 56.9 47.1 36.1 62.7 6.6 7.|-- 2001:4888:20:1002:201:24:: 0.0% 32 52.5 43.9 32.1 61.8 8.2 8.|-- 2600:804:21f::1 0.0% 32 52.9 56.5 40.7 82.0 9.1 9.|-- Loopback0.GW1.MIA19.ALTER.NET 0.0% 32 62.1 75.5 54.9 137.5 18.4 10.|-- 2600:804:80f::a 0.0% 32 115.0 123.5 108.4 159.1 12.0 11.|-- 2001:4860::1:0:245c 0.0% 32 80.3 80.3 62.1 159.9 21.0 12.|-- 2001:4860::8:0:464f 0.0% 32 75.5 87.9 65.1 160.6 18.6 13.|-- 2001:4860::2:0:a7 0.0% 32 99.7 84.7 69.5 126.2 13.0 14.|-- ??? 100.0 32 0.0 0.0 0.0 0.0 0.0 15.|-- google-public-dns-a.google.com 3.1% 32 94.0 84.1 71.6 102.7 8.2
It's been stable for about an hour, now, so that's good enough for me. Since I'm not using a tunnel with this connection, I can also get a full 1500 byte MTU:
(destiny:18:23)% ping6 -c 4 -M do -s 1452 he.net. PING he.net.(he.net) 1452 data bytes 1460 bytes from he.net: icmp_seq=1 ttl=54 time=140 ms 1460 bytes from he.net: icmp_seq=2 ttl=54 time=167 ms 1460 bytes from he.net: icmp_seq=3 ttl=54 time=136 ms 1460 bytes from he.net: icmp_seq=4 ttl=54 time=134 ms --- he.net. ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 134.451/144.745/167.546/13.340 ms
So, what about the flogging? That's because lots of people will say this is the wrong way of doing things. They say I should call up Verizon Wireless and petition them to support DHCPv6-PD, in addition to the 3GPP-mandated /64 assigned to the cellular interface (see section 1.5.3 of RFC 3314). They also say NAT is evil.
Sure, I could do that, but it won't help me now. Even though NAT does suck in general, I say IPv6 NAT+PAT works fine in certain circumstances like this. It's just a tool, it can be used for good and as well as evil. To be honest, I don't find NAT or this use of it inherently evil.
If you want, read some of my other blog entries on the topic of IPv6 NAT+PAT.
If you keep up at all with Apple products and technology, you probably know what AirPlay is, even if you haven't used it. Yes, it's one of those proprietary protocols developed by Apple that allows iOS devices and iTunes to stream audio and video to an AppleTV device. Display mirroring is also available.
The problem with AirPlay is that it depends exclusively on multicast DNS (shortened as mDNS) with DNS service discovery (DNS-SD) to operate. mDNS is a zero configuration protocol that relies on link-local multicast messages on the local LAN to publish DNS records without the need for a centralized DNS server. DNS-SD is a protocol that compliments mDNS and provides service discovery, too. Apple's implementation of mDNS/DNS-SD is called Bonjour. When I say that AirPlay relies on mDNS/DNS-SD exclusively, I'm saying that there is no way of plugging in an IPv4 and IPv6 address of an AirPlay receiver - if mDNS doesn't work, you're screwed.
And where does mDNS not work? Between subnets (LANs, L2 domains, whatever you want to call it). mDNS uses an IPv4 multicast address of 224.0.0.251 and an IPv6 multicast of ff0X::fb, where X is the scope value (see draft-cheshire-dnsext-multicastdns-15 for details). The IPv4 implementation of mDNS has no hope of getting outside of the current L2 domain even with multicast routing, PIM, and IGMP enabled everywhere. Link-local means those packets cannot ever be routed. The IPv6 implementation of mDNS, on the other hand, might be able to work between L2 domains if the scope value is set to 5 (site). However, I haven't seen an implementation of mDNS on any Apple products that set the scope to anything but 2, which is link-local.
Back to AirPlay! Fortunately, there are some different ways of getting around the above limitations of AirPlay and mDNS. One is purchasing a Bonjour Gateway from a company called Aerohive Networks. This product apparently processes local mDNS packets and unicasts them to other Bonjour gateways that regenerate the packets. The result is that all mDNS-aware devices see devices in other L2 domains. This seems like a nice solution since the L3 infrastructure doesn't need to be changed. Aerohive indicates that these Bonjour gateways can also filter mDNS messages, which sounds somewhat useful.
If you've got a network with Linux boxes, another option is to just run the Avahi daemon on each Linux box and toggle reflection. Avahi is a FOSS implementation of mDNS and DNS-SD. It's really as simple as adding these two lines to /etc/avahi/avahi-daemon.conf:
[reflector] enable-reflector=yes
This tells the Avahi daemon to regenerate mDNS messages on all interfaces. Easy, right? Well, this requires your network to actually run Linux-based routers. My network at home does just that, and I had this up and running in about a minute! I used Aerodrom on Windows 7 as an AirPlay receiver, since I don't own an AppleTV.
Unfortunately, most networks don't run Linux-based routers, but this same solution should work with the help of OpenVPN. OpenVPN can be configured to establish an L2 tunnel between two Linux boxes using TAP interfaces, perfect for use with avahi-daemon. Putting a Linux box on each L2 domain and connecting them with OpenVPN TAP interfaces should be all that's necessary. The Avahi daemon will relay the mDNS messages between the Linux boxes thinking they share a L2 domain.
Obviously this use of avahi-daemon doesn't scale, but wouldn't it be interesting if router manufacturers added this type of functionality to the control plane of their devices? On the other hand, wouldn't it be interesting if Apple used ff05::fb for IPv6 mDNS and provided users the option to plug in an IP address or FQDN instead of requiring the use of mDNS?
I recently returned from a trip to the Galápagos Islands. It was a fantrastic and eye-opening week and a half in Ecuador, which I'll try to recount the highlights.
First, a quick technical note about the photos and videos...
I took my Canon 60D with the 18-135 mm zoom and 60 mm macro lenses, but I only ended up using the 18-135 mm one. There were some shots that would have looked fantastic with the macro, but I probably would have been scolded since we were supposed to stay at least eight feet away from all the wildlife. Anyway, I took a few photos and videos. The video clips (720p@60, H.264) amounted to 21 GiB and the photos (5184 x 3456 pixels, JPEG) to 9.7 GiB with a grand total of roughly 30.7 GiB. I was using a 16 GiB SD card, so I got in the habit of swapping it out every day. I took most of the shots in manual mode with the aperture wide open, only varying the shutter speed, focal length, and ISO settings. Automatic mode just wasn't producing very good shots, for some reason. I used UV and circular polarizer filters for some of the days. Also, I bought a mini-tripod but never really used it.
If you don't care to read the highlights below, and want to jump straight to the photos, here you go:
The above is more or less in order, except for the Quito (some photos were taken during the second visit) and miscellaneous galleries. A very small percentage of the photos aren't mine, and they should be obvious (because they might be of me!). If they're not, just look at the EXIF data at the bottom of the image - pictures that aren't mine aren't shot with a Canon 60D (or Nexus One). Below is a timeline of the trip followed by some details on the wildlife and miscellaneous observations. I've interleaved some smaller and/or cropped variations of the above photos, too.
The itinerary we took was dictated by Celebrity Cruises, since this was in fact a river cruise (probably just to distinguish it from a Caribbean or Meditteranean-type trip). We flew to Quito, Ecuador via Houston, TX and arrived in the early morning on September 30th, staying at the JW Marriott Quito. We spent two days there; one by ourselves and one with the Celebrity tour group (90 people who accompanied us on the ship, too, and some tour guides). And, shocker.. I got a sunburn the first day since I'm a bit stupid and like to learn the hard way every year.
The tour group exposed us to some of the highlights of the area: government buildings, old churches, the local cuisine (love the blackberry juice!), and a trip that took us north of the city to a location that was supposedly at a latitude of 0°0'0" (it actully wasn't, since the original inhabitants didn't have GPS receivers at the time, but it was close enough). Here's a screenshot of the GPS receiver information on my phone:
Since Quito is located in the mountains, the temperature was fairly cool for being so close to the equator. When we were there it got up to around 25°C during the day but got down to 12°C during the evening and part of the morning.
From Quito we took a roughly two hour flight to the Galápagos Islands, specifically Baltra Island, since that's the only one with an air strip. The airline was called AeroGal, and appeared specific to trips between the Galápagos Islands and the South American mainland. Upon arriving in a tiny airport, we took a bus to the bay and traveled to our ship, the Celebrity Xpedition, via Zodiac (a name-brand dinghy), since it wasn't anchored in the bay. In fact, all of our excursions were via Zodiac, which made things interesting when the sea was choppy.
The Celebrity Xpedition is a small boat built in 2001. It's registered in Guayaquil and carries a maximum of 100 passengers and 65 crew. As a result it moves quite a bit more than other typical larger cruise ships. I saw quite a few passengers with the sea sickness patches behind their ears. Since there were three of us, we got a suite with a verandah, which was a nice touch.
The Xpedition took us around to eight of the islands, crossing the equator twice along the route:
The weather in the Galápagos was probably around 22 to 24°C most of the time and partly cloudy during the day. It was sunny sometimes, but certainly not the majority of the time.
Our first excursion was on Sunday, which took us around and onto North Seymour Island via Zodiac. The first thing I noticed about the island is that it was very dry and desolate with lots of cacti and some little green bushes strewn about. This description pretty much sums up all of the Galápagos Islands (except some of the highlands) at this time of year. The rainy season between December and February is when it gets very green.. and overrun with bugs and inclement weather.
We saw sea lions, blue-footed boobies, frigatebirds, yellow wurblers, and marine iguanas. The majority of the rocks we saw the wildlife sitting on are volcanic in origin, which were very dark and sharp.
For the first excursion, I thought we saw quite a bit of wildlife, but it was nothing compared to the next several days. We were instructed to remain at least eight feet away from the wildlife, and to not touch or otherwise disturb them (no flash photography, no yelling at them, feeding, etc.). Surprisingly, most of the wildlife wasn't scared of humans, at all. I walked right past a blue-footed boobie next to its young and it didn't give me the time of day.
On Monday we visited San Cristóbal Island in the morning, which has a small population. After visiting a small museum with the history of the Galápagos (violent and unfortunate, I might say) we shopped a little bit and then headed back to the ship. In the afternoon we visited Española Island, where we were greeted by tons of iguanas and barking sea lions. This was the first island that presented us with a large amount and variety of wildlife.
The marine iguanas that we saw looked pretty menacing, but really are no danger to humans or really anything else on the islands. They're slow-moving, eat algae from the shore, and mostly just sit out in the sun during the day:
The sea lions were loud and active, except when they weren't. Apparently it takes some effort to move on land, so we would routinely see them hopping along at a quick pace and then fall flat on their face and seem to take a nap for a minute or two.
Española Island also presented us with lots of lava lizards, two variants of boobies (Nazca and Blue-footed), and some interesting Galápagos crabs.
On Tuesday we had our first snorkeling experience in the Galápagos. We took the advanced deep sea snorkeling around Champion Island, and used wetsuits since the water was 20°C. It was still cold even with the wetsuit. We saw lots of fish and a sea turtle, but nothing really all that interesting, except for the sea lion swimming around with some of us during the tail end. It probably would have been better if the sun was out to provide more illumination of the reef.
On Tuesday afternoon we visited Floreana Island where we saw some Galápagos Penguins on the rocks near the shore. While in the Zodiac we also got a chance to see some sea turtles poking their heads out of the water to breathe. Getting a good shot was a little difficult.
We took a hike up to the Baroness Lookout (our tour guide gave us the abridged story about this), which gave us a few photo opportunities:
The next day (Wednesday) we went to Bachas beach on Santa Cruz Island and did a short walk and snorkeling. We spotted our first flamingo on the walk. The snorkeling wasn't all that good due to cloudy water (and the sun wasn't out once again).
In the afternoon we went to Bartolomé Island and hiked up 114 meters where we saw some interesting vegetation, lizards, cacti, and a nice view of the island:
In hindsight, this was the day I should have used the circular polarizer filter. We also saw some penguins close to the shore before snorkeling again:
On Thursday we landed in Urbina Bay at Isabela Island and took a 2.0 mile hike across part of the island, which included some rocky turtain and dense vegetation. I was honestly surprised that all of the people in our tour group managed it without issue, since there was quite a bit of balancing involved. The landing part was interesting because we saw a fierce shark fight (for food) right near the beach. We ended up seeing some different wildlife, including two giant tortoises and a couple land iguanas.
We saw a Galápagos Hawk sitting on one of the national park stop signs:
On Thursday afternoon we took an excursion to Fernandina Island where we saw the most iguanas on the trip, so far:
I also snagged a short clip of some of them fighting (not mating: listen to the tour guide):
We also spotted a couple oystercatchers, which have a distinctive head and beak:
Friday brought us to Santiago Island where we saw some fur seals. I kept forgetting the subtle differences between seals and sea lions and eventually just learned to identify them by their colors: seals are black and sea lions are gold. The seals were the first species of wildlife we encountered in the Galápagos that seemed genuinely scared of humans.
We managed to spot a few orcas a mile or two from the island, and did some whale watching for a little bit. I took a few photos, but wasn't able see much detail. The best shot I got that showed the distinguishing white area near the eye is this one:
Snorkeling at Santiago Island was great. I was literally inches away from some sea lions swimming by and we saw one constantly diving down into a crevice looking for food. I spotted a jellyfish, sea turtle, and stingray (I think it was a stingray, it was under a bunch of sand), too. It's too bad I don't own an underwater camera.
In the afternoon we went on a longish hike to Dragon Hill on Santa Cruz (yep, we returned!). The terrain looked a bit like Mars:
Our last day brought us to Puerto Ayora on Santa Cruz. It's one of the heavily populated ports with an urban area and lots of farmland. We took a trip to the Charles Darwin Research Station where we saw some giant tortoises in captivity. One of them was Lonesome George, a 90 year-old tortoise who can't seem to find a compatible mate. He's the last one of his subspecies (categoried as EW: extinct in the wild). They apparently breed giant tortoises at the CDRS, too:
In the afternoon we traveled to the highlands (see map here) and visited a lava tube. We also saw lots of the giant tortoises in their natural habitat:
The highlands were overcast, humid, and very green. Apparently it mists there all the time, so all sorts of plants grow. It was in stark contrast to the rest of the Galápagos islands we'd visted earlier in the week.
The next day we flew back to Quito via AeroGal and departed for home the next day.
Here's a list of everything we saw on or from land:
And a list of things we saw while snorkeling (incomplete, since it was hard to identify most of the fish):
The two animals that were the most visible during the tours are the sea lions and marine iguanas. The sea lions were fun to watch, since they would play with each other or just walk right in front of us, barking. We saw quite a few young sea lions, too. Their vocal cords apparently aren't very developed so their bark sounds a bit different (and cute). Here's a video:
The marine iguanas were everywhere. Sometimes it would be hard to walk since they were scattered all over the trail. For food, they swim into the ocean and eat algae, but have to expunge the sea water from their system when they get back on land. As a result they were constantly doing what one might identify as sneezing. But, instead of a sneeze it was really just the iguana blowing out the salt water from their system. I almost got sprayed by one as it was doing this, too! Also, they smell really bad, especially when there are 20 or 30 of them piled on top of each other.
The giant tortoises are big and slow moving. Shocker, really. They can grow up to 300 kg and have no ears, so they can't hear a thing. They can detect vibrations in the ground, though, so they can tell someone is approaching. When we were walking too near to some of them, they would omit a hiss that sounded like Darth Vader, and pull their head into their shell.
Lots of the birds that we saw on land we also saw from the ship.. even when we were traveling between islands! The Blue-footed Boobies and Frigates apparently travel far out to sea to hunt for fish. We watched several of them nose-diving in the water right near the ship. I got a lucky shot, here:
There were quite a few symbiotic and mutualistic relationships we witnessed among the wildlife. The lava lizards crawl on the sea lions and eat the flies (that apparently get really annoying for the sea lions). Some of the finches pick off ectoparasites from the tortoises, too. There were a few others I don't recall, unfortunately.
About half of the 90 passengers on the cruise were from the United States, I think. The others were either from Canada, England, Hong Kong, or elsewhere. I think only two or three of the passengers were younger than me.
Since my Nexus One works throughout most of the world, I picked up an international data plan for $50 from AT&T that gave me 125 MiB per month. So, without fear of overage charges, data on my phone worked in Quito, the Galápagos Islands, and on the ship. In Quito I had a choice between two Ecudaorian GSM providers: PORTAGSM and MOVISTAR, both of which seemed to use 850/1900 for UMTS and provided HSPA for data. On the Galápagos Islands I picked up both of the same Ecuadorian cellular providers but with wildly high (but usable) latency. Apparently in 2002 the Galápagos Islands obtained a satellite connection back to mainland Ecuador, which is used for the cellular backhaul, too. On the ship, there was a similar cellular site (only supported GPRS) backended by a satellite, but the performance was horrible. And when I mean horrible, it was completely unusable at times:
Request timeout for icmp_seq 311 Request timeout for icmp_seq 312 64 bytes from 69.9.189.182: icmp_seq=163 ttl=46 time=150991.762 ms 64 bytes from 69.9.189.182: icmp_seq=164 ttl=46 time=150401.031 ms
On Wednesday we took a tour of the bridge of the Celebrity Xpedition. It was a fairly modern-looking bridge with no wheel and most components were computer-controlled. I spotted a networking rack that housed a few Linksys-branded devices and a satellite router. Expensive shipboard Wi-Fi was provided by a Cisco WLC (yay 1.1.1.1!) that was apparently centrally-located on the mainland. It was better than the cellular connection, but not by much:
HOST: orion Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.172.1 0.0% 32 1.8 2.3 1.1 9.1 2.1 2.|-- 192.168.15.1 3.1% 32 2.5 2.9 1.7 12.7 2.0 3.|-- 10.224.7.49 3.1% 32 7.2 5.0 3.4 11.7 1.8 4.|-- 10.102.33.53 3.1% 32 671.7 635.1 594.5 693.9 27.3 5.|-- 10.102.33.1 3.1% 32 710.9 638.2 592.1 710.9 27.3 6.|-- 10.102.1.5 3.1% 32 648.1 628.4 589.0 688.0 26.4 7.|-- mci.gwa.vizada-net.net 3.1% 32 681.0 640.5 595.9 743.5 34.5 8.|-- serial3-3.gw4.bos4.alter. 43.8% 32 609.4 636.4 601.9 766.7 37.4 9.|-- 0.ge-3-3-3.xl3.bos4.alter 43.8% 32 646.4 642.8 597.9 714.1 31.3 10.|-- 0.xe-6-1-2.xt1.nyc4.alter 43.8% 32 664.7 650.8 610.3 709.3 29.4 11.|-- gigabitethernet6-0-0.gw1. 45.2% 31 681.1 654.2 602.3 687.6 23.8 12.|-- teliasonera-gw.customer.a 45.2% 31 718.1 654.3 598.6 718.1 37.7 13.|-- nyk-b6-link.telia.net 45.2% 31 656.2 650.5 620.2 709.5 22.5 14.|-- 0.te1-4.tsr1.lga5.us.voxe 6.5% 31 746.9 647.7 608.3 746.9 30.1 15.|-- 0.ae57.csr2.lga6.us.voxel 6.5% 31 684.3 659.7 605.0 817.1 47.0 16.|-- dax.prolixium.com 25.8% 31 646.9 649.7 599.6 716.5 33.9
There was some crazy ICMP error throttling that caused the erroneous packet-loss. Anyway, our stateroom suite status gave us three hours of free use for the week.
Lots of the Galápagos species seemed to be just slightly different than those found in the rest of the world. To distinguish them, it seems that "Galápagos" was added to the title. I kept wondering if we were going to see a Galápagos squirrel.
Some of the tour guides gave us pieces of history about the islands. Apparently the early settlers on the islands brought donkies, dogs, birds, hogs, etc. that disrupted the wildlife on the islands. Some of these animals died off since they couldn't handle the harsh climate and some of the others apparently were slaughtered by ecological societies in order to preserve the balance. One tour guide specifically said that one of the societies is currently investigating the use of painball-like guns to kill a certain species of black bird that is doing damage to the ecology on the island. Sometimes I get confused about what's natural and what isn't, but maybe that's just me.
On an unrelated note, the airport security in Quito (UIO) was very strange compared to airports in the United States. There are two security checkpoints passengers pass through on their way to the plane. The first one is at ticketing, which is similar to a pre-9/11 checkpoint at a United States airport. The second one is at the gate itself, and involves airport employees going through passengers' carry-ons. Afterwards while the passengers wait at the gate, a dog is sent loose and sniffs all of the passenger's carry-on bags. Another security oddity (a good one, I might add) is the checking of baggage claim tickets upon pickup. I don't think I've ever been at an airport in the United States that cares about baggage claim tickets. Ashame.
Not sure what else to say here, but it was an awesome almost two weeks away from the office. Although it's not the cheapest vacation, I'd definitely recommend it!
This is the second part of my LTE adventures blog series. Don't worry, this is the last part. Read part one here.
LG VL-600 (yes, again)
After playing with the Pantech UML290 until I was blue in the face, I decided that I wasn't going to get anywhere with IPv6. I needed to backtrack.
Rather than getting rid of the UML290 (and probably paying some restocking fee among other things), I managed to snag a used LG VL600 from eBay for essentially peanuts, and threw in my SIM card. Surprisingly, moving the SIM card actually worked. Shocker, since this is Verizon we're talking about. Just for the heck of it I checked my account, and it showed a picture of the VL600:
I suspect the presence of a different ESN or IMEI automatically updated the device on my account. Anyway, no hassle.
As expected, IPv6 worked again on OS X and Windows with the VZAM software. So, giving up on IPv6 for a little bit, I turned my focus back to integrating the VL600 into my home network.
I picked up an ALIX.2D13 board and case to be used exclusively for the LTE connection in my condo. After installing Debian (ok, not really installing, I cheated and dd'ed an existing install from one of my Soekris boxes onto the new CF card), I turned up routing and terminated a VPN on the LTE interface, providing a [fast] backup to my existing cable modem connection. With a few tweaks, I was able to seamlessly move Internet and VPN traffic between my cable modem and the LTE connections.
Since I'm using Quagga and run BGP on my network, swinging VPN traffic is as easy as just swapping out a route map with a more appropriate one. Moving IPv4 Internet traffic is more bumpy, since the source IP will change (double NAT, woot!), but is as simple as reloading the iptables script on my core router to policy route all traffic toward the ALIX box. I still routinely hit the spoofing bug, since iptables will "leak" sometimes and spill a packet with an untranslated source out the LTE interface. This is probably something I'll have to look into eventually, but for now I was happy.
I also put together a wrapper script to graph the signal strength from the VL600. Other than the breaks, which are caused by me taking the modem on adventures to Panera Bread and other places, it seems to remain fairly constant:
View the live graph here.
Fixing IPv6
Recently, I was getting annoyed with the lack of IPv6 on Linux with the VL600, and a bug cropped up in kernel 2.6.39 that nuked the VL600's functionality. I sent an e-mail to Andrew Zaborowski, the original author of the VL600 Linux driver, and asked what he thought of the two problems. Unfortunately, as his blog indicated, he was only in the United States on a trip, and wasn't able to continue development of the driver in Europe, where the VL600 serves only as a nice paperweight.
I managed to resolve the 2.6.39 problem fairly easily, as it was a one-line fix.
The lack of IPv6 support took some more thought, and lots of debugging, but I managed to figure it out. The key ended up being a problem with the ethertype of the Ethernet frames containing IPv6 packets. From Andrew's comments in the driver, I was well aware that the VL600 didn't follow the 3GPP specifications very well, but apparently this was just the tip of the iceberg.
I first changed the initial interface flags to enable multicast (IFF_MULTICAST), which can also be done at runtime:
ip link set dev wwan0 multicast on
After doing this, I immediately started seeing more packets in the tcpdump output:
22:31:50.840001 IP6 , wrong link-layer encapsulationbad-hlen 0 0x0000: 6000 0000 0030 3aff fe80 0000 0000 0000 `....0:......... 0x0010: 0000 0034 9471 d840 ff02 0000 0000 0000 ...4.q.@........ 0x0020: 0000 0000 0000 0001 8600 ed45 ff40 ffff ...........E.@.. 0x0030: 0000 0000 0000 0000 0304 4040 ffff ffff ..........@@.... 0x0040: ffff ffff 0000 0000 2600 1004 b008 f951 ........&......Q 0x0050: 0000 0000 0000 0000 ........
However, they were broken. The ethertype is 0x800 (IPv4) but the frame contains an IPv6 packet. The ethertype should obviously have been 0x86dd, but it wasn't. Wireshark was nice enough to ignore the ethertype, and provide a clean decode of the ICMPv6 router advertisement from Verizon:
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0xed45 [correct]
Cur hop limit: 255
Flags: 0x40
0... .... = Managed address configuration: Not set
.1.. .... = Other configuration: Set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 65535
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 2600:1004:b008:f951::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x40
0... .... = On-link flag(L): Not set
.1.. .... = Autonomous address-configuration flag(A): Set
..00 0000 = Reserved: 0
Valid Lifetime: 4294967295 (Infinity)
Preferred Lifetime: 4294967295 (Infinity)
Reserved
Prefix: 2600:1004:b008:f951:: (2600:1004:b008:f951::)
I was curious. How could this work? I ran a tcpdump on the VL600 when plugged into OS X, and it showed valid ethertypes for IPv6. So, I connected the VL600 to a VM I have running Windows Vista, installed the VZAM software, and captured the USB traffic from the host OS (Linux):
21:23:05.494245 BULK SUBMIT to 1:29:2
0x0000: 7800 0000 5d00 0000 0100 0000 0000 0000 x...]...........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 5000 0000 0800 6000 0000 0028 3a80 2600 P.....`....(:.&.
0x0030: 1004 b005 726c 6699 5dff fef7 c054 2001 ....rlf.]....T..
0x0040: 1998 2001 0301 0000 0000 0000 1002 8000 ................
0x0050: 8bfe 0001 0001 6162 6364 6566 6768 696a ......abcdefghij
0x0060: 6b6c 6d6e 6f70 7172 7374 7576 7761 6263 klmnopqrstuvwabc
0x0070: 6465 6667 6869 0000 defghi..
21:23:05.494345 BULK COMPLETE from 1:29:2
21:23:05.563225 BULK COMPLETE from 1:29:3
0x0000: 7800 0000 1b00 0000 0100 0000 0000 0000 x...............
0x0010: 0000 0000 5354 4448 0000 0000 0000 0000 ....STDH........
0x0020: 5000 0000 0800 6000 0000 0028 3a2f 2001 P.....`....(:/..
0x0030: 1998 2001 0301 0000 0000 0000 1002 2600 ..............&.
0x0040: 1004 b005 726c 6699 5dff fef7 c054 8100 ....rlf.]....T..
0x0050: 8afe 0001 0001 6162 6364 6566 6768 696a ......abcdefghij
0x0060: 6b6c 6d6e 6f70 7172 7374 7576 7761 6263 klmnopqrstuvwabc
0x0070: 6465 6667 6869 7333 defghis3
(BTW, the Linux usbmon module and libpcap 1.1.x make it easy as pie to capture USB traffic - I just used tcpdump -i usbmon1)
Anyway, the above output was the result of me running a PING to an IPv6 host on the Internet from the VM. Bytes 37 and 38 clearly show 0x800 as the ethertype. Looks invalid to me, but the OS itself sees the right ethertypes. I figured the driver must be peeking in the L3 header and changing frames containing IPv6 packets to have an ethertype of 0x86dd. Why the heck is LG doing this? It seems retarded, but after some trial & error, I got lg-vl600.c to perform the necessary conversions, as well, and it only took a few lines of code.
Things now seem to work properly, although I can't seem to get autoconfiguration to work on the wwan0 interface, but I can just statically assign the host ID for now:
(evolution:21:06)% sudo rdisc6 wwan0 Soliciting ff02::2 (ff02::2) on wwan0... Hop limit : 255 ( 0xff) Stateful address conf. : No Stateful other conf. : Yes Router preference : medium Router lifetime : 65535 (0x0000ffff) seconds Reachable time : unspecified (0x00000000) Retransmit time : unspecified (0x00000000) Prefix : 2600:1004:b005:6a25::/64 Valid time : infinite (0xffffffff) Pref. time : infinite (0xffffffff) from fe80::2f:82cc:ed40 (evolution:21:07)% sudo ip -6 addr add 2600:1004:b005:6a25::1000/64 dev wwan0 (evolution:21:07)% sudo ip -6 route add default dev wwan0 (evolution:21:08)% ping6 -c4 ipv6.google.com. PING ipv6.google.com.(qy-in-x6a.1e100.net) 56 data bytes 64 bytes from qy-in-x6a.1e100.net: icmp_seq=1 ttl=50 time=88.1 ms 64 bytes from qy-in-x6a.1e100.net: icmp_seq=2 ttl=50 time=88.5 ms 64 bytes from qy-in-x6a.1e100.net: icmp_seq=3 ttl=50 time=83.8 ms 64 bytes from qy-in-x6a.1e100.net: icmp_seq=4 ttl=50 time=83.4 ms --- ipv6.google.com. ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 83.480/86.024/88.579/2.375 ms
So, success! I'll probably try to fix the autoconfiguration problem a little later, but I have a feeling it's something Linux sysctl-related rather than driver or network-related.
You can grab the patch here, for now. I'll be opening up another kernel bugzilla ticket to get this into mainline in the next day or so, too.
Well, since the weather was crappy in Charlotte this weekend, I decided to fix a patch I had written for MTR awhile back. Based on RFC 4950, it decodes the ICMP extensions for MPLS and prints them in the curses and report interfaces of MTR. Here's an example:
(dax:18:12)% ./mtr --report --report-cycles=4 ns2.google.com.
HOST: dax.prolixium.com Loss% Snt Last Avg Best Wrst StDev
1.|-- voxel.prolixium.net 0.0% 4 0.4 2.3 0.4 4.2 2.1
2.|-- 0.ae2.tsr1.lga5.us.voxel. 0.0% 4 0.3 1.5 0.3 5.1 2.4
3.|-- 0.ae59.tsr1.lga3.us.voxel 0.0% 4 0.4 0.4 0.4 0.4 0.0
4.|-- google.tienyc.telxgroup.n 0.0% 4 0.4 0.4 0.4 0.4 0.0
5.|-- 72.14.239.46 0.0% 4 0.6 4.5 0.6 16.0 7.7
6.|-- 209.85.249.11 0.0% 4 20.9 10.6 6.8 20.9 6.9
| +-- [MPLS: Lbl 729852 Exp 4 S 1 TTL 1]
7.|-- 209.85.241.222 0.0% 4 17.9 17.9 17.7 18.2 0.2
| +-- [MPLS: Lbl 602259 Exp 4 S 1 TTL 1]
8.|-- 209.85.241.207 0.0% 4 17.6 17.7 17.6 17.8 0.1
9.|-- 216.239.47.250 0.0% 4 25.5 22.8 17.6 27.3 4.4
| `|-- 216.239.47.242
10.|-- ns2.google.com 0.0% 4 17.8 17.9 17.8 18.0 0.1
And here's one on my internal network showing an MPLS L3VPN with two labels in the stack (the patch will decode up to eight, if anything supports it - Juniper routers process a max of five and then give up):
(dax:18:12)% ./mtr --report --report-cycles=4 -4 -n janeway
HOST: dax.prolixium.com Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.3.254.17 0.0% 4 34.4 33.9 30.6 36.2 2.4
2.|-- 10.3.7.249 0.0% 4 32.5 32.1 31.1 33.6 1.2
3.|-- 10.3.8.46 0.0% 4 31.7 31.8 31.5 32.0 0.2
4.|-- 10.3.8.54 0.0% 4 32.4 33.2 31.8 35.4 1.6
5.|-- 10.3.8.102 0.0% 4 33.2 34.0 31.7 36.1 1.9
6.|-- 10.3.8.77 0.0% 4 32.9 37.9 32.9 47.8 6.7
7.|-- 10.3.8.62 0.0% 4 33.1 34.4 33.1 35.3 0.9
| +-- [MPLS: Lbl 100512 Exp 0 S 0 TTL 1]
| +-- [MPLS: Lbl 16 Exp 0 S 1 TTL 1]
8.|-- 10.3.8.70 0.0% 4 38.3 35.6 33.4 38.3 2.0
| +-- [MPLS: Lbl 100560 Exp 0 S 0 TTL 1]
| +-- [MPLS: Lbl 16 Exp 0 S 1 TTL 2]
9.|-- 10.3.8.98 0.0% 4 47.6 42.5 39.5 47.6 3.6
I couldn't test the IPv6 support, so I left it out. I have yet to see a service provider on the Internet expose this information in a traceroute through their public infrastructure, so I have nothing to test it with. Due to Junos bugs, I couldn't test it in my lab, either! I also left out support for the GTK+ fronend because I don't find it too useful (does anybody?).
Grab the patch here. It's based on 0.80, which is currently the latest release.
Update: Use this patch, now. It includes IPv6 support. Thanks to Ryan Rawdon for pointing out that Cogent exposes MPLS label information on the IPv6 portion of their network, and helping me test it w/MTR.
Update: This patch is now included in the mainline MTR release starting with 0.82. You can grab it here!
Displaying page 1 of 3 of 19 results
     |
This HTML for this page was generated in 0.035 seconds. |