From owner-freebsd-bugs  Sun Oct 15 01:24:31 1995
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id BAA13981
          for bugs-outgoing; Sun, 15 Oct 1995 01:24:31 -0700
Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA13968
          for <bugs@freebsd.org>; Sun, 15 Oct 1995 01:24:25 -0700
Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA18419; Sun, 15 Oct 1995 09:20:43 +0100
Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP
	id JAA06130; Sun, 15 Oct 1995 09:20:43 +0100
Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA17931; Sun, 15 Oct 1995 09:09:52 +0100
From: J Wunsch <j@uriah.heep.sax.de>
Message-Id: <199510150809.JAA17931@uriah.heep.sax.de>
Subject: Re: SLIP problem(s) in STABLE
To: bde@zeta.org.au (Bruce Evans)
Date: Sun, 15 Oct 1995 09:09:50 +0100 (MET)
Cc: bugs@freebsd.org, nnd@itfs.nsk.su
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
In-Reply-To: <199510142342.JAA29837@godzilla.zeta.org.au> from "Bruce Evans" at Oct 15, 95 09:42:25 am
X-Phone: +49-351-2012 669
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 3173      
Sender: owner-bugs@freebsd.org
Precedence: bulk

As Bruce Evans wrote:

> >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.

> 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.

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.)

> 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.

In my case: i don't do it this way.  I use the following script:

...
# redirect stdin first, so the tty remains open with the new tty settings
open(STDIN,  "<$dev");

$debug && print(LOG "sttying $dev for $speed\n");
system "stty", "-f", $dev, $speed, "crtscts";

# now that stty is done, we can redirect stdout, too
# (stty doesn't like redirected stdout)
open(STDOUT, ">$dev");

...
    $status = system("chat", "-v", "", "ATE1Q0M1", "OK", "$phone",
                     "gin:-\\r-gin:", "$sluser",
                     "ord:", "$slpass", "");
...

if($status) {
    kill 'TERM', $lockdpid;
    die "Chat failed\n";
}

# route(8) wants to have a _real_ uid of 0, grant this...
$< = $>;

...
system("slattach", "-h",
       "-c",
       "-e", "/etc/sliphome/goodbye $dev $lockdpid $defaultroute",
       "-s", "$speed",
       "-u", 
       "/etc/sliphome/conf $myname $remote $netmask $defaultroute",
       $dev);

sleep(1);                       # let things settle before we exit
exit(0);


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.


> 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
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

I once had a hard time (endlessly respawning mgetty) until i found
that "stty tty" would do the trick.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)