<br><br><div class="gmail_quote">On Sat, Jan 1, 2011 at 2:47 PM, Guus Sliepen <span dir="ltr"><<a href="mailto:guus@tinc-vpn.org">guus@tinc-vpn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>If MTU probes are not responded to, then yes, tinc will fall back to TCP and<br>
this will increase latency and decrease throughput. It would be interesting to<br>
know why the MTU probes or the responses to them are not received. Perhaps you<br>
can store tinc's debug output (using the --logfile option) and at the same time<br>
run tcpdump on the public network interface to see what is being sent and<br>
received?<br></blockquote><div><br></div><div>Sure I can do that. I'll try to get it done this week. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>MTU probes will be attempted again after one hour by default. It is tied to the</div>
session key timeout, so you can let tinc try more often by adding KeyExpire =<br>
600 to tinc.conf for example. Still, this is suboptimal of course. I will<br>
change it to keep sending MTU probes every PingInterval, just like it does when<br>
MTU probes did not fail.<br></blockquote><div><br></div><div>Ah okay. I definitely didn't observe for an hour. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br>
</div>Hm, that might indicate a bug in tinc. However, I could not reproduce it with<br>
two Linux machines. It could also be a problem with some stateful firewall rule<br>
or a router doing NAT that keeps an old mapping around for 30 seconds.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Every time when the MTU probing fails, I see latency between 700 - 1000 ms<br>
> with 32 byte pings over a LAN.<br>
<br>
</div>That in itself is way too high, but this is a problem many people have seen on<br>
Windows.<br>
<div class="im"><br></div>Yes, the idea is that tinc should figure out the best way to connect to other<br>
nodes on its own of course. I'll try to reproduce the problem with a node<br>
running Windows, maybe that makes a difference.<br></blockquote><div><br></div><div>Yes this whole thing could very well be related to a Windows client and perhaps it's related to some of the other complaints I've also seen of other Windows users report nasty latency.</div>
<div><br></div><div>I will see if I can reproduce the effect with a Linux client too. </div><div><br></div><div>-Donald</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
Met vriendelijke groet / with kind regards,<br>
Guus Sliepen <<a href="mailto:guus@tinc-vpn.org">guus@tinc-vpn.org</a>><br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAk0fhM0ACgkQAxLow12M2nvkMwCfcojnEMNqaTuBp1B7dDI3ymT8<br>
ILsAnjGeAyn6QMCykwbX/rNGebQwzfCc<br>
=hODH<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a><br>
<a href="http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a><br>
<br></blockquote></div><br>