Please test wireless in latest snapshots
-
We commited a change to enforce mtu 1500. Please try a recent snapshot.
-
I have upgraded to the latest RC1 snapshot, and the problem still continues. Once Access Point is enabled, ath0 changes MTU to 2290.
-
I decided to ask on the freebsd-net mailing list, and the response I got was, that 2290 is the default MTU for 802.11.
-
Any chance hostapd is resetting the MTU to 2290? I just looked at it's source code, and it appears that it may be setting it (see line 86), http://hostap.epitest.fi/hostapd/devel/hostapd_8h-source.html and (see line 241) http://hostap.epitest.fi/hostapd/devel/driver__bsd_8c-source.html.
-
weird… the last ifconfig we run on bringing up a wireless card is now 'mtu 1500'. My ath card hasn't shown this behavior in hostap mode, it's always shown 1500 without this recent change so it's not an issue with every ath card.
If anyone finds additional information on this please let us know. I'll be doing more wireless testing as time permits over the next week.
-
Ok heres the deal with me. (20080730-0226)
With no security It works fine, I get an IP address, With WEP It also works fine.
As soon as I enable WPA It will never connect. Even after I disable WPA and either choose no security or wep it still deos NOT work.
Can anyone else test with WEP or no security on initial install BEFORE enabling WPA to confirm it's the same with other hardware?
I have not had a chance to look at the MTU in this process, but if it does happen only when WPA get's turned on it may point us in the correct direction.
(Utilizing a Cisco ABG card in an Acer5620z Laptop.)
Many thanks,
Tom -
pfSense-Full-Update-1.2.1-RC1-20080730-0232
mtu 2290 on ath0 and bridge0
-
THANK YOU!
ifconfig ath1 mtu 1500
ifconfig bridge0 destroy
ifconfig bridge create
ifconfig bridge0 addm ath1 addm axe0 up
(where axe0 is my LAN interface and ath1 is my Wireless (opt1) interface)Works perfectly!
NOTE If you do not have any security or WEP the MTU does not set itself to 2290 so wherever the problem it is, it's only when you enable WPA. Hopefully they can find the piece of code, or create some to set the interface MTU teardown the bridge and recreate!!
@JTY:
Did some testing, not sure if anyone found this before. Anyway…
After bridging the Wireless with the LAN, the following is appears when running dmesg:
bridge0: invalid MTU for re0
I checked the bridge0 interface, and it had an MTU of 2290, just like ath0. Obviosly that MTU is invalid for a standard ethernet NIC, thus it refuses to join bridge.
From there, I attempted to set ath0 (Wireless) MTU via pfSense webConfigurator, but the MTU setting was ignored. So, I manually set it via the shell. However, bridge0 still had an MTU of 2290 after changing ath0's MTU.
Finally, I decided to manually destroy bridge0, and recreate it. Now, that I had ath0 set with an MTU of 1500, both ath0 and re0 would have the same MTU.
ifconfig bridge0 destroy
ifconfig bridge create
ifconfig bridge0 addm ath0 addm re0 upAfter recreating the bridge with both devices having an MTU of 1500, the bridge worked properly. The only left was to create a firewall rule to allow traffic in on the Wireless interface, which I did via the webConfigurator.
Hopefully the above is of use to somebody.
-
Loaded the pfSense-Full-Update-1.2.1-RC1-20080804-0805
After reboot i had no OPT1 interface associated. I reqoqnize that one and went in and set the channel to 6 maually then it got associated (is was set as Auto by default). This the error found in log before i set the channel: kernel: ath0: unable to reset hardware; hal status 12. I have a feeling that WPA Pairwise cant be handle by any client. Is now set to TKIP mode now, which works for me.
The MTU is fixed now i think, all was at 1500 after reboot. Wireless client (WinXP) connected and I can surf from it. Thanks again for all your works for this GREAT firewall/router. Ill keep try updating to newer version whenever thare time for it and report back unsuall stuff from this machine and this newbie user :p
Wireless works …. wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii :P
Oh anotherthing, when entering the Status\Traffic Graph, when graphic graph is showing, try click on Status\Traffic Graph again. Menu dont show fully.
-
Wireless is now working for me.
-
i hate to break the party but my wireless still wont work. mtu is 1500, security with wpa2/aes and i don't even see the wireless network in the list on my xp client. interface status for wireless says 'no carrier'
-
i hate to break the party but my wireless still wont work. mtu is 1500, security with wpa2/aes and i don't even see the wireless network in the list on my xp client. interface status for wireless says 'no carrier'
Goto "Interface" menu and try set your OPT1 channel manually (1-11), then goto Status+interface and check afterward if you still get no carrirer.
-
Goto "Interface" menu and try set your OPT1 channel manually (1-11), then goto Status+interface and check afterward if you still get no carrirer.
it worked, now i can see the wireless network from my laptop but i still can't conect. well it connects but pfsense wont give dhcp info to the laptop. setting static ip is not helping.
i can get dhcp info through stand alone ap connected to pfsense no peroblem though. -
I can confirm the same problem when bridging LAN and WiFi with 1.2.1-RC1 / built on Wed Aug 6.
My notebook is connected, but no DHCP lease. So I tried with static IP assignment, no ping…
Regards
-
same here. alix2c3, wistron cm9, wifi bridged to lan.
-
I'm running a build from the 10th, and no problems with wireless.
-
I run pfSense-Full-Update-1.2.1-RC1-20080810-1453, no problem with Wireless
-
Hi everybody,
I have still problem with bridging.
If LAN interface is down, WLAN won't work. If I plug ethernet cable, everything is working fine again!Hope that helps
Regards
-
This isnt a bug. This has always been that way.
If one interface of a bridge is down, the whole bridge will be down. -
Really, I never saw this problem with 1.2…
But I trust you. Any tips to avoid this (except plugging something ;))?
-
I'm not sure about 1.2
I only remember reading about it.
A quick search brought this post up: http://forum.pfsense.org/index.php/topic,2131.msg12397.html#msg12397Well you can always plug a dummy switch into it ;)
The only alternative i see is not to use a bridge and route :) -
Thanks GruensFroeschli!
I have to buy a switch now :) -
upgraded to the latest image Aug 14th with the same result. i can see my wifi but laptop is not able to get any dhcp info from pfsense and setting up static wont help either.
again, separate ddwrt ap connected to pfsend distributes dhcp no problem. -
I'm not sure about 1.2
I only remember reading about it.
A quick search brought this post up: http://forum.pfsense.org/index.php/topic,2131.msg12397.html#msg12397Well you can always plug a dummy switch into it ;)
The only alternative i see is not to use a bridge and route :)You could also use mad geek skillz to wire a link-up plug. Check out the ethernet loopback plug schematics here:
http://www.ossmann.com/5-in-1.html -
How do i know if the "Turbo" mode is functioning and active? Running: pfSense-Full-Update-1.2.1-RC1-20080815-2044
Is thare a command to check with? (webgui command)
Thanks
-
Do you mean 802.11a turbo?
To test the speed, the best is to have 2 computers on both sides of the wireless link and use iperf http://www.noc.ucf.edu/Tools/Iperf/ to test the actual throughput.
On normal 802.11a you can expect about 25 Mbit.
On 802.11a turbo you can expect about 36 Mbit.
I only know numbers for 802.11a because i just recently had to do some bandwith test with it.
Does anyone have numbers for 802.11g ? -
I have had wireless problems lately too. It works only intermittently. I suspect this happened after I upgraded to 1.2.1-RC1
built on Tue Aug 12 10:45:41 EDT 2008 but can't be sure because the wireless seemed to be working consistently up until a few days ago.I have an Atheros wireless card bridged with a wired NIC. I found DHCP works fine for three computers on the wired network but two computers on the wireless LAN sometimes don't get a DHCP response. Here's an extract from the output of tcpdump -i ath0
22:05:29.312493 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:3c:19:86:82 (oui Unknown), length 300
22:05:33.313494 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:3c:19:86:82 (oui Unknown), length 300
22:05:41.313748 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:3c:19:86:82 (oui Unknown), length 300
22:05:57.315457 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1f:3c:19:86:82 (oui Unknown), length 300I looked in /var/log/filter.log and saw:
Aug 18 22:05:29 pfsense pf: 10. 487110 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 27894, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:29 pfsense pf: 000077 rule 68/0(match): block in on bridge0: (tos 0x0, ttl 128, id 33426, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:29 pfsense pf: 000044 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 27314, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:33 pfsense pf: 262309 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 21164, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:33 pfsense pf: 000077 rule 68/0(match): block in on bridge0: (tos 0x0, ttl 128, id 12450, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:33 pfsense pf: 000045 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 11139, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:41 pfsense pf: 5. 628048 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 2725, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:41 pfsense pf: 000081 rule 68/0(match): block in on bridge0: (tos 0x0, ttl 128, id 41427, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:41 pfsense pf: 000043 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 62387, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:57 pfsense pf: 16. 001574 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 9992, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:57 pfsense pf: 000071 rule 68/0(match): block in on bridge0: (tos 0x0, ttl 128, id 29988, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
Aug 18 22:05:57 pfsense pf: 000044 rule 68/0(match): block in on ath0: (tos 0x0, ttl 128, id 2102, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]Looks like the firewall is blocking the DHCP requests from ath0. I'm not aware that I have done anything to change any rules so I'm curious why DHCP requests on the wireless LAN sometimes succeed and sometimes don't.
I did a status display (http://pfsense/status.php) and looked at the rules and noticed these rules:
@15 anchor "dhcpserverlan" all [ Evaluations: 253280 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1624 ] @16 pass in quick on rl0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server on LAN" [ Evaluations: 253280 Packets: 1335 Bytes: 456101 States: 0 ] [ Inserted: uid 0 pid 1624 ] @17 pass in quick on rl0 inet proto udp from any port = bootpc to 192.168.211.173 port = bootps keep state label "allow access to DHCP server on LAN" [ Evaluations: 138 Packets: 295 Bytes: 96892 States: 0 ] [ Inserted: uid 0 pid 1624 ] @18 pass out quick on rl0 inet proto udp from 192.168.211.173 port = bootps to any port = bootpc keep state label "allow access to DHCP server on LAN" [ Evaluations: 39484 Packets: 14 Bytes: 4592 States: 0 ] [ Inserted: uid 0 pid 1624 ]
but there are no corresponding rules for ath0. OK, so maybe I need to check my configuration and enable dhcp on OPT1 (the ath0). There is nowhere to do that on the Interfaces->OPT1 menu and if I go to Services -> DHCP Server there is no tab for OPT1 (the wireless interface), only for LAN and DMZ (both wired LAN interfaces).
Perhaps the generated firewall rules for dhcpserver should have specified interface bridge0 rather than rl0?
-
Bridging is working for me now on a wireless interface and I was having issues before. Using "built on Thu Aug 14 18:19:52 EDT 2008" right now.
-
Bridging is working for me now on a wireless interface and I was having issues before. Using "built on Thu Aug 14 18:19:52 EDT 2008" right now.
I have tried the loopback plug without success (same version as you).
Interesting, do you have anything plugged into your LAN interface (if it is the one bridged with your WLAN)?Regards
-
Bridging is working for me now on a wireless interface and I was having issues before. Using "built on Thu Aug 14 18:19:52 EDT 2008" right now.
Interesting, do you have anything plugged into your LAN interface (if it is the one bridged with your WLAN)?
Cable modem on WAN; gb switch on LAN side of pfsense. Wireless card bridged with lan for 802.11g access.
-
what kind of security setting you guys have? it doesn't work for me bridget to lan with wpa2/aes.
-
what kind of security setting you guys have? it doesn't work for me bridget to lan with wpa2/aes.
wpa2/tkip here.
-
what kind of security setting you guys have? it doesn't work for me bridget to lan with wpa2/aes.
WPA TKIP
-
what kind of security setting you guys have? it doesn't work for me bridget to lan with wpa2/aes.
WPA2 TKIP
-
nothing works for me… :(
-
Trying to use rum0 as an AP bridged to LAN. can see rum0 as opt1 but no wireless option under interfaces.
where should I be looking? or is this a bug that wireless options are recognized ? -
Trying to use rum0 as an AP bridged to LAN. can see rum0 as opt1 but no wireless option under interfaces.
Looks as if /etc/inc/globals.inc needs to be updated to include the new WLAN interfaces supported in FreeBSD 7.0: add rum to the WLAN interface list on the line beginning "wireless_regex" => . From the Interfaces menu, (assign) you will probably need to delete the interface and then add it again to have the wireless capabilities displayed.
Note to pfSense developers: the two VLAN lists in the same file possibly need to be updated also. Does et (the Agere ET1310 driver) need to be in one or more of the VLAN lists?
-
I don't know is this a bug. I have a pfsense box with tree nics, wan, lan, opt1 connected to a zyxel wireless router only used as a wireless accesspoint. With some of the snapshots of 1.2.1 it got disconnected, on the wireless side, and i have to restart the firewall, this never happened in 1.2. This can happen after 1 h or after 1 day. Another thing is that once or twice my firewall has locked and i cannot connect either by web interface or ssh and with no internet access whatsoever.
Is now using 1.2.1-rc1 build aug 25.
-
Editing /etc/inc/globals.inc allowed wirless options for rum0 to be set
Thanks Again !! -
Interface added, thanks!!