Don't know if anyone reads these or if there is an active maintainer for this but here it goes:
I am currently running 2.6.29.4 kernel with staging et131x compiled into the kernel (not as a module). I tested my et131x box as a gateway with a few VLANs (tagged and untagged).
The driver seems to work just fine as untagged VLAN link (eth0). When I use the tagged link (let's say eth0.3) as the inside interface small packets like ping and dns work ok but I am having problems with tcp connections. To me this seems to be the "classic" MTU TCP MSS problem. When I set MTU of the et131x tagged link (eth0.3) to 1496 and do TCPMSS mangling (set-mss 1456) in iptables the box works as a gateway also for TCP connections.
I also tested the same box with a cheap 8139 card and it worked perfectly without any MTU adjusting or iptables mangling.
Can anyone else confirm this issue and can I provide some more info to help fix this?
--
Jaakko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the cause for your problem is just the staging quality driver. I assume you have faced what I have seen several time with et131x driver:
Your network seems to work just ok and suddenly all traffic stops and after a while you start getting these watchdog timeouts.
I have tested using my box with et131x with high speed traffic (in terms of PPS not necessarily high BPS) and every time it seems to fail within a few hours and I get similar log. At least for now I don't use this NIC&driver anymore.
I don't believe changing MTU or doing TCP MSS mangling will help you here. I believe my original problem is only related to VLAN tagging but since you asked:
Set MTU in /etc/network/interfaces (I assume you are using Debian alike):
iface eth4 inet static
address 192.168.0.1
netmask 255.255.255.0
mtu 1496
then do ifdown eth4; ifup eth4
You can do TCP MSS mangling like this:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -i eth4 -s 192.168.0.1/24 -j TCPMSS --set-mss 1456
--
Jaakko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am afraid so but it could be a long time before these are fixed, if ever. Of course you could try finding an active developer somewhere. Maybe you have already seen, there has been some coding style changes for this driver in
Of course these changes won't fix these issues but it's nice to see that something is happening. If you are using your box as a router/firewall you might have better luck with OpenBSD, for example pfSense.
--
Jaakko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't know if anyone reads these or if there is an active maintainer for this but here it goes:
I am currently running 2.6.29.4 kernel with staging et131x compiled into the kernel (not as a module). I tested my et131x box as a gateway with a few VLANs (tagged and untagged).
The driver seems to work just fine as untagged VLAN link (eth0). When I use the tagged link (let's say eth0.3) as the inside interface small packets like ping and dns work ok but I am having problems with tcp connections. To me this seems to be the "classic" MTU TCP MSS problem. When I set MTU of the et131x tagged link (eth0.3) to 1496 and do TCPMSS mangling (set-mss 1456) in iptables the box works as a gateway also for TCP connections.
I also tested the same box with a cheap 8139 card and it worked perfectly without any MTU adjusting or iptables mangling.
Can anyone else confirm this issue and can I provide some more info to help fix this?
--
Jaakko
Hi Jaakko,
could this be the cause for my problem (see kernel-log-snapshot) ?
How do I adjust MTU to 1496 and TCPMSS to 1456 ?
My devices are eth4 and eth5
THX
Jul 15 18:27:14 deb2009 kernel: [ 271.820645] ------------[ cut here ]------------
Jul 15 18:27:14 deb2009 kernel: [ 271.820708] WARNING: at kernel/irq/manage.c:441 free_irq+0x27/0xcb()
Jul 15 18:27:14 deb2009 kernel: [ 271.820774] Modules linked in: xt_length iptable_mangle xt_MARK cls_fw sch_htb xt_multiport ipt_LOG xt_tcpudp xt_state iptable_filter nf_nat_irc nf_nat_ftp iptable_nat nf_nat nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack ip_tables x_tables ipv6 dm_snapshot dm_mirror dm_log dm_mod loop et131x(P) sd_mod serio_raw psmouse snd_pcm snd_timer i2c_viapro snd soundcore snd_page_alloc i2c_core pcspkr shpchp pci_hotplug via_agp agpgart evdev ext2 mbcache usb_storage ide_disk sata_via ata_generic libata uhci_hcd ehci_hcd scsi_mod dock via82cxxx ide_pci_generic usbcore ide_core 8139too 8139cp mii thermal_sys
Jul 15 18:27:14 deb2009 kernel: [ 271.824378] Pid: 0, comm: swapper Tainted: P 2.6.26-2-486 #1
Jul 15 18:27:14 deb2009 kernel: [ 271.824452] [<c011bac4>] warn_on_slowpath+0x40/0x65
Jul 15 18:27:14 deb2009 kernel: [ 271.824662] [<c011c435>] printk+0x14/0x18
Jul 15 18:27:14 deb2009 kernel: [ 271.824776] [<de9778ee>] DumpDeviceBlock+0xb9/0xca [et131x]
Jul 15 18:27:14 deb2009 kernel: [ 271.824923] [<c0146cec>] free_irq+0x27/0xcb
Jul 15 18:27:14 deb2009 kernel: [ 271.825038] [<de976830>] et131x_close+0x8d/0xd1 [et131x]
Jul 15 18:27:14 deb2009 kernel: [ 271.825164] [<de977074>] et131x_tx_timeout+0x240/0x261 [et131x]
Jul 15 18:27:14 deb2009 kernel: [ 271.825372] [<c025d936>] dev_watchdog+0x0/0xc3
Jul 15 18:27:14 deb2009 kernel: [ 271.825481] [<c025d99c>] dev_watchdog+0x66/0xc3
Jul 15 18:27:14 deb2009 kernel: [ 271.825594] [<c0122025>] run_timer_softirq+0x10e/0x169
Jul 15 18:27:14 deb2009 kernel: [ 271.825709] [<c025d936>] dev_watchdog+0x0/0xc3
Jul 15 18:27:14 deb2009 kernel: [ 271.825831] [<c011f44d>] __do_softirq+0x3e/0x87
Jul 15 18:27:14 deb2009 kernel: [ 271.825945] [<c011f4cb>] do_softirq+0x35/0x43
Jul 15 18:27:14 deb2009 kernel: [ 271.826055] [<c011f7a1>] irq_exit+0x25/0x53
Jul 15 18:27:14 deb2009 kernel: [ 271.826161] [<c010e386>] smp_apic_timer_interrupt+0x59/0x61
Jul 15 18:27:14 deb2009 kernel: [ 271.826278] [<c01025ed>] default_idle+0x0/0x4e
Jul 15 18:27:14 deb2009 kernel: [ 271.826386] [<c0104798>] apic_timer_interrupt+0x28/0x30
Jul 15 18:27:14 deb2009 kernel: [ 271.826496] [<c01025ed>] default_idle+0x0/0x4e
Jul 15 18:27:14 deb2009 kernel: [ 271.826622] [<c0112b58>] native_safe_halt+0x2/0x3
Jul 15 18:27:14 deb2009 kernel: [ 271.826739] [<c0102615>] default_idle+0x28/0x4e
Jul 15 18:27:14 deb2009 kernel: [ 271.826845] [<c010256d>] cpu_idle+0x51/0x6a
Jul 15 18:27:14 deb2009 kernel: [ 271.826961] =======================
Jul 15 18:27:14 deb2009 kernel: [ 271.827022] ---[ end trace 39b52a87acce8f34 ]---
Hello Peter,
I think the cause for your problem is just the staging quality driver. I assume you have faced what I have seen several time with et131x driver:
Your network seems to work just ok and suddenly all traffic stops and after a while you start getting these watchdog timeouts.
I have tested using my box with et131x with high speed traffic (in terms of PPS not necessarily high BPS) and every time it seems to fail within a few hours and I get similar log. At least for now I don't use this NIC&driver anymore.
I don't believe changing MTU or doing TCP MSS mangling will help you here. I believe my original problem is only related to VLAN tagging but since you asked:
Set MTU in /etc/network/interfaces (I assume you are using Debian alike):
iface eth4 inet static
address 192.168.0.1
netmask 255.255.255.0
mtu 1496
then do ifdown eth4; ifup eth4
You can do TCP MSS mangling like this:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -i eth4 -s 192.168.0.1/24 -j TCPMSS --set-mss 1456
--
Jaakko
Hi Jaakko ,
thanks!
My box
http://linitx.com/viewproduct.php?prodid=11714
has 2xGigaLAN et131x ports and I like to use it for file copy procedures.
So I have to wait for a bugles driver version?
THX
Hi Peter,
I am afraid so but it could be a long time before these are fixed, if ever. Of course you could try finding an active developer somewhere. Maybe you have already seen, there has been some coding style changes for this driver in
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/staging/
Of course these changes won't fix these issues but it's nice to see that something is happening. If you are using your box as a router/firewall you might have better luck with OpenBSD, for example pfSense.
--
Jaakko