All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: IPv6-UDP 0x0000 checksum
Date: Thu, 26 Jan 2017 14:49:06 +0100	[thread overview]
Message-ID: <1485438546.14760.7.camel@sipsolutions.net> (raw)
In-Reply-To: <1485438299.5145.117.camel@edumazet-glaptop3.roam.corp.google.com> (sfid-20170126_144502_343976_16232A6D)

On Thu, 2017-01-26 at 05:44 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 14:27 +0100, Johannes Berg wrote:
> > Hi,
> > 
> > It looks like right now we may have a hardware bug and accept
> > 0x0000 as
> > valid, when the outcome of the calculation is 0xffff.
> > 
> > What do you think we should do about this?
> > 
> > We could ignore the issue entirely, since 0 wasn't ever supposed to
> > be
> > sent anyway - but then we don't drop frames that we should drop. I
> > didn't manage to find the code in the IPv6/UDP stack that even does
> > that, but I assume it's there somewhere.
> > 
> > Alternatively, we could parse the packet to find the checksum
> > inside,
> > and if it's 0 then don't report CHECKSUM_UNNECESSARY, but that
> > seems
> > rather expensive/difficult due to the IPv6 variable header and all
> > that. If we wanted to go this route, are there any helper functions
> > for
> > this?
> > 
> > Unfortunately, in the current devices, we neither have a complete
> > indication that the packet was even UDP-IPv6, nor do we have the
> > raw
> > csum or anything like that. I think they're adding that to the next
> > hardware spin, but we probably need to address this issue now.

> Is this a xmit or rcv problem ?

Oops, sorry - receive. We can only indicate "CHECKSUM_UNNECESSARY",
nothing more advanced right now, but right now we'd indicate that if
the packet had 0x0000 in the checksum field, but should've had 0xffff.

On TX I believe we actually do in HW exactly what your patch just did.

johannes

  reply	other threads:[~2017-01-26 13:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26 13:27 IPv6-UDP 0x0000 checksum Johannes Berg
2017-01-26 13:44 ` Eric Dumazet
2017-01-26 13:49   ` Johannes Berg [this message]
2017-01-26 14:45     ` Eric Dumazet
2017-01-26 14:45       ` Eric Dumazet
2017-01-26 14:49       ` Johannes Berg
2017-01-26 14:49         ` Johannes Berg
2017-01-26 15:24         ` Eric Dumazet
2017-01-26 15:24           ` Eric Dumazet
2017-01-26 15:27           ` Eric Dumazet
2017-01-26 15:27             ` Eric Dumazet
2017-01-26 15:36             ` Johannes Berg
2017-01-26 15:36               ` Johannes Berg
2017-01-26 15:32           ` Johannes Berg

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=1485438546.14760.7.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --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.