From: Andrew Barr <barr.156@os...> - 2004-02-07 20:09:07
I am new to this list, and I have a question. I have successfully set up my
Dell Inspiron 300m's Intel PRO/Wireless 2100 (Centrino) adapter using
Ndiswrapper, and I can access my home network just fine. There is a network
up on campus that I would like to use as well, and it uses 802.1x
authentication and dynamic WEP rekeying. I have a username and password and
I've used the Intel PROset software in Windows to successfully authenticate
before. I would like to access this network in Linux (I want to eventually
make this a Linux-only laptop). My question is: is there anything about
Ndiswrapper that would prevent Xsupplicant from the Open1x project from
properly using 802.1x authentication and rekeying? I am using the latest
stable Ndiswrapper version, and I had to download the Xsupplicant CVS (the
network uses LEAP, which is not supported in the stable version). The
documentation for Xsupplicant says that some wireless cards have issues with
802.1x and dynamic WEP so I thought someone might be able to give me an idea
of whether it worked or not before I was back up on campus on Monday. The
documentation has a section addressed to driver maintainers that provides
-- Getting a driver to work with 802.1x, dynamic WEP, and Linux --
In most cases, getting a wireless card driver to work correctly with 802.1x,
and Linux is fairly simple. Current driver implementations will issue a
reset when the WEP keys are set. When the card is reset, it will start a
802.11 authentication/association. This in turn causes a new 802.1x
authentication to happen. Once the 802.1x authentication is complete, and a
WEP key is set, the card is again reset.
As you can see, this behavior will cause the card to reset itself
and keep the card from passing traffic correctly. The solution to this
is as simple as *NOT* having the card reset when a WEP key is set!
One other issue that seems to be common among wireless card drivers is the
assumption that the last WEP key set should be the WEP key used to transmit.
Prior to 802.1x, this made some amount of sense, and would work with no
problems. However, because 802.1x enables the use of more than one key (one
for transmit, one for recieve, one for broadcast, etc.) the assumption that
the last key set is the transmit key generally doesn't work. Instead, when
the IOCTL to set the key is made, the only time that the index for the
transmit key should change, is when the key length is zero.
I hope I've provided enough information. Thanks to anyone who can help me.