Date: Mon, 19 Feb 2001 05:45:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: josb@cncdsl.com Cc: arch@FreeBSD.ORG Subject: Dialer interface Message-ID: <200102190545.WAA12821@usr05.primenet.com> In-Reply-To: <20010217162656.E54688@lizzy.bugworks.com> from "Jos Backus" at Feb 17, 2001 04:26:56 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > Yes, the 'dialer' interface is a bit of a mess. Several years ago > > there was an entry in the CSRG project wish list for a networked > > dialer daemon that would intermediate access to dialout tty devices. > > (I *think* it was Keith Bostic's idea.) This might solve part of > > the problem. > > Maybe we could import BSD/OS' gettyd. Please don't. Microport had a much better approach in the mid 1908's, where you have three devices, /dev/tty11, /dev/tty11m, /dec/tty11M. One device had no modem control; this effectively meant that it didn't require DCD to open, or use CTS/RTS handshaking, or assert DTR only when an open was pending (so that a modem would answer the phone). I think modem control bit can be managed (or should be) via the gettytab, today. There were also two modem control devices: one for inbound calls, and one for outbound calls. The getty sat in the open on the inbound one, waiting for DCD to go high. When DCD went high, the open completed, and it spit out /etc/issue and it's initial "login: " request (getty issued this, so that you could still send it break, and get it to do the baud rate rotor thing; this predated baud rate locking in modems, but would be valid today with older modems to supporting locking, and/or people who hate having screens of data flash past after they hit ^C). If the outbound device was open, then the inbound open would be blocked, regardless of where or not DCD was present. That way you could call out on the outbound device, have DCD go high when the connection came up, and not be fighting with getty. The outbound device did not block its open pending DCD. If the inbound device was active because of the DCD being high from an incoming call being there first, then the open of the outgoing device would be failed (instead of blocking). So basically, getty ran all the time, not like the "enable/disable" thing on SCO, and not like the getty whose open completed, that then looked for a lock file, and closed and backed off until, as it checked once a minute, the lock file went away. This is, I think, how it should work. Only today, we could use only two devices, since modem controls could be handled in the gettytab, letting us get rid of the non-modem-control device (getty would open with O_NDELAY on such devices). For dealing with FAX, VOICE, and DATA calls, seperately, based on the connection notification banner from the modem, another O_RING (I don't care what it's named) option to open could let the open complete when RI went high, instead of waiting for DCD to be asserted (and missing the banner). A lot of the multiplex getty replacements open O_NDELAY and then watch for the banner. This conflicts with the ability to dial out on the same device. The O_RING approach resolves this problem (assuming there is no connection, the getty can close and reopen to wait for the next call, at the same time getting out of the way of a dialout). PS: I wrote a networked dialer daemon in the late 1980's, at Century Software. I don't think Greg ever released it as a prouct; he might be willing to give out the code. If not, it's a really, really trivial thing to write (the one I did used telnet protocol over the wire, and lived on a seperate port). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102190545.WAA12821>