Bill, Colin & whoever was following this thread:

>>I hope it's not the LCP process (well, LCP state machine). My ppp link

Its not.  Fact is, its not coming from NetBSD either!  It IS coming
from a system on the net at work!  Interesting thing is, that system
is seeing something when I connect using NetBSD that is stimulating
it, but I haven't the foggiest idea what that could be.  The reason I
say that is, that it doesn't happen when connecting to the very same
service via PPP from any of several other machines/OS's, which includes
an NOS remote client which runs on Win95, or NT.  I also connect to 
this same service using Linux (various flavors...Slackware, Debian, 
RedHat), from Mac's running MacOS, and yes, even (in the past) FreeBSD.

And, all the traffic is coming from one of the NOS's servers on the
target network.  Now, this server is setup to permit connections via
tcp/ip, and it uses a mechanism based on UDP's.  However, most of the
packets seen are from that server and sent to the network's broadcast
address, and the great majority of them are not to the specific port
used for that NOS (out of 800 plus packets probably 90% of them fit
this category).

Now, without getting any more specific, I understand it would be tuff
to comment, but is it possible this server is seeing something from
NetBSD that is stimulating this behavior?  The scenario suggests that
is what is happening, but I'm at a loss here.....

With this particular NOS environment, a client does solicit responses
from a particular class of server (which this one fits) and it must
find one BEFORE a login attempt to that NOS environment can proceed.

What I'm thinking here is that the server THINKS it has seen that
request (that solicitation from the client IS a broadcast by the way
to which only servers that can support the client will respond, which
is why I think that may be what is causing this).  No, I don't actually
know exactly what that request looks like, but I'm gonna find out!  :)

>>doesn't have that problem. It could be a weird NetBSD-ISP interaction,
>

Yeah, thats what I'm seeing as a matter of fact Bill!  Good 
prognostication!  It sure fits the category 'weird' :)

>>though I bet it's more likely a configuration error somewhere. Though I
>>know not where.

I think this proves thats not it too...Well, maybe not...could be at 
that server, but it supports alot of folks using this access each day,
so the question becomes Why is it thinking that NetBSD may desire service
from IT?  It is bizarre...thats for sure.

At the very least, I know for sure that my first suspicion was clearly
wrong, and if you recall that was that NetBSD was somehow the source of
it all.  This proves its not that at all.  Which also jives with the fact
that I couldn't see anyting running on NetBSD that would be generating
it, 'cause it wasn't!

Oh, and guess what else?  This little session also proves that it is 
NOT my Linux NAT box that doesn't like the RFC1323 packet!  IT IS THE
device that supports the ppp ports at that end!  So, I was doubly wrong
on that one!  Ken strongly suggested it might be that server that does
support those ports, and that was correct!  Thats also why the Linux
box didn't show any error in the log files too, since the other end
terminated the link normally as far as Linux is concerned, apparently.

How do I know that?  Well, here I was dialed up directly this time from
ppp on the NetBSD system, and attempting the telnet thru all that flurry
of traffic just for the devil of it, and guess what......the link died!
The Linux NAT wasn't even in the picture this time!  So, I said, I'll be
darn'd (not exaclty what I said he says humbly....).  Then I says to 
myself, I've gotta do that again, just to be sure...so I did.  And, it
did!

Now I've gotta call that vendor and give'm the devil on that one!

Cool...
Paul