VNC Shifty Keyboard Problems

I've described, in a previous post, the way I use x11vnc, vncviewer and ssh, to access the graphical desktop on my home PC from work. I have a rather similar setup for accessing my work PC desktop from home. But I rarely use VNC to access my own computers - I usually only need VNC to troubleshoot problems on my wife's Window$ PC. The combination of ssh, screen, and emacs -nw is usually sufficient for most of my own remote access needs.

So I haven't used VNC for a while, which is why I haven't noticed a major problem: the SHIFT key doesn't work. Well, actually it does work, but some keys cannot be SHIFTed - e.g. the combination of SHIFT and the slash (/) key, on my keyboard, should yield a question mark (?), but I get the slash instead.

I first hit the problem at work, upon accessing my home machine, but I didn't have time to delve into this so I let it go. I was rather surprised to be hit by the same problem that same night, but this time while trying to access my work PC from home.

I used xev on the remote machine to spy on the keyboard events that are sent to the X server by the remote VNC server, in response to keyboard events sent to it by the local VNC client. Oddly enough, when I hit slash with the SHIFT key pressed, xev printed out the expected question mark. This meant that the local keyboard events reached the other side unharmed.

I suspected that the problem is with the specific VNC viewer that I'm using (RealVNC), so I searched the Net for any SHIFT related problem that RealVNC users may have already reported. No luck - as far as I could tell, no one has reported or complained about the exact same problem that I had.

When I got back to work the next day I tried accessing my home PC with the TightVNC VNC viewer, and hit the same problem. OK, this meant one thing: the problem is with the VNC servers (I used x11vnc on both sides). I scanned the x11vnc manual page for any clue, and found out that it has quite a few command line options to handle all sorts of keyboard related problems and features. It looked rather hopeless. And then I found the flag -debug_keyboard, so I modified the x11vnc command line to look like this:

x11vnc -debug_keyboard -ncache 0 --forever -localhost -display :0 -rfbauth .vnc/passwd &

restarted the VNC server, connected again and typed a few question marks. I read the log messages in the remote ~/.xsession-errors, but it all seemed to be correct - i.e. the server got both the SHIFT and the slash, and logged a question mark key being pressed.

At this point I had no choice but to guess a combination of command line options that might fix my problem. Luckily, my first attempt paid off:

x11vnc -xkb -ncache 0 --forever -localhost -display :0 -rfbauth .vnc/passwd &

I can happily join the other monkeys now.

[08 Mar 2009] UPDATE: Karl J. Runge, the author of x11vnc, was kind enough to contact me directly in order to debug this issue. Thanks!

He directed me to add -dk -dk -o logfile to the x11vnc command line, both with and without -xkb.

It turns out that the real culprit is the gnome-settings-daemon which is also launched from ~/.xprofile. If it's not running x11vnc works like a charm. This must be a recent regression in gnome-settings-daemon.

Mr. Runge concluded that I'll have to stick with the -xkb command line option. Which is fine by me. It works.

From Lenny To Squeeze

[07 Feb 2011] UPDATE: this is an old post about upgrading Debian/testing. If you're considering upgrading Debian/stable, please read the official upgrade instructions.

Debian "lenny" is now officially Debian/stable and the codename for the new Debian/testing is "squeeze". I've long since modified /etc/apt/sources.list to refer to testing instead of lenny, so all I had to do in order to upgrade was wait for Debian/unstable to become Debian/testing. This was quite noticeable: I suddenly got, after running

aptitude update

that there are over 300 packages to upgrade!

I switched to a text console with CTRL-ALT-F1, logged in as root and typed

aptitude full-upgrade

The upgrade itself went smoothly, with no problems at all. I rebooted the machine and it came up just fine. A piece of cake.

My other Debian system is a live HDD (doesn't this sound like a bumper sticker?). I've been using it for the past year and half, as a laptop alternative. I've neglected to upgrade it for quite a while, so I was a bit reluctant to switch it to Squeeze. But I decided to do it anyway, as soon as I found a few free hours (you know - those hours when most people sleep).

I ran aptitude update, and I then hit the first problem: aptitude didn't recognize the full-upgrade command. The version of aptitude that was installed on my live HDD was simply too old.

I could've used apt-get dist-upgrade, but I've learned to like aptitude's dependency conflict resolution (it's powerful enough to solve Sudoku puzzles!). So I first upgraded aptitude itself, and only then launched the full upgrade. Which, surprisingly enough, just worked.

Free time...

I'm seriously considering going to sleep.

Z Z Z Z Z

Detect Which Process is Using Which Port

On my previous post I documented the way I access the desktop on my home PC or my wife's laptop, using VNC and ssh.

Sometimes the connection is cut for some reason, and may leave behind an ssh process hogging a forwarded port, preventing me from connecting again. The solution is simple - kill that process.

But in order to kill the rogue process I need to find its process id. Now how do I do that? Easy - by using netstat to look up which process is listening to one of the forwarded ports:

netstat -lnpA inet | grep -e 590.

VNC Tunnel over SSH

I have a VNC server running on both my wife's PC (TightVNC) and my own (x11vnc), allowing me remote access to each computer's desktop.

For security reasons, access to the VNC port (5900) from the outside world is blocked by the firewall on both machines. This may seem weird - after all, this prevents connections from the outside world...

Well, the missing ingredient is that in order to access the VNC server, I first connect to the PC in question with ssh, and tunnel VNC traffic over the secure connection, like this:

ssh -L 5901:localhost:5900 user@home.example.com

This way I have the SSH client on my side forward incoming connections from the local port 5901 to the remote port 5900 on my home PC, via the remote SSH daemon. As far as the VNC server at home is concerned, the incoming connection originated locally. So I can now connect to my home PC like this:

vncviewer localhost:1

The number after the colon is calculated by subtracting 5900 from the local port being forwarded (5901 in our case).

My wife's PC is trickier to access. To start with, the VNC server on my wife's machine is configured to allow connection from localhost only. Second, it's not directly connected to the Internet. My own PC is connected to the Internet over a cable modem, and my wife's PC is connected to my PC, which routes its incoming and outgoing network traffic using Network Address Translation. I'm no expert here - I implemented this by using one of the example configurations that come with the firewall that I've installed on my PC (shorewall).

I have an ssh daemon running on my wife's PC, courtesy of Cygwin, so that I connect to it like this:

ssh -t -L 5902:localhost:5902 user@home.example.com ssh -L 5902:localhost:5900 user@10.0.0.2

where 10.0.0.2 is the local IP address that's allocated to my wife's PC. Note that port 5902 is forwarded twice - once from the local machine to my home PC, and then from my home PC to my wife's laptop. I can then connect to the VNC server running there:

vncviewer localhost:2

What I don't like about this setup is the two steps involved: I first need to establish a secure shell connection, and only then run the VNC viewer application. After a while it becomes tedious. Here's how I really connect to my home PC:

ssh -t -C -L 5901:localhost:5900 -R 40022:localhost:22 user@home.example.com \
ssh -t -p 40022 127.0.0.1 vncviewer -display :0 -FullScreen  -LowColourLevel 2 \
-PreferredEncoding ZRLE localhost:1

where I ssh back to my local machine at work by reverse forwarding of port 22 (my workstation is behind a firewall), and launch the VNC viewer (RealVNC). I also use compression on both the secure connection (-C) and the VNC client command line, in order to speed up the link.

I use a similar method to connect to my wife's PC, but with a few more forwarding hops.