MTU issues

[dorian]

> On Tue, Dec 10, 2013 at 07:13:49PM +0100, dorian wrote:
>
>> For sure the problem is not a matter of MSS as http requests to the
>> "problematic" http servers opened new TCP sessions (I've seen full
>> triple TCP handshake starting with SYN packets)
> Ok.
>
>> It is also not a "general" GPRS transmission problem since other http
>> servers were available.
>>
>> According tcpdump output  ICMP Fragmentation Needed packets are sent by
>> clients (with src addresses of the clients) rather than TINC itself (I
>> understand that in this case the src IP should the router's one).
>> Btw: TINC is sitting at gateway.
> It depends on which interface exactly you ran tcpdump on. Tinc itself does not
> have an IP address, when it generates an ICMP Fragmentation Needed packet, it
> uses the destination address from the packet that was too big as the source
> address for the ICMP packet. So it might only look like it is from the client.
Sorry but I do not understand this explanation.

Clear is that "it uses the destination address from the packet that was
too big as the source" since this packet is to be sent to the originator
of the big packet to inform him that should resend shorter packets.
But the source address of the ICMP packet has to belong to the creator
of this packet.
So in case when it is TINC which creates the icmp packet it can use only
ones of the router's IPs.

Apart from above - I observed with tcpdump the interface connected to
the clients (LAN) rather than TINC interface.
So I should not see packets sent to the external hosts on this interface
if the packets are created by TINC.

BTW: in my setup TINC interface (tun device) has no IP at all - all the
traffic from LAN is routed via tunnel.
>
>> Down/up of the tunnel immediately removes the problem
>>
>> Therefore I assumed that there was a matter of MTU.
>>
>> But if MTU is dynamically adopted to the current connection state I have
>> no idea what to look for...
> It would be interesting to run tinc with the options -d5
> --logfile=/tmp/tinc.log for ten minutes or so, without sending any traffic over
> the VPN. Then check the logs to see what happens with the PMTU probes. It would
> be helpful if you could send a copy of that log.
Ok. I'll try to do this.
But cannot do it immediately since the problem is not a permanent one.
When GPRS connection is stable the effect does not appear.
> Instead of an MTU problem it could also be that the mobile provider is dropping
> (certain) UDP packets, as they might associate it with VoIP traffic which they
> might want to block. Using the TCPOnly option might help in this case.
>
Maybe this is good testing point...

But I assumed that the UDP/TCP transport is also dynamically replaceable
by TINC (same as MTU renegotiating for established tunnel)
Was I right?
Or maybe the kind of transport (UDP or TCP) is chosen only once at the
moment of tunnel creation?