Surfing the Luminiferous Ether

Sven Mesecke arranged for his employer, Buffalo, to sponsor the social event. Sven showed up with his daughter Abby, proving that we start working on developing wireless engineers young!

Our even was held at Stubbs’s Bar-B-Q, and featured some of the live music that Austin is famous for. I haven’t gone to that many concerts, so it was a bit of an eye-opening experience to be in the room with the enthusiasm and energy of the bands. Young Abby introduced the first band of the night, The Ginn Sisters:

Following a break, Guy Forsyth took the stage. Due to the heat, I had to flee the crowded area downstairs for the relative cool of the less crowded upper floor:

Throughout the evening, people were playing pool. I’m sure that the pool table was attractive in part because it was located inside the air-conditioned area. Here’s Dave Stephenson preparing to break:

It was an awesome event. My only problem was that a meeting the next morning was of interest, and 8:30 am in Austin is 6:30 am for an out-of-state Californian. I had to leave before the second set was done just to get to bed at a reasonable hour.

It’s hard to build a conference wireless network. I’ve built a few over the past five years, and it is always a big engineering challenge. As you build the network, you refine your plans. When users arrive and start sending traffic, you refine your plans. As loads ebb and flow, you refine your plans. I won’t say it’s easy, but it is a well traveled path. Every major gathering of networkers requires wireless connectivity.

I’m accustomed to the user experience on wireless LANs built for industry trade groups like the Wi-Fi Alliance, the IEEE 802.11 working group, and the IETF. The Wi-Fi Alliance uses Michael Hijdra and his team at 2Fast4Wireless, and Verilan does work for both IEEE 802.11 and the IETF. This week, I’m speaking at the TERENA NetConnect conference. It’s only the first day, but I’ve had lots of trouble with the network.

First of all, the network uses web “authentication.” All of the conference attendees have been given a unique account, but the use of accounts is enforced by a captive web portal, not WPA. The Wi-Fi Alliance, IEEE 802, and the IETF all run an 802.1X network, though they also offer an option for unauthenticated access. It seems unfortunate to avoid using 802.1X at the TERENA TNC conference because TERENA’s Eduroam project has done a great deal to drive adoption of 802.1X, and many of the attendees are therefore familiar with 802.1X configuration.

When the plenary hall filled up, the performance went down very quickly. In the first eight minutes, I was disconnected four times. At eight minutes, the network connection gave up the ghost and quit working altogether. Before that point, I was seeing round-trip times that I hadn’t seen since the great AT&T frame relay outage of 1998, when round trips were measured in seconds from my then-office to, well, anywhere. Round trip times were also measured in second-plus range here, and are substantially higher even than the GPRS/EDGE network I use when commuting to work:

(4.2.2.1 is one of my favorite test IP addresses. It’s short, quick, easy to type, and it belongs to a highly redundant DNS server so it is almost always there.)

In the plenary, I was sitting towards the back of the room. As it became clear that the network was failing, people closed up their laptops in frustration. In the afternoon session, an attempted demonstration was aborted due to network performance problems. In all of the rooms, Windows reports low signal strength, so some of the performance problems could be due to AP placement constraints.

Last but definitely not least, there are two network names in use. A sign posted at the plenary room indicates that the split is used for load balancing, and instructs us to use the appropriate one based on user name:

I have connected to both networks, and they appear to use the same DHCP server. This is probably a misguided attempt at broadcast containment and/or load balancing. The Wi-Fi/IEEE 802/IETF networks use a single SSID and let the infrastructure figure out load balancing in a way that is transparent to the users.

I recently had a breakfast meeting in Daly City, and my host picked the location. We met at a restaurant that is right next to a residential area. I arrived first, and when I opened my laptop to start work, I saw several wireless networks available.

I chuckled slightly when I saw the following network name:

A few days later, I was visiting the dentist’s office. Upon opening up a Mac, I was greeted with the following message:

Ahem. Well, I guess it is a matter of trust…

Danny McPherson has written about Wi-Fi access in the “refugee camp” that is the SFO Red Carpet Club.

Having independently discovered last week that Red Carpet Club members could now get Internet access for free via T-Mobile, I was eager to get online in an airport without having to drop another $9.95 to T-Mobile…

Although I’m an elite flyer on United, I am a more elite flyer with American. The Admirals Club (American’s counterpart to the Red Carpet Club) has promoted their Internet access much better. Members all received multiple mailings, and guests who buy a day pass get a card with a code on it.

American partnered with MobileStar for access in the Admirals Club in the late 1990s. Until this year, the network continued to operate only as a T-Mobile hotspot. Now, the T-Mobile hot spot operates in parallel with the captive portal for the Admirals Club. Like the Red Carpet Club, all you need is a magic membership number:

To login, all you need is the United Mileage Plus number of the primary Red Carpet Club account holder [Ed note: In the American Admirals Club, it's the AAdvantage number of the account holder]. Now, having long questioned the wisdom of a luggage tag that displays these numbers, be it a “hole-punched” Mileage Plus membership card, or a more obvious oval-shaped Red Carpet Club tag, I’m even more wary now…

Fortunately, the Admirals Club luggage tags don’t have AAdvantage numbers on them. They do have a bar code that I assume can be translated easily into an AAdvantage number by American employees. On the other hand, if somebody is in the club, you can look for a regular luggage tag. Even on the plane, I bet you could do worse than by looking for the right color luggage tag. I would be willing to bet that most people with black elite luggage tags (Executive Platinum) are also Admirals Club members, and the likelihood only increases if you find somebody with a million miler oval.

I’ve yet to explore how difficult it would be to exhaustive search for valid numbers, or if multiple logins are permitted at a given time, or how far outside of the Red Carpet Club these numbers are valid, or…

As to the last point, the numbers are almost certainly valid as long as you can get to an AP. Although it is possible to build a wireless network that attempts to determine location and restrict services to a certain geographic area, the cost is quite high.

My experience is that the signal goes quite a long distance. Even before I forked over the money for an Admirals Club membership, I used their networks frequently. As a non-member, I could almost always sit in a gate area near the entrance and use the network. (I am a long-time T-Mobile hot spot subscriber through my cell phone plan.) In Chicago, I would sit in the hallway joining the H and K concourses, which was especially nice because there were usually unoccupied power plugs. At Los Angeles, I could sit at gate 41 and get a weak signal.

In the past, I tested whether T-Mobile’s hot spot network would support multiple simultaneous logins, and it does not. I have not tested whether the same is true for the captive portal they run for the Admirals Club. I would be surprised if that were the case because club members are allowed to bring guests, and it is likely that travelers with the ability to pay for an airline club membership have friends and family members who also have their own devices.

My reason for braving the “snowstorm” at Heathrow was to be at the JANET(UK) Networkshop conference. The organizers asked me to present an overview of current wireless standards in development. JANET(UK) is also a founding member of the OpenSEA Alliance, and has arranged for some UK universities to test the supplicant as we develop it.

I impressed (in the older sense of drafting somebody into service) Mark Tysom of JANET(UK) into taking pictures while I spoke. He captured me in front of my favorite slide in the talk, which shows the size of the 802.11n draft over time:

Several interesting vital statistics on the 802.11n draft can be found in this 802.11 working group presentation made by Bruce Kraemer, the long-time chair of TGn who has recently been elected the chair of the entire 802.11 working group.

The venue for my talk was the plenary session, which was held at The Barony Hall at the University of Strathclyde. The Barony Hall was previously a church, and is a wonderful venue for large audiences. As a speaker, it can be slightly intimidating, though!

(Thanks for taking photos, Mark!)

Via Glenn Fleishman, I found this Sacramento Bee article describing a imminent deal between BART and Wi-Fi rail. (I tried the Wi-Fi Rail service, but wasn’t impressed.)

The article has two points worth noting. First, the initial trial will expand from the four downtown San Francisco stations to the big underground areas:

If a deal is struck, Lee says WiFi Rail will install the system on BART’s most heavily traveled underground routes – in Oakland, San Francisco and the Transbay Tube – within 120 days. Coverage for BART’s entire 103-mile system would follow.

The underground core of the BART system runs from the four downtown SF stations, the Transbay Tube, and the Oakland Wye (roughly West Oakland north to 19th Street and west to Lake Merritt).

The article then quotes Wi-Fi Rail’s corporate counsel as adding 45 minutes to a workday:

“Take a BART rider who gets on at Walnut Creek and spends 45 minutes going to downtown San Francisco” and back, says [Gilles] Attia [Wi-Fi Rail's corporate lawyer]. By plugging in, “he’s added 1 1/2 hours to his work day.”

Mr. Attia works in Sacramento, so he may not have first-hand experience with BART. Assuming that I’ve got the bounds of the expanded Wi-Fi Rail deployment right, it’s not that big. Lake Merritt to Civic Center (on my commute) is 16 minutes. 19th Street/Oakland to Civic Center is 18 minutes. 19th Street/Oakland to Lake Merritt is only 5 minutes.

Since my initial report on the unreliability of Wi-Fi Rail a year ago, I haven’t found that the service in train cars has improved. Service is faster and more robust on the platform, but I still find the service on the train spotty.

Earlier this week, we published our technology road map for the Open1X supplicant. They are now available for download in either PDF or Microsoft Word.

In the discussions that the project team held, our biggest goal was to get the supplicant running on as many platforms as we could. The first step is the common desktop operating systems (Windows, Mac OS X, Linux). However, there’s a long term trend at work with computers infiltrating everything. When I first started doing wireless LANs, it was something that was nice to have for laptops. In the past several years, we’ve seen 802.11 go from an esoteric data link to the most obvious way to connect a plethora of devices from laptops to game devices (the Xbox and PSP both have 802.11) to phones (I carry a Nokia E61) and PDAs.

Each time a wireless LAN interface gets put into a device, you need the entire protocol stack complete with all the security protocols. Wireless security protocols can be complex, and expertise hasn’t kept up with the wide diversity in available products. Often, a product will have a wireless LAN interface that lags behind the rest of the product in functionality.

One of the best examples of the “wireless feature lag” is our #1 feature request. Everybody who’s interested in our work has asked us to port the supplicant to the iPhone to get better interoperability with wireless LANs. Most university networks require user credentials (WPA-Enterprise) instead of pre-shared keys (WPA-Personal), but the iPhone lacks that feature. Back in October, there was an iPhone SDK announced, with details to follow in February. We’re waiting to see what features the SDK will bring, and hope to start working on an iPhone shortly. (If you’re interested in 802.1X on the iPhone, sign the on-line petition.)

Once upon a time, a company called Harris produced a chipset called the PRISM. It was the chipset to use for building early 802.11 devices. Way back in 2000, I remember building the linux-wlan project driver on an ancient Pentium laptop to get the 802.11 card working. Back in those days, 802.11 was a Mbps standard, with the glimmer of an 11 Mbps “high speed” 802.11b in the distance.

(Interesting fact: “PRISM” was an acronym for the chip, which stood for “Programmable Radio in the ISM band.” ISM refers to the widely-used slice of spectrum around 2.4 GHz that all these devices use.)

Harris spun of the chip business as Intersil in February 2000, raising $500 million in what was at the time, the largest semiconductor IPO in history. Intersil chips were the chip to use. The venerable PRISM was succeeded by the PRISM-II, which added support for 802.11b. Intersil was flying high. As an example, in 2001, an analyst for thestreet.com wrote that you should ignore all of the brands you saw on 802.11 equipment (notably Apple, which had gained notice with the success of the AirPort access points). To bet on the future success of 802.11, he advised, buy Intersil stock:

Intersil is the enabler of the 802.11b revolution. Intersil’s Prism chipsets power more 802.11b networks than anyone else, and its technology is right out there on the bleeding edge. It is profitable, and Intersil is divesting itself of its slow-growth businesses, making it a pure play and developing a strong balance sheet at the same time.

In July 2003, Intersil sold its wireless LAN business to GlobespanVirata for about $350 million. A few months later in November 2003, Conexant systems then acquired the wireless LAN chip business through a $970 million acquisition of GlobespanVirata.

Last week, Conexant’s fourth quarter financial results press release announced the end of the line for the Prism:

Effective immediately, Conexant is discontinuing further investment in standalone wireless networking product development and will eliminate approximately 140 positions worldwide. Beginning in the second quarter of fiscal 2008, the company expects these actions to save approximately $5 million in quarterly operating expenses. The company plans to maintain the staffing levels required to support existing wireless networking customers with current solutions. Conexant’s remaining wireless employees will join the company’s Broadband Access organization and support DSL gateways that incorporate wireless connectivity.

The Prism chips have long been supplanted by newer vendors like Atheros, Intel, and Broadcom, but I still feel a little bit misty-eyed at the end of the era. It was an early Prism radio that inspired me to get involved in 802.11, and their early support of open source drivers like linux-wlan made them the nexus of experimentation on Linux until other vendors decided to get with the program.

On August 1, the I-35W bridge over the Mississippi River collapsed in Minneapolis. I learned about it on the train home when somebody IMed me to ask about it. My parents live in the area now, and my brother was going to be visiting that day, so I made a few quick phone calls to see if everybody was OK. Calling landlines in the area resulted in an “all circuits busy” tone, but I was able to get through to my family’s mobile phones. They don’t live in the same cell as the bridge, which is a good thing according to this recent article in Wi-Fi Planet:

In fact, as many as 1 in 5 cellular calls to and from the disaster area failed to go through when demand peaked after the collapse. According to the Chicago Tribune, emergency workers resorted to personal cell phones as back-up for a new universal radio system, prompting authorities to ask residents to hold their calls to keep the lines open for rescuers.

The article expands on the topic of network access in disasters, noting how network access can be a lifeline. Rapid capacity expansion is a well-known advantage of wireless networks. It won’t be long before disaster-management teams routinely bring wireless equipment, either in the form of 802.11 or some other technology, on to disaster sites to assist the rescue teams.

Municipal networks have an advantage in being the network equivalent of the “first responder.” Many of these networks are now moving in the direction of more secure access technologies, such as 802.1X (WPA Enterprise) and away from browser-based logins. As this shift occurs, networks will need to provide access to emergency services, usually by regulatory mandate. Within 802.11, the protocol features to enable unauthenticated access for limited purpose is being developed in 802.11u.

One of the recurring annoyances with many 802.11 client devices is that they don’t support the best security protocols. Wi-Fi Protected Access (WPA) has two modes: the Personal mode based on pre-shared keys, and the 802.1X-based Enterprise mode. Well-known weaknesses in the former are not present in the stronger Enterprise mode.

One of the troubles with the lack of support for 802.1X is that it causes headaches for network administrators who are concerned about security, but need some widget to build their networks that doesn’t support 802.1X. I have often labeled many of these devices “network paperclips” because they are small, often inexpensive, and frequently, do a great deal to hold networks together. This morning, Jon Oltsik, the founding father of the OpenSEA Alliance picks up on the theme:

While the PC space is well covered, there is a new network-security frontier out there that remains barren. What about Internet Protocol phones? What about mobile devices? What about network-based appliances like printers?

Jon is getting uncomfortably (for the industry at least) close to an open secret about the Wi-Fi certification, too. There’s no requirement to support 802.1X to get Wi-Fi certification, and it’s often hard to tell from the product packaging whether the 802.1X/Enterprise methods of authentication are supported, or whether the product only supports the quicker-and-less-secure PSK/Personal methods. The Wi-Fi Alliance is working on the issue of how to reduce end-user confusion about security capabilities.

What brought all this to the front of my mind this morning is the much ballyhooed iPhone. There’s been a great deal of excitement about the dual 802.11/cellular capabilities of the device to speak VoIP, but it’s dead on arrival as far as most corporate networks are concerned. In a message to the Salsa-FWNA group this morning, Michael Griego writes about the disappointing wireless LAN security support on the iPhone:

Yes, it lacks 802.1x support out of the box, supporting only PSK security mechanisms. I was personally surprised at this and expect/ hope that this will change in one of the surely-soon-to-be-released updates since it should require only adding the supplicant software to make it work.

(Background note: Salsa-FWNA is an Internet2 group that is defining methods of federated authentication across university campuses. The group is making extensive use of 802.1X, which prevents the current iPhone from doing VoIP across campus boundaries.)

Like Michael, I also hope that Apple is working on an improved supplicant for the iPhone. If the iPhone runs MacOS X, it should be a straightforward port of the existing supplicant.

Finally, I’d like to make an offer for anybody reading this. If you have a device that needs to support 802.1X, but you’re not quite sure what to do (or just need a royalty-free code base), contact the OpenSEA Alliance and we’ll work with you on customizing the software to your device. Sufficiently interesting devices will be “self-customizing” once our developers get their hands on samples.