Am 20.03.24 um 13:06 schrieb Gert Doering:
Hi,
On Fri, Mar 15, 2024 at 05:40:02PM +0100, Frank Lichtenheld wrote:
Code looks good and I tested build and default t_client tests.
However, not sure how exactly to verify that it actually works.
The SOCKS proxy I have doesn't exhibit any problems even with
--connect-timeout 1.
Any ideas for testing welcome.
As far as I understand this fix, it's replacing the 5s hard coded timeout
for "handshake with the SOCKS proxy" with --connect-timeout.
So to exhibit any change in behaviour, you need a slow SOCKs proxy...
I have a few ideas how to test this, like
- --socks-proxy <non-answering-ip>:10080
(should fail after 5 seconds without the patch, after --connect-timeout
with the patch)
- hack "something that can speak SOCKS" (like, ssh) to be really slow
in answering - like, "add a sleep(15) in the socks handshake path",
and point OpenVPN to that. Without the patch, this should fail, with
the patch, it should succeeds.
(Note: 'ssh -D nnnn' will do SOCKS, but not UDP -> TCP server needed)
I have no time just now to go hacking on this, so just putting out the
ideas...
For our regular testbed, testing all these timeouts is complicated
(and even if you succeed, it's sllloowww if you want reproduceable
results, so not "milliseconds timers").
Or use something like dummynet. At least on macOS it used to be easy to
simulate a long delay with that and pfctl.
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
