Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[RFC/PATCH] SO_NO_CHECK for IPv6

95 views
Skip to first unread message

Jeff Garzik

unread,
Nov 21, 2007, 7:46:10 AM11/21/07
to net...@vger.kernel.org, LKML

SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
based on a reading of net/ipv4/udp.c.

I wonder if IPv4's CHECKSUM_PARTIAL check from udp_push_pending_frames()
also needs to be copied to IPv6?

Signed-off-by: Jeff Garzik <jga...@redhat.com>
---
net/ipv6/udp.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index ee1cc3f..7927e69 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -538,9 +538,14 @@ static int udp_v6_push_pending_frames(struct sock *sk)
uh->len = htons(up->len);
uh->check = 0;

- if (up->pcflag)
+ if (up->pcflag) /* UDP-Lite */
csum = udplite_csum_outgoing(sk, skb);
- else
+
+ else if (sk->sk_no_check == UDP_CSUM_NOXMIT) { /* UDP csum disabled */
+ skb->ip_summed = CHECKSUM_NONE;
+ goto send;
+
+ } else
csum = udp_csum_outgoing(sk, skb);

/* add protocol-dependent pseudo-header */
@@ -549,6 +554,7 @@ static int udp_v6_push_pending_frames(struct sock *sk)
if (uh->check == 0)
uh->check = CSUM_MANGLED_0;

+send:
err = ip6_push_pending_frames(sk);
out:
up->len = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

YOSHIFUJI Hideaki / 吉藤英明

unread,
Nov 21, 2007, 8:21:21 AM11/21/07
to je...@garzik.org, net...@vger.kernel.org, linux-...@vger.kernel.org, yosh...@linux-ipv6.org
In article <20071121124...@havoc.gtf.org> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik <je...@garzik.org> says:

>
> SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
> based on a reading of net/ipv4/udp.c.

Disagree. UDP checksum is mandatory in IPv6.

--yoshfuji

Herbert Xu

unread,
Nov 21, 2007, 8:44:03 AM11/21/07
to YOSHIFUJI Hideaki / 吉藤英明, je...@garzik.org, net...@vger.kernel.org, linux-...@vger.kernel.org
On Wed, Nov 21, 2007 at 01:20:51PM +0000, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20071121124...@havoc.gtf.org> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik <je...@garzik.org> says:
>
> >
> > SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
> > based on a reading of net/ipv4/udp.c.
>
> Disagree. UDP checksum is mandatory in IPv6.

Right, IPv6 doesn't have a header checksum so the UDP checksum
must be there.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <her...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

David Miller

unread,
Nov 21, 2007, 1:36:08 PM11/21/07
to je...@garzik.org, net...@vger.kernel.org, linux-...@vger.kernel.org
From: Jeff Garzik <je...@garzik.org>
Date: Wed, 21 Nov 2007 07:45:32 -0500

>
> SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
> based on a reading of net/ipv4/udp.c.
>
> I wonder if IPv4's CHECKSUM_PARTIAL check from udp_push_pending_frames()
> also needs to be copied to IPv6?
>
> Signed-off-by: Jeff Garzik <jga...@redhat.com>

IPV6 specifies that, unlike ipv4, this no-checksum behavior
is not allowed.

Jeff Garzik

unread,
Nov 21, 2007, 7:18:34 PM11/21/07
to YOSHIFUJI Hideaki / 吉藤英明, net...@vger.kernel.org, linux-...@vger.kernel.org, Herbert Xu, David Miller
YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20071121124...@havoc.gtf.org> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik <je...@garzik.org> says:
>
>> SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
>> based on a reading of net/ipv4/udp.c.
>
> Disagree. UDP checksum is mandatory in IPv6.

Ah, you mean that I need to turn off UDP checksum on receive end as well
in IPv6... true.

For those interested, I am dealing with a UDP app that already does very
strong checksumming and encryption, so additional software checksumming
at the lower layers is quite simply a waste of CPU cycles. Hardware
checksumming is fine, as long as its "free."

Jeff

Herbert Xu

unread,
Nov 21, 2007, 9:35:03 PM11/21/07
to Jeff Garzik, YOSHIFUJI Hideaki / 吉藤英明, net...@vger.kernel.org, linux-...@vger.kernel.org, David Miller
On Wed, Nov 21, 2007 at 07:17:40PM -0500, Jeff Garzik wrote:
>
> For those interested, I am dealing with a UDP app that already does very
> strong checksumming and encryption, so additional software checksumming
> at the lower layers is quite simply a waste of CPU cycles. Hardware
> checksumming is fine, as long as its "free."

No matter how strong your underlying checksumming is it's not
going to protect the IPv6 header is it :)

YOSHIFUJI Hideaki / 吉藤英明

unread,
Nov 21, 2007, 9:49:12 PM11/21/07
to her...@gondor.apana.org.au, je...@garzik.org, net...@vger.kernel.org, linux-...@vger.kernel.org, da...@davemloft.net, yosh...@linux-ipv6.org
In article <2007112202...@gondor.apana.org.au> (at Thu, 22 Nov 2007 10:34:03 +0800), Herbert Xu <her...@gondor.apana.org.au> says:

> On Wed, Nov 21, 2007 at 07:17:40PM -0500, Jeff Garzik wrote:
> >
> > For those interested, I am dealing with a UDP app that already does very
> > strong checksumming and encryption, so additional software checksumming
> > at the lower layers is quite simply a waste of CPU cycles. Hardware
> > checksumming is fine, as long as its "free."
>
> No matter how strong your underlying checksumming is it's not
> going to protect the IPv6 header is it :)

In that sense, we should use AH.

--yoshfuji

David Miller

unread,
Nov 22, 2007, 8:13:43 PM11/22/07
to je...@garzik.org, yosh...@linux-ipv6.org, net...@vger.kernel.org, linux-...@vger.kernel.org, her...@gondor.apana.org.au
From: Jeff Garzik <je...@garzik.org>
Date: Wed, 21 Nov 2007 19:17:40 -0500

> YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > In article <20071121124...@havoc.gtf.org> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik <je...@garzik.org> says:
> >
> >> SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
> >> based on a reading of net/ipv4/udp.c.
> >
> > Disagree. UDP checksum is mandatory in IPv6.
>
> Ah, you mean that I need to turn off UDP checksum on receive end as well
> in IPv6... true.
>
> For those interested, I am dealing with a UDP app that already does very
> strong checksumming and encryption, so additional software checksumming
> at the lower layers is quite simply a waste of CPU cycles. Hardware
> checksumming is fine, as long as its "free."

Regardless of whatever verifications your application is doing
on the data, it is not checksumming the ports and that's what
the pseudo-header is helping with.

You cannot disable checksums in ipv6/UDP, they are not optional and
with %99.9999999 of cards doing the checksum in hardware, and even if
we do have to compute it it's free during the copy during recvmsg().

David Schwartz

unread,
Nov 23, 2007, 1:08:13 AM11/23/07
to Linux-Kernel@Vger. Kernel. Org, net...@vger.kernel.org

> Regardless of whatever verifications your application is doing
> on the data, it is not checksumming the ports and that's what
> the pseudo-header is helping with.

So what? We are in the case where the data has already gotten to him. If it
got to him in error, he'll reject it anyway. The receive checksum check will
only reject packets that he would reject anyway. That makes it needless.

Of course, if the check is nearly free, there's no potential win, so no
point in bothering.

DS

Herbert Xu

unread,
Nov 24, 2007, 1:01:46 AM11/24/07
to dav...@webmaster.com, linux-...@vger.kernel.org, net...@vger.kernel.org
David Schwartz <dav...@webmaster.com> wrote:
>
>> Regardless of whatever verifications your application is doing
>> on the data, it is not checksumming the ports and that's what
>> the pseudo-header is helping with.
>
> So what? We are in the case where the data has already gotten to him. If it
> got to him in error, he'll reject it anyway. The receive checksum check will
> only reject packets that he would reject anyway. That makes it needless.

What if it goes to the wrong recipient who doesn't have the upper-
level checksums?

This is the whole point, IPv6 unlike IPv4 does not have IP header
checksums so the high-level needs to protect it by checksumming
the pseudo-header.

David Schwartz

unread,
Nov 25, 2007, 10:42:13 AM11/25/07
to Linux-Kernel@Vger. Kernel. Org, net...@vger.kernel.org

> David Schwartz <dav...@webmaster.com> wrote:

> >> Regardless of whatever verifications your application is doing
> >> on the data, it is not checksumming the ports and that's what
> >> the pseudo-header is helping with.

> > So what? We are in the case where the data has already gotten
> > to him. If it
> > got to him in error, he'll reject it anyway. The receive
> > checksum check will
> > only reject packets that he would reject anyway. That makes it needless.

> What if it goes to the wrong recipient who doesn't have the upper-
> level checksums?

Since that's not him, he has no control over its policy and thus no ability
to harm it or help it.

> This is the whole point, IPv6 unlike IPv4 does not have IP header
> checksums so the high-level needs to protect it by checksumming
> the pseudo-header.

Exactly. But *he* doesn't need to check that checksum, given that he already
got the packet, since he has an upper-level checksum. He is not saying that
his reasoning applies to everyone, just that it applies to him. He is not
talking about disabling the send checksum, but the receive checksum. He
knows that he does not need it.

DS

Herbert Xu

unread,
Nov 25, 2007, 9:48:48 PM11/25/07
to dav...@webmaster.com, linux-...@vger.kernel.org, net...@vger.kernel.org
David Schwartz <dav...@webmaster.com> wrote:
>
> Exactly. But *he* doesn't need to check that checksum, given that he already
> got the packet, since he has an upper-level checksum. He is not saying that
> his reasoning applies to everyone, just that it applies to him. He is not
> talking about disabling the send checksum, but the receive checksum. He
> knows that he does not need it.

You must be in some other thread because this one started with
a patch to disable sender checksums.

Oh and please do keep CCs on this list.

0 new messages