The ongoing atheros pain

[danswartz]

No difference here :(

ath0: <atheros 5212="">mem 0xfeae0000-0xfeaeffff irq 21 at device 10.0 on pci2
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:25:86:d3:85:ce
ath0: mac 7.9 phy 4.5 radio 5.6</atheros>

[jimp]

You might compare the output of "sysctl dev.ath" on both your systems, there may be differences there.

Also if you're brave, test out a snapshot of pfSense 2.0-BETA1, the driver support for wireless cards is supposed to be a bit better.

[danswartz]

Here's mine:

sysctl dev.ath

dev.ath.0.%desc: Atheros 5212
dev.ath.0.%driver: ath
dev.ath.0.%location: slot=10 function=0
dev.ath.0.%pnpinfo: vendor=0x168c device=0x0013 subvendor=0x168c subdevice=0x2051 class=0x020000
dev.ath.0.%parent: pci2
dev.ath.0.smoothing_rate: 95
dev.ath.0.sample_rate: 10
dev.ath.0.countrycode: 156
dev.ath.0.regdomain: 32924
dev.ath.0.slottime: 9
dev.ath.0.acktimeout: 48
dev.ath.0.ctstimeout: 48
dev.ath.0.softled: 0
dev.ath.0.ledpin: 0
dev.ath.0.ledon: 0
dev.ath.0.ledidle: 2700
dev.ath.0.txantenna: 0
dev.ath.0.rxantenna: 1
dev.ath.0.diversity: 1
dev.ath.0.txintrperiod: 5
dev.ath.0.diag: 0
dev.ath.0.tpscale: 0
dev.ath.0.tpc: 0
dev.ath.0.tpack: 63
dev.ath.0.tpcts: 63
dev.ath.0.fftxqmin: 2
dev.ath.0.fftxqmax: 50
dev.ath.0.monpass: 24

as far as 2.0 goes, I'm happy it's now in Beta - unfortunately, while I am adventurous, my pfsense gateway is a production box (well, as much as a home office network can be production - LOL.)  I might try upgrading in a few weeks.  In theory, I should be able to go from 1.2.3 Release to 2.0?

[jimp]

You should be able to upgrade from 1.2.3, yes. If you keep a backup and install media handy, a test shouldn't hurt much. If it breaks you can be back up on 1.2.3 in under 10 minutes in most cases (Thanks to PFI).

[danswartz]

True, I forgot about PFI.  I may give this a couple of weeks and see how things are.

[wallabybob]

My output from # sysctl dev.ath is the same as posted by danswartz.

[danswartz]

I have a new theory: this has nothing directly to do with wireless, but is somehow related to bridging.  Keep in mind in my configuration, I have not just wireless hosts on the other end, but other bridges (specifically the two APs that are in dd-wrt client-bridge mode.)  I am wondering if freebsd bridge code is getting upset at something and refusing to pass traffic any longer?  One of the wireless clients is an endpoint (the tivo) and that is going off the air too, but if the pfsense box's bridge is getting wedged, that might be enough to take all 3 down?  Unfortunately, my networking knowledge of bridging is not that great, so I am not sure how&where to proceed.  A data point: using ifconfig down&up on ath0 does not fix this.  Nor does doing so on bridge0.  However, hitting "save" on the ath0 config page DID bring back 2 of the 3 wireless clients.  I had to reboot to get the 3rd one back.  I wonder if this is some artifact of STP or something?

[danswartz]

First hang in over 2 weeks.  As usual, the neighbor's AP went offline.  Interestingly, wireless status shows it still associated.  Power cycling their end did not help.  I tried a hunch and went to the bridged WLAN interface in pfsense and hit "SAVE", without changing anything.  Bingo, their AP came back online.  From my limited reading of the code, the php code in question deletes any existing bridge using that interface and creates a new one.  I know for sure taking the wifi interface down and up does not help, so I am more sure than ever that it is some odd bridging quirk.  Now that I know a less intrusive fix than rebooting the gateway, I don't care as much, since I am moving in 6 months or so, at which time I will have a spare AP to use.

[danswartz]

This is interesting.  I have had the remote AP go offline 3 times now in 2 days (twice today.)  Resetting the ath0 interface (by hitting save on the wlan page) "fixes" it.  I was looking at athstats and saw this:

3065     switched default/rx antenna

Wow, that is a lot of switching, no?  googling for similar issues has showed articles with a handful of switches.  What I am wondering is: if it is switching to  a different connector than the one with the good antenna (for whatever reason), that might drop the signal strength, no?  It occurs to me that the other few clients are all in the same house, the problematic AP is next door at the neighbor's house, so would be more susceptible to rx/tx strength issues?  I tried setting dev.ath.0.diversity to zero with sysctl, but I noticed this:

dev.ath.0.txantenna: 0
dev.ath.0.rxantenna: 1

the rx antenna seems to change occasionally even after I disabled the diversity.  Does anyone have any ideas on this?

(update) more research indicates antenna number 0 means "both", so the right choice would be 1 or 2, it seems.  I've tried setting both to 1 and we'll see.  It would be nice to know what is going on here.  I am pretty close to pulling the card and going back to a separate access point :(

[danswartz]

The (unresolved) (hopefully) final chapter: this is NOT an atheros issue.  The ralink card I got to replace it fared no better.  Within 10 minutes of booting the gateway, the remote AP/bridge went off the air - "fixed" the same way.  I finally gave up and got a $50 netgear router and am now bridge-free.  I just wish I knew what the issue was (for closure).

[jaime]

what card(s) were you attempting to bridge originally when the issue was persisting? are you bridging the net gear with anything? or is it AP mode? or is it attached to your network on a switch as an AP?

[danswartz]

It was a tp-link atheros card and bridged with the ethernet lan card.  The current netgear is just acting as an AP and all is well.