Interview with Chris Hessing, Lead Developer of xsupplicant (Linux Journal) [LWN.net]

Matthew Gast talks with Chris Hessing about wireless security protocols, their implementation and their future. "CH: I feel like the security available right now is pretty good, assuming you're running WPA2 with AES. There are some weaknesses in various EAP flavors that need to be addressed, but that's well underway for the most part. What I'd like to do--and I don't know whether we can--is to get a universal EAP type. Something that allows you to use passwords, allows the storage of passwords in secure form and doesn't lock you in to any particular authentication server."

to post comments

Interview with Chris Hessing, Lead Developer of xsupplicant (Linux Journal)

Posted Aug 13, 2005 15:08 UTC (Sat) by smitty_one_each (subscriber, #28989) [Link] (11 responses)

Is there a table anywhere available, showing wireless hardware as row labels and protocols as column labels?
Even if I wanted to undertake an upgrade to the home wireless network security, I would fear trying to acquire configurable hardware that interoperates and has open drivers.
-Chris

Interview with Chris Hessing, Lead Developer of xsupplicant (Linux Journal)

Posted Aug 14, 2005 7:59 UTC (Sun) by jwb (guest, #15467) [Link] (10 responses)

Yes, and you might well fear it. After all these years, the only hardware with a real, fully-featured, open, cross-platform driver that actually works are still the Prism 2.5 and Orinoco. Often they only way to get what you want with respect to wireless is to buy WRT54GS and use them as bridges. At least with that setup you get b/g operation and the whole alphabet of security hacks. For $75, it's also less than some wireless cards.

I still use this page as a reference to wifi hardware:

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/

Interview with Chris Hessing, Lead Developer of xsupplicant (Linux Journal)

Posted Aug 14, 2005 9:36 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (9 responses)

Perhaps I don't understand what "real, fully-featured, open, cross-platform" mean to jwb but my Intel PRO/Wireless 2100 and my housemate's PRO/Wireless 2200 are more than adequate. I've used the ipw2100 on various networks around Europe, and with more esoteric stuff like IPv6 multicast, without problems.

The linked document seems to be at least six months out of date. It refers to rather old versions of some drivers, mentions problems that were solved at the beginning of 2005 etc. Nevertheless it does link several other cards or chipsets that seem to me to have "real, fully-featured, open, cross platform" drivers.

Interview with Chris Hessing, Lead Developer of xsupplicant (Linux Journal)

Posted Aug 14, 2005 10:00 UTC (Sun) by tajyrink (subscriber, #2750) [Link] (8 responses)

You can't use Intel's wireless solutions without somehow acquiring the closed firmware, which is not freely distributable (the terms are not really acceptable). Even if it would be freely distributable like the firmware files of Symbol, Zydas and Atmel are (mostly thanks to the OpenBSD folks' hard work in discussions), it would be a bit problematic as it's still closed source and can't be distributed in eg. Debian as such.

Of the newer devices Atheros, Ralink and Realtek wireless cards don't seemingly need a firmware file and have open drivers in development, but I think they still contain some binary blob (?). Anyway, at least Ralink's drivers are starting to show some maturity and is a better choice than Intel's cards anyway because the manufacturer is has better policy towards open source community than Intel.

Interview with Chris Hessing, Lead Developer of xsupplicant (Linux Journal)

Posted Aug 14, 2005 10:47 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

however if they were to raise the cost of the devices to add a flash chip to them and put the exact same firmware file in the flash chip (along with a method for upgradeing said flash) the devices would be considered fully supported and there wouldn't be any problem with them at all.

Debian has heartach over this, but I don't think any other significant distro considers the firmware 'freeness' to be an issue (beyond the need to be allowed to distribute the binary firmware blobs)

Interview with Chris Hessing, Lead Developer of xsupplicant (Linux Journal)

Posted Aug 15, 2005 6:22 UTC (Mon) by tajyrink (subscriber, #2750) [Link]

Yes, you're right. The unfortunate thing is that Debian's policy is actually understandable, but the effects of it are a bit odd in the way you just mentioned.

To tialaramex's comment, the problem with Intel's license is that when you redistribute the firmware you become a "vendor" in their mind and you have to comply with additional provisions. That's what makes the firmware non-freely redistributable.

See eg. http://kerneltrap.org/node/4202 for some more information.

Intel wireless drivers (drifting OT)

Posted Aug 14, 2005 14:01 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (5 responses)

The firmware appears to be as freely redistributable as we'd expect. You're obliged to include the license text and ensure it is installed alongside the firmware (like practically anything, including the GPL) and to make the user aware of their rights and responsibilities (ditto).

Unless I'm missing something Intel believes that an RPM including the firmware and an appropriate license is a redistributable binary, in the same sense that a Loki-installer packaged version of e.g. Freeciv is redistributable. Certainly such RPMs exist with Intel's blessing. RPMs are not permitted to show "shrink-wrap" licenses, and so the firmware installs silently, on the assumption that the user will consult the package description or the installed license file to know the applicable conditions. If there's an outstanding issue with Intel's redistribution policy it's something that can be worked on.

I understand the point of principle that argues for preferring a card with a 64kbyte ROM full of unknowable stuff, over a card with 64kbyte of RAM and a 64kbyte firmware blob to be uploaded, but perhaps this principle deserves more consideration. We recently found a bug in an Intel (non-wireless) network chip. The firmware isn't replaceable, so it's now useless. Would we /really/ be worse off if the firmware was a replaceable binary blob? Would other users be worse off?

Intel wireless drivers (drifting OT)

Posted Aug 15, 2005 9:36 UTC (Mon) by nchip (guest, #13292) [Link] (4 responses)

The binary blob issue is becoming more complex. Consider someone would
make a Access Point based on Linux. Later some manufacturer removes the
ethernet port from the Access Point, and replace it with a USB client
port. They also decide to save in costs, and remove the flash storage
while at it.

Now, they would have a USB device, which needs Firmware, which is Linux!
to make matters more complex, it carries proprietary kernel modules.

Would anyone really do that? We are almost there, this one still carries
Linux on it's own flash:

http://www.usr.com/support/product-template.asp?prod=5420

Add to the surrealism: A Linux-based USB device does not work In Linux..

Now to support Something on Linux hosts, you could like some drivers,
considering the firmware (Linux+modules+userland) just a binary blob and
#include it in the kernel header. Or you could hotplug the firmware from
a separate file (which makes it not work out of box). Nobody will want to
cross-compile the firmwares kernel.

In any case someone will compile about bundling kernel and a proprietary
module - while others will point to the drivers already bundling
proprietary firmwares...

Intel wireless drivers (drifting OT)

Posted Aug 15, 2005 9:51 UTC (Mon) by lacostej (guest, #2760) [Link] (2 responses)

> Nobody will want to cross-compile the firmwares kernel.

Isn't it what madwifi does?

Intel wireless drivers (drifting OT)

Posted Aug 21, 2005 15:36 UTC (Sun) by nchip (guest, #13292) [Link] (1 responses)

No? Where did you get that idea from?

Intel wireless drivers (drifting OT)

Posted Aug 22, 2005 0:06 UTC (Mon) by lacostej (guest, #2760) [Link]

I think I should apply a checksum algorythm to the transmission protocol that takes the on-screen bits into neuronal activities... My bad.

Intel wireless drivers (drifting OT)

Posted Aug 15, 2005 10:08 UTC (Mon) by dlang (guest, #313) [Link]

if the firmware is linux then the license of linux will require that the source be made available

and it again doesn't matter if said firmware gets downloaded into ram or is stored in flash/rom on the device