From owner-freebsd-hackers Sat Jun 28 21:13:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA16487 for hackers-outgoing; Sat, 28 Jun 1997 21:13:02 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA16473 for ; Sat, 28 Jun 1997 21:12:46 -0700 (PDT) Received: (qmail 26679 invoked by uid 1000); 29 Jun 1997 03:57:08 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199706281513.BAA32119@godzilla.zeta.org.au> Date: Sat, 28 Jun 1997 20:57:08 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Bruce Evans Subject: Re: com console, and h/w flow control... Cc: freebsd-hackers@FreeBSD.ORG, mburgett@cmnsens.zoom.com, tom@sdf.com Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Bruce Evans; On 28-Jun-97 you wrote: ... > DTR is raised when init opens the console (if it's a serial console). In a properly wired and configured modem (or terminal server), unless DTR is true, the DCE will refuse to pass any connections. We are not trying to prevent an intruder with physical access to the system (we view these attempts as useless - See boot floppy, etc.). What we are trying to do, is define a safe configuration that, while working, will not have a single point of failure. Raising DTR on OPEN is quite satisfactory on the outgoing side of the port. How about NOT completing the open until DCD is true? And sending a SIGHUP when DCD drops? If init is responsible, then we can change that easily. This is what O/S sources are for. Right? :-) > There's nothing to prevent a suitably timed call from interrupting the > boot. I think there's something to prevent single user shells. Anyone knows what that is? > Apart from that, you have to stty the initial state port to turn clocal > off for subsequent logins. You should also stty the lock state port to > lock clocal (off) for subsequent logins in case the kernel doesn't lock > it (the kernel currently locks it (on) for the console only). > > You should not use option BREAK_TO_DEBUGGER. > > The remaining details are the same as for a normal port. I'm not sure of > them all. Thanx! Simon