Kernel: ath0: stuck beacon; resetting (bmiss count 4)
-
is there any solution for the below error which has been a pain now from the past few weeks nanobsd snaps
kernel: ath0: stuck beacon; resetting (bmiss count 4)
older snaps, almost a month old or so used to work perfectly fine on the alix using a atheros wifi card but the recent bug fixes and updates give me a lot of these entries in my system log and my wireless connection has become very unstable.
-
is it just me with this?
-
If you go back to an older snap, does the problem go away? If not, it could just be coincidence. The ath issues are one reason I gave up over a year ago using pfsense for wireless access…
-
around a month and a half backs snap doesnt give the error.
any recommendation on a different brand of wifi card which works flawless?
-
Not really.
-
is it just me with this?
Nope, same problem here with a snapshot-iso (regular install) from a few days a go. Which is gonna be nanobsd eventually, right now I'm just trying to get the card to work.
Using a DWA-552.
edit: I'm not sure how, but I just got rid of the error ??? :)
-
around a month and a half backs snap doesnt give the error.
Then it's voodoo since nothing in the ath driver has changed since we went to FreeBSD 8.1 somewhere around a year ago. :) Nothing in the config really has changed either as there's only one way to set things up, and that's not a config-related condition.
There's a lot of info on this issue in general on FreeBSD lists if you search on it.
My ath cards all work fine, only APs I use, so not sure what to suggest.
-
is it just me with this?
Same thing here with current i386 snapshots…. (this didn't happen the last time i tested v2 about a month ago...)
"kernel: ath0: stuck beacon; resetting (bmiss count 4)"
-
It may be possible this is related to one of our mbuf patches that was reverted and deferred to a future version, I really doubt it as it would likely be universal and cause panics but it's possible, try today's snapshot or newer.
-
Hi!
I have had this for a while also.Try setting hw.ath.bstuck to 8 in system/advanced/system tunables (add new row).
I also added hw.ath.longcal and value 30.
For me WiFi now works better.
/UrbanSk
-
i was surprised to see replies to this thread coz i just stopped getting mails regarding new posts from the forum for some reason.
-
i was surprised to see replies to this thread coz i just stopped getting mails regarding new posts from the forum for some reason.
Looks like the mail queue is backlogged. I'm getting the notifications, they're just extremely slow.
-
For me changing wifi channel worked a few times already (as I get this error from time to time).
-
i was surprised to see replies to this thread coz i just stopped getting mails regarding new posts from the forum for some reason.
Hmm, weird :P
Here it seemed like I just had to choose the right settings, although I haven't got a clue which setting it might have been that solved it…
(About the issue you created this topic for, not the email problem ;) ) -
i was planning to post a bounty to start with $100 and mayb more ppl can contribute to it to make wireless hotspot more robust and alos get rid of these stuck beacon if any1 was willing to complete it.
-
Which wifi card are you using btw?
-
Compex WLM54G atheros 5414 chipset but it reports as this:
dev.ath.0.%desc: Atheros 5413 -
Hmm…
Well, maybe this bug is fixed in a newer version of the ath(4) driver.
I've been told someone is working on it and also adding N support.Only I don't know where to get the most recent version of this driver and how to update the one that currently comes with pfSense.
-
same problem here:
kernel: ath0: stuck beacon; resetting (bmiss count 4)
hardware is:
kernel: ath0: <atheros 5212="">mem 0xfd8f0000-0xfd8fffff irq 17 at device 1.0 on pci5
kernel: ath0: [ITHREAD]
kernel: ath0: AR2413 mac 7.9 RF2413 phy 4.5Version 2.0-BETA5 (i386)
built on Thu Feb 24 17:17:04 EST 2011</atheros> -
probably only the devs would know i guess on how and where to get the updated drivers, i would be very much interested in it.
-
I asked on the FreeBSD forum, got this:
svn co http://svn.freebsd.org/base/head/sys/dev/ath
But does pfSense have svn? Haven't looked at that yet…
- might not work if there where changes in the kernel that are needed by the updated driver.
-
Installed svn using```
pkg_add -r subversionThen I used scp to copy over these from my FreeBSD virtual pc because svn needed them. /usr/lib/libgssapi.so.10 /usr/lib/libheimntlm.so.10 /usr/lib/libkrb5.so.10 /usr/lib/libhx509.so.10 /usr/lib/libasn1.so.10 /usr/lib/libroken.so.10 The svn command downloaded all files from that link. Now have to figure out what to do next.
-
You can't compile on the firewall - having that code on the firewall doesn't do you any good. You would need to download that to a local FreeBSD installation or VM and compile there, and move the resulting files over. (But even then it may not do what you expect…)
-
Ow okay.
Downloaded sourcefiles in virtual pc with FreeBSD 8.2, now trying to compile it, but no luck so far.
Whole bunch of errors when running make on each of the *.c files. -
I did an upgrade to RC1 this morning, broke my wifi. So did a clean install, started from scratch, running into the error the reason this topic was made for. Then after changing the channel couple of times + reboot I managed to get rid of it.
But now a whole different problem, that I thought a clean install would solve, guess not:
Mar 1 15:06:35 hostapd: ath0_wlan0: STA 00:27:10:ce:03:6c IEEE 802.11: deassociated Mar 1 15:06:35 hostapd: ath0_wlan0: STA 00:27:10:ce:03:6c IEEE 802.11: deauthenticated due to local deauth request Mar 1 15:06:32 hostapd: ath0_wlan0: STA 00:27:10:ce:03:6c IEEE 802.11: associated Mar 1 15:06:32 hostapd: ath0_wlan0: STA 00:27:10:ce:03:6c IEEE 802.11: deassociated Mar 1 15:06:32 hostapd: ath0_wlan0: STA 00:27:10:ce:03:6c IEEE 802.11: deauthenticated due to local deauth request Mar 1 15:06:31 hostapd: ath0_wlan0: STA 00:27:10:ce:03:6c WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter Mar 1 15:06:31 hostapd: ath0_wlan0: STA 00:27:10:ce:03:6c IEEE 802.11: associated
I think something changed between beta 5 feb.4 snapshot and RC1, since this problem showed up after the upgrade, but what?
Also the upgrade did not fix the "stuck beacon"-bug, so that is still in there as well. Although it is no longer a pain in the a** at the moment. -
I think something changed between beta 5 feb.4 snapshot and RC1, since this problem showed up after the upgrade, but what?
nothing wireless related has changed in months. These driver issues come and go for some people for unknown reasons. We don't write, maintain or have any control of wireless drivers which is where these issues are, these things need to be reported upstream.
-
Hmm…
Well, I managed to compile a newer version of the driver using the source, but now I need to figure out how to get pfSense to (try to) use that one instead of the one already in the kernel. Google explained how to disable and load drivers, but not how to "override" one already in the kernel without having to rebuild that.
-
According to someone on the FreeBSD forum the only way to use the new driver is to completely rebuild/recompile the kernel.
Already found this: http://devwiki.pfsense.org/DevelopersBootStrapAndDevIso , but what if I only want the kernel? Any howto's on that?
Someone already asked that but did not get response: http://forum.pfsense.org/index.php/topic,26188.msg163743.html#msg163743 -
I modified the make.conf to exclude the driver and created a custom pfSense….. The driver is still in there. >:(
-
http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/061772.html
Mostly the stuck beacon appears to be interference. Try a different channel. Driver isn't going to help that.
-
Already tried that, all 13 channels are busy…
That's why I would like to try an updated driver, hopefully it is a bit more stable than the one FreeBSD 8.1/pfSense 2 has got.Or at least the option to try it and help testing it for Adrian (who is working on it), don't have that option now because there does not seem to be a way to remove the driver already in the kernel.
-
Not much in that message implies that the stuck beacon message will really improve with a different driver. He talks about some features that haven't been ported yet, and that some chips may not improve at all (or may get worse) with a new driver.
That said, if you load a driver's .ko file from /boot/loader.conf.local it can override the in-kernel version of the driver.
But if you want to try the debug kernel options mentioned in that message, you'll have to run off a whole custom kernel (may as well make a custom iso/update) and the builder works fine for me. I just setup another builder today and had no trouble getting through the ports and such.
-
Other people have reported in these forums that they have successfully used a driver in a loadable module to override the driver in the kernel. I haven't tried it myself so can't verify this from personal experience.
If you care to follow this path you will need to load the module form of the driver at boot time by adding a line like if_ath_load="YES" to /boot/loader.conf.local
I would also suggest you add a printf() call to the attach function in your driver (for example, printf("bartgrefte's ath attach function\n");) so you can be sure the system is using your driver and not the driver in the kernel.
-
Hmm, okay.
Read about that, did not new that method could override a driver integrated in the kernelWell, if the MODULES_OVERRIDE option jimp mentioned in a different topic does not work, I'll try that :)
-
Other people have reported in these forums that they have successfully used a driver in a loadable module to override the driver in the kernel. I haven't tried it myself so can't verify this from personal experience.
**If you care to follow this path you will need to load the module form of the driver at boot time by adding a line like if_ath_load="YES" to /boot/loader.conf.localI would also suggest you add a printf() call to the attach function in your driver (for example, printf("bartgrefte's ath attach function\n");) so you can be sure the system is using your driver and not the driver in the kernel.**
Tried that, can't tell if it worked. Not seeing that sentence pop up anywhere in dmesg.
Note: loader.conf.local did not exist, so I created one with Vi.offtopic: Why does pfSense not have Nano instead of Vi? Nano is easier to use.
-
vi is better. ;D
ee is there if you need an easy editor.
-
Matter of personal opinion I guess :P
I kinda prefer Nano, because with that you don't have to look up the commands, they are on the screen ;D -
ee is the same way, it wastes a lot of screen area on listing commands and menus and such. Me, I'd rather be editing than looking at that. :-)
-
I just want to share my experience with this problem. I was running PfSense 1.2.3 with a ath card and no problems. When i upgraded to "2.0-RC1 (i386) built on Sat Feb 26 15:30:26 EST 2011" wireless stopped working (with the same error).
The only setting i changed to get this working was channel (wireless channel).
-
Changing the channel has worked for some people, but all channels are busy here and I have tried all of them without luck.
Right know I'm considering switching to a Linux based alternative for pfSense, hoping that the Linux equivalent of the Atheros driver does not contain this bug and because that one does (as far as I know) offer support for the N standard.