VOTE if you like to see better Wifi driver support in pfSense !!!
-
Not sure if it's the best tested, that would have to be Atheros because it's the most widely used.
Thanks Jimp. So, which Atheros chip supports multiple AP and Infrastructure mode at the same time? I thought it was only Marvell chips that were tested for that (maybe the list is not updated?)
For ath, on the excel sheet, I see "Lot and lots…." but there is no even one supported card listed. I already have the experience of ath driver not working "AR9220" has bugs. So, which ath chips are tested to be working if there are lots and lots?
Best,
-
So, which Atheros chip supports multiple AP and Infrastructure mode at the same time?
See the man page for the ath driver (at http://www.freebsd.org/cgi/man.cgi?query=ath&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html). It says (in part):
Multiple station interfaces may be operated together with hostap interfaces to construct a wireless repeater device.
-
There's a larger list of cards on the ath_hal(4) page.
Even more on the 9.0-rel version of that page.I am slightly confused over the relationship between the two drivers (parts). :-\
Steve
-
Just do a search here on the forum, plenty of chips mentioned. Personally I've got a 5413 and a 5212 and some others and they all work fine.
The dmesg info looks like:
ath0: <atheros 5413=""> mem 0xe00c0000-0xe00cffff irq 9 at device 12.0 on pci0 ath0: [ITHREAD] ath0: AR5413 mac 10.5 RF5413 phy 6.1</atheros>
So if you search for similar terms I imagine you'll turn up a lot of info.
The man pages are nice, but seeing posts from people actually using the cards is more reassuring.
-
So, far there is ~43% approval in support of some sort of wireless for pfSense. I think that is high enough for development team to decide that it's time to focus some resources towards it. Bad wireless support means loosing market share eventually.
-
That really doesn't mean much. Re-read cmb's post:
http://forum.pfsense.org/index.php/topic,48132.msg253792.html#msg253792
We are at the mercy of FreeBSD here - we can try to pull in patches but at the end of the day they are not our drivers. All we can do is patch and hope it helps. We do not have the resources to put development into wireless drivers. The work that is happening on FreeBSD's side is great, and in the future we will benefit from the hard work going on there, but in the mean time all we can do is wait for that to get to a point where we can pull it in.
Wireless works well for many of us, it just doesn't do 802.11n.
-
I think that is high enough for development team to decide that it's time to focus some resources towards it.
Do you think that wireless drivers should come above IPv6? Bug fixing? All the other great stuff the already stretched development team do? ;)
It would be great to have everything but it's all about priorities.Besides:
@erikarn:FWIW, I've just committed a fix that lets one run the -HEAD ath(4) driver on an 8.x tree.
means that anyone can compile the ath(4) driver from -HEAD on a FreeBSD 8.3 machine and load the resulting kernel module on pfSense 2.1. (I think!)
As soon as 8.3 gets official I'm sure someone will do that.Steve
-
Besides:
@erikarn:FWIW, I've just committed a fix that lets one run the -HEAD ath(4) driver on an 8.x tree.
means that anyone can compile the ath(4) driver from -HEAD on a FreeBSD 8.3 machine and load the resulting kernel module on pfSense 2.1. (I think!)
As soon as 8.3 gets official I'm sure someone will do that.Steve
That would be fantastic. I have an AR5416 based card (RNX-N360PC) that occasionally goes offline. It tries to reset the hardware due to a "stuck beacon" and fails leaving the card unusable until the system is restarted. Based on the research I've done it appears to be a bug with noise floor calculation that may be fixed in -HEAD.
I specifically bought an ath card to have better support on Linux and BSD but this bug still nailed me :(
-
I get stuck beacons but it never actually causes a problem.
You can try setting hw.ath.bstuck to a higher value, I use 8.Steve
-
My pfsense box here at the office is sitting between other equipment on a rack in a server room; not a good place for a wireless access point. We use 3 APs in different parts of the office to get coverage.
As for my house if I need to move something big I would rather plug in to my gigabit switch then do it over wireless anyway. G is fine for internet stuff as it is still faster then my DSL.
-
I get stuck beacons but it never actually causes a problem.
You can try setting hw.ath.bstuck to a higher value, I use 8.Steve
I have it set to 8. I usually have several successful resets after stuck beacons before it gets the card into an inconsistent state. I went through numerous iterations of settings and tweaks but I still end up having to restart 2-3x a week.
My AP is in an environment with very little other activity (no other Wifi, bluetooth, microwave, etc.) which, as I understand it, lends itself to the overshooting problem that causes the stuck beacon resets. You have less likelihood of going from a very low noise floor to a high one and interpolating to an out of range value if you're in an environment with one or more other radios within range. When my neighbor turns on their wifi printer (acts as an AP in ad-hoc mode) it normally causes my wifi to go down. Sometimes Wii controllers (bluetooth) will cause it to go down too.
I've never successfully logged it happening. As soon as it happens hostapd goes into an infinite loop trying to reset the HW and floods the log. By the time I'm able to either kill hostapd or restart it has filled and rolled over my system log. I have noticed (as I mention above) that it can/will successfully reset sometimes though.
If I understood BSD better (I'm of a Linux background) then I might try to fix the code that causes this.