RE: kernel or ppp problem?
Could you try these with the baud set to 17.2k or lower ?
Some UARTS have problems when going above that.
Whats the output of the serial ports in /proc/tty/drivers/serial ?
PS. Just up really early.
> -----Original Message-----
> From: Eugene Stemple [mailto:gene_s@hughes.net]
> Sent: 14 May 2007 18:38
> To: James Stevenson
> Cc: debian-user@lists.debian.org
> Subject: Re: kernel or ppp problem?
>
> 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...
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
Reply to: