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

Opened 15 years ago

Last modified 15 years ago

Thinkpad R40 - reduced scan results since r2360

Reported by: ziegler@uni-freiburg.de Assigned to:
Priority: major Milestone:
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description (Last modified by mentor)

I cannot longer conncect to the AP using madwifi, since I updated to r2360. (The last version I checked is the r2367). Accompanying symptom: "iwlist ath0 scan" lists only half of the stations I normally see (but it lists (sometimes) the station I want to connect to.)

I run Debian testing on a thinkpad R40. I try to connect with wireless-tools (28-1) and wpasupplicant (0.6.0~cvs20070224-3) to a WPAII-encrypted AP. My wireless card is Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01).

The syslog after loading driver (r2367) (I removed date and time)

ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133)
wlan: 0.8.4.2 (svn r2367)
ath_pci: 0.9.4.5 (svn r2367)
PCI: Enabling device 0000:02:02.0 (0310 -> 0312)
ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
ath_rate_sample: 1.2 (svn r2367)
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 5.6 phy 4.1 5 GHz radio 1.7 2 GHz radio 2.3
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5212: mem=0xc0200000, irq=11

The syslog for r2357 is the same except that the version numbers are changed and the first line, which is: ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)

Attachments

madwifi-0.9.3-ionizer-no-min-rssi.diff (1.6 kB) - added by mtaylor on 05/24/07 20:48:45.
Remove minimum RSSI from scan results.
scan_results_2357 (3.5 kB) - added by ziegler@uni-freiburg.de on 05/25/07 01:02:06.
scan using r2357
scan_results_2371 (2.2 kB) - added by ziegler@uni-freiburg.de on 05/25/07 01:02:46.
scan using r2371

Change History

05/24/07 20:07:25 changed by mentor

  • description changed.

05/24/07 20:10:35 changed by mentor

  • description changed.

05/24/07 20:11:57 changed by mentor

  • summary changed from madwifi stopped working with my thinkpad R40 since version r2360 to Thinkpad R40 - reduced scan results since r2360.

05/24/07 20:13:02 changed by mentor

Is there any pattern as to which scan results show up?

05/24/07 20:13:54 changed by mentor

  • priority changed from blocker to major.

05/24/07 20:48:45 changed by mtaylor

  • attachment madwifi-0.9.3-ionizer-no-min-rssi.diff added.

Remove minimum RSSI from scan results.

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

The attached patch eliminates a filter that is applied to stations scanning for APs. It would drop any AP with low RSSI. I got this patch from Lintrack and the rational was that people almost always want to see everything even if the numbers are low and often an unstable link is better than nothing.

I'm suspicious that this is a duplicate of the 'sensitivity' issue that has been reported elsewhere and removing this filter might give us another data point.

Mentor, what do you think?

05/24/07 20:52:09 changed by mtaylor

It occurs to me that we might also use my reverse engineering patch to dump the registers from the old HAL and the new and see if there is something different in the noise floor register or the calibration registers.

Same advice I gave to the guy with 1343 regarding digging deeper into the problem on your end. #1343

05/25/07 01:02:06 changed by ziegler@uni-freiburg.de

  • attachment scan_results_2357 added.

scan using r2357

05/25/07 01:02:46 changed by ziegler@uni-freiburg.de

  • attachment scan_results_2371 added.

scan using r2371

05/25/07 01:11:30 changed by ziegler@uni-freiburg

I attached the scan results using r2357 and r2371. (Adresses and ESSIDs anonymized). r2371 lists 3 APs; 2357 lists two more (Name-1 and Name-2), which are weaker than the others.

With r2357 I can connect with Name-2, with r2371 I cannot!!

05/25/07 01:44:57 changed by ziegler@uni-freiburg

r2371 connects to my AP if its is strong enough. So I would describe the problem as "madwifi r2371 does not connect to weak APs".

05/25/07 18:19:53 changed by mentor

I don't think we should be filtering scan results. Obviously, we shouldn't report scan results below the clear channel threshold, but by definition we would not be getting such results from the hardware. Decisions on whether to associate or not, based on signal level belong elsewhere...