Armen,
    Thanks for your comments....there's alot here to munch on..

>may i comment on this thread: "co-operation makes it happen"

yep!

>i thought the ping of doom thing was an extra-large ICMP packet...telnet
>is tcp..(?)
>If the NAT functionality is breaking, that should be killing the
>routing on the internal network, not pppd. afaik, ppp0 is independant of

Yes, that IS the incongruous part of it!  Maybe Dave can explain a little
about what that is, but as you may have already seen, his suggestion WAS
the fix!  The thing thats upsetting about that is why it would cause the
Linux processes to kill the pppd.  And, I spent a little time looking for
any message or whatever, and found nothing.  That makes it look just like
the link was being closed normally.  It should be interesting to hear what
Dave may have to say about what RFC1323 is about.

>eth0 (ethernet on linux) and ip-nat (and/or ipf) simply routes data
>between the two network interfaces. (unless ip-nat is somehow built into
>pppd on linux that i don't know about)

No, its not.  But it does require a kernel rebuild to support it, so it
is pretty close to the heartbeat.  I'm not sure where that stands now, 
but I think the later kernels have the NAT capability, or at least the
hooks for it, whatever they call it.  When I first started using it, a
special build was required for it to function.  That may no longer be 
the case.

>i dunno about the rfc thing, but you really should look for a verbose
>option in pppd on the linux box to see exactly what is going on that
>causes the problem. i think someone mentioned "debug", which would be cool
>to start with.

Yeah, if I knew how to use it effectively.  Tell ya' what I'd like to
do: boot NetBSD and don't enter the sysctl.  Have tcpdump on Linux watch
the ppp0 device and see what happens, and watch the ethernet too. I did
grab a bunch of packets since I had it watching the ethernet while I
tried it earlier.  Thats when I saw my named wasn't working too!  Yeah,
first I thought I had screwed something up on the NetBSD resolv.conf as
it kept telling me it was getting no response from the nameserver.  Darn!
So then I tried it from my laptop (running Linux) and it told me the same
thing.....hmmm.

>Also, you mentioned you attempted to telnet from your netbsd box to the
>outside world, and that "killed" the connection.  did you try any other
>tcp protocols like ftp from the netbsd box, or mosaic from the netbsd box?

No I didn't.  I was using the generic kernel, so X wasn't there.  And,
the masquerading code won't handle ftp's properly (well, it will, but not
this version I have running here; its too old).  Yeah I know, I really
need to fix that.

>i couldn't tell if the ftp and mosaic you mentioned were from the netbsd
>box or other machines on the network.

Mosaic or other browser like from a MacOS or Linux box was fine, yes.

>just checking, but did you give each machine a unique ip or is ipnat/pppd

Oh yeah, every machine I have has its own IP address on my private net
in reserved address space (192.168.....).  The Linux box/NAT hides my net
behind that one valid IP.

>like ken said, this problem is a lot bigger than you think it is. windows

No, it IS now shown that it was precisely what I said this morning, and 
that is, that NetBSD is/was doing something different than all the rest, 
and it was very likely that Dave's answer just might be the key!  And it
was!  All of them, not just Linux, have the BUG, to use Dave's term.  
Fortunately, NetBSD has the ability to turn that off, so now it works, 
and doesn't kill it.  Problem is, whenever they all do 1323, it'll come
back! :)

>and linux aren't perfect, and a lot of software is written specifically 

And I don't think anyone ever said that.  What I did say was that it was 
far more likely that NetBSD was doing something none of the others was 
doing,
since it spawned the problem when none of the others did.  As it turns out
that was exactly the case.  And its a good thing for me that Dave pumped 
me
to try that sysctl, since I seemed to have missed it the first time.

>oh yeah, upgrade that ipmasq code. (keep backups of whatever, too) :)

YAH, I had planned to do that awhile ago, but got into other things and
never did get my hands on a new distribution.  Plus, I wanted to get rid
of that old box, and put the MB'd in a little tower, and that never got
done either.  That old box has a dying fan in the power supply, and I 
need another spot for a drive, etc, etc, etc....You know how that goes.

What was it Steinbeck said, "the best laid plans of mice and men often
go astray"!?  I think that applies here....

:)
Paul