Surfing the Luminiferous Ether

Recently, my parents moved out of a two-story house into a condominium. The condo is smaller, but it’s more spread out. The building is also a great deal sturdier, since it’s a 13-story high-rise, instead of a two-story detached home. In the old house, a single AP in the middle of the home on the second floor covered everything adequately. In the new condo, the wireless signal was not so great around the edges of the unit, and that expressed itself most dramatically in the speed of transferring recording programs between two TiVos.

Obviously, a second AP was needed to cover the extra horizontal distance, but I needed to link them to a single VLAN in order to get communications between clients of the two APs. The condo’s walls were already finished, and the last thing I wanted to learn to do was how to fish cable through ceilings and walls. (”It’s easy,” says a colleague with the right tools, as I tell him this after the fact. “There’s a really long drill bit, and then you just snake a pull cable over the ceiling. It works even better when you’re not on the top floor of the building!”)

It turns out the problem was pretty easy to solve with powerline networking. One of the APs acts like a firewall/router for the whole condo, and feeds the second AP over powerline. A third unit connects up a computer with only an Ethernet port. I used the new HomePlug AV equipment, which boasts speeds of up to 200 Mbps. According to the Netgear’s test tool, raw link speeds are 150-175 Mbps. (I wound up selecting the Netgear equipment because it was the best industrial design in the group, and it had the least garish display.)

I have one big worry about the equipment. It works by sending the data over the electrical wire as high-frequency modulation. Most power strips/surge suppressors will filter out high frequency noise, so the units need to be plugged directly into the wall. Without protection, I wonder how they’ll fare when the power flickers in a storm. Naturally, I worry about security as well, since there is no obvious security protocol configuration that took place during my installation.

At this point, everything seems to be working. The question is whether I am brave enough to upgrade the APs to some new firmware. I am tempted to because the third-party firmware offers multi-SSID support, with different security configurations, which would help contain some of the potential damage from the non-WPA TiVos.

You heard it here first. In May, I wrote that the new Wi-Fi service on BART needs some improvement. My blog post was picked up by the Contra Costa Times, and here’s what they had to say about my overall impression that it’s a marginal service:

[BART spokesperson Linton] Johnson acknowledged that Wi-Fi Rail is adjusting the placement of the access points.

“At this point, this is an internal test. Although customer feedback is valuable, this part of the test isn’t designed for that. Maybe the next part will be,” he said.

One thing that I’ve learned in my career in high-tech is that early customers will work with you and help you fix just about anything because of their enthusiasm. It’s one of the big reasons why I’ve spent more than half my time at start-up companies. I’d be interested in learning more about how the trains are getting connected up, and I’d dearly like to see an wireless LAN connection that could stay up when the trains are in the tunnels. I’d also like to think that my opinions about wireless LANs might be worth something.

George Ou blogged an interesting survey of retail wireless LAN security in his neighborhood, and rhetorically asks the question of whether we need another gazillion dollars in damage before the industry wakes up and does something about it. The problem is that features and convenience, as always, outweigh security.

With my current company, I’ve worked with a couple of retail stores to implement wireless LANs. One of the major advantages that stores perceive is the ability to add devices whenever it’s necessary to respond to demand. One of the classic examples that always came up was the idea of a store wanting to use cash registers, connected wirelessly, during sales or the busy holiday season to add check-out capacity.

The problem? Most cash registers don’t have 802.1X supplicants, and they run a motley collection of old operating systems that may not allow easy addition of 802.1X. OS/2 was a common operating system, but there was significant presence for Windows95, Windows 2000, and even (shudder) DOS. You just don’t have good options for using the right sort of wireless LAN security protocols. Most retail companies were either unaware of the risk, or willing to take the risk given the apparent high cost of upgrading to devices that were capable of supporting WPA.

Or, from the organizational perspective, it doesn’t help that retail stores are not monolithic entities. There may (or may not) be somebody in the IT department who understands the risks of using poor wireless security protocols, but I don’t think it’s a stretch to say that such a person probably isn’t involved in the details of picking out cash registers. It’s almost certain that the stores are not demanding features like WPA2 from their cash register vendors.

(Yes, this is one of the things that could be addressed in part by the OpenSEA Alliance and the Open1X Project.)

With Interop over, it’s worth jotting down a few lessons about the Interop Labs Faraday cage. First, the results were better than I expected, given the difficulty of building a complete RF shield. Based on measurements we took using both test tools and laptop-based tools, it appears that our cage provided about 40-45 dB of shield, which is a good amount given our abbreviated time and limited materials budget. For comparison, the VeriWave test chambers are guaranteed to provide at least 80 dB of shielding (though the number appears to be much higher in practice).

• 802.11 shielding: 40 dB of shielding is good enough to provide a substantial reduction in the number of visible APs. Even before the show started, it was possible to see 300 to 400 APs immediately outside the door of the cage. With the door closed, we could reduce that number to 20-30, which includes the four APs that were powered on inside the cage.
• Mobile phone shielding: The cage did cause some signal loss for cell phone signals, but the service came through loud and clear. Occasionally, some phones would exhibit the loss of one bar, but I don’t believe there is a standard indication for what a bar means between vendors, or even between different phones from the same vendor.
• Related to the first point, the team from DiVitas found the cage extremely useful. Their demonstration of an fixed/mobile convergence application depended on having “reasonable” 802.11 service to set up a call on 802.11, and then degraded service to hand the call over to the voice network. Our cage provided that without any difficulty, and even allowed people to hear that voice quality on 802.11 can be better than voice quality on cellular networks.

After going through the process, we did learn a few lessons:

• Buy, don’t build. We had to spend lots of time fiddling with the cage, and there were complicated entry/exit procedures for making sure that the door was adequately screened. Various flaps had to be secured in particular ways to get maximum shielding.
• Related to the previous point: Don’t buy from us. We had fun building it, but this is not a vocation for us.
• Materials matter. The cage was made of aluminum screen because it is inexpensive material, but aluminium has properties that are suboptimal for a project like this. Aluminium naturally forms a protective oxide layer. In aerospace, that’s cool. In Faraday cage manufacture, it’s not. The aluminium oxide is an insulator, so we saw resistances across the outer mesh screen approach an ohm if the current had to cross sheet boundaries. Aluminium is a difficult material to work with, since it melts at 660 °C, but its oxide melts at 2054 °C. In practice, we were unable to join the metal sheets together directly because we didn’t want to try brazing (and we lacked equipment which could generate the requisite heat anyway); we ultimately settled for “sewing” the sheets together with copper wire as shown in the photos included with original post.
• Complete screening is hard. Our first attempt was to keep the cage completely isolated from everything, with only a power drop. However, putting Ethernet cables in to the cage did not seem to change the screening effect at all. Ethernet is tightly twisted to resist carrying interference, but it can still act like an antenna. There are two possible conclusions: we did a perfect job putting the Ethernet in, or the cage leaked enough that there was no incremental penalty from the Ethernet cables. We’ll go with the latter choice.
• As a sign that the cage leaked even without the Ethernet, we did not notice any difference between (1) no Ethernet cables, (2) one Ethernet cable, (3) one Ethernet cable with a snap-on ferrite core, or (4) two Ethernet cables, one of which had a snap-on core. For demonstration purposes, we put two cables in to the cage, but a “real” cage should take penetrations much more seriously.
• Grounding didn’t matter. The electrical contractor set up a ground wire for us from the show electrical system, but connecting it did not make a difference in the effectiveness of the cage. Our suspicion is that the ground wire was good enough to act as an electrical safety, but that it had high impedance to the ground itself. In the end, we decided to leave it connected because it “looked cool.”

As part of the VoIP demo at year’s Interop Labs, we’re building a Faraday cage. Last year, I did some basic research into quality of service using WMM by recording voice samples over the air, using the wireless traffic at the show floor for background noise.

This year, the team wanted to do something a bit more controlled. We had questions about how well WMM worked when more than a single call was prioritized. To control for the many variables of wireless traffic on the trade show floor, we needed to isolate the VoIP testing from everything else. During the staging event, Jed Daniels built a prototype Faraday cage to keep the show floor out, and our background traffic in.

Building a walk-in cage is a lot harder than building a small prototype. Faraday cages work best when they are a single conductive surface, but the walk-in cage was big enough that we had to join sheets of mesh. To improve conductivity between panels, we wound up “sewing” sheets together with copper wire.

Needles are not well designed for pulling wire through a small-aperture mesh, so we needed to sew in two-person teams. Here’s me working with Jed, pulling copper wire through the mesh as we sew along the base:

Here’s the reverse view, looking over Jed’s head towards the outside.

Here’s a shot of the final result, with Jed and an engineer from Veriwave working on the test tool to generate controlled background traffic for our demonstrations:

Finally, after all that work, we felt the need to “make our mark,” so all the people who worked on the cage sewed initials in to the front panel:

(From the upper left to the lower right, the initials are Jed Daniels, Mike McCauley, Matthew Gast, J.J. McNamara, Jerry Perser, Bill “WEJ” Jensen, and John Balogh.)

Today, the OpenSEA Alliance launched, with the objective of developing a cross-platform open source 802.1X supplicant. I was fortunate enough to be part of the initial group, both as an individual and representing one of the founding companies.

Any time you get multiple companies together, it can be challenging coming to consensus. We were helped immensely by Cliff Schmidt from the Apache foundation, and were lucky to be able to draw extensively on his expertise.

One of the few thorny issues that was outside of Cliff’s immediate expertise in law was deciding on a name. Naturally, he helped assist the group in selecting a name that was not already in use and could be legally protected, but we still had to come up with a name within those broad criteria. “OpenSEA” was my suggestion, originally proposed to come up with a middle ground between a name that was specifically tied to 802.1X and a more general name. Officially, “SEA” stands for “Secure Edge Access,” but unofficially, we’re using the “open sea” phrase to indicate that changes at the network edge will have profound effects on the way networks are built and managed. As a fun point, we get the ability to give nautical-themed code names to our projects.

Starting the organization was quite educational, and I’m glad I participated. In addition to getting agreement on how to structure the organization, there’s a lot of start-up work to do to incorporate, get a bank account, and so on. At our first meeting last week, I was elected to the board of directors for a two-year term, ending in 2009. I’m concurrently serving a one-year term as corporate secretary.

So, the easy work is done, and the organization is running. The challenge now is to make it successful. Right now, the group depends on volunteer labor. As part of the process of starting OpenSEA, I learned from a colleague that the Wi-Fi Alliance started in much the same way, but it has now become successful enough that it has a professional staff. While OpenSEA probably will not be as well-known as Wi-Fi, it can certainly become successful enough to outgrow volunteers.

Last week, I learned about the Wi-Fi service on the downtown corridor for BART. I’ve been riding BART all week, in part due to the collapse of the freeway that runs between my home and the office. As a result, I’ve used the service quite a bit this week.

Wi-Fi Rail claims to cover the platforms at the four stations in the downtown corridor (Civic Center, Powell, Montgomery, and Embarcadero), plus the tunnel between Civic Center and Powell. To put this in proper context, consult the BART system map.

After using for the network for a week, here’s a few notes on how to use it to its best advantage:

• Stay on the platform side of the train. In the downtown corridor, all the stations have a center platform, so the doors on the left side of the train open. I have sat on both the left side and the right side of the train, and I have noticed that the network performs better when I sit on the left, presumably because it it closer to the access points covering the platform, and it is closer to the metal walls of the train.
• Sit on the first car of the train. If you’re in the lead car of the train, your 802.11 device can look for the access point as the train enters the station, not as it finishes pulling in to the station. There may also be an advantage to sitting in the first car because the signal only needs to penetrate the front of one car and not multiple cars, but that’s a speculative theory without knowing more about the placement of access points.
• Don’t count on the network when moving. I’m not sure where the access points are, but I doubt they are on the train. There are no new devices that are apparent on the trains themselves, and the signal strength fluctuates wildly enough that it seems like the the access points are placed along the train line and not on the train cars. 802.11 doesn’t do vehicular speeds between devices all that well, unless you’ve engineered a wide area network.
• Don’t expect anything in the tunnels. Although Wi-Fi Rail has specifically stated that they tried to cover the tunnel between Civic Center and Powell stations, I don’t see a qualitative difference between it and the other two tunnel segments. I’m able to use the network to get work done by paying attention to when the signal is good and sending data, or by queuing up data to go when a connection is restored.

Coverage is not great once you leave the platform, which restricts the buyers to BART riders who have a long wait on the platform at one of the four stations. A passenger like me who rides through the stops would hardly notice, since it’s scheduled as a five-minute trip. (Are business travelers riding to the airport a big market for Wi-Fi services?)

From a practical perspective, it seems like the only people who would be willing to spend the money are those waiting for a train, not those getting off. If you are getting off because you live close and were willing to pay the high price, a broadband connection is probably a few minutes away at home. If you’re transfering to a bus, there are hot spots at street level. If you’re transfering to the to the Muni Metro subway, forget about using electronic devices at rush-hour because the trains are so crowded.

I’ll stick with my unlimited cell data plan from T-Mobile, which offers continuous EDGE service through the downtown tunnels, and adds the ability to use any T-Mobile hot spot in the country.

I’ve been out of the country, so I can only watch from afar, but Glenn ran a story about getting 802.11 on BART, provided by a company called Wi-Fi Rail.

I was interested, so I clicked through to find out more about the network. According to the WiFi Rail site, the network covers “Embarcadero, Montgomery Street, Powell Street, and Civic Center, and the the tubes between Civic Center and Powell Street.” That’s not quite as good as the existing area covered by the cellular network between Civic Center and Embarcadero that I have been using with my T-Mobile data subscription. (I certainly hope that the speeds are better.)

Wi-Fi Rail is asking a hefty amount ($10/day, $30/month, or $300/year). For just four stations (and the tube link between only two of them), there’s no point in buying the service a higher price than my T-Mobile HotSpot subscription. For one subscription, I would prefer to work continuously through the hour-long train ride. The cell data connection is available in the downtown corridor and in the above-ground areas of the East Bay, so it covers a bit more than half of my journey. To pry open my wallet, WiFi Rail will need to get coverage for more than half of the journey, perhaps by partnering with other hot spot networks. (They will also need a better roll-out schedule than was promised in this November 2005 San Francisco Chronicle story on the cellular network.)

The big problem for the train deployments is how to connect train riders to the Internet as they move. Typically, a train deployment will use Wi-Fi on the inside, linked up to one of a variety of backhaul technologies. The WiFi Rail web site doesn’t talk about how the train riders are linked up. My guess, given that I haven’t seen antennas in the trains, is that in-train service is provided by the APs on the platform, perhaps with antennas to get coverage down the tunnel. Spacing between the downtown stations is about half a mile, and the tunnel is nice and straight. If WiFi Rail is using the APs to provide service in tunnels, they will probably use a a fancy antenna (either a distributed antenna system or a “leaky coaxial” antenna) to get good-size coverage from a single AP.

Service is apparently free during the trial period. When I tried to sign-up, here’s what I saw when I handed over an e-mail address:

I hope the service is provided more robustly than the sign-up…

There are multiple wireless networks at the Hong Kong International Airport, but most of them cost money. If you want free access, go to gate 2, which is right underneath The Wing, the Cathay Pacific business-class lounge. You can hop on the free network without being in the lounge, and the signal strength is very good since it’s not walled in on the level above.

Two months ago in London, the IEEE 802.11 working group sent out a new 802.11n draft out for a vote.

The ballot closed on Friday. I’m sitting in the opening plenary for this week’s IEEE 802.11 meeting in Orlando, and the results of the ballot have just been reported. The short of it is that draft 2.0 did receive a 75% supermajority. Due to the interest in the draft, Stuart Kerry, the 802.11 working group chair, announced that the 2.0 draft would be made available for sale by the IEEE.

For the curious, here are the facts:

• 325 voters were eligible to participate in the ballot. 306 (94.2%) did. (There is a floor on the return ratio which must be met before a ballot result is followed.)
• 231 voters approved of the draft, which at 83.4% handily surpassed the 75% threshold required to move forward. From this point on, the 802.11n draft will go through what’s called a “recirculation” ballot. Subsequent drafts will go back to the same set of voters from January as long the approval rate stays above 75%.
• There were 46 votes (16.6%) not in favor of approving, and 28 abstensions (9.2%). Four votes were invalid and not counted.
• There is likely to be some minor change to the draft going forward. It received 3,163 comments (including duplicates). The task group leadership did some basic comment processing, and reported that there are 1,441 unique editorial comments and 1,635 unique technical comments.

It’s not quite correct to say that the draft has “passed,” since it’s not yet moving on to the next stage of the IEEE process (called a “sponsor ballot”). However, it’s clear from the results that the draft is technically solid. While there may be some minor changes to the existing text before ratification, it seems almost certain that the major features have taken shape, especially since draft 2 is going to be used as the basis for Wi-Fi certification efforts.