Linux 2.6.17 & Linux 2.6.20 I encountered a problem recently with a server that raised my awareness of Path MTU Discovery. The server was sending HTTP replies where the DNF flag bit of the IP packets was set. A downstream server/router returned an ICMP packet "Fragmentation Required MTU=1300". Initially the firewall was blocking this ICMP message and the transaction failed since all the outbound packets> 1300 were dropped. Opening up the firewall to pass the ICMP packets back to the server resulted in no difference in behavior and the transactions still failed. Experimentation on another Linux system showed a similar behavior. Just guessing I turned on 'tcp_mtu_probing'. This seemed to result in the 'correct' behavior of the TCP stream. Once it received the ICMP message from downstream it reduced the packet length to < the MTU. However it seemed to default to a 562 byte MTU and not the 1300 as requested. Another experiment was to just turn ON 'ip_no_pmtu_disc'. This resulted in outbound packets without the DNF flag set and the transactions worked ok. On both systems I checked tcp_mtu_probing was ON and ip_no_pmtu_disc was OFF by default. It appears that in this case TCP doesn't work correctly over the WAN? In the interest of safety I turned ON 'ip_no_pmtu_disc' on the web server. I believe this just makes it work in the 'old fashioned' Internet way allowing routers to fragment the packets on the fly. Is this a real problem with the Linux network stack or am I just doing something wrong? Thanks in advance. Snafu _________________________________________________________________ Change the world with e-mail. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ChangeWorld-- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
