Date: Sat, 28 Jun 1997 20:57:08 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-hackers@FreeBSD.ORG, mburgett@cmnsens.zoom.com, tom@sdf.com Subject: Re: com console, and h/w flow control... Message-ID: <XFMail.970628205708.Shimon@i-Connect.Net> In-Reply-To: <199706281513.BAA32119@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970628205708.Shimon>