From: Richard Braun <syn@sceen.net>
To: sparclinux@vger.kernel.org
Subject: Checksum problem on sparc64
Date: Thu, 23 Mar 2006 22:35:10 +0000 [thread overview]
Message-ID: <20060323223510.GA7683@sceen.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]
Hello,
I'm using kernel 2.6.15.6 on my Ultra1 (vanilla kernel without modification).
My network setup is a bit weird since I'm using a PPPoE link with MTU 1400 (I
have packet losses if using a higher MTU because of the link quality). My NAT
router is a 2.6.15.6 kernel too running on i386. The problems I experience
were already present when I used 2.6.12.6 kernel. Now here is the problem :
I have a SSH server on my sparc64 box, and port 22 on the public interface
is redirected to that host. When downloading with sftp for example, everything
runs fine until some point. Using tcpdump to discover what was going on,
I captured these packets (on public interface) :
13:14:30.359867 > 0800 1416: IP (tos 0x8, ttl 63, id 26858, offset 0, flags
[DF], length: 1400) 213.41.243.68.22 > 84.96.34.158.59002: . [tcp sum ok]
3703221:3704569(1348) ack 9968 win 6788 <nop,nop,timestamp 34000986 1795720>
13:14:30.397874 > 0800 1416: IP (tos 0x8, ttl 63, id 26859, offset 0, flags
[DF], length: 1400) 10.0.0.2.22 > 84.96.34.158.59002: . [bad tcp cksum 696d
(->696c)!] 3016044:3017392(1348) ack 7729 win 6788 <nop,nop,timestamp 34000990
1795720>
Packets were similar on the LAN interface with the exception of NAT for the
first packet :
13:14:30.359816 08:00:20:86:c9:98 > 00:90:27:71:ed:ae, ethertype IPv4 (0x0800),
length 1414: IP (tos 0x8, ttl 64, id 26858, offset 0, flags [DF], length:
1400) 10.0.0.2.22 > 84.96.34.158.59002: . [tcp sum ok] 3703221:3704569(1348)
ack 9872 win 6788 <nop,nop,timestamp 34000986 1795720>
13:14:30.397818 08:00:20:86:c9:98 > 00:90:27:71:ed:ae, ethertype IPv4 (0x0800),
length 1414: IP (tos 0x8, ttl 64, id 26859, offset 0, flags [DF], length:
1400) 10.0.0.2.22 > 84.96.34.158.59002: . [bad tcp cksum 696d (->696c)!]
3643729:3645077(1348) ack 9872 win 6788 <nop,nop,timestamp 34000990 1795720>
I'm not sure why the tcp checksum is bad. It could be a hardware problem or
a kernel bug. Therefore I decided to report this. I think I have similar
problems with IPv6, but I have not investigated yet. The problem looks quite
random for now, but I can easily reproduce it (I begin a download over sftp,
wait a few seconds/minutes, then the rate drops).
Hope it helps (and sorry for previous private queries btw).
--
Richard Braun
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2006-03-23 22:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 22:35 Richard Braun [this message]
2006-06-04 5:52 ` Checksum problem on sparc64 Richard Braun
2006-06-04 14:32 ` Samuel Thibault
2006-06-04 14:34 ` Samuel Thibault
2006-06-05 4:05 ` David Miller
2006-06-05 4:32 ` David Miller
2006-06-05 12:05 ` Richard Braun
2006-06-05 18:19 ` David Miller
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=20060323223510.GA7683@sceen.net \
--to=syn@sceen.net \
--cc=sparclinux@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.