can't connect to hidden network

Bug #50214 reported by nanophase
210
This bug affects 2 people
Affects Status Importance Assigned to Milestone
NetworkManager
Fix Released
Wishlist
knetworkmanager (Baltix)
Invalid
Undecided
Unassigned
network-manager (Ubuntu)
Fix Released
High
Alexander Sack

Bug Description

Since I installed dapper clean from CD, NM won't connect to my own hidden network., however it did before. The network was even in the list after a few seconds, the new feature of reverse mac scanning in 0.6.2.

Now even if I use "connect to other network" and I enter everything in there, the connection won't be a success. Not hiding the SSID solves the problem immediately, just as manually connecting to the AP with iwconfig eth1 essid <mine> ...

Revision history for this message
nanophase (nanophase) wrote : syslog with increased verbosity

Maybe this helps a bit. I tried my laptop on an other AP just to be sure.
The situation was the following:
WEP2 tkip encrypted AP, not hidden. Connection couldn't be made in any way.

I was able to connect to this one aswell, without any difficulties, before installing dapper clean. I'm not really an NM specialist, but isn't that the wrong driver NM is using (see log). wpa_driver_wext... ? I think driver ipw should be used here (ipw2200 here).

Revision history for this message
Scott Robinson (scott-ubuntu) wrote :

The wext driver is correct. Is this issue still occuring to you, and does it occur in edgy?

Revision history for this message
nanophase (nanophase) wrote :

Confirmed, I just installed latest edgy beta, then upgraded it, and it's the same.
1. WPA / TKIP
2. WPA2 / AES
both result in the same: when ssid is hidden, I can't connect to my AP, if it's not, I can connect in both configurations.

Revision history for this message
Scott Robinson (scott-ubuntu) wrote :

Some additional information would be very helpful. If you can, please attach the results of the following commands:

lshal
ifconfig -a
lspci -v

A brief description of your hardware configuration would be pretty handy too.

Thanks! With this information, your issue will be closer to being resolved.

Revision history for this message
nanophase (nanophase) wrote :
Revision history for this message
nanophase (nanophase) wrote :
Revision history for this message
nanophase (nanophase) wrote :
Revision history for this message
nanophase (nanophase) wrote :
Revision history for this message
nanophase (nanophase) wrote :

It is a HP pavilion zt3000 series laptop, ipw2200.
Let me know if you need anything else.

Revision history for this message
hackel (hackel) wrote :

I would like to confirm this problem in edgy. I'm using a BCM4318 with bcm43xx driver, Ubuntu kernel 2.6.17.10-generic.

If I enable Wireless SSID Broadcast on my router, I'm able to connect to it easily with Network Manager. If I enter the information manually, however, it doesn't work. My router is a WRT54GS v4 running DD-WRT and set to use WPA2 Pre-Shared Key Mixed (reverts to WPA1), TKIP+AES.

My connection also works fine setup in /etc/network/interfaces.

Also, if I use ndiswrapper instead of bcm43xx, I CAN connect to my hidden network with Network Manager. I'm not really sure what this means, since the original bug reporter was using an ipw2200 card and had the same problem.

Changed in network-manager:
status: Unconfirmed → Confirmed
Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

I can confirm this problem on Feisty Herd 4. I'm not able to connect to my ap if it's hidden (i.e. SSID broadcast disabled), but will connect just fine if the ap is NOT hidden.
Hw configuration: Sony Vaio VGN-FS315E, atheros integrated wireless.

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :
Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

The distro is Kubuntu 7.04 Herd 4, NOT Baltix...

Revision history for this message
Arthur Schiwon (blizzz) wrote :

I confirm this problem on IBM Thinkpad T22 with Kubuntu 7.04 Beta, using an PCMCIA Card with an Atheros chipset, router is AVM Fritz!Box Fon WLAN 7050.

Like other reports, it works perfectly when the essid is broadcastet.

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

It seems that this problem is actually caused by wireless-tools version 28 that supports Wireless Extension up to version 20, but ubuntu kernel and wireless drivers are compiled with Wireless Extension v21, which will be completely supported only from the next wireless-tools - v29.
I tried previous K(Ubuntu) versions and everything worked correctly, but iwconfig --version showed that there was no mismatch between Wireless Extensions version and Wireless tools version. (See also bug #91009)

Revision history for this message
André Fettouhi (a-fettouhi) wrote :

Same problem here with my hidden AP and my Inspiron 8200 laptop with a Netgear WAG511 card (/using madwifi). A solution seems to be uninstalling the NM and install Wicd. By the way I'm running Ubuntu 7.04 Beta with all updates installed as of the 12th of April 2007.

Regards

André

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

Thanks for this comment. I'll try this workaround, but I think that connection to a hidden AP should be possible with default packages (i.e. NM/KNM). It's really simple to fix this just by going back to Wireless Extension v20 until Wireless Tools v29 will be released.

Btw, I use 7.04 Beta with all updates as of 12th April 2007, too.

Revision history for this message
Michael (mike984) wrote :

I can firm - I have Atheros based card and Feisty beta with all updates as of today. Cannot connect to Netgear WGT624 router if SSID is hidden. Changing the router to broadcast SSID allows Feisty to connect.

Revision history for this message
David Vinas (dvinas) wrote :

I also have the same problem with my HP Compaq nc6000 laptop, Atheros driver, and using the new Feisty 7.04 release. If I understand what you're saying, Witold, we need to recompile the kernel with Wireless Extension v20 until Wireless Tools v29 is released. Any idea when that release will happen?

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

Hi David,
Yes, You understand correctly. Please find below the answer about availability (this comes from Jean Tourrilhes, maintainer of Wireless Tools)
Personally, I tried to install the v29 pre17 (it is a beta version) and it worked correctly, but I think that it is better to recompile kernel and drivers with Wireless Extensions v20 until a stable new version of WT is released. This is also because we don't have any clue of when it will happen.

pokaż szczegóły
  16.04 (7 dni temu)
On Wed, Apr 11, 2007 at 04:14:03PM +0200, Witold Krakowski wrote:
> Hello,
>
> Is there any timeline for the Wireless Tools v29 availability?

       When I get enough bug reports convincing me it's good to go ;-)

Jean Tourrilhes

Revision history for this message
Nathan Pettigrew (nathanp39) wrote :

I've been having this problem since I started trying FIesty. Disabled hiding the SSID and Network Manager was able to connect. Otherwise, NM would sit at 28% and timeout eventually.
I'm also using the Atheros chipset to connect to a WGT624.
Thanks, Nathan

Revision history for this message
Chris Mangrum (mangrum) wrote :

I have been having what seems to be the same issue. I use MAC filtering and do not broadcast my SSID on my home wireless router. Using xubuntu 6.10 was not a problem, but after reinstalling fresh from the xubuntu 7.04 cd, it initially found the AP and got an IP address during install, but after a reboot I got a link light from the AP but dhclient failed to obtain an IP. I tried dropping and bringing up the interface and multiple DCHP renewals with no success. Only when I turned on ssid broadcasting again from my AP did it work correctly and obtain an IP. I'm using a Netgear wireless card on an older HP laptop.

Chris

Revision history for this message
Sven Hoffmeister (schaumkeks) wrote :

Confirming this for ipw2200 as of Feisty. Since I switched from WEP to WPA+WPA2 on my router, enabling SSID broadcast is the workaround I currently use.

Small workaround that worked for me before figuring this out: After logging in and entering the password for the keyring where the WPA passphrase is stored, I immediately disabled networking in NetworkManager applet (right-click on icon) and reenabled it again. After that procedure the dhclient got a IP address and I was connected.

Revision history for this message
Kaspar Metz (kap) wrote :

Same problem here, on a thinkpad T41 with AR5212 in combination with an apple airport wlan base station (hidden ssid, WPA2). The problem exists here since my update to feisty, everything worked well with dapper.

Thanks
 Kaspar Metz

Revision history for this message
Dima Ryazanov (dima-gmail) wrote :

Same problem here...

If I try to connect the first time, NetworkManager sets the wrong channel (at least, according to iwconfig). If I tell it to connect again, before it times out, it associates with the AP correctly - but still waits, for whatever reason. If I try to connect for the third time, it actually connects.

Revision history for this message
Matthew Carpenter (matt-eisgr) wrote :

Confirmed: Feisty latest, IPW3945.

I didn't have the problem in Edgy, but it's likely because I used manual config of /etc/network/interfaces to setup my own maintained /etc/wpa_supplicant.conf file. Even doing that, at some point I believe I was force to tell iwconfig what the ssid was and then I could connect. ap_scan and ssid_scan settings used to let me connect fine. I thought I was just going nuts and that it didn't work as I thought it once did. Still think I'm nuts, but at least I believe this is not one example. :)

This resolution makes sense. Looking forward to updates fixing this. recompiling kernels is a thing which should stay in my past, when I didn't have as much else to worry about. Maintaining out-of-circulation packages (especially kernels) just doesn't scale or make sense for corporate use.

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

Recompiling the kernel by yourself certainly not, but there are kernel updates every now and then, so these kernels could be recompiled with drivers supported by current stable version of Wireless tools. This does make sense.

Revision history for this message
Matthew Carpenter (matt-eisgr) wrote : Re: [Bug 50214] Re: can't connect to hidden network

On Friday 15 June 2007, Witold Krakowski wrote:
> Recompiling the kernel by yourself certainly not, but there are kernel
> updates every now and then, so these kernels could be recompiled with
> drivers supported by current stable version of Wireless tools. This does
> make sense.

Indeed it does. Do we know what the plans are? Is there something in the
communication stream that needs to occur yet?

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

>>Indeed it does. Do we know what the plans are?
I certainly don't know. I guess the ubuntu kernel team should know more about this.

Is there something in the communication stream that needs to occur yet?
The first thing that should occur, is that somebody from QA should assign an importance level to this bug. Now it is "Undecided", but I think it should be high. I'm not in the QA, so I cannot change this.

The best thing to do for the 7.10 release should be to include the new Wireless Tools version - 29.
However, v29 is not ready yet (please have a look here https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214/comments/20 for my comment about this and for an answer about availability from Wireless Tools maiintainer).

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

Oh well....the ubuntu team is screwing this again...now, if you type "iwconfig --version" you'll get the following:

ituc@Hobson:~$ iwconfig --version
iwconfig Wireless-Tools version 29
          Compatible with Wireless Extension v11 to v21.

Kernel Currently compiled with Wireless Extension v22.

ath0 Recommended Wireless Extension v13 or later,
              Currently compiled with Wireless Extension v22

Somebody please FIX this ! Is it SO DIFFICULT to match kernel Wireless Extension and Wireless Tools versions so they play nice together?? What's wrong with you, people? (this is to everyone on the ubuntu team who might be involved in fixing this really simple bug).

Revision history for this message
Julie Verley (diranda) wrote :

Confirmed in Kubuntu/Xubuntu/Ubuntu Feisty. I upgraded to the Gutsy wireless-tools 29, which doesn't make any difference.

This is an -extremely- important bug and it needs to be addressed, since it seems to have been a problem through several versions of Ubuntu.

In order to make my wireless work at home with our hidden network, I have had to come up with workarounds that don't seem to work consistently, since this problem is inherent in the kernel and wireless-tools. I have uninstalled Network Manager, turned it off and other things, but would prefer to use Network Manager, as it works very well in Debian Etch.

Thanks,
Julie

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

Hi Julie, upgrading only wireless tools won't make difference, because the kernel is recompiled with Wireless Extension version that is not supported by Wireless Tools. This is a simple mismatch and the kernel team can easily solve this by recompiling the kernel. I already did that on my system and it works.

Revision history for this message
Alexander Sack (asac) wrote :

witold, can you please summarize the steps to take so we can set this bug to triaged and finally implement a solution?

Revision history for this message
Alexander Sack (asac) wrote :

taking the lead for now.

Changed in network-manager:
assignee: nobody → asac
Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

Hi Alexander,
Are You asking me for steps necessary to solve the problem?

If so, the answer is simple - you have to compile the kernel with Wireless Extension that is supported by the Wireless Tools used.
Here's a simple example: If we use Wireless Tools v29, which is compatible with Wireless Extensions v11 to v21, then you have to compile the kernel with Wireless Extensions v21.
Right now you see the following:

ituc@Hobson:~$ iwconfig --version
 iwconfig Wireless-Tools version 29
           Compatible with Wireless Extension v11 to v21.
Kernel Currently compiled with Wireless Extension v22.
ath0 Recommended Wireless Extension v13 or later,
               Currently compiled with Wireless Extension v22

It is easy to see that Wireless-Tools version 29 doesn't support Wireless Extension v22. Since v29 is the newest Wireless Tools version, what we have to do is to use Wireless Extensions <= v21 for the kernel.

Revision history for this message
luisalmo (lost180) wrote :

My Wireless-Tools and Extension are compatible with each other:

lost@SILVIA:~$ iwconfig --version
iwconfig Wireless-Tools version 28
          Compatible with Wireless Extension v11 to v20.

Kernel Currently compiled with Wireless Extension v20.

wlan0 Recommend Wireless Extension v18 or later,
          Currently compiled with Wireless Extension v20.

I can connect to my hidden networks (home/work) using NetworkManager by going to "Connect to Other Wireless Network" and manually entering SSID, WPA password, etc. However on reboot, NetworkManager will not auto reconnect to either network, I have to do it manually every time, even though both networks are saved in gconf-editor.

I'm using Ubuntu 6.10, BCM4318 with ndiswrapper driver on an Acer Aspire 3000 laptop.

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

But You CAN connect to a hidden network, and you can because Wireless-Tools and Extension are compatible with each other.

Your problem is quite different and i already seen it somewhere in the forums. What we are talking about here is the incompatible Wireless-Tools and Extensions.

Revision history for this message
aquo (sbauch) wrote :

I further investigated on this bug and can confirm there is a bug. Connecting to a hidden network with the network manager doesn't work on my feisty installation with kernel 2.6.20-16.

As already stated the wireless extensions of the kernel and Wireless Tools don't match.

aquo@cayley:~$ iwconfig --version
iwconfig Wireless-Tools version 28
          Compatible with Wireless Extension v11 to v20.

Kernel Currently compiled with Wireless Extension v21.

ath0 Recommend Wireless Extension v13 or later,
          Currently compiled with Wireless Extension v21.

I tried to resolve the problem by installing unstable wireless tools v29-pre22 on my box. This didn't solve the problem, even if with the upper command wireless extensions of kernel and supported wireless version of wireless tools now match.

This is explainable (same on patched system/unpatched system):

aquo@cayley:~$ ldd /usr/sbin/NetworkManager
        linux-gate.so.1 => (0xffffe000)
...
        libiw.so.28 => /lib/libiw.so.28 (0xb7ee9000)
...
        /lib/ld-linux.so.2 (0xb7f12000)

The NetworkManager is directly linked against libiw from Wireless Tools (for ubuntu this is an extra package libiw28, the source is distributed with wireless tools) and apparently doesn't use the command line tools like iwconfig, but the library interface. It is possible the that code responsible for translating between different versions of Wireless Extension is part of Wireless tools (like iwlist, iwconfig) and not part of the library and that Network Manager is missing the right translations between the versions.

The unstable wireless tools (not yet released) bring libiw.so.29 with them. I didn't try to replace libiw.so.28 by libiw.so.29.

Conclusion: libiw28 doesn't match the kernel 2.6.20-15/16 on feisty.

Connecting with wpa_supplicant and simple WPA-PSK from commandline works without problem, also connecting with broadcasted ESSID and NetworkManager.

It would be nice if Witold Krakowski could comment on how to recompile the kernel with older wireless extension.

Revision history for this message
Witold Krakowski (wkrakowski-gmail) wrote :

>> It would be nice if Witold Krakowski could comment on how to recompile the kernel with older wireless extension.

You're wrong. The right sentence is: "It would be nice if Ubuntu Kernel Team could recompile the damn kernel correctly"

They KNOW how to do that and they should fix this, not me. I'm NOT a member of Ubuntu Kernel Team. Also, it seems they're NOT INTERESTED in solving this issue.

Revision history for this message
aquo (sbauch) wrote :

Is there a configuration option for compiling the kernel and all the modules with a different version of Wireless Extension? How have you done this, you said "This is a simple mismatch and the kernel team can easily solve this by recompiling the kernel. I already did that on my system and it works." I want to do it in the same way. Does it require to patch in an older version of Wireless Extension into the kernel source or is that parameterizable?

After having reviewed lots of code yesterday (libiw, wpa_ctrl of NetworkManager) I am still not convinced this will help, i want to see the fix for the kernel. I also have tried to install a newer upstream version of wpa_supplicant, but this doesn't help either. I also replaced libiw.so.28 by copying libiw.so.29 over it (i have not recompiled NetworkManager against it), nothing broke, but connecting to a hidden network didn't work.

I also found another version mismatch, but this time it's only cosmetics. It is wpa_supplicant #126510

Alexander Sack (asac)
Changed in network-manager:
importance: Undecided → High
Alexander Sack (asac)
Changed in network-manager:
status: Confirmed → In Progress
Changed in network-manager:
status: Unknown → New
Changed in network-manager:
milestone: none → ubuntu-7.10-rc
Alexander Sack (asac)
Changed in network-manager:
status: In Progress → Fix Released
Changed in network-manager:
status: New → Invalid
Changed in network-manager:
status: Fix Released → Incomplete
Alexander Sack (asac)
Changed in network-manager:
milestone: ubuntu-7.10 → ubuntu-8.04-beta
status: Incomplete → Confirmed
Changed in network-manager:
status: Invalid → Confirmed
Changed in network-manager:
status: Confirmed → Fix Released
Changed in knetworkmanager:
status: New → Fix Released
status: Fix Released → Invalid
Alexander Sack (asac)
Changed in network-manager:
milestone: ubuntu-8.04-beta → ubuntu-8.04
129 comments hidden view all 209 comments
Revision history for this message
Christiansen (happylinux) wrote :

The syslog without hidden SSID

Revision history for this message
Christiansen (happylinux) wrote :

The tests with ZyXEL (chipset zd1211rw) seems exact identical with that of Atheros above.

SSID Not Hidden: Connects
SSID Hidden : Do not connect

Executing iwconfig while connecting with NM shows the right ESSID, and doing iwpriv scan do not make the make it connect.

BTW Got the syslog files for both hidden and nonhidden connections attempts if they could be of any interest.

Revision history for this message
sip (pankovs) wrote :

> what is your SSID used? is it a factory default?

No, it's not a factory default, I've changed it in my router setup (I'm not sure that I understand your question completely).

Revision history for this message
Martin Pool (mbp) wrote :

Using network-manager built from this branch (0.6.6-0ubuntu4~test1) on my x61s with iwl3945 and e1000:

Changing my network setup for testing seems to require choosing "edit wireless network" and deleting it. This is somewhat reasonable though it would be good to get a clearer message along the lines of "this network is now unencrypted, are you really sure you want to connect", but that's a separate bug.

I can connect to a public, wpa2 psk network.

I can connect to a private, non-encrypted network, but it seems that I need to choose "connect to other network" every time. Previously, nm seemed to automatically detect hidden networks I had previously used.

However, this version breaks connections to a wired network, which was always working in hardy previously. When I try, I get stuck at one light and the following log.

Revision history for this message
Martin Pool (mbp) wrote : can get wpa2 & hidden; now can't get wired reliably

Here is the log from when it failed for me this morning. I've just tried again and it worked the first time and failed the second time, giving these messages:

Mar 28 14:45:44 lithe kernel: [74974.067369] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Mar 28 14:45:44 lithe kernel: [74974.070019] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Mar 28 14:45:56 lithe kernel: [74986.034541] ADDRCONF(NETDEV_UP): wlan0_rename: link is not ready
Mar 28 14:46:31 lithe dhcdbd: Unrequested down ?:3

I am left with

mbp@lithe% ip r
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.7.160
default dev eth0 scope link metric 1000

Clicking "Wired network" a third time made it work again.

Revision history for this message
Martin Pool (mbp) wrote :

I can't reproduce this problem after rebooting.

Revision history for this message
Alexander Sack (asac) wrote :

i am uploading what we have now. I will close thise catch all bug for now. if you still have issues, please open a new bug for each individual chipset you know about.

title it like [CHIPSET] cannot connect to hidden network.

maybe prod me (asac) on irc so i can bring your bug on track for hardy.

Thanks,
 - Alexander

Changed in network-manager:
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.6.6-0ubuntu4

---------------
network-manager (0.6.6-0ubuntu4) hardy; urgency=low

  * fix hidden networks for chipsets that do not have scan_capa enabled
    driver. (LP: #50214, #200950, #203793, #199679). The following
    behaviour is now implemented:
      * use scan_ssid 1 with AP_SCAN 1 for all scan_capa_ssid drivers
      * use scan_ssid 1 with AP_SCAN 1 for all drivers with buggy
        scan_capa_ssid and buggy ap_scan and explicitly set essid through
        wireless extensions to help driver to find bssids of hidden ssid
          Drivers with buggy scan_capa_ssid: ipw2200
          Drivers with buggy ap_scan 2: iwl3945, iwl4965
      * use AP_SCAN 2 for all other drivers and set essid through wireless
        extensions forcefully.
        - update debian/patches/42b_fix_ap_scan_hidden.patch
    - add debian/patches/42b_fix_ap_scan_hidden.patch
    - update debian/patches/series

 -- Alexander Sack <email address hidden> Fri, 28 Mar 2008 10:38:42 +0100

Changed in network-manager:
status: Fix Committed → Fix Released
Revision history for this message
Luke Hoersten (lukehoersten) wrote :

This problem has been reintroduced in Ubuntu 8.04. NetworkManager does not work for all Ubuntu on the Purdue University campus because of this. I've attached the output of /var/log/messages for three different connection attempts.

Revision history for this message
Gene Caldwell (gene-caldwell) wrote :

Now might not be the best time to bring this up since additions are now closed for hardy, but WiCD does not have this problem....as least for me(tried LinuxMint, wireless worked out of the box on hidden SSID's). I have not been able to figure out to get it to work installing it on my own tho for feisty. can this be added as a backup system to help insure people can connect wirelessly ? just to insure people have an internet capable distro ?

Revision history for this message
Gene Caldwell (gene-caldwell) wrote :

"network-manager (0.6.6-0ubuntu4) hardy; urgency=low"

"Low" ? "urgency=low" ? maybe this is the reason why this problem has existed for 2 years now for so many people ???

Revision history for this message
Alexander Sack (asac) wrote :

Gene, could you test and report?

Revision history for this message
Gene Caldwell (gene-caldwell) wrote :

Alexander,
I am truly sorry, I cannot. The computer I have the problem with is a production machine, not a test machine. Its my Girl Friends work computer, I simply cannot take a work computer out of commission for beta testing as much as I really would like to try to provide you feed back on so this issue can be fixed. Thats the first problem.

The second problem is that I'm totally clueless as to what you need me to do to test your patch, I read every post you guys have made for the last several days and I simply do not know enough about linux to know how to get the patch installed or even know if messed up during the process. I can however install a .deb package...duh, like its something troublesome or complicated :) but as I did not see anyone asking for deb packages from you to try, I have been just hoping that someone with my same chipset will provide you the needed feedback. I'm sorry, I don't know how to do as you ask and feel you are trying at the moment and don't want to interfere with your efforts by asking for special just for me.

I do have another computer I can test with tho that has a different chipset that has the very same hidden SSID problem, however I still have the same problem, I don't know how to install a patch if it is not delivered in a deb package.....

I would love to help and provide feed back ( I love testing things out ) if I only knew how to install your patch. Just so you know, I really did try, I'm not a dummy, I just can't figure out the linux way of doing things, I guess I spent too many years in windows.

production machine: Dell C800 with prism54 wireless pcmcia card does not yet work except for what Dave Ward helped out with several months back, there were still problems with his patch tho. no automatic re-connection etc.

other testable machine I CAN test on has atheros wifi card. but as I said, I know nothing about patches.

Revision history for this message
Steve Langasek (vorlon) wrote :

Gene,

The package that's believed to fix this bug has already been uploaded to the archive, and indeed is already present on the daily liveCD builds present here:

  http://cdimage.ubuntu.com/daily-live/current/

So far I don't believe we have anyone else testing prism54; my understanding is that this is an older and relatively uncommon chipset. While the most recent network-manager changes are believed to *generally* be correct, there's really no way we can guarantee that hardy will work for your particular chipset unless someone in possession of the hardware is able to test it.

Revision history for this message
Gene Caldwell (gene-caldwell) wrote :

Steve and Alexander,

I have no problem at all testing a liveCD on THAT production machine with the Prism54 chipset card. I shall d/L and report later. I should give advance notice that on my last liveCD test 7.10 final on that machine I did not have the problem with connecting to my hidden AP. It only became apparent AFTER I installed it to the HD. That really baffled me as it took several installs to get it to know that I had WPA, and NOT WEP. I know, sounds dumb, but the LiveCD 7.10 final worked flawlessly(even hidden SSID) until I installed, then nothing but WEP was detectable except if I held my breath, turned my head sideways, cough twice while standing on my right leg only, not left leg, then it would install correctly and detect WPA. I have read other reports of this issue so I concluded I did nothing wrong.

I will also test on the other wireless chipset I have for hidden SSID. will report back later. getting your new daily image image now........

IF someone can recommend to me a replacement PCMCIA card that is guaranteed to work I would be willing to get past this problem and buy that since its so rare....however I did not know that was the case. but it seems like a lot of work to support just one person.

Revision history for this message
Matt Palmer (mattpalms) wrote : Re: [Bug 50214] Re: can't connect to hidden network
  • unnamed Edit (4.0 KiB, text/html; charset=ISO-8859-1)
Download full text (3.3 KiB)

Alexander,

you are not alone! I happily submitted a bug for the ipw2200 chipset having
used the beta cd, but didn't have the first clue about building branches,
patches or whatever. I actually work in software development - I'm just
not familiar with these tools or procedures, and I don't have endless hours
to spend figuring it out. I spent about an hour trying to find help, but
could find no documentation on what to do at all.

Some concise newbie help for technically minded beta testers would be very
useful.

Regards,

Matt

On Sat, Mar 29, 2008 at 7:04 PM, Gene Caldwell <email address hidden>
wrote:

> Alexander,
> I am truly sorry, I cannot. The computer I have the problem with is a
> production machine, not a test machine. Its my Girl Friends work computer, I
> simply cannot take a work computer out of commission for beta testing as
> much as I really would like to try to provide you feed back on so this issue
> can be fixed. Thats the first problem.
>
> The second problem is that I'm totally clueless as to what you need me
> to do to test your patch, I read every post you guys have made for the
> last several days and I simply do not know enough about linux to know
> how to get the patch installed or even know if messed up during the
> process. I can however install a .deb package...duh, like its something
> troublesome or complicated :) but as I did not see anyone asking for deb
> packages from you to try, I have been just hoping that someone with my
> same chipset will provide you the needed feedback. I'm sorry, I don't
> know how to do as you ask and feel you are trying at the moment and
> don't want to interfere with your efforts by asking for special just for
> me.
>
> I do have another computer I can test with tho that has a different
> chipset that has the very same hidden SSID problem, however I still have
> the same problem, I don't know how to install a patch if it is not
> delivered in a deb package.....
>
> I would love to help and provide feed back ( I love testing things out )
> if I only knew how to install your patch. Just so you know, I really
> did try, I'm not a dummy, I just can't figure out the linux way of doing
> things, I guess I spent too many years in windows.
>
> production machine: Dell C800 with prism54 wireless pcmcia card does not
> yet work except for what Dave Ward helped out with several months back,
> there were still problems with his patch tho. no automatic re-connection
> etc.
>
> other testable machine I CAN test on has atheros wifi card. but as I
> said, I know nothing about patches.
>
> --
> can't connect to hidden network
> https://bugs.launchpad.net/bugs/50214
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in NetworkManager: Fix Released
> Status in Source Package "network-manager" in Ubuntu: Fix Released
> Status in Source Package "knetworkmanager" in Baltix GNU/Linux: Invalid
>
> Bug description:
> Since I installed dapper clean from CD, NM won't connect to my own hidden
> network., however it did before. The network was even in the list after a
> few seconds, the new feature of reverse mac scanning in 0.6.2.
>
> Now even if I use...

Read more...

Revision history for this message
Gene Caldwell (gene-caldwell) wrote :

Matt,
Correct me if I'm wrong here but I think you meant your address to me, not to Alexander. Alexander is the guy who is providing the patches and is trying to get this bug fixed for all of us, he's the guy who knows how to do all this stuff. It's funny tho, you seem to have the very same background as I do. however I am no longer able to work in my chosen profession. I choose to try to stay involved however I can. And like you, I have found it very difficult to gain enough of the requested talent that is needed to provide feed back to these guys on the patches et-al. locating the much needed details or how-to's has also been been hopeless for me. I continue trying tho much like your self. its been over 4 years now for me since I started using linux and I still consider myself a newbie. lol, I guess since I cannot patch my own system shows I still am a newbie.
Gene

Revision history for this message
Matt Palmer (mattpalms) wrote :
  • unnamed Edit (3.0 KiB, text/html; charset=ISO-8859-1)

Gene,

oops, yes, I meant the reply to you! I've also been using linux for 4
years, and I know enough to figure things out - I don't need step-by-step
instructions (although they certainly help!). Having said that, I use
Ubuntu precisely because it doesn't force me to become an O/S expert - but
I'm still free to tinker with the bits I find interesting.

I'll continue to try out betas and submit bugs related to my hardware - it's
in my interest after all! I would like to be able to build and test patches
running from the beta cd, not installed, as I also don't have a spare
testing machine or unlimited bandwidth. I don't know if that's even
possible.

cheers,

Matt

On Sun, Mar 30, 2008 at 4:10 AM, Gene Caldwell <email address hidden>
wrote:

> Matt,
> Correct me if I'm wrong here but I think you meant your address to me, not
> to Alexander. Alexander is the guy who is providing the patches and is
> trying to get this bug fixed for all of us, he's the guy who knows how to do
> all this stuff. It's funny tho, you seem to have the very same background
> as I do. however I am no longer able to work in my chosen profession. I
> choose to try to stay involved however I can. And like you, I have found it
> very difficult to gain enough of the requested talent that is needed to
> provide feed back to these guys on the patches et-al. locating the much
> needed details or how-to's has also been been hopeless for me. I continue
> trying tho much like your self. its been over 4 years now for me since I
> started using linux and I still consider myself a newbie. lol, I guess since
> I cannot patch my own system shows I still am a newbie.
> Gene
>
> --
> can't connect to hidden network
> https://bugs.launchpad.net/bugs/50214
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in NetworkManager: Fix Released
> Status in Source Package "network-manager" in Ubuntu: Fix Released
> Status in Source Package "knetworkmanager" in Baltix GNU/Linux: Invalid
>
> Bug description:
> Since I installed dapper clean from CD, NM won't connect to my own hidden
> network., however it did before. The network was even in the list after a
> few seconds, the new feature of reverse mac scanning in 0.6.2.
>
> Now even if I use "connect to other network" and I enter everything in
> there, the connection won't be a success. Not hiding the SSID solves the
> problem immediately, just as manually connecting to the AP with iwconfig
> eth1 essid <mine> ...
>

Revision history for this message
Gene Caldwell (gene-caldwell) wrote :

Steve and Alexander,
Here are test results for 2 different wifi chipsets:

PRISM54:
The first was my bigger wish list fix: Prism54 SUCCESS using LiveCD
tested hiding SSID while connected to exposed network, re-connected successfully. This was a problem prior. looks like its fixed.
logged on to completely hidden SSID sucessfully !
8.04 reports chipset as follows: Intersel ISL 3890 Prism GT/Prism Duette / ISL 3886 Prism Javelin/ Prism Xbow - Prism54PCI driver used.
using this LiveCD looks like it solves the problem with that chipset, however as I said before, I had sucess on 7.10 also using LiveCD until I installed, then it switched to WEP drivers from WPA and was very very troublesome to get it to finally detect correctly and when it did finally, it had the hidden SSID issue. ATM, I think its good tho.

Atheros:
Second chipset FAILED completely AND crashed NM. NM could not be restarted. had to reboot computer. may have been low memory issue @ 256 mb causing some boot issues, raised to 384mb memory re-ran test, booting fine now. NM no longer crashing, however could NOT connect to hidden SSID. 8.04 reported chipset as Atheros AR2413 802.11bg NIC - ath_pci driver.
tested connecting to hidden SSID FAILS
tested connecting to exposed SSID SUCEEDS.
This computer is just an old generic computer I built 10 years ago, PIII @500mhz, 384mb memory, Nvidia vedio card, SCSI HD subsystem. Runs 7.10 just fine.

I have suspicions that 256 mb memory is an issue right now with current beta status. I'm assuming that basic hardware requirements are still the same tho. Pentium class processor and min 256mb memory.

Revision history for this message
Dima Ryazanov (dima-gmail) wrote :

I'll add some info, too.

I have a Thinkpad T43p with a built-in wireless card that uses the ipw2200 driver. NM identifies the card as "Intel Corporation PRO/Wireless 2915ABG Network Connection". It connects to hidden networks fine. I'm using Gutsy.

I also have an Atheros PCMCIA card - "ath_pci" driver, "Atheros Communications, Inc. AR5212/AR5213 Multiprocessor MAC/baseband processor". I normally use it with Thinkpad T20, running Hardy. It connects to my hidden network - but disconnects after a few seconds. Sometimes it won't connect at all. It connects fine to all other networks - even with WPA, etc.
Before, when I used Gutsy, it didn't connect to a hidden network, either. It would get stuck trying to connect, and "iwconfig" would not show the network name. If I told it to connect again, while it was already trying to connect, it would set the network name correctly, but wouldn't connect. If I did it the third time, it would actually connect - but not for very long.

However, if I plug it into my T43p (with Gutsy), it works perfectly there. It connects immediately, and stays connected.
Not sure what is happening here. Does the rest of the hardware make a difference? Did some bug in Gutsy get fixed after I installed Hardy on T20?

Revision history for this message
Christiansen (happylinux) wrote :

Dima, maby you should have look on Bug #208306 "[ath_pci] cannot connect to hidden ap", which deal with the Atheros based adapters. Using the patch attached do make my 3 different Atheros adapters work.

I've testet Kubuntu from Edgy to Gutsy on a ThinkPad T21 several times, and my experience is that thees laptops (T20-23) is getting rather old for thees new OSs. It seemed to me that the amount of RAM and the Prossesor speed (700~900 Mhz) has a certain influencer on NetworkManager. Mine NM did crash too with Gutsy, using PCMCIA with both Atheros AR5212 and other chipsets. Installing more RAM (128 -> 256 -> 512 Mb) did change things a little as fare as I remember.

Did you shutdown/switch off the buildin ipw2915abg in BIOS on the T43 while you tested the Atheros ?.
Having both Adapters activated on the same time, seems to help the Atheros finding and connecting to a specific hidden SSID - when the one adaptor (ipw2915abg) have made an initial connection first.

Revision history for this message
Alexander Sack (asac) wrote :

Dima, can you please attach your complete syslog and dmesg output of the system that doesn't work? please also attach the output of nm-tool

Thanks,
 - Alexander

Revision history for this message
Alexander Sack (asac) wrote :

Dima, please take those logs _after_ a failed connect attempt.

Revision history for this message
Alexander Sack (asac) wrote :

Gene, Matt. sorry if my instructions where not appropriate. Though this package is already in the archive, I'll try harder to post better instructions next time. I certainly want developers to be able to test these. But its much easier to request tests on a branch than rolling out debs for each individual issues i want to track potential fixes for.

So please review if the following steps are detailed enough for you to tests:

# install build requirements/dependencies
 1. sudo apt-get build-dep network-manager
 2. sudo apt-get install bzr devscripts

# branch the sources
 3. bzr branch https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x.ap_scan network-manager.ubuntu

# build the sources:
 4. cd network-manager.ubuntu
 5. debuild -b

# install the bits for testing
 6. cd ../; dpkg -i network-manager*deb libnm-*deb

Is that good enough?

Thanks for your input,
 - Alexander

Revision history for this message
Alexander Sack (asac) wrote :

Gene, could you put your atheros test results to the ath_pci bug we have now to track this: bug 208306.

Revision history for this message
Alexander Sack (asac) wrote :

Luke,

your log indicates that you have a atheros chipset as well. can you follow up in bug 208306 which deals with this?

Revision history for this message
Christiansen (happylinux) wrote :

Anyone tested the ndiswrapper yet ? - Alexander

If it can be tested with an Atheros based PCMCIA card I think I might give it a try - even thou I don't like chipset vendors that do not give the Linux community a chance or just a clue how to make a driver, then I certainly would like to see K/Ubuntu Hardy rock in any way possible.

Anyone ?

Revision history for this message
Matt Palmer (mattpalms) wrote :
  • unnamed Edit (3.4 KiB, text/html; charset=ISO-8859-1)
  • syslog Edit (81.6 KiB, application/octet-stream; name=syslog)
  • dmesg Edit (28.8 KiB, application/octet-stream; name=dmesg)

Alexander,

great instructions. I had to sudo a little bit more, and do an apt-get
update before it would install all the build dependencies. The only other
errors I got were not having your private GPG key to sign the packages! It
would be great if such simple instructions were obvious and available to
everyone on launchpad.

I ran it all from the live CD, and built a new network manager and installed
it (ubuntu4). I assume this is OK - you don't have to do this from a hard
disk install?

It installed cleanly over the existing one, maintaining my network
connection to an unhidden network. I changed the network back over to
hidden, and it stayed connected. However, when I disconnected and tried to
reconnect, it failed to re-connect, with the same issues. This is on a
thinkpad T43 using ipw2200. Attached is the dmesg and syslog outputs.

Matt

On Mon, Mar 31, 2008 at 11:21 AM, Alexander Sack <email address hidden> wrote:

> Gene, Matt. sorry if my instructions where not appropriate. Though this
> package is already in the archive, I'll try harder to post better
> instructions next time. I certainly want developers to be able to test
> these. But its much easier to request tests on a branch than rolling out
> debs for each individual issues i want to track potential fixes for.
>
> So please review if the following steps are detailed enough for you to
> tests:
>
> # install build requirements/dependencies
> 1. sudo apt-get build-dep network-manager
> 2. sudo apt-get install bzr devscripts
>
> # branch the sources
> 3. bzr branch
> https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x.ap_scan<https://code.edge.launchpad.net/%7Eubuntu-core-dev/network-manager/ubuntu.0.6.x.ap_scan>network-manager.ubuntu
>
> # build the sources:
> 4. cd network-manager.ubuntu
> 5. debuild -b
>
> # install the bits for testing
> 6. cd ../; dpkg -i network-manager*deb libnm-*deb
>
> Is that good enough?
>
> Thanks for your input,
> - Alexander
>
> --
> can't connect to hidden network
> https://bugs.launchpad.net/bugs/50214
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in NetworkManager: Fix Released
> Status in Source Package "network-manager" in Ubuntu: Fix Released
> Status in Source Package "knetworkmanager" in Baltix GNU/Linux: Invalid
>
> Bug description:
> Since I installed dapper clean from CD, NM won't connect to my own hidden
> network., however it did before. The network was even in the list after a
> few seconds, the new feature of reverse mac scanning in 0.6.2.
>
> Now even if I use "connect to other network" and I enter everything in
> there, the connection won't be a success. Not hiding the SSID solves the
> problem immediately, just as manually connecting to the AP with iwconfig
> eth1 essid <mine> ...
>

Revision history for this message
Gene Caldwell (gene-caldwell) wrote :

wait, matt !

I got the same error at the gpg key but it said fatal error and all further processing stopped...I sent an email to Alexander and am waiting now for a response. I just sent it 2 minutes ago....should have taken a smoke break and I would have recieved your post...GRR fatal error to me means stop, you continued to the next step anyway ?
Gene

Revision history for this message
Martin Pool (mbp) wrote :

On Tue, Apr 1, 2008 at 8:23 AM, Gene Caldwell <email address hidden> wrote:
> wait, matt !
>
> I got the same error at the gpg key but it said fatal error and all further processing stopped...I sent an email to Alexander and am waiting now for a response. I just sent it 2 minutes ago....should have taken a smoke break and I would have recieved your post...GRR fatal error to me means stop, you continued to the next step anyway ?

As I said previously (maybe on another dupe), yes, you can continue
and install the unsigned packages.

--
Martin <http://launchpad.net/~mbp/>

Revision history for this message
Alexander Sack (asac) wrote :

Matt, i cannot tell if you are really running the right network manager package as i miss some log output i would expect to see in the latest packages. Anyway, the branch is now available as .deb package in the archive, so you can test the prebuild debs directly. If you still have issues connecting to hidden SSID (or connecting at all), please file a new ipw2200 bug.

For the signing error during build: the failure to sign is not a problem for local tests. I think the error message would not have popped up if you build like:

  debuild -b -uc

Revision history for this message
Matt Palmer (mattpalms) wrote :
  • unnamed Edit (2.4 KiB, text/html; charset=ISO-8859-1)

Alexander,

thanks. I wasn't sure it was correct either - it seemed to be showing
AP_SCAN 1 in the log files, and I thought the replacement should have
changed that to AP_SCAN 2. However, dpkg did seem to do a replacement, and
Synaptic showed an ubuntu2 version before, and an ubuntu4 version
afterward. I will play with these things a bit more when I find time.

In the meantime, I will check out the archive deb package and see how I go
with that.

Matt

On Tue, Apr 1, 2008 at 11:01 AM, Alexander Sack <email address hidden> wrote:

> Matt, i cannot tell if you are really running the right network manager
> package as i miss some log output i would expect to see in the latest
> packages. Anyway, the branch is now available as .deb package in the
> archive, so you can test the prebuild debs directly. If you still have
> issues connecting to hidden SSID (or connecting at all), please file a
> new ipw2200 bug.
>
> For the signing error during build: the failure to sign is not a problem
> for local tests. I think the error message would not have popped up if
> you build like:
>
> debuild -b -uc
>
> --
> can't connect to hidden network
> https://bugs.launchpad.net/bugs/50214
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in NetworkManager: Fix Released
> Status in Source Package "network-manager" in Ubuntu: Fix Released
> Status in Source Package "knetworkmanager" in Baltix GNU/Linux: Invalid
>
> Bug description:
> Since I installed dapper clean from CD, NM won't connect to my own hidden
> network., however it did before. The network was even in the list after a
> few seconds, the new feature of reverse mac scanning in 0.6.2.
>
> Now even if I use "connect to other network" and I enter everything in
> there, the connection won't be a success. Not hiding the SSID solves the
> problem immediately, just as manually connecting to the AP with iwconfig
> eth1 essid <mine> ...
>

Revision history for this message
Christiansen (happylinux) wrote :

Tested ndiswrapper on the latest kernel and SUCCESS for both AR5211 based Netgear PCMCIA adapter an zd1211rw based ZyXEL USB adapter, connecting to hidden SSID with WPA1 security. ZyXEL gives shows higher bandwidth on 54 Mbps than the native driver with only 24 Mbps when using ZyXEL driver version 1.0 (2.x doesn't work). Atheros works sleety better with the native Linux driver.

Used : kernel 2.6.24-14-generic, ndiswrapper-common-1.50-1ubuntu1, ndiswrapper-util-1.9-1.50-1ubuntu1, network-manager-0.6.6-0ubuntu5

Revision history for this message
WhyWontThisWork (jsweepstakes) wrote :

I want to get in the changes so I gotta reply.... did we fine a solution? sorry to everybody else who wants to hear changes about the bug and is going to get an e-mail so that I can get the reports too.....

Revision history for this message
Christiansen (happylinux) wrote :

I've opened a new bug #217006 on the ipw2200, as it seems that the bugs with this chipset has not been fully solved yet.

Revision history for this message
joshua (gongjh01) wrote :

Alexander,

Thanks for your patience! I have followed your instructions as below, while it doesn't work for me:

 1. sudo apt-get build-dep network-manager
 2. sudo apt-get install bzr devscripts
 3. bzr branch https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x.ap_scan network-manager.ubuntu
 4. cd network-manager.ubuntu
 5. debuild -b

All the first four steps are just OK, while when I came to the 5th step, I got a message "fatal error..." in the terminal, should I first uninstall the network-manager existed and then run the steps? By the way, why not release the patches in the source so that our rookies can update network-manager in Synaptic? You know, "compile and build" is often a killer for the rookie's ubuntu!

Revision history for this message
Dave Vree (hdave) wrote :

I can confirm this bug on Hardy with wireless device is a Broadcom BCM4328 (Vendor = 0x14E4, Product = 0x4328). I am using ndiswrapper still...is this correct?

Revision history for this message
Diegstroyer (diegstroyer) wrote :

No,i'm using a Intel Wireless 2200, but i can connect fine before the RC
version.

El dl 28 de 04 de 2008 a les 22:21 +0000, en/na HDave va escriure:
> I can confirm this bug on Hardy with wireless device is a Broadcom
> BCM4328 (Vendor = 0x14E4, Product = 0x4328). I am using ndiswrapper
> still...is this correct?
>

Revision history for this message
Gilberto "Velenux" Ficara (g-ficara) wrote :

I have a similar problem on Kubuntu Karmic Netbook Remix. The problem affects also wicd, not network manager alone, maybe it's a wpa_supplicant related issue? Or maybe the way NM/wicd creates config files for hidden networks...

At the moment I worked around it activating SSID broadcast on my AP.

Revision history for this message
Sebastian Schuberth (sschuberth) wrote :

I'm still having this issue on Ubuntu 10.04 "Lucid Lynx" with latest updates (kernel 2.6.32-24-generic): The Intel 3945ABG adapter in my ASUS A8Js notebook cannot connect to to my FRITZ!Box Fon WLAN 7270 (security is set to "WPA + WPA2") if my SSID is hidden. It works fine if I broadcast the SSID, but I'd rather prefer not to for security reasons.

Changed in network-manager:
importance: Unknown → Wishlist
Displaying first 40 and last 40 comments. View all 209 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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