Getty and PPP

[Harald Becker]

 Hallo Denys!

>>> getty -i -h -n -I 'ATE0Q1&D2&C1S0=1\015' -l /usr/bin/startppp 115200 /dev/ttyS1
>>>
>>> Is there any reason that getty would not wait?  I don't have the '-L'
>>> so it seems it should wait for carrier detect.
> It doesn't wait because we open tty with O_NONBLOCK.
> I don't know why we do that.
>
> agetty also does this. So it seems it's not a busybox deviation.

Outch ... looks to me O_NONBLOCK is wrong in getty ... except you do an
open (w/o blocking), emit some codes, close the device and reopen with
blocking ... or you have to wait for the raise of carrier on modem lines
in a different way.

>>   -I INITSTR   Send INITSTR before anything else
>>
>> As a suggestion -- could be better to cange this to read:
>>
>>   -I INITSTR   Send terminal INITSTR before anything else
>>
>> or
>>
>>   -I INITSTR   Send terminal (NOT modem) INITSTR before anything else
>>
>> or
>>
>>   -I INITSTR   Send terminal INITSTR before anything else (NOT for modem)
>
> I do not understand what are you trying to say in that text.
> We can't know where INITSTR goes (to modem or to whatever is connected
> to that modem) - we merely send these bytes to the tty.

INITSTR was never designed to be used for modem initialization tasks.
It's indention always was for tty init (like switching tty emulation,
tty reset etc.). So help  text shell give the info not to misuse for
modem init purposes as there are so many users expecting normal getty's
to work the same way as mgetty (which allows to initialize the modem
that way).


> One related gray area is whether we should use open(O_NONBLOCK)
> or not, and if not, what to do with INITSTR then: it will no longer be sent
> to tty immediately, but only after open() succeeds (which on !CLOCAL
> lines means "after Carrier Detect appears") - meaning that INITSTR
> can no longer be used to initialize modems.

INITSTR shall be send to the line after connection to tty has been
established and shall be used to initialize the tty (may be connected
via a modem line) to understand the expected control codes. INITSTR
shall never be send before the connection to the tty has been
established. As this INITSTR ist NOT for modem initialization. That was
the long standing behavior of getty processes on many systems I had been
working with.

Modem initialization is normally done ahead before getty is activated
and shall leave the modem in a state where it initializes to a working
state by just activating the DTR handshake signal. After that modem
shall be ready to accept incoming calls (auto answer).

If you want to have functionality to initialize a modem you need a
different function which opens the tty device in local mode, send the
init sequence, wait for the response then close the tty and reopen in
none local mode. ... or do it the mgetty way, open device and
watch/control all modem lines on your own (required by modern modems to
use extended functionalities).

This design may be considered awesome but think of the fact, the design
has been made at a time where modems where very thumb devices and multi
purpose/multi function "computers" for it's own. This is why mgetty is
so much different from other gettys. mgetty is designed to control/use
complex multi purpose modem devices.

Busybox getty is assembled close to the behavior of a standard getty so
it shall clearly inform users not to misuse INITSTR for modem
initialization purposes. IMHO (else BB getty needs heavy redesign!).

--
Harald