Tom Oehser <[EMAIL PROTECTED]> wrote:
>
> The problem is, when I go directly from the PPP connected machine, the
> two ends negotiate the MTU at 296 in the first place.
I think your two ends are *trying* to neogitate the MTU, but failing.
My meager understanding of this (I haven't read the relating RFC's) is
that there is not a specific protocol-negotiation option that has been
added to TCP that negotiates MTU size. Rather, it is "discovered" as a
side-effect of the use of DF (don't-fragment) packets and ICMP messages
that they elicit (or don't).
> When I go from the forwarded machine, the two ends negotiate an MTU of
> 1500, and the path-MTU process is supposed to do the further downward
> negotiation.
I don't think there's any such "negotiation" that goes on. The two ends
merely send unfragmentable packets, and if they work at a size near
1500, that's what they will continue to use. If one of the routers in
between complains that it can't send the packet, then the side sending
the large packet will refragment with a smaller size, and try again.
So you see, you don't really have the type of control you need in order
to solve this problem:
You control this part ------------------------+
/----|------\
+-------+ ............. +--------------+ +-----------+
| Dest. |---. Internet .--| Term. Server |--< PPP >--| Masq. Box |
+-------+ ............. +--------------+ +-----------+
\----------------------|--------------------/
+---- This part is NOT under your control.
Your destination host sends a large, unfragmentable packet, across the
internet, and it reaches the Terminal Server on the other side of your
PPP link. Your terminal server knows the MTU size that you negotiated
with it, when you connected. It knows that the packet will not fit. It
knows that the packet cannot be fragmented, because it has the DF bit.
So, before your Masq box even *sees* the packet, it gets rejected on the
other side of the link. Now, that server SHOULD send back an ICMP-
unreachable response to the destination, but for some reason that you
have no control of, that packet gets lost on the way back to the
destination, probably because the destination is behind a paranoid
firewall that drops all ICMP messages. Try pinging the destination to
see if that's true.
So, as I understand the problem, you don't really have much hope of
fixing this, without contacting the remote system administrators and
getting them to fix the problem on their end.
Of course, I could be completely wrong about this. But as I've found in
the past, the best way to get correct information is to post incorrect
information, and let someone correct you. Someone always does. :)
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Nothing takes the taste out of peanut
sometimes known as David DeSimone || butter quite like unrequited love."
http://www.dallas.net/~fox/ || -- Charlie Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
