Hi, On Thu, Feb 10, 2022 at 05:26:27PM +0100, Arne Schwabe wrote: > Instead relying on the link_mtu_dynamic field and its calculation > in the frame struct, add a new field max_fragment_size and add > a calculation of it similar to mssfix. > > Also whenever mssfix value is calculated, we also want to calculate > the values for fragment as both options need to be calculated from > the real overhead. > > Patch v2: Fix syntax in rst man page
Not sure what exactly caused this (maybe the reordering), but applying
3/8 after 1+2 (in tree) leads to "UDP p2mp server crashing"
2022-02-11 12:24:07 us=152359 Initialization Sequence Completed
2022-02-11 12:24:18 us=290966 MULTI: multi_create_instance called
2022-02-11 12:24:18 us=291063 194.97.140.21:62328 Re-using SSL/TLS context
2022-02-11 12:24:18 us=291116 194.97.140.21:62328 LZO compression initializing
2022-02-11 12:24:18 us=291376 194.97.140.21:62328 Control Channel MTU parms [
mss_fix:0 max_frag:0 tun_mtu:1250 headroom:126 payload:1376 tailroom:126 L:1622
EF:38 EB:0 ET:0 EL:3 ]
Program received signal SIGSEGV, Segmentation fault.
frame_calculate_mssfix (lsi=0x0, options=0x555555642280, kt=0x555555642b40,
frame=0x555555642dd0) at mss.c:305
305 overhead += get_ip_encap_overhead(options, lsi);
(gdb) where
#0 frame_calculate_mssfix (lsi=0x0, options=0x555555642280, kt=0x555555642b40,
frame=0x555555642dd0) at mss.c:305
#1 frame_calculate_dynamic (frame=frame@entry=0x555555642dd0,
kt=kt@entry=0x555555642b40, options=options@entry=0x555555642280, lsi=0x0)
at mss.c:334
#2 0x000055555557b2bb in init_instance (c=c@entry=0x555555642280,
env=<optimized out>, flags=flags@entry=10) at init.c:4234
#3 0x000055555557c4a6 in inherit_context_child
(dest=dest@entry=0x555555642280, src=src@entry=0x7fffffffc4b0) at init.c:4459
#4 0x0000555555591af3 in multi_create_instance (m=m@entry=0x7fffffffc3f0,
real=real@entry=0x7fffffffc2b0) at multi.c:759
#5 0x000055555558b89e in multi_get_create_instance_udp (m=0x7fffffffc3f0,
floated=floated@entry=0x7fffffffc33f) at mudp.c:103
#6 0x0000555555591efa in multi_process_incoming_link
(m=m@entry=0x7fffffffc3f0, instance=instance@entry=0x0,
mpp_flags=mpp_flags@entry=5)
at multi.c:3107
the crucial part is "lsi=0x0" here, I think, but I'm not sure why... we do
have a socket, we know we bound it to IPv6 (+dual-stack)...
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 [email protected]
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
