Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1343 (new defect)

Opened 15 years ago

Last modified 12 years ago

Atheros AR5212 has awful reception, trouble holding connections

Reported by: thomasmallen@gmail.com Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: v0.9.3
Keywords: atheros, ath_pci, sensitivity Cc:
Patch is attached: 0 Pending:

Description (Last modified by mrenzmann)

I use an internal wireless card in an IBM ThinkPad, chipset Atheros AR5212 (not sure of the specific brand/model, bought laptop used), and I am gettting very poor performance when using the Madwifi "ath_pci" module. I have experienced this in Debian (Etch, Lenny), Sabayon, Ubuntu, PCLinuxOS, Zenwalk, Arch, and a couple other distributions. The main problem is signal strength and the ability to hold a connection. The latter is a result from the former, as any wireless card can't hold a weak signal for long.

I haven't performed any tests (as if I know how), but I can provide some anecdotal evidence, for what it's worth. At my local coffee shop, most of the patrons use laptops to take advantage of the free internet. I never have any difficulty picking up the signal with my MacBook using OSX, but my ThinkPad can seldom hold the signal for more than a few seconds. As a matter of fact, near any open network, my ThinkPad sees the signal as one bar at most, and seldom has any luck joining.

The Ubuntu users mistakenly assumed this to be a problem with the distro, and filed a bug report. There are links to the relevant forum topic and the bug report in the attached text file. Any help is appreciated, but I think this is a problem with the module. I was unable to find any fixes for the bug.

Change History

05/24/07 14:58:20 changed by mrenzmann

05/24/07 14:59:36 changed by mrenzmann

  • description changed.

05/24/07 15:01:16 changed by mrenzmann

  • description changed.

05/24/07 16:37:08 changed by strasak@bubakov.net

Probably related to #705 , if it is related, this - bad sensitivity - imo really is serious issue especially on long distance links and on other side on short links with low quality - integrated and stuff - antennas such as thomasmallen and most of notebook owners probably have.

05/24/07 17:15:20 changed by Kev

I'm not sure if this will help or not, but I'll report my similar problem.

I am running an IBM Thinkpad T43 with Ubuntu 7.04 and WinXP Professional. I am currently in our school library, where my wireless signal in Windows is 90-100% from my seat. I booted into Ubuntu first this morning to test it out, and the wireless signal strength was roughly 8-10%, and I was unable to connect to the network. In Windows, I use an Atheros driver for my wireless card (the one installed out of the box).

If there are any tips, or if anyone needs me to test things, please reply.

Thanks, Kev

05/24/07 20:43:05 changed by mtaylor

There are several things you might try:

  1. Remove the minimum RSSI value requirement during AP scans. Thus even AP with weak signals will still show up in the scans.
  2. Disable hostroaming (iwpriv athN hostroaming 0) or update the roaming thresholds (iwpriv athN rssi11? 1 and iwpriv athN rate11? 1) Currently these default to roam if SNR drops below 18, which is very conservative but might screw you up in some cases.
  3. Sensitivity is affected by the gain control / calibration timer. Make sure that calibration is happening regularly. athdebug -i athN +calibration and see that calibration is happening about once a second until it stabilizes.
  4. Report back on the signal and noise values reported by iwconfig when this is happening. How is your noise floor? The problems I can think of are: coarse gain adjustment is necessary but didn't happen or noise floor is unnaturally high, resulting in lower RSSI values.
  5. Run athstats and tell us what you see.
  6. See if its a driver problem or a hardware problem by booting Windows - a real pain I know.

Cheers,

Mike

05/25/07 00:09:16 changed by strasak@bubakov.net

Mike,
please take a look at #705 on tests that guy made, i have also heard from ppl here that they have significantly better performance with StarOS and RouterOS on bad - in terms of signal strenght and noise level - links. The hostroaming parameter i've somehow missed, will try if turning it off will have some effect on intentionally crippled link or stuff.
Pavel

05/26/07 19:47:16 changed by anonymous

I can confirm this again. I'm in kubuntu 7.04 and I have been trying for a few days to get my AR5212 card to work in my room. Then I found this ticket and brought my Lenovo tablet about 4ft from my router, where I get a 5-11Mb/s connection.

It is definitely a probelm with the madwifi driver. I have perfect reception (i.e. 48-54Mb/s) in my room in windows but I can't connect in linux.

These are from a few feet from my router:

ben@ben-laptop:~$ athstats
204 tx management frames
39 tx failed due to too many retries
6299 long on-chip tx retries
165 tx frames with no ack marked
1079 tx frames with an alternate rate
5874 rx failed due to bad CRC
146143 PHY errors
    14351 (phy error code 17)
    2 (phy error code 23)
    131609 (phy error code 25)
    181 (phy error code 31)
1311 periodic calibrations
rssi of last ack: 56
rssi of last rcv: 50
13314 switched default/rx antenna
Antenna profile:
[1] tx      723 rx    38048
[2] tx    27901 rx    51355
ben@ben-laptop:~$ iwconfig ath0
ath0      IEEE 802.11g  ESSID:"unique"  Nickname:""
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:06:25:F7:C8:6A
          Bit Rate:5 Mb/s   Tx-Power:8 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=59/94  Signal level=-36 dBm  Noise level=-95 dBm
          Rx invalid nwid:4658  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

05/26/07 22:00:19 changed by anonymous

A fix is to use ndiswrapper. hxxp://ubuntuforums.org/showthread.php?p=2688436

It made my wifi work perfectly from my room.

06/02/07 17:10:34 changed by thomasmallen@gmail.com

As you guys requested when I added this ticket, here are the stats at my coffee shop (they boosted their signal slightly, so I'm just barely able to get on, although the signal drops often):

ath0 IEEE 802.11g ESSID:"murky" Nickname:""

Mode:Managed Frequency:2.412 GHz Access Point: 00:18:39:AC:E2:38 Bit Rate:11 Mb/s Tx-Power:17 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality=26/94 Signal level=-68 dBm Noise level=-94 dBm Rx invalid nwid:19685 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0

06/02/07 22:26:42 changed by mentor

That's plenty of signal.

I'm currently connected at 36Mb/s at similar power levels (on the same frequency, actually). So, something else must be happening here. Perhaps you should use 80211debug to monitor association? Are you getting any packet loss if you try pinging a local host over the wireless?

06/03/07 10:43:27 changed by strasak@bubakov.net

The rx invalid nwid is symptome of the problem, it usually increase when there is lot of interference around. Also, along with things mentor suggested, i would run athstats -i wifi0 1 and watch what is happenning on link, especially PHY errors and longs.

06/07/07 04:18:56 changed by moron@industrial.org

I am personally experiencing these same symptoms. Initially I thought it was due to a crappy D-Link router I was using but I have since replaced that with one of the Linux based Linksys units and the problem persists on my desktop but not on other machines in the house. Link quality shows as poor and connectivity is lost at random times, sometimes it takes several rounds of /etc/init.d/networking restart to get / regain a connection.

First, here's what lspci says:

02:05.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

Next, here is the Linux Kernel version I am running:

2.6.20-16-generic #2 SMP x86_64 GNU/Linux

Next, here is the output of iwconfig:

ath0      IEEE 802.11g  ESSID:"essidgoeshere"  Nickname:""
          Mode:Managed  Frequency:2.447 GHz  Access Point: 00:2A:60:6F:F9:33
          Bit Rate:11 Mb/s   Tx-Power:18 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=12/94  Signal level=-84 dBm  Noise level=-96 dBm
          Rx invalid nwid:1596  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Next, here is what "sudo athstats -i wifi0" athstats shows:

179 tx management frames
5 tx failed due to too many retries
1351 long on-chip tx retries
163 tx frames with no ack marked
437 tx frames with an alternate rate
3287 rx failed due to bad CRC
49169 PHY errors
    5371 (phy error code 17)
    43795 (phy error code 25)
    3 (phy error code 31)
530 periodic calibrations
rssi of last ack: 6
rssi of last rcv: 11
1 switched default/rx antenna
Antenna profile:
[1] tx     4660 rx    26316
[2] tx     4546 rx        0

I do not have a way of booting Windows on this machine but I can say that sitting anywhere else in the house I have tried with a Windows laptop I have no connectivity issues with the local wireless LAN. I am open to considering this a strength issue of some sort but under my previous Gentoo install (same card, different box) the sensitivity values were noticeably higher.

I am not seeing anything obvious in the logs co-inciding with a loss of connection but I am also not sure what to look for at this point. I am running Ubuntu Feisty,

If there is anything else I can do to help troubleshoot this please let me know.

Cheers

06/07/07 09:50:25 changed by strasak@bubakov.net

try turning diversity off and set tx and rx antenna to 1, but anyway, signal level seems to be extraordinary low -> see RSSI of rcv and ack. On this signal level reliable connection is hardly possible. Maybe it is really that HAL sensitivity issue as described in ticket #705. What version of madwifi/HAL had your previous Gentoo install had ?

07/04/07 15:12:31 changed by gustavo@sagui.org

I've been experiencing the same problem for some time, on two different setups: a PCI card on a desktop that I use as an AP, and a laptop.

For the desktop the problems started sometime in the first semester of this year, but I can't place the date because mostly I use the network from a close range, also I can't boot in Windows to compare as I don't know how to setup Windows as an AP. But, as some people noted, this setup used to work reliably under older versions of Madwifi. The machine runs Fedora 7 and I use the Livna packaged Madwifi (0.9.3.1, HAL 0.9.18.0).

The laptop isn't mine and I don't have it with me now (mine has a broadcom nic), but I installed Linux on it in April and Madwifi never worked reliably. It works perfectly fine on Windows. I tested it with my Madwifi desktop AP here and with the Linksys AP of the laptop owner. In both cases, the network is only usable if the machine is sitting next to the antenna. I tried Fedora 6 and 7, both with Livna packaged Madwifi (0.9.3.1, HAL 0.9.18.0) with the same results.

If you need debug information, just let me know.

07/18/07 04:49:09 changed by anonymous

Does anyone know if this problem is any closer to being solved?

08/09/07 08:52:20 changed by peepstein@canada.com

I seem to have a similar problem. The card that I have is a D-Link WDA-1320. It uses an AR5212 chip. The output of lspci is:

 00:0d.0 Ethernet controller: Atheros Communications, Inc. AR5005G 802.11abg NIC (rev 01)

The output of dmesg | grep Atheros is:

 [17179587.912000] wifi0: Atheros 5212: mem=0xfc000000, irq=185

The Access Point is an Apple Airport Express, and it's about 12 feet away from the computer. I have two laptops that I use all around the house with excellent results, but no matter what I try to do, I only get a link quality of around 0-20/94 with the madwifi+Atheros card. The bitrate fluctuates all over the place. Right now, I've got a link quality of 14/94 and a bitrate of 2 Mb/s.

This is the output of lsmod | grep ath:

 ath_pci               100000  0
 ath_rate_sample        16512  1 ath_pci
 wlan                  207708  6 wlan_tkip,wlan_ccmp,wlan_scan_sta,ath_pci,ath_rate_sample
 ath_hal               192976  3 ath_pci,ath_rate_sample

I'm using ubuntu 6.10 Edgy. My kernel is 2.6.17-10-generic. I'm not sure what else to add. Is this a real genuine problem or are people just trying to connect through walls?

08/16/07 00:13:46 changed by anonymous

Its a problem. Perfect reception in windows and using ndiswrapper. But with madwifi drivers it can't even connect (all in the same place). Its a bug.

09/17/07 20:55:42 changed by Petezzz

Confirming that I have this problem on Ubuntu Feisty with Thinkpad T41 - i.e. very poor signal using wireless. Another Thinkpad T40 with the aironet driver next to this one and running feisty is showing maximum signal strength.

I include most of the info shown in earlier bug reports. Is there anything else I can do to help isolate the problem ?

uname -a
laptop2 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686 GNU/Linux

lspci is as follows ...

2:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

and I am 4 feet away from wireless router with a poor connection ...

iwconfig 
ath0      IEEE 802.11g  ESSID:"JesmondPaddock"  Nickname:""
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:16:B6:02:00:04   
          Bit Rate:18 Mb/s   Tx-Power:14 dBm   Sensitivity=0/3  
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=31/94  Signal level=-67 dBm  Noise level=-98 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
sudo athstats
523 tx management frames
4 tx failed due to too many retries
144 long on-chip tx retries
507 tx frames with no ack marked
1611 tx frames with short preamble
2 tx frames with an alternate rate
1375 tx frames with 11g protection
430 rx failed due to bad CRC
36808 PHY errors
    35091 (phy error code 17)
    1717 (phy error code 25)
1822 periodic calibrations
rssi of last ack: 12
rssi of last rcv: 26
88 switched default/rx antenna
Antenna profile:
[1] tx      213 rx     3540
[2] tx     1506 rx    16482

09/24/07 18:47:54 changed by anonymous

Hi, I run an X60 with Madwifi and the atheros 5212 - absolutely the same problem: windows works fine, but Madwifi has nearly no reception....

09/30/07 02:53:36 changed by mrmarcus66(at)hotmail.com

I also have an AR5212 802.11abg NIC and I have given up using it for the time being. I tried the madwifi svn version the a few days ago this did not work. I an trying to use a AP I am 1 meter away from and I loose connection. If anyone wants any stats/info what's required?

10/03/07 09:27:09 changed by anonymous

I run feisty 7.04, madwifi is on 15 foot line-of-sight with new netgear router, wpn311 card, in same room as windows box, same equipment. windows signal strength always 90% or better, ubuntu box always less than 40%........

10/19/07 21:08:38 changed by anonymous

This Signal Strength Change Occurred Between openSuSE 10.2 and 10.3

Currently, I have the exact same problem of signal strength dropping from 100% to 50%. On openSuSE 10.2 using madwifi and wpa_supplicant, signal strength was always 100% no matter where I was in my house or office. (Both have linksys WRT54G access points). The distances involved are 15 meters or less.

I upgraded the same hardware to openSuSE 10.3 when it was released, had 100% signal strength for a few days, then apparently after the latest update to either madwifi or wpa_supplicant, signal strength has been cut in half. Even if I put my laptop (Toshiba P35) right in front of the AP. The laptop dual boots Win XP and with windows, there has been no change to the signal strength. It is still ~100% no matter where I am in either the house or office. (I have had the same wireless setup for over 2 years)

Whatever changed in the latest 1 or 2 releases of madwifi or wpa has definitively caused changes to the ability of the driver to get good signal strength. I pulled my hair out over this considering all options (even transient sun spot activity) until I found a wealth of others suffering the same reduction in signal strength.

I don't know what is causing it, but I can CONFIRM the problem with madwifi under openSuSE 10.3 with the Atheros AR5212/5213 driver on my Toshiba P35. athstats now shows crc errors that were not there before:

[root Rankin-P35a/home/david] # athstats 379 tx management frames 88 long on-chip tx retries 345 tx frames with no ack marked 10 tx frames with an alternate rate 299 rx failed due to bad CRC 28 PHY errors 28 CCK restart 1312 periodic calibrations 1 rfgain value change rssi of last rcv: 28 79 switched default/rx antenna Antenna profile: [1] tx 1188 rx 24964 [2] tx 176 rx 4211

[root Rankin-P35a/home/david] # athstats ath0

input output altrate short long xretry crcerr crypt phyerr rssi rate 30621 1592 10 0 88 0 312 0 28 30 0M

Any help would be appreciated

10/20/07 05:30:04 changed by anonymous

More information from the openSuSE community:

The fact that it was always 100% was wrong in NetworkManager (we had a

workaround in earlier suse versions but it broke with the newer madwifi drivers): bugzilla(dot)novell(dot)com/show_bug.cgi?id=293556 We fixed this in a recent 10.3 update because it was extremely deceptive. The problem is then either in the madwifi driver and how it outputs signal strength or NM and how it calculates signal strength. -JP

Thanks JP

This is truly a strange problem. What is very very strange is that I think this is a display change or a calculation change in the way the signal strength is computed in one of the apps that feeds the kinternet signal strength display. Whatever the change, the resulting signal

strength display is now incorrect. We have gone from an extreme high to an extreme low signal strength display. How do I know the display is FUBAR? I put my laptop right next to the Linksys AP ( within 1 foot ) and signal strength never exceeded 58%. More testing also reveals something is amiss.

I have also conducted a test with *two separate* 10.3 installs on the same laptop. I have 2 laptop hard drives, the original 4200 rpm Toshiba and a 5400 rpm WD. Both have 10.3 loaded. The 4200 rpm drive was loaded with 10.3 when it was released and has not been updated. The 5400 rpm

drive is the daily use drive (because it is faster) with all current updates via Yast -> software management -> all packages -> update if newer.

The 4200 rpm drive install shows signal strength is 100% The 5400 rpm drive install will not show signal strength over 58% no matter what!

Both 10.3 installs have the same kernel, madwifi version and modules installed:

Rankin-P35a:/home/david # uname -r
2.6.22.9-0.4-default

david@Rankin-P35a:~> rpm -qa | grep wifi
madwifi-kmp-default-0.9.3.2_2.6.22.5_31-0.1
madwifi-devel-0.9.3.99-36
madwifi-0.9.3.99-36

The 4200 rpm drive shows 100% signal strength even though it shows LESS actual signal with iwconfig than the updated install:

iwconfig

ath0      IEEE 802.11g  ESSID:"skyline"  Nickname:""
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:0F:66:52:A3:A1
          Bit Rate:18 Mb/s   Tx-Power:16 dBm   Sensitivity=1/1
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:5FD4-3FF1-5F40-387A-0CF1-4990-AA11-D349
Security mode:restricted
          Power Management:off
          Link Quality=30/70  Signal level=-65 dBm  Noise level=-95 dBm
         ^^^^^^^^^^^^^^^^^^^^
          Rx invalid nwid:1757  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

The 5400 rpm drive shows 45% signal strength even though it has MORE actual signal:

iwconfig

ath0      IEEE 802.11g  ESSID:"skyline"  Nickname:""
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:0F:66:52:A3:A1
          Bit Rate:54 Mb/s   Tx-Power:16 dBm   Sensitivity=1/1
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:3DA2-0064-7787-5868-648E-AE4E-1AEB-D774
Security mode:restricted
          Power Management:off
          Link Quality=32/70  Signal level=-62 dBm  Noise level=-94 dBm
         ^^^^^^^^^^^^^^^^^^^^
          Rx invalid nwid:10572  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

So the bottom line is something has changed and it is not quite right yet. Signal strength cannot be a maximum of 58% 1 foot from the AP. I understand the deceptive overstatement of the link always showing 100%, but I think there is an equal deceptive understatement when the link shows 58% when the laptop is literally on top of the AP.

I hope the additional information helps narrow down where the problem is and what needs to be fixed. From a throughput standpoint, everything is fine. Data passes back and forth between the laptop and the AP just fine regardless of whether the signal strength reads 40% or 100%, but I guarantee you that there will be a whole lot of people that freak over the dramatic drop on the meter.

-- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339

10/20/07 14:39:07 changed by tarvid@ls.net

I had problems associating after an upgrade from Ubuntu Feisty to Gutsy. After somewhat lengthy digging I tried ifdown ath0, ifup ath0 and it seems to be working well. I think this is a problem with the wpasupplicant script at boot time but I don't know how to proceed.

Personally, I can live with the workaround but if I can help resolve this issues that would be neat.

Suggestions welcome.

(follow-up: ↓ 27 ) 11/04/07 21:54:44 changed by vz-madwifi@zeitlins.org

I can confirm that the same problem also exists on HP nw8000 notebook which uses, quoting lspci, Atheros Communications, Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01) under Ubuntu 7.10 using madwifi package 0.9.3+dfsg-1.

Various manifestations of this bug:

* pinging the base station (3com OfficeConnect? router) results in 75% packet loss, while 0% of packets are lost when using ndiswrapper (and this doesn't affect just ping, of course, network is unusable with madwifi and works perfectly with ndiswrapper)

* iwconfig shows constantly increasing "Rx invalid nwid" with madwidi while it's constantly 0 with ndiswrapper

* athstats 1 displays 400-500 phyerr per second:

# athstats -i wifi0 1
   input   output altrate   short    long xretry crcerr  crypt  phyerr rssi rate
   78615     5853     117       0   17427   1238  52788      0  625545   31   0M
      22        4       0       0      14      0      2      0     433   31   0M
      19        1       0       0       4      0     20      0     327   31   0M
      18        0       0       0       0      0     19      0     442   31   0M
      24        5       0       0       5      0     11      0     488   30   0M
      35       16       0       0      33      0     38      0     393   30   0M

* anecdotically, iwconfig displays 40/100 link quality with ndiswrapper but only ~20 with ath_pci; signal level is -70dBm with ndiswrapper and -58dBm with ath_pci

It also seems that the reception is much worse when there are other networks in range (they come from the neighbours so I can't really turn then on/off at wish), even if they use different channels.

(in reply to: ↑ 26 ) 11/05/07 06:35:59 changed by mrenzmann

Replying to vz-madwifi@zeitlins.org:

signal level is -70dBm with ndiswrapper and -58dBm with ath_pci

Actually this means that the signal level is better with MadWifi than with ndiswrapper...

11/05/07 17:12:52 changed by Mike Taylor

Also, "invalid nwid" means "packet with a different SSID" and it isn't an error, it just means you are sharing the channel with neighbors. Next, NDIS wrapper may not be updating those statistics, depending on how well it is integrated with wireless extensions. I guarantee that if you get a value of zero with ndis wrapper, that it is NOT updating this statistic. NDIS is a generic API for network drivers, so it's very doubtful that dedicated wireless statistics/counters are being published by NDIS wrappers.

11/06/07 11:31:32 changed by vz-madwifi@zeitlins.org

I am more than ready to believe that ndiswrapper doesn't report the statistics correctly. I will recheck the signal level, maybe I've inversed the numbers because I distinctly remember the Gnome applet showing much higher level for ndiswrapper than for ath_pci.

However to be honest this isn't really relevant, what matters is the 75% ping loss with ath_pci (and, again, it's not just ping: opening google.com in Firefox takes up to 5 minutes when it doesn't time out... the network is completely unusable).

If I can provide any additional information, please let me know.

Thanks!

12/02/07 01:24:40 changed by jcerruti@gmail.com

Adding myself to the long queue of reports here.

I have a Lenovo Thinkpad T60 that has an integrated AR5212. I'm using it with Ubuntu Feisty 7.04. ath_pci is currently 0.9.4.5 (0.9.3.1). Using this integrated wlan, I can barely connect to my wireless router if I'm closer that three feet. If I walk away a little then the receive level drops and I loose the connection pretty quicly.

I added an external wireless card which turned out to be another AR5212 from Linksys. With this card I could get a bit more reception but I still have to be on the same room with the router, which is not very normal. Even in this case, the new wireless interface drops and regains connection every now and then, overriding the configuration of my VPN client and disrupting my work.

Any chance we can get some attention on this problem? It sounds it is not at all rare. I would be willing to contribute some of my time to help if I got some direction.

12/02/07 02:16:30 changed by jcerruti@gmail.com

Confirming: just switched to ndiswrapper with the internal wireless card: now I can add this comment to the ticket from the opposite corner of the house - a few rooms away

(follow-up: ↓ 33 ) 01/03/08 23:28:12 changed by geert.steyaert@gmail.com

Same issue here, using a RHEL 5.1 based version of the IBM Internal only distro OpenClient? 2.1. Totally unacceptable performance using this Wifi Linux install. Win XP on the same box worked perfect. I can see same behavior in error counts in the stats.

Some info : madwifi-0.9.3.3-1.oc2.src.rpm version kernel module created is : 9:0.9.3.3-2.6.18-53.el5_1

Any idea ? I don't wanna go to ndiswrapper, rather go for an Intel based mini PCI-E card if not solved in the near future. But I'm not too hopefull seeing the length and duration of this thread ...

(in reply to: ↑ 32 ) 01/04/08 00:56:39 changed by anonymous

Replying to geert.steyaert@gmail.com:

Same issue here, using a RHEL 5.1 based version of the IBM Internal only distro OpenClient? 2.1. Totally unacceptable performance using this Wifi Linux install. Win XP on the same box worked perfect. I can see same behavior in error counts in the stats. Some info : madwifi-0.9.3.3-1.oc2.src.rpm version kernel module created is : 9:0.9.3.3-2.6.18-53.el5_1 Any idea ? I don't wanna go to ndiswrapper, rather go for an Intel based mini PCI-E card if not solved in the near future. But I'm not too hopefull seeing the length and duration of this thread ...

some extra info, in case people are interested : laptop IBM T60, HW model 1951-A47, AR5212 Wireless NIC using Wireless NetworkManager 0.6.5-35 and wpa_supplicant 0.5.7-16

Willing to help/test things if needed

01/06/08 04:47:36 changed by mentor

Has everyone with this problem checked their diversity settings, and looked at their antenna profile with 'athstats'?

01/06/08 13:40:43 changed by anonymous

ok, some more stats :

with AP next to laptop :

#athstats
39 beacon miss interrupts
9117 tx management frames
25 tx failed due to too many retries
19420 long on-chip tx retries
4368 tx frames with no ack marked
478240 tx frames with short preamble
2619 tx frames with an alternate rate
62082 rx failed due to bad CRC
4400102 PHY errors
    266811 OFDM timing
    65 OFDM restart
    4133226 CCK timing
45061 periodic calibrations
rssi of last ack: 72
rssi of last rcv: 67
316674 switched default/rx antenna
Antenna profile:
[1] tx   471356 rx  1982807
[2] tx     2087 rx  1140505

wadwifi settings :

[root@be05294 ~]# grep -r . /proc/sys/dev/{wifi0,ath}/*
/proc/sys/dev/wifi0/ackrate:0
/proc/sys/dev/wifi0/acktimeout:48
/proc/sys/dev/wifi0/countrycode:0
/proc/sys/dev/wifi0/ctstimeout:48
/proc/sys/dev/wifi0/debug:0
/proc/sys/dev/wifi0/diversity:1
/proc/sys/dev/wifi0/fftxqmin:3
/proc/sys/dev/wifi0/ledpin:0
/proc/sys/dev/wifi0/regdomain:98
/proc/sys/dev/wifi0/rxantenna:1
/proc/sys/dev/wifi0/slottime:9
/proc/sys/dev/wifi0/softled:1
/proc/sys/dev/wifi0/tkipmic:1
/proc/sys/dev/wifi0/txantenna:0
/proc/sys/dev/wifi0/txintrperiod:5
/proc/sys/dev/wifi0/xrpollcount:32
/proc/sys/dev/wifi0/xrpollperiod:100
/proc/sys/dev/ath/calibrate:1
/proc/sys/dev/ath/countrycode:0
/proc/sys/dev/ath/debug:0
/proc/sys/dev/ath/hal/swba_backoff:0
/proc/sys/dev/ath/hal/sw_beacon_response_time:10
/proc/sys/dev/ath/hal/dma_beacon_response_time:2
/proc/sys/dev/ath/outdoor:0
/proc/sys/dev/ath/xchanmode:1

Transmit power :

[root@be05294 ~]# iwlist ath0 txpower
ath0      8 available transmit-powers :
          0 dBm         (1 mW)
          5 dBm         (3 mW)
          7 dBm         (5 mW)
          9 dBm         (7 mW)
          11 dBm        (12 mW)
          13 dBm        (19 mW)
          15 dBm        (31 mW)
          17 dBm        (50 mW)
          Current Tx-Power=8 dBm        (6 mW)

Way too low :( also country setting is 0 ????

Seems to be replication ar variant of ticket #936.

In there it's mentioned to be working as of subversion release r2695 but he was using different chip. This was 4 months ago. Wouldn't this be included yet in the last version, 9.3.3 ?

Forgive my questions, never tought I had to go this deep into my wifi setup to get it all working (as it was in XP). But I'm still having fun ... :)

Any pointers on how to improve and if the #936 was solved in the main 9.3.3 release ?

Thanks.

01/06/08 20:12:20 changed by geert.steyaert@gmail.com

just after going 2 rooms aways from AP (perfect connectivity in Win XP)

I've manually set the txpower to 17 when being in different but no help, still no proper connectivity. And again (as seen when sitting next to the AP) it drops after some time back to 8 ...

The stats when 'remote' :

#iwconfig
...
wifi0     no wireless extensions.

ath0      IEEE 802.11g  ESSID:"linksys"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:12:17:xx:xx:xx   
          Bit Rate:1 Mb/s   Tx-Power=17 dBm   Sensitivity=1/1  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:xxxxxxxxxxxxxxxxxxxxxxx   Security mode:restricted
          Power Management:off
          Link Quality=28/70  Signal level=-67 dBm  Noise level=-95 dBm
          Rx invalid nwid:212  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

...

again some stats :

# athstats
141 beacon miss interrupts
11627 tx management frames
6 tx encapsulation failed
285 tx failed due to too many retries
22298 long on-chip tx retries
6346 tx frames with no ack marked
487253 tx frames with short preamble
2816 tx frames with an alternate rate
67327 rx failed due to bad CRC
6476316 PHY errors
    467144 OFDM timing
    65 OFDM restart
    6009107 CCK timing
68071 periodic calibrations
rssi of last ack: 28
rssi of last rcv: 30
435449 switched default/rx antenna
Antenna profile:
[1] tx   477909 rx  2300797
[2] tx     2674 rx  1437184

after some time NetworkManager reports the AP disconnect. The resulting iwconfig :

ath0      IEEE 802.11g  ESSID:"linksys"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated   
          Bit Rate:0 kb/s   Tx-Power=8 dBm   Sensitivity=1/1  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=0/70  Signal level=-95 dBm  Noise level=-95 dBm
          Rx invalid nwid:477  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


#iwconfig ath0 scan :
ath0      Scan completed :
          Cell 01 - Address: 00:12:17:xx:xx:xx
                    ESSID:"linksys"
                    Mode:Master
                    Frequency:2.412 GHz (Channel 1)
                    Quality=32/70  Signal level=-63 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
                    Extra:bcn_int=50
...

Back sitting next to the AP :

# iwlist ath0 scan
ath0      Scan completed :
          Cell 01 - Address: 00:12:17:xx:xx:xx
                    ESSID:"linksys"
                    Mode:Master
                    Frequency:2.412 GHz (Channel 1)
                    Quality=39/70  Signal level=-56 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
                    Extra:bcn_int=50
...

Anymore ideas/things I can try out ?

Thanks.

01/06/08 20:34:27 changed by geert.steyaert@gmail.com

A dump from the system messages, as recorded from removing the USB mouse and moving laptop into other room, including the coming back, as of 19:52:28, the reconnecting of the mouse, sitting next to AP.

Jan  6 19:10:54 be05294 kernel: usb 1-1: USB disconnect, address 4
Jan  6 19:21:09 be05294 NetworkManager: <info>  ath0: link timed out. 
Jan  6 19:21:09 be05294 NetworkManager: <info>  SWITCH: found better connection 'ath0/linksys' than current connection 'ath0/linksys'.  same_ssid=1, have_link=0 
Jan  6 19:21:09 be05294 NetworkManager: <info>  Will activate connection 'ath0/linksys'. 
Jan  6 19:21:09 be05294 NetworkManager: <info>  Device ath0 activation scheduled... 
Jan  6 19:21:09 be05294 NetworkManager: <info>  Deactivating device ath0. 
Jan  6 19:21:09 be05294 dhclient: wifi0: unknown hardware address type 801
Jan  6 19:21:09 be05294 dhclient: wifi0: unknown hardware address type 801
Jan  6 19:21:09 be05294 dhclient: DHCPRELEASE on ath0 to 10.110.0.2 port 67
Jan  6 19:21:09 be05294 dhcdbd:  dhclient 4698 down (9) but si_code == 0 and releasing==0 !
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) started... 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled... 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) started... 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) scheduled... 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) complete. 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) starting... 
Jan  6 19:21:10 be05294 NetworkManager: <info>  IBM Wireless - workaround setting ESSID to linksys 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0/wireless): access point 'linksys' is encrypted, but NO valid key exists.  New key needed. 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) New wireless user key requested for network 'linksys'. 
Jan  6 19:21:10 be05294 NetworkManager: <info>  DHCP daemon state is now 14 (normal exit) for interface ath0 
Jan  6 19:21:10 be05294 NetworkManager: <info>  DHCP daemon state is now 11 (unknown) for interface ath0 
Jan  6 19:21:10 be05294 NetworkManager: <info>  DHCP daemon state is now 14 (normal exit) for interface ath0 
Jan  6 19:21:10 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) complete. 
Jan  6 19:21:10 be05294 avahi-daemon[3361]: Withdrawing address record for 10.110.0.116 on ath0.
Jan  6 19:21:10 be05294 avahi-daemon[3361]: Leaving mDNS multicast group on interface ath0.IPv4 with address 10.110.0.116.
Jan  6 19:21:10 be05294 avahi-daemon[3361]: iface.c: interface_mdns_mcast_join() called but no local address available.
Jan  6 19:21:10 be05294 avahi-daemon[3361]: Interface ath0.IPv4 no longer relevant for mDNS.
Jan  6 19:21:11 be05294 NetworkManager: <info>  Activation (ath0) New wireless user key for network 'linksys' received. 
Jan  6 19:21:11 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled... 
Jan  6 19:21:11 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) started... 
Jan  6 19:21:11 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) scheduled... 
Jan  6 19:21:11 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) complete. 
Jan  6 19:21:11 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) starting... 
Jan  6 19:21:11 be05294 NetworkManager: <info>  IBM Wireless - workaround setting ESSID to linksys 
Jan  6 19:21:11 be05294 NetworkManager: <info>  Activation (ath0/wireless): access point 'linksys' is encrypted, and a key exists.  No new key needed. 
Jan  6 19:21:12 be05294 NetworkManager: <info>  IBM Wireless - FOUND DRIVER madwifi 
Jan  6 19:21:12 be05294 NetworkManager: <info>  Setting wpa_supplicant driver to madwifi 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'INTERFACE_ADD ath0		madwifi	/var/run/wpa_supplicant	' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  IBM Wireless - Setting AP_SCAN to 1 as this is the default 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'AP_SCAN 1' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'ADD_NETWORK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was '0' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 ssid 6c696e6b737973' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  IBM Wireless - Setting SCAN_SSID overwritten by custom settings to 1 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 scan_ssid 1' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 proto WPA2' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 key_mgmt WPA-PSK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 psk <key>' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: sending command 'ENABLE_NETWORK 0' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:21:12 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) complete. 
Jan  6 19:21:12 be05294 NetworkManager: <info>  Activation (ath0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to access point 'linksys'. 
Jan  6 19:21:12 be05294 NetworkManager: <info>  Activation (ath0) Stage 3 of 5 (IP Configure Start) scheduled. 
Jan  6 19:21:12 be05294 NetworkManager: <info>  Activation (ath0) Stage 3 of 5 (IP Configure Start) started... 
Jan  6 19:21:13 be05294 NetworkManager: <info>  Activation (ath0) Beginning DHCP transaction. 
Jan  6 19:21:13 be05294 NetworkManager: <info>  Activation (ath0) Stage 3 of 5 (IP Configure Start) complete. 
Jan  6 19:21:13 be05294 NetworkManager: <info>  DHCP daemon state is now 12 (successfully started) for interface ath0 
Jan  6 19:21:13 be05294 dhclient: wifi0: unknown hardware address type 801
Jan  6 19:21:13 be05294 NetworkManager: <info>  DHCP daemon state is now 1 (starting) for interface ath0 
Jan  6 19:21:13 be05294 dhclient: wifi0: unknown hardware address type 801
Jan  6 19:21:13 be05294 dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8
Jan  6 19:21:21 be05294 dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 18
Jan  6 19:21:39 be05294 dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 18
Jan  6 19:21:41 be05294 NetworkManager: <info>  Old device 'ath0' activating, won't change. 
Jan  6 19:21:45 be05294 NetworkManager: <info>  ath0: link timed out. 
Jan  6 19:21:45 be05294 NetworkManager: <info>  Old device 'ath0' activating, won't change. 
Jan  6 19:21:57 be05294 dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 13
Jan  6 19:22:06 be05294 NetworkManager: <info>  ath0: link timed out. 
Jan  6 19:22:10 be05294 dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4
Jan  6 19:22:14 be05294 dhclient: No DHCPOFFERS received.
Jan  6 19:22:14 be05294 dhcdbd: Unrequested down ?:3
Jan  6 19:22:14 be05294 NetworkManager: <info>  DHCP daemon state is now 14 (normal exit) for interface ath0 
Jan  6 19:22:46 be05294 NetworkManager: <info>  ath0: link timed out. 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Device 'ath0' DHCP transaction took too long (>99s), stopping it. 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Activation (ath0) Stage 4 of 5 (IP Configure Timeout) scheduled... 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Activation (ath0) Stage 4 of 5 (IP Configure Timeout) started... 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Activation (ath0) failure scheduled... 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Activation (ath0) Stage 4 of 5 (IP Configure Timeout) complete. 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Activation (ath0) failed for access point (linksys) 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Activation (ath0) failed. 
Jan  6 19:22:52 be05294 NetworkManager: <info>  Deactivating device ath0. 
Jan  6 19:26:29 be05294 ntpd[4748]: sendto(79.99.122.30) (fd=18): Invalid argument
Jan  6 19:28:17 be05294 ntpd[4748]: sendto(80.200.240.52) (fd=18): Invalid argument
Jan  6 19:28:35 be05294 ntpd[4748]: sendto(78.40.96.167) (fd=18): Invalid argument
Jan  6 19:43:33 be05294 ntpd[4748]: sendto(79.99.122.30) (fd=18): Invalid argument
Jan  6 19:45:22 be05294 ntpd[4748]: sendto(80.200.240.52) (fd=18): Invalid argument
Jan  6 19:45:38 be05294 ntpd[4748]: sendto(78.40.96.167) (fd=18): Invalid argument

Jan  6 19:52:28 be05294 kernel: usb 1-1: new low speed USB device using uhci_hcd and address 5
Jan  6 19:52:29 be05294 kernel: usb 1-1: configuration #1 chosen from 1 choice
Jan  6 19:52:29 be05294 kernel: input: Logitech Optical USB Mouse as /class/input/input5
Jan  6 19:52:29 be05294 kernel: input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on usb-0000:00:1d.0-1
Jan  6 19:52:50 be05294 NetworkManager: <info>  User Switch: /org/freedesktop/NetworkManager/Devices/ath0 / linksys 
Jan  6 19:52:50 be05294 NetworkManager: <info>  Deactivating device ath0. 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Device ath0 activation scheduled... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) started... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) started... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) scheduled... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) complete. 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) starting... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  IBM Wireless - workaround setting ESSID to linksys 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0/wireless): access point 'linksys' is encrypted, but NO valid key exists.  New key needed. 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) New wireless user key requested for network 'linksys'. 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) complete. 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) New wireless user key for network 'linksys' received. 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) started... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) scheduled... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 1 of 5 (Device Prepare) complete. 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) starting... 
Jan  6 19:52:51 be05294 NetworkManager: <info>  IBM Wireless - workaround setting ESSID to linksys 
Jan  6 19:52:51 be05294 NetworkManager: <info>  Activation (ath0/wireless): access point 'linksys' is encrypted, and a key exists.  No new key needed. 
Jan  6 19:52:52 be05294 NetworkManager: <info>  IBM Wireless - FOUND DRIVER madwifi 
Jan  6 19:52:52 be05294 NetworkManager: <info>  Setting wpa_supplicant driver to madwifi 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'INTERFACE_ADD ath0		madwifi	/var/run/wpa_supplicant	' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  IBM Wireless - Setting AP_SCAN to 1 as this is the default 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'AP_SCAN 1' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'ADD_NETWORK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was '0' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 ssid 6c696e6b737973' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  IBM Wireless - Setting SCAN_SSID overwritten by custom settings to 1 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 scan_ssid 1' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 proto WPA2' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 key_mgmt WPA-PSK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'SET_NETWORK 0 psk <key>' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: sending command 'ENABLE_NETWORK 0' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  SUP: response was 'OK' 
Jan  6 19:52:52 be05294 NetworkManager: <info>  Activation (ath0) Stage 2 of 5 (Device Configure) complete. 
Jan  6 19:52:52 be05294 NetworkManager: <info>  Activation (ath0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to access point 'linksys'. 
Jan  6 19:52:52 be05294 NetworkManager: <info>  Activation (ath0) Stage 3 of 5 (IP Configure Start) scheduled. 
Jan  6 19:52:52 be05294 NetworkManager: <info>  Activation (ath0) Stage 3 of 5 (IP Configure Start) started... 
Jan  6 19:52:54 be05294 NetworkManager: <info>  Activation (ath0) Beginning DHCP transaction. 
Jan  6 19:52:54 be05294 NetworkManager: <info>  Activation (ath0) Stage 3 of 5 (IP Configure Start) complete. 
Jan  6 19:52:54 be05294 NetworkManager: <info>  DHCP daemon state is now 12 (successfully started) for interface ath0 
Jan  6 19:52:54 be05294 dhclient: wifi0: unknown hardware address type 801
Jan  6 19:52:54 be05294 NetworkManager: <info>  DHCP daemon state is now 1 (starting) for interface ath0 
Jan  6 19:52:54 be05294 dhclient: wifi0: unknown hardware address type 801
Jan  6 19:52:54 be05294 dhclient: DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 3
Jan  6 19:52:54 be05294 dhclient: DHCPOFFER from 10.110.0.2
Jan  6 19:52:54 be05294 dhclient: DHCPREQUEST on ath0 to 255.255.255.255 port 67
Jan  6 19:52:54 be05294 dhclient: DHCPACK from 10.110.0.2
Jan  6 19:52:54 be05294 NetworkManager: <info>  DHCP daemon state is now 2 (bound) for interface ath0 
Jan  6 19:52:54 be05294 NetworkManager: <info>  Activation (ath0) Stage 4 of 5 (IP Configure Get) scheduled... 
Jan  6 19:52:54 be05294 NetworkManager: <info>  Activation (ath0) Stage 4 of 5 (IP Configure Get) started... 
Jan  6 19:52:54 be05294 dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.host_name
Jan  6 19:52:54 be05294 dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_domain
Jan  6 19:52:54 be05294 dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_servers
Jan  6 19:52:54 be05294 NetworkManager: <info>  Retrieved the following IP4 configuration from the DHCP daemon: 
Jan  6 19:52:54 be05294 NetworkManager: <info>    address 10.110.0.116 
Jan  6 19:52:54 be05294 NetworkManager: <info>    netmask 255.255.255.0 
Jan  6 19:52:54 be05294 NetworkManager: <info>    broadcast 10.110.0.255 
Jan  6 19:52:54 be05294 NetworkManager: <info>    gateway 10.110.0.2 
Jan  6 19:52:54 be05294 NetworkManager: <info>    nameserver 10.110.0.2 
Jan  6 19:52:54 be05294 NetworkManager: <info>    domain name 'ibm.com' 
Jan  6 19:52:54 be05294 NetworkManager: <info>  Activation (ath0) Stage 5 of 5 (IP Configure Commit) scheduled... 
Jan  6 19:52:54 be05294 NetworkManager: <info>  Activation (ath0) Stage 4 of 5 (IP Configure Get) complete. 
Jan  6 19:52:54 be05294 NetworkManager: <info>  Activation (ath0) Stage 5 of 5 (IP Configure Commit) started... 
Jan  6 19:52:54 be05294 avahi-daemon[3361]: New relevant interface ath0.IPv4 for mDNS.
Jan  6 19:52:54 be05294 avahi-daemon[3361]: Joining mDNS multicast group on interface ath0.IPv4 with address 10.110.0.116.
Jan  6 19:52:54 be05294 dhclient: bound to 10.110.0.116 -- renewal in 41223 seconds.
Jan  6 19:52:54 be05294 avahi-daemon[3361]: Registering new address record for 10.110.0.116 on ath0.
Jan  6 19:52:54 be05294 kernel: FIREWALL: IN=ath0 OUT= MAC= SRC=10.110.0.116 DST=224.0.0.251 LEN=385 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=365 
Jan  6 19:52:54 be05294 kernel: FIREWALL: IN=ath0 OUT= MAC= SRC=10.110.0.116 DST=224.0.0.251 LEN=210 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=190 
Jan  6 19:52:55 be05294 kernel: FIREWALL: IN=ath0 OUT= MAC= SRC=10.110.0.116 DST=224.0.0.251 LEN=385 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=365 
Jan  6 19:52:55 be05294 kernel: FIREWALL: IN=ath0 OUT= MAC= SRC=10.110.0.116 DST=224.0.0.251 LEN=385 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=365 
Jan  6 19:52:55 be05294 kernel: FIREWALL: IN=ath0 OUT= MAC= SRC=10.110.0.116 DST=224.0.0.251 LEN=263 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=243 
Jan  6 19:52:55 be05294 NetworkManager: <info>  Activation (ath0) successful, device activated. 
Jan  6 19:52:55 be05294 NetworkManager: <info>  Activation (ath0) Finish handler scheduled. 
Jan  6 19:52:55 be05294 NetworkManager: <info>  Activation (ath0) Stage 5 of 5 (IP Configure Commit) complete. 
Jan  6 19:52:56 be05294 NetworkManager: <info>  Setting reconnection timeout to 60000 msec 

01/12/08 20:58:19 changed by geert.steyaert@gmail.com

good news ... finally ... YES !!!!

I installed subversion, checked out the latest trunk version,

make clean; make all; make reinstall

Reboot

And it worked ! I'm writing this entry over the WiFi link :) The Transmit Power seems to be stable high (17 dBm), maybe other changes also helped solve the problem.

Just posting this back to let people know how 'easy' it is to fix this annoying issue :)

Geert

Some details :

#athstats

204 tx management frames
15 long on-chip tx retries
185 tx frames with no ack marked
855 tx frames with short preamble
1 rx failed due to bad CRC
434 periodic calibrations
rssi of last ack: 26
rssi of last rcv: 26
3 switched default/rx antenna
Antenna profile:
[1] tx      886 rx     5265
[2] tx       17 rx       15

#iwconfig

ath0      IEEE 802.11g  ESSID:"Clarion" 
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:0F:24:8C:26:20  
          Bit Rate:11 Mb/s   Tx-Power=17 dBm   Sensitivity=1/1 
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=26/70  Signal level=-60 dBm  Noise level=-86 dBm
          Rx invalid nwid:6  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

# iwlist ath0 txpower

ath0      8 available transmit-powers :
          0 dBm         (1 mW)
          5 dBm         (3 mW)
          7 dBm         (5 mW)
          9 dBm         (7 mW)
          11 dBm        (12 mW)
          13 dBm        (19 mW)
          15 dBm        (31 mW)
          17 dBm        (50 mW)
          Current Tx-Power=17 dBm       (50 mW)

#grep -r . /proc/sys/dev/{wifi0,ath}/*

/proc/sys/dev/wifi0/ackrate:0
/proc/sys/dev/wifi0/acktimeout:48
/proc/sys/dev/wifi0/countrycode:0
/proc/sys/dev/wifi0/ctstimeout:48
/proc/sys/dev/wifi0/debug:0
/proc/sys/dev/wifi0/diversity:1
/proc/sys/dev/wifi0/fftxqmin:3
/proc/sys/dev/wifi0/ledpin:0
/proc/sys/dev/wifi0/regdomain:98
/proc/sys/dev/wifi0/rxantenna:1
/proc/sys/dev/wifi0/slottime:9
/proc/sys/dev/wifi0/softled:1
/proc/sys/dev/wifi0/txantenna:0
/proc/sys/dev/wifi0/txintrperiod:5
/proc/sys/dev/wifi0/xrpollcount:32
/proc/sys/dev/wifi0/xrpollperiod:100
/proc/sys/dev/ath/calibrate:1
/proc/sys/dev/ath/countrycode:0
/proc/sys/dev/ath/debug:0
/proc/sys/dev/ath/hal/swba_backoff:0
/proc/sys/dev/ath/hal/sw_beacon_response_time:10
/proc/sys/dev/ath/hal/dma_beacon_response_time:2
/proc/sys/dev/ath/outdoor:0
/proc/sys/dev/ath/xchanmode:1

good news ... finally ... YES !!!!

Installed subversion, checked out the latest trunk version,

make clean; make all; make reinstall

Reboot

And it worked ! I'm writing this entry over the WiFi link :) The Transmit Power seems to be consistently high (17 dBm now, 50 mW), maybe other changes also helped solve the problem.

Just posting this back to let people know how 'easy' it is to fix this annoying issue :)

Geert

Some details :

#athstats

204 tx management frames
15 long on-chip tx retries
185 tx frames with no ack marked
855 tx frames with short preamble
1 rx failed due to bad CRC
434 periodic calibrations
rssi of last ack: 26
rssi of last rcv: 26
3 switched default/rx antenna
Antenna profile:
[1] tx      886 rx     5265
[2] tx       17 rx       15

#iwconfig

ath0      IEEE 802.11g  ESSID:"Clarion" 
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:0F:24:8C:26:20  
          Bit Rate:11 Mb/s   Tx-Power=17 dBm   Sensitivity=1/1 
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=26/70  Signal level=-60 dBm  Noise level=-86 dBm
          Rx invalid nwid:6  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

# iwlist ath0 txpower

ath0      8 available transmit-powers :
          0 dBm         (1 mW)
          5 dBm         (3 mW)
          7 dBm         (5 mW)
          9 dBm         (7 mW)
          11 dBm        (12 mW)
          13 dBm        (19 mW)
          15 dBm        (31 mW)
          17 dBm        (50 mW)
          Current Tx-Power=17 dBm       (50 mW)

#grep -r . /proc/sys/dev/{wifi0,ath}/*

/proc/sys/dev/wifi0/ackrate:0
/proc/sys/dev/wifi0/acktimeout:48
/proc/sys/dev/wifi0/countrycode:0
/proc/sys/dev/wifi0/ctstimeout:48
/proc/sys/dev/wifi0/debug:0
/proc/sys/dev/wifi0/diversity:1
/proc/sys/dev/wifi0/fftxqmin:3
/proc/sys/dev/wifi0/ledpin:0
/proc/sys/dev/wifi0/regdomain:98
/proc/sys/dev/wifi0/rxantenna:1
/proc/sys/dev/wifi0/slottime:9
/proc/sys/dev/wifi0/softled:1
/proc/sys/dev/wifi0/txantenna:0
/proc/sys/dev/wifi0/txintrperiod:5
/proc/sys/dev/wifi0/xrpollcount:32
/proc/sys/dev/wifi0/xrpollperiod:100
/proc/sys/dev/ath/calibrate:1
/proc/sys/dev/ath/countrycode:0
/proc/sys/dev/ath/debug:0
/proc/sys/dev/ath/hal/swba_backoff:0
/proc/sys/dev/ath/hal/sw_beacon_response_time:10
/proc/sys/dev/ath/hal/dma_beacon_response_time:2
/proc/sys/dev/ath/outdoor:0
/proc/sys/dev/ath/xchanmode:1

02/13/08 04:52:41 changed by jra@baylink.com

My problems with the 5212 are much less severe than most people's here (SuSE 10.2, 0.9.3.3, talking to a WHR-G125 running DD-WRT v24rc1 at 56mW xmit, 40 feet across my house):

I get occasional loss of association to my AP; sometimes it can auto-reassociate... sometimes I have to force it manually through networkmanager, and just occasionally, it won't sync up for a while.

I've tried the suggested

iwpriv ath0 bgscan 0 ff 0 burst 0 protmode 0

and so far it hasn't dropped on me since, though I don't know if that's data yet.

I cannot connect at *all*, though, to my office wifi, a Belkin running WEP128 (or, indeed, any WEP128 AP). Given the good results people seem to be seeing with SVN, can anyone make a projection as to when 0.9.4 will be pinched off?

I see that all 0.9.5 tickets are closed on the roadmap, but only 3/15 for 0.9.4, does that mean that we'll jump directly to .5 when the .4 tickets close? :-)

02/14/08 06:01:26 changed by jeremy

i'm having the same problems. i'm typing this on a computer with xubuntu and ipw2200, with a fair signal. my debian g3 powerbook with madwifi beside it gets zip, very very low. don't blame the powerbook, it works fine otherwise :).

a new driver was released today. are the changes mentioned by geert.steyaert@gmail.com above in this version, or should i go and try the svn one?

(follow-up: ↓ 42 ) 02/15/08 03:09:38 changed by anonymous

0.9.4 has not fixed my problems

(in reply to: ↑ 41 ; follow-up: ↓ 43 ) 02/15/08 05:50:39 changed by mrenzmann

Replying to anonymous:

0.9.4 has not fixed my problems

Please explain. Did you actually try to turn ANI off, or did you just use the new version the way you did with the old?

(in reply to: ↑ 42 ; follow-up: ↓ 44 ) 02/15/08 21:30:11 changed by anonymous

i used it the same way as the old, turning off antenna diversity and setting rx/txantenna to 1. pardon my ignorance; what is ANI? i'll try it, anything...

(in reply to: ↑ 43 ) 02/18/08 05:54:03 changed by mrenzmann

Replying to anonymous:

i used it the same way as the old, turning off antenna diversity and setting rx/txantenna to 1.

No surprise then that 0.9.4 did not work different for you than older versions. No idea why you expected that, by the way.

pardon my ignorance; what is ANI? i'll try it, anything...

See #705, especially the last comment by br1 (02/14/08 07:30:27).

12/25/08 11:34:37 changed by crosser@average.org

I run Ubuntu Intrepid on ThinkPad? T60p, chip AR5212 802.11abg NIC (rev 01). Under Windows, wireless works flawlessly, signal level is 80 - 100%. WiFi phone (Nokia E61, N85), too, reports good signal and works fine. Under Linux, signal is reported very low, and connection is intermittent. Tried with stock Ubuntu driver, with SVN rev. 3901, and also with a patch suggested in #705. As per suggestion earlier in this ticket, tried

# iwpriv ath1 hostroaming 0
# iwpriv ath1 rate11g_x2 1
# iwpriv ath1 rssi11g 1

and nothing of that made any difference.

# iwconfig ath1
ath1      IEEE 802.11g  ESSID:""  Nickname:""
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:23:04:xx:xx:xx   
          Bit Rate:1 Mb/s   Tx-Power:17 dBm   Sensitivity=1/1  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=31/70  Signal level=-64 dBm  Noise level=-95 dBm
          Rx invalid nwid:45289  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
# athstats
3755 tx management frames
36 long on-chip tx retries
3530 tx frames with no ack marked
3607 tx frames with short preamble
11440 rx failed due to bad CRC
519 PHY errors
    519 CCK restart
rssi of last rcv: 31
612 switched default/rx antenna
Antenna profile:
[1] tx       51 rx    59796
[2] tx     1798 rx    28623
# iwlist ath1 txpower
ath1      8 available transmit-powers :
	  0 dBm  	(1 mW)
	  5 dBm  	(3 mW)
	  7 dBm  	(5 mW)
	  9 dBm  	(7 mW)
	  11 dBm  	(12 mW)
	  13 dBm  	(19 mW)
	  15 dBm  	(31 mW)
	  17 dBm  	(50 mW)
          Current Tx-Power:17 dBm  	(50 mW)
# grep -r . /proc/sys/dev/{wifi0,ath}/*
/proc/sys/dev/wifi0/ackrate:0
/proc/sys/dev/wifi0/acktimeout:30
/proc/sys/dev/wifi0/countrycode:0
/proc/sys/dev/wifi0/ctstimeout:30
/proc/sys/dev/wifi0/debug:0
/proc/sys/dev/wifi0/distance:750
/proc/sys/dev/wifi0/diversity:1
/proc/sys/dev/wifi0/fftxqmin:3
/proc/sys/dev/wifi0/intmit:0
/proc/sys/dev/wifi0/ledpin:0
/proc/sys/dev/wifi0/maxvaps:4
/proc/sys/dev/wifi0/radar_ignored:0
/proc/sys/dev/wifi0/regdomain:98
/proc/sys/dev/wifi0/rp_ignored:0
/proc/sys/dev/wifi0/rxantenna:1
/proc/sys/dev/wifi0/slottime:20
/proc/sys/dev/wifi0/softled:1
/proc/sys/dev/wifi0/txantenna:0
/proc/sys/dev/wifi0/txintrperiod:5
/proc/sys/dev/wifi0/xrpollcount:32
/proc/sys/dev/wifi0/xrpollperiod:100
/proc/sys/dev/ath/countrycode:0
/proc/sys/dev/ath/debug:0
/proc/sys/dev/ath/hal/dma_beacon_response_time:2
/proc/sys/dev/ath/hal/sw_beacon_response_time:10
/proc/sys/dev/ath/hal/swba_backoff:0
/proc/sys/dev/ath/maxvaps:4
/proc/sys/dev/ath/outdoor:0
/proc/sys/dev/ath/xchanmode:0

Any suggestions?

Thanks,

Eugene

07/01/09 23:44:18 changed by anonymous

Have you tried it with softled=0 OR (softled = 1 AND ledpin = 1)? This solved the problem on my AR5212.

07/02/09 12:01:13 changed by crosser@average.org

1. "sysctl -w dev.{wifi0|wifi1|ath1|wmaster0}.softled=0" yields "error: "dev.xxxx.softled" is an unknown key" for me (kernel 2.6.29).

2. Seriously? How on earth the LED wiring may affect the signal stability?

Eugene

07/02/09 14:11:22 changed by anonymous

2. Seriously? How on earth the LED wiring may affect the signal stability?

That's what I thought in the first place too. The problem is (as far as I understand) GPIO-related:

- pin0 of the card usually triggers rfkill (on 2.6 kernels) - if you set the blinking led to pin0, each time a packet comes in the rfkill switch is being triggered

Do you have anything in /proc/sys/dev?

03/09/10 13:29:28 changed by crosser@average.org

Just a (very late) note that the problem is completely gone as of Ubuntu Karmic (currently, that is kernel 2.6.31 that comes with ath5k 0.6.0, and wpa_supplicant 0.6.9).