... moves the crash onward to
0x00005555555891b6 in datagram_overhead (proto=<error reading variable: Cannot
access memory at address 0x24>, af=10) at socket.h:617
617 overhead += (proto == PROTO_UDP) ? 8 : 20;
(gdb) where
#0 0x00005555555891b6 in datagram_overhead (proto=<error reading variable: Cannot
access memory at address 0x24>, af=10) at socket.h:617
#1 get_ip_encap_overhead (lsi=0x0, options=0x555555642280) at mss.c:248
#2 frame_calculate_mssfix (lsi=0x0, options=0x555555642280, kt=0x555555642b40,
frame=0x555555642dd0) at mss.c:305
#3 frame_calculate_dynamic (frame=frame@entry=0x555555642dd0,
kt=kt@entry=0x555555642b40, options=options@entry=0x555555642280, lsi=0x0)
at mss.c:334
#4 0x000055555557b2bb in init_instance (c=c@entry=0x555555642280, env=<optimized
out>, flags=flags@entry=10) at init.c:4234
#5 0x000055555557c4a6 in inherit_context_child
(dest=dest@entry=0x555555642280, src=src@entry=0x7fffffffc4b0) at init.c:4459
which looks weird, but is likely due to inlining.
The culprit is this one:
return datagram_overhead(af, lsi->proto);
"lsi" is still NULL...
Not sure how to fix this in a good way.
This function is called to early now and doesn't anything useful anymore
apart when used in --static/crypto none context. So I changed it to not
crash in these cases and added a comment that the call is superflous for
most of OpenVPN's operation. If we at some point remove --static/no
crypto (non TLS modes), we can do a lot of cleanup.
Arne
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
