Wireless card compatibility with pfsense
-
The general consensus around here seems to be that an ethernet connected access point is a better choice than an internal card. It's certainly easier, is fully portable, it doesn't depend on any drivers.
Heh, came to the same conclusion and posted before I read your response. Thanks for the help!
-
The general consensus around here seems to be that an ethernet connected access point is a better choice than an internal card. It's certainly easier, is fully portable, it doesn't depend on any drivers.
I agree, but troubleshooting facilities in some external APs may well be very limited compared to what is in pfSense.
Nevermind that doesn't support WPA2, this seems harder than it should be. Am I missing something?
Strange! the page you linked to says WEP, WPA, WPA2
-
This is just as a home router, so I'm not too concerned about troubleshooting facilities.
-
Here is a list of PCI and CardBus hardware which FreeBSD 8.1 RELEASE and Ports state they support by the ath_hal module.
http://www.freebsd.org/cgi/man.cgi?query=ath_hal&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE+and+Ports&arch=default&format=htmlHere is a list of PCI and CardBus hardware which FreeBSD 8.3 RELEASE and Ports state they support by the ath_hal module.
http://www.freebsd.org/cgi/man.cgi?query=ath_hal&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE+and+Ports&arch=default&format=htmlI think pfsense.org should add the first link above in the hardware section somewhere.
Why Atheros? It is the most common wireless chips found in wireless equipment.
I had one of these 10 Years ago Netgear WG511T LMAO ….. Wish I still had it. Keep in mind even though it is listed, it still doesn't mean you wont have some problems.
NO PCI-E cards listed …..
One thing I have learned you have to Accept, is dealing with the fact open source can be 3 to 4 years behind in certain aspects of the hardware. This is the case here!
Edit: Corrected Link
-
Atheros is simply the best supported wireless hardware in FreeBSD. Largely that is due to the efforts of one man: http://wiki.freebsd.org/AdrianChadd though I'm sure he'd be the first to tell you there were many contributions from others.
I agree that there will always be some delay getting hardware support in FOSS that is usually because manufacturers do not provide drivers or datasheets. Thus much has to be worked out from the ground up.
FreeBSD is usually somewhat behind Linux in this respect simply because there are less people hacking on stuff for it. Lastly pfSense is behind FreeBSD as applying the various patches and scripts to a FreeBSD release takes time and effort.Thus pfSense 2.0.1 is built on FreeBSD 8.1 which was released in July 2010 but hardware support was likely finalised sometime before that and even at that time it will have been behind whatever Linux was supporting. So, yes, 3 years is probably a good guess. ;)
Steve
P.S.
Your first link above is wrong. Fixed. -
There may not be pci-e cards, but there are mini-pci-e cards and you can find mini-pci-e to pci-e adapters around.
Also the drivers in 2.1-BETA are much newer and more likely to support recent cards, especially from Atheros.
-
The general consensus around here seems to be that an ethernet connected access point is a better choice than an internal card. It's certainly easier, is fully portable, it doesn't depend on any drivers.
I couldn't agree more. pfSense has a lot of tasty eggs in its basket, and the fact that the wireless functionality exists is what makes the product so awesome. But, in this case, I will go with an external wireless AP.
Some main challenges remain with finding an ideal external AP, though. For me:
(1) find one that doles out DHCP settings to its wireless clients, where it doesn't insist that the AP itself be the default gateway, or at least give you the option to point somewhere else, (such as your pfSense box), for your default gateway. The AP would obviously be bridged to LAN subnet of your pfSense box.
(2) find one that supports simultaneous dual band, and still does (1)
(3) find one that supports MSSID (I need lots of SSIDs (multiple guest-type access solutions per physical AP), with each SSID associated with a distinct VLAN & subnet), as well as does (1) as well as (2)
(4) find one supports the wireless AC standard (OK, this is truly a nice to have, but… I still want it). I will even risk the fact that AC is not yet ratified.
These features all exist on various AP platforms, but I have yet to find ONE that supports ALL of these in one unit. I have been looking at http://www.newegg.com/Product/Product.aspx?Item=N82E16833168130 , but have yet to confirm it can do (1).
… hope I didn't take us too far off on a tangent here...
NT SUX
-
1, 2/ You do NOT want DHCP running on your AP, so just scratch it.
-
1, 2/ You do NOT want DHCP running on your AP, so just scratch it.
So… how would I send DHCP data to the wireless clients connecting to the AP? Are are you referring to the actual IP of the AP - that would be static. To be clear, it's the DHCP daemon I am referring to - not the client - on the AP itself.
-
Uhm, you enable DHCP server on pfSense.
-
Uhm, you enable DHCP server on pfSense.
I have a feeling you're trying to be helpful, rather than condescending.
I also have a requirement for MSSID, with each instance mapped to a unique VLAN/subnet. Not sure pfSense can accommodate this with regard to DHCP.
So, to simplify things, perhaps this would call for a solution where the AP itself is also a router (rather than a bridge), with its WAN NIC on the pfSense LAN subnet. An extra hop is added, I guess, but it's internal, so it should be negligible. This would resolve the DHCP "issue".
Thanks for your input.
-
Rather depends on the AP wifi and firmware. I can imagine this would be doable with some Atheros-based box and DD-WRT.
-
I also have a requirement for MSSID, with each instance mapped to a unique VLAN/subnet. Not sure pfSense can accommodate this with regard to DHCP.
Why not? The usual arrangement here would be to have the access point mapping each virtual access point to a different VLAN with all the VLANs trunked to pfSense. pfSense is then configured with those VLANs such that each VAP appears to be a separate interface complete with DHCP server, firewall rules etc.
Steve
-
I also have a requirement for MSSID, with each instance mapped to a unique VLAN/subnet. Not sure pfSense can accommodate this with regard to DHCP.
Why not? The usual arrangement here would be to have the access point mapping each virtual access point to a different VLAN with all the VLANs trunked to pfSense. pfSense is then configured with those VLANs such that each VAP appears to be a separate interface complete with DHCP server, firewall rules etc.
Steve
OK great - then I have some reading to do. Not quite sure where the .1q trunks are set up in pfsense, and how they correlate to the number of sub-interfaces I will require on the physical NIC (on the pfsense box) associated with the AP.
-
Not quite sure where the .1q trunks are set up in pfsense,
Nowhere as such. If you are using a particular physical interface as a "trunk", go to Interfaces -> (assign), click on the VLANs tab, click on "+" to create a VLAN you wish to add and fill in the details, click Save then click on the Interface assignments tab and click "+" to add the VLAN to the pfSense pool of interfaces. Your VLAN interface will now have an OPTx style name (OPT1, OPT2, etc) and you then go to Interfaces -> OPTx and fill in the details such as IP address etc then go to Firewall -> Rules to add rules to control traffic and then (optionally) go to Services -> DHCP Server to configure DHCP services on the VLAN.
-
Not quite sure where the .1q trunks are set up in pfsense,
Nowhere as such. If you are using a particular physical interface as a "trunk", go to Interfaces -> (assign), click on the VLANs tab, click on "+" to create a VLAN you wish to add and fill in the details, click Save then click on the Interface assignments tab and click "+" to add the VLAN to the pfSense pool of interfaces. Your VLAN interface will now have an OPTx style name (OPT1, OPT2, etc) and you then go to Interfaces -> OPTx and fill in the details such as IP address etc then go to Firewall -> Rules to add rules to control traffic and then (optionally) go to Services -> DHCP Server to configure DHCP services on the VLAN.
If I am understanding you correctly, this method sounds analogous to a method for creating a sub-interface on the physical NIC in other products. Therefore, I should create each additional "Optx" interface that I require, ensure that the MAC matches the original physical NIC, and map the isolated VLANs (and the subnets contained within each VLAN) to what I have created in my AP via the trunk. And then create a suitable policy/rule set for each one I create.
Having the ability to run a distinct DCHP daemon per sub-interface is an awesome option!
Thanks very much! Can't wait to try it out!
-
Sounds like you have the idea. Have fun! :)
Steve
