MTU issues [closed]

[dorian]

Thanks a lot for all the replies.

Owing to them I realized that the problem I've found is NOT TINC-related.

The key factor is that this a client who sends ICMP Fragmentation Needed
packets (the source address of the packets is client's IPs).
So both TINC and router are working perfectly.

It is a problem of the client's device that for some reasons it drops to
lower MTU.
Now I am working on it.

Sorry for all the mess but seeing MTU problems I focused on typical
bottleneck concerned with tunnelling and for some reasons I switched of
the thinking...

Additionally the client was making connection via unstable GPRS media
which again made me to bound my problem with TINC.


Regards,
Dorian

>
>>>> 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.
> No, if tinc itself generates an ICMP packet (inside the VPN) then it will have
> the destination address of the packet that was too big as the source address.
>
>> 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.
> Correct, in that case those ICMP packets were not generated by tinc, but by the
> client itself. Although it would be strange for the client to do this, since it
> is unlikely that the MTU of the LAN interface is smaller than the PMTU to the
> web server...
>
>> BTW: in my setup TINC interface (tun device) has no IP at all - all the
>> traffic from LAN is routed via tunnel.
> Could you send us the output of "ifconfig -a" and "netstat -r -n" from the
> computer running tinc, so we can see exactly how it is set up?
>
>>> 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?
> Tinc falls back to TCP if there is no response at all to its MTU probes. This
> should happen dynamically, not only at tunnel creation. However, if there is
> less than 100% packet loss or if for example the ISP drops only UDP packets of
> a certain size, this is not seen by tinc as a reason to fall back to TCP.
>
>
>
> _______________________________________________
> tinc-devel mailing list
> tinc-devel at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel