Re: Dialup networking/ppp

[Lars Hecking <lhecking%nmrc.ie@localhost>]

> The symptoms might point to broken serial handshaking. This can be any one of:
> 
> - broken serial cable at your end
> - modem not notified of hardware handshaking at your end
> - pppd not notified of hardware handshaking at your end ("crtscts" option)
> 
> - broken serial cable at provider
> - modem not notified of hardware handshaking at provider
> - pppd not notified of hardware handshaking at provider ("crtscts" option)
 
 I would tend to exclude hw problems of that type. The trouble started only
 when I upgarded to 060.

> Nowadays, with less hobbyist dialup servers, the 2nd three seem less likely, 
> especially as commercially-used hardware does operate on E1 and up digital
> lines, doing ADC/DAC, modem function, "serial" handshaking, and PPP 
> all-in-one.

 Right. The dialin server at the other end identifies itself as Cisco 2511.
 Nothing I would call "hobbyist" :-)

> This said: you should verify, using a serial line analyzer (err, one of those
> 7red+7green boxen you plug into the Amiga serial port then plugging the modem
> cable into the other end) that the handshaking does work _right at the

 Not a snowball's chance in hell that I could get hold of such a device :-/

> Amiga_. Then you should do the same _right at the modem_, however here you
> can look at the modem LEDs in most cases.
> 
> In both cases, when you do a bulk FTP upload, CTS should go 
> off sometimes, and _at the same times_ TxD should be quiet; similarly,
> if you do an FTP download, RTS shoudl go off sometimes, and RxD should
> be quiet at the same time.
 
 I'm too lazy to look up what CTS and RTS mean, but in case of downloads,
 the RD (read data) LED is on almost constant, and SD (send data) blinks
 at 2 or 3 Hz. Yes, it looks like RD goes off when SD comes on.
 Now, if I start some cpu consuming process (e.g. kernel compile) during
 download, both LEDs go off and stay off mostly until that process is
 finished.

> If this does not happen exactly as described above, please report what
> _exactly_ happens! also, your full pppd configuration (excluding passwords
> of course) and /etc/ttys and kernel startup messages (/var/run/dmesg.boot)
> will be needed, and your full kernel configuration file.
> 
> Sorry if this is more explicit than you need, but I wanted to write the text
> once and make a "pppd performance troubleshooting guide" out of it without
> rewriting.

 Your explicit response is appreciated and most welcome!