|
| 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!
I was re-watching an episode of SG:A this evening, and happened to spot a somewhat familiar shell command written on the whiteboard next to where Bill Nye and Rodney McKay were having an argument:
It even says fork bomb above it! This is from Brain Storm (season 5 episode 16) where one of Rodney's scientist friends was trying to fix global warming by creating a massive heat sink from Rodney's stolen research (that ended up not working). Note that this is a shell version of a fork bomb. Wikipedia provides several other ways of doing it in other languages.
More TV shows need easter eggs like this one. It makes watching them over and over and over much more entertaining! (hellooo, Rick Berman.. Brannon Braga?)
Well, World IPv6 Day has come and gone. I won't bore you with statistics that you can easily search for (like this one).
Anyway, it was a great success, with two unfortunate exceptions.
For the first hour or two, Juniper Networks had an issue with their site being reachable, yet not loading completely for clients behind tunnels. It was identified to be a PMTUD issue, and was fixed shortly after.
For the first 17 hours, Level 3 Communications had a tiny issue with their public website. It simply threw HTTP 404 errors:
I'm not sure why it took them so long to fix. They were also one of the parties that was noticeably absent from the IPv6 providers chat where I hung out throughout the day. Either way, epic fail.
Pretty much everything else worked as planned. It was neat hitting almost every major site via IPv6. YouTube seemed to serve out video from the caches faster via IPv6 than via IPv4. I suspect this was due to Google not rate limiting IPv6 connections, which is nice.
And also, speaking of YouTube.. apparently they are among some of the folks who decided to keep some of their AAAAs around after June 8th. For example, I'm still seeing AAAAs for their streaming servers:
09:50:27.583022 IP 127.0.0.1.22516 > 127.0.0.1.53: 13777+ AAAA? v10.lscache7.c.youtube.com. (44) 09:50:27.590659 IP 127.0.0.1.53 > 127.0.0.1.22516: 13777 1/4/0 AAAA 2001:4860:4003:5::17 (151)
I'm certainly not complaining, video content still downloads quickly compared to IPv4!
One disappointment for World IPv6 Day is Netflix. They seem to have gone in the other direction. Although once providing web services and streaming over IPv6 (via Limelight Networks), they've almost completely abandoned IPv6 after moving their systems to Amazon EC2. Although EC2 is starting to support IPv6, I think they're a long way from actually making it available to all of their customers.
To keep a nice log of things, I threw together a tiny script that parses the participant list and runs the following for each hostname provided:
A snapshot of this taken on Jun 8th at 07:57:57 (EDT) is available here. The source is this web server:
One thing to note in the above snapshot is that if Level3 is taken, hop 3's PTR is erroneous. It's not Dallas1, it's probably NewYork1. Although, maybe they developed some quantum entanglement network interface to make the round-trip time between Dallas and New York lower than 1 ms. Yeah, probably not.
In other news, although my place of employment intentionally did not participate in World IPv6 Day with website dual-stacking, we ended up doing it five days later. Corporate policy forbids me to associate myself with the company name in "blogs and web forums," so I can't actually provide it. However, if you think really big MSO in the United States, you'll figure it out pretty quickly. Also, let's just say that there's a surprisingly large volume of 6to4 traffic. Not much Teredo traffic, but I think I have an idea about that. I also saw a few silly addresses:
Not sure what to think about those, other than.. epic fail! I'll let you figure out why.
One other thing I've noticed.. lots of hits from 2600:1010::/29 and 2600:1000::/28. Yep, these are IPv6 addresses from mobile devices on Verizon's LTE network. And to boot, they've all got an MSS of 1940. This means the L3 MTU is 2000. Anyone with one of those USB dongles care to confirm this?
There's talk about the next IPv6 event lasting for a week. I'm on board for that!
There's no doubt…
% for i in google facebook youtube yahoo bing cnn aol cisco; do host www.${i}.com.; done
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.91.105
www.l.google.com has address 74.125.91.106
www.l.google.com has address 74.125.91.147
www.l.google.com has address 74.125.91.99
www.l.google.com has address 74.125.91.103
www.l.google.com has address 74.125.91.104
www.l.google.com has IPv6 address 2001:4860:b009::69
www.facebook.com has address 66.220.149.11
www.facebook.com has IPv6 address 2620:0:1c08:4000:face:b00c:0:1
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 74.125.67.136
youtube-ui.l.google.com has address 74.125.67.190
youtube-ui.l.google.com has address 74.125.67.91
youtube-ui.l.google.com has address 74.125.67.93
youtube-ui.l.google.com has IPv6 address 2001:4860:8001::88
www.yahoo.com is an alias for fpfd.wa1.b.yahoo.com.
fpfd.wa1.b.yahoo.com has address 69.147.125.65
fpfd.wa1.b.yahoo.com has address 67.195.160.76
fpfd.wa1.b.yahoo.com has IPv6 address 2001:4998:f00b:1fe::3000
fpfd.wa1.b.yahoo.com has IPv6 address 2001:4998:f00b:1fe::3001
www.bing.com is an alias for ipv6.search.ms.com.edgesuite.net.
ipv6.search.ms.com.edgesuite.net is an alias for a1877.dscb.akamai.net.
a1877.dscb.akamai.net has address 98.27.88.88
a1877.dscb.akamai.net has address 98.27.88.89
a1877.dscb.akamai.net has address 98.27.88.15
a1877.dscb.akamai.net has IPv6 address 2600:1407:1::d89c:f213
a1877.dscb.akamai.net has IPv6 address 2600:1407:1::d89c:f20b
www.cnn.com is an alias for v4v6.cnn.com.
v4v6.cnn.com has address 157.166.255.19
v4v6.cnn.com has address 157.166.224.25
v4v6.cnn.com has address 157.166.224.26
v4v6.cnn.com has address 157.166.226.25
v4v6.cnn.com has address 157.166.226.26
v4v6.cnn.com has address 157.166.255.18
v4v6.cnn.com has IPv6 address 2620:100:e000:2000::1
v4v6.cnn.com has IPv6 address 2620:100:e000:8000::1
www.aol.com is an alias for www.aol.com.aol.akadns.net.
www.aol.com.aol.akadns.net is an alias for www-east.aol.com.aol.akadns.net.
www-east.aol.com.aol.akadns.net is an alias for v6v4-www-nva.evip.aol.com.
v6v4-www-nva.evip.aol.com has address 64.12.246.205
v6v4-www-nva.evip.aol.com has address 64.12.244.203
v6v4-www-nva.evip.aol.com has address 64.12.245.203
v6v4-www-nva.evip.aol.com has IPv6 address 2001:4b0:1668:2202:2::1
www.cisco.com is an alias for v6day.cisco.com.akadns.net.
v6day.cisco.com.akadns.net is an alias for geo-v6day.cisco.com.akadns.net.
geo-v6day.cisco.com.akadns.net is an alias for cisco-redir.v6day.akadns.net.
cisco-redir.v6day.akadns.net is an alias for cisco.v6day.akadns.net.
cisco.v6day.akadns.net has address 72.246.112.170
cisco.v6day.akadns.net has IPv6 address 2001:420:80:1:c:15c0:d06:f00d
It's begun!
Well, it's been a little bit since I've blogged anything. Sorry about that. Let's see if I can hit the high points of the last month or so.
World IPv6 Day is approaching. Yep, by approaching I mean it's next week! If you don't know anything about it, click on the link. If you're too lazy to do that, go have some sugar. Basically, World IPv6 Day is when lots of high-profile sites will become dual-stack as a widespread test flight of the protocol. It'll only last for 24 hours, and most of the sites will remove the AAAAs at the conclusion of the test flight. It's scheduled on Wednesday, June 8th from 00:00 UTC to 00:00 UTC on June 9th.
(just for the record, prolixium.com has had an AAAA record for about eight years, at this point)
When taking breaks from studying for the JNCIP-SEC exam, I've gone back to my service provider lab, and implemented some RSVP-TE and interprovider VPNs. Strangely enough, the Juniper Olive makes a great MPLS P router, if you keep Junos below 8.5. I used a Juniper SRX210, Dynamips'ed Cisco 7200 running 12.4(15)T5, and a bunch of virtual machines running Debian GNU/Linux. Here's what it looks like:
Essentially, zat's fxp4.0 can talk to martini's Untrust interface via an MPLS L2 VPN established between ori and asgard. The L3 MTU is a little low (1426), but it works. Also, I started playing with MikroTik's RouterOS, too. It seems like a fully-featured operating system (erm, lacks IS-IS, but is close enough) for low-end CPE or MPLS LERs.
In other news, I just passed the JNCIP-SEC, today. It was a bit harder than I had expected, but I still emerged victorious. For some reason Prometric made me turn all my pockets inside-out (yes, this included my back pockets) before starting the exam. I was wondering if there was going to be a pat down, too. Crazy. Now, I suppose I should register for the JNCIE-SEC, right? I may start studying for the JUCIP-SP instead, since that will serve to recertify my JNCIE-M that expires next year (actually, I think it converts the JNCIE-M to JNCIE-SP). We'll see.
I picked up Anjunabeats Worldwide 03 and Paul van Dyk's Vonyc Sessions 2010, recently. Both compliations are quite epic, and the following tracks are my favorites, so far:
On another topic, I was over a friend's house on Memorial Day, earlier this week. He's got one of the newer 240Hz Samsung LED TVs with that hideous motion interpolation feature (in the form of Auto Motion Plus). I sat through a few minutes of Star Trek Generations, which I've seen over a dozen times, before deciding to see if there was a way of disabling it in the settings. There is, and it looks much better when disabled. I don't get the appeal.. it just makes everything look like a behind-the-scenes version of the fiim. Most Engadget HD readers agree with me.
My once happy Windows Media Center setup (on isis) stopped working, the other day. Apparently one of those lovely Microsoft updates to Windows 7 started causing WMC to die after a minute or two of usage with the dreaded nvlddmkm stopped responding and has recovered message. I couldn't grab a screenshot fast enough, but it looks something like this:
My first stab at fixing the problem was to uninstall the latest batch of Windows updates, which for me were:
It worked until I upgraded the hard disk in the machine, then Windows did some driver fussing and I started receiving the nvlddmkm errors once again. My latest solution is to uninstall all Microsoft updates (excluding security updates, those are nice to keep) including service pack 1. We'll see how well that works out. I'm still using version 183 of the nVidia drivers, since they allow me to use the VGA (ie, non-digital) output for premium channels that are protected by DRM. Newer revisions of the driver require DVI or HDMI output, and an HDCP-compliant monitor, which my 24" Dell isn't. Anyway, upgrading the driver didn't help fixing the original problem, so I'm not missing much.
It's been pretty hot in Charlotte for the last week or two. I'm talking 95°F and hotter for days on end. It seems to be higher than normal for this time of the year.
I think that's about it. I'll try to keep this more updated from now on, but no guarantees!
I finally upgraded my Nexus One to CyanogenMod 7.0, which is based on Android 2.3.3 (from 6.0, which is based on Android 2.2), this weekend. I've got mixed feelings about the upgrade, for a couple of reasons.
First, I don't see that much of an improvement. There are no mind-blowing features that I've encountered. The speed of my phone feels about the same as it did with CyanogenMod 6.0. However, that being said, two things are faster: IMAP e-mail retrieval and Wi-Fi connectivity. The phone will connect to my WPA'ed and hidden SSID at home within 5-10 seconds whereas before it would usually take a couple of minutes. The same with IMAP e-mail. After refreshing my inbox it only takes a few seconds to synchronize and retrieve new messages, even on HSPA, vs. a minute or two with 6.0.
Secondly, some things are broken or don't exist anymore.
The CyanogenMod-specific feature that first started annoying me is the lack of numeric signal strength indicator on the status bar. I loved this feature, since the number of "bars" usually means nothing to me. I could easily look at the status bar and see if my signal was really good (-75 dBm) or really great (-67 dBm), while I'd have full bars under both conditions. This feature isn't included in CM 7.0. Why? Supposedly the themes engine had problems with it. See this for some more information.
I don't think this is a CM problem, but SMTP via IPv6 doesn't work anymore. Yes, you read that right. I haven't dug into it enough to determine who's at fault, but Android is sending an IPv6 literal for the EHLO argument without brackets or the IPv6: prefix, so my SMTP server (Exim) is throwing a hissy fit:
220 nox.prolixium.com ESMTP Exim 4.75 Sat, 16 Apr 2011 11:54:35 -0400 EHLO 2001:48c8:1:106:3ae7:d8ff:fe18:e670 501 Syntactically invalid EHLO argument(s)
I'll probably end up rolling a custom deb of Exim to fix this myself, since the Android fix will probably take awhile, and I don't feel like flashing my phone again. There are loads of Android and Exim postings surrounding this, so just Google for it to get more details.
Let's see, what else.. oh, the camera sound can't be changed anymore. I recall with CM 6.0 I could change it from the annoying "snap" sound to a less-obtrusive "beep beep" sound. With CM 7.0 I can still change it, but I have to change /system/media/audio/ui/camera_click.ogg after mounting /system as rw. Annoying, but at least the camera sound can still be muted (by silencing the whole device).
This is an Android 2.3 issue, but I don't like the behavior of the status bar, anymore. I have a full power control widget on one of my screens so I could do without the limited and unnecessary power controls that take up valuable space when the status bar is unrolled. Also, the finger dragging motion to unroll or roll up the status bar seems to have been modified, since I'm having a harder time with it compared to CM 6.0. Also, I don't like that it's black by default. Many applications that put icons in the notification area seem to assume a gray status bar, and have non-transparent gradations as a result. They look silly and have a white "hue" around them.
Overall, I'm happy to be running 7.0, but meh, I probably should have skipped this upgrade.
If you're from Charlotte, you know that the south loop of I-485 causes daily delays and traffic, due to its low lane count.
Well, it's even worse when it's closed.
My normal commute consists of exiting Ballantyne via Lancaster, a short trip on 51, and then I-485 for most of the rest of the trip. Today, knowing that I-485 is closed, I try to exit my development, and are greeted by a parking lot:
All of the exits out of Ballantyne are either blocked off or just a parking lot. So, I drove south, thinking I would be able to get on 160 to I-77 and head north. Along the way, I noted that Johnston Rd was backed-up pretty far:
Unfortunately, I had to drive much farther south than I had expected. The total distance was 50 miles and took a little less than an hour and a half:
Surprisingly, I heard stories of folks sitting in traffic for two and three hours, and having to turn around and go home! So, my commute wasn't too bad. Very scenic, 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 12 of 121 of 965 results
     |
This HTML for this page was generated in 0.006 seconds. |