From: Juan Orti <jorti@pm.me>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>,
"passt-user@passt.top" <passt-user@passt.top>
Subject: Re: IPv6 UDP not working
Date: Sun, 28 May 2023 16:27:13 +0000 [thread overview]
Message-ID: <WHlyhD5T65ltZwbmE6P6VYj_LrRtssLIZRrtTQZxo0Ru6q6zzIRHi0OxNX7UaWOwunTU0YRWu12pdbgv5f6Ruza9IoTnzD22uUF20f_r4qg=@pm.me> (raw)
In-Reply-To: <20230528163812.69e359dd@elisabeth>
------- Original Message -------
El domingo, 28 de mayo de 2023 a las 16:38, Stefano Brivio <sbrivio@redhat.com> escribió:
> I guess that might come from the IPV6_PKTINFO ancillary data
> (cmsg_type 0x32) -- I'm not sure how and why it's used here as strace
> doesn't dump the CMSG_DATA content, but, having a look at
> ip6_datagram_send_ctl() (net/ipv6/datagram.c), EINVAL might come from:
>
> 1. a link-local address being passed along... I doubt that's the case
>
> 2. a non-local address (or one we can't bind to anyway) being used. To
> check if we're in this case, it would be helpful if you could share
> the addressing information from the container (ip -6 address show),
> and if you could try 'sysctl -w net.ipv6.ip_nonlocal_bind = 1',
> again from the container.
net.ipv6.ip_nonlocal_bind=1 is not helping. This is the container network config:
# ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp88s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 state UNKNOWN qlen 1000
inet6 fddc:f797:78ef:70::5/64 scope global flags 02
valid_lft forever preferred_lft forever
inet6 fe80::5cef:4eff:fe6c:551f/64 scope link
valid_lft forever preferred_lft forever
# ip -6 r show table all
fddc:f797:78ef:70::/64 dev enp88s0 metric 256
fe80::/64 dev enp88s0 metric 256
default via fe80::ea9f:80ff:fe5d:3d6e dev enp88s0 metric 1024
local ::1 dev lo table local metric 0
local fddc:f797:78ef:70::5 dev enp88s0 table local metric 0
local fe80::5cef:4eff:fe6c:551f dev enp88s0 table local metric 0
multicast ff00::/8 dev enp88s0 table local metric 256
With a tcpdump inside the container I can see that the incoming packets are actually arriving with the link-local address as the destination (is this expected?).
16:18:26.248659 IP6 (hlim 255, next-header UDP (17) payload length: 63) fddc:f797:78ef:10::b46.42091 > fe80::5cef:4eff:fe6c:551f.53: [udp sum ok] 6215+ [1au] A? www.google.com. (55)
16:18:31.253942 IP6 (hlim 255, next-header UDP (17) payload length: 63) fddc:f797:78ef:10::b46.34965 > fe80::5cef:4eff:fe6c:551f.53: [udp sum ok] 6215+ [1au] A? www.google.com. (55)
16:18:36.257294 IP6 (hlim 255, next-header UDP (17) payload length: 63) fddc:f797:78ef:10::b46.55302 > fe80::5cef:4eff:fe6c:551f.53: [udp sum ok] 6215+ [1au] A? www.google.com. (55)
TCP also uses the link-local address, however it works:
16:20:50.933652 IP6 (flowlabel 0x000e0, hlim 255, next-header TCP (6) payload length: 28) fddc:f797:78ef:10::b46.36213 > fe80::5cef:4eff:fe6c:551f.53: Flags [S], cksum 0x8f00 (correct), seq 3612741141, win 65535, options [mss 4096,nop,wscale 7], length 0
16:20:50.933670 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::5cef:4eff:fe6c:551f > ff02::1:ff5d:3d6e: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::ea9f:80ff:fe5d:3d6e
source link-address option (1), length 8 (1): 5e:ef:4e:6c:55:1f
16:20:50.933675 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::5cef:4eff:fe6c:551f > ff02::1:ff5d:3d6e: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::ea9f:80ff:fe5d:3d6e
source link-address option (1), length 8 (1): 5e:ef:4e:6c:55:1f
16:20:50.933910 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ea9f:80ff:fe5d:3d6e > fe80::5cef:4eff:fe6c:551f: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::ea9f:80ff:fe5d:3d6e, Flags [router, solicited, override]
destination link-address option (2), length 8 (1): 48:21:0b:32:59:8e
16:20:50.933915 IP6 (flowlabel 0x57ab1, hlim 64, next-header TCP (6) payload length: 28) fe80::5cef:4eff:fe6c:551f.53 > fddc:f797:78ef:10::b46.36213: Flags [S.], cksum 0x6abe (correct), seq 3302060021, ack 3612741142, win 65460, options [mss 65460,nop,wscale 7], length 0
16:20:50.933921 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ea9f:80ff:fe5d:3d6e > fe80::5cef:4eff:fe6c:551f: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::ea9f:80ff:fe5d:3d6e, Flags [router, solicited, override]
destination link-address option (2), length 8 (1): 48:21:0b:32:59:8e
16:20:50.933934 IP6 (flowlabel 0x000e0, hlim 255, next-header TCP (6) payload length: 77) fddc:f797:78ef:10::b46.36213 > fe80::5cef:4eff:fe6c:551f.53: Flags [.], cksum 0x4e3d (correct), seq 1:58, ack 1, win 46080, length 57 29365+ [1au] A? www.google.com. (55)
16:20:50.933943 IP6 (flowlabel 0x57ab1, hlim 64, next-header TCP (6) payload length: 20) fe80::5cef:4eff:fe6c:551f.53 > fddc:f797:78ef:10::b46.36213: Flags [.], cksum 0x8e07 (correct), ack 58, win 511, length 0
16:20:50.934239 IP6 (flowlabel 0x57ab1, hlim 64, next-header TCP (6) payload length: 70) fe80::5cef:4eff:fe6c:551f.53 > fddc:f797:78ef:10::b46.36213: Flags [P.], cksum 0x4c39 (correct), seq 1:51, ack 58, win 512, length 50 29365 1/0/0 www.google.com. A 216.239.38.120 (48)
16:20:50.934253 IP6 (flowlabel 0x000e0, hlim 255, next-header TCP (6) payload length: 20) fddc:f797:78ef:10::b46.36213 > fe80::5cef:4eff:fe6c:551f.53: Flags [.], cksum 0x8e6c (correct), ack 51, win 360, length 0
16:20:50.934795 IP6 (flowlabel 0x000e0, hlim 255, next-header TCP (6) payload length: 20) fddc:f797:78ef:10::b46.36213 > fe80::5cef:4eff:fe6c:551f.53: Flags [F.], cksum 0x8e6b (correct), seq 58, ack 51, win 360, length 0
16:20:50.934874 IP6 (flowlabel 0x57ab1, hlim 64, next-header TCP (6) payload length: 20) fe80::5cef:4eff:fe6c:551f.53 > fddc:f797:78ef:10::b46.36213: Flags [F.], cksum 0x8dd2 (correct), seq 51, ack 59, win 512, length 0
16:20:50.934888 IP6 (flowlabel 0x000e0, hlim 255, next-header TCP (6) payload length: 20) fddc:f797:78ef:10::b46.36213 > fe80::5cef:4eff:fe6c:551f.53: Flags [.], cksum 0x8e6a (correct), ack 52, win 360, length 0
next prev parent reply other threads:[~2023-05-28 16:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <o0t07HOIe1WVorR4ppjQtAzY-E0bv5xAt-6UHTffXL_jo2sor1DmCVar_CuqwchJNLRUt8Q3mK3eZfQdJh0ryvXvuf-ewSHRBT5MhOoglDw=@pm.me>
2023-05-28 5:23 ` IPv6 UDP not working David Gibson
2023-05-28 10:12 ` Juan Orti
2023-05-28 10:50 ` Juan Orti
2023-05-28 14:38 ` Stefano Brivio
2023-05-28 16:27 ` Juan Orti [this message]
2023-05-28 22:08 ` Stefano Brivio
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='WHlyhD5T65ltZwbmE6P6VYj_LrRtssLIZRrtTQZxo0Ru6q6zzIRHi0OxNX7UaWOwunTU0YRWu12pdbgv5f6Ruza9IoTnzD22uUF20f_r4qg=@pm.me' \
--to=jorti@pm.me \
--cc=david@gibson.dropbear.id.au \
--cc=passt-user@passt.top \
--cc=sbrivio@redhat.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 IMAP folder(s).