[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#490382: marked as done (netcfg: Wireless configuration issues with ath5k)

Your message dated Sun, 2 Jan 2011 15:54:32 +1100
with message-id <20110102045432.GD5595@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 owner@bugs.debian.org

490382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490382
Debian Bug Tracking System
Contact owner@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 
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 
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.

Attachment: 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 ---

Reply to: