can't connect to hidden network

[nanophase]

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

[nanophase (nanophase)]

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

[Scott Robinson (scott-ubuntu)]

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

[nanophase (nanophase)]

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.

[Scott Robinson (scott-ubuntu)]

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.

[nanophase (nanophase)]

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

[hackel (hackel)]

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.

[Witold Krakowski (wkrakowski-gmail)]

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.

[Witold Krakowski (wkrakowski-gmail)]

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

[Arthur Schiwon (blizzz)]

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.

[Witold Krakowski (wkrakowski-gmail)]

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)

[André Fettouhi (a-fettouhi)]

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é

[Witold Krakowski (wkrakowski-gmail)]

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.

[Michael (mike984)]

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.

[David Vinas (dvinas)]

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?

[Witold Krakowski (wkrakowski-gmail)]

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

[Nathan Pettigrew (nathanp39)]

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

[Chris Mangrum (mangrum)]

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

[Sven Hoffmeister (schaumkeks)]

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.

[Kaspar Metz (kap)]

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

[Dima Ryazanov (dima-gmail)]

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.

[Matthew Carpenter (matt-eisgr)]

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.

[Witold Krakowski (wkrakowski-gmail)]

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.

[Matthew Carpenter (matt-eisgr)]

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?

[Witold Krakowski (wkrakowski-gmail)]

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

[Witold Krakowski (wkrakowski-gmail)]

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

[Julie Verley (diranda)]

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

[Witold Krakowski (wkrakowski-gmail)]

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.

[Alexander Sack (asac)]

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

[Alexander Sack (asac)]

taking the lead for now.

[Witold Krakowski (wkrakowski-gmail)]

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.

[luisalmo (lost180)]

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.

[Witold Krakowski (wkrakowski-gmail)]

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.

[aquo (sbauch)]

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.

[Witold Krakowski (wkrakowski-gmail)]

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

[aquo (sbauch)]

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

[Witold Krakowski (wkrakowski-gmail)]

>>i want to see the fix for the kernel.
Me too. The trouble is that the kernel team, the NM team and whoever else doesn't seem to care. This damn fault is here since dapper. I don't care about it too anymore as long as there is no Ubuntu dev who takes this fault seriously. until then I'll use other system on my laptop and use *buntu only on my desktop (wired) system.

[aquo (sbauch)]

So you don't have any working fix at the moment?

[Witold Krakowski (wkrakowski-gmail)]

As I already told, I made it work on one of my computers, but I certainly
didn't make any patch.
Ubuntu Kernel Team and Ubuntu NM team should sort it out. That's all. This
bug is here for well over a year and I think it's time to fix it. If the
Ubuntu developers don't care, neither do I.

2007/7/17, aquo <email address hidden>:
>
> So you don't have any working fix at the moment?
>
> --
> 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.
>

[SPaul (ubuntu-wetlogic)]

I've run into a similar problem on a laptop running Fiesty running 2.6.20-16-generic.
iwconfig --version says it is Wireless-Tools version 28, compatible with v11-v20
and the kernel is compiled with Wireless Extension v21. The machine is using
ndiswrapper / bcmwl5 for device 14E4:4311. lspci claims this is a "Broadcom Dell
Wireless 1390 WLAN Mini-PCI Card", though that's probably not what Compaq would
like us to call it (since thisis a Presario F500).

The network I've been having trouble getting onto is a WPA enterprise (TKIP,
WPA-EAP, EAP-TLS) network which doesn't broadcast its SSID. In this situation,
I'm familiar with the regular wireless-tools failing to associate with certain chipsets.
For example the Atheros cards won't associate to a WPA access point (even if
some non-TKIP EAP traffic is necessary before encryption) because it disqualifies
the base station because its WPA flag doesn't match the interface's WPA configuration.

I was a little taken aback however with the ndiswrapper behavior of not even displaying
the requested ESSID while it was scanning. An "iwconfig wlan0 essid foo" then an
"iwconfig wlan0" right after would give "ESSID:off/any" which had me barking up the
wrong tree for a while wondering if the hardware was active at all. A "iwlist wlan0 scan"
would successfully list all broadcasting access points, however, and from notes in other
fora, I guessed correctly that only when the association succeeds does the ESSID: line
on ndiswrapper interfaces reflect the requested access point name.

I'm used to working around the "won't assocciate to WPA host" problem on Atheros-based
machines using "ap_scan = 1" global flag in the wpa_supplicant.conf. This instructs
WPA-supplicant to not only passively watch the interface for associations, but to actively
scan and configure the interface to connect to each of the configured networks in case the
network is hidden. This works successfully on Atheros machines, but does not on this
Feisty / ndiswrapper machine with wpa_supplicant configured as either "-Dwext" or
"-Dndiswrapper".

Before resorting to kernel recompilation and the attendant issues with upgrades, etc, I hit
upon a solution. In Atheros-based machines you can control the WPA functionality using
an iwpriv call (which I assume is what wpa_supplicant does). Sure enough ndiswrapper
for this broadcom card also had a promising looking iwpriv named "set_auth_mode". After
a lot of wrangling and repeated trials I ended up with a working combination:

With wpa_supplicant configured with "ap_scan = 0", and "-Dwext" (_not_ ndiswrapper)
running using /etc/network/interfaces wpa-* calls (i.e., configuring network-manager not
to configure this interface) wpa_supplicant would configure the right ESSID but sit around
waiting for association. If while wpa_supplicant is in this state, one issued the command
"iwpriv wlan0 set_auth_mode 3" (and I did another "iwconfig wlan0 essid <ssid>" for good
measure) all of a sudden the interface would associate, wpa_supplicant would notice and
fire off the EAP-TLS process and everything was smooth sailing from there.

The trick was now to find a way to automate this delicate dance in a repe...

[David Roth (davidroth)]

I can also confirm this issue with hidden networks. please see my post at: https://bugs.launchpad.net/bugs/127660. This is really making my Kubuntu experience unpleasant! Help!!! Thanks!

[Alex Ibrado (alex-kdex)]

Confirmed on Feisty, ipw3945 (Lenovo 3000 N100 0689).

On the same box, wlassistant (Wireless Assistant 0.5.7) *can* connect to a WPA2 AP with hidden ESSID (I put NM to sleep first). What's it doing right..?

[Alexander Sack (asac)]

On Tue, Jul 17, 2007 at 08:48:32AM -0000, Witold Krakowski wrote:
> >>i want to see the fix for the kernel.
> Me too. The trouble is that the kernel team, the NM team and whoever else doesn't seem to care. This damn fault is here since dapper. I don't care about it too anymore as long as there is no Ubuntu dev who takes this fault seriously. until then I'll use other system on my laptop and use *buntu only on my desktop (wired) system.
>

We need to confirm that getting things in synch actually fixes
things. For me it doesn't here on feisty. Have no idea where to get a
wireless tools that is compatible with gutsy atm.

Anyway: Please show more evidence that bringing them in sych fixes issues
for you. If that is the case, I will take care that the kernel team
acts more responsible in this regards.

 - Alexander

[Alexander Sack (asac)]

On Tue, Jul 17, 2007 at 06:27:33PM -0000, SPaul wrote:
> I've run into a similar problem on a laptop running Fiesty running 2.6.20-16-generic.
> iwconfig --version says it is Wireless-Tools version 28, compatible with v11-v20
> and the kernel is compiled with Wireless Extension v21. The machine is using
> ndiswrapper / bcmwl5 for device 14E4:4311. lspci claims this is a "Broadcom Dell
> Wireless 1390 WLAN Mini-PCI Card", though that's probably not what Compaq would
> like us to call it (since thisis a Presario F500).

Everyone subscribed to this bug and running feisty ...

can you please try to build the gutsy wireless tools package under
feisty and see if your issues go away? You might need to build
network-manager as well once you updated your wireless tools.

If you need help on how to do that ping me on #ubuntu-devel or
#ubuntu-bugs on freenode.

Thanks for your help.

... the problem here still is that there are lots of people claiming
different things ... so lets get this tracked down by testing first.

 - Alexander

[Witold Krakowski (wkrakowski-gmail)]

Hi Alexander. Before things got out of synch (Dapper AFAIK) it was working correctly for me on few different machines.

>>Have no idea where to get a wireless tools that is compatible with gutsy atm.

There is only one wireless tools and in gutsy there is the latest version - 29. The trouble is that it is compatible with Wireless Extensions up to v 21, but Ubuntu devs are updating continuously, so now we have WE v 22.
The only way to bring things in synch is to stop updating Wireless Extensions and to keep v 21, as it is the latest version supported by Wireless Tools.
You can find more info about Wireless Tools at this url: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

[Matthew Carpenter (matt-eisgr)]

On Thursday 26 July 2007, Alexander Sack wrote:
> On Tue, Jul 17, 2007 at 08:48:32AM -0000, Witold Krakowski wrote:
> > >>i want to see the fix for the kernel.
> >
> > Me too. The trouble is that the kernel team, the NM team and whoever else
> > doesn't seem to care. This damn fault is here since dapper. I don't care
> > about it too anymore as long as there is no Ubuntu dev who takes this
> > fault seriously. until then I'll use other system on my laptop and use
> > *buntu only on my desktop (wired) system.
>
> We need to confirm that getting things in synch actually fixes
> things. For me it doesn't here on feisty. Have no idea where to get a
> wireless tools that is compatible with gutsy atm.
>
> Anyway: Please show more evidence that bringing them in sych fixes issues
> for you. If that is the case, I will take care that the kernel team
> acts more responsible in this regards.

Thanks Alexander...
Having one developer develop a deb (or two or three) and distributing them
make more sense, as most of us aren't developers per se, and the recompiling
is likely to provide inconsistent results.

I'll install a package that I can remove and replace with the originals, but
I'm not likely to compile from source, at least not without copy-and-paste
instructions that we can all follow, making it more worth the time and
potential down-time.

I realize that I'm but one person. Perhaps one of the other folks who have
indicated the fix could make debs available?

[clifford (clifford-offline)]

Hi guys. Just a suggestion. While I do not have a similar setup to test this in at the moment, I did have the same problem on a SuSE laptop recently, running kernel 2.6.22.1-default and wireless-tools-29pre10-22. Simply running "iwlist scan" seems to trigger the association and fix the problem. Is there a chance that this would fix it on Ubuntu too?

[Witold Krakowski (wkrakowski-gmail)]

Hi clifford,

I'll try that, but I think that what you suggest is more a workaround than a real solution. I don't want to have to type "iwlist scan" in the console every time I need to connect to a wlan and most of ubuntu users probably don't want too.

[Matthew Carpenter (matt-eisgr)]

On Friday 27 July 2007, clifford wrote:
> Hi guys. Just a suggestion. While I do not have a similar setup to test
> this in at the moment, I did have the same problem on a SuSE laptop
> recently, running kernel 2.6.22.1-default and wireless-tools-29pre10-22.
> Simply running "iwlist scan" seems to trigger the association and fix
> the problem. Is there a chance that this would fix it on Ubuntu too?

I've done this to make the wifi work with other networks, but not to get
access to a hidden SSID.

[Václav Šmilauer (eudoxos)]

I was able to work around this problem by killing NetworkManager and running NetworkManager --no-daemon from root console. Then it associated with the hidden network just fine. I have to kill NetworkManager and run it again (with --no-daemon) if the association needs to be repeated. Can someone reproduce this workaround?

I have ndiswrapper-driven acx111 card, recent gutsy with kernel 2.6.22-9:

 iwconfig Wireless-Tools version 29
           Compatible with Wireless Extension v11 to v21.
 Kernel Currently compiled with Wireless Extension v22.
 wlan0 Recommend Wireless Extension v18 or later,
           Currently compiled with Wireless Extension v22.

[Alexander Sack (asac)]

On Thu, Aug 16, 2007 at 08:19:35AM -0000, Václav Šmilauer wrote:
> I was able to work around this problem by killing NetworkManager and
> running NetworkManager --no-daemon from root console. Then it associated
> with the hidden network just fine. I have to kill NetworkManager and run
> it again (with --no-daemon) if the association needs to be repeated. Can
> someone reproduce this workaround?

and just restarting NetworkManager doesn't help? or killing and
starting with --no-daemon parameter?

 - Alexander

[Matthew Carpenter (matt-eisgr)]

On Saturday 25 August 2007, Alexander Sack wrote:
> On Thu, Aug 16, 2007 at 08:19:35AM -0000, Václav Šmilauer wrote:
> > I was able to work around this problem by killing NetworkManager and
> > running NetworkManager --no-daemon from root console. Then it associated
> > with the hidden network just fine. I have to kill NetworkManager and run
> > it again (with --no-daemon) if the association needs to be repeated. Can
> > someone reproduce this workaround?
>
> and just restarting NetworkManager doesn't help? or killing and
> starting with --no-daemon parameter?
>
> - Alexander

Who are you talking to? It sounds like Alexander answered your question
before you asked it, and if you were not talking to Alexander, please
indicate who you were talking to so that we can appropriately and promptly
respond. I do not wish for this bug to be REJECTED because we dropped the
ball on communication.

[Alexander Sack (asac)]

On Mon, Aug 27, 2007 at 11:06:18AM -0000, Matthew Carpenter wrote:
> On Saturday 25 August 2007, Alexander Sack wrote:
> > On Thu, Aug 16, 2007 at 08:19:35AM -0000, Václav Šmilauer wrote:
                                                ^^^^^^
> > > I was able to work around this problem by killing NetworkManager and
> > > running NetworkManager --no-daemon from root console. Then it associated
> > > with the hidden network just fine. I have to kill NetworkManager and run
> > > it again (with --no-daemon) if the association needs to be repeated. Can
> > > someone reproduce this workaround?
> >
> > and just restarting NetworkManager doesn't help? or killing and
> > starting with --no-daemon parameter?
> >
> > - Alexander
>
> Who are you talking to? It sounds like Alexander answered your question
> before you asked it, and if you were not talking to Alexander, please
> indicate who you were talking to so that we can appropriately and promptly
> respond. I do not wish for this bug to be REJECTED because we dropped the
> ball on communication.
>

Its obvious imo ... I quoted Vaclav (see above) ... so the questions was for him.

 - Alexander

[Ben Gladwell (bengladwell)]

Killing NetworkManager and restarting with --no-daemon doesn't fix the problem for me. (and its hard to see why it would)

ipw3945

uname -r: 2.6.20-16-generic

iwconfig --version:
iwconfig Wireless-Tools version 28
          Compatible with Wireless Extension v11 to v20.

Kernel Currently compiled with Wireless Extension v21.

eth1 Recommend Wireless Extension v16 or later,
          Currently compiled with Wireless Extension v21.

[Alexander Sack (asac)]

bumping importance.

[Alexander Sack (asac)]

Ben, could you please attach your /var/log/syslog when trying to connect to hidden network?

[Ben Gladwell (bengladwell)]

Thanks for taking the initiative on this.

I've attached my syslog as requested. I have edited out a bunch of hex dumps, b/c I don't know what they represent and I don't want to submit my WPA key. If I edited out something you need, I can get you that information if you can point me to some documentation that explains the hex dumps.

Thanks again,

Ben Gladwell

Alexander Sack <email address hidden> wrote: Ben, could you please attach your /var/log/syslog when trying to connect
to hidden network?

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

---------------------------------
Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV.

Sep 25 13:05:36 linspiron6400 ntpd_initres[5861]: ntpd returns a permission denied error!
Sep 25 13:05:36 linspiron6400 last message repeated 4 times
Sep 25 13:05:37 linspiron6400 kernel: [13180.384000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:8b:b3:e0:16:08:00 SRC=192.168.1.150 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=61052 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:38 linspiron6400 kernel: [13181.584000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:04:f2:71:7e:08:00 SRC=192.168.1.151 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7858 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:39 linspiron6400 kernel: [13182.640000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:8b:b3:e0:16:08:00 SRC=192.168.1.150 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=61058 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:40 linspiron6400 kernel: [13183.388000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:8b:b3:e0:16:08:00 SRC=192.168.1.150 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=61060 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:41 linspiron6400 kernel: [13184.748000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:04:f2:71:7e:08:00 SRC=192.168.1.151 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7871 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:42 linspiron6400 kernel: [13185.500000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:04:f2:71:7e:08:00 SRC=192.168.1.151 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=7874 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:43 linspiron6400 kernel: [13186.404000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:03:1d:54:22:08:00 SRC=192.168.1.149 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=61196 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:44 linspiron6400 kernel: [13187.900000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:01:03:1d:54:22:08:00 SRC=192.168.1.149 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=61198 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:52 linspiron6400 kernel: [13195.380000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:8b:b3:e0:16:08:00 SRC=192.168.1.150 DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=61152 PROTO=UDP SPT=137 DPT=137 LEN=58
Sep 25 13:05:52 linspiron6400 kernel: [13195.380000] ''IN-world':'IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:8b:b3:e0...

[Michael (mike984)]

This bug persists in Gutsy as well - see https://bugs.launchpad.net/ubuntu/+source/gnome-network/+bug/136504

[Janna (horsecrazyinca)]

Agreed, I'm running Gutsy with the latest updates and this is still a problem.

[Alexander Sack (asac)]

i uploaded a testpackage to my ppa with a patch i found in the upstream bug added a minute ago to this bug.

Please get the network manager packages for version 0.6.5-0ubuntu16~ppa3 from my PPA and if you can connect to hidden networks.

http://ppa.launchpad.net/asac/ubuntu/pool/main/n/network-manager/

If this helps, we might be able to fix this for gutsy. So please test asap.

Thanks,
 - Alexander

[Sven Hoffmeister (schaumkeks)]

With the testpackage provided by Alexander it seems to work (tested with ipw2200 and WPA/WPA2 encrypted network). Connected right after entering SSID and Password.
As I have no Gutsy installed (needed because of newer libc etc. dependencies) I used a USB pendrive system. Later I reinstalled the newest Gutsy version of network-manager just to make sure it fails again.

Thanks Alexander. Hope this will be part of the Gutsy release, if there are no side-effects reported.
Bye, Sven

[Ben Gladwell (bengladwell)]

When I try to install the test package, I get this error:

$ sudo dpkg -i network-manager_0.6.5-0ubuntu16~ppa3_i386.deb
Preparing to replace network-manager 0.6.4-6ubuntu7 (using network-manager_0.6.5-0ubuntu16~ppa3_i386.deb) ...
Unpacking replacement network-manager ...
dpkg: error processing network-manager_0.6.5-0ubuntu16~ppa3_i386.deb (--install):
 trying to overwrite `/usr/share/gnome-vpn-properties/nm-vpn-properties.glade', which is also in package network-manager-gnome
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 network-manager_0.6.5-0ubuntu16~ppa3_i386.deb

What am I doing wrong?

Thanks again,

Ben

[Ludovico Fischer (ludovicofischer)]

Hello, I managed to install the package but it does not work for me at the moment. I think though it may not be related directlyto the bug, but there seems to be a conflict with my manual setup (it says something like 'there is already a pid file in /var/run'). The problem is that each time I install the package it breaks my connection; I have to run remove --purge and put my /etc/network/interfaces back in place just to run a search the problem on google.

[Janna (horsecrazyinca)]

Ben, I had to sudo apt-get remove network-manager and network-manager-gnome. I then installed the package. Then I reinstalled network-manager-gnome.

And it works perfectly! I connected to a hidden network with WPA2 no problem. I'm running Gutsy with the latest updates.

*does a little dance*

[Matthew Carpenter (matt-eisgr)]

On Friday 12 October 2007, Ludovico Fischer wrote:
> Hello, I managed to install the package but it does not work for me at
> the moment. I think though it may not be related directlyto the bug, but
> there seems to be a conflict with my manual setup (it says something
> like 'there is already a pid file in /var/run'). The problem is that
> each time I install the package it breaks my connection; I have to run
> remove --purge and put my /etc/network/interfaces back in place just to
> run a search the problem on google.

Hello Ludovico,

For something so simple, I find manipulating the results of the scripts can
help. They are in /var/lib/dpkg/info/ and have names like <package>.prerm
and <package>.postinst etc....

remove --purge is rather extreme. Have you simply tried removing the pid file
in /var/run/??

[Ben Gladwell (bengladwell)]

Thanks for the advice to apt-get remove network-manager and network-manager-gnome. Unfortunately, that didn't work. I still have quite a few unmet dependencies:

The following packages have unmet dependencies:
  network-manager: Depends: libc6 (>= 2.6-1) but 2.5-0ubuntu14 is installed.
                   Depends: libdbus-1-3 (>= 1.1.1) but 1.0.2-1ubuntu4 is installed.
                   Depends: libdbus-glib-1-2 (>= 0.74) but 0.73-1 is installed.
                   Depends: libglib2.0-0 (>= 2.14.0) but 2.12.11-0ubuntu1 is installed.
                   Depends: libiw29 (>= 28+29pre7) which is a virtual package

I'm still on Fiesty - do I have to upgrade to Gutsy to try this fix? If so, I'm out of luck for now.

Thanks - Ben

[Alexander Sack (asac)]

gutsy is _required_ to test this package.

[Stéphane Graber (stgraber)]

Above fix let me connect to hidden open and WPA networks.
I tried switching between wired, WPA and open with a mix of hidden and open network without seeing any problem.
I'm using it for a couple of hour now and didn't see any regression from current gutsy yet.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

this looks fine - it's working here, too.

[Alexander Sack (asac)]

network-manager (0.6.5-0ubuntu16) gutsy; urgency=low

  * debian/README.Debian: adapt README to match the new behaviour of
    network-manager, which doesn't manage _any_ device configured in
    /etc/network/interfaces anymore.
  * debian/patches/42a_lp50214_gnome464215_fix_hidden.patch,series: new patch
    that fixes hidden network for most chipsets (LP: #50214).

 -- Alexander Sack <email address hidden> Mon, 15 Oct 2007 18:55:20 +0200

[Michael (mike984)]

With the new network-manager installed, my hp dv6500t with Intel 4965 is connecting fine to my hidden ssid.

[Christiansen (happylinux)]

Great work Alexander and others ??, thanks for the well done work on this one.

Tested the NM 0.6.5-0ubuntu16 from the repository on a buildin "IBM 11a/b/g Wireless LAN Mini PCI Adapter II" (Athero AR5212), a PCMCIA "Netgear WG511T" (Atheros AR5211) and a PCI "Netgear WG311T" (Atheros AR5211), they work perfect, as they did in Edgy (so now it's certainly time for an upgrade)
Not to confuse anything, but I can mention that the "Intel 2200BG" and the "Intel 2915ABG" continues to work after a upgrade too, as they did before.

[Matthew Carpenter (matt-eisgr)]

On Tuesday 16 October 2007, Christiansen wrote:
> Great work Alexander and others ??, thanks for the well done work on
> this one.
>
> Tested the NM 0.6.5-0ubuntu16 from the repository on a buildin "IBM 11a/b/g
> Wireless LAN Mini PCI Adapter II" (Athero AR5212), a PCMCIA "Netgear
> WG511T" (Atheros AR5211) and a PCI "Netgear WG311T" (Atheros AR5211), they
> work perfect, as they did in Edgy (so now it's certainly time for an
> upgrade) Not to confuse anything, but I can mention that the "Intel 2200BG"
> and the "Intel 2915ABG" continues to work after a upgrade too, as they did
> before.

Well done. Please backport this to Feisty (and Dapper since it's still
supported).

Thank you!
Matt

[Ioannis Ramfos (isr81)]

Unfortunately, this still doesn't work for the Ralink rt73 usb chipset (rt2x00 driver).

[Kunal Thakar (kunalt)]

I still can't connect to a hidden WEP network using intel 3945. I am going to try out wlassistant and wicd (wicd.sf.net) next. Anyone successful with that?

[josesuarez1983 (j-suarez-agapito)]

Since nm version 0.6.5-15 (this version included) I can't connect to my hidden WEP-secured network. It worked fine with -14 version (the one included in Gutsy Beta).

I use a Conceptronic C54Ri and I have never been able to connect to this network using the rt61pci drivers contained in the kernel so I have been using ndiswrapper for more than 4 months without any problems (Oh, and by the way, I have tried to blacklist rt61pci but that gets ignored every time I boot the PC so I always end up deleting the rt2x00 folder in the linux-ubuntu-modules package every time that package gets upgraded).However since the upgrade to nm -15 and also -16 I can't connect to the wireless network.

The strange thing is that after having upgraded only network-manager from Gutsy Beta to -16 version, I tried 'apt-get remove --purge'ing network-manager and by doing " iwconfig wlan0 essid NETWORK_NAME ; iwconfig wlan0 key HEX_PASSWD ; iwconfig wlan0 mode Managed ; dhclient wlan0 " (all of them with sudo) the dhclient doesn't get any IP offer!

I also tried configuring the device in /etc/network/interfaces with all those parameters and /etc/init.d/networking restart doesn't get any IP address for the wlan0 interface...

If any further info is required, tell me so

[josesuarez1983 (j-suarez-agapito)]

OK, it definately is a problem with nm versions -15 and -16 because with a clean upgrade to Gutsy final release wireless doesn't work but then I down grade all nm related packages to -14 version and... voilá wireless works again.
As I said before, I use a Conceptronic C54Ri with ndiswrapper (rt61 fails to connect even with nm -14 version to the network ndiswrapper connects OK).

[Phil (mafioso-filippo)]

Hi guys,
i also still have the same problem. My mini-pci card Intersil Corporation ISL3890 [Prism GT/Prism Duette]/ISL3886 [Prism Javelin/Prism Xbow] (rev 01) refuses to connect to a network with a hidden ssid. I have Ubuntu gutsy with the latest updates (networkmanager 0.6.5-Oubuntu16) and as encryption WPA-PSK. When i set my router to broadcast the ssid it works.
If you need further information about my hardware or settings just let me know.

[anonym (launch-mailinator)]

josesuarez1983 is correct. This problem still persists for me. I cannot connect to my hidden WEP-encrypted network, but as soon as I unhide it, I can connect to it fine.

I'm running the latest Gutsy release with network-manager version 0.6.5-0ubuntu16. I've been working on this problem for about two days now and have exhausted just about every other means of fixing this problem except to downgrade to 0.6.5-0ubuntu14.

[anonym (launch-mailinator)]

This is the exact procedure I went about to get my internet working again. I lost the package for 0.6.5-0ubuntu14, so I was forced to use those for Feisty, which work just as well. (This is for a i386 system running Kubuntu; in order words, I'm using KNetworkManager, not the GNOME one. Modify accordingly.)
The Feisty package for NetworkManager has a slight dependency flaw in that it requires libiw28 to be installed, so that has to be done first (Gutsy is packaged with libiw29).

sudo apt-get remove --assume-yes --purge network-manager network-manger-kde
wget http://archive.ubuntu.com/ubuntu/pool/main/w/wireless-tools/libiw28_28-1ubuntu3_i386.deb
wget http://archive.ubuntu.com/ubuntu/pool/main/n/network-manager/network-manager_0.6.4-6ubuntu7_i386.deb
sudo dpkg -i libiw28_28-1ubuntu3_i386.deb
sudo dpkg -i network-manager_0.6.4-6ubuntu7_i386.deb
sudo apt-get install --assume-yes network-manager-kde

Only thing now is that I have a nagging button in the corner to tell me to upgrade to the latest network-manager that I have to avoid. Adept doesn't have a feature to lock packages. At least I can place a hold in apt-get/aptitude on the package...

Additional notes for those that are interested:
* My wireless chipset is the bcm4319, so yeah, this wasn't exactly easy to diagnose to be the problem.
* I got wireless working initially by ndiswrapper, but, of course, it didn't connect to my hidden network, but could connect to unhidden networks just fine.

[Mark Ferguson (markfergy)]

Hi Alexander,

This patch you have applied has affected the ndiswrapper driver.

I am running Kubuntu on IBM laptop Z60t with Atheros wireless card AR5212

Originally I think it was on Fiesty I had problems with a kernel upgrade that effected my wireless connectivity to hidden networks.

I download the source for wireless-tools 29 (I think this was the recommend fix)
And also the latest ndiswrapper, wpa_supplicat and Network Manager 0.6.5 (unpatched)

Once I compiled and installed these programs my wireless was working again

On upgrading to Gutsy suddenly I could not connect to my wireless router using ndiswrapper.

Interestingly if I use the madwifi driver then I can connect fine to my hidden wireless network.

I noticed that in the daemon.log the AP_SCAN command was set to 1 where previously it was set to 2
I thought AP_SCAN = 2 is what should be set when connecting to a hidden wireless network.

I tested this out by running wpa_supplicant from the command line using the ndiswrapper driver.

wpa_supplicant -c/etc/wpa_supplicant.conf -iwlan0 -d

I set ap_scan = 1 in the wpa_supplicant.conf file and wpa_supplicant could not
connect to the wireless router. When I set the value back to 2 it could connect.

I also tried using wpa_supplicant on the command line for the madwifi driver and I
could connect to the wireless router using AP_SCAN = 1 or 2.

I downloaded the source package unpacked and applied the patches.
network-manager_0.6.5-0ubuntu16.diff.gz
network-manager_0.6.5-0ubuntu16.dsc
network-manager_0.6.5.orig.tar.gz

In the patched file nm-device-802-11-wireless.c

I changed this section of the code (approx line 2923):

 if (!strcmp (kernel_driver, "orinoco_cs"))
                ap_scan = "AP_SCAN 2";
        else if (is_adhoc || !supports_wpa)
  ap_scan = "AP_SCAN 2";
 else
                ap_scan = "AP_SCAN 1";

to:

 if (!strcmp (kernel_driver, "orinoco_cs"))
                ap_scan = "AP_SCAN 2";
        else if (is_adhoc || !supports_wpa)
  ap_scan = "AP_SCAN 2";
        else if (!nm_ap_get_broadcast (ap) && !strcmp (kernel_driver, "ndiswrapper"))
  ap_scan = "AP_SCAN 2";
 else
                ap_scan = "AP_SCAN 1";

I can now use the Ndiswrapper with Network Manager to connect to a hidden wireless network.

In the original nm-device-802-11-wireless.c all non broadcast access points had ap_scan = "AP_SCAN 2"

Looks like it may be driver specific in regards to what the correct value for ap_scan should be on hidden networks.

[Christiansen (happylinux)]

josesuarez1983, Ioanna Ramfos and others with the RaLink chipset.

I seems that Gutsy has overall problems with the RaLink Chipset (or the driver development seems to be the actual problem), so could it be that your problem isn't a problem connecting to hidden access points with NM, but a problem connecting at all. Have any of you tested if it is possible to connect to your access point with the SSID NOT hidden ?

Unfortunately I don't have a RaLink adapter to test with, but among others I have been following this bug:

https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/134660

which isn't related to the NM, but the driver it self.

[josesuarez1983 (j-suarez-agapito)]

I think there are two issues:

First: I can't connect at all using the free driver for RaLink: I can't even connect to unhidden unprotected networks! So this would be the free driver development issue.

Second: NM seems to be screwed (only for certain chips?). NM is not ok from version -15 onwards because when using ndiswrapper with versions -15 and -16 of nm and libnm (or whatever the name is for the nm library) I "almost" can never connect to networks (I say almost because: 1) Connecting to hidden protected networks is impossible. 2) Connecting to unhidden unprotected networks works only like 1 out of 50 times!!, if you're lucky, because sometimes you can't connect at all).

I hope this helps to clarify the state of the bug.

[Mike Siegel (siegelmike)]

Jose,

I could be wrong, but this sounds like an issue unrelated to this bug report. Christiansen suggesting following a different bug located here:
https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/134660

It might be in your best interest to post your feedback there instead.

The key issue in this bug report seems to be addressed by Alexander's comment (comment #64):
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214/comments/64

-Mike

[anonym (launch-mailinator)]

I am still having problems connecting to my WEP encrypted hidden network. Attached is the relevant portion of my syslog during the time that my NetworkManager is trying to connect to the router.

Mark Ferguson helped to point out one of the key problems. In the syslog, at line 19, despite my network being hidden, NetworkManager is trying to run AP_SCAN 1 for some reason, rather than AP_SCAN 2.

My bcm4318 card is using Ndiswrapper.

[Ben Gladwell (bengladwell)]

ipw3945 works for me with Alexander's patch

It took me a couple tries, but I am now able to connect to my WPA-PSK TKIP hidden SSID AP. I noticed at least one person using ipw3945 saying the patch didn't work, so here are some things I did wrong at first:

1) You have to be running Gutsy
2) Make sure to install all three packages from Alexander's ppa: libnm-glib0_0.6.5-0ubuntu16~ppa3_<arch>.deb, libnm-util0_0.6.5-0ubuntu16~ppa3_<arch>.deb, and network-manager_0.6.5-0ubuntu16~ppa3_<arch>.deb
3) I could not connect unless I manually selected TKIP when the passphrase entry dialog popped up (if I left it on automatic, it would not connect)

-Ben

[David Ward (dpward)]

I can confirm that versions -15 and -16 of NetworkManager have *broken my ability to connect at all to hidden networks*, let alone automatically re-connect to them after restart/suspend, for both me and my two roommates' laptops. We all have different models of laptops but are all using Gutsy, ndiswrapper, and the Broadcom 43xx chipset. (ndiswrapper is the version supplied with Gutsy, although I have also tried using version 1.49 compiled from source, with no better success.) Using the bcm43xx kernel driver is not really an option, as it is still quite unreliable from what I have read and from my limited usage. Also unhiding the access point is not an option, as we are using Georgia Tech's campus-wide network (and I know that other college campuses have a similar setup). I can barely even Google a site where I can still obtain the .deb for version -14 of NetworkManager, although that does seem to allow us connect, albeit requiring us to re-enter the SSID and WEP key every time we connect.

[David Ward (dpward)]

I can confirm that versions -15 and -16 of NetworkManager have *broken my ability to connect at all to hidden networks*, let alone automatically re-connect to them after restart/suspend, for both me and my two roommates' laptops. We all have different models of laptops but are all using Gutsy, ndiswrapper, and the Broadcom 43xx chipset. (ndiswrapper is the version supplied with Gutsy, although I have also tried using version 1.49 compiled from source, with no better success.)

I have attached my syslog, which matches that of anonym above. I just did a completely clean install of Gutsy, then blacklisted bcm43xx and performed the steps to install/configure ndiswrapper. After restarting, I can connect to open wireless networks but not to hidden ones.

Using the bcm43xx kernel driver is not really an option, as it is still quite unreliable from what I have read and from my limited usage. Also unhiding the access points is not an option, as we are using Georgia Tech's campus-wide network (and I know that other college campuses have a similar setup). I can barely even Google a site where I can still obtain the .deb for version -14 of NetworkManager, although that does seem to allow us connect, albeit requiring us to re-enter the SSID and WEP key every time.

I appreciate everyone's help in continuing to work toward a resolution to this issue. In the meantime I have somehow gotten my roommates to memorize our campus WEP key along with me... :)

[Kunal Thakar (kunalt)]

I just identified that NM is surely the cause of my problem. I am using ipw3945 and I can't connect to hidden WEP networks. I tried the some commands [1] and I could connect without a problem. In order for me to connect, I need to shut NM down. I can't connect with NM active.

[1] http://ubuntuforums.org/showthread.php?t=571188

Now that I am sure the problem is with NM, how can I try to fix it? Is there a better way than looking at the source :) ?

[kurbacik (varlott1-deactivatedaccount)]

I can connect to Purdue University's campus-wide wireless network with NM, but NM doesn't reconnect to the network on the reboot or after resume/suspend. I use 64bit Feisty on a HP laptop with ndswrapper and Broadcom 4306 chipset. Is there a solution for this in Network Manager 0.6.4?

[Luke Hoersten (lukehoersten)]

Same problem for me at Purdue. I have to restart NM after suspend/resume to get it to connect again.

Also, every time I reboot, I have to type in all my connection information again. Shouldn't this be saved in gconf?

[Gene Caldwell (gene-caldwell)]

I have this very same problem....but I did not see in this bug report that NM see's the AP but refuses to connect if SSID broadcast is turned off. I can understand why it might be a problem connecting if the AP is hidden, but for Gutsy (NM) to know the AP is there, display the hidden AP as a choice to connect to, but refuse to connect puzzles me. I read the things people have tried here, and its all over my head, I have no idea what most of the things are discussed here are.

I don't like having to broadcast my SSID, is there some simple cheat someone can tell me that will let me connect to the hidden AP for now until someone gets this fixed ? my SPEC's are: DD-WRT router(works great for other wireless clients), WPA2-personal mixed tkip+aes, NetGear 54g pcmcia wifi card ( prism54pci driver on wlan0).

Like everyone else here, if I turn on SSID broadcast, it works great, but the minute I turn it off, it WILL disconnect the notebook and refuse to re-connect.

[Gene Caldwell (gene-caldwell)]

This is bug is either not fixed or not released so I changed the status from "fixed release" to incomplete. can someone who worked on this bug add some comment about the actual status ? this is after all a security issue.

[Bill (codyw725)]

Has there been any new information regarding this issue? I too am having issues connecting to a hidden ssid network at my home. I am using WPA Personal with Ubuntu 7.04 Feisty Fawn. It works fine if I turn on my ssid broadcasting, but stops as soon as I turn off my ssid broadcasting. It still doesn't work even if I setup the network manually. One thing I did notice is that if the network is hidden and you attempt to connect to the network manually, even though you enter the network information manually, it places a "null" value for the ssid instead of the actual ssid. Any information/help or a fix would be great.

[David Ward (dpward)]

There do seem to be multiple issues here, each one affecting different drivers.

Regarding the issue affecting ndiswrapper: I think anonym was onto something when he noticed that AP_SCAN 1 is being used rather than AP_SCAN 2. Can someone come up with a patch so we can see if that is the problem? (I don't know where to make the changes to do it myself...) Did someone make a deliberate change to NetworkManager so that it issues AP_SCAN 1 when it used to issue AP_SCAN 2? What are the differences between/reasons for using AP_SCAN 1 instead of AP_SCAN 2? Would a change back to AP_SCAN 2 affect other drivers, possibly breaking them?

I appreciate everyone's continued effort on this. I'd really like to see all of these issues sorted out before Hardy is released with LTS. In my mind, problematic wireless networking support is one of the biggest show-stoppers for using Linux out-of-the-box with no prior experience.

[Gene Caldwell (gene-caldwell)]

has any one taken note that this has been an ongoing bug for well over 18 months now or three going on 4 releases of ubuntu ? why can't this security threat get a higher priority ? I did a google for AP_SCAN 1 and find that this issue affects more than just Ubuntu, most of the major distros have a hidden SSID problem. whats the common thread ?

[David Ward (dpward)]

Okay so to answer some of my own questions...

It appears that the change to AP_SCAN 1 for hidden networks was deliberate, but this very change is exactly what broke NetworkManager + ndiswrapper. I've attached a patch that checks for ndiswrapper and uses AP_SCAN 2 if it finds it. Unfortunately it still does not fix hidden network auto-detection, but at least you can connect to hidden networks using the "Connect to Other Wireless Networks..." option... which you couldn't do with -15, -16, or -16.7.10.0 using ndiswrapper.

Which leads me to a very irritating point...

Mark Ferguson's post on 10/23 pointed out that there was a problem with Alexander Sack's patch, which totally broke ndiswrapper with hidden networks. Mark described exactly what the problem was and exactly what was needed to fix it (change AP_SCAN 1 to AP_SCAN 2 for ndiswrapper).

Over two months later, being frustrated that the problem is going unnoticed, having never modified a Debian package before or even looked at the source for NetworkManager, ndiswrapper, or wpa_supplicant before...I was able to come up with a patch for this in a matter of hours. I think anyone who had been working with this code could probably have done this in five minutes.

I hate to be complaining, and I know that this is a community project and is enhanced by people in their spare time and all that stuff... but seriously guys... what is going on? network-manager is a rather significant package that has become central to Ubuntu's functionality. And the Broadcom chipset is not uncommon at all (look in Dell laptops, Linksys wireless adapters, etc...).

[Gene Caldwell (gene-caldwell)]

Bravo, lets turn up the heat. I wish I could help, but I can't so all I can do is report the problems I find. I have no clue if this patch will fix my problem or not as I have no clue if I am using ndiswrapper or not. I installed 7.10 fresh on a DELL Latitude C800 that has a netgear PCMCIA WiFi card installed and 7.10 detected it and looks like it installed Prism54PCI for the WiFi and it works, this does not look like restricted driver as the restricted driver manager does not indicate any restricted drivers in use. the question is.......will this patch fix my problem ? I really hate having to broadcast my SSID.

[David Ward (dpward)]

Gene, you can see if you are using ndiswrapper by typing the command: ndiswrapper -l

If it's been set up, you should see at least one line containing "driver installed".

The only change I made in the patch was to always use AP_SCAN 2 for the ndiswrapper driver.

[Gene Caldwell (gene-caldwell)]

nope, says its not installed, but can install it using apt-get. but I read your patch and I don't think it applies to me, I can read code and your patch seems to rule me out. I have a hidden AP, its not ad-hock, and I see wpa_supplicant running as well as the prism54PCI running in the task manager. My AP does support WPA as well as WPA2, so I think your patch is not for me even if I knew how or where to apply it.

But guess what ? you get the door prize, you are the first an only person to respond to me about this problem. at least I know I have not pissed off the whole world...

[David Ward (dpward)]

Gene, I did some Google searching, and it appears that prism54 also requires AP_SCAN 2 rather than AP_SCAN 1 to work properly, so you are probably being affected by the same issue. I expanded the earlier patch to fix prism54 in addition to ndiswrapper. (Disregard the earlier patch; this one includes its changes).

Here's how you can use the patch to generate a custom package (hopefully I'm not leaving anything out):

- Download the patch to /tmp/fix_hidden_networks_ndiswrapper_prism54.patch

- Make sure you have the packages for build-essential, devscripts, and quilt installed:
sudo apt-get install build-essential devscripts quilt

- Download the source and update it to version 0.6.5-0ubuntu16.7.10.0:
cd /usr/local/src/
sudo apt-get source network-manager
cd network-manager-0.6.5/
sudo quilt push -a

- Apply the patch:
sudo quilt import /tmp/fix_hidden_networks_ndiswrapper_prism54.patch
sudo quilt push

- Change the version number of the package to distinguish it
sudo debchange --newversion=0.6.5-0ubuntu16.7.10.0custom0
(your editor will appear for you to modify the changelog)

- Build the new version
sudo apt-get build-dep network-manager
sudo debuild binary

- Update your packages
cd ../
sudo dpkg -i libnm-glib0_0.6.5-0ubuntu16.7.10.0custom0_i386.deb libnm-util0_0.6.5-0ubuntu16.7.10.0custom0_i386.deb network-manager_0.6.5-0ubuntu16.7.10.0custom0_i386.deb

Then see if it works...

[Gene Caldwell (gene-caldwell)]

ok, the stress is not that I have no clue what you want me to do, nor is it that I will have to trust you didn't leave a step out, the stress is that its the girlfriends computer and I won't know how long she becomes ankle locked if I mess up her computer and she cannot get back onto the web to do her girl things. LOL, I'll give this a shot tomorrow when I am more alert and rested.

[David Ward (dpward)]

Okay so I did leave at least one step out... after
     cd network-manager-0.6.5/
do this for quilt to work:
     sudo ln -s debian/patches patches

I cleaned up the patch slightly and have re-attached it. The earlier ones have been deleted to avoid confusion.

[Linux works (linux-works)]

David,

I did tried your patch and it worked nicely for me. Thanks for the nice instructions.
I am using Gutsy and Ndiswrapper for bcm4318 .

If somehow I can save this hidden ssid setting for my network .. then I do not have to enter it every time.
Thanks

[Gene Caldwell (gene-caldwell)]

Yes, I got it done also David. I'm still trying to decide if the cure is worse than the illness though, jury is still out on that - not remembering the SSID or password on each boot is the sh**s. But It works just fine and SSID is now hidden.

[David Ward (dpward)]

Glad that both of you were able to get it working.

NetworkManager should be remembering the SSID for hidden networks, but it is not. This is a separate issue that is raised in bug 39707 (which has also been open for a very long time). I'd suggest nominating that bug for Hardy if you want to see it fixed.

[David Ward (dpward)]

Can anyone confirm if this issue is affecting the upstream package in Debian or GNOME? If so, we should change the status of that to something other than "Invalid". I don't see how this could only be affecting Ubuntu unless they are using a later version of NetworkManager (unless changes the Ubuntu maintainers made to this package are responsible for breaking this in the first place...which could be the case).

[Gene Caldwell (gene-caldwell)]

I received an email message this morning stating :

** Changed in: network-manager
       Status: Confirmed => Fix Released

So I did a manual update of the affected computer and nothing was updated. If this bug fix has been released, then why would there be no NM updates today ? Also, this will be the second time the status has been changed from Confirmed => Fix Released. I changed the status back to confirmed FROM FIX released on 2007-12-15. It looks like there is a problem or disconnect between what end users see and what developers think has happened.

Status should not be changed from confirmed to released until it can be confirmed that end users have access to the FIXED software AND confirm that the release has indeed resolved the problem. Since there are no confirmed reports from bug reporters of this bug that the fix worked, I believe that the status change in this bug was way too premature and SHOULD be changed back to confirmed until such time as it is confirmed that the bug is resolved in the real world.

[David Ward (dpward)]

Gene, the released fix appears to be for the upstream NetworkManager
package in GNOME, not the Ubuntu network-manager package that is linked
to the same bug report. Take a look at the bug page:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/50214

So hopefully that fix will make its way downstream and we can see what
happens.

David

Gene Caldwell wrote:
> I received an email message this morning stating :
>
> ** Changed in: network-manager
> Status: Confirmed => Fix Released
>
> So I did a manual update of the affected computer and nothing was
> updated. If this bug fix has been released, then why would there be no
> NM updates today ? Also, this will be the second time the status has
> been changed from Confirmed => Fix Released. I changed the status back
> to confirmed FROM FIX released on 2007-12-15. It looks like there is a
> problem or disconnect between what end users see and what developers
> think has happened.
>
> Status should not be changed from confirmed to released until it can be
> confirmed that end users have access to the FIXED software AND confirm
> that the release has indeed resolved the problem. Since there are no
> confirmed reports from bug reporters of this bug that the fix worked, I
> believe that the status change in this bug was way too premature and
> SHOULD be changed back to confirmed until such time as it is confirmed
> that the bug is resolved in the real world.
>
>

[Gene Caldwell (gene-caldwell)]

oooohhhh, my bad.....hummm, no way to edit. I did not realize how this launchpad thing was setup, it looks like I did not understand that this was not a Ubuntu bug reporting tool, but rather a common location for affected distros ? is that correct ?

I guess that really answers my next question, I seem to recall that the kernel needs to be sync'd with NM and that what I'm really looking for is a kernel update along with a driver update as well as a new NM application to get everything working, is that correct ? I think I read the kernel needs to be linked with the correct NM because there was conflicting versions being used and the fix here in NM needs to have the driver changed per the NM fix to add the required NM scanning requirements. Did I get this right ? and that does not even include the bug 39707 you link to that prevents remembering the AP details... ?

Gene

[David Ward (dpward)]

NetworkManager is just a tool to control your network connections. It
assumes that you already have a network/wireless driver installed
correctly, which is either compiled in the kernel or is a kernel
module. So if you are having a trouble with the kernel driver for your
network card, you need to get that fixed before you can use NetworkManager.

Now NetworkManager may have a problem *using* your specific driver
correctly... in my case, it is simply issuing the wrong command
(AP_SCAN 1) to wpa_supplicant, when in fact it should be AP_SCAN 2 for
ndiswrapper. But this is not (I don't think) a problem with the
ndiswrapper kernel module.

And bug 39707 is a completely separate issue altogether.

[David Roth (davidroth)]

Alexander, once the fix is confirmed, will it make it to Hardy? I am running Hardy Alpha4 now and I still can not connect to hidden SSID's (In my case I am using WPA Encryption). And I am also using your Network-Manager 0.7 PPA also.

P.S. NM 0.7 is working great BTW (Minus the hidden SSID issue).

[Gene Caldwell (gene-caldwell)]

ok, I can confirm that the NM update as well as the gnome-N-M update that came out several weeks ago DID NOT resolve the problem I am having with hidden SSID AP's, however I seem to recall that the wireless drivers had to be updated to accept or pass some new Variable that was needed. I really did not expect to see the hidden SSID problem go away until I saw that the wireless driver was updated....which I have not, and hence, I still have the problem.

[MarcH (marc-h38)]

In case anyone is interested, here is a workaround found for ipw2200 and gutsy. I found these instructions in some ipw2200 forum, and they DO work! Just add ap_scan=2 and an explicit key_mgmt= line in your /etc/wpa_supplicant.conf file.

Example:
ctrl_interface=/var/run/wpa_supplicant
          ctrl_interface_group=admin
ap_scan=2 # mandatory for hidden ssid with ipw2200!
network={
ssid="yourhiddenssid"
key_mgmt=WPA-PSK # mandatory for hidden ssid with ipw2200!
psk="whatever"
}

Check ipw2200 resources for more details.
All software used is 100% gutsy, no patches of any kind.
Sorry, I do not know how to feed network manager with a wpa_supplicant configuration file.

[Schmirrwurst (schmirrwurst)]

Thank you for that work around, but I think the ability beeing able to change and connect a wlan with the user interface (knetworkmanager or under gnome) should work out of the box, it is a core feature !
I'm experiencing the same problem under hardy 5, even when connecting via "connect another network" in knetorkmanager, most of the time the interface is connecting, and then connects the next known network...

[Bill (codyw725)]

I am using NDISWRAPPER with Feisty Fawn 7.04 and can't connect to hidden network. If the patch is simply just changing to AP_SCAN2, where is this change made at? I can just do it manually without applying the patch and see if there is any success. In other news, I am still appalled that this issue has been ongoing as long as it has without anyone catching onto it and incorporating it into future linux distros. I have both FC8 and FC9 Alpha at home, but have yet to try those two to see if there is any changes for the better for hidden SSID's. Will repost what I find out

[Aaron Hatch (wantsportycar)]

I created an account here just to say, "THANKS!" to David Ward. The patch worked great. Why on earth isn't this bug been fixed since it has been known for nearly 2 years!!!!!!!!

[kurbacik (varlott1-deactivatedaccount)]

The patch also works fine for me too on 7.10.0. If only I could connect automatically to the hidden SSID at the university.

[sumguy (sumguy)]

I can automatically connect to hidden AP in either Vanilla Ubuntu (Gutsy) or LinuxMint (Darnya(based on Gutsy)).

I was trying out the latest alpha build of Xubuntu (Hardy) and I guess the bug is back because i was unable to connect to it at all. Also if i tried a second time to connect it would crash network manager.

I'm NOT using WPA/WPA2 or WEP on my network.

Dell INSPIRON 6000
ipw2200

[David Ward (dpward)]

scubanator87 - the issue here is not automatic connection - it's being able to connect period to hidden networks. The issue seems to be that network-manager is not interfacing with several drivers the way it is supposed to (using the wrong AP_SCAN value, for example). I assume then that there is no problem with ipw2200.

Bug 39707 deals with the automatic connection piece that several of us are experiencing as well.

[Christiansen (happylinux)]

After upgrading Hardy beta 5 to Hardy beta 6 connectivity to hidden SSIDs with ipw2200/2915 and atheros based cards (AR5212 chip) don't work any more.

Done some further testing, and found the patched/changed network manager 0.6.6-0ubuntu1 was installed. After experiencing the problem on a couple of different access points types with hidden SSIDs, I reinstalled Hardy beta 6 from scratch just to verify that the problem wasn't caused from the upgrades from beta 4 -> 5 -> 6.

Downgrading the network-manager to 0.6.5 from Hardy beta 5 solved the problem. After a trying a new upgrade to NM 0.6.6 the problem was (of course) back again. This time I then removed these tree packages (sequenced) :
1) network-manager-kde_0.2ubuntu1-0ubuntu12_i386.deb
2) network-manager_0.6.6-0ubuntu1_i386.deb
3) libnl1_1.1-1_i386.deb

and then installed thees tre Hardy beta 5 packages instead :
1) libnl1-pre6_1.0~pre6-6_i386.deb
2) network-manager_0.6.5-0ubuntu16.7.10.0_i386.deb
3) network-manager-kde_0.2ubuntu1-0ubuntu7_i386.deb

Now both ipw2200/2915 based adapters as well as the atheros based were working again
btw. didn't need to change the package - libnm-util0_0.6.6-0ubuntu1_i386.deb.

The changes between the NM 0.6.5-0ubuntu16 and the 0.6.6-0ubuntu1 seems to have made all the these adapters unusable when connecting to hidden SSIDs. And I can't help wondering if the main resaon maby is this, found in the changelog for network -manager:

>network-manager (0.6.6~rc2-0ubuntu1) hardy; urgency=low

> .....<truncated>.....
> * try to drop hidden AP tweaks (lets hope that scan_capa patch in 2.6.24
> fixes this)
> - drop debian/patches/42a_lp50214_gnome464215_fix_hidden.patch
> - update debian/patches/series
> .....<truncated>.....
>
> -- Alexander Sack <e-mail hidden> Wed, 05 Mar 2008 19:06:19 +0100

[Gene Caldwell (gene-caldwell)]

until all the drivers for WiFi cards are changed to add an argument that is now required by NM, its doubtful that wifi will work properly. The fix if the hidden SSID problems is solved in NM with a new parameter argument that is supplied by the wireless driver. there have been no driver updates as of yet that I have seen that include the new argument requirement.

[MichaelM (michael-the-drummer)]

Can confirm this in Hardy Alpha 6. I can not connect to a wireless lan (WPA Enterprise) that has a hidden SSID. This worked fine in 7.10. This is on a Dell XPS M1210 using the Intel 945 chipset.

[Alexander Sack (asac)]

1. atheros should work again with latest upload.

2. drivers for intel 3945 was switched to iwl3945 which still uses a bad mac implementation that lacks the scan_capa capability patches. I won't tweak this unless I know that the mac implementation will stay broken like
now for final. thus pushing milestone further ahead.

[Alexander Sack (asac)]

for ipw2200 i don't know, but most likely it doesn't expose the scan_capa capability as well.

[Christiansen (happylinux)]

Sorry Alexander, but the latest upgrade to Hardy network-manager-0.6.6-0ubuntu2 didn't change the non-working atheros for my AR5211 and AR5212's - when connecting to the different APs with WPA1 and hidden SSIDs I have access to. Rolling back to the network-manager_0.6.5-0ubuntu16.7.10.0_i386.deb as described above still makes all of them work.

Is there any way to make the ipw2200 working for Hardy. As fare as I can find out, NM does not pass the SSID specified in the configuration made with KNM. When I try to connect, executing a "iwconfig eth1" from the CLI, constantly shows no "essid". Executing a "iwconfig eth1 essid MYSSID" while NM tries to connect, makes it connect right away. Is this probably caused by a missing "scan_capa" capability ?. I would be happy to help solve this issue, as I know of a lot of laptop using thees wireless chipset (ipw2200bg/ipw2915abg).

[Rama (rama-buddy)]

David:

can I use your patch to connect to a hidden SSID network with 64/128 bit WEP encryption

thanks

[David Ward (dpward)]

Rama, I am connecting to a network with 64-bit WEP encryption.

The patch I wrote will only fix the issue if you are using the ndiswrapper or prism54 wireless drivers. These are both breaking because NetworkManager is issuing the incorrect AP_SCAN value to wpa_supplicant. Beyond that, there are other drivers that seem to be having different problems.

David

[Rama (rama-buddy)]

David :

Thanks a lot !!!!!!!!!!!!!!!! your patch worked for me and now I am able to connect to hidden SSID networks.

[Matt Palmer (mattpalms)]

I have this problem using Thinkpad T43 (ipw2200). Works fine in Gutsy, not in Hardy (running from live CD). Unhide the SSID on my access point, and the network connects fine (posting using hardy beta on the same machine!).

The syslog shows it tries to connect, but times out. I've attached the relevant extract.

[Todd Morgan (tubatodd)]

I can confirm that this bug is true in the Hardy 8.04 Beta that was just released. I have a Toshiba laptop with a built-in intel 3945 wireless adapter. Fron the nm-applet I can see my neighbors' networks. Since my SSID is hidden, I have to manually configure it. When manually configuring using nm-applet OR the "network" option in System>Administration, it keeps asking for my WEP key which I type in. It acts like it is trying to authenticate, times out and prompts for the WEP key again.

[Steve Langasek (vorlon)]

This bug has unfortunately become a catch-all for any bugs that users are experiencing connecting to hidden networks, which is a problem because there are many, separate bugs involved here - each chipset may require different handling due to driver-specific limitations, and the nature of the hidden SSID problems have changed substantially between dapper and hardy.

Here are the bugs that have been identified and filed separately at this point; if your problem fits the description of one of these, please send any follow-ups to that bug instead of to this one:

* cannot associate with hidden SSIDs using NM 0.6.6-0ubuntu2 and the iwl3945 driver in hardy (driver does not support scan_capa, should be fixed in the kernel) - bug #200950

* cannot associate with hidden SSIDs using NM 0.6.6-0ubuntu2 and the ipw2200 driver in hardy - bug #199679

* NM 0.6.6-0ubuntu2 fails to connect to any wireless networks, instead spins and drives up the system load - bug #204768, fixed in hal

* ralink drivers don't work in hardy - bug #134660

If you are subscribed to this bug because you're experiencing a problem separate from any of those listed above, and you are running the current versions of all packages from hardy (especially hal and network-manager), it would probably be helpful if you would restate your problem here so that we can properly triage the remaining issues.

[Gene Caldwell (gene-caldwell)]

I strongly DISAGREE ! this bug is one bug only. Its a bug report for people that are trying to wirelessly connect to hidden SSID's , and can't. Thats all this bug is about. if you cannot cannot to a hidden SSID then this is where it should be reported. just because you have a different chipset than the next guy makes no difference. Developers may choose to consider each chipset a different bug report, but do not make it a hassle for users to report their bugs.

By trying to open a new bug report for each chipset hides the fact that no one can connect to a hidden SSID and THAT is common to all the people here. it also makes it hard to see that Ubuntu has known about this wireless problem for over 2 years now and does not appear to be any closer to fixing now. there is only only thing that will happen if this bug starts to get reported as some other bug, it won't get fixed. To follow the suggestion above will only server to keep this as an isolated bug for individual wireless users. This 2 year old bug shows that many many users are having this issue, I tried to get this bug addresed for hardy 8.04 by sending emails to any dev emails I could find but all I got was ignored. THIS BUG NEEDS to be addressed and should be given top priority as it is a security risk !

[David Ward (dpward)]

No, Steve is right. This is not one problem, but several problems that have the same apparent outcome, which is making this impossible to fix if it's treated as a single problem. Suppose your computer stopped booting into Ubuntu altogether. Could it be because your hard drive has physically failed? your hard drive's boot sector is overwritten? your hard drive's partition table is overwritten? your BIOS configuration settings are incorrect? your BIOS has become corrupt after a firmware update? Any of these will produce the same end result. But if you want to fix it, you have to focus on and address the cause of the problem at hand for your particular situation, instead of worrying about all the different things that could be causing it not to work.

Steve -- my issue relates to ndiswrapper, and Gene's relates to prism54. Both drivers seem to be fixed by changing the AP_SCAN value that is issued to wpa_supplicant by NetworkManager when those drivers are present. (Fixed, meaning that they will connect when the hidden AP information is entered manually, but they won't connect automatically at login.) I haven't tested it in Hardy yet, but I haven't seen anything in the changelog to suggest that this behavior has been modified at all from 0.6.5-0ubuntu16.7.10.0?

[Gene Caldwell (gene-caldwell)]

I'm not going to pretend I followed your example because you suggested hardware issues in your example David....I read each and every one of the posts in this bug report. and in short, the problem can be divided into exactly 2 groups,, driver issue, and NM. in both cases the result is the same, no network connection. in some of the cases it looks like the issue was NM alone, while in other cases it was BOTH the driver and NM. I guess what I'm irked about is that there seems to be concern for printer drivers working "out of the box" but we can't get the same attention to network connectivity. I think this issue is a show stopper. If I have to expose my wireless network to the bad guys, then I should probably look for another distro.

I'm irked that I have put lots of effort into testing for the last 4 years and providing feed back and can't seem to get this BUG addressed, its like its just too much of a hassle for the devs. to give any attention to. I do not see it as different problems. NM is the front end to other network software and NM brings everything togather to make the network connection. I don't see it as seperate issues, I see it as smaller parts of a common software failing for different reasons. I love the distro, but this is a clear lack of concern for the users for far too long.

[Steve Langasek (vorlon)]

Gene,

On Mon, Mar 24, 2008 at 04:30:48AM -0000, Gene Caldwell wrote:
> I strongly DISAGREE ! this bug is one bug only.

Well yes, that's certainly how it's being treated in the bug report, and
that's what I'm explaining is a problem. There are many discrete bugs being
discussed in this one bug report - to be able to make headway on any of
them, the developers need to be able to track, work on, and propose fixes
for each of these bugs individually, otherwise it's impossible to know when
we're making progress (and impossible to divide up the work between
developers, even when the bugs have unrelated causes).

I'm not just being contrary here, I'm speaking as a developer who is trying
to wade through the many unrelated comments in this report and extract some
semblance of order to be able to help the people who have commented to get
their various bugs fixed - because ultimately that /is/ what I'm trying to
do. Treating each bug separately helps us do that. Lumping all the
unrelated or distantly related bugs into a single bug report does not; it
just makes it more likely that some of the problems will be overlooked.

> By trying to open a new bug report for each chipset hides the fact that
> no one can connect to a hidden SSID

This is not a fact. With the current versions of the kernel and
network-manager, there are many users who *can* connect to hidden SSIDs, and
the remaining issues need to be handled on a per-chipset basis.

[Steve Langasek (vorlon)]

A look at the kernel sources gives me the following list of drivers that implement scan_capa:

ipw2200
hostap
mac80211, which is used by:
 - rt2x00usb
 - rt73usb
 - rt2x00pci
 - rt2500pci
 - rt2400pci
 - rt61pci
 - rt2500usb
 - b43
 - p54pci
 - b43legacy
 - p54usb
 - rtl8187
 - adm8211

This means that, as far as I'm able to determine from the kernel, all of these drivers should be able to connect to hidden SSIDs with Linux 2.6.24-12 and network-manager 0.6.6-0ubuntu3. Gene, this list seems to cover your chipset; can you please confirm that you're running the current versions of these packages, or if not, upgrade and report the results?

David, ndiswrapper is clearly not in this list, so does not support the scan_capa functionality; handling this driver will probably require addition of another quirk in network-manager along with the existing quirk for atheros drivers. On the other hand, it's possible that ndiswrapper does support the necessary interfaces when they're supported by the underlying wrapped driver, so this could be a regression for some other ndiswrapper users... on the gripping hand, it looks like it should only be a performance regression rather than a regression in functionality. So we're probably ok to go ahead with a change like your patch for ndiswrapper; it's probably best if Alexander comments on it first, though, since he knows this code far better than I do.

[Gene Caldwell (gene-caldwell)]

unfortunately the machine with the prism54 wireless is now a production machine, and the current state of the beta 8.10 does not seem a likely test candidate for 8.10 yet. I do have other wireless machines that I can test, can't remember which chipset off the top of my head, but they have the same hidden SSID problem, so I can test those.

[Gene Caldwell (gene-caldwell)]

sorry, don't know why i'm calling it 8.10, I know its 8.04

[Alexander Sack (asac)]

please test the branch above. instructions on how to get it to your disc can be found at the branch url given

to build you can just run

 $ debuild -b

out of the branch directory. use dpkg -i to install the packages for testing.

If you still cannot connect to hidden SSID, please attach your complete /var/log/syslog to the bug and state clearly if you could connect to hidden networks in gutsy.

[Alexander Sack (asac)]

... after this round of testing I will sort the remaining issues to specialised per-chipset bugs.

[Gene Caldwell (gene-caldwell)]

"
 Alexander Sack wrote 1 hour ago: (permalink)

please test the branch above. instructions on how to get it to your disc can be found at the branch url given

to build you can just run

 $ debuild -b

out of the branch directory. use dpkg -i to install the packages for testing.

If you still cannot connect to hidden SSID, please attach your complete /var/log/syslog to the bug and state clearly if you could connect to hidden networks in gutsy.
"

I see no branch above that you are referring to in this post.... will the latest beta release not work ?

[Steve Langasek (vorlon)]

Hi Alexander,

Doesn't this branch clobber the ath_pci quirk from the previous upload?:

- else if (!nm_ap_get_broadcast (ap))
- ap_scan = self->priv->has_scan_capa_ssid && nm_null_safe_strcmp("ath_pci", kernel_driver) ? "AP_SCAN 1" : "AP_SCAN 2";

There is no other mention of ath_pci in the new patch, so it appears atheros chips will now be handled according to the scan_capa value, which I understood was incorrect. Was the AP_SCAN change not necessary, or is this a regression for atheros users?

[Matt Palmer (mattpalms)]

The branch is right at the top of the bug report web page, not in the email.

cheers,

Matt.

On Mon, Mar 24, 2008 at 10:42 PM, Gene Caldwell <email address hidden>
wrote:

> "
> Alexander Sack wrote 1 hour ago: (permalink)
>
> please test the branch above. instructions on how to get it to your disc
> can be found at the branch url given
>
> to build you can just run
>
> $ debuild -b
>
> out of the branch directory. use dpkg -i to install the packages for
> testing.
>
> If you still cannot connect to hidden SSID, please attach your complete
> /var/log/syslog to the bug and state clearly if you could connect to hidden
> networks in gutsy.
> "
>
> I see no branch above that you are referring to in this post.... will
> the latest beta release not work ?
>
> --
> 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: Confirmed
> 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> ...
>

[Alexander Sack (asac)]

> Doesn't this branch clobber the ath_pci quirk from the previous upload?:

there has been a report that the current ath_pci tweak doesn't work for hidden APs. See: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/50214/comments/131

[Alexander Sack (asac)]

> I see no branch above that you are referring to in this post.... will the latest beta release not work ?

https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x.ap_scan

[Fernando Miguel (fernandomiguel)]

On Monday 24 March 2008 05:22:24 Gene Caldwell wrote:
> If I have to expose my wireless network to the bad guys, then I should probably look for another distro.

[off topic]
SSID hidding is in NO situation a good way to defend yourself. Its quite easy to either listen to packets or injecting packets to find out the real SSID even if hidden.
Its as secure as wep or mac address filtering. And it causes lots of problems when roaming between wifi nodes.
If hardware capable please migrate to WPA/WPA2 and a proper password scheme.
[/off topic]

Still this does not neglet the fact that Ubuntu should, and is working for some ppl, when it encounters an hidden SSID WiFi network.

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by...

[Alexander Sack (asac)]

i did some cleanups of the hidden ssid tweaks on the branch. Please test!!

The new behaviour is:

  * 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 tools 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
    - update debian/patches/42b_fix_ap_scan_hidden.patch

[Alexander Sack (asac)]

one more addition: to install the build dependencies to build the branch, run:

 sudo apt-get build-dep network-manager

[Alexander Sack (asac)]

note: the branch has been reported to fix hidden ssid for ipw2200 in bug 199679. please give feedback for your driver/chipset as well.

[redacted (redacted)]

This bug did not occur for me in Dapper, Edgy, or Gutsy. It is occurring in Hardy. I use the ipw3945 driver.

[Alexander Sack (asac)]

blue774, please test the bzr branch you can find at the top of this bug reports web-page

[Steve Langasek (vorlon)]

bluej774,

On Tue, Mar 25, 2008 at 06:43:22PM -0000, bluej774 wrote:
> This bug did not occur for me in Dapper, Edgy, or Gutsy. It is
> occurring in Hardy. I use the ipw3945 driver.

Hardy does not use the ipw3945 driver, but rather the iwl3945 driver. The
issue with iwl3945 connectivity is bug #200950; please test the indicated
branch following Alexander's instructions.

[Christiansen (happylinux)]

Connecting to hidden WPA secured SSID with Atheros based adapters and Hardy still does not work. The labtops was updatet from main repository as of 2008-03-26 21:20 UTC.

First build network-manager.0.6.6-0ubuntu4-test1 (2008-03-24 or branch ID109) and tested both Internal IBM and external Cisco AIR-CB21AG PCMCIA adapters (with internal switched off in BIOS) with no luck. Test was done against two different APs- a WPA1 and a WPA2 secured.
First then found out that there was a network-manager.0.6.6-0ubuntu4-test1 (2008-03-25 or branch ID110). Build this one and did the same test as above without better luck - this test was only done against the WPA1 secured AP.

BTW. Connecting with Kubuntu Gutsy or Hardy Beta 5 (NM 0.6.5) from the same laptops works okay.

Attatches syslog from the latest failed connection attempt with internal adapter.

[Christiansen (happylinux)]

Tested 2 different ZyXEL based USB adapters too - 3COM OfficeConnect and ZyXEL AG-220 - without better luck.

Used network-manager.0.6.6-0ubuntu4-test1 (2008-03-25 or branch ID110), and connecting to a WPA1 secured AP with hidden SSID.

BTW. Both adapters work with Gutsy.

Attached syslog from failed connection attempt with 3COM OfficeConnect stick.

[Alexander Sack (asac)]

christiansen, does any of your chipsets work with broadcast SSID (non-hidden)? or is everything broken for you?

[Alexander Sack (asac)]

anyone here can test this branch with ndiswrapper?

[sip (pankovs)]

It's working for me! iwl3945, hidden SSID, no security, branch 110.

[sip (pankovs)]

Only one minor problem remains. After restart network manager doesn't automatically reconnect to my hidden network, though it exists in the wireless networks list.

[Christiansen (happylinux)]

> Alexander Sack wrote
> christiansen, does any of your chipsets work with broadcast SSID (non-hidden)? or is everything broken for you?

When UNHIDING the WPA2 secured SSID, connecting with Hardy and network-manager.0.6.6-0ubuntu4-test1 (2008-03-25 or branch ID110) seems to work fine for both the Atheros and the ZyXEL chipset - Rebootet 2 times with each and got connected. I will do further testing on the subject for a WPA1 secured network later today.

BTW. The connection time SEEMS a to take a little longer than for Gutsy, but I haven't timed it.

[Alexander Sack (asac)]

christiansen,

for the chipsets that don't work, does iwconfig ever show any essid?

(run iwconfig repeatetely while network manager is spinning)

If it doesn't, is setting essid through iwconfig while connecting helping you? to do so, try to connect to hidden network through NM, then set essid to whatever your hidden net uses and after that run a scan (sudo iwlist scan) to help NM get the bssid.

[Alexander Sack (asac)]

sip,

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

[Christiansen (happylinux)]

Hi Alexander,

Did some further testing, using the buildin Atheros on one laptop. First I used unhidden SSID on the WPA1 secured AP, as you asked for. The connection was established, and network communication was okay.

Then I shutdown the laptop, and form an other computer enabled hiding of the SSID again. A littel later I booted up the laptop once more, and could not get connectet - tried manually a couple of times.

Attached the syslog for both the connection attempt with and without hidden SSID.

Restarted the laptop, still with the AP SSID hidden, and did the tests you asked for too. As you hopefully can see from the attached iwconfig/iwpriv logfile piped out while executing the commands and connecting with NM, the ESSID is set by NM right when it started connecting. The iwpriv scan didn't seem to make any difference, and I didn't get connected at all.

I will now try to make some tests with the ZyXEL USB adapters too...

[Christiansen (happylinux)]

The syslog with hidden SSID

[Christiansen (happylinux)]

The syslog without hidden SSID

[Christiansen (happylinux)]

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.

[sip (pankovs)]

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

[Martin Pool (mbp)]

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.

[Martin Pool (mbp)]

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.

[Martin Pool (mbp)]

I can't reproduce this problem after rebooting.

[Alexander Sack (asac)]

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

[Launchpad Janitor (janitor)]

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

[Luke Hoersten (lukehoersten)]

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.

[Gene Caldwell (gene-caldwell)]

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 ?

[Gene Caldwell (gene-caldwell)]

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

[Alexander Sack (asac)]

Gene, could you test and report?

[Gene Caldwell (gene-caldwell)]

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.

[Steve Langasek (vorlon)]

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.

[Gene Caldwell (gene-caldwell)]

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.

[Matt Palmer (mattpalms)]

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

[Gene Caldwell (gene-caldwell)]

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

[Matt Palmer (mattpalms)]

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

[Gene Caldwell (gene-caldwell)]

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.

[Dima Ryazanov (dima-gmail)]

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?

[Christiansen (happylinux)]

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.

[Alexander Sack (asac)]

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

[Alexander Sack (asac)]

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

[Alexander Sack (asac)]

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

[Alexander Sack (asac)]

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

[Alexander Sack (asac)]

Luke,

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

[Christiansen (happylinux)]

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 ?

[Matt Palmer (mattpalms)]

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

[Gene Caldwell (gene-caldwell)]

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

[Martin Pool (mbp)]

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/>

[Alexander Sack (asac)]

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

[Matt Palmer (mattpalms)]

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

[Christiansen (happylinux)]

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

[WhyWontThisWork (jsweepstakes)]

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

[Christiansen (happylinux)]

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.

[joshua (gongjh01)]

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!

[Dave Vree (hdave)]

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?

[Diegstroyer (diegstroyer)]

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

[Gilberto "Velenux" Ficara (g-ficara)]

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.

[Sebastian Schuberth (sschuberth)]

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.