Re: kernel or ppp problem?

[Eugene Stemple <gene_s@hughes.net>]

James,

   The serial ports (both ends) are set at 38.4K.  As to PPP on
the two ends  -- lets call the systems "black" and "white" (for
lack of a better name)  --  the Black system has an mgetty
listening on the serial port (ttyS0) and brings up pppd when
valid LCP packets are seen;  the White system opens the link
via "pon" script.  The link open process goes normally, although
there _may_ be packet delays I can't see since neither the
ppp record option nor the tcpdump monitor can start until the
ppp link is "up."  There are no packet rcv errors or retransmissions
over extended sessions so I consider the serial path essentially
error free.  The packet dumps from tcpdump are error free whether
there were delays or not.

  I've looked through the pppd code (main.c) and the kernel ppp
support (ppp_generic.c and ppp_async.c) trying to find some place
where a timeout may be involved.  It is not obvious; but there are
lots of #include header files and system definitions and macro
definitions which might invoke a timeout.  I may seem overly
focused on "timeouts" but that is the only software mechanism I
can imagine whereby data exists in a receive buffer but is not
seen by the application until "something" happens 3.7 seconds
later to suddenly wake up the process and/or flush the buffer.
If there is ANY delay at all it is ALWAYS the same ~3.75 seconds.

  The ppp option (record <filename>) did not provide anything
better than the tcpdump packet capture; and the ppp option
(kdebug 7) gave no error complaints.

  In case you're wondering why I would "PPP-link" two linux
systems via null modem it is just a more convenient way to
test the problem first seen in a RF-modem link to a remote
linux user site.

   Thanks for your quick reply.  Were you up really late Sunday
night or up really early Monday morning?

  I'd be glad to run any kind of experiment you might think of
and log various diagnostic information.  In my problem posting
I aimed for a middle ground between too little data and lengthy
logs from tcpdumps from two machines but I have tcpdump files
available or I can save them in a well chosen test experiment.

   ...Gene...