*BSD News Article 18876


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!kralizec.zeta.org.au!not-for-mail
From: bde@kralizec.zeta.org.au (Bruce Evans)
Newsgroups: comp.os.386bsd.questions
Subject: Re: sio - problem with login hanging up
Date: 27 Jul 1993 08:02:44 +1000
Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis
Lines: 44
Message-ID: <231ka4INNrkf@kralizec.zeta.org.au>
References: <22mg9nINNlud@kralizec.zeta.org.au> <CAn28H.6AI@sugar.NeoSoft.COM> <22s698INNdf3@kralizec.zeta.org.au> <CAq3uA.9nx@sugar.NeoSoft.COM>
NNTP-Posting-Host: kralizec.zeta.org.au

In <CAq3uA.9nx@sugar.NeoSoft.COM> peter@NeoSoft.com (Peter da Silva) writes:

>In article <22s698INNdf3@kralizec.zeta.org.au> bde@kralizec.zeta.org.au (Bruce Evans) writes:
>> OK, you have convinced me.  By the way, the default settings for sio will
>> be the same as the initial settings now - `clocal -echo*' :-). ...

>One problem that's been pointed out to me, with this, is what to do about
>slattach. It depends on establishing a connection, closing the port without
>dropping it, and opening it again with slattach. ...

No problem, I think.  You have to avoid the last close on the port or the
connection will be dropped (unless clocal is used).  This may be done by
starting slattach from inside another program that has the port open.
slattach forks and holds the connection open in its child process, so
the other program can be exited.

>... How does that sort of
>thing interact with the BIDIR code anyway?

OK, I think, again provided there is always a dialout program holding the
connection open.

However, I prefer to do things like this:

	stty clocal -hupcl ...  (exit)
	connection_program ...  (exit)
	slattach ...

`clocal -hupcl' stops the modem from learning about the temporarily broken
connection.  This currently works very badly with BIDIR stuff.  If there
is a getty on the port, it wakes up when connection_program is exited
because carrier has been established.  One way to avoid these problems
without kludges is to hold the port open in another program.

>Also, I hate to bring up the multiple /dev entries again, but whether it's
>clocal or not should depend on whether you're using the BIDIR onr non-BIDIR
>port, right?

It's not that simple.  clocal is good for terminals and they are more
dialin than dialout.  clocal has mixed affects on dialout ports.  It is
ignored for opens (acts as if on) and I'm going to partlially ignore it
(act as if on) for carrier drops.
-- 
Bruce Evans  bde@kralizec.zeta.org.au