Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!pipex!uknet!mcsun!sun4nl!relay.philips.nl!cnplss5!bashful!rooij From: rooij@bashful.isp.cft.philips.nl (Guido van Rooij) Subject: Re: dial in (0.2.4) Message-ID: <1993Jul16.071001.23914@cnplss5.cnps.philips.nl> Sender: news@cnplss5.cnps.philips.nl (USENET News System) Nntp-Posting-Host: bashful Organization: Philips Communications & Processing Services, Eindhoven References: <21p7es$jf6@urmel.informatik.rwth-aachen.de> <CA7FKC.MIo@zap.uniforum.qc.ca> Date: Fri, 16 Jul 1993 07:10:01 GMT Lines: 23 fortin@zap.uniforum.qc.ca (Denis Fortin) writes: >there is a "login" process running for user "login:", which seems to >indicate that the BIDIR stuff might have a small flaw somewhere. >(i.e. the uucico fails and goes away, but the DTR isn't dropped >right away or the buffer isn't flushed or something so that the getty >gets woken up and receives the login: prompt from the remote system >and then attempts to negociate a login with it (so both systems end >up with users called "login:" trying to log on with a password >"Password:" :-(. Indeed. I forgot to implement a 'hold DTR down for a minimum time' like in cgd's driver. It's quite easy to solve and I'll do it soon. (Note that you can set it in your modem too: there is a S-reg that specifies after how many msec's of DTR, teh connection is closed.) Basically what happens is that the dialout session closes the connection. DTR is held low. Getty wakes up but because the modem did not (yet) react to DTR being low, getty sees a carrier and the open succeeds. >Has anybody else seen this? >-- >Denis, fortin@zap.uniforum.qc.ca -Guido