how connect dumb terminal over USB ?

nourathar · 2014-02-21 16:33:36

Hi,

I found this very beautiful old dumb terminal from circa 1980 and it seems to be functioning.
Today I got the right cables and usb-serial converters to connect it to my Arch box via USB, but I am stuck how to proceed.

In the wiki I found this page
https://wiki.archlinux.org/index.php/Wo … al_console

where it is explained how to start getty listening on /dev/ttyS0 using systemctl, and that seems to work for ttyUSB0 too.
I can start it, ttyUSB0 exists, but the getty service on it remains inactive.
Also I know I need to set the console type (vt52), baud rate, parity and such, and can not find anywhere how to set these.

SO I think I can start getty on my USB port, but I think it does not work because it does not have the right settings for my dumb terminal.

I found this explanation http://www.vanemery.com/Linux/Serial/se … nsole.html
which is perfect, except that most of it does not apply to systemd...

if I enter

agetty 19200 ttyUSB0 vt52

on my linuxbox, nothing happens, but then I'm not even sure whether that makes any sense.

thanks for any help !

J.

Last edited by nourathar (2014-02-21 16:48:59)

ewaller · 2014-02-21 17:22:41

First, you might check that everything works.
Check your output by piping something to /dev/ttyUSB0
For example: # ps-ef > /dev/ttyUSB0
You should see the output on the terminal. If the command hangs, check the hardware handshaking signals (DTE, DSR, RTS, and CTS), or, turn off hardware handshaking on the port.
If you see garbled characters, check the Baud, character format and parity.
Once that works, then try getting data from the port:
# echo < /dev/ttyUSB0
Type some characters on the terminal, hit Ctrl-D, and see if the characters are printed to the console.

You might fire up a terminal emulator (minicom, gtkterm) and tell it to use port /dev/ttyUSB0. You should then be able to "Chat". Type on the terminal, it appears on the console. Type on the console, it appears on the terminal.

Once you get this working, then take the next step.
BTW, this does work. In a fit of extreme nerdiness, I set my system up to use a serial console via a USB port. I them fired up my HP 50g calculator with a terminal program that lets it talk serial over its USB connection to a host. On my calculator, I was able to log in. I then realized I needed to get outside for a while

nourathar · 2014-02-21 22:40:52

thanks for the great advice: i'll try and report back !
Great story about the fit of nerdiness too , I guess the point of mine is just that I'd like to 'switch on' the terminal rather than 'open' it...

Last edited by nourathar (2014-02-21 22:41:09)

ewaller · 2014-02-21 22:54:59

Oh, one thing I forgot....

Most personal computers are wired as Data Terminals, not as Data Sets. (This hearkens back to the original IBM PC. The theory was that a "PC" would probably end up being hooked to one of their "Big Iron" machines [real computers] as a terminal.) As such your are likely to need a Null Modem cable rather than a straight through cable.

Last edited by ewaller (2014-02-21 22:56:00)

nourathar · 2014-02-22 10:32:48

Ok,

I can't get the printing of characters on the terminal to work properly:

something like

echo 'blabla' > /dev/ttyUSB0

gives me garbled characters on the terminal screen.

Parity 'No' is the only thing that works, baud rate of the terminal can not go higher than 19.2K baud and there is not more I can adjust on the terminal.

Then I found out about setserial and looked at the settings of my port:

$ setserial /dev/ttyUSB0 -G
/dev/ttyUSB0 uart 16654 port 0x0000 irq 0 baud_base 460800 spd_normal

but then if I try to set the baudrate to what I know it is, this happens:

setserial /dev/ttyUSB0 baud_base 19200
Cannot set serial info: Inappropriate ioctl for device

then I found out about stty:

sudo stty -F /dev/ttyUSB0 19200

now outputting on the terminal works !
but strangely the values reported by

$ setserial /dev/ttyUSB0 -G

have not changed..
will try input from terminal now....

Last edited by nourathar (2014-02-22 10:41:18)

nourathar · 2014-02-22 10:48:10

I can not get input from the terminal to work:

echo < /dev/ttyUSB0

does not wait for input, should it ?

but what is interesting is that

cat /dev/ttyUSB0

causes the characters I type on the video terminal to appear on the video terminal screen, which is normally not the case (if not in 'local' mode)
so it does seem to work to some extent, I would say ?

minicom --device /dev/ttyUSB0 --term vt52 --baudrate 19200

does not really work: if I type on the video terminal I get garbled characters on my linux box, if i type on my linux box I do not get characters on the video terminal.
Also here I think that it is a question of settings, but I don't really know what it could be.

And I am not surre that minicom recognizes that 'vt52' setting: the minicom statusbar tells me it is using VT102 and I can not find anywhere which terminals are supported.

thanks so far !

Last edited by nourathar (2014-02-22 11:44:57)

ewaller · 2014-02-22 15:47:56

The echo command I gave was just a first guess. In retrospect the cat command is a better choice. Is it a vt52 ? I had one of those when I was a kid -- attached to an Apple II with USCD P-System Pascal running on it. The vt52 was much nicer than for that than was the Apple II keyboard and display. I love the little relay click deep inside the machine every time you press a key

The difference between a vt52 and vt102 communication has to do with escape sequences. These are the character sequences that cause the terminal to do things like go to an x,y location, clear screen, clear to end of line, display blinking characters, display bold characters, etc.... These really don't matter until after you log in and try to run a program like emacs, vim, or anything that uses curses. The settings in minicom tell it to respond to escape sequences in the same way a vtxxx would. The vt10x series terminals were far more common than the older vt52 so things are more likely to default more modern terminals. Setting the terminal type in minicom is really not important for talking terminal to terminial.

Regardless, I think you are to the point where you can proceed with working on logging in from the terminal. I need to do a few things this morning, and I need to do a bit of research on this. I'll work with you on this as the day goes forward. Serial terminals make me all nostalgic.

Here is an article on the vt52

Edit: I note that that article says that Baud is limited to 9600. Mayhaps you do not have the vt52?

Last edited by ewaller (2014-02-22 15:50:47)

ewaller · 2014-02-22 17:10:39

I have not actually done this with systemd.

I think all you need to start /usr/lib/systemd/system/serial-getty@.service like:
systemctl start serrial-getty@ttyUSB0

It defaults to 9600 Baud (I think ), but it appears you change Baud by pressing the break key on the terminal.

Last edited by ewaller (2014-02-22 17:11:17)

nourathar · 2014-02-22 17:12:51

Hi,

what I have is a Volker-Craig 4152 terminal, so it is vt52-compatible, but it is not the same machine as a DEC vt52.
The manual for it is on its way, but I'm pretty sure there should be a way to switch on some kind of extra auditory feedback on this one too..
It does beep very nicely once in a while..

I'll try some more things too, but this is all very new to me and I do not seem to find documentation on how to do this under systemd, so any help is very much appreciated !
(I would be happy to add to the wiki with some info on how to do this..)

The thing I do not get with serial-getty service is how /where to set things like terminal type, baudrate and such.

Edit:

I tried what you suggested, and it seems to work, but I get garbled characters and other weirdness, which means that some communication is going on between the video terminal and my linux box, but they don't talk to eachother yet..

but it seems this page

http://0pointer.de/blog/projects/serial-console.html

is telling me what I need.

Last edited by nourathar (2014-02-22 17:23:22)

nourathar · 2014-02-22 18:28:47

ok, some progress:

I read http://0pointer.de/blog/projects/serial-console.html
and understood a bit more, so I now have this file as

/etc/systemd/system/serial-getty@ttyUSB0.service

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

[Service]
ExecStart=-/sbin/agetty --keep-baud %I 19200 vt52
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

which is the template, except for the line

ExecStart=-/sbin/agetty --keep-baud %I 19200 vt52

and I did

# ln -s /etc/systemd/system/serial-getty@ttyUSB0.service /etc/systemd/system/getty.target.wants/
# systemctl daemon-reload
# systemctl start serial-getty@ttyUSB0.service

which gave me something I suspected was a garbled login prompt.
I switched my terminal to 9600 baud and now I have an arch login prompt, but keys like return, line feed, enter and backspace do not work, so I can not actually login.

So the service works, it seems, but the settings in my file do not seem to be applied: the baurdrate not, and presumable also not the vt52 setting, which I suppose is rather crucial for things to actually work. Perhaps that is also the explanation for the return key etc. not working ?

does anybody know what is going on here ?
what am I doing wrong ?

Last edited by nourathar (2014-02-22 18:49:14)

ewaller · 2014-02-22 19:10:22

Sounds promising. If I understand, the terminal now shows an Arch log on prompt, you can type your user name, and it echos, but the return key does not work? Try Ctrl-m instead of return.
The other possibility is that you still have a problem with character format (7 bit vs 8 bit) or maybe a parity problem. The terminal may ignore parity, whereas Linux doesn't.

nourathar · 2014-02-22 19:25:09

hmm, I was doing something else, and now it just works ?
that is great
now I do hope this is reproducible !

Only thing is that I still see some weird characters and for instance archey gives strange results;
on second thought I guess I have to switch off colour somewhere: it might be codes dealing with colour that I am seeing, I see the same kind of weirdness in directory listings around directory names.

but thanks a lot for your help and for putting me on the right track !

Last edited by nourathar (2014-02-22 19:26:10)

nourathar · 2014-02-23 11:58:09

I don't know what coincidence or sequence of me trying things out made it work once yesterday; but it was an unreproducible miracle apparently.

I figured out that even when it worked yesterday, I was seeing color codes, which means that the 'vt52' argument of agetty must have been ignored, since I checked the terminfo of vt52 using infocmp, and there is no reason why there should be color codes there. It was probably reverting to a linux terminal even. The default for serial-getty is 'vt100', which also dates from way before consoles in color existed.

And earlier I figured out that also it was ignoring the baud-rate argument, so it seems perhaps the serial-getty@ttyUSB0.service I set up is not being used so my arguments and options are irrelevant ? or it fails and falls back to some other default ?

Edit:

after looking at the systemctl journal I saw stuff like this:.

$ sudo journalctl -u serial-getty@ttyUSB0.service
Feb 23 13:14:10 box login[1506]: pam_securetty(login:auth): access denied: tty 'ttyUSB0' is not secure !
Feb 23 13:14:10 box login[1506]: pam_tally(login:auth): pam_get_uid; no such user
Feb 23 13:14:12 box login[1506]: pam_unix(login:auth): check pass; user unknown
Feb 23 13:14:12 box login[1506]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=ttyUSB0 ruser= rhost=
Feb 23 13:14:14 box login[1506]: FAILED LOGIN 1 FROM ttyUSB0 FOR (unknown), User not known to the underlying authentication module

adding 'ttyUSB0' to /etc/securetty removed that error, but did not solve my problem with keys like 'return', 'backspace' (and control-M) not working.
But it makes me wonder how it could possibly have worked yesterday, when I could login (once) without problem ?

I am pretty sure I am very close, but not quite there..

hmmm..

Last edited by nourathar (2014-02-23 12:34:31)

nourathar · 2014-02-23 13:41:21

it works predictably now, but the logic I found baffles me:

if I type my login name (5 characters), pressing 'line feed' will produce a 'q' on the screen, return and enter don't work, so I can't login.

if I type only two characters of my login name, 'line feed' works, I get a login error, but afterwards I can login normally and everything works.

So presumable there is some kind of learning / finding out / handshaking between terminal and Linux box going on, and the linux box needs to receive a 'line feed' quickly in order to be able to recognize it ? Very strange, and I'd rather avoid this strange workaround..

and again I see what I think are colour codes. For instance the output of 'archey' shows '1;34m' at the beginning of the first lines that are darker blue on a Linux console, and '0m' before white text. 'ls' does that too, but for instance 'greed' works fine.

but $TERM is correct:

$ echo $TERM
vt52

so now I wonder:
- what is this 'line feed' business all about and how can I avoid it ?
- how I can tell my linux box that my video terminal is black and white (or is this dependent on how aware each programme is of the terminal properties ?)

Last edited by nourathar (2014-02-23 15:51:44)

ewaller · 2014-02-23 16:26:05

As to the colors after logging in, do you have a fancy prompt?

ewaller@odin ~ 1006 %echo $PS1       
%F{cyan}%n%F{white}@%F{cyan}%m %F{white}%~ %F{red}%B%(?..[%?])%b%F{yellow}%h%F{white} %#
ewaller@odin ~ 1007 %export PS1="$"
$

I'll ponder the other questions.

nourathar · 2014-02-23 23:40:51

ewaller wrote:

As to the colors after logging in, do you have a fancy prompt?

no I don't use one.
The colour code thing happens with some commands and not others, so that makes me think perhaps some commands are more aware of the possibillity of black-and-white consoles than others ? On my Linux box console 'greed' is in color, but it looks fine on my video terminal, no color codes.

Last edited by nourathar (2014-02-24 12:30:07)

Arch Linux

#1 2014-02-21 16:33:36

how connect dumb terminal over USB ?

#2 2014-02-21 17:22:41

Re: how connect dumb terminal over USB ?

#3 2014-02-21 22:40:52

Re: how connect dumb terminal over USB ?

#4 2014-02-21 22:54:59

Re: how connect dumb terminal over USB ?

#5 2014-02-22 10:32:48

Re: how connect dumb terminal over USB ?

#6 2014-02-22 10:48:10

Re: how connect dumb terminal over USB ?

#7 2014-02-22 15:47:56

Re: how connect dumb terminal over USB ?

#8 2014-02-22 17:10:39

Re: how connect dumb terminal over USB ?

#9 2014-02-22 17:12:51

Re: how connect dumb terminal over USB ?

#10 2014-02-22 18:28:47

Re: how connect dumb terminal over USB ?

#11 2014-02-22 19:10:22

Re: how connect dumb terminal over USB ?

#12 2014-02-22 19:25:09

Re: how connect dumb terminal over USB ?

#13 2014-02-23 11:58:09

Re: how connect dumb terminal over USB ?

#14 2014-02-23 13:41:21

Re: how connect dumb terminal over USB ?

#15 2014-02-23 16:26:05

Re: how connect dumb terminal over USB ?

#16 2014-02-23 23:40:51

Re: how connect dumb terminal over USB ?

Board footer