Where is the error here?  Using an ESSID less generic than "linksys" might be 
helpful to avoid associating with the wrong AP...

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?

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
associate.

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.

There is one AP on each channel from 1-16. Mine's on 1 and the connection is
always great.

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.

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.

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"

Zack, does that resolve the issue for you?

If we were to make that the default, it might resolve it... but for now it's a
nice workaround :)

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. :-)

For the record, at least one Fedora user has experienced the problem, but
neglected to file a report:
http://blogs.gurulabs.com/dax/archives/2006/04/keeping_your_in.html

Here's a post to networkmanager-list detailing the problem:
http://mail.gnome.org/archives/networkmanager-list/2006-July/msg00090.html

Zhu Yi, any thoughts on making "associate=0" the default?

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.

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.

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).

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.

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).

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...?

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.

So the problem is: "some networks are not found even if module is loaded with
associate=0", right?

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.

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?

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.

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?

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.

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.

NetworkManager runs as root and it is unable to find any APs to associate with
when I use "associate=0".

Don't know how is NetworkManager implemented. Just try sudo before iwlist scan.
Did it list your networks?