Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#11273 - [initscripts] New network daemon fails to associate with a significant number of cards.

Attached to Project: Arch Linux
Opened by Connor Behan (connorbehan) - Wednesday, 20 August 2008, 23:11 GMT
Last edited by Paul Mattal (paul) - Saturday, 06 February 2010, 13:56 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas B├Ąchler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No

Details

Description:
Since the 18/08/08 initscripts update, running /etc/rc.d/network start fails on unsecured networks with "Could not associate ath0 - try increasing WIRELESS_TIMEOUT and check networkis WEP or has no security" regardless of WIRELESS_TIMEOUT value for ath0 drivers and possibly others. Workarounds exist.

Additional info:
* initscripts 2008.08-1
* relevant /etc/rc.conf areas:

MODULES=(ath0)
INTEFACES=(ath0)
ath0="dhcp"
DAEMONS=(network)

* /etc/conf.d/wireless:

wlan_ath0="ath0 mode managed essid default"
WLAN_INTERFACES=(ath0)

Steps to reproduce:
Setup your files as shown above, turn on an unsecured wireless router, insert an affected card such as an Atheros one and startup your system.
This task depends upon

Closed by  Paul Mattal (paul)
Saturday, 06 February 2010, 13:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  We believe this is fixed in newer versions of initscripts, but requests for confirmation have not been answered. Please request reopen if you have evidence this is still a bug.
Comment by c (monstermudder78) - Thursday, 21 August 2008, 06:48 GMT
Had the same problem with a Texas Instruments ACX 111 wireless card and wireless settings managed through /etd/rc.conf.
Comment by John Stechschulte (jstech) - Friday, 22 August 2008, 03:43 GMT
Same problem with RaLink RT2561/RT61 chipset on GIGABYTE GN-WP01GS card.
Comment by Christopher (IMG) - Sunday, 24 August 2008, 16:41 GMT
Up to the level i understand the "problem", i experience it myself since last update to 2.6.26 with my intel pro wireless 3945 card, using the iwl3945/mac80211 module combo.

Extra tip: the network script *does* apply the "mode", "essid" (things you set with iwconfig), etc, but nothing regarding ip/netmask (things you set with ifconfig) so the network remains down.(at least for me)

Extra tip2: if you manually set ip/netmask using ifconfig and the bring up the wireless interface, and then run again the network script , it reports no errors and seems to "complete" its tasks, but your connectivity is poor (at least for ad-hoc that i tested) *and* dmesg brings a lot of messages like :

..............
wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 26:00:9d:76:70:bb
wlan0: Configured IBSS beacon template
phy2: Adding new IBSS station 00:16:b6:a1:0e:6e (dev=wlan0)
wlan0: Configured IBSS beacon template
phy2: Adding new IBSS station 00:16:b6:a1:0e:6e (dev=wlan0)
wlan0: Configured IBSS beacon template
..............

Comment by Jules (Misfit138) - Tuesday, 26 August 2008, 03:35 GMT
Same problem here. Madwifi and Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)
Comment by Jules (Misfit138) - Tuesday, 26 August 2008, 03:42 GMT Comment by Galtsev (gdv) - Tuesday, 26 August 2008, 09:15 GMT
For me (Atheros+madwifi) it appear, like iwgetid don't return correct access point id until requested interface is up.
After commenting out this lines in /etc/rc.d/network

#bssid=`iwgetid $1 -ra`
#if [[ "$bssid" = "00:00:00:00:00:00" ]]; then
# printhl "Could not associate $1 - try increasing WIRELESS_TIMEOUT and check network is WEP or has no security"
# return 1
#fi

it start working again.
The same behaviour described in http://bbs.archlinux.org/viewtopic.php?pid=408692#p408692
Comment by Christopher (IMG) - Thursday, 28 August 2008, 07:23 GMT
I would like to add, that this happened to me also using ndiswrapper + windows XP driver v11.(intel pro wireless 3945ABG)
Comment by Jud (judfilm) - Thursday, 04 December 2008, 10:39 GMT
Is this still a problem?
Comment by John (CapnJB) - Monday, 09 March 2009, 17:02 GMT
So I've had a problem with this for a while, but haven't had physical access to my PC that runs Arch. Anyways, upon examining the contents of the following lines in /etc/rc.d/network:

/usr/sbin/iwconfig $iwcfg
[[ -z "$WIRELESS_TIMEOUT" ]] && WIRELESS_TIMEOUT=2
sleep $WIRELESS_TIMEOUT

bssid=`iwgetid $1 -ra`
if [[ "$bssid" = "00:00:00:00:00:00" ]]; then
printhl "Could not associate $1 - try increasing WIRELESS_TIMEOUT and check network is WEP or has no security"
return 1
fi

It appears that these lines configure the device, but don't bring it up. They then test to see if it has associated with an access point, which by my understanding cannot happen unless the device has been brought up. I inserted a line that says "/sbin/ifconfig ${1} up" after the "/usr/sbin/iwconfig" line, and now the script works for me.
Comment by Paolo De Stefani (xpaolo) - Saturday, 14 March 2009, 16:53 GMT
Same problem for me with an rt61 pci wireless card. 'iwgetid wlan0 -ra' always returned '00:00:00:00:00:00' until you bring up the interface with 'ifconfig wlan0 <ip>' that is done after iwgetid.
So i worked around in this way:

bssid=`iwgetid $1 -ra`
bssid="00:1B:11:3F:66:6A" # force the NWID
if [[ "$bssid" = "00:00:00:00:00:00" ]]; then
printhl "Could not associate $1 - try increasing WIRELESS_TIMEOUT and check network is WEP or has no security"
return 1
fi
Comment by Hatem Nassrat (pykler) - Thursday, 19 March 2009, 12:44 GMT
I am not sure if the commenters had the same bug as the original submitter, if so please see:

http://bugs.archlinux.org/task/13299

for a patch to fix this issue.

Thanks.
Comment by Paul Mattal (paul) - Monday, 25 January 2010, 13:41 GMT
What's the status on this? Is it working now?

Loading...