Re: gettytab Einstellung fuer Modem

As Dominik Brettnacher wrote:

> Aber davon ab: mit /dev/cuaa1 klappt es, wie in gettytab(5)
> beschrieben. Mit /dev/ttyd1 hingegen nicht. Ist nicht nur meine
> Erfahrung hier, sondern das funktioniert anscheinend auch bei vielen
> anderen so, wenn man sich mal in den englischsprachigen
> Mailinglisten umschaut. Warum?

Weil Du den Unterschied zwischen ttyd und cua nicht verstanden hast.

Das Prinzip ist folgendes. Wenn ein Port sowohl für dialin als auch
dialout benutzt wird und vernünftig funktionierende Modems hat, dann
stellt man das Modem auf ATS0=1 (und die zum getty passende Baudrate)
und speichert dies ab. Danach wird der getty auf ttyd* gestartet, da
das Modem keinen Carrier hat, blockt open(2), und der getty schläft
auf diesem Event.

Jetzt kann eins von zwei Dingen passieren (vom Herunterfahren des
Rechners mal abgesehen): 1.) ein Ruf kommt an, das Modem nimmt (S0=1)
ab und setzt schließlich DCD, sowie der Carrier erkannt ist. Damit
wird der schlafende getty geweckt, und der Nutzer kann sich einloggen.

2.) Jemand benutzt das zugehörige cua (calling unit). Er bekommt
initial die Verbindung auch ohne das Vorhandensein eines DCD
zugeschlagen, der open(2) auf dem ttyd wird ausgesetzt, so daß der
getty weiterschläft. Kommt später noch ein DCD zustande (und ist
CLOCAL nicht gesetzt), so verhält sich der Port ab diesem Moment wie
ein Modem-Dialin, d. h. ein Abfallen von DCD bewirkt ein SIGHUP.
Sowie der cua geschlossen worden ist (egal ob durch DCD-Abfall oder
freiwillig durch den Aufrufer), wird das ttyd wieder entblockt, so daß
alles von vorn losgehen kann.

Diese Variante der Verteilung hat den Vorteil, im Kernel eine Art
Semaphore zu benutzen, die insgesamt recht sauber funktioniert. Das
alles ohne das Verlassen auf eklige Lockfiles irgendwo im Filesystem
(die nur aus Kompatibilitätsgründen trotzdem in der Regel angelegt
werden).

Für mgetty (das ja die Meldungen nach dem CONNECT auswerten möchte)
wäre es noch eine sinnvolle Erweiterung, ein ``connect on ring'' für
das ttyd als Option zu implementieren, d. h. das geblockte open()
nicht erst bei DCD zu vollenden sondern schon beim Auftauchen des
Signals RI. Damit könnte man die Vorteile beider Konzepte vereinen.

Wenn Du natürlich ein Modem hast, das so'nen Humbug wie ``init
strings'' braucht, dann bist Du aufgeschmissen. Für mich gehören
derartige Teile genauso wie IDE-Platten allerdings bestenfalls in die
Rundablage... YMMV.

Wenn Du Nutzer hast, die an den Modemeinstellungen rumspielen,
solltest Du die man page zu rmuser(8) konsultieren der Deine Wahl für
die Mitglieder der Gruppe `dialer' nochmals überdenken. :-) Ein Laden
des aktiven Profiles nach DTR-Verlust sollte für jedes ordentliche
Modem ausreichend sein (AT&D3 oder sowas).

-- 
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message