Bug #88
closed
TXCSUM forced on at boot which breaks wireless bridging
100%
Description
When you have a wireless interface bridged to a wired interface, txcsum needs to be disabled on the wired NIC in order for it to properly pass out traffic for non-local hosts across the bridge. It seems to contact the pfsense box itself OK, but nothing beyond.
On boot, txcsum is being forced on (Lines 939-942 of etc/inc/pfsense-utils.inc) which breaks the bridge at boot. Once the system is fully booted, you can go to Interfaces > OPT1 (or whatever the wireless interface is), then click Apply, and once the bridge is set back up, txcsum is disabled on the card.
I tried explicitly setting -txcsum in the code for the bridge setup, but apparently the code from pfsense-utils.inc happens after that point since it seemed to have no effect. Only when I commented out the above mentioned lines in pfsense-utils.inc was I able to get a working bridge on reboot.
Not sure if that check in pfsense-utils.inc needs to be "bridge-aware" or if it's even really necessary.
How to reproduce:
Add ath0 as an OPT, enable, bridge to LAN, add firewall rules, and reboot. Bridge doesn't work. Check ifconfig output, txcsum is present. Either Apply on the interface config page or run "ifconfig <LAN int> -txcsum", bridge works.
Updated by Chris Buechler over 15 years ago
This is not universally true, there are instances I know of where this works fine, including my own AP. Maybe driver-specific? Or specific to some other circumstance?
Updated by Jim Pingle over 15 years ago
We may need to find out what other hardware people are using then, it is a problem with vr0+ath0 at least. Not sure when it started either.
There is one other report of turning off txcsum helping:
http://forum.pfsense.org/index.php/topic,15468.msg98911.html#msg98911
Updated by Chris Buechler about 15 years ago
- Target version changed from 1.2.3 to 2.0
- Affected Version changed from 1.2.3 to 2.0
Fixed in 1_2.
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/369fb26331d05781e42835776c8c31105f57399c
Leaving open for 2.0, and did not commit this to mainline, as we need to revisit on FreeBSD 8. This appears to be vr(4) specific, and may no longer be an issue in 8.
Updated by Jim Pingle about 15 years ago
That patch won't help at boot, unfortunately. The bridge is setup and that code is evaluated before the settings check for Enable/Disable hardware checksums (Lines 939-942 of etc/inc/pfsense-utils.inc). If hardware checksums are not disabled, they are forced on by enable_hardware_offloading().
If you reinitialize the bridge after boot, the checksums were already turned off, even without being explicitly turned off.
Updated by Chris Buechler about 15 years ago
additional commit to fix at boot time.
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/19ee38b4c955b0ab5702bd9fd76f1e547708bac8
Updated by Jim Pingle about 15 years ago
Looks like that last patch may have had some unintended side effects on vlans:
Updated by Chris Buechler about 15 years ago
At a glance it looked like it just made a different bug apparent where VLANs shouldn't have that set, but that code actually does properly skip VLANs. The errors came from interfaces_vlan_configure which wasn't touched, and I'm not sure how that change made it start spitting its errors out onto the console, but it's fixed now.
Updated by Ben Eisenbraun about 15 years ago
I have this problem running on an Alix2d2 with an Atheros card, so it's also a vr0+ath0 combo. 'ifconfig vr0 -txcsum' resolves the problem.
It looks like they are disabling txcsum on m0n0 in some situations due to the same issue:
http://forum.m0n0.ch/index.php?topic=1476.0;wap2
Updated by Chris Buechler about 15 years ago
- Status changed from New to Resolved
It appears the driver bug that necessitated this change in RELENG_1_2 is no longer an issue in FreeBSD 8.0, so no need to apply this change in mainline.
Updated by Chris Buechler over 14 years ago
- Status changed from Resolved to New
- Priority changed from High to Normal
Now appears to be an issue in 8.1 with some bridging scenarios and vr NICs. Probably need the same fix from 1_2 applied.
Updated by Erik Fonnesbeck over 14 years ago
It might not be affected by this when the bridge has the IP address and the members have no IP addresses. That is my configuration and TXCSUM is on and not causing problems.
Updated by Dainel Spisak over 14 years ago
I am experiencing this problem under Pfsense 2.0 Mon May 24 01:39:17 EDT 2010 on my ALIX2c3. This worked correctly under 1.2.3-release for me. Under 2.0 if I go and reapply my WLAN interface settings TXCSUM is still set. But if I delete Bridge0 and recreate the WLAN <-> LAN bridge TXCSUM does get removed from my vr0 interface properly and WiFi traffic will start to work again.
Updated by Lars Hupfeldt Nielsen over 14 years ago
I have the same problem. running on ALIX with atheros based card. ifconfig vr0 -txcsum solves problem.
Updated by Lars Hupfeldt Nielsen over 14 years ago
2.0-BETA3
built on Thu Jun 17 13:50:57 EDT 2010
FreeBSD pfsense2.hupfeldt 8.1-RC1 FreeBSD 8.1-RC1 #0: Thu Jun 17 13:49:55 EDT 2010 root@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 i386
Updated by Chris Buechler over 14 years ago
- Category changed from Operating System to Interfaces
- Status changed from Feedback to New
This still isn't properly disabling txcsum. Ermal, you can see it on 10.0.64.180.
Updated by Ermal Luçi over 14 years ago
- Status changed from New to Feedback
It should work on latest snapshot.
Updated by Ermal Luçi over 14 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 51d5aad75a0a88034b49db3d867e8a1e49fe2f12.
Updated by Chris Buechler almost 14 years ago
- Status changed from Feedback to Resolved