From owner-freebsd-current Sat Jun 21 11:31:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA12932 for current-outgoing; Sat, 21 Jun 1997 11:31:56 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA12927 for ; Sat, 21 Jun 1997 11:31:54 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.5/8.7.3) with SMTP id OAA22108; Sat, 21 Jun 1997 14:30:55 -0400 (EDT) Message-Id: <199706211830.OAA22108@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Terry Lambert cc: adam@veda.is (Adam David), joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: getty modem control References: <199706202227.PAA24698@phaeton.artisoft.com> In-reply-to: Your message of "Fri, 20 Jun 1997 15:27:38 PDT." <199706202227.PAA24698@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jun 1997 14:30:55 -0400 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Connect speed is evil. The data rate should be driven with the > RS232C external clock for modems (described in the RS232C, Bell 103C, > and Bell 212 standards). The negotiation for speed should be done > at the carrier recognition, and not between the UART on the modem > and the UART in the computer. Yes connect speed is evil. The data rate should be fixed at some higher rate, and you should use CTS/RTS "hardware" flow control. It's unclean and non-EIA standard, but the only thing which actually works for contemporary modems which use RS232, and link-level compression and reliability. You can't use an external clock for async data; the UART needs to sample at (usually) 3 or more times the data rate to discover the center of each bit by finding the leading edge of the start bit. Of course for DTE synchronous data transfers and modems, things are all different. Of course, for non-RS232 connected modems (like inside terminal servers which take a ISDN PRI in one and and ethernet out the other), things are all different. > This is an evil perpetrated on honest, God-fearing people by Intel > and National Semiconductor. You can't blame Intel for *this* particular evil. The folks that got this stuff right was Telebit. Their original modems had two serial interfaces on the connector, so you could chat with the modem out-of-band to configure and query it. These days, you'd use an SNMP MIB... louie