*BSD News Article 19147


Return to BSD News archive

Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Using the sio ports with a Modem
Message-ID: <1993Aug3.223714.18384@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University, Ogden, UT
References: <23ihduINNpre@kralizec.zeta.org.au> <1993Aug3.051002.2690@fcom.cc.utah.edu> <1993Aug3.092159.1696@cnplss5.cnps.philips.nl>
Date: Tue, 3 Aug 93 22:37:14 GMT
Lines: 121

In article <1993Aug3.092159.1696@cnplss5.cnps.philips.nl> rooij@bashful.isp.cft.philips.nl (Guido van Rooij) writes:
>terry@cs.weber.edu (A Wizard of Earth C) writes:
>>You lose modem control signals from the modem, notably carrier loss
>>notification, which is necessary to cause slattach to realize it has lost
>>the connection and it needs to be reestablished (or PPP, for that matter).
>
>Why? If clocal is clear, you'll get them anyway. You can also make
>the modem line the controlling tty.

If CLOCAL is not set, you can't get result codes from the modem without DCD
present in the current driver.  That's why his suggestions were workarounds.

>>Same problem as above, plus if CLOCAL is set always, a line drop (like a
>>power failure at your house but not where the computer is) will leave your
>>login session active for the next caller.  Also, without DCD drop reconized
>>(CLOCAL turns this off), the computer won't drop DTR to the modem, causing
>>it to reset as if powered off (if the modem is correctly configured).  The
>>result is that the first caller in sets the baud rate for all subsequent
>>callers until a callout (and DTR drop) or a modem reset.  Avatek modems,
>>Hayes modems, US Robotics modems, and others suffer from this problem.
>
>Therefore, you should not use the dialin port for dialout.

Certainly not with the current drivers (again, I never disputed this as a
workaround, only its desirability in a working driver).

>>Except CLOCAL should never be set on a dialin port (but you aren't exactly
>>saying it should be set anyway).
>
>Agreed, therefore -CLOCAL should be the default for dialin ports.

Or dialout if you expect your software to work correctly and recognize DCD
loss (ie: your Xmodem quits when the line is dropped and reconnects instead
of sending 10 packets without ACKs and timing out because it's too stupid
to see that carrier went away).  It's just that it won't work with the
current drivers as implemented.

>>>Too many places.  Given bidirectional ports, these programs can just open
>>>the dialout port, then set CLOCAL to whatever is appropriate.
>
>>*NEVER* set CLOCAL on a modem -- you lose carrier loss notification.  The
>>only place this is appropriate is for the "ct" command as part of a dialback
>>script for security or to save long distance charges.  CLOCAL must be set to
>>allow the dialout after the hangup without SIGHUP killing the process.
>
>But if you don't set clocal, how are you gonna talk to the modem? This
>requires additional hacks in the driver that are not very beautiful.

Exactly right -- but hacks which are in every version of UNIX serial drivers
since the idea of allowing dialout on dial-in lines came out.

>According to me, if a program wants the signal delivery it either sets
>clocal or makes the line its controlling tty. 

According to the programming manual, you *can't* set CLOCAL (literally
meaning "a local connection") and expect to receive signals from non-local
events (like DCD on-to-off transition).  CLOCAL by definition defeats the
modem control.  This is the difference between tty1A and tty1a on SCO
boxes -- tty1a has CLOCAL set by default and tty1A doesn't.

Unsetting CLOCAL generally has the result of the appearance of a soft DCD
loss, since you can't query the current DCD level with CLOCAL set and
without polling the port (there is an ioctl() to read, but none to wait
for a state change).

>I think there are 2 views here, I also talked a lot about exactly
>this with Bruce and Andrew Chernov. I dont think there is a standard
>here: on Suns, you get the SIGHUP by default, but according to Andrew,
>on some other systems you don't, thus allowing multiple dialouts
>in one session without having to deal with SIGHUP. I am not aware
>of any standard in this area. Does anyone know about one?

When I rewrote the Sun and SVR3/SVR4 serial code for TERM (a commercial comm
product), I handled connection loss *and* supported simultaneous sessions on
telnet, rlogin, pty, and serial transports.  This was device consumer code,
but the principle is the same; there exists a finite state automaton on both
sides of the kernel interface, and both sides can determine the current state
of the code on the other side of the wall from their own state.

You *want* to deal with SIGHUP to ensure timely response to things like a
SL/IP or PPP connection going down.

Barring other authoritative examples of BSD behaviour, I believe we should
take the SunOS and Ultrix behaviours as our model.

Agreed that some serial drivers don't support the idea of signal delivery
to their first open and have to be set up as the controlling tty.  These
serial drivers are broken, since signals are to go to the controlling process,
and process group need not be predicated on tty (such systems invariably
have problems with programs using pty's, such as "screen").  A good example
was available at one time as an interim implementation on Sony NeWS
workstations (which also claim BSD heritige).

Again, calling unit devices simply avoid incoming device locking which would
otherwise have to take place in user space code, ala the SCO uugetty.  They
server no other purpose, nor should they.

If you want to extend the functions provided in the serial driver on the
basis of bipartite drivers, a much better mechanism to implement is transparent
printing.  Let me warn you right off the bat the the Computone model is not
sufficient to this task, since it does not guarantee atomicity of escape
sequences to the device.  A "transparent print" device requires that the
print device not become active in such a way as to interrupt a user escape
sequence of the normal tty device.  This means you will have to maintain an
emulation automaton in the driver that represents accurately the current
state of the connected device, and only unblock printer I/O when the automaton
is at the base (zero) state.  But please don't try to extend the calling
unit paradigm to anything beyond its intended use in avoiding device locking
by using the kernel operations for atomicity.

Remember also that at some time in the future, this will all have to fall
under the "normal behaviour" of an "ldterm" style module in a stackable I/O
system, whether it's a Streams implementation, an X-Kernel implementation,
or Bill's promised Currents implementation.


					Terry Lambert
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.