UNR Ath9K unstable connection

I can comfirm this bug on a Acer Extensa 5430-5855. Atheros Communications Inc. AR928X Wireless Network Adapter .Connection drops often. Large file transfers from bit torrent or scp can force this condition. Started out default. Network Manager wouldn't reconnect on it's own. Tried jaunty-backports no effect. Tried Wicd. still dropping connections but will reconnect on it's own more often. Also tried compile compat-wireless stable module no effect. Tried compiling bleeding edge driver but error in the source code so stopped. Tried bluetooth coexistence to no effect. Disabled bluetooth to no effect. Also it is noteworthy that the bitrate in iwconfig for wlan0 is Bit Rate=0 kb/s. I had that issue with a broadcom driver a few distros back and the results were similiar to this.

All worked fine in hardy never had an issue on the same hardware. Only good thing i can say is when connected scp speeds are 5MB/s where in hardy they were 2.5MB/s.

Router Linksys wrt160n DD-WRT v24-sp1 (07/27/08) vpn
(SVN revision 10011)
This is current but i have tried multiple versions including the stock firmware to rule this out.
Settings mixed mode. WPA2 but again I have tried g only, n only, and WPA . all have issues.

uname -r
2.6.28-11-generic ** running this one clean install but have tested all below kernels problem persists
uname -r
2.6.28-12-generic
uname -r
2.6.28-11-server
uname -r
2.6.28-12-server

lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
00:01.0 PCI bridge: Acer Incorporated [ALI] Device 9602
00:05.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 1)
00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 2)
00:07.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 3)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode]
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3a)
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 11h HyperTransport Configuration (rev 40)
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 11h Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 11h DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 11h Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 11h Link Control
01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics]
01:05.1 Audio device: ATI Technologies Inc RS780 Azalia controller
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5764M Gigabit Ethernet PC...

I can confirm this bug. I have two Asus Eee PCs right beside each other on the same network. One is a 1000 model with RaLink RT2860 wireless and it works perfectly. Strong signal, connects dependably and quickly. But I also have an Eee PC 1000HE beside it running the Atheros AR928X wireless and often it will not connect to the network without multiple attempts and the signal strength is very weak (29% for Atheros versus 100% for RaLink).

Oh, and I'm running Ubuntu 9.04 NBR with kernel 2.6.28-11-generic on both machines.

Can you please try lbm (linux-backport-modules) or compat-wireless:

http://wireless.kernel.org/en/users/Download

I tried backports and it fixes the problem with the connection sometimes taking multiple tries and the problem of the connection just dropping for no apparent reason. However, the signal strength problem remains. I helped a friend by an EeePC because my 1000 works well. But his is a 1000HE and uses different wireless hardware.

Unless someone can tell us that we are missing a setting and this really isn't a bug, we are returning the ASUS netbook and going shopping for a different model in the next couple days. Right now we are looking hard at the MSI Wind netbook and Acer Aspire One models.

A side request (only indirectly related to the bug): If anyone knows of the newest models of MSI Wind or Acer Aspire Ones with regard to 9.04 I'd like to know more.

Thanks Luis.

Hi, I have a brand new eee 1000HE running 9.04 NBR with updates applied recently. Running kernel 2.6.28-11-generic.

I haven't seen this problem yet, either on an 802.11b network with an older Apple AP, nor on an 802.11g network (not sure what AP or specific configuration it has but could find out if anyone is curious).

Aha, I don't have an Atheros wireless interface, it's an RaLink RT2860. So I guess some 1000HE's have Ath's and some have this...

On Sun, Jun 7, 2009 at 12:31 PM, petrock<email address hidden> wrote:
> I tried backports and it fixes the problem with the connection sometimes
> taking multiple tries and the problem of the connection just dropping
> for no apparent reason. However, the signal strength problem remains

A patch has been posted for this, it hasn't yet been merged into
wireless-testing though.

> . I
> helped a friend by an EeePC because my 1000 works well. But his is a
> 1000HE and uses different wireless hardware.

So why are you reporting this on the same bug report?

> Unless someone can tell us that we are missing a setting and this really
> isn't a bug, we are returning the ASUS netbook and going shopping for a
> different model in the next couple days. Right now we are looking hard
> at the MSI Wind netbook and Acer Aspire One models.

You need to provide more details in order to allow developer help you.
Pleas read:

http://wireless.kernel.org/en/users/Documentation/Reporting_bugs

  Luis

do something !

On Wed, Jun 24, 2009 at 6:32 AM, goto<email address hidden> wrote:
> do something !

Huh?

I think he's trying to communicate his desperation :p

Sincerely Yours
Nicholas Ipsen

On Wed, Jun 24, 2009 at 9:53 PM, Luis R. Rodriguez <email address hidden> wrote:

> On Wed, Jun 24, 2009 at 6:32 AM, goto<email address hidden> wrote:
> > do something !
>
> Huh?
>
> --
> UNR Ath9K unstable connection
> https://bugs.launchpad.net/bugs/378156
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager” package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: network-manager
>
>
> I'm having wireless connectivity problems with my netbook. The connection
> alternates between being fine (short periods) and no connectivity (longer
> periods), resulting in upwards of 70% packet loss over a prolonged period of
> time.
>
> These problems only occur with the Ubuntu Netbook Remix install. The
> seperate WinXP install has no wireless connectivity issues. The problem is
> also just with wireless, as a wired connection does not display any
> packetloss.
>
> I'm using network-manager, but I've also tried wicd with no improvement.
> The channel being used by the router also does not seem to matter, (I've
> tried 1 through 11.)
>
> The only thing that I can see that seems off in any of the settings (full
> output below):
> IE: IEEE 802.11i/WPA2 Version 1 (from iwlist)
>
>
> The network I'm using is 802.11bgn, not 802.11i. I can't seem to find this
> setting anywhere else though. I'm trying to use 802.11n, or g in the worst
> case.
>
>
>
> Router: Dlink DIR-655
> Netbook: Asus EeePC 1000HE
> Dual-Booting UNR Jaunty (2.6.28-11-generic) and WinXP
> Driver: Ath9k
>
> ifconfig wlan0
> [code]
> wlan0 Link encap:Ethernet HWaddr 00:22:43:77:4a:34
> inet addr:192.168.0.198 Bcast:192.168.0.255 Mask:255.255.255.0
> inet6 addr: fe80::222:43ff:fe77:4a34/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:11492 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8897 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:13632811 (13.6 MB) TX bytes:1665099 (1.6 MB)
> [/code]iwlist:
> [code]wlan0 Scan completed :
> Cell 01 - Address: 00:22:B0:B8:25:55
> ESSID:"Minerva"
> Mode:Master
> Channel:2
> Frequency:2.417 GHz (Channel 2)
> Quality=109/100 Signal level:-48 dBm Noise
> level=-118 dBm
> Encryption key:on
> IE: Unknown: 00074D696E65727661
> IE: Unknown: 010482848B96
> IE: Unknown: 030102
> IE: Unknown: 2A0100
> IE: Unknown: 32088C129824B048606C
> IE: IEEE 802.11i/WPA2 Version 1
> Group Cipher : TKIP
> Pairwise Ciphers (2) : TKIP CCMP
> Authentication Suites (1) : PSK
> IE: Unknown:
> DD180050F2020101000003A4000027A4000042435E0062322F00
> IE: Unknown:
> 2D1A4E101BFFFF0000000000000...

I've been running stock Ubuntu 9.04 on an EEE 701 with an AR242x adapter and seeing similar problems. iwconfig reports almost constant changes (changing several times per second) to the bit rate on the wlan0 adapter when connected to an access point in the same room, with the values ranging from 1 Mb/s to 36 Mb/s. Link quality and noise level values stay the same throughout.

Installing the backported drivers in the linux-backports-modules-jaunty package appears to resolve the issue; the bit rate remains near-constant at either 48 or 54 Mb/s (with a much slower rate of change), signal strength is comparable to other wireless-enabled computers I have available that use the same access point, and download speeds are consistently good (I can download a 900 MB file over HTTP from a local server at a constant rate of 3 MB/s) and without apparent episodes of packet loss.

If it would help, I can revert back to the stock driver and provide whatever debugging information is required, but based on my experience, I'd suggest simply trying to get the relevant driver(s) into an update.

hi,

when i was on jaunty, installing the backports module on my eeepc 1000HE solved the problem completely: i had very reliable wireless. Now i upgraded to karmic and the problem is back, it doesn't improve after installing linux-backport-modules-karmic. my logs are filled with

<pre>
[ 2340.239872] ath9k: DMA failed to stop in 10 ms AR_CR=0xdeadbeef AR_DIAG_SW=0xdeadbeef
</pre>

i get the symptoms described above: need multiple tries to connect, it disconnects every once in a while, and when connected it seems to be intermittent. problem seems to be worse after resume.

I have the unstable connection problem with an ar928x wireless card, using the ath9k driver. The card is in a brand new Dell Inspiron 1440.

I first noticed the problem in a standard 9.04 installation, where the connection would stop working for a 30s-1 minute period. NetworkManager wouldn't report any problems, but dmesg showed wlan0 deauthenticating and doing a "direct probe" to the AP. After a while, the log becomes filled with this loop of deauth and re-association with the AP. Installing linux-backports-modules-jaunty had no effect.

I am now trying again in 9.10 Alpha 5, with linux-backports-modules-karmic installed. I have the same problem, and I would even say it is worse. Every 30 seconds I am disconnected, although the signal strength remains full and NetworkManager reports no problems. The output of dmesg looks the same as before.

I will add the various logs to this bug as soon as I can find a network cable to get that laptop on the network.

This bug may be a duplicate of https://bugs.launchpad.net/bugs/407040 - could the others with symptoms confirm?

hi,

possibly related:

https://bugs.launchpad.net/linux/+bug/414560
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/379096
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/407040 as mentioned above
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/414560

http://bugzilla.kernel.org/show_bug.cgi?id=13807
http://bugzilla.kernel.org/show_bug.cgi?id=13581
http://bugzilla.kernel.org/show_bug.cgi?id=13630

greetings,
frank

hi, i've downloaded the source of backports-modules-karmic and i'm experimenting a bit.

my first try was this one: https://lists.ath9k.org/pipermail/ath9k-devel/2009-August/002277.html but it doesn't seem to be the culprit (i commented out the relevant code and still the connectivity is bad).

i tried to revert the dynamic power management (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3cbb5dd73697b3f1c677daffe29f00ace22b71e9) as described in kernel bug 13807, but the patch doesn't revert properly anymore (seems al ot of restructuring was done since). "iwconfig wlan0 power off" makes no difference either.

other suggestions for things to try are welcome.

hi,

seems i'm having a bit more success now. i used today's wireless-testing now with the two changes (rfkill disabling and no dynamic power management by default). my system seems to behave up to now (i managed to upload the debs without connection stalls)

i put them here (don't know how to make a PPA yet)
http://front18.smartlounge.be/ath9k-rebuilt-090909.zip (no garantees they will work / not eat your hardware but on my system they work). after installing either reboot either remove all mac80211 related modules and reinsert them. after installing now my system shows "power: off" when i do iwconfig wlan0.

i wonder if they make a difference somewhere else. i'm on an eee pc 1000HA.

greetings,
frank

Hi,

I had a stable wireless network with 8.10. I upgraded to 9.04 and I' am experiencing from time to time an extremely slow bitrate (bitrate drops from a normal 250 Kb/s until 300b/s). Pinging to my router (192.168.1.1) is unstable as well
(Packages are returned from 6 to 90 msec). Sometimes the network is working fine, then I gets slow for a while, a.s.o.

I have a wl-167g usb-adapter which uses rt2500usb
. No problems are reported in the message-logs and I'm not loosing
my connection. Firefox reports from time to time that connection with the server has been lost.

I just found a solution for RT2500 slow connection problem (http://ubuntuforums.org/showthread.php?p=7605785).
One proposes to install Wicd.

iwconfig
 returns : wlan0 Bit Rate=1 Mb/s Tx-Power=20 dBm

where iwlist wlan0 bitrate
 returns
          wlan0 unknown bit-rate information.

          Current Bit Rate=54 Mb/s

iwconfig <-> iwlist ????

after setting sudo iwconfig wlan0 rate 54M I have a normal working wireless network again and both commands
are returning the same bitrate.

Well, for the time being I'll have to issue this command each time I boot Ubuntu

I also have this problem with b43, the sta driver and ndiswrapper.

wlan0: deauthenticating by local choice (reason=3)
is the line from dmesg I get after the connection drops out

Using karmic alpha 5 and I just downloaded the backported wireless modules, so i'll see if that helps.

Here is a bit more info:

I have an Asus eeepc 1000HE that uses the ath9k driver. With the latest Karmic updates. Upon power on the system seems to perform flawlessly. I can ping my local work station and get 1.xms time returns on the packets and 0% loss. Once I close the lid and put the beast to sleep and then return from suspend things change.

I can ping my local work station but packet return times start at about 100ms give or take a few (98 or so) and the it drops a few milliseconds until it gets down to about 1.x, it then resets at 100ms and begins to count down again. during this time there are may or may not be dropped packets. Sometimes 0% sometimes maybe 3% or 7%.

Here is a trace:

Just after power on
-------------------------------------------------------------------------------------------------
george@europa:~$ ping 199.60.63.2
PING 199.60.63.2 (199.60.63.2) 56(84) bytes of data.
64 bytes from 199.60.63.2: icmp_seq=1 ttl=64 time=6.34 ms
64 bytes from 199.60.63.2: icmp_seq=2 ttl=64 time=1.65 ms
64 bytes from 199.60.63.2: icmp_seq=3 ttl=64 time=1.72 ms
64 bytes from 199.60.63.2: icmp_seq=4 ttl=64 time=1.72 ms
64 bytes from 199.60.63.2: icmp_seq=5 ttl=64 time=1.73 ms
64 bytes from 199.60.63.2: icmp_seq=6 ttl=64 time=1.61 ms
64 bytes from 199.60.63.2: icmp_seq=7 ttl=64 time=1.66 ms
64 bytes from 199.60.63.2: icmp_seq=8 ttl=64 time=1.53 ms
64 bytes from 199.60.63.2: icmp_seq=9 ttl=64 time=709 ms
64 bytes from 199.60.63.2: icmp_seq=10 ttl=64 time=1.67 ms
64 bytes from 199.60.63.2: icmp_seq=11 ttl=64 time=1.65 ms
64 bytes from 199.60.63.2: icmp_seq=12 ttl=64 time=1.70 ms
64 bytes from 199.60.63.2: icmp_seq=13 ttl=64 time=1.75 ms
64 bytes from 199.60.63.2: icmp_seq=14 ttl=64 time=1.72 ms
64 bytes from 199.60.63.2: icmp_seq=15 ttl=64 time=1.68 ms
64 bytes from 199.60.63.2: icmp_seq=16 ttl=64 time=1.72 ms
64 bytes from 199.60.63.2: icmp_seq=17 ttl=64 time=2.03 ms
64 bytes from 199.60.63.2: icmp_seq=18 ttl=64 time=1.66 ms
64 bytes from 199.60.63.2: icmp_seq=19 ttl=64 time=1.62 ms
64 bytes from 199.60.63.2: icmp_seq=20 ttl=64 time=1.66 ms
^C
--- 199.60.63.2 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19036ms
rtt min/avg/max/mdev = 1.532/37.315/709.398/154.189 ms
george@europa:~$

After returning from suspend
------------------------------------------------------------------------------------------------
george@europa:~$ ping 199.60.63.2
PING 199.60.63.2 (199.60.63.2) 56(84) bytes of data.
64 bytes from 199.60.63.2: icmp_seq=1 ttl=64 time=173 ms
64 bytes from 199.60.63.2: icmp_seq=2 ttl=64 time=71.7 ms
64 bytes from 199.60.63.2: icmp_seq=3 ttl=64 time=69.7 ms
64 bytes from 199.60.63.2: icmp_seq=4 ttl=64 time=68.0 ms
64 bytes from 199.60.63.2: icmp_seq=5 ttl=64 time=66.6 ms
64 bytes from 199.60.63.2: icmp_seq=6 ttl=64 time=64.6 ms
64 bytes from 199.60.63.2: icmp_seq=7 ttl=64 time=62.7 ms
64 bytes from 199.60.63.2: icmp_seq=8 ttl=64 time=60.6 ms
64 bytes from 199.60.63.2: icmp_seq=9 ttl=64 time=58.6 ms
64 bytes from 199.60.63.2: icmp_seq=10 ttl=64 time=56.7 ms
64 bytes from 199.60.63.2: icmp_seq=11 ttl=64 time=54.6 ms
64 bytes from 199.60.63.2: icmp_seq=12 ttl=64 time=52.7 ms
64 bytes from 199.60.63.2: ...

Just to make it clear in my previous post the cycle down and back happens indefinitely.

100ms
 99.8ms
 98.7ms
  .
  .
2.67ms
100ms
99.8ms
99.6ms
98.2ms
 .
 .
2.54ms
100ms

and so on
Cheers

I also confirm the bug wuth ath9k - using ASUS X59GL - wifi (using networkmanager) works ok if the amount of data transmitted is small (web pages etc), however, big file transfers (100M+) the link drops, waits (up to 30 seconds) then restarts. Overall, huge amounts of packet loss...

Performing a rmmod ath9k / modprobe ath9k after hibernate can re-enable the network (without the countdown).

I'm using latest software patches etc for Karmic...

Thanks

Carl.

driver issue. someone claimed that ath9k got worse for older chipsets in karmic

So just curious, any news on this bug? I just tried the latest beta and it doesn't fix the issues. Any tips to resolving this?

Cheers
George

2009/10/1 George Farris <email address hidden>

> So just curious, any news on this bug? I just tried the latest beta and
> it doesn't fix the issues. Any tips to resolving this?
>

No. In fact things appear to have gotten worse, from what I can tell.

- Evan

The latest updates seemed to have fixed my wifi issues. I am running the non-UNR beta and had experienced the same instability issues as described above prior to the latest upgrades with the ath9K driver.

The connection appears to be stable for me with large file transfers, returning from suspended state and disabling wifi via Fn-F2 (eee 1000he). I'm going to cross my fingers and hope this is fixed.

2009/10/3 upt1me <email address hidden>

> The latest updates seemed to have fixed my wifi issues.

So if I install the current version of karmic it will come with the fixed
driver?
Or do I have to still download the ath9k driver separately and build it
locally?

- Evan

As of this morning Saturday, Oct 3 10:57am PST this bug still exists.

I have had anywhere from 0 to 57% packet loss on pings after a restore from suspend and it still counts down from 99 to about 2ms, resets back to 99ms and counts down. Sometimes it hangs.

This is on an Asus eeepc 1000he bought about 4 months ago with the ath9k driver and UNR

Not fixed yet.

I'm just hoping that 9.10 fixes it, I don't really want to buy another version of windows, well at least not on the netbook, I use it on the desktop and laptop. This is pretty frustrating, thankfully I don't use my netbook everyday so it's not the end of the world.

On Mon, Oct 5, 2009 at 5:19 PM, 1000HEUSER <email address hidden> wrote:
> I'm just hoping that 9.10 fixes it, I don't really want to buy another
> version of windows, well at least not on the netbook, I use it on the
> desktop and laptop. This is pretty frustrating, thankfully I don't use
> my netbook everyday so it's not the end of the world.

Can you guys try out the latest stable compat-wireless release?

http://wireless.kernel.org/en/users/Download/stable/

  Luis

Yippy! My eeepc got his wifi back! I installed the compat-wireless 2.6.32-rc1 on a 2.6.31.11 kernel and it works fine. The older version of the compat-wireless wouldn't compile on my machine. Thanks for your hints. No packet losses anymore!

The latest linux-backports-modules-karmic-generic solved this problem for me. See https://bugs.launchpad.net/linux/+bug/414560.

Not solved for me.

ii linux-image-2.6.31-14-generic 2.6.31-14.48
ii linux-backports-modules-karmic-generic 2.6.31.14.27

# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:
          Mode:Managed Frequency:2.412 GHz Access Point:
          Bit Rate=2 Mb/s Tx-Power=20 dBm

I've seen bitrate 0, 1 Mb, 2Mb, but never the 54Mb it should be, unless I manually set it, but even then I still don't get decent speeds and I get the frequent dropped connections described in #414560.

On Wed, Oct 28, 2009 at 8:42 PM, Jason Toffaletti <email address hidden> wrote:
> Not solved for me.
>
> ii  linux-image-2.6.31-14-generic             2.6.31-14.48
> ii  linux-backports-modules-karmic-generic    2.6.31.14.27

Tim, is this the package that provides the 2.6.32-rc5 stable
compat-wireless stuff? Or is it likely that has not yet trickled down
to regular packages (it might just be in proposed right now).

  Luis

Luis R. Rodriguez wrote:
> On Wed, Oct 28, 2009 at 8:42 PM, Jason Toffaletti <email address hidden> wrote:
>> Not solved for me.
>>
>> ii linux-image-2.6.31-14-generic 2.6.31-14.48
>> ii linux-backports-modules-karmic-generic 2.6.31.14.27
>
> Tim, is this the package that provides the 2.6.32-rc5 stable
> compat-wireless stuff? Or is it likely that has not yet trickled down
> to regular packages (it might just be in proposed right now).
>
> Luis
>

The last Karmic LBM release was based on -rc4:

UBUNTU: Update to stable compat-wireless-2.6.32-rc4

--
Tim Gardner <email address hidden>

On Thu, Oct 29, 2009 at 2:07 PM, Tim Gardner <email address hidden> wrote:
> Luis R. Rodriguez wrote:
>> On Wed, Oct 28, 2009 at 8:42 PM, Jason Toffaletti <email address hidden> wrote:
>>> Not solved for me.
>>>
>>> ii  linux-image-2.6.31-14-generic             2.6.31-14.48
>>> ii  linux-backports-modules-karmic-generic    2.6.31.14.27
>>
>> Tim, is this the package that provides the 2.6.32-rc5 stable
>> compat-wireless stuff? Or is it likely that has not yet trickled down
>> to regular packages (it might just be in proposed right now).
>>
>>   Luis
>>
>
> The last Karmic LBM release was based on -rc4:
>
> UBUNTU: Update to stable compat-wireless-2.6.32-rc4

Thanks TIm, when you do dpkg -l on it should it be:

 ii linux-backports-modules-karmic-generic 2.6.31.14.27

Or something a little different?

  Luis

Luis R. Rodriguez wrote:
> On Thu, Oct 29, 2009 at 2:07 PM, Tim Gardner <email address hidden> wrote:
>> Luis R. Rodriguez wrote:
>>> On Wed, Oct 28, 2009 at 8:42 PM, Jason Toffaletti <email address hidden> wrote:
>>>> Not solved for me.
>>>>
>>>> ii linux-image-2.6.31-14-generic 2.6.31-14.48
>>>> ii linux-backports-modules-karmic-generic 2.6.31.14.27
>>> Tim, is this the package that provides the 2.6.32-rc5 stable
>>> compat-wireless stuff? Or is it likely that has not yet trickled down
>>> to regular packages (it might just be in proposed right now).
>>>
>>> Luis
>>>
>> The last Karmic LBM release was based on -rc4:
>>
>> UBUNTU: Update to stable compat-wireless-2.6.32-rc4
>
> Thanks TIm, when you do dpkg -l on it should it be:
>
> ii linux-backports-modules-karmic-generic 2.6.31.14.27
>
> Or something a little different?
>
> Luis
>

Actually thats not the right LBM version number, its 2.6.31.14.16.

You can always check for the current upload in Launchpad:

https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.31

rtg
--
Tim Gardner <email address hidden>

I just noticed this behavior of the wireless on my 1000HE. If I choose the 2.6.28-16 then I see the problem. When I choose the 2.6.28-11 it does not have the problem.

Have tried backports as well as wireless backports. The connection stays associated but becomes idle for seconds at a time. During the idle times there is nothing coming from dmesg to debug it. I'm running 9.10 but this happened in 9.04 as well. I'm running AR928X. The good thing is I don't get disassociated but as far as streaming video forget about it. I have to boot into winblows for any streaming needs. My recommendation is stay away from all dell products due to atheros and potentially intel graphics. This will never be fixed. You will just have to deal with it. Buy a supported PCMCIA card that has no issues that... should fix it.

Backports is the problem. Upon further investigation AR928X is working now without backports.

I have TP-Link WR841ND (2x2 MIMO Atheros XSPAN Router) and WN821N (2x2 MIMO Atheros XSPAN Router).

On the PC with the WN821N, lsusb reports:

Bus 002 Device 004: ID 0cf3:1002 Atheros Communications, Inc.

and lsmod reports:
Module Size Used by
mac80211 210104 1 ar9170usb
led_class 5256 1 ar9170usb
ath 10304 1 ar9170usb
cfg80211 109144 3 ar9170usb,mac80211,ath

Before yesterday, it was loading a module called "usb" (descriptive!!!) and giving me 1 mbits, dropping out frequently wiht 90% signal strength.

Now, it is loading ar9120usb, which is probably correct, but still connects at 1Mbps:

wlan6 IEEE 802.11bgn ESSID:"kismet"
          Mode:Managed Frequency:2.412 GHz Access Point: 00:1D:0F:D9:DD:08
          Bit Rate=1 Mb/s Tx-Power=20 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=61/70 Signal level=-49 dBm Noise level=-85 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

My Intel 4965AGN notebook running Win7 connects at ~120Mbps at least twice the distance away and pushes 32Mbps / > 4 mb/s net throughput where as this only gets ~6Mbps / <1 mb/s.

I am just wondering. Is this an issue with the in-kernel Atheros drivers in general (at current state) or specific to ubuntu? I am running karmic with latest updates (2.6.31-14.48).

confirmed here. using up-to-date ubuntu karmic and not using kernel backports.

device
01:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
on a asus eee pc t91

going to test with compat-wireless and iwconfig wlan0 rate 54M

much better with compat-wireless-2.6.32-rc7 (i would say fixed, but sometimes ping takes more to respond)
iwconfig wlan0 rate 54M don`t help

thanks for the support!

I can confirm that with current compat-wireless (I use the release of Nov 25th) I have a stable, fast connection and also a higher connection strength. Streaming video works again. I suggest updating the backports-modules soon.

On Mon, Nov 30, 2009 at 2:35 AM, Plippo <email address hidden> wrote:
> I can confirm that with current compat-wireless (I use the release of
> Nov 25th) I have a stable, fast connection and also a higher connection
> strength. Streaming video works again. I suggest updating the backports-
> modules soon.

lbm is based on the stable compat-wireless releases, if you use
bleeding edge that is only supported if you are using the truly latest
bleeding edge (as of today) and through the linux-wireless mailing
list.

Can someone please close this bug report.

 Luis

Thanks for the clarification, I didn't know that there is also a stable branch of compat-wireless.

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.