may i comment on this thread: "co-operation makes it happen"
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
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)
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.
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?
i couldn't tell if the ftp and mosaic you mentioned were from the netbsd
box or other machines on the network.
just checking, but did you give each machine a unique ip or is ipnat/pppd
crashing because two have the same?
like ken said, this problem is a lot bigger than you think it is. windows
and linux aren't perfect, and a lot of software is written specifically 
tailored to get around bugs in other software. NetBSD might not have done
that. not NetBSD's fault...
oh yeah, upgrade that ipmasq code. (keep backups of whatever, too) :)
good luck,
  - a

On Wed, 26 Nov 1997, wb2oyc wrote:

> Jason,
>     I think, and so does Dave, that you're closer to the source of the
> problem with this line of thought!  more....
> 
> >Remember the "ping of doom"? Pings sent to a machine that were larger 
> >
> Yep.
> >
> >Likewise, it could be that something that NetBSD is sending something 
> >(either valid or invalid) that exposes a bug in linux / pppd. 
> 
> Right on!  And Dave suggested a sysctl regarding RFC1323 to disable
> something that it may be doing.....precisely!  Oh, its not the Linux
> pppd that I think is being affected, but it is the IP_masquerading 
> code (the NAT functionality) that is breaking, if anything, that leads
> to this fault.  I think that is the weak link here.
> 
> The reason is, that there are limits on, and the need to provide
> special mechanisms for some protocols and/or UDP's for example.  
> Plus, my IP_masq code is old, and needs to be updated.  Thats why
> I think its the weak link in this, and probably what is breaking.
> 
> In light of that, the question becomes what is it, if anything, that
> might be happening during the setup of the session being originated
> on NetBSD that is exposing the fault.  Dave may have id'd it!
> 
> Dave and I have been having a spirited discussion on the side on this,
> and I'm hoping it has led to us  finding something significant on it.
> I missed it the first time he said it....guess I was tired and more
> than just a little frustrated...but I'll be able to try it later and
> I'll be sure to let everyone know what the outcome is.
> 
> Thanks!
> Paul
>