Subject: wierd serial I/O (slip) probs
To: None <current-users@NetBSD.ORG>
From: VaX#n8 <vax@ccwf.cc.utexas.edu>
List: current-users
Date: 11/29/1994 22:14:38
Okay, I'm having strange problems here.  I've been trying to get my slip
maintaining program to restart the link after a dropped link - unsuccessfully.
The setup is this:

NetBSD 0.9 Perl executable (I think - date is 18 Jan 1994)
NetBSD-1.0 kernel and programs

Before making the link, I set clocal properly.
I have tried two variants of the program, one which leaves clocal on, the
other which turns clocal off after getting a CONNECT string (and back on
when the echo times out... see next paragraph)

The problem is that, when the link is dropped, the program detects it
with a echo that times out.  It then hangs up the modem and sends another
dial string, but the modem never sends an "OK" back to the dial string
(I don't know about the hangup string - except that it is most definitely
hung up - MR AA HS CS are the only lights on.  TR comes on when sending
"+++" et. al.

Now, here's the problem; if all the lights go off (incl. TR {DTR}), then
the serial port should be set to its original, normal state, right?
So why is the subsequent write to the port timing out?  I go through the
exact same procedure - dup'ing the /dev/ttyxx onto stdin/out, etc.

Note that killing the process off and re-running it works fine.
I assumed that perhaps some process-related structure was screwing it
up (an unclosed fd perhaps?)

So, on that note, I wrote another program which was a "master" and forked
off a sub-process which should dial/connect/ping/whatever.  However, this
"master" program simply configures the line (as clocal) and then opens it,
but it hangs -every other time- on open. It doesn't get to the forking loop
on the even-numbered runs.  Of course, if it works right, it should only
run once, but what is holding state between sequential runs?

I've examined termios, com, and two device driver books but I'm stumped.
Recompiling perl would mean getting 5.0 and making a new kernel and
having to learn config.new (I'm -current source-wise), which would be
a minor delay :)
-- 
VaX#n8 (vak-sa-nate) - n, CS senior++ and Unix junkie - vax@ccwf.cc.utexas.edu
Just the vax-man.  Read my MIPS, no new VAXes!        - PGP key on request