duncan@comp.vuw.ac.nz (Duncan McEwan) (08/31/88)
Some months ago, I posted a description of a problem that we were having with
dialup UUCP connections between our Pyramid and various other machines
(including another Pyramid, an ICL Clan, and a VAX 750 running Ultrix). I
received a few suggestions, but unfortunately nothing that solved the problem.
After investigating the problem intermittently since then, I think I can
explain what was happening. My apologies for the length of this article, but I
decided to post it because a) it may help others who encounter similar
problems, and b) there are still some unanswered questions that somebody on the
net might be able to help with.
My original article was only posted to comp.sys.pyramid, but since the problems
turned out to be modem related, I am crossposting this to comp.dcom.modems.
For the benefit of readers of comp.dcom.modems who didn't see my original
posting (and for readers of comp.sys.pyramid who have forgotten it), the
following is a brief description of the problem.
Many calls (both incoming and outgoing) between our pyramid and one of our
neighbours would start up fine, get through the login and selection of the 'g'
protocol OK, then sometime later fail, always apparently in the same way. Our
uucico would write the message "Alarm while reading SYN - RXMIT" repeatedly at
approximately 10 second intervals until either it, or the remote uucico gave up
and hung up the phone.
The modem on our side was a Quattro SB2422. This is a "hayes compatible"
V22bis 2400 bps modem, made (I think) by a UK company called "Dowty
Electronics". I don't know if it is sold in the U.S. The remote site's had
various modems including Quattro's, MultiTech 224e's and SendData Quad's. The
above symptoms would occur intermittently (though on occasions on up to 50% of
the calls) between any of the above modems and our Quattro.
It turned out that there were 3 problems, each causing calls to fail
at different stages. The failure could occur
1) during the initialisation of the 'g' protocol (during the INITA/B/C
exchange)
2) immediately after the 'g' initialisation, during the negotiation of the
first file transfer or line turnaround.
3) at some random point during the transfer of a data file from our pyramid
to the remote system.
The third case was slightly different, in that although the RXMIT error's
were repeated a number of times the uucico's sometimes managed to recover
and continue transfering data. It was also the easiest to solve because we
could easily see what was happening on a line monitor between our pyramid and
the Quattro, so I will describe what was causing it first.
We use our Quattro for both incoming and outgoing calls (using a version of the
"acucntrl" program). Because of the way the Quattro only autobauds on "at"
commands, we have found it easiest to have it permanently set up to talk to the
pyramid at 2400bps ("constant speed interface" turned on).
I knew that with the constant speed interface enabled the modem might have to
use flow control on the pyramid<->modem line if it connected to a modem running
at less than 2400bps. I also knew that when uucico was running xon/xoff was
disabled, and since none of our terminals had rts/cts flow control enabled, any
flow control it tried to use would be ineffective. But I also thought this
wouldn't matter because the 'g' protocol would provide sufficient flow control.
But from what we saw on the line monitor that appeared not to be the case. The
result was many incomplete packets being received by the remote host which it
did not ack, and hence lots of RXMIT messages. If the same packet had to be
retransmitted too many times our uucico would give up. The solution was to
tell the modem to use rts/cts and to enable rts/cts on the tty line connected
to the modem.
The second problem only occurred when a call was between a Quattro and a
MultiTech 224e modem. From tests I have run, it appears that when a sequence
of approximately 20 null's is sent from the DTE connected to the Quattro to the
one connected to the MultiTech one or two often (but not always) get dropped.
A line monitor shows them on the serial line going into the Quattro but not on
the line out from the MultiTech!
Not surprisingly this behaviour upsets UUCP! Immediately after initialisation
of the 'g' protocol, the transmit buffer is null filled. If the first message
after 'g' initialisation from the uucico on the Quattro side is a short one,
some of the null's in the 64 byte packet that is sent get lost. So the remote
uucico does not see a valid packet. One reason the first message from the
Quattro to the MultiTech may be short is if uucico on the Quattro side made the
call, but has no work for the remote. In this case it sends a 64 byte message
containing an "H" followed by 63 nulls.
I have used two different Quattro's (one on our machine and one on a
neighbours) and two different MultiTech's (again one on our machine and one on
a (different) neighbour) and observed the same behaviour in each case. It does
not happen between two MultiTech's, or two Quattro.
Until we figure out which modem is at fault and try to get it fixed we just
have to avoid the Quattro/MultiTech combination. Has anyone ever experienced a
problem like this? Can anyone offer advice on how to track down which modem is
to blame?
The last problem that we solved was made more difficult because the symptoms
seemed exactly like the second problem. But they couldn't be caused by null
bytes being dropped because they occurred during the INITA/B/C sequence at the
start of the 'g' protocol. Those messages are short (8 or so bytes each) and
do not contain sequences of nulls.
What we actually saw on our line monitor was an INITA message from the remote
uucico to ours, and an INITA from ours to theirs. This was followed
immediately an INITB from the remote, but nothing from us. After a short time
we sent another INITA, which they responded to with another INITB. This was
repeated several times until one of the uucico's gave up and hung up the line.
The INITA messages from both ends looked identical, which led us to believe the
problem was with our pyramid (either its uucico, or less likely, faulty
hardware). It wasn't until we looked at the parity bit that we saw the real
problem was that our Quattro modem was converting the INITA message from the
remote site to even parity. So the packet our uucico was seeing was invalid.
We were still puzzled by the fact that the modem did not behave like this every
time. It turns out that the Quattro determines both the terminal baud rate
*and parity* from any "at" command. When in data mode it converts all data
from a remote modem to the parity determined this way.
Fortunately there is a workaround. If the "at" command is sent with space
parity the Quattro allows all 8 bits through untouched. Pyramid's uucico sends
all it's "at" commands with space parity, so every time we made an outgoing
UUCP call the modem would be set into a state that would allow the 'g' protocol
to work correctly. "Tip" on the other hand uses even parity by default, so
whenever we used it, the modem would be put into a state where it clobbered the
8th bit. We have now changed /etc/remote so all the entries specify space
parity, but I don't know what we will do if we encounter a host that requires
some other parity.
The (old) Quattro manual I have does not document this "feature", but I have
spoken to one of the distributors engineers who says his manual does. As a
small consolation for all the time I spent trying to track the problem down, he
is sending me a copy of the updated manual! But he also claims the Quattro is
behaving perfectly reasonably. Is he right? How many other modems behave like
this?
Duncanjbm@uncle.UUCP (John B. Milton) (09/01/88)
In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: ... >We use our Quattro for both incoming and outgoing calls (using a version of the >"acucntrl" program). Because of the way the Quattro only autobauds on "at" >commands, we have found it easiest to have it permanently set up to talk to the >pyramid at 2400bps ("constant speed interface" turned on). What is the "acucntrl" program, and where did you get it? John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/03/88)
>>We use our Quattro for both incoming and outgoing calls (using a version of >>the "acucntrl" program). >What is the "acucntrl" program, and where did you get it? acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when it wants to make an outgoing call, to scribble on the tty data structures in the kernel and keep init(8) from waking up. In other words, it provides dialin and dialout on the same line. Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de- pendent (what do you expect for a program that opens and writes on /dev/kmem?) and needs a fair amount of hacking to make it work on a Pyramid. Several brave souls have done this, including Romain Kang @ pyrnj and (apparently) someone in New Zealand. Of course, 4.3BSD Tahoe has a port to the CCI Power 6/32. Someday (*SIGH*) someone here will implement the Sun/Mt. Xinu fix that allows real modem devices and provides portable goof-proof in/out calling. I've been wanting to do that for some time. Unfortunately it is the kind of thing that makes smaller existing customers happy, but isn't real meaningful to the large customers who are buying machines tomorrow. So it has taken a back seat to other development. :-( If, say, Southwest Bell (Hi Bruce!) were to threaten to dump all their machines in the Mississippi if they didn't have dialin/dialout capability, then it would get done tomorrow afternoon. :-) <csg>
brian@ncrcan.UUCP (09/03/88)
In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: > [stuff deleted] >The (old) Quattro manual I have does not document this "feature" [modem >changing parity of the received data] , but I have >spoken to one of the distributors engineers who says his manual does. As a >small consolation for all the time I spent trying to track the problem down, he >is sending me a copy of the updated manual! But he also claims the Quattro is >behaving perfectly reasonably. Is he right? How many other modems behave like >this? No! He is not right. No sane modem should mess with the data stream. It's purpose is to get the data across a communications channel *unchanged*. If I am on side A and send data at even parity I expect it to be received at the other side also with even parity, not at the last parity that was used when sending to the (broken) modem. This is no feature, it is a bug! No other modems I know of due this. There may be some that allow this to be configured (someone may want it), but it should not be forced upon you because some designer thought that that's the way it should be done. Brian. -- +-------------------+--------------------------------------------------------+ | Brian Onn | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+--------------------------------------------------------+
dave@onfcanim.UUCP (Dave Martindale) (09/04/88)
In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: >We were still puzzled by the fact that the modem did not behave like this every >time. It turns out that the Quattro determines both the terminal baud rate >*and parity* from any "at" command. When in data mode it converts all data >from a remote modem to the parity determined this way. > >The (old) Quattro manual I have does not document this "feature", but I have >spoken to one of the distributors engineers who says his manual does. >But he also claims the Quattro is behaving perfectly reasonably. >Is he right? How many other modems behave like this? I believe that a modem's job is to get bits from one place to another, without changing them. I have never used any modem where it was even possible to ask it to do parity-bit stripping in data mode. Any modem that decides to throw away some data bits by default is, in my opinion, a piece of junk. Without some sort of explicit instructions to ignore the 8th bit, the modem *must* assume that all bits are data. Parity stripping in command mode may be quite reasonable, but not in data mode. Dave Martindale
evan@telly.UUCP (Evan Leibovitch) (09/04/88)
In article <37899@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > >What is the "acucntrl" program, and where did you get it? > > acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when > it wants to make an outgoing call, to scribble on the tty data structures in > the kernel and keep init(8) from waking up. In other words, it provides dialin > and dialout on the same line. > > Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de- > pendent (what do you expect for a program that opens and writes on /dev/kmem?) > and needs a fair amount of hacking to make it work on a Pyramid. There is also a System V acucntrl which does the same thing, but not as gracefully (?) as direct kernel diddling. The program, with setuid root, checks to see if the port is in use from a process besides getty (also looks for uucp LCK.* files). If free, the program edits /etc/inittab to change the entry from 'respawn' to 'off', and then kills the getty. A different invokation undoes this - changes inittab back to respawn, and calls telinit. This worked steadily for me on a Convergent Megaframe, though I'm not using it now. -- Evan Leibovitch, SA of System Telly, located in beautiful Brampton, Ontario evan@telly.UUCP / {uunet!attcan,utzoo}!telly!evan The advantage of the incomprehensible is that it never loses its freshness.
duncan@comp.vuw.ac.nz (Duncan McEwan) (09/05/88)
In <37899@pyramid.pyramid.com> csg@pyramid.com (Carl S. Gutekunst) writes: >acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when >it wants to make an outgoing call, to scribble on the tty data structures in An earlier version of OSx (3.?) supported uucico automatically invoking acucntrl to do it's stuff if the keyword "inout" appeared in L-devices. That capability seems to have disappeared from OSx 4.?, so I have to invoke uucico from a script with a call to acucntrl immediately before it. This is a right pain, since it complicates the way I have to do polling. Why was it taken out? >Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de- >pendent (what do you expect for a program that opens and writes on /dev/kmem?) >and needs a fair amount of hacking to make it work on a Pyramid. Several brave >souls have done this, including Romain Kang @ pyrnj In fact, I think it is rather easier to make it work on a Pyramid than on a VAX running 4.3. The version I run, which came indirectly from Romain, but which I modified slightly (can't remember why now -- its been a while) has all the /dev/kmem stuff ripped out and replaced by an ioctl to the itp driver to set hardwired carrier on. I don't think the result behaves exactly like the 4.3bsd version, in that after enabling software carrier any transition of the hardware carrier will not be noticed. Apart from that it seems to work reasonably well most of the time. Occasionally if fails mysteriously - the acucntrl seems to succeed (ie it doesn't write a diagnosic indicating the ioctl failed) but the following invokation of uucico gets a "TIMEOUT ON DEVICE OPEN" error. Not having access to the source to the itp driver, I don't know if there any circumstances in which the ioctl returns with a good status but didn't, or perhaps hasn't yet enabled the software carrier. Since it works most of the time, I have never gotten around to investigating the problem. >Someday (*SIGH*) someone here will implement the Sun/Mt. Xinu fix that allows >real modem devices and provides portable goof-proof in/out calling. That would indeed be a nice addition. >If, say, Southwest Bell (Hi Bruce!) were to threaten to dump all their >machines in the Mississippi if they didn't have dialin/dialout capability, >then it would get done tomorrow afternoon. :-) C'mon Bruce -- how about it, huh? What's a few wet Pyramid's between fellow users :-) Duncan
jbm@uncle.UUCP (John B. Milton) (09/06/88)
In article <324@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: >In article <37899@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >> >What is the "acucntrl" program, and where did you get it? >> >> acucntrl is a little hack that comes with 4.3BSD. It is invoked by uucico when ... > >There is also a System V acucntrl which does the same thing, but not as >gracefully (?) as direct kernel diddling. ... Fine, where can I GET this program? John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2
boxdiger@impch.UUCP (Patrick Guelat) (09/06/88)
In article <324@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: % In article <37899@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: % > % > Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX de- % > pendent (what do you expect for a program that opens and writes on /dev/kmem?) % There is also a System V acucntrl which does the same thing, but not as % gracefully (?) as direct kernel diddling. % % The program, with setuid root, checks to see if the port is in use from % a process besides getty (also looks for uucp LCK.* files). If free, the % program edits /etc/inittab to change the entry from 'respawn' to 'off', % and then kills the getty. % % A different invokation undoes this - changes inittab back to respawn, and % calls telinit. % Another solution has been done by SCO in their XENIX. There is a program called 'ungetty'. It looks up in /etc/utmp if there is a user on the line, if there isn't it sends a SIGUSR1-signal to the getty process. Getty will change the utmpentry to 'DIALOUT' and then sleep until it receives a SIGUSR2 from ungetty. (when the DIALOUT job has been done..). It will then die, init will remove the 'DIALOUT' entry and fork a new getty for this port. ( No flames about SCO-init.....) Patrick
cdold@starfish.Convergent.COM (Clarence Dold) (09/07/88)
From article <324@telly.UUCP>, by evan@telly.UUCP (Evan Leibovitch): > There is also a System V acucntrl which does the same thing, but not as > gracefully (?) as direct kernel diddling. > > This worked steadily for me on a Convergent Megaframe, though I'm not > using it now. The uucp package on Convergent SysV (CTIX 5.x) includes a 'uugetty', that I didn't think was Convergent exclusive. It does everything that acucntrl appears to do, for cu and uucico. C-Kermit doesn't agree with it, though. It works rather simply, by looking for lock files, the contents of which are the owning process id. If that process id is not active, the lock is removed. ct, cu, uucico, and uugetty all are suid uucp, and cooperate in this scheme. -- Clarence A Dold - cdold@starfish.Convergent.COM (408) 435-5274 ...pyramid!ctnews!mitisft!professo!dold P.O.Box 6685, San Jose, CA 95150-6685
pst@comdesign.CDI.COM (Paul Traina) (09/07/88)
From article <692@starfish.Convergent.COM>, by cdold@starfish.Convergent.COM (Clarence Dold): | The uucp package on Convergent SysV (CTIX 5.x) includes a 'uugetty', that I | didn't think was Convergent exclusive. It does everything that acucntrl | appears to do, for cu and uucico. C-Kermit doesn't agree with it, though. | It works rather simply, by looking for lock files, the contents of which | are the owning process id. If that process id is not active, the lock is | removed. ct, cu, uucico, and uugetty all are suid uucp, and cooperate in | this scheme. I just upgraded one of our SsyV systems to Honey-DANBER uucp, and it turns out all you need to do to make C-Kermit work properly with uugetty/uucico/etc. is to recompile ckutio.c with -DATT3BX. This makes locks go in /usr/spool/locks and inserts the pid of the kermit process into the lock file. This switch should be renamed to something like -DHDBUUCP or somesuch. Happy Hacking, the PST -- Paul Traina To believe that what is true for {uunet|pyramid}!comdesign!pst you in your private heart is true pst@condor.cdi.com for all men, that is genius.
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (09/08/88)
My new Prime EXL316 also came with a uugetty that is supposed to handle this correctly. The technique appears to be a combination of lock files, and serial drivers that have two entry points to each device (as apparently exists in Sun systems: ie. normally, you can't write to a serial device that doesn't assert DCD. By adding 128 to the minor number of the device, you can mknod a new special file that ignores Carrier. Since uugetty doesn't attempt to login until it sees chars, uucico can grab the other device and lock uugetty out. I'm not clear on this for one reason: The EXL doesn't support pin 8 in their rs232 connection, and their official cable ties pin 8 to pin 6. I think this is why I haven't gotten it to work properly with my TB modem yet. Anybody else out there have a Prime unix box that they've gotten bi-directional modem lines to work on? Thanks in advance --Dan Daniel A. Graifer Franklin Capital Investments uunet!fciva!dag 7900 Westpark Drive, Suite A130 (703)821-3244 McLean, VA 22102 -- Daniel A. Graifer Franklin Capital Investments uunet!fciva!dag 7900 Westpark Drive, Suite A130 (703)821-3244 McLean, VA 22102
cdold@starfish.Convergent.COM (Clarence Dold) (09/09/88)
From article <520@comdesign.CDI.COM>, by pst@comdesign.CDI.COM (Paul Traina): > From article <692@starfish.Convergent.COM>, by cdold@starfish.Convergent.COM (Clarence Dold): > | The uucp package on Convergent SysV (CTIX 5.x) includes a 'uugetty', that I > | appears to do, for cu and uucico. C-Kermit doesn't agree with it, though. > I just upgraded one of our SsyV systems to Honey-DANBER uucp, and it turns > out all you need to do to make C-Kermit work properly with uugetty/uucico/etc. > is to recompile ckutio.c with -DATT3BX. This makes locks go in /usr/spool/locks The problem I had with this scheme if I recall correctly, is that kermit had to be suid uucp, in order to kill uugetty, a step in the outbound dialing. If this was true, a shell spawned from kermit carried the effective id of uucp, endangering some security. A shell spawned from cu gives the original uid, rather than uucp. I thought I could hack the code, but gave up. C-Kermit, 4E(070) 29 Jan 88, AT&T System III/System V I never even looked at -DATT3BX. I read from your message that this should be a separate compile, outside of defining ATT3BX to the full Makefile. I'll try that, but I wanted to post back to the net first, to avoid someone inadvertently leaving a hole in security. -- Clarence A Dold - cdold@starfish.Convergent.COM (408) 435-5274 ...pyramid!ctnews!mitisft!professo!dold P.O.Box 6685, San Jose, CA 95150-6685
jbm@uncle.UUCP (John B. Milton) (09/13/88)
In article <421@fciva.FRANKLIN.COM> dag@fciva.UUCP (Daniel A. Graifer) writes: ... >yet. Anybody else out there have a Prime unix box that they've gotten >bi-directional modem lines to work on? ... I modified a program that was posted to the net a while back "modem-ctl". I am using this program on a UNIXpc connected to a TB. I did not know about the +128 tty device until after I finished. All the line access is done by opening the line with O_NDELAY, doing an ioctl() with CLOCAL turned on, then a fcntl() to turn off O_NDELAY so things work right again. Neat trick. This program is run by init. It talks to the modem to set it up to answer a call, right now using HAYES commands. It spends most of it's time hanging in a read waiting for "RING". After each character it reads, it does an access() to check for the lock file. If it sees a lock file, it immediately exits. There are a few side effects to this. As long as this program has the line open, any other program can come along and open the line, a uucico for example. When the program exits, init repawns it, and it comes back and finds a lock file. This time it just waits for the lock file to go away, opens the line, talk to the modem and waits. If it gets the RING, it sends ATA to answer the phone, waits a while for CONNECT xxx, then the fun part. Based on the xxx, it fork() & exec()s an: /etc/getty -h xxx /dev/ttyzzz The /etc/gettydefs needs to adjusted a little. As you Bezerkers can tell this was written for SYSV. What I have seen of BSD termio(7) would make this easier. A while ago I promissed to post this unix-pc.sources, but what I think I want to do now is a beta test. All volunteers e-mail me. Describe your hardware (# of ttys,etc.) Phone lines (direct, PBX, Datakit, etc.) Modems (HAYES, TB, etc.) OS (SYSV, XENIX, BSD) Typical users (kind, load) Current setup (weirdness you use for two-way lines) How much time you have to goof around with it Whether or not you have a diff that can produce -c (context) diffs A good e-mail address I will try to select a good test cross section (or all of you if I only get a few :). I have a few things to clean up, so I should be ready by the time I get replies. If anyone out there has experience with modem-ctl, even if you're not interested in participating, please drop me a line. BTW the name of the program will (so far) be prtty (pre tty) I was going to call it pretty, but there is already a program in the archives by that name. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu home: (614) 294-4823, work: (614) 459-7641; CP/M to MP/M, MS-DOS to OS/2
jgp@moscom.UUCP (Jim Prescott) (09/14/88)
In article <310@impch.UUCP> boxdiger@impch.UUCP (Patrick Guelat) writes: >In article <324@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: >% In article <37899@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >%> Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX... >% There is also a System V acucntrl which does the same thing, but not as >% .... >% program edits /etc/inittab to change the entry from 'respawn' to 'off', >% and then kills the getty. >Another solution has been done by SCO in their XENIX. >There is a program called 'ungetty'. It looks up in /etc/utmp if there >is a user on the line, if there isn't it sends a SIGUSR1-signal to getty There sure are a lot of complex solutions that perform the same function as the so called Sun hacks which work as follows: - a modem gets 2 names, /dev/ttyd0 (for getty) and /dev/cua0 (for dialout with uucp, kermit, tip or whatever). - an open on ttyd0 blocks until DCD gets raised. getty spends most of it's life waiting for someone to call in and raise DCD so it can complete the open. - an open on cua0 succeeds without DCD - the kernel ensures that only 1 of ttyd0 and cua0 can be open at the same time. If someone is logged in then an open of cua0 fails. If cua0 gets opened by someone then getty won't see DCD until cua0 gets closed. This isolates all the changes in the tty driver. No changes to any programs are required and it works with both modems and direct connections. The only disadvantage that I've heard about it is that since it can be done in user mode it shouldn't be in the kernel. Since it came with our 9/84 release of HCR V7 for a pdp-11 I don't think that it can add all that much code. Anybody know why everyone hasn't picked up on this? I know that some of the PC Unix systems use it. -- Jim Prescott moscom!jgp@cs.rochester.edu {rutgers,ames,harvard}!rochester!moscom!jgp
chris@mimsy.UUCP (Chris Torek) (09/15/88)
In article <1260@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes: >There sure are a lot of complex solutions that perform the same function >as ... [having two device in the kernel and doing the duplexing there] >This isolates all the changes in the tty driver. No changes to any programs >are required and it works with both modems and direct connections. The only >disadvantage that I've heard about it is that since it can be done in user >mode it shouldn't be in the kernel. Since it came with our 9/84 release >of HCR V7 for a pdp-11 I don't think that it can add all that much code. > >Anybody know why everyone hasn't picked up on this? People claim that it is `inelegant' to put this in the kernel. `Why,' they cry, `should we do it here when we can do it in user mode?' To which I answer: `Indeed, perhaps you are right. Let us also remove the file system code from the kernel, for that, too, can be done in user mode. Build a ``file system library''; user programs can open the disk drives directly. Just think of the flexibility!' Indeed, the very reason that the file system is in the kernel is the same reason that tty multiplexing should be (and, in other cases, already is) also in the kernel. (One can argue that services such as these should be moved back out into separate processes, a la Mach; nonetheless, the multiplexing should be centrally sited.) Perhaps I shall have another go at convincing Mike Karels in November. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dave@onfcanim.UUCP (Dave Martindale) (09/16/88)
In article <13564@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >People claim that it is `inelegant' to put this in the kernel. `Why,' >they cry, `should we do it here when we can do it in user mode?' It's worth noting that the Berkely "acucntrl" runs in user mode in name only - it goes poking around in /dev/kmem to do its work. >Indeed, the very reason that the file system is in the kernel is the >same reason that tty multiplexing should be (and, in other cases, >already is) also in the kernel. (One can argue that services such as >these should be moved back out into separate processes, a la Mach; >nonetheless, the multiplexing should be centrally sited.) Also, if it really was centrally sited, it would work properly for all devices all the time. Acucntrl certainly doesn't work properly all the time. I've lost count of how often I've dialed up a modem on onfcanim, got carrier, and then got hung up on because uucico also wanted to use the line and I wasn't logged in yet. A kernel-based interlock would just look at the carrier detect bit - if it was up, uucico's open would fail. This still leaves a window of a second or two where I can call into a modem which uucico has already allocated for dailout, but it's much smaller. And even that could be narrowed by kernel fixes - by not raising DTR to an answer modem until the kernel sees RING asserted. Dave Martindale
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (09/16/88)
In article <1260@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes: >In article <310@impch.UUCP> boxdiger@impch.UUCP (Patrick Guelat) writes: >>In article <324@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: >>% In article <37899@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >>%> Standard OSx does not provide acucntrl. The 4.3BSD version is highly VAX... >>% There is also a System V acucntrl which does the same thing, but not as >>% .... >There sure are a lot of complex solutions that perform the same function >as the so called Sun hacks which work as follows: > - a modem gets 2 names, /dev/ttyd0 (for getty) and /dev/cua0 (for > dialout with uucp, kermit, tip or whatever). > - an open on ttyd0 blocks until DCD gets raised. getty spends > most of it's life waiting for someone to call in and raise > DCD so it can complete the open. > - an open on cua0 succeeds without DCD > - the kernel ensures that only 1 of ttyd0 and cua0 can be open at > the same time. If someone is logged in then an open of cua0 > fails. If cua0 gets opened by someone then getty won't see > DCD until cua0 gets closed. > >This isolates all the changes in the tty driver. No changes to any programs >are required and it works with both modems and direct connections. The only >disadvantage that I've heard about it is that since it can be done in user >mode it shouldn't be in the kernel. Since it came with our 9/84 release >of HCR V7 for a pdp-11 I don't think that it can add all that much code. > What I do is define *three* virtual devices for each serial port, for local, modem and getty use. Each has their own name and minor device for example: mknod tty0al c 0 0 mknod tty0am c 0 128 mknod tty0ag c 0 192 You simply treat each of these as a separate physical device when doing your configuration. I.e. you make entries in inittab for tty0ag if you have an incoming modem and L-devices for tty0am for dialing out. When something attempts to use the device the driver simply ensures that some simple rules are followed to prevent more than one virtual device accessing the physical device at a time. These changes are fairly easy to add to a serial driver, and can be encapsulated into about three different procedures that are called from the serial open and close routines. The following rules work well. They seem to work well and allow a wide variation of standard unix software to work well. I.e. cu, uucico, getty. A few variations such as forcing HUPCL and not allowing CLOCAL for the getty devices help keep your system a bit more secure. I havn't figured out what to use the last set of minor device numbers for (64-127) but one suggestion is to support a printer attached to a terminal on that port. Local Virtual Device (LVD) ========================== The LVD is generally used for direct connect terminals, where you do not want the line to disconnect when if it is unplugged, or if you wish to use a three wire (GND, TD, RD) connection. - an LVD cannot be opened if the MVD is open or waiting to open; or if the GVD is open. - CLOCAL and CARR_ON are set for each successful open (i.e. a second open will set them again). - CLOCAL can be turned of enabling the use of modem controls. Modem Virtual Device (MVD) ========================== The MVD is generally used with any device which supports modem controls, and when you have software which can utilize the signals appropriately. - a MVD cannot be opened if the LVD is open or waiting to open; or if the GVD is open. - when opened a MVD will wait for carrier if FNDELAY is specified. - CLOCAL can be turned on to disable the use of modem controls. Getty Virtual Device (GVD) ========================== The GVD is designed specifically to allow a modem to be used for both incoming and outgoing calls without having to disable / enable the getty waiting for incoming calls. It does this by only allowing the getty to wake up for carrier when no other virtual device is open and wants to respond to the carrier. - when opened a GVD will always wait for carrier, even if the LVD or MVD is open, or the MVD is waiting for carrier. - CLOCAL is not allowed to be set for a GVD. - HUPCL is not allowed to be reset for a GVD. - a GVD waits two seconds after seeing carrier, checks that no other virtual device completed an open, flush's the incoming data before completing the open. - a GVD will wait two seconds, re-init the serial chip and raise DTR after a different virtual device closes and drops DTR if waiting for carrier. Carrier Detect ============== Changes in Carrier Detect are monitored iff a virtual device is open, waiting to open (MVD or GVD) and CLOCAL is not set. If Carrier is lost then the drivers buffers are flushed and a SIGHUP signal is sent to the process group which opened the device regardless of what type of virtual device is open (if CLOCAL is not set). If Carrier becomes true, any processes waiting for carrier are restarted (usually a MVD or GVD waiting to open). Error Codes =========== ENXIO invalid channel, no serial device associated with this minor device. EBUSY all ready open with XCLUDE flag, or different virtual device -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
stefan@mikros.systemware.de (Stefan Stapelberg) (09/21/88)
In article <1260@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes: > >[driver supporting dialin/dialout on same device] > >Anybody know why everyone hasn't picked up on this? I know that some of >the PC Unix systems use it. I would like to implement this scheme, but controlling the DTR signal from the modem turns out to be a problem: The modem doesn't answer rings if DTR has not been asserted by the opening process. Unfortunately, I have to use DTR to hangup the modem after dialing out. So my question is: If getty's open has asserted DTR high and uucico's last close sets DTR to low, how can I ensure that the modem still will answer rings? I cannot use the RI signal. I didn't want to have the driver to look for a "RING" (in word responses or as a hardware signal) and initializing the modem from within driver level seems to be a bad idea also. Any hints? Thanx, Stefan -- MIKROS Systemware stefan@mikros.UUCP, {uunet,mcvax}!unido!mikros!stefan Stefan Stapelberg stefan@mikros.systemware.de, stefan@ira.uka.de Phone +49 9352 5948 ^D: These are my employer's opinions - you wonder why?
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (09/22/88)
In article <324@mikros.systemware.de> stefan@mikros.UUCP (Stefan Stapelberg) writes: >I would like to implement this scheme, but controlling the >DTR signal from the modem turns out to be a problem: The modem >doesn't answer rings if DTR has not been asserted by the opening >process. Unfortunately, I have to use DTR to hangup the modem >after dialing out. The Bell-compatible modem spec says that to hang up a modem, you drop DTR and hold it down until CD goes away... but you do not have to hold it down more than 250 milliseconds. Can you just pulse DTR down (to hang up) then back up? Marc Kaufman (kaufman@polya.stanford.edu)
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (09/23/88)
In article <324@mikros.systemware.de> stefan@mikros.UUCP (Stefan Stapelberg) writes: >In article <1260@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes: >> >>[driver supporting dialin/dialout on same device] >> >>Anybody know why everyone hasn't picked up on this? I know that some of >>the PC Unix systems use it. > >I would like to implement this scheme, but controlling the >DTR signal from the modem turns out to be a problem: The modem >doesn't answer rings if DTR has not been asserted by the opening >process. Unfortunately, I have to use DTR to hangup the modem >after dialing out. > >So my question is: If getty's open has asserted DTR high and >uucico's last close sets DTR to low, how can I ensure that the >modem still will answer rings? I cannot use the RI signal. > >I didn't want to have the driver to look for a "RING" (in word >responses or as a hardware signal) and initializing the modem >from within driver level seems to be a bad idea also. > It's actually quite easy when you do it in the driver. In the close routine you must: wakeup((caddr_t)&tp->t_canq); This wakes up the process (getty in this case) waiting for DCD to be set (remembering that getty already saw DCD get set for this session, but ignored it because another process was also waiting, so it went back to sleep). Then in the wait loop for the getty device: case GDEVICE: /* getty, wait for carrier */ /* if nobody is already waiting or has opened the physical device * we init tp, and the hardware, to raise DTR */ if ( !( *statep & GISOPEN ) ) { *statep |= GWOPEN; x = SPLTTY(); if ( !( flag & FNDELAY ) ) /* should we wait for CARR_ON */ while ( (*statep & GWOPEN ) && /* have we been cancelled? */ (( *statep & (LISOPEN|MISOPEN)) || /* anyone else open? */ (!( tp->t_state & CARR_ON )) ) /* no carrier yet? */ ) { delay(GETTYWAIT*HZ); /* wait a bit */ if ( *statep == GWOPEN ) { /* if only GWOPEN */ ttinit( tp ); /* fake tty init and raise DTR */ tp->t_proc = XXXPROC; tp->t_state |= WOPEN; /* getty waiting */ XXXPARAM( dev, tp, ON, NO ); YYYSTS( chan ); /* should we be doing this? */ if ( YYYSDCD( chan ) ) tp->t_state |= CARR_ON; else tp->t_state &= ~CARR_ON; } if ( !(tp->t_state&CARR_ON) || (*statep != GWOPEN) ) sleep((caddr_t)&tp->t_canq, TTIPRI );/* wait for carrier */ } if ( *statep & GWOPEN ) { /* was open cancelled by close? */ *statep &= ~GWOPEN; /* reset GWOPEN */ *statep |= GISOPEN; /* set GISOPEN */ delay(GETTYWAIT*HZ); /* give modem time to get line */ ttyflush( tp, FREAD|FWRITE ); /* dump any messages from modem */ YYYSTS( chan ); /* should we be doing this? */ if ( !YYYSDCD( chan ) ) /* check for DCD again */ goto errexit; /* oh boy! let's bomb out */ /* could try goto top; */ } else { *statep &= ~(GWOPEN|GISOPEN); /* reset GWOPEN */ goto errexit; /* can't hack it bomb out */ } Basically getty continously sleeps waiting for DCD. Whenever it wakes up it checks for DCD, no one else having the port open, etc. If DCD is no asserted then it waits two seconds, raises DTR and goes back to sleep. This gives the modem plenty of time to reset (Hayes are the worst I've seen, take about 1 second to reset). Another little feature is to wait one or two seconds after seeing DCD and flushing the buffers. This will get rid of any unwanted messages from your modem. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532