| 1 |
On Sunday 01 Sep 2013 08:40:20 Grant wrote: |
| 2 |
> >> How is PMTUD enabled/disabled on Gentoo? I've recently been made |
| 3 |
> >> aware of the existence of MTU and I'm wondering if mine is set |
| 4 |
> >> properly for a cell phone tethered connection. |
| 5 |
> |
| 6 |
> Thanks Mick. Can you generally rely on PMTUD to set the MTU optimally |
| 7 |
> or should this be experimented with when changing connections? |
| 8 |
|
| 9 |
Short answer: default Linux machine settings behave properly as network |
| 10 |
devices and acknowledge packets larger than their MTU value with the |
| 11 |
appropriate response. |
| 12 |
|
| 13 |
Longer answer: |
| 14 |
|
| 15 |
Communications between IPv4 end points use PMTUD by setting a Don't Fragment |
| 16 |
(DF) bit in the headers of the outgoing packet. If a router/server along the |
| 17 |
path has a smaller MTU, it will drop that packet and respond with an ICMP |
| 18 |
'Destination Unreachable -- Fragmentation Needed' packet including its smaller |
| 19 |
MTU value. Upon receiving this smaller packet value the initiating host will |
| 20 |
dynamically reduce the size of the outgoing packets, until the packet arrives |
| 21 |
at its intended destination. PMTUD should always be switched on in any well |
| 22 |
behaving network implementation, but here's the rub: some network nodes, |
| 23 |
firewalls, servers are configured to never respond with *any* ICMP packets |
| 24 |
(because they think that this is a way to avoid DDoS problems and the like). |
| 25 |
Therefore, the initiating host keeps sending large packets never knowing that |
| 26 |
they are dropped on the way. This network problem is known as a PMTUD black |
| 27 |
hole and is explained better here: |
| 28 |
|
| 29 |
http://tools.ietf.org/html/rfc2923 |
| 30 |
|
| 31 |
Some MSWindows servers were notoriously bad at this, but I think that modern |
| 32 |
configurations have corrected their buggy ways. Linux machines have PMTUD |
| 33 |
switched on by default and behave properly. |
| 34 |
|
| 35 |
|
| 36 |
If you are still troubled by the proxy connection stalling problem, have you |
| 37 |
tried transferring large files over the network using scp/sftp to see if you |
| 38 |
are also getting similar symptoms? This would isolate it to the application |
| 39 |
level (squid) or if the problem remains would point to network configuration |
| 40 |
issues. |
| 41 |
|
| 42 |
-- |
| 43 |
Regards, |
| 44 |
Mick |
Archives