From: Russell King <rmk@arm.linux.org.uk>
To: netdev@vger.kernel.org
Subject: 2.6.25: Weird IPv4 stack behaviour, IPv6 is fine
Date: Mon, 28 Apr 2008 00:14:11 +0100 [thread overview]
Message-ID: <20080427231411.GA5261@flint.arm.linux.org.uk> (raw)
Hi,
I've upgraded lists.arm.linux.org.uk to 2.6.25, and I'm now seeing some
very weird networking behaviour from the machine which seems to only
affect IPv4 - including ICMP and NFS(tcp).
tcpdump is available (all 4MB worth):
http://www.home.arm.linux.org.uk/~rmk/ping.capture
Machines involved:
dyn-67 - x86 box 2.6.20-1.2320.fc5
(192.168.0.67 / 2002:4e20:1eda:1:201:80ff:fe4b:1778)
n2100 - ARM box 2.6.24
(78.32.30.221, has ipv6 as well)
lists - ARM box 2.6.25
(78.32.30.220 / 2002:4e20:1eda:1:201:3dff:fe00:0156)
The dump shows three 8200 byte pings running - one IPv4 on n2100 against
lists, one IPv4 on dyn-67 against lists, and one IPv6 on dyn-67 against
lists.
The tcpdump was running on lists itself.
Everything looks fine until around packet 1688, where n2100 sends an
echo request to lists, which doesn't get a reply. 300ms later, dyn-67
sends an echo request to lists, which also coincidentally doesn't get
a reply. Note, however, how the IPv6 pings continue.
The stats for the pings upon their termination are:
rmk@dyn-67:[~]:<1005> ping6 -s 8192 lists
PING lists(lists.arm.linux.org.uk) 8192 data bytes
--- lists ping statistics ---
101 packets transmitted, 101 received, 0% packet loss, time 99990ms
rtt min/avg/max/mdev = 4.132/4.488/26.585/2.374 ms, pipe 2
rmk@dyn-67:[~]:<1051> ping -s 8192 lists
PING lists.arm.linux.org.uk (78.32.30.220) 8192(8220) bytes of data.
--- lists.arm.linux.org.uk ping statistics ---
101 packets transmitted, 54 received, 46% packet loss, time 99993ms
rtt min/avg/max/mdev = 4.139/6.027/35.274/6.405 ms
root@n2100:~# ping -s 8192 lists
PING lists.arm.linux.org.uk (78.32.30.220) 8192(8220) bytes of data.
--- lists.arm.linux.org.uk ping statistics ---
101 packets transmitted, 55 received, 45% packet loss, time 100020ms
rtt min/avg/max/mdev = 4.404/4.610/13.235/1.175 ms
Lastly, in /proc/net/snmp on lists, I find:
Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates
Ip: 2 64 12771 0 0 0 0 0 5159 6262 9 0 2 8172 1363 2 922 0 5520
Note - InReceives = 12771, but InDelivers = 5159 - so roughly 50% of
IPv4 packets were received but not delivered, which appears to tie up
with the ping statistics.
Not sure what to make of this at the moment. Any ideas?
--
Russell King
next reply other threads:[~2008-04-27 23:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-27 23:14 Russell King [this message]
2008-04-27 23:17 ` 2.6.25: Weird IPv4 stack behaviour, IPv6 is fine Russell King
2008-04-27 23:26 ` David Miller
2008-04-28 7:02 ` Pavel Emelyanov
2008-04-28 9:31 ` Russell King
2008-04-28 10:18 ` Russell King
2008-04-28 10:30 ` David Miller
2008-04-28 12:00 ` Russell King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080427231411.GA5261@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.