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]
