Changes between Initial Version and Version 1 of Ticket #867


Ignore:
Timestamp:
03/31/17 19:48:32 (7 years ago)
Author:
David Sommerseth
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #867 – Description

    initial v1  
    11After some thorough testing with static key configurations a corner case was found.  There are several workarounds, but I wonder if this warrants a fix.
    22
    3 Basically the issue is found on the v2.4 side in configurations with --proto {udp, tcp-server} where both sides uses the --remote option.  In this scenario a reconnect attempt does not happen, thus only the first resolved IP address is used.
     3Basically the issue is found on the v2.4 side in configurations with `--proto {udp, tcp-server}` where both sides uses the `--remote option`.  In this scenario a reconnect attempt does not happen, thus only the first resolved IP address is used.
    44
    55== Setup
    … …  
    5151 1. Alternative, use ''either'' `--proto udp4` on the v2.4 side ''or'' `--proto udp6` on the v2.3 side
    5252 1. Alternative, add `--keepalive 10 20` on the v2.4 side.  This triggers a re-connect which will use another resolved IP address
    53  1. Alternative, switch to TCP using `--proto tcp-client` on the v2.4 side.  This also triggers a reconnect.
     53 1. Alternative, switch to TCP using `--proto tcp-client` on the v2.4 side and `--proto tcp-server` on the v2.3 side.  This also triggers a reconnect.  The other way around does not work, as the v2.3 side will then listen to an IPv4 socket while the v2.4 side tries to connect using an IPv6 socket.
    5454
    5555== Conclusion