Latest snapsot wireless bridged as well as static not working
-
So to summarise:
-
tcpdump shows dhcp requests received on the wireless NIC
-
the wireless NIC has firewall rules to allow DHCP traffic
-
the firewall filter log doesn't show DHCP requests blocked
-
the DHCP server log doesn't show any DHCP requests recognised.
I'd be suspicious that you have somehow got a firewall rule that quietly blocks the DHCP requests from the wireless NIC. I can't think of any other explanation that fits what you report. How about dumping the firewall rules and posting them: type the shell command pfctl -s rules -v.
-
-
see the txt file for dump
-
The rules dump includes
pass in quick on ath0 proto udp from any port 66 >< 69 to any port 66 >< 69 keep state label "USER_RULE: pass dhcp traffic"
[ Evaluations: 48 Packets: 211 Bytes: 69208 States: 0 ]
[ Inserted: uid 0 pid 3678 ]From the pfctl man page it appears this means 211 packets matched this rule.
I don't know what filter dhcpd uses to request incoming packets but probably most of those 211 packets should have gone to dhcpd but apparently didn't. Was dhcpd running? (Had it died?) -
dhcpd is running happily and hands out ips on the lan but doesnt on the wireless bridged to lan.
like i said the same config, without any changes works very well for releases in March or so and i was using it so far until i tried the 7th april and onwards snapshots and it has been down every since.
its just that in bridge or non bridge, dhcp doesnt hand out ips on the wireless interface at all.
-
Nothing jumped out at me as changing between March and April, but you might browse through the commits to see if you notice anything:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/logs/RELENG_1_2
I didn't look through the tools/builder scripts, but sometimes changes there can affect the releases as well.
https://rcs.pfsense.org/projects/pfsense-tools
-
on some more testing i found out the following
wireless to lan bridge doesnt work but as i said even on standalone wireless as access point configured to give out ip using dhcp wasnt able to do that but after a lot of config change it some how gave out the ip using dhcp put the dns server should be 192.168.2.1 as that being the ip of the wireless but it used to give dns address of that listed under the system>general setup but the tick box is tick saying Allow DNS server list to be overridden by DHCP/PPP on WAN so basically something to do with that so i then removed the dns entries over there and kept the tick box ticked so then the dns server changed to 192.168.2.1 which is the ip of the wireless interface so i guess the bug is in that tick box, inspite of it being ticked it still gives the wireless clients the dns server written in the boxes above so keeping them clear seems to solve the dhcp in standard wireless mode.
ill do further testing by enabling wireless to lan bridge and report it further -
in standalone wireless mode its giving out ips but as soon as i switch it to bridge mode, then it still gives out ips but the ones that it used to give out when in standalone mode so the routing is wrong on it so nothing opens in the client and also everytime i do some changes the CPU usage jumps to 100% so i guess ill simply stick to the march release atleast its stable
-
I can confirm that Wireless bridging is Borked on My Alix box running builds 0416-2048 and 0417-2146. Devices are associating successfully, but no traffic is being passed to LAN (Wifi bridged -> LAN). Have rolled back to 0328-0054, retaining same config, which works just fine.
Hardware:
Alix 2c3 BIOS 0.99h
Atheros 5212 based miniPCI card (Wistron CM9)can u provide me with the file that u got , 0328-0054?
-
currently running :
1.2.3-PRERELEASE-TESTING-VERSION
built on Sat Mar 28 00:40:33 EDT 2009works perfectly fine, wireless, dhcp, dns, wireless to lan bridge
-
can u provide me with the file that u got , 0328-0054?
No problem, here ya go:
http://files.me.com/jason.pugh/oizgne
(link will only be active for next 7 days)BTW I have noticed looking at the embedded images that the image size jumps by about 1.2MB from the 0328-0054 build to the April builds with broken WiFi bridging. There are usually small fluctuations in size, but the big jump suggests that a large change might have been commited, or compile option changed?
[IDIOT DISCLAIMER]
As I have not been invoved in any serious dev work for a number of years now, please treat the above comment as speculation rather than fact!
[/IDIOT DISCLAIMER] -
thanks for the file, works perfectly fine.
i was checking the change log, maybe the difference in file size was maybe because of some driver update or new install, not sure though.
-
I suspect for the bulk of you this is user error, missing firewall rules that allow DHCP or something. Mine works perfectly fine and I know it works fine for numerous others and haven't personally seen a box where it didn't. Though this:
I can confirm that Wireless bridging is Borked on My Alix box running builds 0416-2048 and 0417-2146. Devices are associating successfully, but no traffic is being passed to LAN (Wifi bridged -> LAN). Have rolled back to 0328-0054, retaining same config, which works just fine.
sounds legit. Sloth: if I get you a few snapshots between 3/28 and 4/16 can you test to narrow down the change more closely? Nothing sticks out at me between those points.
-
cmb,
Yup, no problem testing a few snapshots around those dates if you can make them available. I was going to have a look at them Myself, but didn't get onto the download area before they had been removed - Doh! Just one problem though - I'm travelling from tomorrow am (European time), so would need the snapshots within the next couple of hours to stand a chance of getting them flashed and tested.
BTW I'm just about to try the RC…..
-
If this is an user error why did it occurr (without any changes) so suddenly after certain snapshot? And why is it fixed when reverting back to an older version?
Also for me this is occurring so that the DHCP works fine for one time and after the first connection it stops giving out ip's (or any other traffic for that matter). If I refresh the interface ( go to interfaces->wlan and push save) it again works for one time.
I am using RL2560, some people here are using atheros chipsets so it probably isnt driver related.
I have tried WPA2 and WPA (both and separaly). Previously I was using WPA only with G only mode.
EDIT: just flashed the new RC, same thing. Works for the first time (after boot or restarting interface) and after that nothing.
In system logs I see:
Apr 23 23:13:13 hostapd: ral0: STA <mac_here>WPA: group key handshake completed (WPA)
Apr 23 23:12:30 hostapd: ral0: STA <mac_here>WPA: group key handshake completed (WPA)
Apr 23 23:12:29 hostapd: ral0: STA <mac_here>WPA: pairwise key handshake completed (WPA)
Apr 23 23:12:29 hostapd: ral0: STA <mac_here>IEEE 802.11: associated</mac_here></mac_here></mac_here></mac_here> -
i certainly dont think its a user error coz i have been using the config ever since and nothing has changed in it, the rules r all fine etc and bytheway u guys can test between 28th march and 7th april coz i have tried 17th, 13th, 21st april and all r broken so to narrow it down, 28th march to 7th april so that makes it 9 snapshots for those 9 days
one more thing, when was it that the system page started showing 1.2.3 RC1 on a march release coz if im not wrong i was using such a march release and was working fine, i guess something even after 28th
-
If this is an user error why did it occurr (without any changes) so suddenly after certain snapshot? And why is it fixed when reverting back to an older version?
As I said, if you're one that can revert back to an earlier 1.2.3 snapshot and it's fixed, that's not the case.
I don't have many embedded snapshots for testing though to narrow it down. Lot of iso and full update files. Will see what I can find. Thanks for narrowing down the dates already.
-
I don't see any relevant changes between March 28 and April 7.
Those who are having this problem, try checking "Allow IPv6" under System -> Advanced. That change falls within this window, but there isn't any way that should have anything to do with this unless PF's inet6 does strange things. It isn't for me, and I seriously doubt if that's the case, but it's the only remotely relevant change I see in the 1.2 branch between those dates.
-
there is no option under system->advanced to enable or disable ipv6
-
Sure there is.
-
basically it doesnt appear in my current 28th march release, i completely forgot about it.
ill need to reinstall the latest firmware and give it a try.
-
Try to install the RC1 snapshot linked on the latest blog entry:
http://blog.pfsense.org/?p=428
-
It seems that my new NC10 can connect jus fine, but my other devices (that used to work, Wii and e90) still cant connect after the first connection.
If theres something changed in rules or maybe a bug fixed that would have affected those could someone give a ruleset that allows all lan-wlan traffic so that basicly there would be no filtering etc. between them. I only want to extend my wire network with wlan.
-
UPDATE: I swapped my ralink (rt2560f) card to an atheros (cant remember the exact chipset but same tp-link card that many has been using). All my problems went away! So it seems that my problems were with the ralink drivers.
-
There is definatly something hardware specific going on here.
I had my 1.2.3 working at home with only intermittent problems connecting with wireless (dhcp problem as others specified). With a later version of 1.2.3 this did not happen often and a reboot fixed it.
On upgrading the ALix board from the old firewall 2D1 to the slightly more powerful 2D3 no matter how many reboots given Wireless would not hand out DHCP. This was done using the same flash card so config and OS was identical. I also tried rolling back and forward and while i didnt try all versions of 1.2.3 RC-1 released none of them worked.
There is something hardware specific about this.
-
-
Currently at home the ALix 2D3 which is similar to the 2D1 but includes USB ports, 256mb of memory rather than 128 and slightly higher clockspeed.
-
What about your wireless hardware? Is it the same as what you were using in the 2D1?
-
Yup Its an Atheros (same card all the time) : Heres info got from 1.2.2 currently running on it. ( Loads of In / Out errors but working. )
"dmesg | grep ath"
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
ath0: <atheros 5212="">mem 0xe00c0000-0xe00cffff irq 9 at device 12.0 on pci0
ath0: [ITHREAD]
ath0: using obsoleted if_watchdog interface
ath0: mac 10.5 phy 6.1 radio 6.3</atheros> -
i also have the atheros card and doesnt work on 1.2.3, not that it doesnt work at all but doesnt give out ip using dhcp, if ip is set in clients to manual then atleast it communicates. i tried everything
-
Yeah i'd like to add that while the DHCP doesnt work with wireless the actual wireless card is working properly for the first time with no interface in / out errors ect. All previous versions always left me with In / Out errors.
-
DHCP works fine on my atheros NIC.
Here's the kernel I'm running
uname -a
FreeBSD pfsense.example.org 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #0: Mon Apr 13 15:59:41 EDT 2009 sullrich@RELENG_1_2-snapshots.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense.7 i386
Here's how my interface is reported in the startup:
dmesg | grep ath
ath0: <atheros 5212="">mem 0xee000000-0xee00ffff irq 12 at device 8.0 on pci0
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:19:e0:xx:xx:xx
ath0: mac 7.9 phy 4.5 radio 5.6</atheros>Your atheros is a more recent revision than mine?
-
i go the below atheros card working with the march release but not the latest one
$ dmesg | grep ath ath0: <atheros 5413="">mem 0xe00c0000-0xe00cffff irq 9 at device 12.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: xx:xx:xx:xx:xx:xx ath0: mac 10.5 phy 6.1 radio 6.3 ath0: promiscuous mode enabled</atheros>
-
any1 tested the latest snapshots for wireless functionality?
-
I've updated yesterday from original rc1 release to the May 12th one. release from May 14th wouldn't event boot on my Alix 0_o.
After update wireless (bridged to LAN) went down and my laptop was showing limited or no connectivity message.
I had to kill the wireless interface and assigned it again. That fixed it and it works OK.
oh, and I'm running alix with atheros 5212. -
the snapshot server was down till now and now that its up, i tried the 18th may 7.1 base, 7.2 base of freebsd and m having same issues, wireless not get IP from DHCP when bridged with LAN, the second issue i saw with both the bsd versions of 1.2.3 was in system log there was an error saying couldn't not get the MTU of ath0 so using 1500 but then it couldn't bridge with LAN due to that wireless not being able to set its MTU value so the next line it said the same but now for vr1 which is the LAN interface
-
I also have bridging issues with the original 1.2.3RC1 build.
In my case if I only set bridging in the wireless interface it doesn't work (I don't use dhcp though and assign static ip's).
However if I set the bridging from the lan interface too it starts working!
This is annoying but I suppose I can live with that. -
I was having that same MTU issue as xbipin, mtu to the bridge interface was not set at 1500 when i ran the ifconfig command.
Using the below commands fixed it for me on my Alix 2c2
ifconfig vr0 mtu 1500
ifconfig ath0 mtu 1500
ifconfig bridge0 destroy
ifconfig bridge create -
I also have bridging issues with the original 1.2.3RC1 build.
In my case if I only set bridging in the wireless interface it doesn't work (I don't use dhcp though and assign static ip's).
However if I set the bridging from the lan interface too it starts working!
This is annoying but I suppose I can live with that.do u mean to say LAN bridged to WAN works but wireless bridged to LAN doesnt?
-
No,
What I am saying , it matters in which interface I set the bridging.
If I set the bridging in wireless interface (ath0 to lan) it doesn't work.
If I go to lan's interface and set there to bridget to ath0 then it works.
The thing is , this setting is not retained after reboot and I have to repeat this procedure everytime I want to reboot.
I also get the error message about wrong mtu when bridging but strangely enough the bridge works fine afterwards. -
i tried the following release
1.2.3-RC1
built on Sat May 23 03:47:37 EDT 2009and still sad coz wireless bridged to LAN and wireless clients dont get ip address from DHCP running on LAN interface