Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!fu-berlin.de!news.belwue.de!News.Uni-Marburg.DE!news.th-darmstadt.de!hrz-ws11.hrz.uni-kassel.de!phase23!citylink.dinoex.sub.org!peter
From: peter@citylink.dinoex.sub.org (Peter Much)
Subject: Re: Problems with Com Ports
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Organization: Buero fuer Sektenforschung und Qualitaetspruefung in der Esoterik
Message-ID: <DCrC7u.525@citylink.dinoex.sub.org>
References: <3uremo$qsr@crl10.crl.com> <3vimm8$466@crl2.crl.com> <3vkrt3$k6j@bonnie.tcd-dresden.de> <3vqipt$m65@crl8.crl.com>
Date: Thu, 3 Aug 1995 23:07:05 GMT
Lines: 40
In article <3vqipt$m65@crl8.crl.com>, Christine Maxwell <kaila@crl.com> wrote:
>J Wunsch (j@bonnie.heep.sax.de) wrote:
>: Hmm, did you remind that all you're getting is garbage as long as the
>: speeds don't match? That's why the standard getty is using BREAK --
>: it's detected by the hardware. Your CONNECT message is rather
>: worthless if all you're getting is "b D_$הר\". :)
> I tried using the break code normally for a while, but it didn't
>work, and 90% of my users haven't a clue what a break is aside from a way
>to stop their car. Granted the connect message would be a problem in
>that case, but I believe most modern modems allow you to initialize with
>the option to report the DCE speed even while speed buffering, at least
>this wierd ibm modem does :) so it wouldn't be coming in as garbage :)
It shouldn't be a problem. As far as i remind vaguely from reading
some modem doc's, the CONNECT message will always be presented with the
speed the modem was last accessed. If there happens a speed adjustment
in the modem after connecting, this speed adjustment will happen after
the modem has reported the CONNECT message.
So, if the getty gives the modem an AT command when initializing, the
CONNECT message should come with the same speed as the AT command was.
The point seems to be: With this technique, one cannot retry, if it fails
(which is likely possible on an overloaded machine due to lost characters,
until that getty is swapped in again).
With BREAKs, one can retry, and the speeds will change again.
But i think this is mainly a point with automatic login scripts (uucp
etc.) - normal users won't like an overloaded machine, anyway...
Peter
--
Gib HASS keine Chance -
sag nein zu Faschismus, Feminismus und Staatsreligion
Write to: Peter Much * Koelnische Str. 22 * D-34117 Kassel * +49-561-774961
peter@citylink.dinoex.sub.org much@hrz.uni-kassel.de p.much@asco.nev.sub.de