MTU issues

[dorian]

Thanks a lot for info about MTU.

Anyway the answer creates next doubts concerned the nature of observed
problem.

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)

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.

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...

Any ideas?

Rgds,
Dorian


>> Sorry for disturbing you if the issues has been discussed earlier but I
>> cannot find clear explanation of my problem.
>>
>> Tracing the tinc logs (a debug level) I have found that the MTU value of
>> the connection is determined and chosen at the beginning of the tunnel
>> setup.
>>
>> My question is following: is the MTU value renegotiated / rechecked
>> after the tunnel is established?
> Yes, by default every minute there is a check to see whether the MTU value has
> increased or decreased. You can make the interval between checks short using
> the PingInterval option.
>
>> The question concerns the following observation.
>> After successful connection everything is working correctly.
>> Unfortunately since I am using tunnelling over GPRS media -for some time
>> the quality of the connection is degraded.
>>
>> When it happens I am observing icmp "fragmentation needed" packets sent
>> from clients to some http server.
>> It looks like the servers ignore this kind of icmp messages (maybe
>> because of improper firewall?) and the packets sent to clients are never
>> fragmented.
>> As the result - for the clients some part of the web becomes inaccessible.
> Tinc also tries to clamp the MSS value of TCP connections, but that only works
> at the beginning of a TCP connection. If such a connection is kept open for a
> long time, and the PMTU changes inbetween, then tinc can only send ICMP
> Fragmentation Needed packets. If those are dropped by a firewall, there is not
> much tinc can do.
>
>> Manual tunnel down/up fixes the problem immediately since (probably - I
>> didn't compare them) new lower MTU is chosen.
>>
>> I am wondering if it is possible to make MTU renegotiation to be automatic?
> It is automatic, what you can change is the time between PMTU probes.
>
>
>
> _______________________________________________
> tinc-devel mailing list
> tinc-devel at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel