PMTUDiscovery vs ClampMSS

[Guus Sliepen]

On Mon, Dec 13, 2010 at 02:06:43PM -0600, Rob Townley wrote:

> >> Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes.
> >> When the server does not receive a PMTU request back from one of the
> >> clients even when the packet size is very small (say 164), then it
> >> reverts to TCP.
> >
> > That means that communication with the client via UDP is not possible.
> 
> The log files from the clients indicate the MTU sizes are being sent
> back. i need ethereal or tcpdump or something.

Indeed, the packets could be dropped anywhere.

> These same machines in the same network going through a different tinc
> "server" will often get sub millisecond response times, but sometimes
> get as slow as 1 second of latency for each and every ping.  So i have
> a cron job on that tinc server that restarts tinc daemon every hour.
> i noticed one difference is that the broadcast address is not set on
> the tcp only non-working tinc ip server.

Is this a Windows machine? I think the problem then is the same one that
other's have experienced with Windows, a possible suspect is the TAP-Win32
driver.

> >> It takes a very long time to do simple pings (1 second or so), so i
> >> wonder what else i can do?
> >
> > Can you check whether non-VPN traffic from the client to the server is slow as
> > well, or maybe if there is a high level of packet loss?
> 
> i have 3 public internet IP addresses sitting behind a single cable
> modem.  Cable Modem goes to a switch and from the switch to 3 NAT
> devices.  One firewall is dedicated to wireless laptops.  The wireless
> laptops can ping google.com in 20ms, but will often require 1000ms -
> 4000ms to ping the tinc server hosted on the vyatta box.  i wonder if
> by the time the laptop responds with an acceptable MTU, the server has
> already lowered the MTU that it does not read the entire packet.

During PMTU discovery, tinc will send all packets that are larger than the
lower bound via TCP. After tinc has found the correct MTU value, it will
fragment ping packets like any router should do for packets that are larger
than the MTU but do not have the DF bit set.

In any case, tinc will never just truncate a packet. It will either be sent or
not. If it is not sent due to MTU problems, tinc will generate an appropriate
ICMP message in response. Also, the receiver accepts all packets, even if they
are larger than the PMTU.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20101213/703933ae/attachment.pgp>