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
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 :-\
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.
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…
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 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.
1. The documentation says theres no filtering between bridged interfaces. But I have to set a rule on the OPT1 interface to allow all traffic to all nets like this to make it work (especially for DHCP request).
Proto Source Port Destination Port Gateway Description
* * * * * * OPT1 -> Any
So there IS filtering between bridged interfaces.
2. Flaky Wlan driver on the client side. Nasty Netgear WG511 PCMCIA Card. Forced it to eat a newer driver for an 3Com Office Connect Card and works now without problems and even has AES support now.
So for all people with the same problem:
If you want to create the following setup:
WAN -> Internet
LAN -> Local wired network
OPT1 -> AP Wireless LAN bridged to Local wired Network
just do the following
-Get your WAN and LAN running. Then go to the OPT1 settings page and set it to be bridged with LAN. Leave the IP configuration for the OPT1 interface to static.
-Setup the remaining wifi stuff (WPA,WEP,Keys etc) and save the settings.
-Next go to the Firewall Rules settings page and click on OPT1 interface. Add a new rule to allow traffic from any to any.
Maybe your card doesn't support WPA2 under freebsd. We don't detect the capabilities of the card concerning wpa2 afaik. You'll find a config script (generated from your gui settings) for the wireless card in your /tmp folder. Try to ssh in to your system and run the script manually. Does it reject some of the options that the script tries to set?
In what mode does that nic run? In accesspoint mode it should show always link up. In case it's one of the client modes like infrastructure or adhoc it means the accesspoint it was connected went down.
Check status>systemlogs for obvious messages. If you can't access your system anymore after this bug occurs setup a remote syslog server to send the messages to another system to investigate later.
If this is a wrap or a soekris make sure your PSU is strong enough to handle the 2 wireless cards. If it is a wrap make sure you have the latest bios. There were some fixes that affect atheros problems.
If you want to unhide it from the gui just remove the two highlighted green lines from the file ( http://cvstrac.pfsense.com/chngview?cn=14890 ) by using diagnostics>edit but it won't work. That's why it was hidden. It's not a pfSense bug but a driver bug in freebsd.
Thanks a lot !! I unhided the setting and enabled it and as far as i can tell it works for me.
I'm not surprised as my only problems thus far have been with a USB keyboard :) Unfortunately I can only use half height cards in this case, and I haven't found any dual ports that would fit. If that kind of error simply kills the wireless, I can live with it being a little flakey since it's just for Internet connectivity in conference rooms. As long as it doesn't kill the firewall completely.
…"how should I design this szenario. Should I use the AP ? Where should I put it to?"...
Do you want the linksys and the pfSense system to both be wirelessly directly connected to your mesh? And, they will be in separate locations? Otherwise, if they are near each other, only one needs to be on the wireless mesh and functioning as a wireless "AP"; thus, the second unit would be connected to the first via ethernet/wired. So, configure routing as normal, and add an HNA route announcement in OLSR for the second unit's IP & netmask.
Freifunk/olsr for Linksys WRT54GL...
To also use it as an "access point", update it with this package: "freifunk-dnsmasq..*_mipsel.ipk" from...
If you want wireless dhcp to Not use NAT and serve "real routed" IPs to local wireless clients then ssh (or PuTTY) into your linksys, you'll need to backup copy and delete /etc/dnsmasq.conf then recreate it because it's just a reference to a rom file, edit /etc/dnsmasq.conf with "vi" editor and add an extra "dhcp-range" line for device "wlnat" and configure the desired dhcp IP range and netmask (restrict range to your node's IPs) for wireless clients, also comment out lines begining with "address=", and if you set up "olsr nat" in the gui then erase it. [update] Newer versions may require DNS server IPs to be specified in dnsmasq.conf.
If you need more help check the Freifunk mailing list…
As for OLSR on pfSense:
sample olsr & dnsmasq configs...
plus add startup shell scripts such as these for olsrd & dnsmasq ...
If it's prism 2 based and you find the correct firmware to make it operate in AP mode, then it should be found by freebsd. If it's PrismGT or somthing along those lines then it will not work. In general old prism cards/prism cards in general are not recommended. Try to get your hands on something Atheros based.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.