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 #973 (new defect)

Opened 15 years ago

Last modified 15 years ago

ThinkPad Z60t: moving from r1543 to r1757 madwifi stops working at all

Reported by: ilpettegolo@yahoo.it Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version:
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Linux Fedora 4 Installed madwifi r1543 working fine. I decided to upgrade to last svn (at the moment r1757), and driver stops working: correctly see the access point, mac address, channel, but no association. I tried with WEP enabled and without any encryption, but no changes. So, I going back and tried all version, starting from r1546. Last working release is r1605, r1611 doesn't work. The configuration is the same (modprobe, network scritps are all untouched). I attach two file with dmesg created from an "ifup" command wuth WEP enabled, with "athdebug xmit", one with release r1605 and one with r1611, and two files with "athstats" "80211stats" after an "ifup" with both version. Let me know if I can do other tests.

Attachments

dmesg-r1605.txt (35.8 kB) - added by ilpettegolo@yahoo.it on 10/22/06 19:46:27.
dmesg with athdebug +xmit
dmesg-r1611.txt (51.4 kB) - added by ilpettegolo@yahoo.it on 10/22/06 19:47:31.
dmesg with athdebug +xmit (madwifi not working)
r1605.txt (0.6 kB) - added by ilpettegolo@yahoo.it on 10/22/06 19:48:41.
output of 80211stats, atstats, islist ap (r1605)
r1611.txt (0.7 kB) - added by ilpettegolo@yahoo.it on 10/22/06 19:49:24.
output of 80211stats, atstats, islist ap (r1611)
madwifi-r1605-FC6-compile.patch (14.2 kB) - added by ilpettegolo@yahoo.it on 12/03/06 22:53:21.
Patch for r1605 to compile on Fedora Core 6 (kernel 2.6.18)

Change History

10/22/06 19:46:27 changed by ilpettegolo@yahoo.it

  • attachment dmesg-r1605.txt added.

dmesg with athdebug +xmit

10/22/06 19:47:31 changed by ilpettegolo@yahoo.it

  • attachment dmesg-r1611.txt added.

dmesg with athdebug +xmit (madwifi not working)

10/22/06 19:48:41 changed by ilpettegolo@yahoo.it

  • attachment r1605.txt added.

output of 80211stats, atstats, islist ap (r1605)

10/22/06 19:49:24 changed by ilpettegolo@yahoo.it

  • attachment r1611.txt added.

output of 80211stats, atstats, islist ap (r1611)

10/28/06 15:47:20 changed by ilpettegolo@yahoo.it

I upgrade to Fedora Core 6. I made some other tests. Old version (r1605) doesn't compile anymore, so I stuck with useless wireless interface. If I go really close to the access point (1-2m) there are more probabilities to get associated and successfully get an IP, but I get 70-80% packet loss. If I go over 4m from the access point I cannot connect anymore. athstats show this:

587 tx management frames
294 tx failed due to too many retries
2444 long on-chip tx retries
538 tx frames with no ack marked
844 tx frames with short preamble
9 tx frames with an alternate rate
1 tx frames with 11g protection
1714 rx failed due to bad CRC
44107 PHY errors
    16168 OFDM timing
    27939 CCK timing
562 periodic calibrations
rssi of last ack: 64
rssi of last rcv: 63
23 switched default/rx antenna
Antenna profile:
[1] tx      299 rx     6219
[2] tx       10 rx      602

after 15 minutes of activity.

The Thinkpad Z60t seem to come with two antennas, one placed in the upper side of the display frame. If I "cover" the antenna (i.e. placing hand) the signal level drop from -31 to -42, and athstats shows one more "switched default/rx antenna".

Regdomain is 98, and if I try to set countrycode to any value (tried Denmark, Germany, Italy, UK) I get the well-known error from hal:

unable to collect channel list from hal; regdomain likely 98 country code 380

10/30/06 11:01:50 changed by mrenzmann

If I go really close to the access point (1-2m) there are more probabilities to get associated and successfully get an IP, but I get 70-80% packet loss.

Check FAQ/SignalTooStrong.

10/30/06 11:38:47 changed by ilpettegolo@yahoo.it

My problem is the opposite. If I go very close, I have association and IP (despite very high packet loss rate), but if I go far from access point (>2m) I totally loss connection. The signal and quality remain high, but no packets at all.

Yesterday I tinker with r1605, and after successfully compiled in Fedora Core 6, I get my card working perfectly, with the same configuration, same access point, same distance from AP, with no packet loss at all.

I think the problem is in tha HAL module, that changed just from r1605 to r1611. From this release on I have always the same problem.

I've found a little differences in the /proc variables: r1605

ath/calibrate:30
ath/countrycode:0
ath/debug:0
ath/outdoor:0
ath/regdomain:0
ath/xchanmode:1
wifi0/ackrate:0
wifi0/acktimeout:48
wifi0/countrycode:0
wifi0/ctstimeout:48
wifi0/debug:0
wifi0/diversity:1
wifi0/fftxqmin:3
wifi0/ledpin:0
wifi0/regdomain:98
wifi0/rxantenna:1
wifi0/slottime:9
wifi0/softled:1
wifi0/tkipmic:1
wifi0/txantenna:0
wifi0/txintrperiod:5
wifi0/xrpollcount:32
wifi0/xrpollperiod:100

r1784

ath/calibrate:1
ath/countrycode:0
ath/debug:0
ath/outdoor:0
ath/xchanmode:1
wifi0/ackrate:0
wifi0/acktimeout:48
wifi0/countrycode:0
wifi0/ctstimeout:48
wifi0/debug:0
wifi0/diversity:1
wifi0/fftxqmin:3
wifi0/ledpin:1
wifi0/regdomain:98
wifi0/rxantenna:1
wifi0/slottime:20
wifi0/softled:1
wifi0/tkipmic:1
wifi0/txantenna:0
wifi0/txintrperiod:5
wifi0/xrpollcount:32
wifi0/xrpollperiod:100

The difference in the wifi0/slottime can be significant?

Thank you

11/08/06 23:22:29 changed by lucag <at> student.ethz.ch

I can confirm the regression between r1605 and r1611. I have a ThinkPad? T60 with a (lspci -n) "168c:1014 (rev 01)" aka "Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)" card. The system is OpenSUSE 10.1 with stock 2.6.16.21-0.25-smp kernel.

r1605 works flawlessly, while r1611 and r1794 (thus possibly every revision in between) do not work at all.

With r1611 I am able to successfully associate to an AP (with or without WEP) but then the connection deteriorates rapidly. iwconfig shows that the card rapidly (in ~5-10 seconds) decreases the rate from 11Mb/s (on a b AP) resp. from 54Mb/s to lower rates until 1Mb/s and then loses the association. After a while it will associate again with the same AP and show the same symptoms. During the short timespan that the association lasts the connection is somewhat usable: I am able to negotiate an ip via dhcp in about half of the cases, in the other half the ACK by the server is simply lost.

11/08/06 23:48:34 changed by lucag <at> student.ethz.ch

Further testing showed that the revision breaking the driver for me is r1606, that is (svn log) "Update HAL to version 0.9.17.0 (from ath_hal-20060506.tgz)".

11/20/06 14:17:38 changed by anonymous

I have exactly the same Problem as lucag. I too have an ETH T60p with the 168c:1014 (rev 01)" WLAN-Card. Unfortunally the r1605 Version isn't compiling with kernel-gentoo-2.6.18-r2 although I've fixed the "roundup-bug".

12/03/06 22:53:21 changed by ilpettegolo@yahoo.it

  • attachment madwifi-r1605-FC6-compile.patch added.

Patch for r1605 to compile on Fedora Core 6 (kernel 2.6.18)

12/18/06 21:56:55 changed by lucag <at> student.ethz.ch

The problem seems related to the mode selection:
iwpriv ath0 mode 2
(i.e. forcing the card into b mode) solves the issues described, as soon as "iwpriv ath0 mode 0" is executed the problem returns.

My "test setup" (using r1863):

iwpriv ath0 mode 2
(associate, get an ip etc..)
ping www.google.com
(no problem at all)
iwpriv ath0 mode 0
(packets stop arriving, rate drops, card desassociates)
iwpriv ath0 mode 2
(card is able to associate again, pings are returned again)

12/21/06 21:21:41 changed by soon

I have tried the exact same thing on my IBM T60 with Atheros 5212.

Switching to mode 2 I can connect (using NetworkManager), going back to mode 0 things deteriorate and become unpredictable ...

Soren O'Neill

01/31/07 13:45:40 changed by lucag <at> student.ethz.ch

This problem seems to have been fixed in the HAL 0.9.20.3 branch.