Tincd cannot flush and resets the connection

[Hans de Groot]

Hi,

Thanks for your reply.

I tried your settings but it did not help.

I switched back to a direct mysql connection from the master001 to the
client001 via port forwarding and gues what? I have the same problem
here. (some times it works sometimes not)

Only there is a difference, only the mysql session gets stuck,. ping and
other connectivity keeps working. In the tinc setup the whole tinc
interface/route got reset. (network unreachable)

So I gues tinc is not to blame here. but I have no clue why this happens.
I am using perl/dbi to connect to remote mysql servers for ages. It
almost seems like there is a content sniffing firewall that blocks
things, but since tinc encrypt things it could never know about the
mysql data over a tinc line. 

Anyway thanks again for your reply.

Regards

Hans de Groot








On Sun, 6 Sep 2009 22:10:35 +0200
Guus Sliepen <guus at tinc-vpn.org> wrote:

> On Sun, Sep 06, 2009 at 12:20:57PM +0200, Hans de Groot wrote:
> 
> > Now I also have 4 clienst that conenct from my home which is behind nat
> > and when using netstat I see 4 connects from my ipat home to poort 655
> > on the master.
> > 
> > I can ping al 4 the clients  (on the internal tincd ip numbers) from the
> > master en vice versa. I can also ping all the other tincd ipnumers
> > 
> > But when I set up a mysql connect (ie mysql -h client1 ....)
> > problems start.  This is very unstable. sometimes it connects and I am
> > in the msql client. Sometimes I can issue a use msql and it work or
> > sometimes it allready fails. and sometimes I can even get to the select
> > * from part and have the results (many times in a row or sometimes just
> > once and it gets stuck.
> > 
> > In debug mode tincd tells me it could ot flush data from the master in
> > xx seconds and restarts/reset the connection and ping works again.
> 
> You are using TCPOnly, and apparently the TCP buffers are full. This is
> probably because MySQL sends a lot of data at once, and the kernel does not
> know the real bandwidth of your tunnel yet, and sends everything to tinc in one
> go. Tinc tries to send it over its tunnel, filling the TCP buffers, but since
> it takes a while before the other side ACKs it, tinc cannot send anymore. There
> is a check in tinc to drop connections that are "stuck" as far as it can see.
> This causes a restart of that connection, and it will probably result in the
> very bad performance you experience.
> 
> There are some changes in the git repository already that might alleviate this
> problem, but I do not know what you can do with tinc 1.0.9 except adding
> traffic shaping with iproute, or by decreasing the size of the TCP buffers:
> 
> echo 4096 16384 32768 >/proc/sys/net/ipv4/tcp_wmem
> 
> If the latter helps, I can try to automate this in tinc.
> 
> > It seems I can make any connection from the client to the master but not
> > from the master to the client.
> > I seems like the master gets confused (sometimes) where to send the data
> > (or where to set up a new tcp session) My clients are behind a masq
> > firewall and are unreachable from the outside. 
> > Ping always works but this is icmp. 
> 
> If your clients are behind a masquerading firewall, then the tincd on the
> server cannot set up a TCP connection with the clients of course. But once the
> tincds on the clients have made a connection to the server, the server should
> be able to connect to the clients without problems via the tunnels. Unless the
> clients themselves run some kind of firewall that block incoming connections
> from the VPN interface.
> 
> > client001
> > Cipher = blowfish
> > Compression =0
> > Digest = sha1
> > IndirectData = no
> > Port = 655
> > # hier de echte subnet mask waarden gebruiken
> > Subnet = 5.10.22.0/24
> > TCPonly = Yes
> 
> If you use TCPOnly = yes, IndirectData is always set to yes as well.
> 
> -- 
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>

--- 
Hans de Groot 
Email: hansg at dandy.nl   www: http://www.dandy.nl