Date: Fri, 09 Aug 2002 10:55:22 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Langille <dan@langille.org> Cc: hackers@freebsd.org Subject: Re: serial console com1 to com1 == login race condition? Message-ID: <3D54020A.C4D1F405@mindspring.com> References: <3D53B3E5.5384.276CA6F0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Langille wrote: > I have two remote boxes. My colocation hosts have strung a crossover > serial cable from com1 to com1 on these boxes. The idea is that if I > paint myself into a corner on one box, I can get access to it from > the other box via the serial cable. > > But... > > I will need to set up serial consoles on each box in advance of a > problem arising. But won't I get a race condition with each box > thinking the other is trying to login? The historical fix for this problem is to not emit a banner or login until you get two CR's within a small time window. It is the banner/login that triggers the mutual login attempts. Usually, this is a getty hack. I believe vgetty and mgetty can do this (the initial system greeting and login banner comes from getty). You *must* have modem control, e.g. HUPCL, so that exiting the com program has the effect of resetting the other end to getty, rather than leaving it logged in, etc.. If these are actually consoles, then you are probably already screwed, since there will be a lot of spew with CR/LF all over the place. If you are willing to hack the driver, then you can make sure you are not sending DTR to the other side unless you open with a modified cu/tip program that has to do an explicit ioctl to turn it on to the other end. One incredibly -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D54020A.C4D1F405>