Hi, On 25/03/2021 22:37, Antonio Quartulli wrote: > Anybody can see why we need that for port-share? > I'd rather try to understand the above and ditch this member entirely, > if the answer is "we don't need it".
After more tests I indeed recovered the reason why this is needed with port-share. If we don't "hold back", upon connection the server will send its own SERVER_HARD_RESET, regardless of the client having sent a CLIENT_HARD_RESET or not. This behaviour indeed breaks port-share because the non-OpenVPN application on the other side will receive an unexpected packet and will most likely kill the connection. For this reason we need to hold any control channel packet until we have confirmed that the first packet is indeed a CLIENT_HARD_RESET. Regarding TCP, the only thing I can think about is that this flag helps mimicking UDP: instead of sending the HARD_RESET right after a TCP Connection is opened, the server will wait for the client packet first. In UDP I presume this is standard behaviour as we have no connection opening event. My guess is that this behaviour may be useful to avoid race conditions on the client where the SERVER_HARD_RESET is received when still unexpected? But maybe the code has evolved enough to not requiring this sequence of events anymore. Cheers, -- Antonio Quartulli _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
