Your message dated Sun, 2 Jan 2011 15:54:32 +1100
with message-id <20110102045432.gd5...@hezmatt.org>
and subject line Wireless config issues with ath5k
has caused the Debian Bug report #490382,
regarding netcfg: Wireless configuration issues with ath5k
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
490382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490382
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
As the ath5k driver has been extensively rewritten, and mac80211-based
wireless cards have been tested to work OK, I'm going to close off this bug
report. If there are any issues, please feel free to reopen this bug report
or open a new one.
--- End Message ---
