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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).