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 #756 (closed defect: fixed)

Opened 13 years ago

Last modified 12 years ago

AP mode: unable to connect devices to

Reported by: anonymous Assigned to:
Priority: major Milestone:
Component: madwifi: 802.11 stack Version: v0.9.1
Keywords: madwifi connect problem bad ap found Cc:
Patch is attached: 1 Pending:

Description

When I create AP (simplest trivial configuration without security, as described in newbie howto), I have problem connecting to this AP with many Hardware Boxes as clients (Trendnet TEW-510APB, Compex WPE54AG, Some 3Com AP)

With card from other Linux Machine it works, from Windows too.

TEW-510APB periodically writes this debug info:

staSmeJoinCallback: Requesting authentication...
[2 second delay]
[mac of remote ap] [essid]: Bad AP Found! 

I tried many variations with authmode and wep but without efect. If I place WEP keys bad, nothing is written on console.

I also tried 802.11b/g modes wds and other modes which are available and result is same. That makes me feel that problem cloud be on some "higher" sublayer

I tried it with kernel 2.6.14, 2.6.16, 2.6.17, madwifi madwifi-ng-r1485-20060325, madwifi-ng-r1502-20060414, madwifi-0.9.1, madwifi-ng-r1686-20060715

On the web I can't found any info or user with similar problems. Is there any who uses it?

Maybee I repeating periadically some stupid mistake, if somebody runs this config, I'll glad if drop me a mail with all configs, and binary kernel image.

Or any hint to do some deeper debug

Attachments

80211log.log (44.0 kB) - added by tomas@simek.info on 07/18/06 09:11:44.
athdebug.log (485.3 kB) - added by tomas@simek.info on 07/18/06 09:12:58.
foreign_ap_assoc_fix.diff (1.3 kB) - added by tomas@simek.info on 07/19/06 08:58:29.
Patch correcting association many hardware APs in client mode to madwifi AP

Change History

07/18/06 06:20:29 changed by mrenzmann

  • milestone deleted.

Check DevDocs/AthDebug regarding turning on debugging for MadWifi, maybe this gives some more hints.

07/18/06 06:20:40 changed by mrenzmann

  • patch_attached deleted.

07/18/06 09:10:57 changed by tomas@simek.info

I did 0xffffffff debug both 80211 and ath layer. I'm glad I had some minimal result. Interesting is last line last from sample of 80211log. Both Files are attached.

Can somebody fix it or explain what happens ?

Jul 18 08:49:59 tomas kernel: ath0: received probe_req from 00:0e:8e:7b:2a:95 rssi 32
Jul 18 08:49:59 tomas kernel: ath0: ieee80211_tmp_node: c5db0000<00:0e:8e:7b:2a:95> refcnt 1
Jul 18 08:49:59 tomas kernel: ath0: [00:0e:8e:7b:2a:95] recv probe req
Jul 18 08:49:59 tomas kernel: ath0: ieee80211_ref_node (ieee80211_send_mgmt:1789) c5db0000<00:0e:8e:7b:2a:95> refcnt 2
Jul 18 08:49:59 tomas kernel: [00:0e:8e:7b:2a:95] send probe_resp on channel 108
Jul 18 08:49:59 tomas kernel: ath0: ath_tx_start: dac42000<00:11:95:ff:e3:1c> refcnt 5
Jul 18 08:50:00 tomas kernel: ath0: received auth from 00:0e:8e:7b:2a:95 rssi 29
Jul 18 08:50:00 tomas kernel: ath0: [00:0e:8e:7b:2a:95] recv auth frame with algorithm 0 seq 1
Jul 18 08:50:00 tomas kernel: ath0: ieee80211_alloc_node: c359c000<00:0e:8e:7b:2a:95> in station table, refcnt 1
Jul 18 08:50:00 tomas kernel: ath0: ieee80211_auth_open: c359c000<00:0e:8e:7b:2a:95> refcnt 1
Jul 18 08:50:00 tomas kernel: ath0: ieee80211_ref_node (ieee80211_send_mgmt:1789) c359c000<00:0e:8e:7b:2a:95> refcnt 2
Jul 18 08:50:00 tomas kernel: [00:0e:8e:7b:2a:95] send auth on channel 108
Jul 18 08:50:00 tomas kernel: ath0: ath_tx_start: dac42000<00:11:95:ff:e3:1c> refcnt 4
Jul 18 08:50:00 tomas kernel: ath0: [00:0e:8e:7b:2a:95] station authenticated (open)
Jul 18 08:50:00 tomas kernel: ath0: _ieee80211_free_node: c5db0000<00:0e:8e:7b:2a:95> in <gone> table, refcnt 0
Jul 18 08:50:00 tomas kernel: ath0: _ieee80211_crypto_delkey: NONE keyix 65535 flags 0x3 tsc 0 len 0
Jul 18 08:50:00 tomas kernel: ath0: received assoc_req from 00:0e:8e:7b:2a:95 rssi 23
Jul 18 08:50:00 tomas kernel: ath0: [00:0e:8e:7b:2a:95] deny assoc request, capability mismatch 0x100

07/18/06 09:11:44 changed by tomas@simek.info

  • attachment 80211log.log added.

07/18/06 09:12:58 changed by tomas@simek.info

  • attachment athdebug.log added.

07/19/06 08:58:29 changed by tomas@simek.info

  • attachment foreign_ap_assoc_fix.diff added.

Patch correcting association many hardware APs in client mode to madwifi AP

07/19/06 09:10:06 changed by tomas@simek.info

This patch correcting association many hardware APs as client to Madwifi AP. Solution used was change deny association request due capability mismatch (IEEE80211_CAPINFO_ESS in capinfo not set), to warning only. All problematic APs work okay after this

Signed-off-by: Tomas Simek, CCS International <tomas@simek.info>

07/19/06 09:22:03 changed by tomas@simek.info

I found solution of this problem and wrote patch. Becouse I'm total newbie in coding stuff like this, I please someone to check if all is ok more with precise:). I tried to read all instructions. I can't find checkbox "patch attached".

Also is good to check if not do more complex solution (module commandline parameter for ignoring this and similar mitchmatches)

Thank You And hope that this will be usefull.

07/20/06 06:28:08 changed by mrenzmann

  • patch_attached set to 1.

The "patch attached" checkbox is there, but you are not allowed to change it atm. This is a result of no longer granting users the right to modify ticket properties (such as "patch attached") as a response to the ticket spam that shows up here. I'll soon revert that restriction, since we now have better options to get rid of (and prevent) spam.

Thanks for the patch, I'll set the "patch attached" checkbox for you.

08/10/06 14:15:00 changed by anonymous

Works for me. After applying the patch my Trendnet TEW-510APB client now connects to the Atheros AP :-)

07/17/07 15:19:18 changed by mtaylor

  • status changed from new to closed.
  • resolution set to fixed.