(Good news: I finally got it working.  Manuel's suggestion worked---my
brain just wasn't working.  I was setting those options on the gateway,
not on the client.  (sigh)  Now things seem to be working much more
nicely.  Both ftp to ftp.netbsd.org and http to www.netbsd.org are
working.)


> > I dropped in a -current kernel (snapshot from Dec. 1).  It seemed to have
> > trouble with my old LinkSys (err, DLink? I forget which) ethernet card
 [...]
>
> Hmm.. Well thats a seperate issue, we (most likely someone moew

Indeed.  One thing at a time.  But running current is going to have to
wait if it doesn't like my ethernet card.  (^&


> knowlegable than me) can help you deal with it later.  I upgraded my
> gateway to -current just to get the in-kernel pppoe support.  Its supposed
> to be much more efficient than a userland solution like mouse-pppoe or
> rp-pppoe.

How much of a difference does it make if the machine's a PII 233, with
relatively light duties other than playing network gateway?


> > > However, as an interim solution you can avoid getting fragments from
> > > ftp/www.netbsd.org by artificially lowering your MSS and/or by working
> > > around the bug w.r.t. TCP options.
> >
> > Can you define MSS for me?
>
> Sorry, sure.  TCP MSS is "maximum segment size".  It's an option that can
 [...explanation of MSS and MSS-related problem...]

Ah, thanks.  This clarifies things quite a bit.


> I'd suggest you use the rp-pppoe package.  It's very popular (mostly used
> on Linux) and has a few extra nicities, including TCP MSS clamping.
> However, if you're planning on upgrading to -current and using its

I'd like to go that route.  I meant to start my old machine tracking
-current a ways back, but got the machine entrenched in a semi-vital role.


> > > problems all interacting here...  Its unfortunant that, since most of the
> > > world is connected to the net over a 1500 mtu link, people with a lower
> > > MTU discover (and have to deal with) the bugs :)
> >
> > I've never had a problem before---but then, I didn't use NAT before.  (^&
>
> Even without NAT, try going to a broken site like www.bmo.com without
> doing MSS clamping or setting tcp.mss_ifmtu to 1, it'll just hang...

Really?  Ick.


> Anyway, if you just do a "route change default -mtu 1480" from one of your
> clients behind the gateway (assuming its a NetBSD machine), TCP from that
> machine should work fine.  It's not an ideal situation (the lower the MTU
> the more overhead), but its a simple temporary work-around.

(nod)


Ah well.  Everything is well in Pleasantville again.  (^&  Next up is that
matter of dynamic configuration and then give -current another shot.

Thanks again to all for their help.


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu