Login via USB Serial
                        ====================

Why, on earth, bother, why would one care?

Serial   logins,  done  right,   bypass   boatloads  of  network
equipment.  Back in the old  days,  servers  (some of them  even
Intel X86-based) offered, by default, console login via a RS232C
interface  and a terminal  or modem, in which case they could be
accessed  remotely  via  dial-up.   Throughput  speed  would  be
limited,  typically to 9600bps. Early  home-brew  computers used
terminals for access. Systems such as Apple IIs, Commodore's PET
& CBM series, RadioShack's Tandy product line, and finally IBM's
PCs changed that to an  integrated  monitor and keyboard  setup.
Servers    eventually   added   ILO   (integrated    lights-out)
controllers,  where a separate  processor  would allow access to
production   hardware  via  telnet,  ssh,  web  console,   would
therefore be vulnerable to LAN issues, such as failing switches,
jabbering, routing errors.

Linux, including  Raspbian, offers means to enable login through
serial interfaces. This used to be done by editing files such as
/etc/ttys to add a process  (such as getty,  mgetty,  agetty) to
listen on a serial port for  connections,  determine  throughput
rate, eventually  spawn off a login on that port. These days all
of this is taken care of by systemd using a service  definition.
Raspbian   provides  a  template  for  this  purpose,  found  in
/lib/systemd/system/serial-getty@.service.

This service template needs to be copied to be associated with a
device. Serial interfaces show up as /dev/ttyUSB0, /dev/ttyUSB1,
etc, also modified if necessary, then enabled and (if an adapter
is  present)  started.  Trying to start the  service  without an
adapter causes the start command to hang indefinitely.

The only thing to change is the  bitrate.  The  default bit rate
sequence  is   115200,38400,9600   bps.  When   establishing   a
connection,  the caller would send CR, LF or CRLF, then wait for
a legible  response. If none would show, or data received  would
appear  garbled,  the  caller  would  send a break  (one or more
null-bytes, or even a sequence of at list  (bits-per-byte)  zero
bits) to cause the called party to switch to the next (typically
slower) bps setting. Back when serial  consoles  were in general
use, 9600 was standard, 19200 would be pushing it, faster wasn't
an option,  and,  should  all that fail, 2400  would have to do.
Hardware has gotten  faster, so 115200 is easily doable, even by
a boat-anchor  OS like Windows. For remote  access, or if unsure
about  throughput  limitations of your terminal  server or other
communications gear, stick with 9600.

The default  service  template likes high speeds, so these might
have to go before starting the service:

pi@pi2b02:~/Serial $ cat setup.sh
#!/bin/sh
sed 's/115200,38400,//g' /lib/systemd/system/serial-getty@.service | \
    sudo dd of=/lib/systemd/system/serial-getty@ttyUSB0.service
ls -ls /lib/systemd/system/serial*
sudo systemctl daemon-reload
sudo systemctl stop serial-getty@ttyUSB0.service
sudo systemctl disable serial-getty@ttyUSB0.service
sudo systemctl enable serial-getty@ttyUSB0.service
if [ -f /dev/ttyUSB0 ]
then
    sudo systemctl start serial-getty@ttyUSB0.service
fi


pi@pi2b02:~/Serial $