Ceci est une ancienne révision du document !
Years ago, many screen-less devices did not usually have access to any kind of dedicated network. Ubiquitous WiFi was not yet a thing, nor was Bluetooth. Some of the more expensive printers did have Ethernet cards, as did servers, but in many cases, to set up the device or to regain control in the case of a crash, access was made through a serial connection.
Flash forward to modern times, and the serial port has disappeared altogether from most computers – though some servers and professional-grade routers still retain them as standard. The major use-case as of now is probably access to automobile onboard electronics, through the OBD (On-board Diagnostic) port found underneath the steering wheel in most cars. This can be seen as a variant of a serial connection. But, although some aspects of serial technology have changed over the years, it can still be a nice way to control a home server or an IoT (Internet of Things) device such a Raspberry Pi. As before, using a serial connection means we can troubleshoot and repair our system without ever needing to plug in a screen and a keyboard which, depending on its physical location, may be something of an issue. The protocols concerned are relatively simple, software is ubiquitous (for GNU/Linux and BSD operating systems), and hardware is cheap. For this reason, serial access can become something akin to a spare tire: a technique that we do not really wish to use often, but that we are very happy to have at our disposition when the need arises.
The hardware
I picked up the hardware required for this experiment online, and for a mere 10 euros obtained: two USB-to-serial dongles, and one 1.8 meter null-modem cable. One of the dongles will be needed to equip my (modern) computer with a serial port, in this case with the DB-9 male connector. The other dongle will be used on a Raspberry Pi. Although this small board already has two possibilities as regards serial connections, the onboard electronic circuits work only with TTL (Transistor-transistor level) voltages of about 0 V (for a logic 0), and about +5 V (for a logic 1) which, incidentally, is also the case for the Arduino. The usual serial connection for computers, on the other hand, obeys the RS-232 norm and works with inverted voltages of about +12 V (for a logic 0), and -12 V (for a logic 1). Specific integrated circuits (such as the MAX 232) are available to do conversion; however, for the Raspberry Pi it is simpler and more convenient to use a standard USB to serial dongle.
The null-modem cable is a very simple cable to connect two serial devices, that in our case has a female DB-9 connector at each end. It performs two main functions. One is as an electrical bus, where Signal Ground on both devices are connected together, and each device’s TX (transmission) pin is connected to the other device’s RX (reception) pin. The second function, which is implemented in most well-built null-modem cables, is to deactivate hardware control pins on both interfaces. Back in the day, these were used to control traffic between two modems, but this function is not really necessary for a short cable with no active electronics.
Setting up a serial terminal service
From the software point of view, it is fairly difficult to find up-to-date documentation on setting up a serial terminal server on a modern GNU/Linux distribution. The basic program –the getty utility– is usually already installed. But, most tutorials were written in a period when system services were configured using init or upstart, including community documentation found today at https://help.ubuntu.com/community/SerialConsoleHowto . Since that time, however, most distributions have moved over to systemd. It would seem that they have done so at a time when serial connections are little-used, which is why they have been rather neglected by the manuals.
I will be following this note https://ubuntuforums.org/showthread.php?t=2343595 by user paulstaf. Though short, it is clear and will set you on the right track for most distributions, for instance on Ubuntu and Linux Mint for a computer, or Raspbian for a Raspberry Pi. I will be using Linux Mint 19.1 on the client computer, and either the same on a server computer or Raspbian 9 on a Raspberry Pi, also as a server. Most instructions should be identical between recent versions of Ubuntu, Linux Mint and Debian.
The first thing we will need to do is verify our existing system on the server. Let us start by seeing if getty is actually installed – as, indeed, it should be, to give up access to that standard VT (Virtual Terminals) that usually are activated on GNU/Linux systems:
# getty –version getty from util-linux 2.29.2
This looks good. If getty is not installed on your system, get it using your package manager of choice. Now, let us test the hardware. Plug the dongle into any available USB port, and check the kernel messages:
# dmesg | grep ttyUSB [ 2507.371545] usb 1-1.4: ch341-uart converter now attached to ttyUSB0
So far, so good: our USB dongle has been recognized by the kernel’s USB subsystem, and configured as /dev/ttyUSB0. Most USB-to-serial hardware is rather standard, and should be detected and set up with no problems. However, if it is correctly connected and no /dev/ttyUSB* devices show up, that means we have a hardware problem and will probably need to try another physical dongle.
Next, become root (using the su or sudo commands), and navigate to the directory /lib/systemd/system. Here, we will need to create a new service file. It can have any name we choose, but it is best to use a name we will remember easily. For instance, let us call it ttyUSB0.service, and edit it with the following contents:
[Unit] Description=USB Serial dongle console service [Service] ExecStart=/sbin/getty -L 115200 ttyUSB0 vt102 Restart=always [Install] WantedBy=multi-user.target
The main line here is the one beginning with “ExecStart”. In this, we invoke getty with the correct device and line speed; we will thus need to get it right. Substitute your real device name here, it may or not be ttyUSB0, depending on your precise setup. As for line speed, most devices will run along happily at 115200 baud (bits / second). If yours does not, try lowering the speed to 28800 or even 9600 for testing purposes. Once we are happy with our configuration, let us save the file and reload the daemon. This will force systemd to re-examine its configuration files, and hopefully detect the presence of the new file we just created.
# systemctl daemon-reload
Finally, we need to flag this service as enabled, so systemd will activate it each time the computer is booted:
# systemctl enable ttyUSB0.service Created symlink /etc/systemd/system/multi-user.target.wants/ttyUSB0.service → /lib/systemd/system/ttyUSB0.service.
In theory, we should now have a working setup on our server. The original authors of these instructions indicate they like to reboot the server computer to make sure the new configuration is in place, and, indeed, this can do no harm.
Once our getty service is up and running, let us turn to the client computer from which we intend to connect to the server. On a GNU/Linux system, there are very many serial terminal programs available. One that should already be installed is screen:
$ screen /dev/ttyUSB0 115200
Connect the two devices and the null-modem cable. You may need to hit the Enter key a couple of times on the client screen to activate the connection. You have also obtained some “strange characters” due to bit-rate errors, but they should disappear when the next login message comes up from the server. You can quit the screen command with key combination Ctrl+A and then an uppercase letter K.
If this does not work, perhaps a better choice would be either of cu or minicom. Install either using the standard commands:
$ sudo apt install cu $ sudo apt install minicom
Then connect, e.g. with cu:
$ cu -l /dev/ttyUSB0 -s 115200Connected. Raspbian GNU/Linux 9 raspberrypi ttyUSB0 raspberrypi login: pi Password: Last login: Fri Jul 12 18:15:53 UTC 2019 on ttyUSB0 […] pi@raspberrypi:~$
As before, a couple of Enter keys may be necessary to get to the login prompt. You can quit cu using command “~.”
Similar connections should be rather easy to set up on clients with a Mac OS or a Microsoft operating system, using the appropriate tools in either case. Even a very old or low-spec computer should be well up to the task of working as a serial terminal – even one with a rather ancient Intel 80386 to Pentium IV processor. If you still have one lying around, it could even come with a serial port on the motherboard known in the BIOS or MS-DOS as COM1: or COM2:, and in Linux as /dev/ttyS0 or /dev/ttyS1 . These can easily be found by examining the rear panel of the computer body for a 9-pin connector: see (a) in the following image. In such a case, you will not even need to acquire a USB dongle.
Enjoy!