tinc - Aug 2016 - Windows not reconnecting after Standby

Hello,

I am using tinc for about two years now, and server-side everything is
perfect.  But on my Windows 10 computer using tinc 1.1 and the OpenVPN TAP
Provider 9.0.0.21 I always have to shutdown and restart the tinc service,
when the computer returns from standby or hibernation.  This problem is not
related to the recent Windows updates.

I am using
Mode = switch
ExperimentalProtocol = no

Depending on the other settings, I sometimes see errors like "Metadata
socket read error for <control>" or "Error while writing to TAP
device..."

Right now I have the Metadata error, and log just shows an ongoing stream
of "Sending UDP probe length 18" to the various ConnectTo hosts.

I would like to know, if reconnecting to tinc automatically works for other
users on Windows 10 and if there is some recommended configuration?

Thanks for any advice, or workaround,

Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20160823/217d5d40/attachment.html>

You should try using the older TAP-Win32 drivers that are bundled with tinc
(i.e. 9.0.0.9). Using the newer, NDIS6 drivers (>= 9.0.0.21) is not
recommended; according to some testing I did in the past it seems to result
in poor tinc performance (for reasons I wasn't quite able to determine). I
am using tinc 1.1 with 9.0.0.9 on Windows 10 and it behaves correctly when
returning from standby.

On 23 August 2016 at 14:10, karel04 at gmail.com <karel04 at gmail.com>
wrote:
> Hello,
>
> I am using tinc for about two years now, and server-side everything is
> perfect.  But on my Windows 10 computer using tinc 1.1 and the OpenVPN TAP
> Provider 9.0.0.21 I always have to shutdown and restart the tinc service,
> when the computer returns from standby or hibernation.  This problem is not
> related to the recent Windows updates.
>
> I am using
> Mode = switch
> ExperimentalProtocol = no
>
> Depending on the other settings, I sometimes see errors like "Metadata
> socket read error for <control>" or "Error while writing to
TAP device..."
>
> Right now I have the Metadata error, and log just shows an ongoing stream
> of "Sending UDP probe length 18" to the various ConnectTo hosts.
>
> I would like to know, if reconnecting to tinc automatically works for
> other users on Windows 10 and if there is some recommended configuration?
>
> Thanks for any advice, or workaround,
>
> Karel
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20160823/433c5534/attachment-0001.html>

Thank you very much.  I can confirm that the TAP-WIN32 driver behaves
differently.  The quick tests so far revealed that it either reconnected
after Standby and Hibernation.


I think that at some point I started using the OpenVPN drivers when I had
either had trouble with unsigned drivers or the network detection and then
just stayed with it.  Thanks for pointing out my self-made problem.


On Tue, Aug 23, 2016 at 7:52 PM, Etienne Dechamps <etienne at
edechamps.fr>
wrote:
> You should try using the older TAP-Win32 drivers that are bundled with
> tinc (i.e. 9.0.0.9). Using the newer, NDIS6 drivers (>= 9.0.0.21) is not
> recommended; according to some testing I did in the past it seems to result
> in poor tinc performance (for reasons I wasn't quite able to
determine). I
> am using tinc 1.1 with 9.0.0.9 on Windows 10 and it behaves correctly when
> returning from standby.
>
> On 23 August 2016 at 14:10, karel04 at gmail.com <karel04 at
gmail.com> wrote:
>
>> Hello,
>>
>> I am using tinc for about two years now, and server-side everything is
>> perfect.  But on my Windows 10 computer using tinc 1.1 and the OpenVPN
TAP
>> Provider 9.0.0.21 I always have to shutdown and restart the tinc
service,
>> when the computer returns from standby or hibernation.  This problem is
not
>> related to the recent Windows updates.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20160823/64a11eb8/attachment.html>