Bug 187145

Summary:	Netfilter won't pass packets over 2040 bytes
Product:	[Fedora] Fedora	Reporter:	Ade Rixon <ade.rixon>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5	CC:	wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-10-19 18:37:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ade Rixon 2006-03-28 19:41:21 UTC

Description of problem:
System configured as dual-homed NAT router to Internet with firewalling.
With iptables (netfilter) enabled, it can't process received IP packets over
2040 bytes on the LAN interface. Unloading netfilter allows it to work again.
The interface is a VIA-Rhine. My Internet interface (a 3c59x) is unaffected.

Version-Release number of selected component (if applicable):
2.6.15-1.2054_FC5
Also found with 2.6.16-1.2069_FC5 and 2.6.15-1.1833_FC4

How reproducible:
Send pings of 2012 and 2013 bytes to remote server on LAN. Unload iptables
(service iptables stop) to remove problem.

Steps to Reproduce:
1. ping -s 2012 local_ip - works
2. ping -s 2013 local_ip - fails, no packets
3. service iptables stop
4. ping -s 2013 local_ip - works
  
Actual results:
]# ping -s 2012 -c 3 bart
PING bart.foo.org.uk (XXX.XXX.XXX.XXX) 2012(2040) bytes of data.
...
--- bart.foo.org.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.750/0.755/0.763/0.023 ms

# ping -s 2013 -c 3 bart
PING bart.foo.org.uk (XXX.XXX.XXX.XXX) 2013(2041) bytes of data.

--- bart.foo.org.uk ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2012ms


Expected results:
Pings should work for all valid packet sizes.

Additional info:
System was working normally with FC3 until upgraded to FC5.
Tcpdump shows the incoming fragmented echo-reply packets, but they are never
received by ping. Problem affects all protocols, including ICMP echo, NFS
(udp/tcp) and SSH. mii-tool reports 100Mb/s full duplex.
lspci for both NICs:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
	Subsystem: ASUSTeK Computer Inc. A7V8X-X Motherboard
	Flags: bus master, stepping, medium devsel, latency 32, IRQ 11
	I/O ports at b000 [size=256]
	Memory at ec800000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [40] Power Management version 2
00:0e.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
	Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
	Flags: bus master, medium devsel, latency 32, IRQ 3
	I/O ports at d800 [size=128]
	Memory at ed800000 (32-bit, non-prefetchable) [size=128]
	[virtual] Expansion ROM at 50000000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2

Comment 1 Ade Rixon 2006-03-29 08:41:56 UTC

Further to the above: I get the problem even if there are no iptables rules;
just having the module loaded is sufficient.

Networking works correctly if I use the rhinefet driver from www.viaarena.com
instead of via-rhine.

Comment 2 Ade Rixon 2006-03-31 10:54:48 UTC

Narrowing it down further, everything works regardless of driver if I bring down
the interface, unload then reload the driver and bring up the interface *after*
netfilter has loaded.

Comment 3 Dave Jones 2006-10-16 19:06:47 UTC

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 4 Ade Rixon 2006-10-19 18:37:29 UTC

Skip it - the FC5 upgrade swapped the naming of eth0/1 for my NICs and so
bandwidth limiting (with wondershaper) was being applied to the internal
interface instead of the external one. This broke ping.