1

My goal is to use an FTDI null modem cable (FTDI-nmc) with integrated USB-serial converter on both ends as a simple and convenient method to occasionally log-in to various headless devices such as servers, SCB's and developer boards.

My headless devices all have two things in common: a USB port and a Linux operating system. For simplicity, let's just call them 'server'. I use a laptop or SBC, e.g. RPi3 (let's just call them 'client') to log in to the headless devices using the FTDI-nmc. Both run on Linux too. For various reasons I do not want to use network connections for this, a serial connection is plenty enough for my purposes.

My knowledge of Linux in general and serial connections in particular is quite limited. Unsurprisingly, my first couple of attempts to connect a Linux box (Ubuntu 18.04 desktop) to SCB's (RPi3 latest Raspbian) and Tinkerboard (latest Debian Tinker OS) were unsuccessful. I always used Putty on the client (and still do) to attempt log-in on the server. Several configuration changes later I was lucky enough to arrive at a login prompt and a successful login, but for some reason I got the log-in prompt only the first time the FTDI-nmc was plugged in. Disconnecting it and plugging it in a second time would always end in failure to connect, i.e. no login prompt would come up. Unfortunately, I was disappointed (and stupid) enough to not take any notes about the config changes I had made at that point. That was a mistake.

On the other hand, it prompted me to look for and read more info on the topic which hopefully gave me a better understanding of the whole problem. Broadly speaking, here are things I changed/modified/tested but no longer consider as being part of the core problem:

  1. kernel command line, adding console=ttyUSB0 (server yes, client no) is enough
  2. serial-getty@ttyUSB0.service (enabled on server, disabled on client) is probably OK with ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 %I $TERM
    (or would it be better to replace $TERM with vt102 or xterm ?)
  3. default udev rules unchanged (at least on server, not sure on client)
  4. permissions (tried everything possible without success)

Yet, no matter what I change in terms of configuration, the result is so far always the same:
If I start Putty on the client and open a connection with the serial port (/dev/ttyUSB0), only a blank, unresponsive terminal window will pop up. It shows nothing but a cursor and it is not possible to type anything in this terminal window. However, some form of access over the serial ports appears to take place as Putty does not complain or throw any error message.

The terminal window being blank with no text whatsoever makes me believe that the process has not even gotten to the point where it's supposed to switch to the login program, i.e. the point where one has to type a password. If that is true, does it also mean that the process gets stuck because something is wrong with the communication parameters of the serial connection. Likely a mismatch between both ends of the serial line? My best guess is a mismatch in baud rate. If the baud rate were correct, shouldn't there at least be a login prompt asking for the user name? If I understand correctly, agetty uses the the first few characters of the login name to figure out parity. But, apparently, the process does not even get that far in my case. Hence, my suspicion about a baud-rate mismatch. But why can't I at least see garbled text then, instead of just a blank terminal window.

Needless to say, I have tried all kinds of baud rates in Putty settings but to no avail. (I use the same baud rate in the Putty categories "session - speed" and "Connection-serial". Does the choice of baud rate in category "Connection - Data" matter as well?)

How can I verify the actual baud rate? stty -F /dev/ttyUSB0 -a is supposed to be the right tool for the job, but it gives me results which do not seem to correlate with anything I'd expect based on other settings. If I use console=ttyUSB0,115200 on the kernel command line of the server and reboot, stty still shows 9600, for example. But using the baud rate reported by stty (9600) as the speed for Putty on the client doesn't seem to have any effect either.

Am I correct in assuming that the flow control setting is not critical in the sense that the FTDI-nmc will automatically adapt to the settings in Putty (given that I do not use a flow control parameter setting in the kernel command line or the serial-getty service of systemd). In other words, any flow control settings in Putty shoudn't cause errors in the FTDI chip, right?

Finally, I need to mention the one thing I can recall from the one successful login mentioned above. The permissions and (owner:group) for the device file /dev/ttyUSB0 port on the client were different compared to now. The first time the FTDI-nmc was plugged in it ended up as (root:tty) with 620 permission. At these conditions the login prompt showed up and login was successful via Putty. However, closing the Putty session, unplugging and reconnecting the FTDI-nmc always resulted in /dev/ttyUSB0 with (root:dialout) and 660 permissions (which is identical to what I got in all subsequent login attempts up to now) and the problem with a blank Putty terminal window and missing login prompt appeared. I do not have the slightest idea how this was possible. And as mentioned before, trying all kinds of different settings regarding group memmbership and permissions didn't help solve the probelm. Unfortunately I do not recall any of the other configuration details from that singular successful login (I could repeat that effect several times with unchanged settings, so 'singular' in the sense of 'one particular parameter configuration'. Well, at least this observation seems to indicate that the cable itself is not at fault.

Any advice on this is much appreciated. I am sure I am missing something obvious, but I am running out of ideas.

0

The core problem seems to be a bug related to bind/unbind kernel events in systems with kernel versions 4.12+ and difficulties of systemd/udev daemons to handle these events. In my case this apparently has the effect that the serial-getty@ttyUSB0.service only works the first time the FTDI-nmc is plugged in. Once unplugged, the service won't automatically spawn a new getty upon replugging the USB device. I do not understand all technical details but as far as I can tell this bug has not been resolved yet.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.