* IPv6 Destination Options question
@ 2019-12-14 16:11 Christoph Grenz
2019-12-14 20:40 ` Tom Herbert
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Grenz @ 2019-12-14 16:11 UTC (permalink / raw)
To: netdev
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.
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IPv6 Destination Options question
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
0 siblings, 1 reply; 4+ messages in thread
From: Tom Herbert @ 2019-12-14 20:40 UTC (permalink / raw)
To: Christoph Grenz; +Cc: Linux Kernel Network Developers
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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IPv6 Destination Options question
2019-12-14 20:40 ` Tom Herbert
@ 2019-12-14 21:11 ` Christoph Grenz
2019-12-16 1:59 ` Christoph Grenz
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Grenz @ 2019-12-14 21:11 UTC (permalink / raw)
To: Tom Herbert, Linux Kernel Network Developers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IPv6 Destination Options question
2019-12-14 21:11 ` Christoph Grenz
@ 2019-12-16 1:59 ` Christoph Grenz
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Grenz @ 2019-12-16 1:59 UTC (permalink / raw)
To: Tom Herbert, Linux Kernel Network Developers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-12-16 1:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).