Hello, I have got several usb to serial convertors supported by FreeBSD (uftdi(4) and uplcom(4) based) and for some reason getty doesn't work with them. I can use them for outgoing communication without problem. While researching the issue I connected two computers with rollover serial cable. When I connect normal serial ports, I can run getty on both computers. When I connect uftdi(4) or uplcom(4) provided serial port to regular serial port getty works when running only on the computer with regular serial. When I start getty on usb serial (and stop in on the regular) I can connect to it from the computer with regular serial but after printing banner and login prompt it doesn't accept any input. I have ucom and uplcom built with USB_DEBUG so look at the debugging output. When comparing the debug from cu and getty's usage of the device I see that getty seems to stop device after each received newline character (in the debug output I see calls to ucomstop). If I issue some stty commands (stty -f /dev/cuaU0 dtrflow and sometimes crtscts) ucom will read some more characters (up to the next "\n"). Once login is completed (after "fixing up" the port several times with stty) communication works fine. I can't find any way to stop getty from calling ucomstop. Ucomstop is probably called as a result of getty initialization of a tty (port) but I can't find a way to disable it. The importance of newlines is probably because getty(8) reads just a username than changes into login(1) and does the reinitialization. Maybe login does some initialization too. Getty does it again when login refuses the password and getty is respawned. Workaround which works for me is to ingore the calls to ucomstop. I don't know what are these calls supposed to achieve but just from reading the names of the calls makes me wonder. We want to _stop reading_ - why should we? On the contrary - we are expecting some input. Attached patch fixes the problem for me. Better fix probably involves modifying getty(8). The situation is the same on 5-STABLE as on 6-CURRENT. Michal Mertl
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC