Bug 214852 - on boot ipw2200 sometimes is unable to scan properly
Summary: on boot ipw2200 sometimes is unable to scan properly
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-09 18:55 UTC by Zack Cerza
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-14 18:59:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Zack Cerza 2006-11-09 18:55:16 UTC
Description of problem:
Sometimes (possibly even every time) I boot, my ipw2200 associates with a random
AP and as a result is somehow unable to scan properly.

Version-Release number of selected component (if applicable):

Additional info:
# iwconfig eth1
eth1      IEEE 802.11b  ESSID:"linksys"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:0C:41:9B:6B:0A   
          Bit Rate:11 Mb/s   Tx-Power=20 dBm   Sensitivity=8/0  
          Retry limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=70/100  Signal level=-58 dBm  Noise level=-89 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:6

# iwlist eth1 scan
eth1      Scan completed :
          Cell 01 - Address: 00:0C:41:9B:6B:0A
                    Protocol:IEEE 802.11b
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Quality=68/100  Signal level=-59 dBm  
                    Extra: Last beacon: 1936ms ago

# iwconfig eth1 essid z
# iwlist eth1 scan
<20+ APs are shown>

Comment 2 John W. Linville 2006-11-16 18:56:57 UTC
Where is the error here?  Using an ESSID less generic than "linksys" might be 
helpful to avoid associating with the wrong AP...

Comment 3 John W. Linville 2006-11-16 18:59:53 UTC
Hmmm...now I think I see what you are saying...so when ESSID is "linksys", you 
only see one AP?  But changing it to something else, you see multiple APs?

Comment 4 Zack Cerza 2006-11-16 19:33:51 UTC
Pretty much, yeah. The adaptor comes up associated with 'linksys' or some other
open AP, and as a result seems unable to scan for others. If I change it to
another one, somehow it seems to be able to get at least one proper scan off.

It should probably come up unassociated until I or NetworkManager tell it to

Comment 5 Chuyee 2006-11-30 03:31:03 UTC
Yes, if an STA is associated, it should have relative shorter time to hop to
other channels for scan. I see your "linksys" AP is on channel 6. What channels
are the APs on? If "some other open APs" are on the similar channels, that could
explain the problem.

Comment 6 Zack Cerza 2006-11-30 22:57:45 UTC
There is one AP on each channel from 1-16. Mine's on 1 and the connection is
always great.

Comment 7 Chuyee 2006-12-01 02:00:18 UTC
Please provide detailed info. Which one is yours? Can you attach the scan result
for all the APs (when STA is not associated). Scan result when STA is associated
with each AP.

Comment 8 Zack Cerza 2006-12-12 17:07:20 UTC
What's an STA?

'linksys' is not my AP, and I've never manually connected to it or any other AP
with that name. The adaptor simply decides to associate with it sometimes on
boot. My AP at is 'z'. I will try to get you a scan tonight when the adaptor is
associated with no AP, and one when it is associated with my AP ('z'), but I
can't associate with the rest as they are secured and I don't own them. Except
for 'linksys' that is.

Comment 9 Chuyee 2006-12-14 02:35:44 UTC
STA means station, it is used in IEEE 802.11 spec quite a lot.

If you don't want the card to make a guess for which AP to associate unless you
tell it manually, just load the module with "modprobe ipw2200 associate=0"

Comment 10 John W. Linville 2006-12-14 16:13:43 UTC
Zack, does that resolve the issue for you?

Comment 11 Zack Cerza 2006-12-14 16:41:17 UTC
If we were to make that the default, it might resolve it... but for now it's a
nice workaround :)

Comment 12 John W. Linville 2006-12-14 18:59:31 UTC
That has been the default behavior a while, and your situation is the first 
problem I've heard with it that way.  I don't see much incentive to change it, 
unless you can make the case upstream.

With that in mind, I'm going to close this as WONTFIX.  At least you have a 
work-around. :-)

Comment 13 Zack Cerza 2006-12-14 19:41:43 UTC
For the record, at least one Fedora user has experienced the problem, but
neglected to file a report:

Here's a post to networkmanager-list detailing the problem:

Comment 14 John W. Linville 2006-12-18 13:36:53 UTC
Zhu Yi, any thoughts on making "associate=0" the default?

Comment 15 Chris Adams 2006-12-18 19:02:48 UTC
I see the same problem at my house (except mine defaults to some neighbor's
"MSHOME" AP).  If I manually set the essid, it finds my network.  I will try the
"associate=0" work-around to see if that helps tonight.

Comment 16 Chuyee 2006-12-20 05:52:53 UTC
Hi John,

You can add "associate=0" as a modprobe option in Redhat releases. If you want
to change the driver, I'd suggest to send the patch to netdev/lkml and explain
why it is the right thing. In case it doesn't break someone else's usage. I'm OK
with both.

Comment 17 John W. Linville 2006-12-20 14:56:05 UTC
Zhu Yi,

Yes, I am familiar w/ the kernel patch proposal process... :-)  I was more 
interested in why you think the default associate behaviour is correct 
(presuming that you do).

Comment 18 Chuyee 2006-12-21 02:38:18 UTC
The option helps some users that don't configure anything for the wireless. And
they will have a better chance to find the wireless "just work". I'm OK with
changing the default value. Just to make sure it won't block other user's usage.

Comment 19 Chris Adams 2006-12-22 02:26:50 UTC
With "associate=0", I get worse results.  Instead of latching on to an open
wireless network, the scan results come and go.  If I run "iwlist eth1 scanning"
repeatedly, I see networks come and go quickly; the only result I get twice in a
row is "No scan results" which comes up most of the time.  Because of this,
NetworkManager is unable to find any networks to connect to (it only lists the
wired network).

If I remove that option from modprobe.conf, ifconfig eth1 down && modprobe -r
ipw2200, it goes back to working (NM immediately causes the module to be
reloaded and it immediately finds networks).  On a clean reboot, it latches back
on to some neighbor's wireless LAN, which seems to block scanning (although
today it does scan and find my wireless LAN after a minute).

This is with FC6 kernel 2.6.18-1.2849.fc6 and an Intel 2915ABG.

As for auto-associating making it "just work"; you still have to configure the
interface with IP information or run DHCP.  I don't think other wireless NICs do
this in Linux, so I don't think it is useful (especially if it blocks scanning
and association with configured networks).

Comment 20 John W. Linville 2007-01-03 15:40:41 UTC
Chris, I'm not sure I understand what you are advocating.  The beginning of 
your comment says that associate=0 is worse, but the end seems to indicate 
that you don't like associate=1 either...?

Comment 21 Chris Adams 2007-01-08 02:57:19 UTC
My opinion would be that wireless NICs shouldn't auto-associate.  This is
especially true for the ipw2200 since it seems to interfere with scanning for
available networks (if I am in an area with an open network, no other networks
are found until I "iwconfig eth1 xyzzy").

However, when I test associate=0, I get worse results.  "iwlist eth1 scanning"
shows networks coming and going rapidly (with "No scan results" sometimes), and
NM never sees anything.  Again, if I "iwconfig eth1 xyzzy", it seems to clear up.

Comment 22 Chuyee 2007-01-08 03:13:39 UTC
So the problem is: "some networks are not found even if module is loaded with
associate=0", right?

Comment 23 Chris Adams 2007-01-11 15:08:53 UTC
Yes, that is correct.  If I boot with associate=0 in an area with only encrypted
networks (e.g. where it shouldn't make a difference), I still have problems. 
Watching "iwlist eth1 scanning", I see networks come and go rapidly, half the
time getting "No scan results".  Network Manager doesn't ever list any networks
to which I can connect.

If I comment out associate=0 and power cycle, NM finds a network as soon as I
log in and connects.

Comment 24 Chuyee 2007-01-12 01:18:28 UTC
If you comment out "associate=0" and reboot, do you provide the key to make it
connect? Before you set the key, does "iwlist scan" show any networks?

Comment 25 Chris Adams 2007-01-12 19:22:55 UTC
I am using Network Manager, and it asks as soon as I log in for the password to
the keyring.  I hit Deny on that, and NM asked for the network key.  I hit
cancel, and do "iwlist eth1 scanning", and it lists the networks I expect to see
(all with security of some type).  If I keep watching, the list doesn't change
except for fluctuations in the signal level.  No network come or go, and I never
get "No scan results".

It would seem to me that "associate=0" has some additional side affects.

Comment 26 Chuyee 2007-01-30 01:05:31 UTC
I don't see any side affects. You can list the AP, but since the AP is
encrypted, you cannot associate with it without providing a key. What's your
expected behavior?

Comment 27 Chris Adams 2007-01-30 01:12:18 UTC
Please read what I have said: if I set "associate=0", I cannot reliably list
APs.  "iwlist eth1 scanning" shows APs coming and going, and NetworkManager
never sees them.

Comment 28 Chuyee 2007-01-30 02:45:27 UTC
OK. You need to be root to scan for new APs. This is the requirement by
wireless-tools. Otherwise you just read the buffered results.

When "associate=0" is provided, the driver doesn't do scan at background. So
user has to run "iwlist scan" (or other applications thru wext) from time to
time to get the latest AP list and prevent them from aging out.

Comment 29 Chris Adams 2007-01-30 02:54:27 UTC
NetworkManager runs as root and it is unable to find any APs to associate with
when I use "associate=0".

Comment 30 Chuyee 2007-01-30 03:34:48 UTC
Don't know how is NetworkManager implemented. Just try sudo before iwlist scan.
Did it list your networks?

Note You need to log in before you can comment on or make changes to this bug.