Re: Getty on USB serial port

["William D. Jones" <thor0505%comcast.net@localhost>]

Thank you for your answers.

> echo hello >/dev/ttyU0
Indeed that's what I did. I'll see if I can duplicate later. But reading 
tmux backlog, I had commented out the gettytab entry for ttyU0 when I tried 
that.

> it also has an automatic PPP detection. In the latter case, it will not 
> exec login but pppd.
Indeed, this is my intent for /dev/plcom0. The only reason I have a USB 
serial port attached is because I know I'll inevitably screw it up and lock 
myself out of my Pi if I don't :). Also, just plain good for debugging.

> So, using the framebuffer is the most simple method. The serial port isn't 
> used then.
For those reading along, this means putting "console=fb" into your 
`/boot/cmdline.txt`, even for a headless system.

> 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.
Yes, basically this is my concern. I don't know how well ppp will cope with 
random bursts of text. Just out of curiosity, I assume I need to write this 
program myself; how might I go about doing that? I know I need to `dup2` to 
redirect, but the problem is getting the correct fd to redirect so processes 
writing text to the console "see" my altered fd.

> 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.
Although ultimately what I'm going to do is just add a custom entry to 
`/etc/gettytab` with basically "run as fast as possible", this is useful to 
know. getty manual says that it will set the speed for me.


-----Original Message----- 
From: Michael van Elst
Sent: Friday, September 15, 2017 10:29 AM
To: William D. Jones
Cc: netbsd-users%netbsd.org@localhost
Subject: Re: Getty on USB serial port

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

--
William D. Jones
thor0505%comcast.net@localhost