OK, I was doing some debugging with Xorg, and thought I had to use the Magic SysRq key to kill it. But when I had pressed Alt-SysRq-R to give the keyboard control from Xorg back to the kernel, it turned out that I not longer needed to do another SysRq because my Xorg magically worked again… 😉 Unfortunately now, everytime I pressed Alt-F4 to close a window, I found myself on tty4… rather poor. So I needed some way to tell Xorg to grab the keyboard again, and there it is: Just open an xterm and execute
sudo kbd_mode -s
Apparently libdvdread only works with UDF file systems. I tried to point VLC to an ISO 9660 image file, but libdvdread only complained:
$ vlc dvd://foo.iso libdvdread: Using libdvdcss version 1.2.10 for DVD access libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed libdvdread: Can't open file VIDEO_TS.IFO. $ file foo.iso foo.iso: # ISO 9660 CD-ROM filesystem data 'CDROM '
However, after I extracted the image file to a folder, everything went as expected. (OPf course also with an image file containing an UDF file system :-))
I was bored today and started to play around with this Windows Mobile Messaging application (I think it’s called Outlook Mobile or sort of thing), and I found out that I was not able to connect to my IMAP mailbox on my root server, though it worked with my Freemail account. So I wanted to see what makes Outlook Mobile bother about my IMAP server.
If you are familiar with Linux (which I suppose you are ;-)), you certainly know netcat. With this little tool, you can talk directly to servers on a byte-oriented basis, and this can be very useful if you have to debug programs which use character-oriented protocols like IMAP, SMTP, IRC and so on.
But I’ve realised that I can not only use netcat to talk to a server myself, but even to build a transparent proxy server that displays all the data that comes over it. After a while — okay, it was about 2 hours — I got the following nice command:
$ mkfifo pipe
$ tty=`tty`; netcat -l 1234 < pipe | tee $tty | netcat myserver.com 143 | tee pipe
I could now set up Outlook Mobile to talk to port 1234 on my home computer and the bytes went straight to my console and also to port 143 (the IMAP port) on my server.
The first direction was straightforward: the first netcat process listens to the local port and pipes its output first to the console (using tee) and then to a second netcat instance that does the communication with the remote server. Now, the commands from the server have to get back to the client, so I created a named pipe using mkfifo (of course, your filesystem has to support it, so you better not do this on FAT) and used this as the input to the first netcat process that sends it back to the original client.
Of course, I could have used Wireshark, but I hate that it does not allow to copy&paste the contents of a packet so I have only the bytes of the protocol that I need — which can be quite useful if you want to reuse parts of the content, especially in character-oriented protocols. Also, the filter settings in Wireshark can be annoying, there is no simple way to only have packets from one network connection (or I haven’t found it yet).
So, finally I found out that is has something to do with the IMAP capabilities that Outlook Mobile bothers about. I suppose I will write something about it if I have traced the problem back.
Update: Note: You can also rewrite the server and/or client messages using sed, but be sure to use unbuffered output with -u like that: