Hardware and Software Prerequisites
Before you can turn a pair of old serial ports into a modern IP link, you need to make sure the physical layer is ready. Two PCs with a working RS‑232 interface are the minimum requirement. The ports should be exposed in the case, or you must have a USB‑to‑serial adapter that presents itself as a ttyS device. RedHat Linux 7.3 was used for the original test, but any Linux distribution that ships with the Serial cables come in a handful of flavours. The one that will work for our purpose is a null‑modem cable, sometimes called a crossover cable. It swaps the transmit and receive lines so that the two machines can talk directly. In addition to the two data wires, you’ll need the handshake lines to be connected if you plan on using the full duplex capabilities of the port; the most common arrangement is a 9‑pin cable with the DTR and RTS lines swapped. If your cable is a straight‑through cable, you may still be able to establish a link by disabling hardware flow control in the serial driver, but the connection will be less reliable, especially at higher speeds. Serial ports are notoriously noisy. Even a short cable can pick up electromagnetic interference from nearby devices, and a poor connector can cause data corruption. If you notice packet loss or frequent connection resets, try a different cable or a shorter length. Lowering the baud rate can also make the link more robust; the example below uses 115200 bits per second, but dropping to 9600 or 19200 is a safe fallback. The Make sure your two PCs are ready to run the commands in the next section. You can test that the serial port is accessible by running In the following sections you’ll see the actual commands needed to bring the two machines online. They will create a new virtual network interface, configure an IP address for each side, and add static routes so the operating system knows how to reach the remote host. The whole operation is performed from a terminal on each machine, so you can execute everything while the system is up and running. With the cable connected and the machines booted, open a root terminal on the first computer. The first command launches the SLIP driver on the chosen serial port. The syntax is Next, configure the network side of the link. Run To make the route explicit, add a static entry: At this point PC 1 is fully configured. Repeat the entire sequence on the second computer, swapping the IP addresses. Run After the configuration is in place, test the connectivity with a simple ping: Because the SLIP interface is created on demand by the Even though the steps above are straightforward, real‑world deployments can hit a few snags. The most common symptoms are packet loss, failed pings, or applications timing out. The first thing to check is the physical layer: confirm that the cable is firmly seated on both ends and that the connectors match the pinouts expected by the serial ports. If you see a series of “connection timed out” messages, try lowering the baud rate. The 115200 setting is aggressive for an RS‑232 line that might be subject to noise; 9600 or 19200 can often recover a flaky link. If the cable is fine, use On the software side, check the status of the SLIP driver with When troubleshooting route problems, use Once you have a working connection, automating the startup process is a logical next step. The most portable approach is to create a small shell script named Finally, remember that SLIP is a very simple protocol that carries IP packets over a serial line. It lacks error detection beyond the underlying serial hardware, so you should not rely on it for high‑throughput or mission‑critical traffic. For situations that require more robust error handling or dynamic routing, consider using PPP (Point‑to‑Point Protocol), which offers built‑in authentication and link management. However, for quick experiments, troubleshooting, or teaching concepts of network layering, a SLIP connection over a null‑modem cable remains a lightweight and effective tool.slattach binary and the net-tools package will perform the same steps. Keep in mind that the kernel must have the SLIP driver compiled; most recent kernels include it by default, but you can check by running lsmod | grep slip after booting. If the module is missing, load it with modprobe slip
slattach command accepts any value supported by the kernel, so you are free to experiment.stty -F /dev/ttyS0 and confirming you get output instead of an error. If you use a USB‑to‑serial adapter, the device will show up as something like /dev/ttyUSB0 and you should replace /dev/ttyS0 in all examples with the proper path. The rest of the procedure is identical, whether you are working with a built‑in COM port or a USB adapter.Step‑by‑Step Configuration of the Serial Link
slattach -p slip -s 115200 /dev/ttyS0 &. The -p flag tells the driver to use the SLIP protocol; the -s flag sets the baud rate, and the trailing ampersand puts the process in the background so you can type other commands. The driver creates a new interface named sl0 and assigns it a state of DOWN until you bring it up later. Because we have two machines, each side will use the same name; the kernel knows which physical link the data arrives on, so there is no conflict.ifconfig sl0 192.168.0.1 pointopoint 192.168.0.2 up. This assigns the IP address to the local side, tells the driver that the remote address is , and brings the interface up. The pointopoint keyword is essential; it tells the kernel that the link has only one peer, which eliminates the need for ARP lookups and lets the routing logic treat it as a direct connection. After this command the kernel knows that any packets destined for should be sent out over sl0
route add -host 192.168.0.2 dev sl0. While the point‑to‑point configuration already implies the host route, this explicit entry makes the path visible in netstat -rn and can help troubleshoot routing problems. The command tells the kernel that traffic to the specific host must go through the sl0 interface. If you prefer, you can replace -host with -net and a subnet mask, but a host route is sufficient for two devices.slattach -p slip -s 115200 /dev/ttyS0 & again, then ifconfig sl0 192.168.0.2 pointopoint 192.168.0.1 up, and finally route add -host 192.168.0.1 dev sl0. Notice that both sides run the same slattach command; only the address assignments differ. Once both machines have completed the steps, the two SLIP interfaces are linked, and the operating systems know how to reach each other.ping 192.168.0.2 from the first machine, and ping 192.168.0.1 from the second. A healthy ping reply confirms that the link is up and that the IP stack is passing packets correctly over the serial line. You can also try telnet 192.168.0.2 23 if you have an SSH or Telnet server listening, or ftp 192.168.0.2 to confirm that larger packets survive the serial transmission. These applications will work as long as the IP link is stable, because the SLIP interface appears to the rest of the system like any other network adapter.slattach command, you must run it each time the system boots. If you want the link to come up automatically, add the three commands to a startup script. One common place is /etc/profile; by appending the lines there, they will run every time a user logs in. For a more robust solution that starts before login, create an init.d script or a systemd service that runs slattach at boot time, checks that the device file exists, and brings the interface up. This ensures the link is ready for applications that run as root or during system startup.Testing, Troubleshooting and Automation
dmesg or journalctl -k to look for kernel messages related to the serial driver. Errors such as “slattach: cannot open /dev/ttyS0” or “slattach: interface sl0 already exists” indicate that the device file is missing or that the interface was not brought down properly in a previous session. You can bring the interface down with ifconfig sl0 down before restarting slattach
cat /proc/net/slip. A properly configured link should show the local and remote IP addresses, the number of transmitted and received packets, and any error counters. A sudden spike in error counts often points to a bad cable or insufficient handshake lines. The slattach command accepts a -d flag that enables debug output, which can be captured by redirecting the command to a log file. For example, slattach -p slip -s 115200 -d /dev/ttyS0 >> /var/log/slip.log 2>&1 & will write debug messages to a file for later inspection.netstat -rn to verify that the host route to the peer exists and that the metric matches the expected value. If you find an unexpected route, delete it with route del -host 192.168.0.2 dev sl0 and recreate it. The routing table is per‑system, so any change you make will affect all traffic destined for that address, including any services that listen on that IP./usr/local/bin/serial‑slip.sh that contains the three commands. Make the script executable with chmod +x /usr/local/bin/serial‑slip.sh. Then add a line to /etc/rc.d/rc.local (or the systemd equivalent) to call the script: /usr/local/bin/serial‑slip.sh. This guarantees that the SLIP interface is available before any networked applications start. If you prefer systemd, a service file with ExecStart=/usr/local/bin/serial‑slip.sh and a WantedBy=multi-user.target line will provide similar behaviour.
No comments yet. Be the first to comment!