Can't run getty on usb to serial converters and workaround

From: Michal Mertl <mime_at_traveller.cz>
Date: Fri, 21 Jan 2005 19:13:08 +0100
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


Received on Fri Jan 21 2005 - 17:13:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC