Date: Sun, 15 Oct 1995 20:27:27 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, j@uriah.heep.sax.de Cc: bugs@freebsd.org, nnd@itfs.nsk.su Subject: Re: SLIP problem(s) in STABLE Message-ID: <199510151027.UAA14679@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I'm suffering from the same. Lousy modem, lousy lines: the modem >drops carrier for less than a second sometimes, and then finds out >that the line went back, and rises DCD again. I can see it at the >front LEDs. Security issues aside, people with cheap modems won't >like us. :-( >Interestingly, iijppp doesn't seem to give up immediately with the >same modem and the same lines. (I have the option to use both >protocols.) I think iijppp sets CLOCAL and polls DCD every second or two. It could easily debounce DCD. slattach OTOH goes to a lot of trouble to get SIGHUPs and the driver doesn't debounce carrier (except as a side effect of not acting on carrier changes for a few usec, during which time the carrier may bounce without the intermediate states being noticed). SIGHUPs are only delivered if CLOCAL is clear and clearing CLOCAL gives POSIX modem disconnect semantics which are only appropriate for logins. iijppp's approach is probably best. slattach could continue after going to a lot of trouble to subvert the POSIX semantics but it isn't clear what the slip driver will do if it sees the carrier drop. >> slattach to close it. Terminal programs should be called from inside >> slattach, not the other way round. >In my case: i don't do it this way. I use the following script: >... >That is, the Perl script first opens the line, calls chat(1) to dial >the phone number, and finally transfers the line to slattach(8). >Since the script itself exits then, slattach is the only process >holding the line open. It should also work to return to a script like this to redial instead of using slattach's redial command. This is currently broken; slattach starts up again if the redial command is empty. >> TIOCSETD only requires an open line. It's unnecessary to reset the >> discipline because reopening resets it. >Are you absolutely sure? >Oct 9 03:01:25 uriah mgetty[3279]: tcsetattr failed: Inappropriate ioctl for device I think I was wrong. Nothing clears t_line for last closes or first opens. This is a bug. The standard l_open() routine (ttyopen()) must be called for first opens, if only to set the TS_ISOPEN flag. This error message is for something else, however. >Oct 9 03:01:25 uriah mgetty[3279]: tcgetattr failed: Inappropriate ioctl for device >Oct 9 03:01:25 uriah mgetty[3279]: tcsetattr failed: Inappropriate ioctl for device >Oct 9 03:01:29 uriah mgetty[3279]: do_chat: error in read(): Input/output error EIO might be called by the line not actually being closed, or (somewhat bogusly) by a timeout. Timeouts are likely if TS_ISOPEN doesn't get set and you use `comcontrol drainwait ...'. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510151027.UAA14679>