From: Patrick McHardy <kaber@trash.net>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>,
netdev@vger.kernel.org,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>,
Marc Lehmann <schmorp@schmorp.de>
Subject: Re: masquerading failure for at least icmp and tcp+sack on amd64
Date: Wed, 14 Sep 2005 03:10:38 +0200 [thread overview]
Message-ID: <4327788E.8030708@trash.net> (raw)
In-Reply-To: <20050913110902.0ad58b90@localhost.localdomain>
Stephen Hemminger wrote:
> Some background, the semantic of ip_summed is different on the
> output than the input path. On input, it means a checksum is
> available in skb->csum; and on output it means the packet is
> destined for a device that can do hardware checksumming.
Yep, so far the netfilter code should be correct since my batch
of HW checksum fixes.
> I have gotten reports of receive checksum errors on
> some systems, it may be related to certain revisions of
> hardware. It would be useful to see the message printed out
> by the skge driver that shows chip and revision.
That may be the reason. I've audited most relevant code-paths
for this case and they seem to be mostly OK. There are a couple
of cases in the ppp code I'm not sure about yet, but I couldn't
trigger any errors in my test-setup. Anyway they don't seem to
be related to this problem since it also happens with sk98_lin
which doesn't set CHECKSUM_HW.
> Also, on the input path for TCP and UDP, the code does not
> depend on the hardware being correct, and if the checksum
> is incorrect, it just prints a warning and does a software
> checksum before deciding to drop.
> Perhaps netfilter code needs to handle that case?
Yes, this is not handled so far. But is looks like there is
some other problem because it also happens with sk98_lin.
Thanks for your help Stephen.
next prev parent reply other threads:[~2005-09-14 1:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050907052057.09714a4c.akpm@osdl.org>
2005-09-07 12:39 ` Fw: masquerading failure for at least icmp and tcp+sack on amd64 Patrick McHardy
2005-09-07 20:59 ` Marc Lehmann
2005-09-07 21:34 ` Patrick McHardy
2005-09-07 21:52 ` Marc Lehmann
2005-09-09 11:41 ` Patrick McHardy
2005-09-11 13:19 ` Marc Lehmann
2005-09-11 14:10 ` Patrick McHardy
2005-09-13 18:09 ` Stephen Hemminger
2005-09-13 20:59 ` David S. Miller
2005-09-14 1:13 ` Patrick McHardy
2005-09-14 3:41 ` David S. Miller
2005-09-14 1:10 ` Patrick McHardy [this message]
2005-09-14 19:09 ` Fw: " Marc Lehmann
2005-09-07 21:34 ` Marc Lehmann
2005-09-07 21:42 ` Patrick McHardy
2005-09-07 21:54 ` Marc Lehmann
2005-09-07 22:08 ` Patrick McHardy
2005-09-06 17:29 Marc Lehmann
2005-09-07 12:44 ` Marc Lehmann
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=4327788E.8030708@trash.net \
--to=kaber@trash.net \
--cc=akpm@osdl.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=schmorp@schmorp.de \
--cc=shemminger@osdl.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.