A bug between Atheros Communications AR5212 802.11abg nic and Ubuntus network applet

Bug #111068 reported by Mickey
24
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

I want to be helpful but not sure exactly where the problem lies. I will walk you through my doings, it is a bug but I am unable to make sense of it. Due to its extreme complexity in nature I am actually writing this to you on the wireless that has the bug! please readon.

More details:

I have a hidden wireless network at home running off of trendnet router.

My Actions:

1. Boot ubuntus live-CD up (Feisty).

2. Restricted devices manager picks up Atheros Communications AR5212 normally.

3. It shows all the possible wireless networks within the range of the perimeter.

4. I Right click on connect to other network, select my networks SSID, Wep Hex enter it and hit connect.

5. The logo begins to spin and it seems it is trying to connect.

Problems:

A. It times out connecting to the network and gives up.

B. If it does connect to the network it does not get assigned computer name, gateway, etc and so fourth.

C. It does get connected to the network and all is ok but disagrees with the applet.

D. Disabling the onboard wired jack (eth0) and retrying (ath0) sometimes seems to work??

Tried:

A. Clicking manual configuration enter all the details but it refuses to connect.

Luck:

Ubuntus network utility crashed and gnomes network utility was able to get me on the wireless network. I am afterall speaking to you on it, but the applet is gone. Because as long as ubuntus applet is running. It seems I will never be able to connect to the network at all.

Reproduction:

Speechless, I do not know how to reproduce the same exact steps to get the problem or avoid it. The beta versions of feisty had the issue but a bit better.

It is a bug but what kind? as you notice I am speaking to you again right now on the bugged live cd booted in ram. Only because of luck on this boot.

Revision history for this message
Christiansen (happylinux) wrote :

I too have been experiencing these problems with the Atheros 5212 Chipset (both IBM Thinkpad buildin and Netgear external PCMCIA/PCI adapters) and network-manager when connecting to hidden access points - though all my adapters work with K/Ubuntu 6.10. I have tried to locate the problem, as I suspected the driver to be the problem (Ubuntu Restricted Modules), but must admit I was suprised to find that it's the network-manager or knetworkmanager that must be the problem.

Yesterday I tried to use wpa_supplicant from the console line instead. First I created a wpa_supplicant.conf file from the template under /usr/share/doc/wpasupplicant/templates, then :
sudo iwconfig ath0 essid MYSID
sudo wpa_supplicant -Dwext -iath0 -c/etc/wpa_supplicant.conf -dd
sudo dhclient

Works every time and after reboot too, so now I can't help suspecting the network-manager. What's odd is that K/Ubuntu and network-manager seems to work flawless with Intel 2915A/B/G and 2200B/G (Buildin IBM Thinkpads) adapters against the same hidden access point.

I seems that problems much alike this have been reported in several other bugs (often under linux-restricted-modules) in launchpad under Ubuntu and network-manager since version 7.04, but a great deal of the bugs unfortunately don't state which WiFi chipset is used. But why can't network manager handle the Atheros chipset against hidden AP, when it can handle Intels flewlessly ? - could the difference between hardware be the reason that this bug has not yet been solved ?.

Revision history for this message
Christiansen (happylinux) wrote :

Sorry, forgot to mention that my comment above is excactly the same for 7.10 - Gutsy Tribe 1+2+3.

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 111068] Re: A bug between Atheros Communications AR5212 802.11abg nic and Ubuntus network applet

On Mon, Jul 23, 2007 at 08:48:01PM -0000, Christiansen wrote:
> I too have been experiencing these problems with the Atheros 5212
> Chipset (both IBM Thinkpad buildin and Netgear external PCMCIA/PCI
> adapters) and network-manager when connecting to hidden access points -
> though all my adapters work with K/Ubuntu 6.10. I have tried to locate
> the problem, as I suspected the driver to be the problem (Ubuntu
> Restricted Modules), but must admit I was suprised to find that it's the
> network-manager or knetworkmanager that must be the problem.
>
> Yesterday I tried to use wpa_supplicant from the console line instead. First I created a wpa_supplicant.conf file from the template under /usr/share/doc/wpasupplicant/templates, then :
> sudo iwconfig ath0 essid MYSID
> sudo wpa_supplicant -Dwext -iath0 -c/etc/wpa_supplicant.conf -dd
> sudo dhclient
>
> Works every time and after reboot too, so now I can't help suspecting
> the network-manager. What's odd is that K/Ubuntu and network-manager
> seems to work flawless with Intel 2915A/B/G and 2200B/G (Buildin IBM
> Thinkpads) adapters against the same hidden access point.
>
> I seems that problems much alike this have been reported in several
> other bugs (often under linux-restricted-modules) in launchpad under
> Ubuntu and network-manager since version 7.04, but a great deal of the
> bugs unfortunately don't state which WiFi chipset is used. But why can't
> network manager handle the Atheros chipset against hidden AP, when it
> can handle Intels flewlessly ? - could the difference between hardware
> be the reason that this bug has not yet been solved ?.
>

So what driver is used for your card?

 - Alexander

Revision history for this message
Christiansen (happylinux) wrote :

Hi Alexander

The driver is part of the Linux-restricted-modules package, isn't that right ?.
My feisty uses version 2.6.20-16.29 of this package, and in my Gutsy it's now on 2.6.22-8.4.
According to dmesg, the madwifi driver reports 0.9.3.1 on both my Feisty and Gutsy laptop (no fiddling with self compiling of any sort !).

I reckon that another bug (#50204) is discussing the Athero and Wireless-Tools incompatibility, but according "iwconfig -v" on Gutsy I'm using Kernel and ath0 driver compiled with Wireless-Extensions v22. But doesn't connecting succesfully with wpa_supplicant, as described earlier in this bug, include using this Extention ?

Please feel free to ask if I could supply any additional info or testing to solve this bug.

Christiansen

Revision history for this message
Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

Changed in network-manager:
status: New → Incomplete
Revision history for this message
Mickey (michael.z) wrote :

Hello,

I'm the original bug submitter right now I'm not on ubuntu on this box. Thanks to other posters stepping in the bug is not fixed with ubuntu. I end up using: iwconfig interfacename essid channel 6 mode managed key soso open so on arguments. Then I must do ifdown interface and ifup interface again. partially configuring within gnome, partially configuring within the command line. Every time, so it does not truly work but the card does work so to speak.

Revision history for this message
Christiansen (happylinux) wrote :

If I'm "other posters" mentioned by Mickey, that have affected that the bug not to become solved, I'm very sorry.
I may have misread the originally bug description, as I now reckon that this bug probably concerning the wep-hex encrypted with hidden SSIDs. My problem with WPA on hidden SSIDs was solved in Gutsy final, as I found and followed the bug "https://bugs.launchpad.net/bugs/50214" concerning this specific issue.

Revision history for this message
brandon.n.atkinson (brandon-n-atkinson) wrote :
Download full text (3.5 KiB)

This issue is still alive and well, and in my case, the ESSID of the network is not hidden.
Also, I'm seeing the following behavior on Debian Etch as well as Ubuntu (I have one identical machine on each distro).

Wireless AP:
linksys WRT54GL v1.1 with DD-WRT v23 w/ VPN firmware
128-bit WEP Encrypted with hex key

Connecting host(s) hardware:
2 identical IBM Thinkpad x31 laptops, with IBM a/b/g wireless II (Atheros 5212 based),
One running Debian Etch, one running Ubuntu 7.10 Desktop
using the default madwifi driver (ath_pci) on Ubuntu with the default x86 kernel.

Symptoms:
Network Manager can connect via wired connection immediately, no problems

Network Manager can see my ESSID (ansible) and recognizes it is WEP encrypted

Network Manager can see my neighbor's ESSID (default) and recognizes it as unencrypted

Network Manager takes a long time to connect to any wireless source, but it actually can connect consistently to the non-WEP access point.

NM is completely unable to connect to my WEP encrypted access point. I've noticed that NM is able to associate the NIC with my WEP access point semi-consistently, but after that, it reports "Waiting for Network Key", and I type in the correct WEP key in the dialog. After I've hit OK in the dialog, it still is "Waiting for the Network Key", but interestingly enough, an "iwconfig" reports a bogus key has been set by NM, which doesn't even look close to what I typed in. Strange.
After all is said and done, the connect attempt times out.

Another interesting fact is that I'm able to connect consistently and quickly if I simply associate, set WEP key, and call dhclient manually. I'm also able to connect reliably with wlassistant (which may be because it is really calling the iwconfig commands like I would by hand, but I'm not sure).

Oh, and one more thing... I only started having this problem sometime after upgrading to 7.10. Ever since that upgrade things have been flaky with NM.

lspci output:
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc R...

Read more...

Revision history for this message
brandon.n.atkinson (brandon-n-atkinson) wrote :

Some more information...

I just connected to my WEP encrypted access point, after trying for days. Now I can't connect again.

Now I'm having trouble connecting to the non-encrypted access point as well.

This is actually typical of my experience with NM... extreme flakiness. I'm having trouble getting to the root of the problem because the symptoms seem to change at will. The fact that it's flaky connecting through my a/b/g card is consistent though.

Another thing I have noticed, is that when it has a hard time connecting, it seems to scan all available bands the card has to offer, it jumps from 802.11a to 802.11g, and back. It tends to spend more time on the 802.11a band for some reason, even though I do not have any 802.11a networks anywhere within range.... weird.

----

I just tried a little something, based on my last observation... that NM seems to force the driver into the 802.11a band a lot ... Stumbled onto a page that mentioned this might help...

% iwpriv ath0 mode 3

I'm no expert, but isn't this a driver specific command?

I tried this, and I was immediately able to connect to my AP and the my neighbor's unsecured AP. It still seems that NM is somewhat flaky even with this setting, since it seems to want to jump to my neighbor's AP when I explicitly tell it to connect to my AP. After selecting my AP a couple of times, it seems to finally listen and connect to my AP, however.

Revision history for this message
brandon.n.atkinson (brandon-n-atkinson) wrote :

Sorry, me again....

I did a little research, and this command:

% iwpriv ath0 mode 3

Is a private ioctl call that tells the madwifi driver to only connect via 802.11g mode.
This seems to fix the problem I was having connecting.

However, what technique is NM using to scan/connect that is causing the madwifi driver to wig out and keep trying the 802.11a band?
It seems strange that the wlassistant has no problem connecting while NM has severe difficulty....

Changed in network-manager:
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
Cory Dodt (corydodt) wrote :

I am having the same issue as brandon atkinson, it seems, because "iwpriv ath0 mode 3" worked for me as well after 4 days of wireless outage. The bug was *fixed* at some point in the recent past, because I've been using hardy for about one month, and my wireless driver has worked the entire time. Then an update to, I think, NM caused it to stop working again, and no kernel upgrades or messing around have fixed it. My stack:

- madwifi (current nightly snapshot)
- hardy heron, up-to-date as of 2008-03-10.
- currently running Linux 2.6.24-12-generic

And this, in rc.local:
   modprobe ath_pci
   iwpriv ath0 bgscan 0

This config worked fine for me on G networks both WPA and unencrypted.

Around, approximately, Thursday 2008-03-06 an update went into hardy that broke the wireless for me. No connection to either WPA or unencrypted networks with madwifi.

For a while I switched to ndiswrapper'd drivers, which worked, but ONLY on unencrypted networks. No WPA.

Finally today I found this bug, and brandon's post above, turned off ndiswrapper, and tried iwpriv ath0 mode 3. Bingo, everything works again in WPA. So I believe there is a real bug here; it seems to be kernel-independent (it is definitely OS-independent, as I can boot to Leopard and use the wireless network). It may affect ndiswrapper and madwifi, or only madwifi (if ndiswrapper's wpa problems were r/t something else).

What I expected to happen: connect to my 802.11g (WPA) network as usual, with the above stack and rc.local.

What actually happened: I have to add iwpriv ath0 mode 3 to connect to any 802.11g network with madwifi.

Revision history for this message
Mark Rijckenberg (markrijckenberg) wrote :

Please follow these instructions to install and use wicd (wifi network manager):

http://wicd.sourceforge.net/download.php

Please let us know if wifi and WPA2 encryption works better using wicd

Revision history for this message
David Clarke (daclarke) wrote :

I'd like to second Cory Dodt's comments - this is exactly what I saw - WEP wifi borked by some update that went in to hardy a few days ago. The "iwpriv ath0 mode 3" command also resolves for me. Deleting the wireless network from network manager makes no difference.

I'm running hardy on a T41 thinkpad, lspci says
--
02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
--
Before finding this I tried kernels 2.6.24-8-generic/2.6.24-11-generic/2.6.24-11-386 and 2.6.24-12-generic but all failed.

Revision history for this message
René Fritz (ubuntu-colorcube) wrote :

Until NM 0.6.5 wlan in principle worked for me. Sometimes I lost the connection and sometimes connecting just didn't worked until I restarted NM. (feisty, gutsy, hardy)

Recently I upgraded to 0.6.6 and no wlan connection was possible. Reinstalling 0.6.5 fixed it.

Using ...

% iwpriv ath0 mode 3

... makes 0.6.6 connecting again.
Also I think NM works more reliable with this setting, but the time will show.

My config:
Thinkpad T43
Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
hardy
kernel 2.6.24-11-generic, 2.6.24-12-generic
madwifi/ath_pci
knetworkmanager
WPA2

Btw: wcid didn't worked for me - just no wlan detected

Revision history for this message
chefweb (ulrich-timm-uni-rostock) wrote :

some problem here:
Thinkpad T43 with Atheros 5212.
I have the connection problem since the upgrade to nm 0.66

Revision history for this message
caribo (paul-caribo) wrote :

Same problem using Atheros AR5413 802.11abg NIC (rev 1)

Network manager hangs around until poked with iwpriv ath0 mode 3, or iwconfig ath0 essid MYSSID..

Alternative workaround is to set router to support g only. Since doing this NetworkManager connects automatically, BUT now knetworkmanager repeatedly reports that it has found a new network even though it is already connected. suspect this is something to do with bgscan??? This happens consistently regardless of whether the wireless SSID is hidden or not.

kernel: 2.6.24-12-generic

iwconfig ath0

ath0 IEEE 802.11g ESSID:"MYSID" Nickname:""
          Mode:Managed Frequency:2.462 GHz Access Point: 00:AA:AA:AA:FF:FF
          Bit Rate:54 Mb/s Tx-Power:17 dBm Sensitivity=1/1
          Retry:off RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=54/70 Signal level=-42 dBm Noise level=-96 dBm
          Rx invalid nwid:22169 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

lspci -v

02:03.0 Ethernet controller: Atheros Communications, Inc. AR5413 802.11abg NIC (rev 01)
        Subsystem: Atheros Communications, Inc. Unknown device 1062
        Flags: bus master, medium devsel, latency 168, IRQ 7
        Memory at f8fe0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2

dpkg -l | grep network-manager

ii network-manager 0.6.6-0ubuntu1 network management framework daemon
ii network-manager-kde 1:0.2ubuntu1-0ubuntu12 KDE systray applet for controlling NetworkMa

Revision history for this message
Mario Limonciello (superm1) wrote :

I ran into recent problems with this as well. The iwpriv mode switch does absolve them.

Revision history for this message
mparem (mparem) wrote :

It may be does not fit to current topic exactly, but I see the same problem with the iwl4965 interface on my t61p laptop running Xubuntu hardy, but I probably have no chance to use iwpriv command:

t61p:~$ iwpriv iwl0
iwl0 no private ioctls.

Revision history for this message
caribo (paul-caribo) wrote :

@mparem

I am pretty sure that iwpriv requires root privileges.

Try:-

sudo iwpriv iwl0

Revision history for this message
luke16 (luke16-gmail) wrote :

Using asus with hardy beta. When I try the iwpriv command with mode 3 argument, I get an invalid command error. Is there any other way to do this?

Revision history for this message
Christiansen (happylinux) wrote :

luke16, you could try and have a look at bug #208306 "[ath_pci] cannot connect to hidden ap", if your chipset is Atheros (I've seem atheros and asus mentioned another place". Steffen has provided a patch that solves the hidden APs and Atheros problem for me, which is not in the main channels (yet ??).

Revision history for this message
luke16 (luke16-gmail) wrote :

Well, all of the access points that I was trying to connect to weren't hidden, so I would assume that is unrelated.

And sorry, I completely forgot to mention that I am using atheros with an asus eeepc.

Since iwpriv ath0 mode 3 didn't work, I managed to fix this problem by just going into the network config and typing out my AP manually. This bug only started happening to me after I updated today, so whatever caused this is fairly new, since the last time I ran the software updater was less than a week ago.

--thanks

Revision history for this message
Christiansen (happylinux) wrote : Re: [Bug 111068] Re: A bug between Atheros Communications AR5212 802.11abg nic and Ubuntus network applet

Okay, that it's not hidden is of cause another matter then.

BUT between your last update and the update yesterday there has been
released another network-manager-0.6.6-0ubuntu4. So even if the bug I
mentioned (208306) is concerning hidden SSIDs, I would suggest that you
try to install thees to packages from Steffens repository
"nmutil-0.6.6-0ubuntu5-ppa2_YourProcessor.deb" and
"network-manager-0.6.6-0ubuntu5-ppa2.deb", because they change the AP
scanning mode for Atheros.

Get them here if you would try anyway :
http://ppa.launchpad.net/sroecker/ubuntu/pool/main/n/network-manager/

Regards
 Christiansen

> Well, all of the access points that I was trying to connect to weren't
> hidden, so I would assume that is unrelated.
>
> And sorry, I completely forgot to mention that I am using atheros with
> an asus eeepc.
>
> Since iwpriv ath0 mode 3 didn't work, I managed to fix this problem by
> just going into the network config and typing out my AP manually. This
> bug only started happening to me after I updated today, so whatever
> caused this is fairly new, since the last time I ran the software
> updater was less than a week ago.
>
> --thanks
>
> --
> A bug between Atheros Communications AR5212 802.11abg nic and Ubuntus
> network applet
> https://bugs.launchpad.net/bugs/111068
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
luke16 (luke16-gmail) wrote :

It's working now after the latest update, so thanks.

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

hidden SSID for ath_pci should be fixed in 0.6.6-0ubuntu5. Have fun!

Changed in network-manager:
status: Triaged → Fix Released
Revision history for this message
Stivo (stivo) wrote :

Well i have a thinkpad t42 with heron beta, same wlan card, and all the updates that are available now.
I still can not connect to any wireless lan except if I use:

sudo iwpriv ath0 mode 3

So it is not fixed yet...

Revision history for this message
Stivo (stivo) wrote :

ok since the last update it seems to work again.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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