@kpa:

@NoProbRob:

As I understand it, in order to use authentication, I cannot use an external wireless AP (such as WRT54G) because that won't pass the MAC address of the client PC thru to pfSense to use for the authentication.

Yes you can as long as the wireless AP operates as a bridge between wireless and wired networks and does not do any routing.

Thanks for the reply! Thanks to you I've got it working in a "simulation mode" with another router connected as the WAN providing an "up" connection with DHCP, etc., and two laptops entering through the wireless into the LAN side. Captive Portal catches the laptops, then allows them through to that fake WAN after authenticating. It all seems to work smoothly, so I expect it to do so when I hook up the real WAN.

I thought I had heard or read somewhere that the MAC wouldn't be passed thru the wireless, but it would make sense that that would be the case only if the wireless was handling DHCP, routing, etc. As you said, it does seem to work with the wireless serving as a "dumb" AP bridge to the LAN and nothing more.  I guess I had a "mental block" about the MAC so I foolishly didn't look into it further.

Thanks again!!

FYI- this is covered in the Doc Wiki also:

http://doc.pfsense.org/index.php/Use_an_existing_wireless_router_with_pfSense

Do you want to bridge the pfSense?
You can only bridge the wireless interface if it is in access-point mode.
So you would have to run the AP on the pfSenses side, or set up a routed network (which is imo more proper than a bridged scenario).

Were you getting any "stuck beacon" error messages in your system log?  I've seen that at first with both Atheros-based cards I've tried (5212 and 5416 chipsets).  Changing channels or removing the antennas sometimes would make it stop.  It eventually seemed to go away on its own in both cases after I had already tried changing channels, rebooting, etc., and I was then able to use the channel I wanted without seeing the error.  They may require some kind of calibration period before they work right on the ath driver.

I've also seen good results from a card I have that is based on the Marvell 88W8363 (mwl driver in FreeBSD), but with no initial issues either, unlike the Atheros cards.  It does require at least FreeBSD 8, however; which means it won't work in pfSense 1.2.3, only 2.0.  The card supports 802.11n, but the mwl driver doesn't seem to support 802.11n rates yet (only up to 54mbps).  Like ath, the mwl driver also supports virtual access points on 2.0 (new in FreeBSD 8 ), but unfortunately the mwl driver is currently missing something that is needed for the additional access points to actually be usable by wireless clients.

a restart seemed to do it.  I guess i assumed that was not required.  Thanks for the tip.  I was trying your other suggestion but it was taking a while and not finishing.

Might save you a few watts but I'm sure your Buffalo HP will have a better signal than a wireless card on your pf box.  There are still a few ath driver issues that will give you stuck beacons and device timeouts.  So for reliability's sake, stick with your Buffalo.

In complete contrast to the above, I have pfSense on a ALIX using a WLM54G-HP card and its rock solid with no errors ever.  Had the same card on a pci adapter on my micro-atx pf box and it gave me nothing but problems.  Dumped the internal wireless and I'm enjoying a problem free WHR-HP-G54 with DDWRT just like yourself.

I did not compiled the drivers by myself, but I think you need to enable superchannel at compile time.

/* Set this to 1 to disable regulatory domain restrictions */  #define SUPERCHANNEL    0  /* Set this to 1 to disable regulatory domain restrictions for channel tests.  * WARNING: This is for debuging only and has side effects (eg. scan takes too long  * and results timeouts). It's also illegal to tune to some of the supported frequencies  * in some countries, so use this at your own risk, you 've been warned. */  #define CHAN_DEBUG    0

@wallabybob:

Log doesn't mean much to me.

Have you tried the WiFi without encryption? With alternate forms of encryption?

Well tried w/o encryption and same problem. tried to connect using the laptops wifi.
The host system a Dell latitud D630 with 2GB ram start to slow down really mush when I connect to wifi

I try just now after a reboot and it work well!!  ??? I don't understand everything but after all it work.

Thanks everyone for your help. ;D

Last I saw, the Intel cards – even if they did work -- do not work in hostap mode, so they could not be used to setup a pfSense access point. They could only be used for wireless WAN.

It looks like the iwn driver would support the 4965AGN, and if that isn't already in pfSense 2.0 it could probably be included in the kernel config (it may not have been updated to include that driver). However, as I said in the previous paragraph, the iwn(4) man page for the driver indicates that it doesn't support hostap mode, only station, adhoc, and monitor modes.

The challenge isn't just finding an N card that works with FreeBSD, but also an N card which has a driver that supports hostap mode with N.

I just received the 7dbi car antennas in & they don't seem to be boosting my signal strength….what am I doing wrong? Am I buying to cheap of antennas? my range is very weak, same as before...I'm only about 50ft from my PFSense router AP & I struggle to get full bars; Or is this normal? There isn't really all that many AP's in my area.

Here is a link to the antennas I bought so you guys could hopefully help me evaluate this a little better.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=300378554883

sigh, search the forum - sounds like you are having the same issue i was.  my tplink ath unit works fine -until it doesn't and i have to reboot to "fix" it.  it's been okay for a couple of weeks now, though.

Belikeyeshua was using the word "card" in all of the posts, so I assume it was either PCI or mini PCI (and not mini PCIe since TP-Link doesn't seem to make any of those yet).  It must be either the TL-WN851N (2 antennas) or TL-WN951N (3 antennas) for PCI or the TL-WN861N (for 2 antennas) or TL-WN961N (for 3 antennas) for mini PCI.  As far as I know, all 4 of those use the same Atheros chip(s).

I have a TL-WN660G (Atheros 5212) and a TL-WN861N (Atheros 5416), but at least for now the TL-WN660G is working better for me (on 1.2.3 release and 2.0 beta).  They are supposed to have the same specs, as far as transmit power and receive sensitivity, so it might be that there are some driver issues or that the Atheros 5416 chip might not work as well in compatibility mode.  Another possibility could be that the TL-WN861N might require two antennas to meet the stated specs, and I may have broken something inside one of mine sometime.

Well, I can tell you what not to buy: an EnGenius EPI-3601S

It installed painlessly, and the transmit power is excellent, but the sensitivity is so poor that I can't connect to the thing when I'm standing right next to it.

pfSense 1.2.3 is built on FreeBSD 7.2 so if your card is supported by FreeBSD 7.2 its also supported in pfSense 1.2.3.

pfSense 2.0-BETA is built on FreeBSD 8.0 so if your card is supported by FreeBSD 8.0 its also supported in pfSense 2.0-BETA.

FreeBSD support can be checked by looking up the man page for the appropriate drivers at http://www.freebsd.org/cgi/man.cgi (Select the appropriate FreeBSD version.) The ral driver supports some Ralink PCI chipsets and the ural and rum drivers support some Ralink USB chipsets.

It would seem from reports in theses forums that Atheros based PCI cards are more commonly used in the pfSense community than Ralink based PCI cards.

@wallabybob:

@varazir:

Well then I have to look for another usb wireless adapter

I've had positive experience with USB adapters based on the Ralink chipset (rum driver). I've used a D-Link DWL G122 and a TP-Link TL-WN321G. Unfortunately D-Link have the practice of changing the chipset in their devices without changing the model number, making it a bit hard to be sure that you are buying a device with a chipset supported by FreeBSD. The D-Link I bought on eBay was a hardware rev C and that seemed to work OK with the FreeBSD rum driver, though it didn't get a lot of use.

When last I looked, I couldn't find any adapters based on the earlier Ralink chipset supported by the ural driver.

Borrow a D-link rev C adepter from a friend and it worked great