> > 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.
no no- I meant, *the initial MSS negotiation*- which DOES work, even if
the ICMP based path-MTU is broken. There are *2* negotiations:
1) MSS (maximum segment size), negotiated by the endpoints
2) path-MTU, using ICMP, involving intermediates. ICMP code 3 type 4,
yes, the DF message.
What I'm saying is, *if I go directly from the PPP connected machine*,
the *initial* mss negotiation negotiates 296, and *it works*.
*if I go from the eth0*, doesn't work, because of ICMP filtering, and
because the MSS negotiation (*not* path-MTU) settles on 1460.
*SO*, what I'm suggesting, is not directly a fix of the (broken on the
*other* end) path-MTU, but a *modification of the MSS*.
> 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
Again, there are *2* things happening: SYN->MSS at the beginning of the
connection, and path-MTU using the DF and ICMP. The path-MTU is broken,
*but the MSS isn't*!!! So! If the *initial MSS* was adjusted, it would
work around the problem. Yes!
> 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
But that ignores my point. If the initial connectiion sets up the MSS,
*within the part I control*(Yes!), then it *won't have to DO this*!!!
dest ---- internet --- term server --PPP-- masq box --eth0-- my other box
^known 296 ^known 1500
The masq box *knows* that the PPP is 296. It forwards the initial stuff
from my other box, with MSS=1460 (NOT path-MTU). If it adjusts that down
to 256, the path-MTU will be a MOOT POINT, because the ENDPOINTS will have
already NEGOTIATED the INITIAL MAXIMUM SEGMENT SIZE to LESS than the
problem size!
> 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.
We have no hope of fixing the path-MTU problem.
I don't see why we can't workaround it by adjusting the MSS downwards.
>
> 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. :)
-Tom
>
> --
> [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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
