Input problem over ssh

[dbbolton]

I have a Debian system and a FreeBSD system. From the Debian system, I am connecting to the FreeBSD system via SSH. When I attempt to navigate a menu (such as the options brought up by make), my non-printing keys (arrows, pageup/down) do not work: http://i.imgur.com/5DQ5hE1.png. As you can see, the keys are printing sequences to the screen instead.

I have tried different users, terms (xterm and urxvt), and shells (bash and zsh) on the client, and different shells on the server (sh and zsh), always with the same result.

This does not happen when I am physically on the FreeBSD machine.

 

[ShelLuser]

I have a Debian system and a FreeBSD system. From the Debian system, I am connecting to the FreeBSD system via SSH.

How exactly are you connected to the Debian system? I assume directly on the console, but considering that a remote X session (X forwarding using SSH for example) is also commonly used I don't want to make assumptions.

I have tried different users, terms (xterm and urxvt), and shells (bash and zsh) on the client, and different shells on the server (sh and zsh), always with the same result.

That doesn't really tell us much. Can I assume that you tried all efforts from within the X environment and always opened a graphical console from which you used the commandline SSH program?

Because then I'm also interested to know what happens if you simply pick one of the TTY's (main console, from the X screen press control-alt-f1 for example), logon, and start an SSH session from there.

Your screenshot also looks somewhat odd to me. How exactly did you come up with the config screen? Because if you'd have used # make config it would not have mentioned something about cleaning sudo. Therefore I assume you're using a program like portmaster, is that correct?

If so: what happens if you merely use # make config and nothing else?

 

[dbbolton]

On the Debian system, which I am physically using, I tried both the Linux console (i.e. tty0) and the terms mentioned. I simply ran the command ssh user@IP to connect to the FreeBSD machine, which is not running X at all.

As for the configuration screen, I had just run make install clean from the directory.

I'm now sure that the problem is not related to make though. I noticed that mouse wheel movements also print to the command line: http://i.imgur.com/hr55NBk.png

It seems that it will print a different string depending on where the cursor is when the wheel is moved, up or down. That commandline in the screenshot is zsh running on the BSD machine. The terminal is gnome-terminal running on the Debian machine.

Also, after closing the connection with the BSD machine, those weird mouse characters will continue appearing until that term is closed, but it does not happen in a term if no connection with the BSD machine is established.

 

[SirDice]

The problem is probably TERM related. These can be quite inconsistent between different operating systems. After logging on on the FreeBSD host from Debian try setting TERM to xterm, see if that helps. Also try setting the TERM variable to xterm before connecting to the FreeBSD host.

 

[dbbolton]

It seems they are both already set to xterm.

[CMD=user@debian >]echo $TERM[/CMD]                                                               
xterm
[CMD=user@debian >]ssh user@freebsd[/CMD]

# snip

[CMD=user@freebsd >]echo $TERM[/CMD]                                                               
xterm

I've also noticed that the Home, End, and Page keys don't seem to work from either machine. After typing a command string and pressing Home, this happens:

[CMD=user@freebsd >]H{cursor[/CMD] position}                                                                      
some command string

Pressing it repeatedly:

[CMD=user@freebsd >]H{cursor postion}[/CMD]                                                                      
H
H
some command string

So it appears the key is moving the cursor to the beginning of the line, but also inserting "H\n".

Could this have something to do with the fact that I'm using an Apple keyboard on the host machine? When I was installing, I didn't see any special option for Apple keyboards. Anyway, that wouldn't explain the anomalies with the regular IBM keyboard on the Debian machine.

Also, I've tried using zkbd to set up the keys on the FreeBSD machine with the zsh line editor: http://zshwiki.org/home/zle/bindkeys?s[]=zkbd

I've never had any problems with this on any terminal emulators, so I believe the problem is specific to the FreeBSD console.

 

[ShelLuser]

I've never had any problems with this on any terminal emulators, so I believe the problem is specific to the FreeBSD console.

Solely based on my own experiences I'm positive that it isn't (but of course I could be wrong). The thing is: I've experienced too many issues with terminal emulation on Linux in the past. From a complete difference in behaviour between a CentOS 5.x and 6.x environment (all hosted by the the same hosting provider, but both also pre-installed by that provider) but also even earlier than that when I was still more active on IRC using irssi. UTF8 used to heavily disrupt my sessions while it worked perfectly for others. Both out of the box Debian environments (where terminal settings (ncurses I think) were concerned).

Even so; re-reading this topic there's one thing I'm missing: Which version of Debian and which version of FreeBSD are you using?

That might be able to shed some more light on all this.

 

[dbbolton]

I'm positive that it isn't

Ok, then why do the navigation keys still screw up on the host machine? The only other alternative (since I've already ruled out the shell) is the keyboard, so I will try to find another one to test on it.

As for the client, it's a mixed system, with a 3.2 kernel. I can post specific package versions if necessary, but remember I had the same experience when connecting straight from the Linux console.

Also, I have some more astonishing news:

http://i.imgur.com/eoWLc6V.png

This time the arrow keys worked as expected in the make menu. In another post, I discovered that some important system files (endian.h and float.h) had become corrupted and replaced them.

Could this have something to do with it?

 

[wblock@]

Ok, then why do the navigation keys still screw up on the host machine?

Because VT100 or ANSI terminal emulation is a very involved state machine, and some escape sequence changed the state.