Free serial over ip software for linux

Shell over ICMP consists of two free and open source applications: one server and one client. Shell over ICMP project allows a user to connect to a remote shell daemon, by using ICMP protocol instead of classical TCP.
Entirely written in Python, soicmp is a working proof-of-concept to demonstrate that data can be transmitted across a network by hiding it in traffic that normally does not contain payloads.
How does it work?
The soicmp server is a daemon that must be started on the remote server. When the server receives a request from the client it looks into the packets payload. The payload must respect certain protocol rules. In detail the client must specify:
command
communication mode (echo|echo/reply)
authentication (y|n)
This is an example of a correct payload string sent by client to server:
$CMD ls -a $MODE echo/reply $PWD root2005 $END
If the payload matches with the server protocol specification then it will pipe the command to "/bin/sh" or "cmd.exe" and execute it. The server then reads the result from the pipe and sends it back to the client that will print it to stdout.
Moreover every client will send ICMP packets having id equal to the clients current process ID and will accept only ICMP replies having the same id value. This prevents output to be printed by other client instances running on the same workstation (this argument is also treated in the FAQs section).
Main features:
- Platform independent.
- Possibility to run soicmp daemon on multiple ethernet interfaces simultaneously handling multiple client connections.
- Possibility to specify the buffer size of outgoing packets.
- Client side source IP address spoofing.
- Remote client case-sensitive (plain texted) authentication.
- Possibility to select two communication types:
- One based on encapsulating command output in unique "one way" ICMP_ECHOREPLY (type 0) packets sent by server to client (see fig. 1).
- Another one that guarantees the correct packets delivering by using the request/response nature of ECHO and ECHOREPLY ICMP packet types (see fig.2)
- No listening sockets are listed by netstat or similar programs.

slsnif is a serial line sniffer. It listens to the specified serial port and logs all data coming through it. slsnif works transparently for both the device connected to the serial port and the controlling software for this device. It operates by opening a pseudo tty (pty) and linking it to the actual serial port.
slsnif operates by opening a pty and linking it to the serial port. These are following parameters / options:
1. Serial port to open (required).
2. Name of the file to direct output to (optional, defaults to stdout).
3. Desired baudrate (optional, defaults to 9600 baud).
4. Timestamp On/Off (optional, defaults to Off).
5. Print ascii values in hex On/Off (optional, defaults to Off)
6. Print number of bytes transmitted On/Off (optional, defaults to Off).
7. Optional colors for timestamp, number of bytes transmitted and normal output.
8. Lock port On/Off (optional, defaults to On).
9. Use Unix98 ptys instead of BSD ptys (optional, defaults to BSD style).
10. Second serial port to open. If specified, this port will be used instead of a pty, thus providing an ability to log data between two serial ports.
Enhancements:
- Added ability to resynchronize ports at any time by sending a SIGUSR1 signal to slsnif. Useful for debugging applications that change port parameters mid-way, after starting the transmission. One example is pppd daemon, which sets initial parameters in the chat script, and changes them later, after chat script terminates.
- Added ability to use SYSV (Unix98) ptys instead of BSD ones (see -u and --unix98 parameters). This option can also be turned on/off from rc-file.

GENRIP is a kernel driver (presently for Linux only) that enables you to carry ethernet frames over generic low-speed/low-power serial radios, such as Microhards MHX series radios. It is intended to speed up the development cycle for those creating low-powered Embedded telemetry and SCADA devices, but may have other applications as well. Once installed, the serial radio simply appears as a network interface like this:

[root@lindev]# ./ifconfig gr0
gr0 Link encap:Generic Radio IP HWaddr 00:00:02:04:06:08
inet addr:192.168.15.1 Mask:255.255.255.0
UP RUNNING MTU:234 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

GENRIP was originally based upon Stuart Cheshires STRIP driver, which is part of the Mobile Computing Group at Stanford Universitys Mosquitonet project. It has been radically modified since.

GENRIP was ported to this application by Lawrence Wimble of Design On Demand, Inc. Design On Demand, Inc. maintains GENRIP and hopes that youll call them if you need help with an embedded project using GENRIP (or any embedded project for that matter).

GENRIP is released for Linux under the GPL. A port to FreeBSD is planned in the near future.

external IP shows your current external IP in the browsers statusbar.

External IP is set to check your IP address once every hour.

Initial SIMPLE IP Firewall is a script for Linux 2.4.x and iptables.

Sample:

Configuration options

###################################
#
# Local Area Network configuration.
#
# your LANs IP range and localhost IP. /24 means to only use the first 24
# bits of the 32 bit IP adress. the same as netmask 255.255.255.0
#

LAN_IP="192.168.0.2"
LAN_IP_RANGE="192.168.0.0/16"
LAN_BCAST_ADRESS="192.168.255.255"
LAN_IFACE="eth1"

###################################
#
# Localhost Configuration.
#

LO_IFACE="lo"
LO_IP="127.0.0.1"

###################################
#
# Internet Configuration.
#

INET_IP="194.236.50.155"
INET_IFACE="eth0"

###################################
#
# IPTables Configuration.
#

IPTABLES="/usr/sbin/iptables"

Module loading

#
# Needed to initially load modules
#
/sbin/depmod -a

#
# Adds some iptables targets like LOG, REJECT and MASQUARADE.
#
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_tables
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
#/sbin/modprobe ipt_REJECT
#/sbin/modprobe ipt_MASQUERADE

#
# Support for owner matching
#
#/sbin/modprobe ipt_owner

#
# Support for connection tracking of FTP and IRC.
#
#/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_conntrack_irc

IPAC-NG is the iptables/ipchains based IP accounting package for Linux.

It collects, summarizes, and nicely displays IP accounting data. Its output can be a simple ASCII table, or graph images. Ipchains and iptables are supported. Logs are stored in files, gdbm, or PostgreSQL database.

ipac consists of one perl script and one C program:

- fetchipac, executed from cron once in a while, reads the current ip accounting data assembled by the kernel and stores it into a database

- ipacsum summarizes the data from a set of records from the database and, optionally,
replaces these records by one. It displays the values as a simple table containing the sums, as png graph pictures or as ascii graph pictures.

COMSERV is a program that allows you to talk to a network terminal server such as a Xyplex MAXserver 1600.
The handy thing about this program is that the client side of the connection does not need to know anything about how to talk to the terminal server. COMSERV handles the connection details. Thus, you can use existing programs like tip to talk to devices attached to your network terminal server without any modification.
Also, you can use COMSERV to turn your Unix computer itself into a terminal server and serve up its own local serial ports over the network for remote systems to access. This is handy if you have several systems lying around and you want to utilize devices attached to their serial ports.
My primary motivation for writing this program was to expand the I/O capabilities of my FreeBSD home computer. I have many serial devices that I want to connect to my PC which include my modem, Palm Pilot, GPS, various micro-controllers, my EEPROM programmer, and other computers and printers. But with only two serial ports on my PC, I became annoyed at having to reach around the back of my computer and swap cables every time I wanted to plug in a different device. [I think all inventions are the product of the laziness of the inventor :-)] So I searched eBay and found a couple of these Xyplex terminal servers that looked promising, I bid on them, got them, and began hacking.
The only problem with using this type of device for serial expansion, is that if you use a program like tip on Unix (tip is a very basic but functional program to connect directly to a serial port), it expects to be able to open the serial port by opening a /dev/xyz device file that corresponds to a real serial device. The Xyplex, on the other hand, communicates to the Unix system via an ethernet network. In order to talk to one of the serial ports on the Xyplex, you need to establish a TCP/IP connection between your Unix computer and the Xyplex device at a particular TCP port. The TCP port you connect to determines which Xyplex serial port you connect to. For the Xyplex 1600, serial port 1 is TCP port 2100, serial port 2, is TCP port 2200 and so on.
Unfortuneately, tip, and programs like it, have no idea how to establish a TCP/IP connection to the Xyplex in order to transfer data to and from a serial device connected to the Xyplex.
This is what COMSERV does. COMSERV creates a set of pseudo-tty device files that are palatable to tip and other programs. COMSERV opens the master side of the pseudo terminal and the client program (tip in this case) opens the slave side. Data written on the slave endpoint comes out on the master endpoint and vice-versa. This mechanism establishes a connection between the client program and COMSERV. COMSERV then uses TCP/IP to establish a connection to the network terminal server.
Thus, data originating from the client program is written to the slave tty where is read by COMSERV. COMSERV then writes the data to the network socket to the Xyplex, which then passes it on to the designated serial port. Data originating from the serial device attached to the Xyplex takes the reverse path.
Only one instance of COMSERV is required to be running on your system to handle all of your network terminal servers (it can handle as many terminal servers and ports as the speed and resources of your system allows). COMSERV is designed to handle many connections in this fashion, and does so by multiplexing between them using asynchronous device and socket I/O.
While I wrote COMSERV to talk to a Xyplex MAXserver 1600, it should work with other manufacturers products as long as they follow a similar API. The Xyplex devices that I have are 16 port devices that connect serial devices to an ethernet network.
If COMSERV sounds useful to you, feel free to download and use it. The program is provided in source form, so you will need to extract it and compile it. If you use FreeBSD, simply do the following:
% cd /usr/ports/comms/comserv
% make install
I use it on FreeBSD 4-STABLE. I dont currently know of any outstanding bugs, but if you find and fix any bugs, please send me your fixes so that others can benefit from them as well.
If you do decide to use COMSERV, please note the accompanying license. In a nutshell, you can use it without restriction as long as you credit me and keep the copyright notice intact. If you happen to like it, feel free to send your thanks, letting me know. If you dont like it, let me know why, perhaps I can improve it. If you improve it, please send me your changes and Ill see about integrating them so that others can benefit from your improvements.
Enhancements:
- Implement a power of 2 backoff and retry for failing connections with a maximum 10 minute wait. This keeps from filling up the logs with failed repeated attempts.