The card: SMC2532W-B
The card is a Prism2.5 chipset based card. It needed to have the firmware flashed before WPA could be supported and used with the hostap drivers.
The card was flashed under Windows 2000. Both the Primary and Secondary firmwares where flashed at the same time. The Primary firmware can never be flashed alone because it will leave the card in an unusable state.
The Primary was flashed to 1.1.1 and the Secondary firmware was flashed to 1.8.2 allowing the card to support WPA encryption.
After the card was flashed, it was testing in Windows which had been using a RAM downloadable firmware to achieve WPA support (the RAM-firmware levels were primary, 1.1.4 and secondary 1.8.2). Once the Downloadable-Firmware option was disabled in the Windows driver, the card could still connect to WPA encrypted access points using the flashed firmware, Pri 1.1.1 and Sec 1.8.2.
The card was now ready to be setup in Linux using the hostap drivers and get WPA support working. The hostap drivers only supported Prism2.5 card with a secondary firmware of 1.7.4 and higher.
To begin with, since the card has been working just fine with the orinoco drivers for unencrypted access points, the following drivers needed to be blacklisted so the PCMCIA card manger would not load the kernel modules when the card was inserted.
Here is what needs to be done.
At this point, on my Toshiba Portégé 3490CT, the hostap_cs driver would cause a kernel panic when loaded into kernel (18.104.22.168-smp). After searching on the Net and trying to upgrade to the latest version of Hostap (0.4.9) since I was running 0.4.4, I came across a forum post on a Ubuntu site that described the same symptoms I was experiencing but with kernel 2.6.22. In an attempt to trouble shoot the problem, the user had connected to his linux box via a serial console but when he did, the driver never crashed. This lead to a work around that allowed the hostap_cs module to be loaded and function. The work around suggested was to add a serial console to the linux boot up process and letting the system come up that way. The reasoning was that the serial console would use the resources that caused the driver to crash and therefore, the driver would move to the next range of memory or IRQ. Since this solution worked for a few other users, I decided to try it myself.
I edited my /etc/lilo.conf file and added the following line to the linux section.
append = "console=ttyS0,9600n8r"
I then ran lilo to load the changed settings and made then take effect on my system. After rebooting and waiting a little while with a blank screen because bootup info was sent to the serial port with no console attached, I finally got a login prompt. I logged in as root and checked the loaded kernel modules with the lsmod command. The hostap and hostap_cs modules had loaded just fine. I also check the system log with the dmesg command and saw that wifi0 was getting referenced. This was a good sign.
Since I like to watch the startup messages and see what is happening on boot up I decided to add a second console to the append line in my /etc/lilo.conf file. My append line now looks like this.
append = "console=tty0 console=ttyS0,9600n8r"
Please note that the serial console is the last one in the list. This is done so that the /dev/console mapping will be made to the serial console. If this is not done, the hostap_cs driver will once again cause a kernel panic.
Now, the card is reconized and the kernel modules get loaded correctly. All that is left is to figure out how to connect to a WPA enabled access point using the wpa_supplicant package.
Through a bit of trial and error and a lot of web searching, I got WPA support in linux working on my system.
First, use the wpa_passphrase command to get the WPA passkey for the access point's ESSID name and phrase.
wpa_passphrase router password
The output should look like this.
Copy these values and open the /etc/wpa_supplicant.conf file for editing. Here is what needs to be done:Begin by opening /etc/wpa_supplicant.conf for editing. Then, in the first network section change the ssid line to match the Access Point's ESSID.
Next, replace the existing psk= line with the ones the were copied from the wpa_passphrase output.
If you would like to allow normal users to have access to the wpa_gui program, you will need to edit one more line. Change the value of 0 to "users" in the ctrl_interface_group line.
This will allow all members of the users group to have access to wpa_supplicant's interface. Now save and close the /etc/wpa_supplicant.conf file.
The wpa_gui program is located in the
/usr/sbin directory. It is nice to make a
symbolic link to the program in the /usr/bin
directory so the normal users can have easy access to
wpa_gui since /usr/bin
is already in there path by default.
ln -s /usr/sbin/wpa_gui /usr/bin/wpa_gui
Well, that is about all. On the next reboot, you should have a working WPA enabled Wi-Fi 802.11b card so let's set it up to be started by the bootup scripts.
To begin, we open /etc/rc.d/rc.inet1.conf for editing. In the file, we move down to the Wireless LAN section where an example for interface wlan0 exists. There, we uncomment the required lines and set their values.
After editing, here is what the section should look like.
## Example config information for wlan0. Uncomment the lines you need and fill
## in your info. (You may not need all of these for your wireless network)
##WLAN_IWPRIV="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=96389dc 66eaf7e6efd5b5523ae43c7925ff4df2f8b7099495192d44a774fda16"
UPDATE: Here is a WEP104 (WEP 128-HEX key) network configuration section for /etc/wpa_supplicant.conf. For ASCII keys, place the text in quotes (13 charaters).
# WEP Network