Date: Mon, 24 Jul 1995 01:37:42 +0400 (MSD) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka "Andrey A. Chernov, Black Mage" <ache@astral.msk.su> To: bde@zeta.org.au, terry@cs.weber.edu Cc: hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <dVc4i4mqF4@astral.msk.su> In-Reply-To: <199507232028.GAA21623@godzilla.zeta.org.au>; from Bruce Evans at Mon, 24 Jul 1995 06:28:08 %2B1000 References: <199507232028.GAA21623@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199507232028.GAA21623@godzilla.zeta.org.au> Bruce Evans
writes:
>It can't possibly depend on anything except signals on its RX line, and
>getty is in complete control of those (unless there are bugs). I'm
>assuming an external modem. For an internal modem emulating a 16x50,
>the current 16x50 setting should apply.
Ok, I finaly understand what you say now :-)
So, described situation is possible, only when some dialout application
previously send chars at different speed and modem remember
last speed. So, my comhardclose() fix with comparam(com->it_in)
isn't enough, because driver need to send AAAT\r command to modem
after it additionly :-(
Getty becomes too modem specific after it.
It need to send AAAT\r initially too to bring modem to current
getty speed first time :-(
So, any dialout program which change serial speed becomes
getty-killer. We need to document locked devices to getty/gettytab
manpage too as mandatory to not allow speed changes.
--
Andrey A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dVc4i4mqF4>