this is my states while pinging and trying to connect to google.com
I guess this means it isnt a NAT issue ?

Proto  Source -> Router -> Destination                                          State   
icmp 64.233.187.99:58624 <- 192.168.0.20                                         0:0
icmp 192.168.0.20:58624 -> 72.186.197.246:43117 -> 64.233.187.99       0:0
tcp 209.85.165.104:80 <- 192.168.0.20:49248                       SYN_SENT:ESTABLISHED
tcp 192.168.0.20:49248 -> 72.186.197.246:57479 -> 209.85.165.104:80
                                                                                                      ESTABLISHED:SYN_SENT

There is no WDS support at the moment. and afaik, there is no way to add it either, the closest you will get is with OLSR.

I haven't change my snapshot after it worked fine and this is what I curently have:
Uptime: 17 days, 02:05

Wooosh!!! Run, baby run! :))) GJ!

@mani99:

Won't it be supported in FreeBSD 6.2 like jeroen234 said?
According to http://www.freebsd.org/releases/6.2R/schedule.html the expected release date of 6.2 is in 5 days. When is the next release of pfs planned?

/Máni

Check the FreeBSD release engineering docs.  6.2 is not even out yet!!

Go to diagnostics>edit and open "/usr/local/www/interfaces_wlan.inc"
Then search for  "Allow  intra-BSS  communication" and remove the "" around that codeblock and save. This will bring back the option in the webgui.

another problem might be:
Interfaces –> WAN --> Block private networks

When set, this option blocks traffic from IP addresses that are reserved for private
networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses
(127/8). You should generally leave this option turned on, unless your WAN network
lies in such a private address space, too.

since your WAN lies in such a private address range you have to uncheck this checkbox

Try http://pfsense.com/~sullrich/1.0.1-SNAPSHOT-12-14-2006/ . These images are based on a newer freebsd version.

Pigtails, connectors and such are not necessarily working on 5.X even if they work great on 2.4.
A lot of connectors have different specs. Be sure to get wires/connectors/pigtails that are made for operation up to 6ghz, or you might find yourself in all sorts of weird trouble. And if you keep testing with 2.4 antennas on the same cables you might find yourself even more lost  ???, since everything seems to perform nicely on 2.4  :-\

Our installers are still very new to wireless, especially regarding precision directional placements; perhaps more training and practice are in order.  Thanks for sharing some experiences aldo!  -pc

I'm not really in a position to test this, i'm located in .no and does not have the service available to develop and test. The previous work was done by having RDP access to a winXP PC and a FreeBSD unit with EVDO card.
I think this work is better suited for someone that can have hands on access to a test system. It's very timeconsuming to work with someone else in a completely different timezone, and depend on that person to be able to fix stuff when I break stuff during testing (like the FreeBSD/pfsense setup not booting after new kernel compiles).

If someone could provide a test setup where I can have access to a IP-reach KVM system, then maybe it can be done easier. But it's still not ideal. $$ allways makes it more interesting, but i still think this task is better suited for someone else. You can start a bounty thread and see what kind of $$ you can raise, if it's enough then someone (me perhaps) will most likely make it happen.

@sullrich:

Try the latest snapshot from http://www.pfsense.com/~sullrich/

If this still has issues then post a message to the FreeBSD-mobile list.

have been attempting to clarify the issue well enough to be able to post on freebsd-modile list.
have tryed the 6.2 snapshots with no change. am presently trying to work out how to add the newest ath_hal into a build.
but this is definately proving to be a difficult learning curve

will post outcomes when i have any more information

The ATH cards has AES built in, WPA itself is provided by hostapd/wpa_supplicant. So setting up WPA with AES only should not steal much, but if you are running close to the HW limits, then hostapd/wpa_supplicant might become a problem.

i have same problem for 3 months now, but my link is stable and works fine.
(cant ping computers on lan, and wifi clients cant ping aeach other, while lan computers can ping wifi clients)
it seems that problem is in freeBSD bridge driver, something is wrong…

i thingk guys will fix that...  ;)

Wireless users have to use the OPT1-IP as gateway. Simply set up a DHCP Server for the OPT1 at services>DHCP server, OPT1 tab. Then create a rule at firewall>rules, opt1 similiar to the default pass rule that is already present at firewall>rules, lan.

I've checked the instructions for the WAP, it looks like it will only work as a bridged unit with one particular router (!?).

Looks like it's nothing to do with pfSense and therefore (unless anyone knows a way round this problem) this thread can be ignored

Also asked and answered before. Search the forum.

I kept having intermittent problems so I changed my setup.  I think having OLSR and Captive Portal and Traffic Shaper, etc, running on one machine was too much for it.  So now the computer that was a pure MPR is now an OLSR "access point" of sorts.  I have OLSR bound to WAN, and LAN is bound to the wired LAN card with a cable running to my firewall/router which acts as captive portal, bandwidth manager, and other things.  I have OLSR turned off on the firewall/router computer.

I had gotten everything working good but when I turned on the Captive Portal I had a problem.  The https captive portal page would come up and when I typed in my name and password the browser would try to reach my homepage and then get redirected to the Captive Portal page again.  This happened every time I clicked on the Continue button on the captive portal page.

I finally got it to work by putting the MAC address of the "access points" LAN card in Pass-through MAC.  I also had to put a check next to Disable MAC Filtering under the Captive Portal tab.

Now when I start up my browser and the homepage tries to come up I get redirected properly to the captive portal and then get directed to my homepage after logging in.  Everything seems more stable with this setup.

I've sent you the ip/pwd.

Test's:

http://pr0n.se/wireless-pfsense/

Evidently very shaky when transferring from the soekris.

madwifi compat. list is probably the best source. This can give you some heads up info tho. http://customerproducts.atheros.com/customerproducts/default.asp