Anyone who regularly works with Linux, AIX, or other Unix-based systems is accustomed to running commands such as ping, traceroute, and netstat directly from the shell.

IBM i provides equivalent networking capabilities through native commands and IBM i Services, including:

• PING

• TRACEROUTE

• QSYS2.NETSTAT_INFO

• Other related Db2 for i SQL Services

However, during an SSH session on IBM i, switching between familiar Unix-style shell syntax and IBM i CL command syntax is not always convenient.

To make network troubleshooting from the PASE environment more practical, I created a small, self-contained Python 3 toolkit called ibmi-rqm-nettools.

The toolkit provides three Unix-style commands for IBM i:

• ping

• traceroute

• netstat

The commands are implemented in Python and designed specifically for use from an SSH or PASE shell session on IBM i.

What the Toolkit Provides

The toolkit includes three small and independent commands:

• ping

• traceroute

• netstat

Its main capabilities include:

• Familiar Unix-style command-line options

• Support for specifying the remote host before or after the command options

• Unix-style ping and traceroute output

• Selection of the local IBM i source IP address

• Control over packet size, packet count, timeout, deadline, interval, and TTL

• Structured TCP/IP connection information

• Network interface and routing-table views

• Identification of the IBM i job associated with a network connection, when available

• Free-text filtering by IP address, port, state, user, protocol, or other displayed values

• Column headings that remain visible when filters are applied

• A consistent -Version and --version option across all three commands

• Structured JSON version information suitable for inventory and automation

The ping and traceroute commands are implemented directly in Python using raw ICMP sockets.

The netstat command queries IBM i networking information through Db2 for i SQL Services and db2util, and then parses, filters, and formats the results in Python.

This does not replace the native networking capabilities of IBM i. The toolkit uses functionality already provided by the platform, including raw sockets, the IBM i TCP/IP stack, and Db2 for i SQL Services.

It simply presents those capabilities through a command-line interface that is more familiar to administrators working with Linux, AIX, and other Unix-based systems.

Prerequisites

The toolkit requires the following components.

Python 3

Python 3 must be installed through IBM i Open Source Package Management.

It is normally available at:

/QOpenSys/pkgs/bin/python3

Authority to Open Raw ICMP Sockets

The ping and traceroute commands require sufficient authority to open a raw ICMP socket using:

socket.SOCK_RAW
socket.IPPROTO_ICMP

In practice, this means running the tools under a user profile with sufficient PASE authority.

This is similar to the restriction imposed by Linux and AIX when an unprivileged user attempts to run a raw-socket-based ping command without root authority or an equivalent capability.

db2util

The netstat command requires db2util to be available in PATH.

db2util is used to execute SQL queries against:

• QSYS2.NETSTAT_INFO

• QSYS2.NETSTAT_INTERFACE_INFO

• QSYS2.NETSTAT_ROUTE_INFO

• QSYS2.NETSTAT_JOB_INFO

No additional Python packages are required.

The toolkit uses only modules included in the Python 3 standard library, including:

• argparse

• csv

• json

• select

• socket

• struct

• subprocess

Install the required IBM i open-source packages with:

yum install python3 db2util

The same packages can also be installed through the Open Source Package Management interface in IBM i Access Client Solutions.

Verify that the executables are available:

/QOpenSys/pkgs/bin/python3 --version
/QOpenSys/pkgs/bin/db2util --help

Ensure /QOpenSys/pkgs/bin Is Included in PATH

Before installing the scripts, check the current value of PATH:

echo "$PATH"

The following directory should be included:

/QOpenSys/pkgs/bin

A trailing slash is also valid:

/QOpenSys/pkgs/bin/

You can verify whether the directory is already present without depending on the exact syntax used to define PATH:

case ":$PATH:" in
    *:/QOpenSys/pkgs/bin:*|*:/QOpenSys/pkgs/bin/:*)
        echo "/QOpenSys/pkgs/bin is already in PATH"
        ;;
    *)
        echo "/QOpenSys/pkgs/bin is not in PATH"
        ;;
esac

When the directory is not present, add it temporarily to the current shell session:

export PATH="/QOpenSys/pkgs/bin:$PATH"

To make the change persistent, add the same line to either ~/.profile or ~/.bashrc.

Do not remove or overwrite any other directories already configured in PATH.

For example:

export PATH="/QOpenSys/pkgs/bin:$PATH"

Reload the profile after making the change:

source ~/.profile

Alternatively, when using Bash:

source ~/.bashrc

Installing the Toolkit

The scripts are published, versioned, and documented in the following GitHub repository:

github.com/rqmartins73/ibmi-rqm-nettools

The project is distributed under the MIT License.

The simplest installation method is to clone the repository directly on the IBM i partition:

git clone https://github.com/rqmartins73/ibmi-rqm-nettools.git
cd ibmi-rqm-nettools
chmod +x ping traceroute netstat
cp ping traceroute netstat /QOpenSys/pkgs/bin/

When git is not available, the files can also be downloaded individually using curl or wget and copied into:

/QOpenSys/pkgs/bin

Verify the installed command locations:

which ping
which traceroute
which netstat

Before installing the scripts, it is advisable to check whether commands with the same names already exist elsewhere in PATH:

type -a ping
type -a traceroute
type -a netstat

When /QOpenSys/pkgs/bin appears early in PATH, the scripts installed there take precedence over commands with the same names found later in PATH.

This behaviour is intentional, but it should be understood before installing the toolkit on a shared IBM i system.

1. The ping Command

The ping command builds ICMP Echo Request packets directly in Python.

This includes:

• The ICMP header

• The packet identifier

• The sequence number

• The payload

• The ICMP checksum

The packet is sent through a raw ICMP socket.

Replies are correlated with requests using the process ID and sequence number, following the same general approach used by traditional Unix ping implementations.

Syntax

ping [options] <host>

  -c count       Number of packets to send
                 0 means continuous, which is the default

  -w deadline    Total timeout in seconds
                 Stops the command even if the requested packet count
                 has not yet been reached

  -W timeout     Per-packet reply timeout in seconds
                 Default: 2

  -i interval    Interval between packets in seconds
                 Default: 1

  -s size        ICMP payload size in bytes
                 Default: 56

  -t ttl         IP time-to-live for outgoing packets

  -l address     Local source IP address
                 The socket is bound to this address before sending

  -q             Quiet mode
                 Displays only the final statistics

  -Version
  --version      Display version information as JSON and exit

Examples

Run ping using the default values:

ping 9.9.9.9

Example output:

PING 9.9.9.9: 56 data bytes
64 bytes from 9.9.9.9: icmp_seq=1 ttl=59 time=12.430 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=59 time=11.982 ms

--- 9.9.9.9 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 11.982/12.206/12.430/0.224 ms

Send four packets:

ping -c 4 9.9.9.9

The remote address can also be specified before the options:

ping 9.9.9.9 -c 4

Send larger packets with a two-second per-packet timeout:

ping -s 1400 -c 10 -W 2 9.9.9.9

Force the test to use a specific local IBM i IP address:

ping -l 10.20.5.24 9.9.9.9

Stop the command after a total of five seconds, regardless of the value specified with -c:

ping -w 5 9.9.9.9

The ability to select the local source address is particularly useful on IBM i systems with multiple interfaces, VLANs, or routing paths.

It allows the administrator to verify not only whether a destination responds, but also whether communication succeeds when traffic originates from a specific IBM i IP address.

This can be especially useful when troubleshooting:

• Site-to-site VPN connections

• Multiple default or static routes

• Firewall rules based on source address

• Applications bound to a specific IBM i interface

• Communication paths between production and disaster recovery networks

2. The traceroute Command

The traceroute command sends ICMP Echo Request packets with progressively increasing TTL values.

It examines the ICMP responses returned by devices along the path, including:

• Time Exceeded messages from intermediate routers

• Destination Unreachable messages

• Echo Reply messages from the final destination

These replies are used to build the hop-by-hop path between the IBM i partition and the remote destination.

Syntax

traceroute [options] <host>

  -m max_ttl     Maximum TTL
                 Default: 30

  -w timeout     Per-probe timeout in seconds
                 Default: 2

  -q nqueries    Number of probes per hop
                 Default: 3

  -n             Do not resolve hostnames
                 Display IP addresses only

  -f first_ttl   Initial TTL
                 Default: 1

  -l address     Local source IP address
                 The socket is bound to this address before sending

  -Version
  --version      Display version information as JSON and exit

Examples

Run traceroute using the default values:

traceroute 9.9.9.9

Example output:

traceroute to 9.9.9.9, 30 hops max, 48 byte packets
 1  10.20.5.1 (10.20.5.1)  0.412 ms  0.398 ms  0.377 ms
 2  172.27.0.1 (172.27.0.1)  1.204 ms  1.156 ms  1.098 ms
...
14  dns.google (9.9.9.9)  11.982 ms  12.107 ms  12.430 ms

Disable hostname resolution and limit the trace to 20 hops:

traceroute -n -m 20 9.9.9.9

Send three probes per hop and use a three-second timeout for each probe:

traceroute -q 3 -w 3 9.9.9.9

Force the trace to use a specific local IBM i source address:

traceroute -l 10.20.5.24 9.9.9.9

Selecting the local source address is important when troubleshooting routing, firewall, or VPN issues.

On a system with multiple IP addresses, a test without a controlled source address may use a different interface or routing path from the application or service being investigated.

For example, the following two tests may follow different paths:

traceroute -l 10.20.5.24 9.9.9.9
traceroute -l 172.26.2.5 9.9.9.9

That difference can be critical when diagnosing asymmetric routing, VPN traffic selectors, source-based firewall rules, or connectivity through different VLANs.

3. The netstat Command

The netstat command queries IBM i networking information through Db2 for i SQL Services and db2util.

It then parses, filters, and formats the returned data in Python.

By default, it queries:

QSYS2.NETSTAT_INFO

This view provides information about active TCP/IP connections.

The command can also query:

QSYS2.NETSTAT_INTERFACE_INFO

for network interface information, and:

QSYS2.NETSTAT_ROUTE_INFO

for the routing table.

When the -p option is specified, the command uses:

QSYS2.NETSTAT_JOB_INFO

to identify the IBM i job associated with each connection.

Syntax

netstat [options] [filter ...]

  -i             Display network interfaces
                 Uses QSYS2.NETSTAT_INTERFACE_INFO

  -r             Display the routing table
                 Uses QSYS2.NETSTAT_ROUTE_INFO

  -t             Display TCP connections only

  -u             Display UDP connections only

  -l             Display listening sockets only

  -p             Include the IBM i job associated with each connection

  -n             Do not resolve well-known port names
                 Display numeric port numbers only

  -Version
  --version      Display version information as JSON and exit

The -t, -u, -l, and -p options apply to the default connection view.

They have no effect when used together with -i or -r.

Displaying Active Connections

The default view displays active TCP/IP connections:

netstat

Example output:

Proto  Local Address            Remote Address           State         Idle(s) User
tcp4   9.5.168.5.as-svrmap      9.5.168.10.60000         ESTABLISHED      12.3 QUSER
tcp4   0.0.0.0.telnet           0.0.0.0.0                LISTEN            0.0 QSYS

Displaying the Associated IBM i Job

Use -p to include the IBM i job associated with each connection:

netstat -p

The job is displayed using the standard IBM i job format:

job-number/user/job-name

Example:

Proto  Local Address            Remote Address           State         Idle(s) User        Job
tcp4   9.5.168.5.as-svrmap      9.5.168.10.60000         ESTABLISHED      12.3 QUSER       012345/QUSER/QRWTSRVR

This can help identify which IBM i job owns a particular TCP/IP connection.

It is particularly useful when investigating:

• Database connections

• ODBC or JDBC sessions

• IBM i Access connections

• FTP or SFTP traffic

• Application server connections

• Connections associated with long-running jobs

• Unexpected listening ports

Displaying Network Interfaces

Display the configured network interfaces:

netstat -i

Example output:

Line         Type   Status   Address          Network             MTU
ETHLINE      ELAN4  ACTIVE   9.5.168.5        9.5.168.0          1500

Displaying the Routing Table

Display the IBM i routing table:

netstat -r

Example output:

Destination          Netmask          Next Hop             Status
0.0.0.0              0.0.0.0          9.5.168.1            YES

Filtering netstat Results

Any additional argument supplied to netstat is treated as a free-text filter.

Filtering is case-insensitive, and only rows containing all the supplied terms are displayed.

Unlike piping the output through grep, the column headings remain visible.

Filter by Connection State

netstat established

Filter by IP Address

netstat 192.168.1.70

Filter by Port

netstat 8471

Filter by User

netstat quser

Filter by Protocol

netstat tcp

Combine Multiple Filters

Multiple filters can be specified in the same command.

Every supplied filter must match the same output row:

netstat 192.168.1.70 established 8471

Conceptually, this is similar to running:

netstat | grep 192.168.1.70 | grep -i established | grep 8471

However, the built-in filtering provides several advantages:

• The column headings remain visible

• Filtering is case-insensitive

• There is no practical limit on the number of filters

• The filtering logic is consistent across all views

• No additional shell pipeline is required

Filtering also applies to the interface and routing-table views.

Combine Structured Options with Filters

Display TCP sockets in the LISTEN state:

netstat -t -l

Display established connections and include the associated IBM i job:

netstat -p established

Display TCP connections associated with port 8471:

netstat -t 8471

Display connections from a specific user and IP address:

netstat quser 192.168.1.70

How the Toolkit Works

ping

The ping command creates an ICMP Echo Request packet using Python's struct.pack() function.

The packet contains:

• ICMP type

• ICMP code

• Checksum

• Packet identifier

• Sequence number

• Payload

The command opens a raw socket using:

socket.socket(
    socket.AF_INET,
    socket.SOCK_RAW,
    socket.IPPROTO_ICMP
)

It sends the packet to the requested destination and uses select() to wait for a response within the configured timeout.

Replies are matched to requests using the packet identifier and sequence number.

The round-trip time is calculated from the time the packet is sent until the corresponding ICMP Echo Reply is received.

traceroute

The traceroute command also uses raw ICMP sockets.

It begins with a low TTL value and increases it for each hop.

When the TTL reaches zero on an intermediate router, that router normally returns an ICMP Time Exceeded message.

The command records the router address and round-trip time, then repeats the process with a higher TTL.

The trace stops when one of the following occurs:

• An ICMP Echo Reply is received from the destination

• An ICMP Destination Unreachable message is received

• The configured maximum TTL is reached

netstat

The netstat command executes fixed SQL queries through:

subprocess.run(["db2util", sql])

The output returned by db2util is parsed using Python's built-in csv module.

The command then:

1. Executes the required SQL query

2. Parses the returned rows

3. Formats the selected columns

4. Applies any requested filters

5. Displays the final output

The SQL statements are fixed by the application and are not constructed from free-form user input.

The user-supplied filters are applied locally to the formatted results.

Version Information

All three commands support:

-Version

and:

--version

The output is returned as structured JSON.

For example:

ping --version

This returns information such as:

• Tool name

• Version

• Author

• Company

• Licence

Using JSON makes the output easier to consume from scripts and automation tools.

It can also be useful when checking which toolkit version is installed across several IBM i partitions.

Security Considerations

The ping and traceroute commands require sufficient authority to open raw ICMP sockets.

This should be reviewed carefully before deploying the toolkit in a production environment.

The netstat command deliberately provides no option to connect to a remote database or supply database credentials.

During development, an option to supply a remote database password was considered, but it was not retained because plaintext passwords supplied on a command line may:

• Be visible through process listings

• Remain in shell history

• Be captured by auditing or monitoring tools

• Be exposed to other users of the system

The netstat implementation therefore always queries the local IBM i database through db2util.

Recommendations Before Production Use

Before installing the scripts in a production environment:

• Test them on a non-production partition

• Review the default settings against your environment

• Verify the authority required to open raw sockets

• Verify the authority required to access the IBM i SQL Services

• Ensure that only authorised users can modify files in /QOpenSys/pkgs/bin

• Check whether commands with the same names are already installed

• Keep the scripts under version control

• Review and deploy updates deliberately rather than automatically

Example file permissions:

chmod 755 /QOpenSys/pkgs/bin/ping
chmod 755 /QOpenSys/pkgs/bin/traceroute
chmod 755 /QOpenSys/pkgs/bin/netstat

The final permissions should always follow the security policies and operational requirements of each organisation.

Practical Examples

The following examples show how the three tools can be combined during IBM i network troubleshooting.

Test connectivity using a specific local IP address and a larger packet size:

ping -c 10 -s 1400 -l 10.20.5.24 9.9.9.9

Trace the network path using a specific IBM i source address:

traceroute -l 172.26.2.5 -w 2 9.9.9.9

Find established connections involving a specific local address and port:

netstat 10.20.5.24 established 8471

Display established TCP connections and the associated IBM i jobs:

netstat -t -p established

Display listening TCP ports:

netstat -t -l

Display only numeric ports:

netstat -n

Display the routing table and filter for the default route:

netstat -r 0.0.0.0

Conclusion

SSH and PASE are important tools for IBM i administration, automation, and troubleshooting.

Using them does not mean abandoning the native capabilities of the IBM i platform.

This toolkit combines:

• Python raw sockets for ICMP-based ping and traceroute

• Db2 for i SQL Services for TCP/IP connection, interface, route, and job information

• db2util for executing SQL directly from the shell

• A consistent command-line interface familiar to Linux, AIX, and Unix administrators

The result is a more practical shell-based experience during an SSH session on IBM i.

Behind these commands, IBM i is still doing the real work through its native TCP/IP stack, raw sockets, Db2 for i, and IBM i SQL Services.

This is not about turning IBM i into Linux.

It is about making shell-based administration and network troubleshooting more practical, while retaining the reliability, security, and capabilities of the IBM i platform.

The source code, README, and changelog are available on GitHub:

github.com/rqmartins73/ibmi-rqm-nettools

---

Ricardo Martins
IBM Power Technical Leader
IBM Champion 2025 and 2026
Blue Chip Portugal

github.com/rqmartins73