Some programs "hang" when running on a serial TTY

H

hjf

I recently connected an ADDS 1010 terminal via an USB to Serial port adapter to my FreeBSD server. After several days of tinkering with the termcap, I actually found a working one in Terminfo. Long story here, but probably not important for this.

The problem I'm having is that some programs hang, or act weirdly when run on a serial tty.

sudo: doesn't sudo. it just hangs. ctrl-C will make it print its help, and drop me back into the shell
less, more: these don't work at all. Ctrl-C drops me back into the shell

when I'm inside GNU Screen, however, sudo, less, more work just fine. vi, nano, irssi work great too.

But, when I use Ctrl-a x, which should lock the screen and ask for a password, it'll hang and become completely unresponsive. it'll echo back characters, but it won't do much more.
All of these programs work fine on SSH sessions. I haven't tried on the system's console though as that server is headless.

The /etc/ttys line relevant to this terminal:

cuaU3 "/usr/libexec/getty std.19200" myvp3a+ on secure

myvp3a+ is my custom profile (it's a customized version of vp3a+). changing it to vt100 breaks most ncurses programs, but sudo still fails.
 
Hmm, could it be a flow control problem? Someone sends control S, and that blocks the other side until it received control Q, which might be baked into some "terminal reset" control sequence? Or could it be that the terminal asserts some of the hardware flow control lines (CTS, RTS, DCD, DSR and all these things I had hoped to forget about) when getting certain control sequences?

Suggestion: Turn ALL flow control off (both hardware and software). Connect the terminal with just 3 wires (ground, TX, RX). Make sure your termcap/terminfo description doesn't use Control-S and Control-Q,

And the really nasty suggestion: Try to find a serial protocol analyzer, so you can see what characters are actually being sent. They used to exist when people used serial ports for industrial purposes. The last ones I've seen were simply a bit of software running on a stock PC with two serial ports, using the RX pins on both serial ports to sniff on the traffic coming by.
 
ralphbsz said:
Hmm, could it be a flow control problem? Someone sends control S, and that blocks the other side until it received control Q, which might be baked into some "terminal reset" control sequence? Or could it be that the terminal asserts some of the hardware flow control lines (CTS, RTS, DCD, DSR and all these things I had hoped to forget about) when getting certain control sequences?

Suggestion: Turn ALL flow control off (both hardware and software). Connect the terminal with just 3 wires (ground, TX, RX). Make sure your termcap/terminfo description doesn't use Control-S and Control-Q,

And the really nasty suggestion: Try to find a serial protocol analyzer, so you can see what characters are actually being sent. They used to exist when people used serial ports for industrial purposes. The last ones I've seen were simply a bit of software running on a stock PC with two serial ports, using the RX pins on both serial ports to sniff on the traffic coming by.
Click to expand...
I'm already using a 3-wire cable. flow control is off in the terminal's menu, and i also ran stty -ixon -ixoff -ixany
no change in behavior
 
Generally what you find is Modems use /dev/cua and everything else uses /dev/tty.

In my experience Cellular Modems are the only thing that use the /dev/cua interfaces. U3G devices.

u3g

man.freebsd.org man.freebsd.org

I never really understood this:
Code: 
       /dev/ttyU*.*      for callin ports
       /dev/ttyU*.*.init
       /dev/ttyU*.*.lock  corresponding     callin     initial-state    and lock-state
              devices

       /dev/cuaU*.*      for callout ports
       /dev/cuaU*.*.init
       /dev/cuaU*.*.lock  corresponding    callout    initial-state  and  lock-state
              devices

All cellular modems use /dev/cua for data so "callin ports" and "callout ports" terminolgy is not fitting.
I think its a leftover from the old telephone modem terminology where you would have callin's and callouts.
 
yes!!! that was it!
i could have sworn there was no ttyU device and that's why I used cuaU. oh well.

thanks everyone!!
 
You must log in or register to reply here.
Back
Top