|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Warning: Soapbox.
It's almost the end of 2013. World IPv6 Launch was over 15 months ago. However, it appears we still have some organizations and protocols that just aren't getting with the program. Even more shocking, we still have some that are taking measures to indirectly inhibit IPv6 development.
I've made a short list.
MPLS. draft-george-mpls-ipv6-only-gap goes over many of the problems that need to be overcome to operate an MPLS network that is free of IPv4. The short story is that it may be awhile before this is possible. I can see many new ISPs deplying RFC 6598 (possibly erroneously) or RFC 1918 space on their backbones just to meet the IPv4 requirements for MPLS, in the short term, unfortunately.
Twitter. Twitter owns 2620:fe::/40 but has not announced it into BGP, yet. The least they could do is provide something like http://ipv6.twitter.com/ on a proxy server to show their interest in keeping up with technology.
Debian GNU/Linux bug #592539 for isc-dhcp-server. The isc-dhcp-server package has both IPv4 and IPv6 functionality but the init scripts to start the IPv6 version of the daemon don't exist. Yes, this means that you can't use DHCPv6 on Debian without writing your own init script or starting it manually. The bug was opened in August of 2010 and has yet to be resolved. Get with the program, folks!
Amazon EC2. This is a sore subject. The only AWS service that supports IPv6 is ELB, unfortunately. EC2 doesn't support it in any region or availability zone, at the moment. This is preventing lots of organizations from correctly deplying IPv6.
Google Compute Engine. GCE is a very poor competitor to Amazon EC2 for a variety of reasons. Google could have actually made one feature more attractive than EC2 by offering IPv6 on it. Unfortunately, they didn't. Fail.
Skype. We all know about this one, so let's just move on.
FreeBSD. A change in the defaults for the IPv6 address selection algorithm in FreeBSD 9.x leaves users with an OS that always prefers IPv4 connectivity when both A and AAAA RRs exist for a particular label. There are two knobs that can be put in /etc/rc.conf that change this behavior (ipv6_activate_all_interfaces and ip6addrctl_policy). That being said, versions of FreeBSD prior to 9.x defaulted to always preferring IPv6 over IPv4 when both RRs exist. It's very backward-thinking of the FreeBSD folks to introduce such a drastic change in the operating system's defaults after supporting IPv6 for so long. Apparently, FreeBSD 4.0 introduced support for IPv6 back in 2000.
Carrier Grade NAT. Unlike traditional NAT, CGN is often deployed on residential networks as a second layer of NAT (the customers' home routers being the first layer). This second layer of NAT breaks end-to-end connectivity even worse than a single layer of NAT, rendering a variety of peer-to-peer applications useless. Even though the problems with CGN are numerous, it helps ISPs push back the deployment of IPv6 for a little while longer, unfortunately.
Well, it's official. I suck at SLAX. I managed to find myself in a small situation at work where I needed to create an op script that's called by some conditions under event-options. Anyway, I always get stuck on the most simplest of things with SLAX and today was no different.
I couldn't figure out how to activate and deactivate portions of the Junos configuration, of all things. I'm talking about stuff like this:
{master:0}[edit]
prox@enterprise# show protocols
bgp {
group foobar {
peer-as 64512;
neighbor 10.0.0.2;
}
}
{master:0}[edit]
prox@enterprise# deactivate protocols bgp group foobar
{master:0}[edit]
prox@enterprise# show protocols
bgp {
inactive: group foobar {
peer-as 64512;
neighbor 10.0.0.2;
}
}
{master:0}[edit]
prox@enterprise# activate protocols bgp group foobar
{master:0}[edit]
prox@enterprise# show protocols
bgp {
group foobar {
peer-as 64512;
neighbor 10.0.0.2;
}
}
For some reason, this was not easily searchable on Google or Bing. I did manage to figure it out, though. To deactivate a piece of the configuration, do the following:
var $config-change = <configuration> {
<protocols> {
<bgp> {
<group inactive="inactive"> {
<name> foobar;
}
}
}
}
var $connection = jcs:open();
var $results := { call jcs:load-configuration( $connection, $configuration = $config-change ); }
if( $results//xnm:error ) {
for-each( $results//xnm:error ) {
<output> message;
}
}
var $close-results = jcs:close($connection);
The above was easily found by just doing something like "show configuration protocols bgp | display xml" on the CLI. However, what I wasn't able to find was how to activate the section, again:
var $config-change = <configuration> {
<protocols> {
<bgp> {
<group active="active"> {
<name> foobar;
}
}
}
}
var $connection = jcs:open();
var $results := { call jcs:load-configuration( $connection, $configuration = $config-change ); }
if( $results//xnm:error ) {
for-each( $results//xnm:error ) {
<output> message;
}
}
var $close-results = jcs:close($connection);
The active="active" piece was all that was needed.
I really would prefer to code op scripts in Perl or Python but I don't think I have much of an option when calling them from event-options. Oh well.
Yep, it's a mouthful. However, it works and is very useful.
Traditionally, Juniper's ScreenOS line of firewalls (NetScreen, SSG, and ISG) have not supported any sort of L2 VPNs. I'm referring specifically to connecting two LANs over an IPsec connection without the need for proxy ARP, static NAT, or any L3 hops. This has been a severe limitation, considering other vendors such as Cisco Systems have supported this type of feature on their ASA product line for quite awhile. It's also been supported in various forms on GNU/Linux systems, although the easiest implementation is with OpenVPN and the oh-so-awesome TUN/TAP driver.
That being said, Juniper's SRX product line supports a couple forms of L2 VPNs over IPSec.
A couple of weeks ago I worked with our Juniper Networks resident engineer to configure an SRX240 with one of the L2 VPN configurations. We got a pair of SRX240 firewalls connected back to back in the lab and configured two types of L2 VPNs over them: VPLS and a Martini-style pseudowire.
The initial configuration we started with was a bit complex. It was based on this example from Juniper, but we quickly changed it around and removed the need for the logical tunnel interfaces.
We tested the configuration with VPLS on two SRX240s cabled together and the BreakingPoint network testing appliance configured downstream. The "routing robot" test components were used in UDP mode and we achieved roughly 70 Mbps in IMIX with the packet size ranging between 64 and 1400 bytes to avoid fragmentation. The SPUs on the SRX240s were near 90-95% utilization. There was no packet-loss, though!
Unfortunately, since the BGP-based VPLS signaling requires BGP (duh), some odd combination of IPsec IKE negotiations and BGP caused the complete tunnel setup time to be longer than expected. It was on the order of minutes at one point. For our purposes, since we only need one port on either side, we decided to scrap VPLS and use an l2circuit instead.
The l2circuit does not require BGP for signaling, only OSPF. The BGP process was deleted and, as a result, the setup time appeared to be decreased slightly. We also bumped up the L3 MTU on the downstream physical interfaces to 1600 in order to adhere to our standard MTU for WAN interfaces, knowing full-well that this would result in fragmentation since the Internet-facing interface is set to 1500. We ended up with a configuration similar to the following:
ge-0/0/0 {
mtu 1614;
encapsulation ethernet-ccc;
unit 0 {
family ccc {
filter {
input CCC-packet-mode;
}
}
}
}
gr-0/0/0 {
unit 0 {
tunnel {
source 10.0.0.130;
destination 10.0.0.129;
}
family inet {
mtu 9000;
address 10.0.0.134/30;
}
family mpls {
mtu 9000;
filter {
input MPLS-packet-mode;
}
}
}
}
ge-0/0/15 {
unit 0 {
family inet {
address 192.0.2.10/30;
}
}
}
lo0 {
unit 0 {
family inet {
filter {
input protect-re;
}
address 10.0.0.2/32;
address 127.0.0.1/32;
}
}
}
st0 {
unit 0 {
family inet {
address 10.0.0.130/30;
}
}
}
static {
route 0.0.0.0/0 next-hop 192.0.2.9;
}
protocols {
mpls {
interface gr-0/0/0.0;
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface gr-0/0/0.0;
}
}
ldp {
interface gr-0/0/0.0;
interface lo0.0;
}
l2circuit {
neighbor 10.0.0.1 {
interface ge-0/0/0.0 {
virtual-circuit-id 100000;
encapsulation-type ethernet;
}
}
}
}
firewall {
family mpls {
filter MPLS-packet-mode {
term all-traffic {
then {
packet-mode;
accept;
}
}
}
}
family ccc {
filter CCC-packet-mode {
term 1 {
then {
packet-mode;
accept;
}
}
}
}
}
I didn't include the security section or the protect-re firewall filter in the above configuration. The security section consists of an IPsec VPN bound to st0.0 and associated zones and policies. st0.0, gr-0/0/0.0, and lo0.0 were all put in the same zone with permissive policies. Also, the "family ccc" under the firewall section is new to me. I wasn't aware that the ccc family existed, prior to working on this! It's apparently used here to instruct the SRX to process frames at L2 while also bypassing the flow module.
Suprisingly, after testing with large packets (up to the MTU of the interface), everything worked well, even with the fragmentation. The speed with IMIX was roughly the same. We then put this into production and everything has been working well for about a week, now! In fact, the final setup involves running MPLS over this whole setup, so we've got an additional layer of MPLS to add to the fun.
Here's what things ultimately look like:
prox@srx240> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131043 ESP:aes-256/sha1 cf2f7c23 1377/ unlim - root 500 192.0.2.127
>131043 ESP:aes-256/sha1 4cdcd526 1377/ unlim - root 500 192.0.2.127
prox@srx240> show ospf neighbor
Address Interface State ID Pri Dead
10.0.0.133 gr-0/0/0.0 Full 10.0.0.1 128 35
prox@srx240> show ldp session
Address State Connection Hold time
10.0.0.1 Operational Open 20
prox@srx240> show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 10.0.0.1
Interface Type St Time last up # Up trans
ge-0/0/0.0(vc 100000) rmt Up Nov 12 15:49:15 2012 1
Remote PE: 10.0.0.1, Negotiated control-word: Yes (Null)
Incoming label: 299776, Outgoing label: 299776
Negotiated PW status TLV: No
Local interface: ge-0/0/0.0, Status: Up, Encapsulation: ETHERNET
prox@srx240>
We're probably going to use this solution again in the future, since it happens to work better than other solutions (proxy ARP, etc.). However, it's unfortunate that we can't get more than roughly 70 Mbps over the connection. I suspect an SRX650 can do much better.
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?
It's been awhile since I've written anything here, so this will be a somewhat combined post.
For three days last week I attended an IPv6 training course at the Microsoft campus in Charlotte. The course was primarily for systems engineers from my department, but I sat in with the hopes that I might pick up a thing or two that will help keep our teams on the same page regarding IPv6 deployment.
The course went over IPv6 basics, transition technologies, deployment considerations, and touched a little bit on security. There were a few labs, which involved setting up various IPv6-related scenarios on Windows Server 2008 R2 (via Hyper-V on laptops, shocker there).
The content of the course was fairly decent, except for three major errors that I pointed out during the instruction:
(1) It was initially stated that clients send one DNS request to their local cache. The cache decides if it should return an A or AAAA record, based on some fictious variables. This was corrected (DNS clients send both A and AAAA queries to the cache, then themselves determine which should be used based on the presence of a GUA address and default route).
(2) When discussing 6to4 tunneling, it was stated that local relays should be used, with no mention of 192.88.99.1. Oddly, the course material stated that 6to4.ipv6.microsoft.com should be used as the relay, which has an A record of 192.88.99.1.
(3) It was stated that router-to-router links must use /64s. I cited that many major ISPs in the United States currently use /126s and /127s for such links, backing it up with some text from RFC 6164 (section 5, specifically).
The course also introduced some strong recommendations I vehemently disagreed with, one of which is the use of RAs and DHCPv6 in the enterprise data center. The instructor stated over and over again that it's hard to type in IPv6 addresses compared to IPv4 addresses for every single server, when using static assignments. So, of course, the solution is the use of RAs (with the M and O flags set), DHCPv6, and DDNS.
I think this is a horrible idea because of the added complexity and dependence on not one, or two, but three external services: router advertisements, DHCPv6 services, and dynamic DNS. The failure of any of these can possibly lead to servers becoming unreachable after a reboot or other network-related interruption. To get even more basic, I object to the use of router advertisements (RAs) in the enterprise data center, to begin with. Sure, in greenfield deployments this might be fine, but turning up RAs cause all IPv6-aware hosts to add a default route, if nothing else (assume the A flag is disabled). This is all some operating systems need to cause the network stacks to start resolving AAAA records and attempt to connect to IPv6 addresses before they're really ready. So, then, in order to selectively turn up IPv6 on some servers, all the other servers must be configured to not accept RAs - a monumental task for most enterprises where there are many platforms involved.
It was also mentioned that the DHCPv6 server on Windows Server 2008 R2 doesn't support static reservations for clients, so there's no way to ensure that clients receive the same address each time, other than the almost infinitely large address space in a /64. For this reason, it appears that it might not be possible to definitively predetermine the IPv6 address of a server before it hits the wire in the data center. To add some icing on the cake, it was suggested that firewall policies be based on the DNS, not addresses or prefixes!
Really, is manually typing an IPv6 and IPv4 address really that difficult to do during the server provisioning process? It only needs to be done once, and can easily be scripted. I asked the instructor for the reasoning behind this DHCPv6 recommendation, and got nothing more than "typing IPv6 addresses is hard." Flummoxed, I started up a thread on the IPv6 operations mailing list, bug got back less than definitive results.
Anyway, the course was fairly well-received by the systems engineers, and I think it'll help speed up deployment in our data centers (erm, it's been there for awhile, but no RAs!). However, I have a feeling I'll be fighting folks on the DHCPv6 issue in the future, if Microsoft sticks with their current recommendation. I got to pass by the Microsoft company store as part of the trip, and picked up some software on the cheap and a Microsoft shirt I'll be sure to wear to the office (to confuse everyone, obviously).
In unrelated news, there's a bill floating around in the House of Representatives that could possibly do some decent damage to the Internet in the United States: SOPA. The Stop Online Piracy Act (SOPA, H.R. 3261) is a bill introduced in the House with the goal to fight copyright infringement and counterfeitting on the Internet. Unfortunately, this bill is so broad that it threatens some open source projects and opens the door for federally-mandated DNS filtering (ie, censorship), something that should send shivers down your spine. Read more about it at the EFF. Feel free to call or write to your congressmen and state representatives about it. Really, this bill needs to be done away with.
Oh, I finally got a real SSL certificate for *.prolixium.com from GoDaddy, recently. If you hit the SSL version of my site, you shouldn't get any certificate errors. I also transferred prolixium.com and prolixium.net from Register.com to GoDaddy, too. It was fairly painless, but took a week for Register.com to get me the EPP codes and authorize the transfer. Other than Register.com's prices being highway robbery, I transferred because of this response to my question about DNSSEC support:
Discussion Thread
---------------------------------------------------------------
Response Via Email(David B.) - 11/03/2011 01:14 PM
Dear Mark.
Thank you for contacting Register.com.
We currently do not support the DNSSEC provision in the registry and at this time there is no indication that this will be added for our customers.
If you have any further questions, please reply to this email or contact a Web Services Consultant 24 hours a day, 7 days a week, at the numbers below.
Thank you for choosing Register.com.
Customer Support
Register.com, Inc.
Toll free within the U.S. and Canada: (877) 731-4441
Outside the U.S. and Canada: (902) 749-5918
Well, now that I'm with GoDaddy for almost all of my domains, and they support DNSSEC now, I should probably set it up, right? Yeah, I'll get to it later!
I'm really sick of UIs going through constant changes. Why do new versions of operating systems feel the need to alter the user interface, when the original one works fine?
Windows 8, ICS, Mac OS X, and even Ubuntu are all forcing users to learn a new user interface. Why? The old one works fine! Sure, Windows 7 and Android 2.3 (and 3.x) may have some bugs and quirks.. but do they need a different UI? I don't think so. iOS, strangely enough, has stayed mostly the same over the years. Go Apple! Alright, I said something nice about Apple, but I'll bash them later (read on).
This isn't limited to operating systems, either. Microsoft Office 2007 radically changed the user interface for almost all of their office applications (Visio didn't see the change until 2010). As a long time Microsoft Office user (Outlook, Visio, and Word), the change cost me some time to get used to. Annoying!
Again, why?
Steve, a coworker and friend of mine, has a good answer:
So people see a "difference". "Oh, it's upgraded, it looks different"
I think he hit the nail on the head. Most consumers don't care about kernel scheduler optimizations, filesystem tweaks, API fixes, or support for the latest and greatest protocols. If the UI looks the same, they will whine that there isn't much of an upgrade. Heck, if the UI changes, most software companies can claim that they've got a new operating system, even though most of the APIs, kernel code, etc. hasn't been touched.
Alright, let's ask why.. again.
Well, I think a part of this is due to Apple. Over the last decade, people have gone from knowing a little bit about the inner workings of their computers and operating systems to not caring one bit. I hear so often "I use Apple because it just works" and "I don't care how it works." Sure, that's fine, but now because people don't know or care about such things, they don't put any thought to the changes that happen at this level. So, moving from 2.4 to 2.6 of the Linux kernel isn't seen at all by the user, if all they are basing the upgrade on is the user interface. If Apple swapped out the *BSD core of OS X and replaced it with the Linux kernel but kept the UI the same.. would most consumers care? Probably not.
Let's think about this from another perspective. If Juniper Networks decided to throw out the CLI for its flagship Junos network operating system (say, for version 12.0) and come up with something completely different, network service providers (NSPs) and enterprises would have a cow! There'd be an "Occupy Juniper" movement almost instantly. Sure, it might work out over the next year, but then if they did the same thing in 14.0, they'd probably start losing large customers.
Sure, it's comparing apples and oranges, but it's interesting to think about.
For now, I guess we're left with changing UIs every year or two for consumer electronics. Maybe it'll settle down in the future, but I don't see that happening any time soon.
What do you think? Am I off my rocker? Yes, probably..
It started as another impulse buy of mine. Shocker.
While browsing eBay I spotted a new Google Cr-48 Chromebook. I snagged it for a decent price and had it a day or so later (the seller lives in Charleston, SC). Actually, I got it right before I left for New Jersey to participate in my college roommate's wedding.
The Google Cr-48 is a prototype piece of hardware running Chrome OS, a specialized distribution of GNU/Linux that runs only one application: Google Chrome. It was shipped out to 60,000 beta testers (at no cost) starting in December of 2010 and ending in March of 2011.
No, I didn't get one. And, at the time, after trying a few of Hexxeh's builds Chromium OS in VMware, I was glad I didn't - the OS seemed like a pile of garbage. My opinion has changed slightly, so read on.
After the Cr-48s had run their course, two new Chromebooks surfaced in the summer of 2011, boasting almost idential specifications to the Cr-48 except for different processor models (Atom N570 vs. Atom N455 in the Cr-48).
The Cr-48 that I obtained is apparently one of two models that beta testers received. Mine is labeled "IEC MARIO FISH 2330" and apparnetly there's another one out there labeled "IEC MARIO PONY 6101" (see this page for more details). It seems that they're idential, for all intents and purposes.
The hardware itself is fairly small and light, but huge and bulky compared to the MacBook Air. It's got a 12.1" screen (1280 by 800 pixels), 2GiB SSD, 802.11abgn Wi-Fi, webcam (I haven't tried this), and SD card slot. There's a USB port, too, but I've heard only HID-related and mass storage devices work correctly. The battery is fairly large, but thin, and sometimes feels like it doesn't sit very securely when installed. I suspect this is the result of corners being cut in the manufacturing or design process, since the laptop was originally intended for testing and not meant to be sold.
The keyboard has no F-keys and the would-be caps-lock key is a "search" button that opens a new tab. An oversized Alt key takes the place of a Windows key. There's no trackpoint-like device, just a touchpad that supports multi-touch, which seems to be coming out of the case, slightly. Again, this is probably due to corners cut in the manufacturing process.
The case itself has a soft rubbery feel and unfortunately visibly shows fingerprints and other grease marks, which sucks for those of us who suffer from OCD. That being said, one of the great things about the Cr-48's case is that it's completely free of branding. In fact, nobody really knows (with certainty) who manufactured the Cr-48s for Google. Anyway, the case looks like it might be a black MacBook at first glance.. but the white Apple logo on the screen is notably absent. I've seen one or two double-takes by people passing me by while hanging out at Panera Bread, and one person struck up a conversation with me about it. I dislike excessive branding, so this makes the Cr-48 a little bit more fun.
The Cr-48 also has another little hidden gem: a Qualcomm EvDO (rev. A) modem that operates on Verizon Wireless's network. Upon activation, there's two years worth of free data (up to 100MiB per month) included with the Cr-48. Data over 100MiB is charged to a credit card.
Oh, also, the battery lasts around a solid eight (8) hours with Wi-Fi enabled. The Atom processor's clock frequency is throttled by usage with cpufreq's "ondemand" scheduler.
Chrome OS is a pretty lean Linux distribution. No boot messages, no windows, just a logon screen and the Google Chrome browser.
The first boot presents the user with a list of languages, connectivity options (I chose Wi-Fi initially), and sign-on options (Google accounts only). Chrome OS then updates itself and reboots. I'll talk about the Google Chrome browser experience later, but other than items on the logon screen (language, connectivity options), all configuration and operation is done through browser tabs. This results in configuration feeling a little bit laggy, for some reason.
The Wi-Fi configuration is interesting, since it allows networks to be defined and saved on a per-user basis. This means that I can define a network, save the PSK (or whatever) for it, and only have the configuration accessible when my user is logged into Chrome OS. This doesn't really help me, but I suppose it can can be appropriate for some situations. The one weird thing about the network configuration is that proxy server settings must be done on a per-connection basis. I always run my browsing through a proxy (accessed via a VPN or SSH tunnel), so this is a little odd.
In reality, Chrome OS doesn't completely force the user to use a web browser for everything, a limited command-line environment (crosh) can be invoked by pressing Ctrl+Alt+t. Switching between Chrome browser windows (add more by hitting Ctrl+n, duh) is done with Alt+Tab, just like Windows. In fact, the whole thing runs on X11 but has a customized window manager that forces all applications to run in full-screen. Anyway, crosh lets one perform some diagnostics (traceroute, PING, etc.) and invoke an SSH client. The SSH client is troublesome because the terminal that crosh is started in (urxvt) somehow doesn't support UTF-8 properly, possibly due to the font selection. It's also annoying when connectivity drops, as there's no way to kill the SSH session (enter-~-. does not work).
Surprisingly, things like Netflix are supported due to Trusted Computing and Chrome OS's link with the built-in TPM. Basically, this gives content providers an assurance that their media won't be copied, stolen, or otherwise "hijacked" from users. If the Chrome OS bootup process is altered, I suspect the TPM will raise and error and prevent DRM-ish things from working.
In fact, speaking of preventing DRM-ish things from working.. there's a hidden developer button in the battery compartment that enables the "shell" command in crosh. I flipped this switch and it wiped all information on the Cr-48 and disabled the TPM (boot verification). I now have to hit Ctrl+d to bypass the frowny-face screen, but now I have access to the shell from crosh, and mostly everything works the same way. I say mostly everything.. because Netflix and other applications and pages that rely on the TPM won't work. No big deal, for me.
I've put some information I got from the shell here. One thing I just noticed while looking at the mount(8) output is that the stateful partition on the SSD is encrypted. I guess this is to prevent someone stealing the laptop, pulling the SSD out of it, and mounting it on another machine.
One nice thing about the developer switch is that Chrome synchronization with Google can be completely disabled. I don't care to synchronize things with Google, I'm weird like that, but unfortunately under normal operation you can't actually disable this (you can disable all but one category to synchronize, which is stupid).
Another nice thing about the developer switch is I can fire up an SSH tunnel from the shell (ssh -L etc..) and get access to a proxy server of mine, so I don't have to surf the Internet at coffee shops in the clear. I noticed OpenVPN binaries are installed, too, but I haven't bothered to setup anything to use it.
I've used Google Chrome before obtaining the Cr-48, but never liked it enough to switch from Iceweasel (a non-branded Firefox). I'm getting used to it a bit more on the Cr-48, since I don't really have a choice of browsers, but some things still bug me a bit.
Instead of using some bookmark synchronization tool or service, I have a personal "start" page of mine that lists all my bookmarks and sorts them by use. It's backed by a MySQL database, and I set this as my home page on all of my systems. I rely on Firefox's (and previously, Epiphany's) type-ahead find feature so I don't have to move my hand to the mouse in order to select a link. If I want to load a link, I hit Ctrl+t, type a unique subset of the link (shdot - Slashdot, for example) and it's logged to MySQL and loaded in my browser. Nice and fast.
Unfortunately, Google Chrome doesn't support the two features that allow me to take advantage of this: loading the home page for each new tab and type-ahead find. What's even worse is that they won't even add the type-ahead find as an option (see here). I've found two extensions that emulate this behavior:
Unfortunately, the Type-ahead-find extension is a little laggy, but it's better than nothing.
It's possible to download and install applications in Google Chrome using the Chrome Web Store. However, compared to the App Store in iOS or Mac OS X, most of the applications aren't really downloaded or installed, links for them are just added to the New Tab Page. Some applications seem to be able to request offline storage, like the Amazon Cloud Reader that allows the reading of Kindle books.
Although probably just limited by the Cr-48's CPU, 720p (or higher) Flash Video on YouTube barely plays. HTML5-based video runs fine, though (can we kill Flash now, please?).
Although I had severe reservations about a browser-only laptop, the Cr-48 seems to have softened my opinion of Chrome OS quite a bit. The funny thing is I'd probably recommend a Chromebook for my grandmother over any Apple product, at this point.
For techie or hacker-types, it's still a bit rough around the edges, but does show promise.
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.
Displaying page 2 of 8 of 59 results
     |
This HTML for this page was generated in 0.020 seconds. |