On Sat, Sep 22, 2001 at 01:48:23PM -0500, Frederick Bruckman wrote:
> On Sat, 22 Sep 2001, Manuel Bouyer wrote:
> 
> > On Fri, Sep 21, 2001 at 08:57:48PM -0500, Gan Starling wrote:
> > > [...]
> > >
> > > gus# ifconfig ppp0
> > > ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1514
> > >         inet 12.87.99.132 -> 199.69.200.57 netmask 0xff000000
> > >         inet6 fe80::203:47ff:fea0:4927%ppp0 -> :: prefixlen 64 scopeid
> > > 0x3
> > > gus#
> >
> > This 1514 is *very* strange, I would have expected it to be 1500.
> 
> But not unusual. This from NetBSD-1.4.3 connected to an ISP's
> commercial terminal server:
> 
> fredb@handy-> ifconfig ppp0
> ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524
>         inet 207.229.133.236 --> 216.80.19.17 netmask 0xffffff00
> 
> and it works fine. (They use several different brands -- Livingston,
> Lucent, 3com -- and it's always the same.)
> 
> > Maybe your machine sends too big packets, and the remote end fails
> > to fragment is ?
> 
> I seem to remember that this was mentioned on a "local", Enteract
> newsgroup, and the explanation was, that it was to leave room to
> encapsulate a full ethernet frame + ppp headers.

Hum, I don't think ppp headers are accounted in the MTU presented by ifconfig
(it says 1500 for ethernet, not 1514).
With this, the NetBSD tcp stack will send 1524-bytes pakets, which will have to
be fragmented when going to some other media (e.g. ethernet).

> 
> My point is, it's only a problem for "deflate", and "deflate" has
> other bugs, too (PR kern/8846).

It can also be a problem if the remote end of the ppp connection can't properly
fragment. The problem may not appear on windows because the max size of a TCP
packet isn't related to the MTU of the local network (if I understood properly
some other threads about MTU :)

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--