Getty and PPP

[Denys Vlasenko]

On Friday 21 October 2011 21:26, Harald Becker wrote:
>  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.

Why do you think O_NONBLOCK is wrong?

agetty uses it (always).
mgetty uses it by default.


> >>   -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.

Says who?

I mean, I can't just take your work for that.
Show me that most/all gettys which have this option
explicitly say that this data are not meant to be used
to initialize modem.

> 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).

"man mgetty" says:

-I <fax id>
    Use the given fax station ID for fax identification. Not used for data modems. 

So, mgetty doesn't even have the same option, much less uses it
as you describe.


> > 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.

I need a bit more convincing. Point me to a few getty implemetations
on Linux which do this.


> 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!).

What is "standard getty"? Are there any [semi-]official docs about it?

-- 
vda