Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA7078 ; Mon, 18 Jan 93 10:47:06 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!agate.berkeley.edu!cgd
From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] sliplogin process doesn't die after hangup
Date: 18 Jan 93 02:19:42
Organization: Kernel Hackers 'r' Us
Lines: 35
Message-ID: <CGD.93Jan18021942@eden.CS.Berkeley.EDU>
References: <1993Jan18.034133.11979@mnemosyne.cs.du.edu>
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: smace@nyx.cs.du.edu's message of Mon, 18 Jan 93 03:41:33 GMT
In article <1993Jan18.034133.11979@mnemosyne.cs.du.edu> smace@nyx.cs.du.edu (Scott Mace) writes:
>I have sucessfully been using SLIP to log into another 386bsd machine
>over USR 14.4 modems. On the 386bsd server side I cannot get sliplogin
>process to HUP after the client end breaks the connection. Are there
>some special #defines I have to use, is it a setup problem, or s bug in
>sliplogin? Any help would be appreciated...
i assume that you're not using my hacked serial driver;
i tried it w/my driver, and it worked fine...
the problem you're seeing is a side effect of line 148 of
/sys/i386/isa/com.c (that line number's correct w/ all the latest
patches... otherwise, it's someplace around there... 8-)
which says:
comsoftCAR |= 1 << unit; /* XXX */
change that 1 to a zero, and recompile/reinstall your kernel.
basically, the stock serial driver completely ignores the carrier
state of the modem (as reported by the RS-232 DCD signal)...
chris
p.s. i'm working on a newer, better version of my driver... not necessarily
faster than the current one, but the current one is buggy, and i made
some *stupid* mistakes in it... 8-) maybe before, maybe after USENIX,
depending on how much sleep i want... 8-)
--
Chris G. Demetriou cgd@cs.berkeley.edu
"Sometimes it is better to have twenty million instructions by
Friday than twenty million instructions per second." -- Wes Clark