I'm trying to debug some network problems and I'm confused by what I'm seeing. I'm no networking expert and RFCs often make my head hurt. Sorry, but this is a bit long, but the question will be:
Should ICMP "Fragmentation needed" messages be returned when sending a too-large packet with the "Don't Fragment" bit set to zero? I'm trying to determine at which device a TCP connection is failing. Basically, who is at fault for the failed connection. Here's the long Details: I'm having a problem with SMTP where the client starts off sending small packets and then sends large (MSS sized) packets. That's normal for SMTP, of course. What's happening is (I'm assuming) the large packets are too big for the network. An ICMP message is sent back indicating this, but the sending mail client doesn't drop its packet size and instead continues to try and send the large packets. The connection is finally lost. It's my basic understanding that the way It should work is: 1) On initial connection smtp server sends back SYN,ACK and includes MSS size. In this case smtp is sending back MSS=1460. 2) client sends packets with "Don't Fragment" bit set and a payload size up to the MSS size. 3) a router along the way detects the packet is too big for a segment and sends back ICMP message saying "Destination unreachable" and "Fragmentation needed". Included in the ICMP is the "MTU of next hop" which tells the new MTU size to use (which it can then use to figure out the MSS payload size). The above sound correct? Now comes the confusion: I've used ethereal on two different mail clients. Outlook and A Printer/Fax/Scanner all-in-one device that has a network connection and an smtp client. That device scans the documents like a fax, but then sends it as a tiff file via smtp. Outlook mail client: It has no problem sending messages. It sends packets at the MSS size (1460) and the packets do indeed have the "Don't Fragment" bit set. An ICMP packet is returned saying "Fragmentation needed" and then the Windows outlook client drops it's MSS to 946 and mail is sent without a problem. According to Ethereal, the ICMP message shows that the "MTU of next hop" is zero. I guess that just means the the router has not implemented RFC 1191 and not really a problem. The Windows reduction to 946 seems like a good guess, perhaps. Now the all-in-on printer/fax/scanner: The connection is setup the same way with the smtp server sending MSS=1460. Unlike outlook, the printer is NOT setting "Don't Fragment" when sending packets to the smtp server. The printer sends data fine with small packet sizes (it seems to send the MIME data one line at a time!). But then it sends a large packet (1460). ICMP is returned with "Fragmentation needed" and the smtp machine starts sending TCP Duplicate ACKs because that large packet did not make it. But instead of reducing the MSS size, the client (printer/fax) resends the packet with the same 1460 size. That process continues for a few attempts and the the printer gives up because it's no longer getting any ACKs back. So, I'm not sure if the problem is with the printer/fax device or with the router sending the ICMP messages. On one hand the printer/fax mail client is NOT reducing its packet size after receiving the ICMP message. On the other hand, the printer/fax client is NOT setting its "Don't Fragment" bit so it may be expecting that the router will fragment it's packets if they are too big. But I don't know the protocols well enough to know the right answer. So, that's my first question. Is the ICMP message in error since the "Don't Fragment" bit is not set? The setup is ADSL modem connected to a D-Link NAT/Switch -- it makes the pppoe connection and then provides NAT'ed internal LAN. The problem, of course is the source address for the ICMP message just shows 192.168.0.1 which is the D-Link box. So I have no idea where the ICMP message is really coming from. Yet another good reason to use Linux as the NAT device. I also remember something about ADSL requiring a smaller MTU size. The printer, of course, has no way to manually adjust the MTU size. Still another reason to use Linux -- in the iptables rules I believe I could simple set the reported MSS size at connection to a lower value. The D-Link DI-714 NAT/switch has no way to adjust the MTU. Thanks, -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
