Re: Getty on USB serial port

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Fri, Sep 15, 2017 at 05:52:10AM -0400, William D. Jones wrote:

> Now the questions:
> * While debugging, I disabled ttyU0 (FTDI cable connected) from the
> gettytab, rebooted, and attempted to echo characters down the serial line to
> be received by minicom on the other end; I got a `-sh: cannot create
> /dev/ttyU0: interrupted` each time. What could possibly cause this?

Looks like you do something like:

echo hello >/dev/ttyU0

and the shell receives an EINTR error which happens when it receives
a signal during that operation. If that's the only thing you do, the
only signal could be a SIGHUP, which means that you lost the carrier
signal and I don't see how that could happen.



> * `getty` is in fact spawning the `NetBSD (hostname) (tty?) login:` message
> and prompt, correct? Then `getty` will execve `login [user]` to ask for the
> password? One thing that confuses me is that the "user" prompt from both
> login and getty are identical. So I thought `getty` somehow execve's `login`
> to immediately show a prompt once certain conditions (RTS/CTS control?) of
> the serial line are met.

The initial prompt is done by getty. It knows some magic that lets you
reconfigure the tty (e.g. the autobaud and portselect features) and it
also has an automatic PPP detection. In the latter case, it will not
exec login but pppd.


> * I wanted to use the serial port that defaults to the console on my rpi as
> the ppp connection for various logistical reasons. Can I redirect kernel
> messages (and init messages) to another tty without recompiling? I don't see
> a kernel option in `man boot`.

The kernel messages always go to the "console", which is a low-level
interface. The kernel only knows two such devices (or three since a few
days), which are the serial port, the framebuffer/keyboard and the
second serial port (for RPI3 support).

Once the kernel is running, the console can be intercepted by a program.
In standard X11 there is a xconsole doing this, which displays the
messages in a window.

So, using the framebuffer is the most simple method. The serial port
isn't used then.

Intercepting the console with a program is another method. This still
causes early messages to be sent to the serial port, but that is seen
by ppp as line noise and filtered out.


> * Possibly related, I'm trying to test an ekermit xfer over /dev/plcom0, but
> to no avail. When I execute `ekermit -r < /dev/plcom0` as root, nothing
> happens; there's no output on remote end. When I execute `ekermit -r <
> /dev/plcom0` as a normal user, I get "Permission denied". Here are the
> permissions of each:
> 
> ```
> rpi-ptrain$ ls -l /dev/plcom0
> crw-------  1 uucp  wheel  93, 0 Jun 25 12:49 /dev/plcom0
> rpi-ptrain$ ls -l /dev/ttyU0
> crw-------  1 wjones  tty  74, 0 Jun 25 17:42 /dev/ttyU0

> Why are they different, and why do I own `ttyU0` (I don't think NetBSD
> dynamically creates/alters device nodes)?

plcom0 still has the default ownership, which is the uucp account for
the original communication protocol ("Unix-to-Unix-CoPy").

ttyU0 was running getty, you logged in and the login process passes
ownership of the tty to you. Ownership is reset when you log out.

The command 'write' is a very traditional way to send messages to
other users on the system by just writing text to their tty. The
command 'mesg' is used to grant and revoke write access for others.

You also need ownership to change tty settings, without this you
couldn't run e.g. a screen editor like vi.


> * While I don't think I'll need this, is `/etc/rc.local` a good place for
> serial parameters I need to change with `stty`?

Most drivers will reset parameters after use, so anything you set
in /etc/rc.local will probably get lost. It's better to set parameters
when you start using a tty.

The initial parameters for the RPI1+2 serial console are hardwired into
the kernel as 115.2kbps and 8N1. You can build a custom kernel to change
this by adding options PLCONSPEED and/or PLCONMODE.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."