Sockets not non-blocking when compiling with MingW

Hello.

When tinc is compiled with MingW, sockets are not made non-blocking
because O_NONBLOCK is not defined anywhere.

This leads to weird timeouts when one or more hosts part of a VPN are
unreachable, because tinc hangs in connect() (and possibly other
places as well).

This guy is probably experiencing this bug:
http://brouwer.uvt.nl/pipermail/tinc/2007-April/001646.html

I've attached a patch that adds some win32-specific code to make
sockets non-blocking. I've been using it for a couple of hours, and
have experienced no problems so far.

Hello.

When tinc is compiled with MingW, sockets are not made non-blocking
because O_NONBLOCK is not defined anywhere.

This leads to weird timeouts when one or more hosts part of a VPN are
unreachable, because tinc hangs in connect() (and possibly other
places as well).

This guy is probably experiencing this bug:
http://brouwer.uvt.nl/pipermail/tinc/2007-April/001646.html

Re: Sockets not non-blocking when compiling with MingW

And here's a revised patch that doesn't break compiling
on other platforms. (whoops.)

And here's a revised patch that doesn't break compiling
on other platforms. (whoops.)

Re: Combining Tinc and Cspace

On Tue, Apr 03, 2007 at 09:46:55AM +0200, Christian Cier-Zniewski wrote:

> Ok. Maybe the word integration is wrong here. Maybe it is more a
> frontend for TINC.
[...]
> As you may have seen there are some helper programs which provide some
> kind of integration for VNC, file transfer and chat. I also thought of a
> helper application which does nothing more than providing config-files
> for TINC, but handles the information exchange necessary to sucessfully
> establish a TINC-VPN with other buddies on the contact list. The
> TINC-TCP and TINC-UDP connections are handled by TINC itself as usual.
> So no modification of TINC is needed.

That's certainly possible. I don't have a lot of time to work on tinc at
the moment, so I won't be doing this. But if someone does provide such a
helper application, I can put it on the website for download.

> TINC uses a TCP connection for control and a UDP connection for data
> from what I understand. You have also implemented a TCP only mode.
> 
> Have you ever thought of a UDP only mode?

Yes. However, tinc needs to exchange data with peers in a reliable way.
TCP is made for this, UDP is not. OpenVPN works around this by
re-implementing TCP on top of UDP. That adds a lot of complexity to the
code.

> I am asking this with the idea above(Peer-to-Peer) in mind. If there
> were a UDP only mode, the clients could start UDP hole punching (for
> TINC-UDP) in their NAT routers, so a user would not even have to modify

Re: Windows to Linux - ping-bug?

On Sun, Apr 29, 2007 at 03:52:41PM +0200, Florian Lagg wrote:

> I have encountered a bug using tincd with Microsoft Windows:
>  
> Below you'll find my Setup and my Logs.
> In short, i do the following:
> 1. office running tincd 1.0.7 and waiting for connections (no ConnectTo, but
> this does not resolve the issue)
> 2. the supporter starts up tincd 1.0.7 on windows (native)
> 3. ping from windows ("support") to the office: 
> Here the error occours: the supporter get's ping timeouts
>  
> possible Workaround:
> If i start an ping from Linux (office) to the Windows-host (support) the
> ping in the other direction (ad 3.) starts working. If there is more then
> one node the Windows-host connects to there must be an initial ping from
> every node!

This is probably caused by NAT. You'd either have to enable explicit
port forwarding of UDP port 655, or use the TCPOnly option to make all
VPN traffic go via TCP.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

On Sun, Apr 29, 2007 at 03:52:41PM +0200, Florian Lagg wrote:

> I have encountered a bug using tincd with Microsoft Windows:

Re: Sockets not non-blocking when compiling with MingW

On Thu, May 10, 2007 at 09:28:36PM +0200, dnk@... wrote:

> When tinc is compiled with MingW, sockets are not made non-blocking
> because O_NONBLOCK is not defined anywhere.
> 
> This leads to weird timeouts when one or more hosts part of a VPN are
> unreachable, because tinc hangs in connect() (and possibly other
> places as well).
> 
> This guy is probably experiencing this bug:
> http://brouwer.uvt.nl/pipermail/tinc/2007-April/001646.html
> 
> I've attached a patch that adds some win32-specific code to make
> sockets non-blocking. I've been using it for a couple of hours, and
> have experienced no problems so far.

Thank you for providing a fix for this issue! I committed the patch to
the Subversion repository. I'll try to release a new version of tinc
with this fix next weekend.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

On Thu, May 10, 2007 at 09:28:36PM +0200, dnk@... wrote:

> When tinc is compiled with MingW, sockets are not made non-blocking
> because O_NONBLOCK is not defined anywhere.
> 

AW: Windows to Linux - ping-bug?

> > I have encountered a bug using tincd with Microsoft Windows:
> >  
> > Below you'll find my Setup and my Logs.
> > In short, i do the following:
> > 1. office running tincd 1.0.7 and waiting for connections (no 
> > ConnectTo, but this does not resolve the issue) 2. the supporter 
> > starts up tincd 1.0.7 on windows (native) 3. ping from windows 
> > ("support") to the office:
> > Here the error occours: the supporter get's ping timeouts
> >  
> > possible Workaround:
> > If i start an ping from Linux (office) to the Windows-host (support) 
> > the ping in the other direction (ad 3.) starts working. If there is 
> > more then one node the Windows-host connects to there must be an 
> > initial ping from every node!
> 
> This is probably caused by NAT. You'd either have to enable explicit 
> port forwarding of UDP port 655, or use the TCPOnly option to make all 
> VPN traffic go via TCP.

TCP should be somewhat slower - so i don't like this option.

For UDP i have one more question:
Thanks for your quick answer.
I explicit forward TCP+UDP 655 from wan (office) to the supporter's laptop. 
The traffic from inside the supporter's network is routed without
limitation.
Isn't that enough? Must I have an additional port forward from inside the
supporters network even if there is no blocking router? Why is it working
after one ping (so the connection should be OK)?

Re: Windows to Linux - ping-bug?

On Mon, May 14, 2007 at 12:21:30PM +0200, Florian Lagg wrote:

> For UDP i have one more question:
> Thanks for your quick answer.
> I explicit forward TCP+UDP 655 from wan (office) to the supporter's laptop. 
> The traffic from inside the supporter's network is routed without
> limitation.
> Isn't that enough? Must I have an additional port forward from inside the
> supporters network even if there is no blocking router? Why is it working
> after one ping (so the connection should be OK)?

That's probably caused by a stateful firewall or NAT. Maybe your
iptables rules contain an INPUT or OUTPUT rule that block any packet
unless it is in state established,related? Or maybe the problem is at
the other end...

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

On Mon, May 14, 2007 at 12:21:30PM +0200, Florian Lagg wrote:

> For UDP i have one more question:
> Thanks for your quick answer.
> I explicit forward TCP+UDP 655 from wan (office) to the supporter's laptop. 
> The traffic from inside the supporter's network is routed without
> limitation.
> Isn't that enough? Must I have an additional port forward from inside the
> supporters network even if there is no blocking router? Why is it working

AW: Windows to Linux - ping-bug?

> > For UDP i have one more question:
> > Thanks for your quick answer.
> > I explicit forward TCP+UDP 655 from wan (office) to the supporter's
laptop. 
> > The traffic from inside the supporter's network is routed without
> > limitation.
> > Isn't that enough? Must I have an additional port forward from inside
the
> > supporters network even if there is no blocking router? Why is it
working
> > after one ping (so the connection should be OK)?
> 
> That's probably caused by a stateful firewall or NAT. Maybe your
> iptables rules contain an INPUT or OUTPUT rule that block any packet
> unless it is in state established,related? Or maybe the problem is at
> the other end...

I'll check this and post the results. Thanks!

 - 
Florian Lagg (http://www.lagg.at)

[Announcement] Version 1.0.8 released

With pleasure we announce the release of version 1.0.8. Here is a
summary of the changes:

 * Fixed some memory and resource leaks.

 * Made network sockets non-blocking under Windows.

This version of tinc is compatible with 1.0pre8, 1.0 and later, but not
with earlier version of tinc.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

With pleasure we announce the release of version 1.0.8. Here is a
summary of the changes:

 * Fixed some memory and resource leaks.

 * Made network sockets non-blocking under Windows.

This version of tinc is compatible with 1.0pre8, 1.0 and later, but not
with earlier version of tinc.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

Re: Sockets not non-blocking when compiling with MingW

On Mon, 14 May 2007 11:44:43 +0200
Guus Sliepen <guus@...> wrote:

> I committed the patch to the Subversion repository. I'll try to
> release a new version of tinc with this fix next weekend.

Thank you.