* 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