Stuck beacon on latest svn of madwifi

I've noticed that when "stuck beacon" happens, SSH session is still running, while NFS is stone dead. So, I tried to lower MTU on both ends to 400 (arbitrary value, just to test) and voila! No more "stuck beacon" messages! Ring any bells?

While looking more at our leetle fraund the stuck beacon, I tried a version that just ignored them (but still reported when > BSTUCK_THRESH) and noticed that most of the time the bmiss count hit 4, 5, or 6... but then everything was happy again for a while. There seemed to be no huge (any?) irq impact on my node in these cases, so I wonder if BSTUCK_THRESH at 3 is just a bit too low, since the card resetting itself is a major disruption. Perhaps it should be 7 (10?) since nobody really seems to know what causes this - setting it a bit higher should still catch the real problem (a little later) when it shows up.

Interestingly, I did have one run where the number of missed beacons hit 52, then recovered. Unfortunately, I saw this after it occurred and was not running bandwidth tests at the time it happened.

For the record we have an extremely congested RF environment. I count >40 aps (which makes pocket pcs unhappy).

Heh, just wanted to note that I met the friendly stuck-beacon the other day two. He is still lurking somewhere.

I had this problem on my pc running madwifi in ap mode: Aug 17 14:40:34 boerek wifi0: stuck beacon; resetting (bmiss count 4) Aug 17 14:40:34 boerek wifi0: stuck beacon; resetting (bmiss count 4) Aug 17 14:41:34 boerek wifi0: stuck beacon; resetting (bmiss count 4) Aug 17 14:41:35 boerek wifi0: stuck beacon; resetting (bmiss count 4)

After reading the comments I recognized this:

ath0      
          Protokoll:Ethernet  Hardware Adresse 00:14:6C:31:B5:5C  
          inet Adresse:192.168.0.254  Bcast:192.168.0.255  Maske:255.255.255.0
          inet6 Adresse: fe80::214:6cff:fe31:b55c/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:2290  Metric:1
          RX packets:22094 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21509 errors:0 dropped:20 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:3332484 (3.1 Mb)  TX bytes:6135970 (5.8 Mb)
wifi0     Protokoll:UNSPEC  Hardware Adresse 00-14-6C-31-B5-5C-F4-9F-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27276 errors:0 dropped:0 overruns:0 frame:31925
          TX packets:25156 errors:111 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:199 
          RX bytes:4817076 (4.5 Mb)  TX bytes:7154297 (6.8 Mb)
          Interrupt:18 Speicher:e0a40000-e0a50000

The mtu of ath0 is wrong, setting it to 1000 made my system immediatly work again.

I am running madwifi-ng-0.9.2 on gentoo.

I noticed after changing the card to channel 11 i haven't received any 'wifi0: stuck beacon; ressetting (bmisscount 4)

Since D. Lau pinged me on this, I can report that we've been running madwifi-ng with BSTUCK_THRESH set to 9 for over six months now with no ill effects and many fewer resets due to stuck beacon (about once a day, if that, instead of every few seconds for brief periods of the day). At this point I'm fairly convinced that most 'stuck beacon' events are just environmental interference (as in the previous comment from Diamonte) and 3 is too low a threshold.

Perhaps the threshold could be raised a little bit, what do others think? The comment suggests it was simply a wild guess to set 3 as threshold in first place.

I suggest it to make sysctl value, for a beacon miss counter. Then anyone could adjust as they need. At the same time value of 3 seems good enough as default value. Don't have any particular idea what is a good number though.

i have same in dmesg: wifi0: stuck beacon; resetting (bmiss count 4)

i running a la fonera ap with openwrt-kamikaze-svn from yesterday.

i have strange connection-problems

ultralow-tranfer-speeds under 20kbyte/s somtimes the speed is ok, but just for a short time

very strange behavior on answering pings... etc

i will now change the channel from 5 to 11 and tell u if this works...

cheers, flo.

no, doesn't help.

for me too..

I've increased BSTUCK_THRESH to 10 in r1982 as suggested. Please test and report.

I'm using madwifi 0.9.2 release and the problem reported in this ticket was noticed. Applied the patch r1982 but still the problem is noticed.

My setup -

Avila Board IXP425 Debian Linux 2.6.18 Madwifi 0.9.2 Seneo & CM10 radios

The problem is quite reproduced for a while and wasn't later. I captured the debug logs from "athdebug 0xFFFFFFFF" and is attached to the ticket.

Analysing logs in madwifi points to madwifi HAL.

The problem was appearing just after the interface is made UP. Despite multiple reboots the problem persists, which should not happen ideally.

Ironially when I unplug the antenna from the wifi radio card, the problem doesn't appear.

I feel it has something to do with antenna diversity. Experimented all possible combinations but failed to narrow down the root cause to diversity.

debug logs captured when the problem is noticed

I was operating on channel 2 and mode 3.... I got wifi0: stuck beacon; resetting (bmiss count 4) error. I changed to channel 11 and mode remains the same. Surprise...... There is no error.... Thanks. But i cant figure out what happened??? Any idea???

what does all this jgbsdak mean

i changed to channel 11 too and no bacon messages anymore.

I can recreate this experience (consistently) and in general, I would say there is inband interference on the channel you have chosen. My setup includes injecting an interfering RF signal in a closed system. When I do this I get the reported 'stuck beacon'. Hope that helps.

I'm able to reproduce the problem consistently. I'm running 3 access points (within 5 meters of each other), all with the same hardware, same software. I'm running them on the same channel, with the same SSID. I know I'm not suppose to do that, but it is one reliable way for me to reproduce the problem. I'm willing to test any potential patch.

This is the software version I'm running:

ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, REGOPS_FUNC)
wlan: 0.8.4.2 (0.9.3.2)
ath_pci: 0.9.4.5 (0.9.3.2)
PCI: enabling device 0000:00:02.0 (0340 -> 0342)
ath_rate_sample: 1.2 (0.9.3.2)
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: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 10.5 phy 6.1 radio 6.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=0x48000000, irq=28

Setting to channel 11 does not help. I have tested this with reproducible results. The message will appear as long as there's enough interference on any selected channel. Is there a workaround or fix for this problem yet? I'm using version 0.9.4

try using svn r3402 or latest trunk.. it seems to be good for 2,4ghz .. not for 5 tho;

I've tested the latest trunk version and I'm still getting stuck beacon. I was running on channel 6, 2.4GHz range.

wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11)

I'm running this version:

ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, REGOPS_FUNC)
wlan: svn r3680
ath_pci: svn r3680
PCI: enabling device 0000:00:02.0 (0340 -> 0342)
MadWifi: ath_attach: HAL managed transmit power control (TPC) disabled.
MadWifi: ath_attach: Interference mitigation is supported.  Currently disabled.
MadWifi: ath_attach: Switching rfkill capability off.
ath_rate_sample: 1.2 (svn r3680)
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: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: Atheros AR5414 chip found (MAC 10.5, PHY SChip 6.1, Radio 6.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 4 for XR traffic
wifi0: Use hw queue 7 for UAPSD traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
ath_pci: wifi0: Atheros 5212: mem=0x48000000, irq=28
wlan: mac acl policy registered

You're right.. it's back again. Did you try r3402

svn up -r 3402

I'm running r3402 since 1st June, and so far so good, no stuck beacon yet. I'll report if I get stuck beacon.

r3402 has memory leak issue, I can't reliably test for stuck beacon.

hmm. I didn't notice that.. I'm running that version for long time now

I have also encountered the Stuck Beacon.
I am using a Ubiquiti XR2 minipci card, in a PCI-MiniPCI adapter in a PCI-X slot. I am using the madwifi-hal-0.10.5.6 branch on both my AP and my client, though I have tried trunk and 0.9.4. My present revision on the AP is 3722, my client is using r3813.
The AP is configured for WPA2-Enterprise using hostapd and freeradius with a mysql backend.
I originally had the network configured on channel 1 of the 802.11g spectrum. After reading this ticket, I looked around and saw that there was one other network on that channel, though its signal quality was only 2dB. There are quite a few networks on channel 6, so I opted to try out channel 11. This does not seem to have any effect at all on the frequency or duration of stuck beacons for me.
Trolling through the IPMI event logs and my syslogs, I have noticed that every occurence of the SBP is accompanied by a SERR assertion from the PCI bus. It appears that the SERR precedes the SBP by slightly less than a second, based on the logs.
It is also interesting to note that I have two other clients on this network - one using an Intel 3945, and the other a Broadcom (I do not know the specific chipset; it's in a 17" PowerBook? G4). I also have a D-Link WNA-1330 PCMCIA card. The SBP and SERR only occur when I am associated from my Atheros-based cards, but the other clients are also affected by them.
lspci output from the AP:

03:08.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5006X 802.11abg NIC [168c:001b] (rev 01)
        Subsystem: Unknown device [0777:3002]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 96 (2500ns min, 7000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 24
        Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
        Kernel driver in use: ath_pci
        Kernel modules: ath_pci

lspci output from my Atheros client, using its onboard minipci card:

03:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212 802.11abg NIC [168c:1014] (rev 01)
        Subsystem: IBM ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (AR5BXB6) [1014:058a]
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at df2f0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000  Data: 0000
        Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
                Vector table: BAR=0 offset=00000000
                PBA: BAR=0 offset=00000000
        Capabilities: [100] Advanced Error Reporting <?>
        Capabilities: [140] Virtual Channel <?>
        Kernel modules: ath_pci

lspci output from my D-Link WNA-1330:

16:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR2413 802.11bg NIC [168c:001a] (rev 01)
        Subsystem: D-Link System Inc Device [1186:3a1c]
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-`[[BR]]
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at c4000000 (32-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
        Kernel modules: ath_pci

Syslog of a recent SERR/SBP occurrence:

Jul 22 21:25:09 [ipmievd] Critical Interrupt sensor - PCI SERR
Jul 22 21:25:10 [kernel] wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11)
Jul 22 21:25:10 [ipmievd] Critical Interrupt sensor - PCI SERR
Jul 22 21:25:10 [kernel] wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11)
Jul 22 22:36:46 [ipmievd] Critical Interrupt sensor - PCI SERR
Jul 22 22:36:47 [kernel] wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11)

Came across this interesting tidbit on the Ubiquiti forums: Changing pci latency or turning bg scan off didn't help enough. I've stopped all stuck beacon messages with madwifi from OpenWrt tree (svn revision 11415) and all their patches. The entire thread is available at http://forum.ubnt.com/forum/viewtopic.php?p=7410#7410

Replying to keaneyw@gmail.com:

Came across this interesting tidbit on the Ubiquiti forums: Changing pci latency or turning bg scan off didn't help enough. I've stopped all stuck beacon messages with madwifi from OpenWrt tree (svn revision 11415) and all their patches. The entire thread is available at http://forum.ubnt.com/forum/viewtopic.php?p=7410#7410

been there... done that. nothing has changed.

I now have to wonder if maybe this SBP is to do with a defective PCI bus somehow. I have moved my XR2 into another machine, and have been running it for a week now without any stuck beacons at all.

I now have to wonder if maybe this SBP is to do with a defective PCI bus somehow. I have moved my XR2 into another machine, and have been running it for a week now without any stuck beacons at all.

Unlikely. I have 3 sets of hardware, same setup, same problem. Looks more like a bug in the HAL layer.

Hello Everyone.

I applied three changes from the OpenWRT trunk to madwifi-hal-2008-08-15-r3851 and I have lesser stuck beacons now (just 4 messages appeared in the logs during the last hour while it sometimes were about 2 per minute).

I tried the card with high load ( I downloaded 1.2 GB from my server ) the throughput was constantly 1.1 MByte/s (sftp). I applied the following patches from OpenWRT Trunk(manually) 374-nbtt_fix.patch 375-atim_tsf_update.patch 376-beacon_update.patch

I also created a diff against madwifi-hal-2008-08-15-r3851 but I don't know how to append it to this reply.

So If anyone wants to try the patch you can download it from [http: //www.crossbone.org/stuck_beacon_patch.bz2]

Bye willem

Hello everyone.

After one day of testing the AP now i found out something interesting.

First of all i want to describe my enviroment because it's easier to imagine how I use my Wireless enviroment

I am running a Internet Gateway which i also use as fileserver. It has an Abit Airpace WLP-01 Wifi card which is based on the Atheros 2425 (5007eg) chipset. I use this card as my Access point device, running bridged with an Intel 100 Mbit adapter to serve my wired stations.

As Wifi Clients I use a Laptop with a Ralink Rt 2500 pcmcia wireless adapter and a Nokia N80 mobile phone. While the stuck beacon messages disappeared when I only connect with my Laptop (using the patches from Openwrt) I can trigger stuck beacons when connecting with the N80 mobile phone.

Before applying the patch, the connection with the N80 was stable for half an hour sometimes although the log was full of stuck beacon messages. The connection dropped short and was up after a few seconds again. I use the N80 mainly as Internet Radio device while doing some work at home so it takes about 150 kbits/second with an mp3 stream.

But before applying the patch I had frequent stuck beacon messages (about two per minute) even when I connected to the AP only with my Laptop.

Now After applying the patch the connection with my Laptop is very stable as I mentioned in the post above. I don't get any stuck beacon messages as long as I don't connect with my N80.

After about four to five minutes after connecting to the AP with my N80 a stuck beacon is triggered and the connection drops. I cannot reconect with the N80 for about half an hour then and I do not see the AP with my N80 allthough i see it with the Laptop.

Since I don't know what the patch mentioned above does because I don't have much knowledge about programming drivers I even don't understand why this happens.

Maybe someone knows what the patch does and Understands why for example the connection with my laptop is very stable now while it is hardly possible to connect with the N80 mobile phone.

Maybe this is also related to ticket 1775 but noone described the stuck beacon problem there.

Best regards Willem

Sorry for posting again

But this stuck_beacon errors really bug me.

As I mentioned above, I got that far, that the stuck beacon errors only appear when i connect with my Nokia N80 mobile device now. Reading a bit Documentation said that this might be a problem with wmm (Wifi Multimedia) Powersaving unaware access points. The wmm Powersaving works like this "The underlying concept of WMM PowerSave? is that the STA (station) triggers the release of buffered data from the AP by sending an uplink data frame" quoted from Wikipedia. [http ://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions]

So maybe this leads to a problem, because the Access point has to release all data stored in the queues.

Turning power managment off on the N80 prevents stuck beacon messages but is no real solution because Wifi without powersaving drains a lot of battery.

Is it possible to enable the wme power saving feature of madwifi with iwpriv setwmmparams?

Bye Willem

Found this with a bit of googling:

Get WMM Parameters:
iwpriv athX getwmmparams PARAM AC APPLY iwpriv athX getwmmparams PARAM AC APPLY
Set WMM Parameters: Set WMM Parameters:
iwpriv athX setwmmparams PARAM AC APPLY VALUE iwpriv athX setwmmparams PARAM AC APPLY VALUE

PARAM:
1: CWmin 1: CWmin
2: CWmax 2: CWmax
3: AIFS 3: AIFS
4: TxopLimit 4: TxopLimit
5: ACM, optional(0), required(1) 5: ACM, optional (0), required (1)
6: NoAck policy 6: NoAck policy
AC:
0: BE 0: BE
1: BK 1: BK
2: VI 2: VI
3: VO 3: VO
APPLY:
0: AP 0: AP
1: STA 1: STA

My AP is down right now, so I can't test this myself. I might work on getting it back up tonight.

Maybe issuing

iwpriv ath0 wmm 0
iwpriv ath0 uapsd 0

helps.

You have to issue this commands before connecting to the access point with a client.

But this will disable wmm and wmm powermanagment and it would be nice to see wmm working.

Bye

Hello

I tried to lock down the stuck beacon problem further. I turned on the following debug flags with athdebug

athdebug +uapds +beacon +recv_desc

Everytime a stuck beacon happens just before sending out the beacon I get the following message {{{ wifi0: ath_beacon_generate: Draining 1 stalled CABQ transmit buffers. }}}

This ONLY happens when one second later a stuck beacon message appears.

Does anyone know how this could be related to the stuck_beacon?

If anyone needs more debugging with different flags I will help.

Bye Willem

Well, this is new for me and I've ran madwifi for a while. The problems started after I upgraded to linux 2.6.26.3 and using latest trunk of madwifi. The host sometimes just lose connection now (i run linnux as AP) and can't reconnect, very annoying.

Hi all,

I have an AP setup with an Atheros base wifi card (using the AcerOne? notebook). I have hostapd configured for WPA-PSK.

I'm having the same probme with stuck beacons:

ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11)

When this happens, my wireless client (Laptop with intel card 200BG) drops the connection. I have to kill ath0 and recreate to be able to establish a connection again.

I'm using the atheros drivers "madwifi-hal-0.10.5.6-r3861-20080903". My AP is using channel 11 (configured in hostapd). My OS is Ubuntu Intrepid Ibex (kernel 2.6.27-rc7).

I did noticed that the MTU of ath0 is 2296. I haven't tried to lower it as a previous user suggested.

I did tried to change to WPA2 but still have the same problems.

Is there a solution for this problem?

Regards.

Same here, Running hostapd and the latest madwifi trunk. anyone found a solution yet?

Ok I found the solution. Use the older trunk r3314 stable driver. You have to apply all patches from the openwrt tree, and use the newer ath_hal-20081002 also from the openwrt tree. Then patch net80211/ieee80211_wireless.c to make it compile against 2.6.26+. I use the latest git of hostapd and it works fine, even with crappy devices such as mobiles phones/psp.

You can download the complete package here: http ://akelo.ath.cx/~mastag/madwifi-trunk-r3314-patched.tar.gz It contains all of the openwrt patches, the new ath_hal-20081002 and my own patch to make it build against 2.6.26+ and up. Just compile with: make WARNINGS= and install with: make WARNINGS= install

Hope it helps :) At least no suck beacons here. Tested on Fedora 9 x86 2.6.26.6-79.fc9.i686 and the git version of hostapd.

Replying to MastaG:

Ok I found the solution. Use the older trunk r3314 stable driver. You have to apply all patches from the openwrt tree, and use the newer ath_hal-20081002 also from the openwrt tree. Then patch net80211/ieee80211_wireless.c to make it compile against 2.6.26+. I use the latest git of hostapd and it works fine, even with crappy devices such as mobiles phones/psp. You can download the complete package here: http ://akelo.ath.cx/~mastag/madwifi-trunk-r3314-patched.tar.gz It contains all of the openwrt patches, the new ath_hal-20081002 and my own patch to make it build against 2.6.26+ and up. Just compile with: make WARNINGS= and install with: make WARNINGS= install Hope it helps :) At least no suck beacons here. Tested on Fedora 9 x86 2.6.26.6-79.fc9.i686 and the git version of hostapd.

Hi,

I've downloaded your package but can't compile it.

Wireless Card: Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)

Running Ubuntu Intrepid (Kernel 2.6.27-7)

Follows the output

root@ubuntu:~/source/madwifi-trunk-r3314-patched# make WARNINGS= Checking requirements... ok. Checking kernel configuration... ok. make -C /lib/modules/2.6.27-7-server/build SUBDIRS=/root/source/madwifi-trunk-r3314-patched modules make[1]: Entering directory `/usr/src/linux-headers-2.6.27-7-server'

CC [M] /root/source/madwifi-trunk-r3314-patched/ath/if_ath.o CC [M] /root/source/madwifi-trunk-r3314-patched/ath/if_ath_radar.o CC [M] /root/source/madwifi-trunk-r3314-patched/ath/if_ath_pci.o LD [M] /root/source/madwifi-trunk-r3314-patched/ath/ath_pci.o CC [M] /root/source/madwifi-trunk-r3314-patched/ath_hal/ah_os.o LD [M] /root/source/madwifi-trunk-r3314-patched/ath_hal/ath_hal.o CC [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/amrr/amrr.o LD [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/amrr/ath_rate_amrr.o CC [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/minstrel/minstrel.o LD [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/minstrel/ath_rate_minstrel.o CC [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/onoe/onoe.o LD [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/onoe/ath_rate_onoe.o CC [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/sample/sample.o LD [M] /root/source/madwifi-trunk-r3314-patched/ath_rate/sample/ath_rate_sample.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/if_media.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_skb.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_beacon.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_crypto.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_crypto_none.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_input.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_node.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_output.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_power.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_scan.o CC [M] /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.o

/root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c: In function 'giwscan_cb': /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1818: warning: passing argument 2 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1818: warning: passing argument 4 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1818: warning: passing argument 5 of 'iwe_stream_add_event' makes integer from pointer without a cast /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1818: error: too many arguments to function 'iwe_stream_add_event' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1831: warning: passing argument 2 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1831: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1831: warning: passing argument 5 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1831: error: too many arguments to function 'iwe_stream_add_point' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1844: warning: passing argument 2 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1844: warning: passing argument 4 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1844: warning: passing argument 5 of 'iwe_stream_add_event' makes integer from pointer without a cast /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1844: error: too many arguments to function 'iwe_stream_add_event' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1857: warning: passing argument 2 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1857: warning: passing argument 4 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1857: warning: passing argument 5 of 'iwe_stream_add_event' makes integer from pointer without a cast /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1857: error: too many arguments to function 'iwe_stream_add_event' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1868: warning: passing argument 2 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1868: warning: passing argument 4 of 'iwe_stream_add_event' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1868: warning: passing argument 5 of 'iwe_stream_add_event' makes integer from pointer without a cast /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1868: error: too many arguments to function 'iwe_stream_add_event' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1883: warning: passing argument 2 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1883: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1883: warning: passing argument 5 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1883: error: too many arguments to function 'iwe_stream_add_point' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1898: warning: passing argument 2 of 'iwe_stream_add_value' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1898: warning: passing argument 5 of 'iwe_stream_add_value' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1898: warning: passing argument 6 of 'iwe_stream_add_value' makes integer from pointer without a cast /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1898: error: too many arguments to function 'iwe_stream_add_value' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1907: warning: passing argument 2 of 'iwe_stream_add_value' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1907: warning: passing argument 5 of 'iwe_stream_add_value' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1907: warning: passing argument 6 of 'iwe_stream_add_value' makes integer from pointer without a cast /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1907: error: too many arguments to function 'iwe_stream_add_value' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1926: warning: passing argument 2 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1926: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1926: warning: passing argument 5 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1926: error: too many arguments to function 'iwe_stream_add_point' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1950: warning: passing argument 2 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1950: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1950: warning: passing argument 5 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1950: error: too many arguments to function 'iwe_stream_add_point' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1976: warning: passing argument 2 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1976: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1976: warning: passing argument 5 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1976: error: too many arguments to function 'iwe_stream_add_point' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1995: warning: passing argument 2 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1995: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1995: warning: passing argument 5 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:1995: error: too many arguments to function 'iwe_stream_add_point' /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:2013: warning: passing argument 2 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:2013: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:2013: warning: passing argument 5 of 'iwe_stream_add_point' from incompatible pointer type /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.c:2013: error: too many arguments to function 'iwe_stream_add_point' make[3]: *** /root/source/madwifi-trunk-r3314-patched/net80211/ieee80211_wireless.o Error 1 make[2]: *** /root/source/madwifi-trunk-r3314-patched/net80211 Error 2 make[1]: *** [_module_/root/source/madwifi-trunk-r3314-patched] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.27-7-server' make: *** [modules] Error 2

Thank you for your help in providing the package. Hope to ear from you soon.

Thanks.

Hi, i still have the problem above even with the newest madwifi from trunk (r3873 is the one i tested) - sometimes i get stuckbeacon messages and get disconnected clients, sometimes only clients disconnect and i see sudden network performance drop. driver submitted by MastaG (http ://akelo.ath.cx/~mastag/madwifi-trunk-r3314-patched.tar.gz) seems to be a lot more stable on my box as far as stuck beacons go (didnot see any so far), still as i see this is patched earlier build (r3314) and in this case I am getting hit by madwifi bug #1581 - whole box hangs after a few hours of uptime (kernel freeze) which was fixed in r3346.

i am using gentoo 2008.0, card is a minipci on daugther board connected to jetway motheboard J7F5M1G2E-VHE.

02:04.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
        Subsystem: Compaq Computer Corporation Device 00e6
        Flags: bus master, medium devsel, latency 96, IRQ 18
        Memory at dfee0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2
        Kernel driver in use: ath_pci
        Kernel modules: ath_pci
02:04.0 0200: 168c:0013 (rev 01)

I have been fighting with this for several days now and I am coming close to the point where i want to open the window and throw all atheros cards out... ;-)

Can anybody offer any help with this? Or offer any alternatives - newer build from openwrt or ath5k (if it works)?

Rgds,Bogdan

Hi, I thought I add just a few notes: - r3873 from trunk/svn - there seems to be sth majorly wrong with this driver, transfer speeds are around 10-20KB/s (no additional iwconfig/iwprivs set on my side), whereas when I switch to any other drivers mentioned above all works fine (2-3MB/s) - the best drivers I have seen so far are 0.9.3.1 - no stuck beacons, no unexpected kernel hangs/freezes, long time since I have seen such a quality from madwifi ;-) there is unfortunately one problem - they are not compatible with kernels >=2.6.24 - i am testing right now madwifi-hal-0.10.5.6 (r3875) from svn, so far so good, much better than r3873_trunk, only one stuck beacon message, nothing dropped so far (transferred a few GB, between 3 clients). i will let you know in next few days if they are stable... Rgds,B.

Would you mind posting what you did in more detail? I tried running all the patches from the openwrt madwifi patches from trunk as you describe with madwifi-r3314, and sticking in the new hal, however the code still differs a bit from your .tgz

No stuck beacons so far with your bundle; ubuntu-7.04 / kernel 2.6.20 / hostapd 0.5.10

Replying to MastaG:

Ok I found the solution. Use the older trunk r3314 stable driver. You have to apply all patches from the openwrt tree, and use the newer ath_hal-20081002 also from the openwrt tree.

I have stuck beacon problem with all versions of driver, including 0.9.3.1. I've been running the trunk r3314 with openwrt patch posted by MastaG for a few days now, no stuck beacon so far. Running Intel XScale, kernel 2.6.24, hostapd v0.6.3.

Replying to bodo-AT-onet.pl :

- the best drivers I have seen so far are 0.9.3.1 - no stuck beacons, no unexpected kernel hangs/freezes, long time since I have seen such a quality from madwifi ;-) there is unfortunately one problem - they are not compatible with kernels >=2.6.24

some more comments from me - i was testing a few more trunks/snapshots: madwifi-hal-0.10.5.6 (r3785) - stuck beacons, clients disconnect, sometimes dont reconnect (have to disable/reenable network on windows client so that they associate again) madwifi-trunk-r3856-20080903 - same as above madwifi-trunk-r3867-20080924 - same as above btw. the message i see currently is: Nov 13 22:47:12 gizmo kernel_says: wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11) Nov 13 23:04:03 gizmo kernel_says: NETDEV WATCHDOG: wifi0: transmit timed out Nov 13 23:04:05 gizmo kernel_says: wifi0: ath_bstuck_tasklet: Stuck beacon; resetting (beacon miss count: 11) newest trunks seem to be broken differently: madwifi-trunk-r3870-20081104 - driver unusable, transfer speeds of 10-15KB/s madwifi-trunk-r3873-20081105 - driver unusable, transfer speeds of 10-15KB/s

my config: jetway J7F5M1G2E-VHE, with via c7 1.2ghz, AR5212 802.11abg NIC 02:04.0 168c:0013 (rev 01), gentoo 2008.0 (x86), kernel 2.6.25-gentoo-r8, hostapd 0.5.10

note: latest builds seem to be causing a bit less stuck beacons, but even a single one happening means my clients disconnect, which is pretty painful as i use the network for playing video/music and everything simply hangs then.

I would also appreciate if MastaG would describe in a bit more detail how he put together his package. for now i am forced to return to 0.9.3.1...

i guess the reason would be that svn of openwrt is these days also several revisions newer, practically only the hal is the same, rest of source files has changed. I am testing this right now, will let you know.

@simon-madwifi@uc.org

Would you mind posting what you did in more detail? I tried running all the patches[[BR]]
 from the openwrt madwifi patches from trunk as you describe with madwifi-r3314, and[[BR]]
 sticking in the new hal, however the code still differs a bit from your .tgz[[BR]]
 

An update on my last message. I still get stuck beacon on trunk r3314 with openwrt patch. Anymore potential fix?

Replying to anonymous:

I have stuck beacon problem with all versions of driver, including 0.9.3.1. I've been running the trunk r3314 with openwrt patch posted by MastaG for a few days now, no stuck beacon so far. Running Intel XScale, kernel 2.6.24, hostapd v0.6.3.

Replying to anonymous:

An update on my last message. I still get stuck beacon on trunk r3314 with openwrt patch. Anymore potential fix? Replying to anonymous:

I have stuck beacon problem with all versions of driver, including 0.9.3.1. I've been running the trunk r3314 with openwrt patch posted by MastaG for a few days now, no stuck beacon so far. Running Intel XScale, kernel 2.6.24, hostapd v0.6.3.

I put up a new one, this one compiles against 2.6.27 http: //www.akelo.ath.cx/~mastag/madwifi-trunk-r3314-patched-2.6.27.tar.gz

Compile with: make WARNINGS= Install with: sudo make WARNINGS= install

This is r3314 with all openwrt patches and the hal module from ath_hal-20081002. I modified the net80211/ieee80211_wireless.c to make it compile against 2.6.27. Works like a charm.. very good transmit rate and no stuck beacons of course. Be sure to use it with the latest hostapd (I use the git version).

Replying to anonymous:

Replying to anonymous:

An update on my last message. I still get stuck beacon on trunk r3314 with openwrt patch. Anymore potential fix? Replying to anonymous:

I have stuck beacon problem with all versions of driver, including 0.9.3.1. I've been running the trunk r3314 with openwrt patch posted by MastaG for a few days now, no stuck beacon so far. Running Intel XScale, kernel 2.6.24, hostapd v0.6.3.

I put up a new one, this one compiles against 2.6.27 http: //www.akelo.ath.cx/~mastag/madwifi-trunk-r3314-patched-2.6.27.tar.gz Compile with: make WARNINGS= Install with: sudo make WARNINGS= install This is r3314 with all openwrt patches and the hal module from ath_hal-20081002. I modified the net80211/ieee80211_wireless.c to make it compile against 2.6.27. Works like a charm.. very good transmit rate and no stuck beacons of course. Be sure to use it with the latest hostapd (I use the git version).

r3314 with openwrt patches and ath_hal-20081002 still has stuck beacon. I get 3 stuck beacons in 5 days, all happened yesterday. This version is still no good.

Confirming no stuck beacons with patched r3314. With original latest svn I get stucks every few minutes :(

r3314 with openwrt patches and ath_hal-20081002 still has stuck beacon. I get 3
stuck beacons in 5 days, all happened yesterday. This version is still no good. 

this is also the experience i have made over last few days, i have been using my own version of madwifi_r3314+openwrt_r13185_patches+hal20081002. plus for sth new I see this message from time to time: Virtual device ath0 asks to queue packet

what actually matters is that, as far as I can see there are no disconnects happening! so the only problem with this driver seem to be occassional annoying entries in syslog.

one curiosity i have noticed: most stuck beacon i have seen so far (3) were generated when no client was associated with AP. 1 more happened straight after rebooting AP, when again - possibly no client was associated.

apart from that driver runs amazingly stable, nothing breaks up, completely different quality to current so called "stable" madwifi drivers

The patched version is no more online. Trunk madwifi still has stuck beacons most of the time. Is there a solution available (except waiting for ath5k AP mode)...

I uploaded a version that compiles against 2.6.29.1 but it has to be loaded manually.

It says "unable to load needed module: <module name>; no support for automatic module loading. So all modules that are needed by ath_pci have to be loaded manually before loading ath_pci I don't know how to fix that. maybe someone does.

You can find the patch at http ://www.crossbone.org/madwifi-r3314-2629.patch

Maybe someone knows what has to be done for automatic module loading.

Replying to willem@crossbone.org:

It says "unable to load needed module: <module name>; no support for automatic module loading. Maybe someone knows what has to be done for automatic module loading.

CONFIG_KMOD has been removed in newer kernels.

Here's how to fix it: in file net80211/ieee80211_linux.c replace: #ifdef CONFIG_KMOD with:

#if defined(CONFIG_KMOD) (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,27))

Replying to anonymous:

Replying to willem@crossbone.org:

It says "unable to load needed module: <module name>; no support for automatic module loading. Maybe someone knows what has to be done for automatic module loading.

CONFIG_KMOD has been removed in newer kernels. Here's how to fix it: in file net80211/ieee80211_linux.c replace: #ifdef CONFIG_KMOD with:

#if defined(CONFIG_KMOD) (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,27))

sorry, I meant:

replace:
#ifdef CONFIG_KMOD
with:
#if defined(CONFIG_KMOD) || (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,27))

Willem, the patch is no longer available on www.crossbone.org/madwifi-r3314-2629.patch - could you attach it to this ticket so that it isn't lost again?