Cannot manage hidden SSID with WEP

Bug #39707 reported by mhanski on 2006-04-15
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Nominated for Hardy by David Ward

Bug Description

Kubuntu/Dapper: My router is setup to use WEP in connection with hidden SSID, which is a pretty common scenario, I guess. I connect to it from knetworkmanager using the "connect to other wireless network" option and filling in my SSID and WEP key. Establishing of the connection works then.

The problem occurs on the next KDE launch:

1. Although knetworkmanager accesses kwallet it doesn't display my once configured SSID on the list of available networks -- it should be there, that's why it has been configured and secured with kwallet

2. If I try to connect to it using "connect to other wireless network", I have to fill in the SSID and WEP key once again -- why, what is the kwallet for?

Nat Tuck (nat-ferrus) wrote :

This problem shows up with unencrypted hidden-SSID networks with the gnome nm-applet interface as well.

Luka Renko (lure) wrote :

Seems like this is common problem of n-m.

Changed in network-manager:
status: Unconfirmed → Confirmed

May be fixed by the attached patch (going into 0ubuntu6), please test the new version and let us know whether it fixes the problem.

Changed in network-manager:
status: Confirmed → Fix Committed
Changed in network-manager:
assignee: nobody → keybuk
status: Fix Committed → Fix Released
mhanski (ma-han2000) wrote :

Scott, could you provide a binary to test? I'm an end user.

mhanski (ma-han2000) wrote :

it seems to behave better now, but please leave this bug open for a couple of days, until I now for sure, the issue is gone

mhanski (ma-han2000) wrote :

there are 2 new issues after the update:
-- knetworkmanager produces every 1-2 minutes a message that the new wireless network has been detected (it's my hidden WEP network)

-- another existing open wireless network won't be detected anymore, but I still can connect to it using the "connect to other network" option.

mhanski (ma-han2000) wrote :

Scott, after having observed it for a few days, I can say, it generally detects my hidden WEP network on KDE launch. There is still a smaller issue which I don't consider very acute:

-- if I connect to another open WLAN network, my hidden SSID will disappear from the knetworkmanager list after a while, although I'm 3 meters away from my WLAN router.

-- the same will happen the other way round: if I connect to my hidden SSID, the other open network will disappear from the list, althoug it's obviously still there

MHouse (mdhouse) wrote :

Same problem here using WPA (Personal) after installing Dapper Flight 7 and NetworkManager 0ubuntu7. Scott, am I mistaken, or does the fix no longer work in v7? I have to say, though, that this is the first time I've been able to get WPA to work in Ubuntu, which makes me very happy.

i also have to manually enter my passphrase and encryption information everytime i want to connect to the hidden access point.

i am now broadcasting my access point and the program works great.

using a dell 1470 mini-pci via ndiswrapper with the bcmwl5 driver.

i have a read-me at...

JasonVenkiteswaran (jjvenky) wrote :

to follow up from MHouse at 2006-05-25 22:12:49 UTC

using a stock dapper (6.06) with all updates and network-manager (0.6.2-0ubuntu7) i too continue to have a problem with hidden a ssid.

i can connect to the ssid via the cli:
sudo iwconfig eth1 essid xxx

but if i enter the ssid name into network-manager i am unable to connect to that access point and get an ip. also, the ssid does not remain in the network-manager menu.

I still have to manually enter my password and encryption information every time i want to connect to the hidden access point. I use Edgy i386 on my HP zv5000 laptop with ndiswrapper 1.39 compiled from source (not Ubuntu package that came with Edgy) and Network Manager 0.6.3 (Edgy package). With wireless AP that broadcast their SSID everything works fine.

yemu (yemu) wrote :

i also have the similar problem in recently updated feisty :-(

Mark Edgington (edgimar) wrote :

Same problem here in Feisty (need to enter the info in each time). I would have thought that I could instead choose "Manual configuration..." from the NetworkManager applet, but doing so seems to behave differently than "Connect to other wireless network...". When I try to configure the network with a manual configuration, the ESSID is not set (is set to none/any). On the other hand, when I type in via "Connect to other wireless network...", the ESSID is properly set, and the connection is established.

gkvas (gernot-kvas-at) wrote :

Ubuntu Feisty:

For hidden SSIDs, I have to connect to the network manually using "Connect to other wireless network". Wouldn't it be clever the network manager would allow to manage all networks, even those with hidden SSIDs? Simply store a list of all networks the user has entered and let the network manager try until it finds the right one (or none for that matter).

Jason Dolan (jason.t.dolan) wrote :

I have the same problem as gkvas. Running Ubuntu Feisty. I have a hidden SSID and I have to connect to my network manually each time using "Connect to other wireless network". It would be very convenient if I only had to add this SSID once through "Connect to other wireless network", and then every other time automatically connect.

Maybe it doesn't make sense to cache every SSID I ever enter because then the network manager would have to check every SSID in that cache every time it wanted to update the list of available networks. That could be bad news if the cache gets really big. But maybe it could save the top used "manually" entered SSID's. Or you can go windows route and create a "network connection order" list. Where it tries each SSID in that list before it attempts to connect to *just any* available network. Really that is the same idea as the cache idea... but the user is managing the cache (and the cache try order) instead of the system.

Either way, it would be great if the nm was updated to fix this problem.

wiz (wiz) wrote :

I confirm. Have hidden wep wlan and must re-create connection every new session. Ubuntu feisty.

James Martin (jimmymartin) wrote :

I confirm too: also posted at:

Same here: Network-manager 0.6.4-6ubuntu7 (7.04 feisty).

Have tested using two APs, one hidden ESSID and one broadcast.
- Connect to hidden AP
- Switch to offline mode
- Switch to online mode
- Observe hidden AP missing from available networks
- Options -> Show Networks
- Observe hidden AP is visible in the history of trusted networks, just can't
be connected to.

"Connect to other Wireless Network" option and manually entering ESSID and WEP
key enables reconnection to the hidden AP.

This is still happening as of version 0.2~r674918-0ubuntu3 (current Gutsy's version).
I tried removing the knetworkmanagerrc file and the program still keeps "forgetting" the hidden ESSID (even though the passwork and the ESSID name were and still are storaged in kdewallet).

Christiansen (happylinux) wrote :

Can confirm this for the network-manager 0.6.5-0ubuntu7 version (7.10 Gutsy / Kubuntu), using a Netgear PCMCIA adapter with Atheros 5212 chipset.

Dubbelchecked that drivers/hardware/accespoint worked, by creating a WPA_supplicant.conf from the exampel given in /usr/share/doc/wpasupplicant/exampel/WPA_wpa_supplicant and running it with :

sudo wpa_supplicant -Dwext -iath0 -c/MyDir/wpa_supplicant.conf
sudo dhclient

Worked without problems.

What I don't get is, that using the laptops build in Intel 2915abg wifi adapter seem to work with network-manager without any playing around. Should i mention that I completely disabled this adapter in BIOS, working with the Netgear adapter.

wiz (wiz) wrote : Bump

Any chances to get hidden SSIDs remembered in 7.10? Very nasty to set those each time.

David Ward (dpward) wrote :

Ditto...please fix the hidden SSID problem in Gutsy. Georgia Tech's campus uses a hidden SSID and WEP key and we are all suffering from this bug here. I imagine other college campuses may have a similar setup.

Same thing here at Purdue. There is a hidden SSID and every time I connect to the Internet I have to insert the setup parameters. Please do something to fix this in time!

aot2002 (jasonbronson) wrote :
Download full text (9.7 KiB)

Also confirmed here gutsy all updates applied as of today

What the heck is up with this

constantly seeing this in logs

Oct 18 17:52:36 localhost kernel: [ 422.112692] nm-applet[6216]: segfault at ffffffffac050590 rip 00002b0ef26fbf18 rsp 00007fffba6ca3b0 error 4
Oct 18 19:16:06 localhost kernel: [ 316.404772] nm-applet[6287]: segfault at ffffffffac037e90 rip 00002b22d076df18 rsp 00007fffdc6587d0 error 4
Oct 18 20:39:59 localhost kernel: [ 112.037291] nm-applet[5864]: segfault at ffffffffac021c80 rip 00002b447f569f18 rsp 00007fff2d85c290 error 4
Oct 19 20:02:48 localhost kernel: [ 2975.963110] nm-applet[5893]: segfault at ffffffffac01df00 rip 00002ad5112aef18 rsp 00007fff9bb17690 error 4
Oct 22 18:29:55 localhost kernel: [ 429.407035] nm-applet[6657]: segfault at ffffffffac025c00 rip 00002b6a9b03af18 rsp 00007fff11d8c890 error 4


Oct 18 19:14:50 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Oct 18 19:15:42 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Oct 18 19:16:29 localhost kernel: [ 326.309483] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 18 19:16:32 localhost kernel: [ 329.506815] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Oct 18 20:37:14 localhost kernel: [ 38.831841] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 18 20:37:54 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Oct 18 20:40:35 localhost kernel: [ 115.647716] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 18 20:41:15 localhost kernel: [ 118.400256] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Oct 18 20:41:15 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Oct 18 20:41:33 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.nis_domain
Oct 18 20:41:33 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.nis_servers
Oct 18 21:52:03 localhost kernel: [ 46.086815] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 18 22:03:24 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Oct 19 08:18:24 localhost kernel: [ 41.248158] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 19 08:19:55 localhost kernel: [ 113.670598] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Oct 19 08:22:44 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
Oct 19 08:23:08 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.host_name
Oct 19 08:23:08 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.nis_domain
Oct 19 08:23:08 localhost dhcdbd: message...


aot2002 (jasonbronson) wrote :

duplicate bug #124336

wiz (wiz) wrote :

Still does not work with ndiswrapper + dell 6400's broadcom chip.

David Ward (dpward) wrote :

Not fixed for at least ndiswrapper

Changed in network-manager:
status: Fix Released → Incomplete
David Ward (dpward) wrote :

Okay, I've spent some time tracing through the source code for NetworkManager. Some observations:

- The problem seems to have nothing to do with AP_SCAN 1 vs. AP_SCAN 2. I only see only place in the entire NetworkManager source that issues AP_SCAN at all (supplicant_send_network_config()), but this is not called before the user resorts to forcing a connection to a specific hidden network.
- In nm_dbus_get_network_data_cb(), all of my stored hidden networks are iterated through, so they at least are being stored somewhere between NetworkManager restarts.
- In nm_device_802_11_wireless_get_best_ap(), ap_list seems to be empty -- it doesn't iterate through the while loop even once, in the presence of the same hidden access point connected to previously.

So without knowing much about how NetworkManager works, and without having more time to sit down and study it, I suspect that one of the following is probably true:
- The allowed hidden networks are being stored incorrectly. After NetworkManager is restarted, the incorrectly stored parameters for the allowed hidden network do not match the actual network parameters, so a connection is not made.
- Stored networks are not being added to the ap_list used in nm_device_802_11_wireless_get_best_ap() if they are not visible. What happens in between nm_dbus_get_network_data_cb() and nm_device_802_11_wireless_get_best_ap() that filters them out()?

Hope that helps...

David Ward (dpward) wrote :

Can this bug please be tagged with qa-hardy-list? Do I need permission from someone to do that? This bug has been around for a very long time...

Changed in network-manager:
status: New → Incomplete
wiz (wiz) wrote :

Looks like this bug still bites only ndiswrapper users. I've switched for 'native' bcm43xx module and it catches my hidden network.

've just tried to connect to the university wireless here at Purdue which uses a hidden ESSID (WPA protection) with the native bcm43xx module and it still doesn't connect automatically. It actually works worse than the ndiswrapper+broadcom windows driver that I currently use.

Martin Pool (mbp) wrote :

This was working for me in gutsy (with iwl3945), but has regressed in Hardy. I now have to type the essid every time I connect.

Changed in network-manager:
assignee: keybuk → nobody
Alexander Sack (asac) wrote :

Martin, does it work for you again in hardy with 0.6.6~rc2-0ubuntu3++ ?

kieran (daralantarial) wrote :

hidden ssid / wpa was working for me with bcm43xx, until the update to 0.6.6~rc2-0ubuntu3. now it doesnt work.

Alexander Sack (asac) wrote :

kieran, could you please open a new bug with a title "[bcm43xx] doesn't connect to hidden SSID" and attach your complete /var/log/syslog (taken after a failed connect attempt to hidden network). Thanks.

 - Alexander

Alexander Sack (asac) wrote :

Martin, your iwlwifi regression is tracked in bug #200950

Alexander Sack (asac) wrote :

kieran, forgot to mention. if you are using ndiswrapper, please use "[ndiswrapper] doesn't ..." as the bug summary instead - obviously.

 - Alexander

Alexander Sack (asac) wrote :

this should be fixed now. in 0.6.6-0ubuntu5. if you still have issues with hidden SSIDs, please file a chipset specific bug about it.

Changed in network-manager:
status: Incomplete → Fix Released

Running the above build in Hardy Heron with Thinkpad T61 Intel Pro 3945. I either have to click 'connect to other wireless network' and enter my ssid and password or if I right click and edit wireless networks, my manager pops up and when I click on it, the keyring pops up. I enter my password, close it, and it starts connecting.
Is there someway to force the keyring to ask me for the info (or not even ask me) so it will just find it and connect?

JoSch (j-schauer) wrote :

you say it's fixed? am i doing something wrong?
i'm running hardy on two laptops (one dell d830 and one thinkpad t61) and on both i still have to reenter the essid and the network key on each reboot.

I think I remember reading that when one uninstalls Network Manager and WICD (?) instead, the SSID problem goes away. (I haven't tried this yet.) It may be a specific problem with Network Manager.
Let me know if anyone has success with this method.

Kevin Hunter (hunteke) wrote :

I use stock (Gnome) Hardy. I have this problem as well. It seems to connect on it's own if I wait long enough, but I needs me internet, so I don't do that often.

I haven't tried uninstalling Network Manager.

I'm not likely to install WICD as it's not in the Ubuntu repos as far as I can tell.

Kevin Hunter (hunteke) wrote :

Hmm, so I just uninstalled both network-manager, and network-manager-gnome via synaptic. I used the "Mark for Complete Removal" option. I rebooted to see what happens from a "fresh start". First time it seemed to work, almost immediately. Cool.

If another end-user wants to try this, here's how to fix your internet connection from the command line. (I don't know how to do this for encrypted network connections, so keep in mind this for unencrypted connections.)

Prior to uninstalling network-manager*, you need to collect the ESSID (name) of your wireless network, and your wireless device (card):

$ iwconfig
  # find the device name, and the associated with the network.
  # Note the ESSID field of your network.
  # The device associated with the ESSID is what you want.
  # The device name will end in a '0'. Common names: eth0, eth1, wlan0

Uninstall network-manager* utilities via System->Administration->Synaptic Package Manager. First, click the Reload button (to be sure you have the most-recent knowledge of the repositories.) Then, click the search button and search for 'network-manager'. Select your installed packages and right-click on them. I suggest the "Complete Removal" option. Click apply.

Then, to get your network back, so you can reinstall those same packages:

$ sudo iwconfig <device_name> essid <network_name>
  # My command was 'sudo iwconfig wlan0 essid YosemiteW'
$ sudo dhclient <device_name>
  # My command was 'sudo dhclient wlan0'

Felipe Balbi (felipebalbi) wrote :

I can still see this on hardy.

Can't connect at all. I had to attach another wifi router since I don't have to the dsl router admin page from my internet provider, they claim that hiding the ESSID is better, as if :-p

Hiding ESSID just opens opportunity for men-in-the-middle attacks, but this is another discussion.

Anyways, any plans to fix this one ?

Changed in network-manager:
status: Incomplete → Invalid
Changed in network-manager:
importance: Unknown → Medium
status: Invalid → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.