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

Opened 14 years ago

Last modified 14 years ago

Very big problems with actual trunks from 3354 to 3375

Reported by: Assigned to:
Priority: critical Milestone:
Component: madwifi: driver Version: trunk
Keywords: trunk Cc:
Patch is attached: 0 Pending:


Hi again,

I still use Alix/Wrap boards, Voyage linux with 2.6.24-mesh Kernel and stable hostapd/wpasupplicant 0.5.10. Also tested the unstable wpa_supp/hostapd. I have to tell you that all trunks I tested after revision 3348 do not work at all as accesspoint (with or without encryption over hostapd). (3348 works fine!)

Revision 3354 was the first which had problems with AP and Client modus. The connection was cutted every 10 to 20 seconds, but re-associated shortly. But I had 18 to 20% packetloss (in my office!).

Now to the problems with the later trunks after rev 3354 (3358/3370/3375 and so on): After creating an accesspoint with hostapd, the AP appears, and I can associate with my clients. But after a few seconds I recieve "bridge-loop-messages" and the client (also a madwifi node) associates and re-associates continuously (and I am very sure that I do not have a phyiscal connection between the eth0 devices of AP and client!).

Much "funnier" is, when I try to connect with my Macbook, the airport connects to the AP, but after a few seconds I lose connection and scanning with the airport is no longer possible. But if I shut down the AP, install an older trunk and the suitable hostapd and wpa_supp and start my AP-script again after "depmod -ae", my macbook associates immediatly to the "new" AP and scanning function will be re-usable.

So please fix this very annoing bug.

kind regards

Jan Giera

Change History

03/07/08 11:55:34 changed by

I have to correct me. 3348 also panics after a while. Using Ubiquiti SR2 cards. And with Wistron CM9 cards the AP is not pingable after a while. I will do more tests for concrete facts.

So long,


03/10/08 08:52:53 changed by

Good morning.

With SVN 3348 and wpa_supp/hostapd 0.5.10 I also get this ugly messages, that I have build a bridge loop.... so I can say for sure, that this SVN also does NOT work. The problem does appear after a few hours with ping-traffic, or happens a little bit earlier with iperf-traffic.

I'm back on my SVN 3279 ... this one worked for weeks without any troubles. But has the known DFS-problems.... it finds "RADAR"-signals, which are his own second 5ghz ap. It blacklists the channel and does not switch to another 5ghz channel...

... please fix it!...

best wishes