Bug 164080 - Can't connect to non-broadcast ESSID
Summary: Can't connect to non-broadcast ESSID
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-24 12:01 UTC by Matthew Saltzman
Modified: 2008-02-12 03:07 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2008-02-12 03:07:27 UTC

Attachments (Terms of Use)
Connect to Other Network patch (3.73 KB, patch)
2005-07-27 03:44 UTC, Bill Moss
no flags Details | Diff

Description Matthew Saltzman 2005-07-24 12:01:14 UTC
Description of problem:
When connecting to get NM to connect to a WAP with a hidden ESSID, NM either
won't connect at all or will start to connect but cycles forever.

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

How reproducible:
Almost always.

Steps to Reproduce:
1. Log in in presence of a WAP with hidden ESSID.
2. Select "connect to other wireless network".
3. Enter ESSID in "wireless netowrk" field.  Enter key if necessary.
Actual results:
Panel icon shows no connection forever or starts to sweep and stays in sweep
mode forever.  No connection made.

Expected results:
Panel icon changes to signal strength meter.  Connection made.

Additional info:

This is an IBM Thinkpad T41 with Cisco Airo 350 miniPCI card.  I see similar
symptoms with a Dell Latitude C640 with Orinoco card.  Using
kernel-2.6.12-1.1398_FC4 (so should have up-to-date Airo driver).

Comment 1 Bill Moss 2005-07-25 19:55:03 UTC
Some experiments to test the scan capabilities of the airo driver in a wireless
network with hidden ESSID's and to test NM with this driver.

Experiment one

T42, kernel-2.6.12-1.1398_FC4, Intel Pro 2200 BG, Cisco 352 wireless adapter,
firmware 5.60.17 (latest)
This kernel comes with a version of the airo driver containing Dan Williams'
quality patches.
Campus wireless network of Cisco AP's with hidden ESSID's.

uninstall: NM, ieee80211-1.0.3, ipw2200-1.0.6, remove network config scripts,
remove network modprobe.conf entries, delete kudzu service, delete network service

cold reboot: iwconfig shows wireless device eth1 and a virtual clone wifi0 which
is a Cisco feature likely created by udev. No configuration on the card.

iwlist eth1 scan produces two cells, one in my office building and one in the
adjoining building. The essid is shown as "". Quality is shown.

configure the 352 card
iwconfig eth1 key xxxxxxxxxxxxxxxxxxxxxxxxxx
iwconfig eth1 essid cuairnet
iwconfig eth1 commit
dhclient eth1

dhclient complains about the virtual device in syslog
dhclient: wifi0: unknown hardware address type 801

Conclusion: the airo driver and firmware and produce a scan with hidden AP's.

Experiment Two

T41, kernel-2.6.12-1.1398_FC4, Cisco MPI350 wireless adapter, firmware 5.41.00
This kernel comes with a version of the airo driver containing Dan Williams'
quality patches.
Campus wireless network of Cisco AP's with hidden ESSID's.

Repeated Experiment One. Same result.

Experiment Three
T42, kernel-2.6.12-1.1398_FC4, Intel Pro 2200 BG, Cisco 352 wireless adapter,
firmware 5.60.17 (latest)
This kernel comes with a version of the airo driver containing Dan Williams'
quality patches.
Campus wireless network of Cisco AP's with hidden ESSID's.

uninstall: ieee80211-1.0.3, ipw2200-1.0.6, remove network config scripts, remove
network modprobe.conf entries, delete kudzu service, delete network service

reinstall NM-HEAD 1.432

NM test1: reboot and login as user with wireless network data already configured
in gconf.
Switch from wired to wireless multiple times; created vpnc connections multiple
Everything works which I assume means that NM must have a non-empty scan list.

NM test2: reboot and login as a user with empty gconf networking settings.
Use the NM 'Connect to Other Wireless Networks ...' . Enter ESSID cuairnet and
WEP key
No connection made.
In about 15 seconds NM puts up Passphrase dialog box that asks for a WEP key for
nm-applet icon disappears but nm-applet is still running.
Syslog: NetworkManager: nm_ap_set_auth_method: assertion `ap != NULL' failed.
gconf: shows only the essid cuairnet and the auth_method.

Comment 2 Bill Moss 2005-07-26 03:08:40 UTC
Matt Saltzman repeat Experiment Two in Comment #1 at his home. Matt reported:

OK So I turned off the SSID at home, and I booted with no network, as we did. 
The wireless card ended up at eth1.

On my Netgear WAP at home, hiding the SSID results in a failed scan

    eth1  Failed to read scan data : No data available.

Unhiding it results in a successful scan.

So it apparently *is* some bloody Cisco proprietary thing, I guess.

Here is my [Bill Moss] conclusion concerning Cisco wireless adapters and NM.
Intel Pro 2200 BG can be purchase on the Web for $31.  

Comment 3 Matthew Saltzman 2005-07-26 22:10:15 UTC
Regardless of the brokenness of the Airo card, one should at least be able to
force a connection to a hidden ESSID if one knows it's name.  The fact that this
doesn't work is a regression from the version in FC3.

That is, I used to be able to select Connect to Other, enter the ESSID, and
connect.  Now I can't with the Netgear router at home.

Comment 4 Bill Moss 2005-07-27 00:24:59 UTC
When the keyring stuff was added to NM some bugs got introduced. I have found
and fixed three bugs so far that all had to do with the key_type not being
handled correctly. Now I can login and use 'Connect ... ' and get a connection.
However, keyring is not written and GConf data is incomplete. If I click on the
Progress bar, then I enter the WEP key again followed by the keyring key. Now
keyring and GConf are written correctly. So a little more to fix. 

The files patched so far are NetworkManagerAP.c, nm-dbus-nm.c,

Comment 5 Dan Williams 2005-07-27 03:23:37 UTC
There are also a few fixes needed to HEAD for 'const' stuff.  A previous patch
had added 'const' to some variables passed to dbus_message_get_args(), this is
incorrect and compiling NM with -O2 produces incorrect behavior.  The correct
solution is to remove 'const' from before variables that are passed to

This bit me when trying to connect using "Other wireless network" because it did
not pass the key type correctly from the applet -> NM, like you say.

Comment 6 Bill Moss 2005-07-27 03:44:16 UTC
Created attachment 117181 [details]
Connect to Other Network patch

Comment 7 Bill Moss 2005-07-27 03:47:30 UTC
I have looked into the problems Matt Saltzman had connecting his
T41/airo/kernel-2.6.12-1.1398_FC4 to the hidden network (Cisco AP's) on campus
and his optionally hidden network at his home (Netgear AP) using NM. Two
unrelated issues had to be separated before I could see what was going on.

1. The current airo driver includes your quality patch. With either of the Cisco
firmwares 5.41.00 or 5.60.17, scans will contain hidden Cisco AP's but not
hidden Netgear AP's. The simple solution is to broadcast at home as is now
recommended by Cisco.

2. I had not used the 'Connect to Other Wireless Network ...' in a while. Today,
I discovered that it is broken. I tested with ipw2200 and airo drivers. The
attached patch file (connect.patch) patches a few lines in 5 source files. The
patches for the two files in src are essential. The other three are clean up.
When I turned on debugging, the problem was obvious. The 'Connect ...' dialog
was not processing the key_type correctly so the key_type was stuck at its
initial value of -1 (shouldn't the initial value be 0 representing the

An observation. The new keyring code is only included in the Passphrase dialog.
So there now is an extra step to use the  'Connect to Other Wireless Network
...' dialog to enter GConf and keyring data for a hidden, encrypted network.

Step (i) Use the 'Connect to Other Wireless Network ...' dialog to enter the
hidden essid and the WEP key. A connection is made. GConf shows that only the
address, essid, and timestamp have been recorded. No keyring dialog takes place.

Step (ii) Click on the progress bar to start the Passphrase dialog, then enter
the WEP key again. GConf is now fully populated with auth_method and key_type.
Also, a keyring dialog comes up so that you can set a default keyring password
or else enter a previously defined password.

Comment 8 Dan Williams 2005-07-27 06:38:28 UTC
Patch committed to CVS.

We need to think about the Other Wireless Network keyring interaction, because
the idea here is that you only get stuff written to GConf/keyring if the
connection is successful.  So we can't necessarily write it to gconf/keyring
from the other networks dialog.  True to form,
gnome/applets/other-networks-dialog.c doesn't write any gconf keys (unless I'm
missing something in a quick look).

But yes, the behavior of this needs to get fixed so that the correct key gets
put into the keyring upon success.  Shouldn't be hard.

Comment 9 Matthew Saltzman 2005-07-27 11:04:19 UTC
Also, having to type the WEP key a second time seems to be unnecessarily kludgy
(and error prone).  Once you've successfully connected, you might need to enter
the keyring password, but the key you just used to connect should be the one
that is stored.

Comment 10 Bill Moss 2005-07-27 14:51:03 UTC
Using the Other Wireless Network dialog does cause the AP address, essid, and
timestamp to be written to GConf but does not put the key in the default
keyring. Consequently, when you go back and click on the progress bar, your are
switched to the Passphrase dialog; i.e. all you are asked for is the key because
NM already has the essid. After that GConf and keyring are fully updated.

I agree with all said above. Not sure how to fix it. Will look at it some more
if time permits. 

BTW, the airo and ipw2200 quality numbers are quite a bit different. I can use
either with my laptop by plugging in the Cisco card before booting. NM shows
both cards but just configures one of them. There are two progress bars and two
labels (Wireless Networks (Cisco Systems 350 Series LAN Adapter & Wireless
Networks (Intel Corporation Pro/Wireless 2200BG) but only the configured one has
the black radio dot. Anyway, if the dust ever settles it would be nice to get
some agreement on quality values. I like the idea of setting 20% to be the
disassociation point under ideal conditions. Then the clear signal level would
fall in the range of 1-10%.

Comment 11 Stefan Becker 2006-09-10 09:48:37 UTC
Is this still valid in FC5? NetworkManager-0.6.4-1.fc5 doesn't have any problems
to connect to non-broadcast ESSID APs and also remembers the settings & password.

BTW: I'm using knetworkmanager, not the GNOME nm-applet.

Comment 12 Matthew Saltzman 2006-09-10 12:07:11 UTC
I (original reporter) gave up on the Cisco card finally and replaced it with an
ipw2200.  There is still some occasional flakiness with connections in certain
circumstances (FC5--usually with updated ieee80211 and ipw2200 drivers or with
Netdev kernels, NM-0.6.4-1.fc5), but it's not clear to me if it's related to
this particular bug or not.

Note, the original issue was Cisco cards being unable to see non-Cisco hidden
SSIDs.  That's not an NM bug.  The rest of the discussion was about making NM
behave reasonably in some failure modes.

Comment 13 Dan Williams 2008-02-12 03:07:27 UTC
Fixed now in F8 and rawhide with the scan capability stuff; that should filter
back to F7 with the update to 0.6.6 when that comes.

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