Archive for the ‘wireless’ Category

Open1X Project update and roadmap

Thursday, February 7th, 2008

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.)

The end of the PRISM era: Conexant stops wireless LAN chip development

Monday, November 5th, 2007

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.

802.11 and disaster recovery

Tuesday, August 14th, 2007

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.

Better 802.1X support for VoIP phones and “network paperclips”

Monday, July 2nd, 2007

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.

A dispatch from the home network: Powerline communications actually work!

Monday, June 18th, 2007

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.

BART says: Yes, Wi-Fi coverage is bad, but you shouldn’t be using it

Monday, June 18th, 2007

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.

Security for retail wireless LANs

Wednesday, June 6th, 2007

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.)

Lessons from building the Faraday Cage at the Interop Labs

Tuesday, May 29th, 2007

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.”

High-tech home ec: Building a Faraday cage at the Interop Labs

Tuesday, May 22nd, 2007

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:
Sewing the cage, outside view

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

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:
Jed in the cage

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:
Initials in the cage
(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.)

OpenSEA launches!

Monday, May 14th, 2007

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.