Hi, On Wed, Dec 07, 2022 at 08:56:04AM +0100, Gert Doering wrote: > the client side tests tested p2p udp (8) before p2p udp TLS (11), so > never noticed that after running (11), (8) would not work any longer...
More specifically, because I never tested p2p tun (8) on the DCO-enabled
servers ("why would I test this, it just slows down things, --secret won't
do DCO anyway").
But it seems, "p2p --secret" is broken hard in current code - it enables
DCO, and fails when the first client connects...
2022-12-07 09:01:32 us=920037 net_iface_new: add tun3 type ovpn-dco
2022-12-07 09:01:32 us=921045 DCO device tun3 opened
...
2022-12-07 09:02:02 us=527605 Attempting to send data packet while data channel
offload is in use. Dropping packet
...
start client, send packet:
2022-12-07 09:02:38 us=285472 Peer Connection Initiated with
[AF_INET6]::ffff:194.97.140.5:18999
Program received signal SIGSEGV, Segmentation fault.
0x000055555556beaf in addr_set_dco_installed (c=<optimized out>) at dco.c:447
447 ks->remote_addr.dco_installed = true;
(gdb) print ks
$1 = (struct key_state *) 0x5f8
... so whatever "ks" is in here, it's not a valid pointer...
Starting the p2p --secret instance with --disable-dco makes it behave
normally.
Since, I think, the claim is "DCO needs TLS", we just need a patch that
disables DCO for p2p --secret mode...
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
