> 1500 has always worked fine for me, as long as the stack wasn't buggy
> (like Trumpet 2.0b).
>
> >clients. This is NOT what PPP was designed for. It was designed for
> >client and server to negotiate agreeable protocol parameters.
Hmm. As the service provider, I might have a bit more knowledge about how
I want that link to perform, wouldn't you say?
Rather than relying on a user with 0 technical knowledge or someone elses
buggy defaults, I do indeed want to control the setup of the link, on both
sides, when I need to, without leading a clueless new user through the ins
and outs of editing the Windows 95 registry. It's a known bug with Win95
and yes, maybe I did mix MRU and MTU semantics. So what, I still want
control of both of them, both directions.
Makes a bit of sense, does it not? I have $500,000 (or more) worth of
terminal equipment, 24+ years doing datacomm and I think I might know how
to setup that PPP link just a little bit better than Mr/Mrs Newbie.
> Exactly.
Yes, in a perfect world, the RFC's make sense. In this one, they don't in
many areas. Ever wonder why AOL chose not to use "real" PPP?
Too much attention to "RFC", too little attention to the real world we
live/work in.
Nuff said,
Back to work.