On Thu, 2017-01-26 at 07:27 -0800, Eric Dumazet wrote:
>
> if (!uh->check && !udp_sk(sk)->no_check6_rx) {
> udp6_csum_zero_error(skb);
> goto csum_error;
> }
Yeah, I'd found no_check6_rx already, was still trying to
On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote:
>
> > Unfortunately, I haven't been able to actually test this yet. I
> > also
> > didn't find the code that would drop frames with CSUM 0 either, so
> > I'm
> > thinking - for now - th
On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote:
>
> > Unfortunately, I haven't been able to actually test this yet. I also
> > didn't find the code that would drop frames with CSUM 0 either, so I'm
> > thinking - for now - that if al
On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote:
> Unfortunately, I haven't been able to actually test this yet. I also
> didn't find the code that would drop frames with CSUM 0 either, so I'm
> thinking - for now - that if all the csum handling is skipped, dropping
> 0 csum frames would al
On Thu, 2017-01-26 at 06:45 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote:
>
> > 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 0x in the c
On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote:
> 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 0x in the checksum field, but should've had 0x.
>
> On TX I believe we actu
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
> > 0x as
> > valid, when the outcome of the calculation is 0x.
> >
> > What do you think we shoul
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 0x as
> valid, when the outcome of the calculation is 0x.
>
> What do you think we should do about this?
>
> We could ignore the issue entirely, since 0 wasn't
Hi,
It looks like right now we may have a hardware bug and accept 0x as
valid, when the outcome of the calculation is 0x.
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
