netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Grenz <christophg+lkml@grenz-bonn.de>
To: Tom Herbert <tom@herbertland.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: IPv6 Destination Options question
Date: Mon, 16 Dec 2019 02:59:01 +0100	[thread overview]
Message-ID: <98532586.q66oQjG9bA@cg-notebook> (raw)
In-Reply-To: <10108598.co7siHb18S@cg-notebook>

Hi Tom,

I narrowed the issue down to a possible bug in the kernel-side IPv6 checksum 
calculation:

A raw socket for IPPROTO_MH has checksum calculation/verification enabled by 
default (as if setsockopt(s, IPPROTO_IPV6, IPV6_CHECKSUM, 4) was used).

I get different checksums for the same packet with and without IPV6_DSTOPTS 
ancillary data. The checksum is independent of the content of the Destination 
Options, but adding multiple IPV6_DSTOPTS anciliary data items changes the 
calculated checksum, even if the resulting packet is otherwise identical.

The checksum verification then discards the packets on the receiving side, 
which is why I didn't get any packets on my IPPROTO_MH socket and suspected a 
problem on the receiving side first.

When I calculate the checksum in userspace and set the IPV6_CHECKSUM socket 
option to -1 to disable the in-kernel calculation on the sending side, I 
receive all packets as expected.

It doesn't happen with IPV6_HOPOPTS or IPV6_RTHDR ancillary data, at least as 
far as I checked.

Could you take a look at it before I submit a bug report?

Best regards
Christoph


Am Samstag, 14. Dezember 2019, 22:11:01 CET schrieb Christoph Grenz:
> Hi Tom,
> 
> my receive code boils down to this Python script:
> 
> --------------------------------------------------------------------
> #!/usr/bin/env python3
> 
> from socket import socket, AF_INET6, IPPROTO_IPV6, IPV6_RECVDSTOPTS,
> SOCK_RAW
> 
> IPPROTO_MH = 135 # IPv6 Mobility Header
> 
> sock = socket(AF_INET6, SOCK_RAW, IPPROTO_MH)
> sock.setsockopt(IPPROTO_IPV6, IPV6_RECVDSTOPTS, True)
> 
> sock.bind(('::',  0))
> 
> while True:
> 	packet, ancdata, msg_flags, address = sock.recvmsg(1800, 512)
> 	print(address[0], packet.hex(), ancdata)
> 
> --------------------------------------------------------------------
> 
> Best regards,
> Christoph
> 
> Am Samstag, 14. Dezember 2019, 12:40:16 CET schrieb Tom Herbert:
> > On Sat, Dec 14, 2019 at 8:19 AM Christoph Grenz
> > 
> > <christophg+lkml@grenz-bonn.de> wrote:
> > > Hello,
> > > 
> > > I'm playing around with Mobile IPv6 and noticed a strange behaviour in
> > > the
> > > Linux network system when using IPv6 destination options:
> > > 
> > > I'm able to send destination options on SOCK_DGRAM and SOCK_RAW sockets
> > > with sendmsg() and IPV6_DSTOPTS ancillary data. The sent packets also
> > > look correct in Wireshark.
> > > 
> > > But I'm not able to receive packets with destination options on a socket
> > > with the IPV6_RECVDSTOPTS socket option enabled. Both a packet with a
> > > Home Address Option and a packet with an empty destination options
> > > header
> > > (only containing padding) won't be received on a socket for the payload
> > > protocol.
> > 
> > Christoph, Can you post your receive code?
> > 
> > Thanks
> > 
> > > Only a SOCK_RAW socket for IPPROTO_DSTOPTS receives the packet.
> > > 
> > > I tested this on a vanilla 5.4.0 kernel and got the same behaviour.
> > > Activating dyndbg for everything in net/ipv6 didn't produce any relevant
> > > output in dmesg.
> > > 
> > > Is this expected behaviour or a bug? Or do I maybe need some other
> > > socket
> > > option or a xfrm policy to receive packets with destination options?
> > > 
> > > Best regards
> > > Christoph



      reply	other threads:[~2019-12-16  1:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-14 16:11 IPv6 Destination Options question Christoph Grenz
2019-12-14 20:40 ` Tom Herbert
2019-12-14 21:11   ` Christoph Grenz
2019-12-16  1:59     ` Christoph Grenz [this message]

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=98532586.q66oQjG9bA@cg-notebook \
    --to=christophg+lkml@grenz-bonn.de \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).