VOTE if you like to see better Wifi driver support in pfSense !!!
-
As pfSense is becoming more and more a home or SOHO firewall/router, it's probably best to have great wireless card driver support built into it. I am wondering if it's only me who thinks that way or if there are more people who agree that no proper wireless support is the weakest link of pfSense now. Given pfSense is often run as a router as well as a firewall device, why not as a wireless router?
Currently a very small list of devices are "partially" supported.
Please show your support if you believe there should be better wireless driver support in pfSense. You can chose up-to 4 options.
-
On the contrary, I think pfsense's strengths are NOT as a SOHO firewall/router with Wifi, afterall at this point in time Linux-based firmware (e.g. Tomato / DD-WRT / OpenWRT etc) are really hard to beat in terms of overall functionality in the SOHO environment.
pfsense depends on FreeBSD for its hardware support, which is only recently trying to play catch up with Linux wifi hardware support, primarily thanks to the heroic efforts of Adrian Chadd.
So, while improved wifi support would be a welcome addition, in many environments utilizing pfsense one can simply do Wifi by using an external AP.
-
Added "doesn't matter to me" option to make it a fair poll.
2.1 will have exactly what it has right now, it's getting released in the near future. We'll have greatly improved wifi support when all Adrian Chadd's recent changes make a stable release, which I suspect will be FreeBSD 9.1, which I suspect will be the base of our 2.2 release. Depends on release timing on their side and ours.
Ultimately the results of this poll have no impact on what we do. Out of necessity for survival, we do what people are willing to pay for, and what those who are willing to pay want to see. The home user market gets us very little, a couple hundred bucks a year at most in donations, which doesn't even cover replacement parts we put in our hosting servers alone on an annual basis.
We couldn't hope to dedicate the kind of resources necessary to improve and maintain wifi support. I'm very happy Atheros has been able to make that happen by hiring Adrian full time. We explored contracting with him to achieve the same end result and it was an order of magnitude beyond what we could possibly afford or hope to raise by donations.
Adrian has even gotten up to the most FreeBSD commits of anyone over the past 12 months in improving Atheros and wifi in general.
http://adrianchadd.blogspot.com/2012/04/and-winner-of-most-committing-committer.htmlSo it's coming!
-
What is the scope of Adrian's work? WiFi infrastructure + drivers for Atheros devices? WiFi infrastructure + drivers for Atheros devices + other drivers "as time permits"?
-
The man seems to be doing a lot: http://wiki.freebsd.org/AdrianChadd
For me there is a missing option: I'd buy an 802.11N card if it was supported but it's not that important.
I have an 802.11N access point on my home network and because it's not inside my pfSense box I have it located where I get best signal distribution. I also have an Atheros 'G' card in my pfSense box, it works fine (apart from occasional stuck beacons).
A separate 'N' AP has many advantages and they are now cheap. About the only reason I can think of not to use one it power consumption.This is an interesting question. I think it speaks for the incredibly scalable nature of pfSense. Really it's only at the very low power end of the scale that this is an issue. I can certainly see the appeal of a one box solution.
I'm sure I remember reading a post from Adrian that building the drivers for 8.3 would be relatively easy. I can't find that now so perhaps that's no longer the case.
Steve
-
What is the scope of Adrian's work? WiFi infrastructure + drivers for Atheros devices? WiFi infrastructure + drivers for Atheros devices + other drivers "as time permits"?
- net80211
- pci/pcie ath(4) NICs
- 802.11n support
- power save handling in hostap (and STA, eventually)
- TPC/regulatory/radar requirements
I don't have the time (but I do have the hardware! Lots of it!) to hack on the USB NICs. If someone ports over the ar9170 and athn/usb code from openbsd to FreeBSD, I'll help hack on it.
Qualcomm Atheros hired me as a developer on their internal stuff. I hack on FreeBSD because I want to and I do it in my spare time. I just happen to have access to a lot more shiny toys now.
As for funding me - yes, I can't contract out any longer but what I suggest is that you contact the foundation and ask them how you can proceed. There are plenty of vendors out there wanting FreeBSD/802.11n work and although it's "better" now, I'd love all the help I can get. So if you're a developer and you'd like to get involved, the foundation is able to sponsor joint venture projects funded by themselves and interested companies. I'd do it, I'm just not allowed to. :-)
Adrian
-
Thanks very much for the input Adrian.
So if you're a developer and you'd like to get involved, the foundation is able to sponsor joint venture projects funded by themselves and interested companies.
Do we have anyone interested in this? Does this make a great bounty job?
Sooner or later, wireless have to be implemented so I still don't believe in the notion of pfSense being a firewall only and "it doesn't matter to me". It might happen this year or if not next year. So, why delay it?
-
Thanks very much for the input Adrian.
So if you're a developer and you'd like to get involved, the foundation is able to sponsor joint venture projects funded by themselves and interested companies.
Do we have anyone interested in this? Does this make a great bounty job?
Sooner or later, wireless have to be implemented so I still don't believe in the notion of pfSense being a firewall only and "it doesn't matter to me". It might happen this year or if not next year. So, why delay it?
If people would like little wifi projects to hack on - I have a loooong list of little projects to get done. (And bigger ones, but they can wait..)
Adrian
-
Hi,
FWIW, I've just committed a fix that lets one run the -HEAD ath(4) driver on an 8.x tree.
It should support all the ath(4) NICs in non-802.11n modes.
Maybe that'll help the pfsense team in releasing some more up to date wifi support, at least before they migrate to 9.x :-)
-
Excellent! :)
Even if it doesn't make it into 8.3 release (and hence pfSense 2.1) I would expect this to make it far easier to add it as a kernel module?
It's so refreshing to have this information straight from the source, thanks!
Steve
-
Just to add some extra data for what is already supported, here's the link to the sheet I try to keep updated:
https://docs.google.com/spreadsheet/ccc?key=0AojFUXcbH0ROdHgwYkFHbkRUdV9hVWljVWl5SXkxbFE&hl=en#gid=0
Though I do need to go through on 8.3 and see if any of those fields need altered. Makes me wonder if the man pages have kept up or if I'll have to go source diving again. :-)
-
https://docs.google.com/spreadsheet/ccc?key=0AojFUXcbH0ROdHgwYkFHbkRUdV9hVWljVWl5SXkxbFE&hl=en#gid=0
So, based on the list above ^^^, Marvell 88W8363 is the best tested and has the most features? So, is this a mini PCI(x) card?
Adding card type to list would be great.
-
Not sure if it's the best tested, that would have to be Atheros because it's the most widely used.
Can't list the card type because the card type doesn't matter, the drivers are based off the chip, not the form factor. Though most PCI are really Mini-PCI on Adapter boards.
-
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.
