> fails with the observed behaviour if the tcp server does not have
> keepalive se.
>
> Also, if 'keepalive' is a *requirement* then it should be set
> mandatorily in server mode with sane defaults (like 'keepalive 10 60' ) .
>
> The original bug still stands:
>
> If I have a working setup,
Am 09.12.20 um 09:42 schrieb Jan Just Keijser:
> Hi,
>
> On 04/12/20 16:24, Arne Schwabe wrote:
If I change the client config to list only a single
remote 1194 udp
line then this reconnect behavior does NOT occur ?!?!?!?
>>> This might be a bug in the initialisation order.
Hi,
On 04/12/20 16:24, Arne Schwabe wrote:
If I change the client config to list only a single
remote 1194 udp
line then this reconnect behavior does NOT occur ?!?!?!?
This might be a bug in the initialisation order. That the ping timer is
armed before next_connection_entry is called. If
> This code path is present from 2.1 on, in more or less unaltered form
Yes but only used for profiles with . For version before
that profiles with only --remote entries used a different (now removed)
code path.
Arne
___
Openvpn-devel mailing
Hi,
On 04/12/20 15:38, Arne Schwabe wrote:
Am 04.12.20 um 11:59 schrieb Jan Just Keijser:
hey guys,
I'm posting this on behalf of the eduVPN team. François Kooman spent a
long time debugging an issue and finally managed to find the piece of
code that causes the weird behavior.
Let me explain:
>> If I change the client config to list only a single
>> remote 1194 udp
>> line then this reconnect behavior does NOT occur ?!?!?!?
>>
> This might be a bug in the initialisation order. That the ping timer is
> armed before next_connection_entry is called. If you force it reconnect
> by
Am 04.12.20 um 11:59 schrieb Jan Just Keijser:
> hey guys,
>
> I'm posting this on behalf of the eduVPN team. François Kooman spent a
> long time debugging an issue and finally managed to find the piece of
> code that causes the weird behavior.
> Let me explain:
>
> For eduVPN, multiple openvpn
hey guys,
I'm posting this on behalf of the eduVPN team. François Kooman spent a
long time debugging an issue and finally managed to find the piece of
code that causes the weird behavior.
Let me explain:
For eduVPN, multiple openvpn instances are offered , both on UDP and TCP
ports and the