Problem with latest RC3 release and atheros

[misteragony]

Hello,

after upgrading to the latest pfsense RC, I noticed that my wireless interface on the pfsense every now and then 'disappears'. About two to three times a day. My wireless clients can't detect my access point anymore, so they can't associate. LAN access is ok. When I login to Pfsense, I see that the interface status is still associated, but at the same time no W-clients can connect. To solve the problem I need to disable the wireless interface and re-enable it, or reboot the box of course. It makes the latest RC not very usable.

Is this related to the atheros driver regression in this RC?

Best regards,
Jan

[wallabybob]

Sounds like what I described in a reply in http://forum.pfsense.org/index.php/topic,20067.0.html

[matrix200]

Cant confirm here that I have a similar problem but I do suggest you check dmesg for stuck beacon messages.
Do you have any?

[misteragony]

dmesg | grep ath

ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
ath0: <atheros 5212="">mem 0xeb000000-0xeb00ffff irq 5 at device 18.0 on pci0
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:19:5b:89:e7:d2
ath0: mac 10.5 phy 6.1 radio 6.3
ath0: device timeout
ath0: device timeout

In system.log I see these:

Nov  1 14:33:51 Exit11 hostapd: ath0: STA 00:24:2c:32:e5:53 WPA: group key handshake completed (WPA)
Nov  1 14:36:54 Exit11 hostapd: ath0: STA 00:24:2c:32:e5:53 IEEE 802.11: deauthenticated due to local deauth request
Nov  1 14:36:54 Exit11 hostapd: ath0: STA 00:24:2c:32:e5:53 IEEE 802.11: deassociated
Nov  1 14:36:58 Exit11 kernel: ath0: device timeout
Nov  1 14:37:04 Exit11 hostapd: ath0: STA 00:24:2c:32:e5:53 IEEE 802.11: associated
Nov  1 14:37:04 Exit11 hostapd: ath0: STA 00:24:2c:32:e5:53 WPA: pairwise key handshake completed (WPA)
Nov  1 14:37:04 Exit11 hostapd: ath0: STA 00:24:2c:32:e5:53 WPA: group key handshake completed (WPA)
Nov  1 14:37:51 Exit11 hostapd: ath0: STA 00:24:2c:32:e5:53 WPA: group key handshake completed (WPA)</atheros>

[aphk99]

Hi!

Just join pfSense few days….  ;D

I'm facing the same issue

If use after 1.2.3-20091005, it will not recognize my Atheros wireless card "AR5007eg"

===pfSense-1.2.3-20091104-0746===
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
ath0: <atheros 2424="" 5424="">mem 0xfe8f0000-0xfe8fffff irq 17 at device 0.0 on pci2
ath0: [ITHREAD]
ath0: unable to attach hardware; HAL status 13
device_attach: ath0 attach returned 6

But before the date 20091004, pfSense-1.2.3 can recognize it and AP functional

===pfSense-1.2.3-20090930-2121===
ath0: <atheros 2424="" 5424="">mem 0xfe8f0000-0xfe8fffff irq 17 at device 0.0 on pci2
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:15:af:xx:xx:xx
ath0: mac 14.2 phy 7.0 radio 10.2</atheros></atheros>

[cmb]

This is one of those battles we can't win. The stock ath driver in FreeBSD 7.2 has issues. The driver we were using with 7.1 with a patch was working well with 7.1, so we reverted back to that for RC3. Well, it fixed the problems the stock ath driver in 7.2 had that I could replicate, but it created new ones for other cards or other situations.

For me, the AP would crap out every 1-2 days with the stock 7.2 driver, but never did with what's in RC3. Well, the exact opposite is happening for a lot of others.

So, for 1.2.3, we're throwing our hands up and going with what's in stock FreeBSD 7.2, even though it has known issues. Nothing we can do, we don't write the drivers, and no FreeBSD developers have any interest in touching ath in 7.x. We have to work with what's out there.

Snapshots as of the past 3 days or so are back to what was in use pre-RC3.

[misteragony]

Hello,

I completely get your point. It's hard to do good for all ;)

Would some kind of versioning system for (wireless) drivers be feasible? See my post under the wireless section of the forums as well.

Or would it be possible to make driver versions selectable from the web interface? In this case users could see which drivers work best for them and select the ones they want and at the same time Pfsense would support the widest variety of HW?

Best regards,
Jan

[matrix200]

Here is something I did with my system and maybe it could help others?
I added a cron job that looks like that :
" /sbin/ifconfig ath0 bintval 500 "
The script runs every half an hour and if I understand correctly  it resets the card.
It did help for me and the card seems to be much more stable now (I still use 1.2.3 RC3 the release).

[Darkk]

I've had a couple of atheros cards before and sometimes would give me problems.  So finally I picked up a cheap Rosewill wireless PCI card with Ralink wireless chipset and the problems went away (Rosewill RNX-G300EX).  Been stable ever since.

It's one of the advantages of having a PCI slot for me to switch hardware around.  Same thing with real-tek NIC devices which may work fine for some and problems for others.  So I stayed with either Intel or D-Link NICs which works flawless on my setup.

Hope this helps.

[danswartz]

thanks, matrix, i will give your ifconfig trick a try.  i just got borked with this :(  i'd love to know if 2.0 was stable enough for me to switch (assuming of course this issue doesn't exist there too…)  i have also thought of replacing the kernel with one from an older snapshot, but that seems risky...

[danswartz]

well, that didn't help.  i am doing the bintval 500 every 1/2 hour, and i just got home to find out the wireless has been down for 2+ hours.  i think i need to try an older kernel.  my gripe here: i understand the devs here are stuck between a rock and a hard place, but as a professional software developer (and maintainer), it is a much worse sin to break something that was working than to not support a newer chipset.  if it were possible to have both kernels, that would be nice :)

[matrix200]

To be frank I also had a downtime a few days ago.
I was getting device timeout messages for a while and AP was gone.
After rebooting my wireless clients and playing a bit with the AP settings it was back on (there isn't something specific that fixed it though).
Like I said I run the official 1.2.3RC3.
On the plus side stuck beacons are much more rare now but this device timeout is causing the same issue so I am happy the devs returned to 7.2 driver as it was better in that respect :)
To sum it up I guess we should just wait for 2.0 with 8.0 and hope drivers are better there.