Package: netcfg Version: 1.44 Severity: important I've been playing with the Lenny Beta2 netboot and my new wireless router. My laptop has an Atheros-based wireless PCMCIA card supported by ath5k.
The ath5k driver has a serious bug with WEP somewhere, so I've been testing D-I with unsecured AP: no WEP/WPA, just (hidden) ESSID and MAC address check on AP. The AP is set for channel 10. Result is that DHCP fails, basically because netcfg does too much. The way to very reliably get a working connection is very simple: ip link set wlan0 up iwconfig wlan0 essid <myessid> dhclient wlan0 But here is what netcfg actually does (log from iwevent; comments added manually). Waiting for Wireless Events from interfaces... # Starting netcfg... 18:48:51.687526 wlan0 Set Mode:Managed 18:48:51.687620 wlan0 Set Frequency:2.412 GHz (Channel 1) 18:48:51.687664 wlan0 Set Encryption key:on 18:48:51.687690 wlan0 Set Encryption key:off 18:48:51.687818 wlan0 Set ESSID:off/any 18:48:52.722911 wlan0 Scan request completed # Prompt for eth0/wlan0 - selecting wlan... # Prompt for 'managed/ad-hoc network' - selecting managed... # Prompt for ESSID - entering... 18:49:52.333805 wlan0 Set Mode:Managed 18:49:52.333837 wlan0 Set Frequency:2.412 GHz (Channel 1) 18:49:52.333857 wlan0 Set Encryption key:on 18:49:52.333866 wlan0 Set Encryption key:off 18:49:52.333878 wlan0 Set ESSID:"<myessid>" # Prompt for WEP key - leaving empty... 18:50:15.887172 wlan0 Set Mode:Managed 18:50:15.887207 wlan0 Set Frequency:2.412 GHz (Channel 1) 18:50:15.887228 wlan0 Set Encryption key:off 18:50:15.887236 wlan0 Set ESSID:"<myessid>" # Trying DHCP... # Failed. # Manually setting correct channel (using iwconfig)... 18:52:28.082868 wlan0 Set Frequency=2.457 GHz (Channel 10) # Retrying DHCP... # Still fails (no rescan?). # Manually resetting ESSID (using iwconfig)... 18:53:46.271342 wlan0 Set ESSID:"<myessid>" 18:53:47.347548 wlan0 Scan request completed 18:53:47.353328 wlan0 Custom driver event:ASSOCINFO(ReqIEs=000c57696c6465726c616e643134010802040b16182430483202606c RespIEs=010882848b962430486c32040c121860dd09001018020013000000) 18:53:47.353361 wlan0 New Access Point/Cell address:00:14:C1:38:E5:15 # Note that sometimes the rescan seems not to take place here! # I'm not sure what exactly triggers the "scan request". It could be the # resetting of the ESSID, but also something external. # Retrying DHCP... # DHCP success! # If the rescan does not happen, DHCP still fails obviously. The basic problem is that netcfg "locks" the driver into a wrong channel (likely the one of the first AP in its initial scan) and because of that the interface fails to associate. If the channel would be left alone, things would go fine. But the setting of the channel seems at least suspicious to me. It could also be this is expected behavior from library/driver and that netcfg is doing things right and that the bug is in ath5k. That can only be verified by replaying this scenario with a different card or driver. I'll try to do just that using the madwifi driver. An alternative to get correct wireless setup is to manually set correct channel using iwconfig from shell *before* starting netcfg. At least that means it's locked into the correct channel. But even here the "rescan" does not get triggered reliably. You'd expect that to happen when the "Searching for APs" progress bar is displayed (between entering ESSID and WEP key), but iwevent does not show that. It will take a few retries of reconfigure wireless and dhcp to get there. Setting a wrong ESSID on purpose does not make much difference. What's also weird is that sometimes the "Searching for APs" progress bar is displayed between ESSID and WEP dialogs, but sometimes it is not. A final problem could also be that dhclient seems to remain running during wireless reconfigurations, or even if netcfg is restarted. All in all highly unsatisfying... Final note. If I manually do ip link set wlan0 up iwconfig wlan0 essid <myessid> dhclient wlan0 and then redo the 'iwconfig essid', that very reliably _does_ trigger a rescan, so something in netcfg or iwlib looks to be interfering with that basic behavior.
signature.asc
Description: This is a digitally signed message part.
