Date: Sun, 15 Oct 1995 09:42:25 +1000 From: Bruce Evans <bde@zeta.org.au> To: bugs@freebsd.org, nnd@itfs.nsk.su Subject: Re: SLIP problem(s) in STABLE Message-ID: <199510142342.JAA29837@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> It was already discovered that SLIP have some problems
>in -current. I found some (same ?) problems in -stable.
>1) After succesfully establishing a SLIP connection by
>'slattach' on a line with modem and loosing/reestablishing carrier
>I can't use that 'slX' interface due to permanent
>'No route to host' messages.
> Reading the sources of /sys/net/if_sl.c and /sys/kern/tty.c
>shows that this message must results from:
>/* /sys/net/if_sl.c - lines from 446 */
> if ((sc->sc_ttyp->t_state & TS_CONNECTED) == 0) {
> m_freem(m);
> return (EHOSTUNREACH);
> }
Urk. The !TS_CONNECTED state is now sticky, as is required by POSIX and
for security (*). Once carrier drops, further carrier rises are ignored
until after the line is completely (+) closed and then reopened.
(*) the sticky state and security can be defeated using CLOCAL unless
CLOCAL is locked off.
(+) including the virtual open for controlling terminals.
This wasn't supposed to affect slattach. slattach is supposed to receive
a SIGHUP. After receiving a SIGHUP, it completely closes the line and
then reopen it. Completely closing the line is quite complicated because
of the requirement to get rid of the old controlling terminal. slattach
attempts to do this by forking and exiting from the parent. This was
necessary in 1.1.5. 2.0 allows getting changing the controlling terminal
by just switching to a new one. I'm not sure if slattach tries this, or
what happens for "switching" to the same controlling terminal.
> As a temporary "solution" ;-( of this problem I make the
>next change to /usr/src/sbin/slattach:
>--- slattach.c.STABLE Sat Oct 14 22:16:12 1995
>+++ slattach.c Sat Oct 14 22:55:55 1995
>@@ -419,6 +419,18 @@
> }
> syslog(LOG_NOTICE, "Carrier now present on %s (sl%d)",
> dev, unit);
>+ /* This HACK clears TS_ZOMBIE flag and set */
>+ /* TS_CONNECTED, which otherwise remains unset. */
>+ tty.c_cflag |= CLOCAL;
>+ if (tcsetattr(fd, TCSANOW, &tty) < 0) {
>+ syslog(LOG_ERR, "tcsetattr(TCSAFLUSH): %m");
>+ exit_handler(1);
>+ }
>+ tty.c_cflag &= ~CLOCAL;
>+ if (tcsetattr(fd, TCSANOW, &tty) < 0) {
>+ syslog(LOG_ERR, "tcsetattr(TCSAFLUSH): %m");
>+ exit_handler(1);
>+ }
> }
> }
> setup_line(0);
Something like this was suggested before slattach did the fork to get rid
of the controlling terminal, and the CLOCAL kludge was put in 1.1.5+
David's patch suite to make it work.
But why doesn't forking and exiting work? Perhaps you started slattach
from inside a terminal program and didn't exit from the terminal program.
The terminal program then holds the line open so there is no way for
slattach to close it. Terminal programs should be called from inside
slattach, not the other way round.
>2) There are some "strangenesses(?)" in slattach behaviour
> - 'slX' interface marked as 'UP' even before carrier is
> established on a line;
I suppose slopen() could be cleverer about carrier.
> - is it really necessary to 'fork' (in 'acquire_line()') every time
> to run 'redial_cmd' (if there is any) ?
See above.
> - it seens to me than "resetting to tty discipline" in this
> 'acquire_line' can't be done when redialing because there is
> no carrier and switching to CLOCAL is done after that ?
TIOCSETD only requires an open line. It's unnecessary to reset the
discipline because reopening resets it. This code is probably
leftover from simpler times before forking and and closing everything
was necessary. Perhaps slattach should rely on the (unportable!)
2.0 semantics of TIOCSCTTY or the (unportable!) 1.1.5++ semantics
of toggling CLOCAL and not do the fork/close.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510142342.JAA29837>