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:[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]