On Wed, Oct 13, 2010 at 10:25 AM, Guus Sliepen <[email protected]> wrote: > On Tue, Oct 12, 2010 at 05:44:47PM -0500, Rob Townley wrote: > >> I know MTU is Maximum Transmission Unit, but what is a "minimum >> Maximum Transmission Unit"? >> Shows up in tinc.log as "Packet for PC5 (ip.x.y.z port 655) larger >> than minimum MTU, forwarding via TCP". > > Tinc tries to discover the actual MTU of the path between two nodes by sending > probe packets of various sizes. It can detect a lower bound and upper bound > for the true MTU. The lower bound (minimum MTU) is the biggest probe that has > been succesfully sent and received back, the upper bound (maximum MTU) is > decreased whenever a RFC compliant router sends an ICMP Packet Too Big message > in response to a probe that is larger than the true MTU.
i am not sure i understand, i would have thought there is minimum packet size as there is a minimum ethernet size. > > Tinc will only send UDP packets that are smaller than the minimum MTU to the > destination, because there is no guarantee that larger packets will arrive. > When the packet is bigger than the maximum MTU, it will either send its own > ICMP Packet Too Big messages, or fragment the packet (only for IPv4 packets > without DF bit set). For packets that are within the minimum and maximum MTU, > it will forward packets via TCP. Again, this just seems backwards, i will have to research more. > > If UDP communication is not possible, no probes will succeed, so the minimum > MTU will be 0 and the maximum MTU will be 1514 by default, and all packets are > thus forwarded via TCP, as it should. > > Tinc keeps sending probes after the real MTU has been determined (by default > once a minute) to check whether UDP communication is still possible. > >> Ping times between tinc nodes are outrageously slow at times ... >> greater than 1 second. Sometimes, it is even 5 seconds. This may have come across as too negative. i think tinc is cool and enjoy it, i am frustrated i have not figured it out yet. > I understand. It could be that temporary disruptions of the network that > caused > the MTU probes to fail, resulting in tinc falling back to TCP. It should > normally try to reestablish UDP connections after an hour. Is there some way to ask tinc to reestablish UDP connections much more frequently? The Tablets (including wireless card) may go into a low power mode on battery, but the network itself is never down. > > I do not know why it would be so slow. But others have experienced such > behaviour in the past as well. In any case, could you run "tincd -n <netname> > -kUSR2" on the tinc server and send me the results? Attached are too files, one is when it seems normal. The other is probably when the multisecond echo requests occur.
BUGS-Jitter.log
Description: Binary data
BUGS-Jitter-pmtu.log
Description: Binary data
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
