I understand it better now.

The problem is, when I go directly from the PPP connected machine, the two
ends negotiate the MTU at 296 in the first place.  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.  Unless the
forwarding code can adjust the initial negotiation, I'm screwed.  I would
like it to do just that- it is, after all, in the middle of the (296) PPP
and the (1500) ethernet- so it KNOWS, or COULD KNOW, that the real limit
is 296... but, it would have to edit the packets in the first place- as
the eth0 masqueraded machine *doesn't* know this. -Tom

On Sun, 27 Dec 1998, Ely Wilson wrote:

> Date: Sun, 27 Dec 1998 23:18:25 -0700 (MST)
> From: Ely Wilson <[EMAIL PROTECTED]>
> To: Tom Oehser <[EMAIL PROTECTED]>
> Subject: Re:  [masq] MTU/MRU, always-defrag, masq not working for some URLs
> 
> > It is supposed to be always-defragging, and in some combination, doesn't.
> > 
> > The "ip_input.c" is going to take me well into the next century to
> > understand well enough to contribute to fixing the problem, though.
> > 
> > I'll let you know when I have tcpdumps that clarify the exactitude,
> > what I've posted so far is useless as far as really digging into it.
> > 
> 
> Well, whatever comes about keep me informed.  I had assumed it was all
> timeout problems (at least that was my problem, that 1 meg might bottleneck
> at a slower connection.)
> 
> This is probably resultant to my lack of understanding of the inner net
> workings of the kernel.  It could be that I shouldn't experience this at
> all, but it seemed quite reasonable.
> 
> As I don't have A Real Network(tm) to play with (just a rigged PLIP based
> net on ip masq) I can't very well isolate the problem any farther than
> 'using plip over a 56k connect, with two systems connected via PLIP cables'
> 
> Anyhow, I'm interested in anything you find out, and willing to dive into
> the code at any time.  Hmm, maybe something to do on my day off.
> 
> 
> ----------------------------------------------------------
>  ---- ely ---                   <[EMAIL PROTECTED]> ------
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]

Reply via email to