Atheros AR242x 64 (5007 chipset)
The information here was helpful for understanding this newer chip. For a module, Zenwalk provides ath5k, but ath5k wasn't responding well to configuration attempts, so I turned to a Madwifi module. Incidentally, the Madwifi site also contains information on ath5k here, and it appears the ath5k module will eventually be effective. Currently however, the steps which worked with the Madwifi module were:
1. in /etc/modprobe.d/blacklist, blacklist the "ath5k" module
2. reboot and lsmod - make sure ath5k is gone
3. download madwifi-hal-0.10.5.6-r3861-20080903.tar.gz , or the newest one there, make, and install.
4. reboot again and lsmod
5. iwconfig ath0
WEP
WEP is trivial, merely requiring the two iwconfig commands "essid" and "key restricted", matched to whatever network I was using. Because I'm multihomed, the order of bringing-up the interfaces was the only other pay-attention issue. If the interfaces are activated backwards in /etc/rc.d/rc.local, then dhcpcd apparently attempt to assign DNS to the interface on the LAN, rather than the one on the WLAN. blah blah blah.
WPA
The basis here was again gained at this Zenwalk wiki , but there are a couple of tweaks or clarifications. It appears that wpa_supplicant relies upon inserting the wext module into the kernel.
1. using wpa_passphrase with the [essid] and [password] varies with the WLAN with which one wants to connect. The command is used similarly to the WEP iwconfig ath0 key restricted "xxxxx", which varies with each WLAN. Wpa_password then, is not a key for the laptop I'm working from, it's a password key hashed for the WLAN I'm attempting to connect with. This means I have a different entry for each WPA WLAN I'm working on.
2. wpa_password [essid] [password] > /etc/wpa_supplicant.conf is a brilliant way to start the initial conf file. And, as noted in the wiki, the file can be this simple to work:
3. The following command line from the wiki configured ath0 properly on the first shot:
network={
ssid="BART Transit"
#psk="oct2008@rezt9bit"
psk=3ad964f16045787dec86a4730e9dec4bedaa9e24f2998eacfa363e80510e3393
key_mgmt=WPA-PSK
proto=WPA
}
wpa_supplicant -i wlan0 -D wext -c /etc/wpa_supplicant.conf -Bthe "-B" switch is added to make the program run as a daemon, and might not be necessary.
4. After the above, I had only to dhcpcd ath0 to get a valid connection.
5. One issue appears to be quickly enabling or disabling configurations for different WLANs via /etc/wpa_supplicant.conf. (see wicd below).
6. Permanence/boot - inserting the line in Step 3 above into an /etc/rc.local should work if I have an /etc/wpa_supplicant.conf file with a single network configuration in it.
more wpa_supplicant.conf
Wpa_supplicant is not necessary for WEP security, since we can program the card directly with CLI commands to prepare WEP. However, if one chooses to run wpa_supplicant for everything, /etc/wpa_supplicant.conf files appear able to configure WEP and unencrypted connections, in addition to WPA connections. The conf files are useful for storing various wi-fi location configurations. Each connection requires a different conf file, eg etc.wpa_supplicant1.conf, etc.wpa_supplicant2.conf, etc. Apparently wicd can do this with a gui interface which manages switching. But this also means the wicd daemon must run - additional memory usage.
A site with the wpa_supplicant.conf commands is this one, and a site that shows the different WLAN setups in the "conf" file is here (scroll down).
wicd
Wicd configuration files live in /etc/wicd/encryption/templates. A primer for converting wpa_supplicant.conf files to wicd configurations is at this site. Once the various templates are in place, it appears we can switch between them using the wicd gui, though it's unclear if dhcpcd would need to be killed and restarted in the command line?
No comments:
Post a Comment