Alphis, its too hard to understand that if your client falls into the "dynamic range" it is a contradiction to have it into the "static arp entries" ?

If you want something to have static ARP, place him outside DHCP dynamic range !

duhhh !!!

Update: if I assign static IP address on the client everything works. Could it be related to the way DHCP server sends "DHCP Offer" message (client doesn't have valid IP address at that point yet)?

I'm not sure as there aren't any providers here supporting it, but it probably operates similarly to the EVDO equipment. If so, having the dial-up framework would be a good starting point- you'd just need to make sure you had the correct drivers.

Could it be the same reason (EAPOL version) - http://forum.pfsense.org/index.php/topic,9333.0.html ?

It's an old thread now, but who knows who may dig this up in the future.

I'm getting reasonable results with 3Com 8760 APs. They're not perfect (one particularly nasty snafu was when one corrupted its flash file system following a power glitch - you can't reflash it from the serial port so I had to RMA the unit). They're fairly polished units that are relatively inexpensive, dual band (simultaneously) and are Power over Ethernet capable. There's 4 VAPs available per band (though you can only have one set of WEP keys per band), the unit supports RADIUS accounting and you can return a VLAN in the RADIUS attributes.

Be aware that the supplied PoE injector is not 802.3af compatible - it's 'always live' rather than sensing as 802.3af intends. If you don't have a suitable PoE switch, ZyXEL make an inexpensive single port 802.3af injector.

The wireless hardware is Atheros.

As I seem to remember being noted in the pfSense blog, this is going to be some way off production yet. FreeBSD 7.0 has only just released; this patch is against -CURRENT, which is unlikely to see the light of day as FreeBSD 8.0-RELEASE for another 18 months or so. It may be more or less than that; at the moment there's no published roadmap for FreeBSD 7.1-RELEASE, let alone any thought of turning HEAD into a release.

I doubt it's possible to merge this work to RELENG_7 easily. Since RELENG_7 was branched and HEAD opened for checkins again, the two branches have diverged quite significantly, meaning that code in HEAD isn't always easy to apply to RELENG_7. It may well break the ABI, which is against the rules of a FreeBSD -STABLE branch, so any patch could not then be checked into RELENG_7. I expect this to need quite a bit of work for drivers to catch up and for the whole set of changes to become stable, simply because it's groundbreaking code.

Even if it's impossible for this to be checked in to RELENG_7, it may be that someone produces a patch for RELENG_7 that the pfSense developers could apply before building pfSense, in much the same way as there's a IPsec NAT-T patch that has been made for RELENG_7. The NAT-T patch which breaks the ABI so can't be merged to the -STABLE branch - sadly this feature 'missed the boat' for FreeBSD 7, much as I hope the patch will be adopted by one or more FreeBSD developers and checked in to HEAD. Such a patch for this code will likely be some while off.

VAPs are useful for me. I'm using 3Com 8760 access points on my setup. For example, I have a couple of older devices that support WPA but not WPA2; I can make them use a separate WPA only VAP, and use my RADIUS server to enforce that the devices that lack WPA2 support are the only devices that can use the WPA VAP. The 8760 operates with 802.1q tagged VLANs; you can set a default VLAN for each VAP and use your RADIUS server to direct the AP to bridge to a different VLAN when you wish to do so. VAP, VLAN and RADIUS makes for a powerful combination.

no gateway set on opt1wifi connection…..set no internet connection.

Set the AP to bridge mode

A year ago or so i tried with a WPN311 (REV. A2) but it didn't really play along. Too many packets errors.

http://forum.pfsense.org/index.php/topic,6444.0.html

Ok i looked around and found that my card is a 5414(i opened the metal shield)  SUPER AG .
I did some testing with other router software an manage to work with super G but not Super A.
I also found some problems with this Chip (5414),in some other software it does not even detect it as a 5GHz capable card.

ura? do you mean ural? ural should work just fine, even in AP mode I think. Do you see a (+) icon at interfaces>assign in the webgui? Also make sure the usb adaptor is plugged in at bootup already. Can you provide th dmesg section of http://<pfsense-ip>/status.php from a bootup with the stick already connected?</pfsense-ip>

I bought the WG311T which had an atheros chipset but worked for a short while and then worked off and on. You may have better luck the with the WG311 than I did with the WG311T which may have a different chipset. This card may work much better under pfSense 1.3 that uses FreeBSD 7.

On pfSense 1.2 I have had much better stability with Linksys Wireless-G USB Network Adapter, WUSB54G Ver. 4. Make sure it is version 4 in order to get a compatible chipset.

Or you could pick up a PCI adapter and a mini PCI atheros card from Netgate.

@hoba:

disable nat by enableing manual outbound nat (firewall>nat, outbound) and deleting all autocreated rules

That is all, that is needed at the pfSense to shutdown NAT. Additional to that you only need that one static route at the openbsd box.

I don't get that other thought with the WLAN and nat but the above procedure is pretty simple and probably better.

Read the config page.

NOTE: leave blank to use the system default DNS servers - this interface's IP if DNS forwarder is enabled, otherwise the servers configured on the General page.

Well still had problems with the receive errors. However on monowall 1.3b11 the problems go away. Not sure if this is maybe a bug somewhere.

Thanks for posting this. There was a similiar hardwarehack neccessary for the wraps when using high power wlan nics iirc. You also should get a decent psu when using such a card.