For non-blocking TCP/Unix connection, OpenVPN checks was it established in
loop and if not - sleeps or handles management for next one second. Since
the first check is made right after the connection attempt, it will likely
be always unsuccessful, causing redundant wait for one or more seconds:
Hi Arne,
> Okay, I looked at the code and you are right. That code is a mess. It
> basically
> calls select/pool with a timeout of 0, then actively does select/pool in
> management for 1s and does this in a loop. That this totally wrong indeed.
>
> I think we should be more radical here. Always
On 01/10/2020 18:36, Simon Matter wrote:
>> From what I recall from the last review years ago, the behavior was also
>> not
>> well defined in restart scenarios (--up-restart) - where the script might
>> be
>> run with different privileges, the --chroot might also change things.
>> Which
>> makes
> On 01/10/2020 17:03, Simon Matter wrote:
>> I really can't understand why this small patch was refused for years and
>> I
>> still feel nobody ever really looked at it.
>
> Perhaps this also an indication of the corner case this patch is covering?
>
> This patch started 7 years ago. There has
On 01/10/2020 17:03, Simon Matter wrote:
> I really can't understand why this small patch was refused for years and I
> still feel nobody ever really looked at it.
Perhaps this also an indication of the corner case this patch is covering?
This patch started 7 years ago. There has been 2 other
Hi Arne,
> Am 22.11.17 um 17:58 schrieb Simon Matter:
>> Hi,
>>
>> In our situation we have the requirement to run scripts before tun/tap
>> is
>> opened, not after. While this could be hacked into the init script, the
>> proper way seems to add it to openvpn as --up-pre option. That's
>>
On 01/10/2020 14:10, Arne Schwabe wrote:
> Am 22.11.17 um 17:58 schrieb Simon Matter:
>> Hi,
>>
>> In our situation we have the requirement to run scripts before tun/tap is
>> opened, not after. While this could be hacked into the init script, the
>> proper way seems to add it to openvpn as
Am 24.09.20 um 11:10 schrieb Vladislav Grishenko:
> Per https://community.openvpn.net/openvpn/wiki/CodeStyle the maximum line
> length is 80 characters. This patch allows to split upcoming changes into
> CodeStyle-conformant (w/o real code change) and more feature-specific.
> Upcoming changes adds
Your patch has been applied to the master and release/2.5 branch.
commit 43cdb0c702dd184541d4fa5e0c2b2899966371a0 (master)
commit 25e3145298c1c9e508470a183991957769301a58 (release/2.5)
Author: Richard Bonhomme
Date: Thu Aug 6 20:01:40 2020 +0100
Improve error msg when all TAP adapters are
Am 06.08.20 um 21:27 schrieb Selva Nair:
> Hi,
>
> This looks good but can we do better? We don't check the error
> (GetLastError()) after the CreateFile() failure -- can we determine
> whether the error was due to permissions, busy file (in use) or
> disabled device and print out a more specific
Am 03.07.19 um 16:50 schrieb Daniel Kaldor:
> OpenVPN using management interface and running with
> 'management-query-remote' in the config will wait for a 'remote MOD'
> or 'remote ACCEPT' message before continuing with connection.
>
> Logs indicate that this stage of the connection process
Am 22.11.17 um 17:58 schrieb Simon Matter:
> Hi,
>
> In our situation we have the requirement to run scripts before tun/tap is
> opened, not after. While this could be hacked into the init script, the
> proper way seems to add it to openvpn as --up-pre option. That's
> independent from any init
Am 14.09.20 um 03:23 schrieb Rafael Gava:
> Hello guys,
>
> A couple years ago I submitted this patch which allows the user to set
> the 'client-ip' as a convenient way to use the leased IP address
> received from OpenVPN server in NAT configuration. For example:
>
> client-nat snat client-ip
Am 28.09.20 um 01:32 schrieb Vladislav Grishenko:
> For non-blocking TCP/Unix connection, OpenVPN checks was it established in
> loop and if not - sleeps or handles management for next one second. Since
> the first check is made right after the connection attempt, it will likely
> be always
14 matches
Mail list logo
