Obnoxious load-dependant bug in UUCP

Alexis Rosen alexis at panix.uucp
Sun Mar 17 17:24:54 AEST 1991


mann at intacc.uucp (Jeff Mann) writes:
> alexis at panix.uucp (Alexis Rosen) writes:
>>I've been using UUCP very heavily on this A/UX Mac IIx now for several months.
>> [...] When the system is fairly busy (several active users), I frequently
>>see log entries like this:
>>cmcl2!notes (3/4-19:24:45) (C,15402,21) IN SEND/SLAVE MODE (INPUT FAILURE)
>>cmcl2!notes (3/4-19:24:45) (C,15402,21) FAILED (conversation complete)
>....
>>  [and, infrequently...]
>>cmcl2!jsb (3/4-19:31:32) (C,15598,1) BAD READ (expected 'C' got FAIL)
>>cmcl2!jsb (3/4-19:31:32) (C,15598,1) FAILED (conversation complete)
>
>I received the same errors for a time when I was setting up uucp, they were
>related to a flow control problem. Since the Mac cannot support hardware
>flow control and modem control at the same time, and since modem control is
>essential for security and other reasons, you cannot use flow control at
>all, which means you can't use the Telebit's auto baud rate translation
>feature. Before I came to my senses and realised this, I tried using software
>flow control (XON/XOFF). Of course, you can't use software flow control
>with uucp. The result of doing so was the same type of error messages
>described above.

Yes. But I expect that with that kind of erroneous setup you could never
transmit binary files of any significant length. That's not it- I turn off
Xon/Xoff. I quote from my L.sys: "ATS48=1S58=0"

>Alexis, would you mind posting a short description of the polling script
>you use (or the script itself if it is short enough). I have also written

Done. This went out several days ago.

>some stuff which lets me successfully use a port for incoming and
>outgoing calls.  First I have a c program called setmodem.  When
>changing a port from incoming to outgoing, it uses init(1M) to turn the
>getty off for the port, turns off modem control so I can talk to the
>modem, and sets up parameters on the Telebit. I also have a fake uucico
>which calls setmodem before exec'ing the real uucico. I can post these
>programs, along with a few necessary changes to inittab, etc., if there
>is a demand for it. I think it should be portable to any A/UX system.

While this no doubt works fine, it's way more elaborate than you need. That's
because somebody at Apple wanted things to work right, and spent some time
and effort making getty Do The Right Thing. It's just too bad s/he wasn't
able to clean up UUCP at the same time. As of 2.0, getty is "bidirectional"
in that it understands UUCP lock files, and it won't grab a serial port it's
trying to open if some other process (like uucico) grabs it first.

The only reason the whole thing doesn't work automatically is that uucico is
still very stupid. It doesn't know to do a "stty -modem" on its line first,
and to set it back when it's done.

The bottom line is that inittab need never be changed. In fact, you don't
really need to write a poll script at all- you can simply wrap uucico in a
script which does a stty on each side of the real uucico. The reason I use a
poll script is to try calling several times. (Also, don't forget that no matter
how you set things up, _something_ has to set TZ before you invoke uucico!!)

Anyway, if anyone has any ideas about that SEND/SLAVE MODE problem, I'd love
to hear it. I'm pretty sure Jeff was on the right track, in that _something_
is freezing up the transmission until uucico times out. I just wish I could
figure out what...

---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis



More information about the Comp.unix.aux mailing list