|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
This is part one of two because, well, the story isn't over, yet! Stay tuned.
For reasons I can't reveal (no, it's not anything bad), I'm not allowed to get Time Warner Cable's DOCSIS 3.0 service in Charlotte, NC, where I live. Therefore, I'm limited to 15Mbps downstream and 1Mbps upstream (with a small amount of tokens for bursting) in my condo, which is really starting to aggrevate me. As a result, I ended up pursuing the LTE service from Verizon Wireless to augment my existing 15/1 Internet connection at home. My initial plan was to setup an on-demand failover to LTE for some or all connections and add an alternate path to my VPN setup, which is where most of my traffic goes, anyway.
Picking Hardware
Unfortunately, nothing's simple with me. I first needed to choose a mobile device, so here were my options:
Now, here were my requirements:
Seems simple, right? Well, no.
I found virtually no information on what devices support IPv6. I knew the Samsung SCH-LC11 didn't, because I played with one at work awhile back. That led me to assume the Novatel 4510L doesn't, either. Forget the hotspots!
As far as the USB modems, a friend who was using the Pantech UML290 earlier in 2011 had sent me some screenshots of the Verizon Access Manager on Windows 7 showing an IPv6 address and a few IPv6 traceroutes. A few searches seemed to indicate that the UML290 is well supported in Linux. That was good enough for me!
I went to the mall and attempted to pick up the UML290 with the 5GiB ($50/month) plan, but they were sold out of it! After given the guarantee that I could swap it out in the next 14 days without a hassle or being charged extra, I ended up walking away with the LG VL600 instead. Maybe it would work with Linux, I thought.
LG VL600
I first tried this thing on OS X with VZAM and was pleasantly surprised at the great speeds I got sitting in my condo: 27ms (to the first hop), 14Mbps down and 16Mbps up:
IPv6, too:
en2: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1428 ether 64:99:5d:fa:d8:fa inet6 fe80::6699:5dff:fefa:d8fa%en2 prefixlen 64 scopeid 0x7 inet6 2600:1004:b000:18ee:6699:5dff:fefa:d8fa prefixlen 64 autoconf inet 10.167.121.54 netmask 0xfffffffc broadcast 10.167.121.55 media: autoselect (1000baseT <full-duplex>) status: active
Strangely enough, it didn't show up in VZAM:
I was wondering about the LTE connection being delivered as an Ethernet interface at first (I'm used to a PPP interface with other mobile data cards and phones) but we'll get to that later. I did a few traceroutes with IPv4:
traceroute to dax.prolixium.com (69.9.189.182), 64 hops max, 52 byte packets 1 * 2 57.sub-69-83-51.myvzw.com (69.83.51.57) 29.500 ms 3 194.sub-69-83-51.myvzw.com (69.83.51.194) 29.618 ms 4 1.sub-69-83-32.myvzw.com (69.83.32.1) 37.532 ms 5 233.sub-69-83-32.myvzw.com (69.83.32.233) 30.433 ms 6 tengige0-0-0-0.gw4.atl5.alter.net (63.122.230.125) 36.933 ms 7 0.ge-1-1-0.xt1.atl5.alter.net (152.63.82.253) 37.727 ms 8 0.so-5-1-0.xt1.atl4.alter.net (152.63.0.85) 36.813 ms 9 tengige0-6-1-0.gw7.atl4.alter.net (152.63.80.133) 40.165 ms 10 teliasonera-gw.customer.alter.net (157.130.90.238) 40.353 ms 11 ash-bb1-link.telia.net (80.91.246.76) 56.173 ms 12 * 13 0.te1-1.tsr1.phl1.us.voxel.net (173.231.161.37) 59.688 ms 14 0.te6-2.tsr1.ewr1.us.voxel.net (173.231.161.33) 56.237 ms 15 * 16 0.ae57.csr2.lga6.us.voxel.net (208.122.44.210) 66.965 ms 17 dax.prolixium.com (69.9.189.182) 62.662 ms
Of course VZW/Cellco (AS6167) uses Verizon Business (AS701) for transit, and the latency is great, too. IPv6 traceroutes, well, they go nowhere:
traceroute6 to ietf.org (2001:1890:1112:1::1e) from 2600:1004:b005:21b6:6699:5dff:fef7:c054, 64 hops max, 12 byte packets 1 2600:1004:b005:21b6::8:ab7c:f840 30.794 ms 2 * 3 *
Apparently ICMPv6 is blocked at the edge, and all that's shown above is the USB modem. I did notice that IPv6 latency appeared to be a bit high to the couple of US-based addresses I tried, and this is because 701 needs more IPv6 peering. I was hitting quite a few things via AMS-IX, as can be seen in a reverse traceroute:
traceroute6 to 2600:1004:b000:18ee:6699:5dff:fefa:d8fa (2600:1004:b000:18ee:6699:5dff:fefa:d8fa) from 2001:48c8:1:2::2, 64 hops max, 12 byte packets 1 voxel.prolixium.net 4.694 ms 2 * 3 0.ae59.tsr1.lga3.us.voxel.net 0.587 ms 4 904.te1-2.tsr1.ams2.nl.voxel.net 73.399 ms 5 AMS-IX.v6.lambdanet.net 79.238 ms 6 FRA-1-pos413.v6.lambdanet.net 98.998 ms 7 6b1.fft4.alter.net 100.261 ms 8 gw6.dca6.alter.net 102.001 ms 9 2600:804:21f::2 121.133 ms 10 2600:804:21f::2 120.699 ms 11 2001:4888:20:1000:201:24:: 120.573 ms 12 2001:4888:20:1001:201:1:: 121.593 ms 13 * 14 *
You get the picture. The traceroute didn't finish because, well.. yep, apparently VZW is dropping all IPv6 noninitiated incoming traffic. Bummer, but not surprising. I wonder what type of firewalls they're using? It might be the Juniper SRX product line.
GNU/Linux
I first tried plugging the card into my Linux router running Debian with a 2.6.32 kernel. Things didn't work initially, and a few blogs I saw indicated the VL600 had horrible Linux support since most of the GSM modem commands don't work as expected. Soon after that, I found this thread and some kernel patches for 2.6.38 (thanks, Andrew!). After patching my kernel, I was able to get online after manually running the vl600-attach.py script. The VL600 gave me an Ethernet interface via the cdc_ether driver that starts working after some modem commands are sent to /dev/ttyACM0, the serial device on the modem. A standard DHCP client is used to grab an IP from the Ethernet interface. Verizon seems to hand out /30s or /29s, even though the interface is essentially nonbroadcast. Anything but a /30 seems wasteful, but whatever, it's NET-10.
Sounds good, right? Not exactly. IPv6 wasn't working. Router solicitations never triggered any router advertisements to be sent. Sending ICMPv6 echo request packets to ff02::2 (the all-routers multicast address) didn't solicit any replies. Shucks.
I attempted to put the Ethernet interface (eth5) into its own routing table, to isolate its default route from the main routing table. I had a heck of a time doing this with dhclient, even after creating a custom dhclient-script to do this automatically, and ended up using RedHat's pump and a slightly horrid /etc/network/interfaces file to accomplish it:
# LTE auto eth5 iface eth5 inet manual up /home/prox/src/balrog-kun-LG-VL600-utils-d4f6975/vl600-attach.py up pump -i eth5 -d --no-gateway --no-ntp --no-resolvconf up ip route add `pump -i eth5 -s|grep Gateways|sed 's/.*Gateways: //'` dev eth5 table lte up ip route add default via `pump -i eth5 -s|grep Gateways|sed 's/.*Gateways: //'` table lte up ip rule add from `pump -i eth5 -s|grep IP|sed 's/.*IP: //'` lookup lte down ip rule del from `pump -i eth5 -s|grep IP|sed 's/.*IP: //'` lookup lte down ip route del default via `pump -i eth5 -s|grep Gateways|sed 's/.*Gateways: //'` table lte down ip route del `pump -i eth5 -s|grep Gateways|sed 's/.*Gateways: //'` dev eth5 table lte down pump -i eth5 -k down ifconfig eth5 inet 0.0.0.0 down down /home/prox/src/balrog-kun-LG-VL600-utils-d4f6975/vl600-detach.py
I configured the iptables MARK functionality along with some IP rules (essentially policy-based routing on Linux) to send certain traffic out the alternate Internet connection, the LTE interface. This worked fine, however it appears that iptables leaks every once and awhile, or when the rules are reloaded. I can't quite figure out why this is the case (possibly ALG-related?) but it resulted in what could be interpreted as spoofed source addresses being forwarded out eth5. They're not really spoofed, they're just untranslated NET-10 source addresses from my network. Well, what does Verizon do with this? They immediately tear down the connection.
Yep, apparently if you spoof just one packet Verizon will drop the connection like it's hot. I tried this on OS X with VZAM, and it does the same thing. Give me a break. I guess they're doing this to prevent floods from chewing up network traffic and causing customers' bills to spiral out of control. Regardless, it's annoying. I even thought this was a bug and upgraded the VL600 to the latest firmware on my Windows 7 workstation, but that didn't help.
I then thought about terminating some VPNs, but couldn't easily figure out a good way of binding OpenVPN to a specific source interface instead of source IP. The IP rules I had setup allowed arbitrary applications to use the alternate routing table if the source IP was specified. Unfortunately the IP on Verizon's network kept changing, so there didn't seem like a clean way of doing this except with static routes, which would conflict with the main VPN connectivity I had out my cable modem interface.
Pantech UML290
Slightly bummed with the hyperactive spoof protection, lack of IPv6 on Linux, and non-standard GSM modem command responses with the VL600, I decided to take advantage of the free 14-day replacement my Verizon sales agent had offered me. I swapped out the VL600 with a Pantech UML290, after my sales agent found one at a somewhat nearby VZW store.
Well, I think this was one of the stupidist things I've done in awhile.
I started out testing it on OS X, and.. what? IPv6 didn't work there, anymore! I tried it on Windows 7 - no love either! According to tcpdump captures, the router solicitations on both OS X and Windows 7 never triggered the sending of any router advertisements. D'oh! I happened to find a blog entry that seems to indicate that the UML290 does not support IPv6. I'm not sure if this is official, or this guy just ran into the same problem I did. Either way, epic fail. I tried whining about it here, but didn't really get anywhere.
I went ahead and did some testing on Linux, too. Well, the good thing is that GSM modem commands are accepted and return adequate responses. The UML290 didn't attach to the cdc_ether module, but I created a small wvdial.conf to generate a ppp0 interface:
[Dialer Defaults] Stupid Mode = 1 Auto DNS = no Modem = /dev/ttyACM0 Phone = *99***3# Username = 2125551111@vzw4g.com Password = vzw
No IPv6 on Linux either, but that's not a shocker at this point. The spoof protection was still present, too. In fact, a single spoofed packet will terminate the PPP connection and cause WvDial to reconnect (and of course get a different IP). Yes, annoying.
I did some more searching around, and figured out that the APN 1 might provide IPv6 over PPP:
AT+CGDCONT? +CGDCONT: 1,"IPV6","vzwims","0:0:0:0:0:0:0:0",0,0 +CGDCONT: 3,"IPV4V6","vzwinternet","0.0.0.0",0,0 +CGDCONT: 4,"IPV4V6","vzwapp","0.0.0.0",0,0 OK
Unfortunately, AT+CGDCONT=1 always produced an error when setting it as an Init2 string in wvdial.conf.
Summary
Well, I've got wicked-fast LTE service but without the IPv6 and decent Linux router support. Am I satisfied? No way. Wait for part two, where I.. maybe get everything working the way I want (I hope).
Update: There's now a part two. Read it if you want to hear the ending!
New comments are currently disabled for this entry.
     |
This HTML for this page was generated in 0.001 seconds. |