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

dmesg with athdebug +xmit

dmesg with athdebug +xmit (madwifi not working)

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

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

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

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.

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

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.

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

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

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

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)

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

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