Network Commands: Diagnosing Connectivity and Monitoring Traffic

Testing Connectivity: ping and traceroute

Network problems are the most common issues in industrial environments. A sensor stops reporting or a PLC loses communication with the SCADA server. The first step is always testing basic connectivity.

ping -c 4 192.168.1.100             # Send 4 packets
ping -c 3 -W 2 192.168.1.100       # 3 packets, 2-second timeout

Key indicators: packet loss should be 0% on a healthy network. Response time over 10ms on a local industrial network suggests congestion.

traceroute -n 192.168.2.50          # Show every hop, skip DNS lookups
traceroute -T -p 502 192.168.2.50   # TCP trace on Modbus port 502

If the trace stops at a certain hop, you know the problem is at that network device.

Checking Ports and Connections: ss and netstat

ss -tuln                             # All listening TCP and UDP ports
ss -tlnp                             # Listening TCP ports with process names
ss -tn state established            # Active connections
ss -tn sport 502                    # Connections on Modbus port 502

Example output of ss -tlnp shows which services are listening:

LISTEN  0  128  0.0.0.0:22    users:(("sshd",pid=892))
LISTEN  0  128  0.0.0.0:502   users:(("modbus_gw",pid=1542))
LISTEN  0  128  127.0.0.1:8080 users:(("scada_web",pid=2100))

The legacy equivalent netstat -tuln works on older systems where ss is unavailable.

Downloading Data: curl and wget

curl http://192.168.1.100:8080/api/status          # GET request
curl -o firmware.bin http://server/firmware.bin      # Download to file
curl -s http://localhost:8080/health | jq .          # Parse JSON response
curl -X POST -d '{"cmd":"read"}' -H "Content-Type: application/json" \
  http://192.168.1.100:5000/api/sensor              # POST request

curl is essential for querying REST APIs exposed by modern PLCs and IoT gateways.

wget http://server/updates/patch.tar.gz              # Download a file
wget -c http://server/large_file.bin                  # Resume interrupted download

Use curl for API interactions and wget for file downloads with resume support.

Network Configuration: ip addr and ip route

ip addr show                         # All interfaces and IPs
ip addr show eth0                    # Specific interface
ip route show                        # Routing table
ip route get 192.168.2.50           # Which route reaches a specific IP

Temporary changes for testing:

sudo ip addr add 192.168.10.1/24 dev eth1          # Add a temporary IP
sudo ip route add 192.168.20.0/24 via 192.168.1.1  # Add a static route

These are lost on reboot. For permanent configuration, edit /etc/netplan/ (Ubuntu) or /etc/sysconfig/network-scripts/ (RHEL).

nslookup scada-server.factory.local  # DNS lookup
cat /etc/resolv.conf                 # Check DNS configuration

Packet Capture: tcpdump

tcpdump captures raw packets and is essential for debugging protocol-level issues in industrial communications.

sudo tcpdump -i eth0 -c 100                      # Capture 100 packets
sudo tcpdump -i eth0 host 192.168.1.100          # Traffic to/from a host
sudo tcpdump -i eth0 port 502                    # Modbus TCP traffic
sudo tcpdump -i eth0 port 502 -w modbus.pcap     # Save for Wireshark analysis
sudo tcpdump -i eth0 port 8080 -A                # Show HTTP payload

Saved .pcap files can be opened in Wireshark for detailed graphical analysis. The standard workflow: capture on the server, analyze on your workstation.

Practical Example: Diagnosing a Connection Drop Between PLC and SCADA Server

PLC-03 (192.168.1.103) stopped responding 30 minutes ago:

# Step 1: Test connectivity
ping -c 4 192.168.1.103
# 100% packet loss

# Step 2: Can we reach the gateway?
ping -c 2 192.168.1.1
# 0% packet loss — gateway is fine

# Step 3: Trace the route
traceroute -n 192.168.1.103
# Stops at hop 1 — PLC itself is unreachable

# Step 4: Check Modbus connections
ss -tn | grep 192.168.1.103
# No output — no active connections

# Step 5: Verify our Modbus gateway is running
ss -tlnp | grep 502
# LISTEN 0 128 0.0.0.0:502 users:(("modbus_gw",pid=1542))

# Step 6: Capture traffic for analysis
sudo tcpdump -i eth0 host 192.168.1.103 -c 20 -w /tmp/plc03.pcap &

# Step 7: Check service logs
journalctl -u modbus-gateway --since "30 minutes ago" | tail -20

This systematic approach — connectivity, routing, ports, process, capture, logs — isolates the problem layer by layer.

Summary

In this lesson you learned networking tools for industrial Linux systems:

ping and traceroute test connectivity and trace the network path.
ss shows listening ports and active connections; netstat is the legacy equivalent.
curl interacts with HTTP APIs; wget downloads files with resume support.
ip addr and ip route manage interfaces and routing tables.
tcpdump captures raw packets for protocol-level debugging with Wireshark.
Systematic diagnosis follows layers: connectivity, routing, ports, process, capture, logs.

In the next lesson, you will learn about systemd services — how to manage, create, and monitor long-running applications on industrial servers.