Latest snapsot wireless bridged as well as static not working
-
…as soon as firewall is rebooted and then when wireless comes online, clients get connected and get an ip also from dhcp but wont be able to surf till the older workaround is performed...
hm… looks like I have exactly the same symptoms. As I posted above, after reboot everything seems to be OK but no traffic goes through on wireless. I can't connect to the router or surf internet, but I can connect to my desktop, which is on the same LAN, using vnc no problem.
So, those errors that I'm getting in the firewall during reboot are not to blame... -
Can confirm that, on reboot with the 0609-2221 7.2 embedded build, I am also seeing no traffic over WiFi until the 'save config' fix. Having said that, once the WiFi fix is 'applied' I am having no other problems: I am able to saturate My WAN connection (10Mbit) with only 20% CPU usage, and latency to My VoIP provider is running at a steady 10-11ms. These figures are pretty much the same as for previous 7.1 builds, so it does not look like I am suffering the same performance problems as xbipin when running 7.2 based builds…
Jason.pfSense image:
1.2.3-RC2 built on Tue Jun 9 21:29:11 EDT 2009 (pfSense-1.2.3-20090609-2221.img.gz embedded freeBSD 7.2)
Hardware:
Alix 2c3 BIOS 0.99h
Atheros 5212 based miniPCI card (Wistron CM9) -
its not that i cant use my complete wan bandwidth but the performance issue is when say u open multiple sites, most new ones that u havent opened that day or say for an hour or so, the initial connection to the site takes a slight bit longer, then again if u open up then it opens quick and even if u reload the page as fresh. i have kept my firewall on aggressive so mayb the reconnection of sites is a bit slower than the 7.1 base for some reason and also if there r no packets going through to WAN then sites take even longer to open and my network card blinks constantly as if still data is to be downloaded even if i load google which takes less than a second in normal cases and if i open up the pfsense site, take almost more than 15secs, i tried reconnecting to my WAN etc but still the same and then when i reverted back to 7.1, it got blazing fast again.
-
xbipin,
Have just tried running My pfsense box with state table optimisation set to 'agressive'. Not noticed a massive slowdown, but CPU usage increased to 12% (from 2% when set to 'normal') while handling normal background WAN traffic (approx 200Kbit/s) and responsiveness of pfSense web interface seemed slower (could see page redraws). NB I'm on a very low latency Internet connection so re-establishing dropped TCP sessions is not so much of a hit, but I could see you having problems on a higher latency connection. I seem to remember reading on here somewhere the advice to run state table optimisation 'normal' unless you have a good reason to set it otherwise (I'm sure someone will hop on here and correct me or give further explaination though!).
NB2: changing the state table optimisation setting appears to break WiFi, requiring the 'save' fix to get it back again.
Jason.
pfSense image:
1.2.3-RC2 built on Tue Jun 9 21:29:11 EDT 2009 (pfSense-1.2.3-20090609-2221.img.gz embedded freeBSD 7.2)
Hardware:
Alix 2c3 BIOS 0.99h
Atheros 5212 based miniPCI card (Wistron CM9) -
just a while ago i tried pfSense-1.2.3-20090611-2116.img.gz but seems pppoe is broken so i tried pfSense-1.2.3-20090610-2204.img.gz and that works now and the internet slowness issue i had is gone all of a sudden but now the wireless, having proper MTU values also wont start and give ips to wireless clients, the save button click work around also doesnt seem to work now, let me mention that i have changed my wireless card to Compex WLM54AGP23 with the atheros 5413 chipset
sorry but wireless is fine but actually the restore section isnt working so it didnt import the firewall rules and that was the issue and i guess its still broken, gives some xml error
-
Well, after a nearby lightening strike last night, I no longer have a working ALIX router >:( The strike took out My cable modem and fried the WAN port of the ALIX box. Interestingly I can still attach to ALIX via serial port and pfSense boots, but boot sequence does not even report existence of WAN interface, and once booted pfSense cannot pass traffic over 2 remaining ports (not surprising I guess as there was the distinctive smell of burnt chips after the strike suggesting that the damage was probably extensive!).
I'll probably spin up an old PC with pfSense as a stop-gap until I can source another ALIX board (anyone selling?), so unfortunately no more embedded testing for now…
Jason.
pfSense image:
1.2.3-RC2 built on Tue Jun 9 21:29:11 EDT 2009 (pfSense-1.2.3-20090609-2221.img.gz embedded freeBSD 7.2)
Hardware:
Alix 2c3 BIOS 0.99htoast :(
Atheros 5212 based miniPCI card (Wistron CM9) waiting for a new home…...... -
here is something else that I haven't seen before…
wireless completely unusable if it's set to turbo g/channel 6. Away from the router I get only 1Mbs/Low, when if I switch to channel 10 or 9 I get 54Mbps/Good
I've never seen this issue before I switched to 1.2.3 7.2 based :-\ -
pfsense and freebsd shows my wireless card as atheros 5413 chipset whereas its a Atheros 5414, i just removed the metal shield off the card and checked and maybe because of that wireless might be having issues as 5414 isnt listed in freebsd 7.1 or 7.2 hardware list
-
Just installed snapshot from 16th , but still need to use the save button fix in lan interface setup.
-
Just installed snapshot from 16th , but still need to use the save button fix in lan interface setup.
that issue still remains but not that worse compared to the older version
-
Its not worse but still somewhat annoying :)
The thing more concerning to me is the stuck beacon issues which returned today (right before the upgrade) and actually were the reason for it.
I thought it was finally over after I had 17 days uptime but alas this problem also persists. -
For those who need to use the save button after reboot still, try this instead after a reboot:
ifconfig vr0 -txcsum
(or whatever your wired bridged interface is)
That seems to clear it up for me. I'm working out how best to patch it for good though.
For whatever reason when you set the bridge up again by clicking save, txcsum is off, but it's on at boot, and it apparently interferes with bridging.
-
For those who need to use the save button after reboot still, try this instead after a reboot:
ifconfig vr0 -txcsum
(or whatever your wired bridged interface is)
That seems to clear it up for me. I'm working out how best to patch it for good though.
For whatever reason when you set the bridge up again by clicking save, txcsum is off, but it's on at boot, and it apparently interferes with bridging.
This fixed it for me too! 8)
-
Thanks, I will check it next time I need to reboot :)
-
@spock:
ifconfig vr0 -txcsum
This fixed it for me too! 8)
What hardware are you using? ALIX? It would help to know the wireless driver and ethernet driver you are using. For me, it's ath0 and vr0.
-
@spock:
ifconfig vr0 -txcsum
This fixed it for me too! 8)
What hardware are you using? ALIX? It would help to know the wireless driver and ethernet driver you are using. For me, it's ath0 and vr0.
It's an alix2c3. bridge0 contains vr0 and ath0, just like yours.
The problem for me was that whenever I did a cold or warm reboot of the alix, wireless clients would get an IP, they could communicate with other hosts on either LAN or WLAN, but not with the alix box itself (which also meant no internet access). I solved this by going into the options of the wireless interface and pressing save after each reboot, and it would all work again.
Now I have tried with 2 reboots, and running 'ifconfig vr0 -txcsum' have had the same effect as pressing save in interface options, it all worked like a charm again!
I'm currently running pfSense-1.2.3-512mb-20090917-0347-nanobsd, but this problem has been around for quite some time for me.
-
I'm also on ALIX (2d3) and had the same symptoms.
Not the first time I've heard of checksum offloading causing issues… Apparently it's not a universal problem though, so it's hard to tell which circumstances will call for turning it off.
-
Alternately, I suppose you could also just check the "Disable Hardware Checksum Offloading" option, which would have the same effect.
Not sure how that might impact the ALIX overall, if at all, but if it is problematic it might be better to leave it off anyhow.
