Sunday, October 26, 2008

How to figure out Linux Devices and Drivers

These are the steps to know if our devices have drivers installed and what they are.

$ less /proc/devices

Character devices:
1 mem
2 pty
3 ttyp
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
6 lp
7 vcs
10 misc
13 input
14 sound
21 sg
29 fb
81 video4linux
116 alsa
128 ptm
136 pts
180 usb
189 usb_device
195 nvidia
253 usb_endpoint
254 rtc

Block devices:
1 ramdisk
2 fd
3 ide0
7 loop
8 sd
9 md
22 ide1
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
253 device-mapper
254 mdp

For example, to see what devices the video4linux driver has:

ls -artl /dev | grep 81
crw-rw---- 1 root root 253, 1 2008-10-26 17:17 usbdev1.1_ep81
crw-rw---- 1 root video 81, 1 2008-10-26 17:17 vbi0
crw-rw---- 1 root video 81, 0 2008-10-26 17:17 video0

To see what devices my NVidia driver has:

ls -artl /dev | grep 195
crw-rw---- 1 root video 195, 255 2008-10-26 17:18 nvidiactl
crw-rw---- 1 root video 195, 0 2008-10-26 17:18 nvidia

The major version is the one that we're interested. It's the first number showed when we do 'ls /dev' as well as the numbers showed in /proc/devices

Monday, October 6, 2008

Some useful socat commands

To link serial port ttyS0 to another serial port:

socat /dev/ttyS0,raw,echo=0,crnl /dev/ttyS1,raw,echo=0,crnl

To get time from time server:

socat -

To forward local http port to remote http port:

socat TCP-LISTEN:80,fork

To forward terminal to the serial port COM1:

socat READLINE,history=$HOME/.cmd_history /dev/ttyS0,raw,echo=0,crnl

Simple file-transfer:

On the server-side: socat TCP-LISTEN:port filename
To send file fro the server: socat TCP:hostname:port filename

socat -

Transfers data between STDIO (-) and a TCP4 connection to port 80 of host This example results in an interactive connection similar to telnet or netcat. The stdin terminal parameters are not changed, so you may close the relay with ^D or abort it with ^C.

socat -d -d READLINE,history=$HOME/.http_history \,crnl

This is similar to the previous example, but you can edit the current line in a bash like manner (READLINE) and use the history file .http_history; socat prints messages about progress (-d -d). The port is specified by service name (www), and correct network line termination characters (crnl) instead of NL are used.

socat TCP4-LISTEN:www

Installs a simple TCP port forwarder. With TCP4-LISTEN it listens on local port "www" until a connection comes in, accepts it, then connects to the remote host (TCP4) and starts data transfer. It will not accept a second connection.

socat -d -d -lmlocal2 \
TCP4-LISTEN:80,bind=myaddr1,su=nobody,fork,range=,reuseaddr \,bind=myaddr2

TCP port forwarder, each side bound to another local IP address (bind). This example handles an almost arbitrary number of parallel or consecutive connections by forking a new process after each accept(). It provides a little security by sudoing to user nobody after forking; it only permits connections from the private 10 network (range); due to reuseaddr, it allows immediate restart after master processes termination, even if some child sockets are not completely shut down. With -lmlocal2, socat logs to stderr until successfully reaching the accept loop. Further logging is directed to syslog with facility local2.

socat TCP4-LISTEN:5555,fork,tcpwrap=script \

A simple server that accepts connections (TCP4-LISTEN) and forks a new child process for each connection; every child acts as single relay. The client must match the rules for daemon process name "script" in /etc/hosts.allow and /etc/hosts.deny, otherwise it is refused access (see "man 5 hosts_access"). For EXECuting the program, the child process chroots to /home/sandbox, sus to user sandbox, and then starts the program /home/sandbox/bin/myscript. Socat and myscript communicate via a pseudo tty (pty); myscripts stderr is redirected to stdout, so its error messages are transferred via socat to the connected client.

socat EXEC:"",fdin=3,fdout=4 \,crnl,,mss=512 is a shell script, distributed with socat, that implements a simple SMTP client. It is programmed to "speak" SMTP on its FDs 3 (in) and 4 (out). The fdin and fdout options tell socat to use these FDs for communication with the program. Because inherits stdin and stdout while socat does not use them, the script can read a mail body from stdin. Socat makes alias1 your local source address (bind), cares for correct network line termination (crnl) and sends at most 512 data bytes per packet (mss).

socat - /dev/ttyS0,raw,echo=0,crnl

Opens an interactive connection via the serial line, e.g. for talking with a modem. raw and echo set ttyS0's terminal parameters to practicable values, crnl converts to correct newline characters. Consider using READLINE instead of `-'.

socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork \,socksuser=nobody,sourceport=20

With UNIX-LISTEN, socat opens a listening UNIX domain socket /tmp/.X11-unix/X1. This path corresponds to local XWindow display :1 on your machine, so XWindow client connections to DISPLAY=:1 are accepted. Socat then speaks with the SOCKS4 server that might permit sourceport 20 based connections due to an FTP related weakness in its static IP filters. Socat pretends to be invoked by socksuser nobody, and requests to be connected to loopback port 6000 (only weak sockd configurations will allow this). So we get a connection to the victims XWindow server and, if it does not require MIT cookies or Kerberos authentication, we can start work. Please note that there can only be one connection at a time, because TCP can establish only one session with a given set of addresses and ports.

socat -u /tmp/readdata,seek-end=0,ignoreeof -

This is an example for unidirectional data transfer (-u). Socat transfers data from file /tmp/readdata (implicit address GOPEN), starting at its current end (seek-end=0 lets socat start reading at current end of file; use seek=0 or no seek option to first read the existing data) in a "tail -f" like mode (ignoreeof). The "file" might also be a listening UNIX domain socket (do not use a seek option then).

(sleep 5; echo PASSWORD; sleep 5; echo ls; sleep 1) |
socat - EXEC:'ssh -l user server',pty,setsid,ctty

EXECutes an ssh session to server. Uses a pty for communication between socat and ssh, makes it ssh's controlling tty (ctty), and makes this pty the owner of a new process group (setsid), so ssh accepts the password from socat.

socat -u TCP4-LISTEN:3334,reuseaddr,fork \

Implements a simple network based message collector. For each client connecting to port 3334, a new child process is generated (option fork). All data sent by the clients are appended to the file /tmp/in.log. If the file does not exist, socat creats it. Option reuseaddr allows immediate restart of the server process.

socat READLINE,noecho='[Pp]assword:' EXEC:'ftp',pty,setsid,ctty

Wraps a command line history (READLINE) around the EXECuted ftp client utility. This allows editing and reuse of FTP commands for relatively comfortable browsing through the ftp directory hierarchy. The password is echoed! pty is required to have ftp issue a prompt. Nevertheless, there may occur some confusion with the password and FTP prompts.

socat PTY,link=$HOME/dev/vmodem0,raw,echo=0,waitslave exec:'

Generates a pseudo terminal device (PTY) on the client that can be reached under the symbolic link $HOME/dev/vmodem0. An application that expects a serial line or modem can be configured to use $HOME/dev/vmodem0; its traffic will be directed to a modemserver via ssh where another socat instance links it with /dev/ttyS0.

socat TCP4-LISTEN:2022,reuseaddr,fork \,proxyport=3128,proxyauth=user:pass

starts a forwarder that accepts connections on port 2022, and directs them through the proxy daemon listening on port 3128 (proxyport) on host proxy, using the CONNECT method, where they are authenticated as "user" with "pass" (proxyauth). The proxy should establish connections to host on port 22 then.

echo |socat -u - file:/tmp/bigfile,create,largefile,seek=100000000000

creates a 100GB sparse file; this requires a file system type that supports this (ext2, ext3, reiserfs, jfs; not minix, vfat). The operation of writing 1 byte might take long (reiserfs: some minutes; ext2: "no" time), and the resulting file can consume some disk space with just its inodes (reiserfs: 2MB; ext2:16KB).

socat tcp-l:7777,reuseaddr,fork system:filan -i 0 -s >&2,nofork

listens for incoming TCP connections on port 7777. For each accepted connection, invokes a shell. This shell has its stdin and stdout directly connected to the TCP socket (nofork). The shell starts filan and lets it print the socket addresses to stderr (your terminal window).

echo -e

functions as primitive binary editor: it writes the 4 bytes 000 014 000 000 to the executable /usr/bin/squid at offset 0x00074420 (this is a real world patch to make the squid executable from Cygwin run under Windows, actual per May 2004).

socat -,readbytes=1000

connect to an unknown service and prevent being flooded.

Piped Serial Port on VirtualBox

There is another very cool feature on Linux and VirtualBox which might solve compatibilities of old softwares that require serial connections. It's the host pipe serial-port. On VirtualBox, enable Serial port and select "Host Pipe", check "Create Pipe" and in "port path" textbox, type /tmp/com1_sock.

When my Windows XP is runnning, it recognizes the COM1 and is able to communicate. The byte-streams are actually piped to /tmp/com1_sock (if we don't do anything, it just acts as a dummy). If we want to forward it as a listening port (e.g, as a tcp server so remote systems are able to communicate with the COM1 via TCP/IP), on Linux host's shell type: socat UNIX-CONNECT:/tmp/com1_socket TCP-LISTEN:. We can pick any available tcp port, for example 8040.

Here's the example:

socat UNIX-CONNECT:/tmp/com1_socket TCP-LISTEN:8040

From another terminal (either local machine or remote machine) we can telnet to this port. For example, from our own Linux host, we can communicate to the Hyperterminal running under Windows-XP guest via this virtual serial port by telnetting to the port:

telnet localhost:8040

Voila! Our Linux machine will display anything we type on Hyperminal. This opens up a lot of experiments for us.

Sunday, October 5, 2008

Using Host-Interfacing and Bridging on VirtualBox

NAT interface on guest OS gives limitation so we may need to add a new virtual interface to it. This is called 'HIF' (Host Interface).

  1. Install bridge-utils, if not yet installed:
    sudo yast -i bridge-utils

  2. edit /etc/sysconfig/network/ifcfg-br0 and write:

  3. BOOTPROTO='dhcp'

  4. Edit /etc/sysconfig/network/ifcfg-eth0 and change the content to:

  5. Create a new permanent interface:
    VBoxAddIF tap0  br0

  6. Configure the guest to have the second Virtual Network Interace and assign 'tap0' as its name

Friday, October 3, 2008

My BlackJack is dead!

Today my 3-months-old Samsung Blackjack II has died for no reason. I've charged the battery for hours but still no luck to turn it on. No sign of life on the cute gadget. Darn, seems I have to bring it to closest store for fix.

Using Xwindow client-server

Before starting, make sure both client and server (remote machine) have port 6000 open for Xserver (on SuSE, file /etc/sysconfig/displaymanager should contain DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes"). Once you have changed it, restart Xwindow (or refresh it by pressing CTL-SHFT-BKSPACE).

  1. From local shell, type "xhost +". This will allow this client to connect to all hosts
  2. ssh to remote machine as: "ssh -Y -o ForwardX11Trusted=yes ". If after following steps it does not work, try "ssh -X -o ForwardX11=yes " (although this is less secure)
  3. Once we're in remote machine, type "xhost +" as well.
  4. if we just want to redirect a single X application, we can pass -display directly to the application. For example, to bring remote xterm window to our local screen, just type "xterm -display address:0", e.g.: xterm -display
  5. If we want to redirect all new X applications to our local screen, modify environment variable DISPLAY. For example: export DISPLAY= and then type any GUI applications.

Thursday, October 2, 2008

Google IMAP Settings

Incoming Mail (IMAP) Server - requires SSL:
Use SSL: Yes
Port: 993
Outgoing Mail (SMTP) Server - requires TLS: (use authentication)
Use Authentication: Yes
Use STARTTLS: Yes (some clients call this SSL)
Port: 465 or 587
Account Name: your full email address (including Google Apps users, please enter
Email Address: your full Gmail email address ( Google Apps users, please enter
Password: your Gmail password