I don't know how relevant it is to this thread, but the other ipod/iphone threads have been locked so…

I was running pfsense 1.2.2 as access point (wpa2/tkip) and my ipod was able to connect, but had timeout issues and could not download anything over WiFi.

Yesterday I upgraded to pfsense 2.0 beta (4-22-2010 build) and now everything is fine with exactly the same WiFi settings.  No timeout issues and downloads are great.

It does not currently have a channel width option, but I'm fairly sure the base system does.  It wouldn't be too difficult to add, though it would likely only be implemented for 2.0.

As for additional channels, if your card supports them, you should probably see them in the list.  Otherwise, they will not be listed.  There is also a possibility that ifconfig on FreeBSD does not support listing those channels, though.  ifconfig gets its information from /etc/regdomain.xml

I have the same problem with the same wifi card (CM9 Atheros chipset) on a Soekris net5505

miibus5: <mii bus=""> on sis1 nsphyter1: <dp83815 10="" 100="" media="" interface=""> PHY 0 on miibus5 nsphyter1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:ca:df:d5 sis1: [ITHREAD] ath0: <atheros 5212=""> mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0 ath0: [ITHREAD] Fatal trap 1: privileged instruction fault while in kernel mode instruction pointer    = 0x20:0x3 stack pointer          = 0x28:0xc1020944 frame pointer          = 0x28:0xc1020958 code segment            = base 0x0, limit 0xfffff, type 0x1b                         = DPL 0, pres 1, def32 1, gran 1 processor eflags        = interrupt enabled, resume, IOPL = 0 current process        = 0 (swapper) trap number            = 1 panic: privileged instruction fault</atheros></dp83815></mii>

The dropdown represents the % of the maximum power not the absolute power.

OK, got my pigtail and set up the internal card, everything is working just fine now, looks like pfSense + Belkin G + OS X is a bad combination…

I use a Kelkin wireless N1 [+?] (MIMO) as my network AP and it works just fine for me…

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.

I usually keep my wireless network on channel 11 since most devices don't seem to use that channel (not sure why) or some other random channel that is "technically" meant for other countries (Mexico, Japan, etc), works wonders for me, but yea other wireless devices can really play havoc with wi-fi…effectively your phone was acting like a signal jammer to the wi-fi.

@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