Hi, On Thu, Aug 04, 2022 at 03:30:25PM +0200, Gert Doering wrote: > Test sets failed: 2b 2c 2f.
So, this is an interesting one.
To trigger this, you need to connect over UDP + IPv6 transport, and
then you need to inject a packet into "openvpn with DCO" that is
fragmented into two parts, which *both* create an UDP packet after
encapsulation which is bigger than 1500 bytes.
$ ping -c1 -s 2900 10.194.2.1
does this.
Tcpdump on the "tun0" interface shows
15:49:16.433666 IP (tos 0x0, ttl 64, id 18639, offset 0, flags [+], proto ICMP
(1), length 1500)
ubuntu2004 > 10.194.2.1: ICMP echo request, id 170, seq 1, length 1480
15:49:16.433703 IP (tos 0x0, ttl 64, id 18639, offset 1480, flags [none], proto
ICMP (1), length 1448)
ubuntu2004 > 10.194.2.1: icmp
so this is one "full sized 1500 byte frame", containing the first fragment,
and then a 1448 byte frame containing the rest.
Connecting with --disable-dco yields this on the outside:
17:09:14.763519 IP6 (flowlabel 0x0082a, hlim 62, next-header Fragment (44)
payload length: 1456) ubuntu2004 > phillip: frag (0x277a4245:0|1448) 34646 >
51194: UDP, bad length 1524 > 1440
17:09:14.763548 IP6 (flowlabel 0x0082a, hlim 62, next-header Fragment (44)
payload length: 92) ubuntu2004 > phillip: frag (0x277a4245:1448|84)
17:09:14.763576 IP6 (flowlabel 0x0082a, hlim 62, next-header Fragment (44)
payload length: 1456) ubuntu2004 > phillip: frag (0x1dec474f:0|1448) 34646 >
51194: UDP, bad length 1472 > 1440
17:09:14.763593 IP6 (flowlabel 0x0082a, hlim 62, next-header Fragment (44)
payload length: 40) ubuntu2004 > phillip: frag (0x1dec474f:1448|32)
this is "4 packets are sent" (and, subsequently, 4 packets come back).
Both "(close to) full inside packets" are too big for an external 1500 byte
packet, and get fragmented. Is this ugly? Yes. Is it according to IP
specs? Yes. Do I expect this to work? Yes! (t_client excercises this
case with the 3000-byte-pings).
Now, *with* DCO, we get this:
17:10:43.771215 IP6 (hlim 62, next-header Fragment (44) payload length: 1456)
ubuntu2004 > phillip: frag (0xe79d84cc:0|1448) 58755 > 51194: UDP, bad length
1524 > 1440
17:10:43.771246 IP6 (hlim 62, next-header Fragment (44) payload length: 92)
ubuntu2004 > phillip: frag (0xe79d84cc:1448|84)
(only *two* packets, then only keepalives)
And at the same time, the client (!) complains
2022-08-04 17:10:38 net_iface_new: add tun0 type ovpn-dco
2022-08-04 17:10:38 DCO device tun0 opened
(so, we're using DCO)
2022-08-04 17:10:43 read UDPv6 [CMSG=50|EMSGSIZE Path-MTU=1500]: Message too
long (fd=3,code=90)
Now... reducing the ping size to 2500...
gert@ubuntu2004:~$ ping -c1 -s 2500 10.194.2.1
2508 bytes from 10.194.2.1: icmp_seq=1 ttl=64 time=126 ms
... actually works.
What is sent out by DCO in this case is 3 packets, 2 fragments, and
one regular UDP packet
17:12:21.512762 IP6 (hlim 62, next-header Fragment (44) payload length: 1456)
ubuntu2004 > phillip: frag (0x12728a31:0|1448) 58755 > 51194: UDP, bad length
1524 > 1440
17:12:21.512806 IP6 (hlim 62, next-header Fragment (44) payload length: 92)
ubuntu2004 > phillip: frag (0x12728a31:1448|84)
17:12:21.512864 IP6 (hlim 63, next-header UDP (17) payload length: 1080)
ubuntu2004.58755 > phillip.51194: [udp sum ok] UDP, length 1072
... because the second half of the fragmented ICMP packet now fits into
one UDP/1500 byte even after openvpn encapsulation.
So my current guess is that the linux kernel sets *some* flag on
"non-primary ICMP fragments" (inside) that get carried over to the final
encapsulated packet, preventing further fragmentation (outside), but
eliciting an "PMTU fail" error instead - which the newly renovated
extended socket error handler picks up. In userland :-)
To add a data point:
gert@ubuntu2004:~$ ping -c1 -s 3500 10.194.2.1
creates *3* packets in the DCO case
17:14:08.780733 IP6 (hlim 62, next-header Fragment (44) payload length: 1456)
ubuntu2004 > phillip: frag (0x16acdc72:0|1448) 58755 > 51194: UDP, bad length
1524 > 1440
17:14:08.780757 IP6 (hlim 62, next-header Fragment (44) payload length: 92)
ubuntu2004 > phillip: frag (0x16acdc72:1448|84)
17:14:08.780842 IP6 (hlim 63, next-header UDP (17) payload length: 600)
ubuntu2004.58755 > phillip.51194: [udp sum ok] UDP, length 592
... and one error message.
In the non-DCO case, this creates *5* packets - 2 1500-inside packet
that get outside fragmented to 2+2 and one smaller "leftover" packet.
So the 2nd fragment is, again, refusing to be fragmented again...
(ping -s 5000 yields 7 packet without DCO, and only 3 with DCO, so a
pattern starts to form ;-) )
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
