Introduction to command-line tools

The previous article ended on the NIC — the hardware that turns bits into a signal and back. Everything from there down to the physical layer is invisible in normal use. You don't see frames, you don't see a TTL field decrementing hop by hop, you don't see a TLS handshake happening before a browser tab even starts rendering. The tools in this part of the module are how you make any of that visible, from a terminal, without needing a full packet capture for every question.

Why a terminal command instead of a GUI

Every operating system ships a graphical way to check "is my network working" — a Wi-Fi icon, a network settings panel, a status light. None of them tell you why something is broken. A command-line tool gives you a specific, repeatable question and a specific answer: which host answered, how long it took, which port is listening, what the DNS server actually returned. That precision is also why these tools show up constantly in incident response and automated monitoring — a script can parse dig's output; it can't parse a GUI.

The three questions these tools answer

Loosely, the tools this module covers split into four groups, each answering a different kind of question:

That grouping isn't a strict boundary — ping also confirms basic name resolution, and nmap can double as a reachability check — but it's a useful way to decide which tool to reach for first when you don't yet know where a problem sits.

A recurring theme: the tool you learned first isn't always the current one

Several of the classic tools in this list — netstat, ifconfig, nslookup — predate a newer generation built to replace them: ss, ip, and dig, respectively. The older tools still exist on many systems, still work, and are still worth recognising, because plenty of documentation, scripts, and older colleagues reference them. But each has a specific, documented reason a maintainer eventually wrote something better, and both generations get their own article here rather than pretending the older one is still the recommended default.

Two practical consequences are worth stating plainly, because they bite people on real servers:

• A minimal Ubuntu Server install or a Debian-based container image frequently ships without net-tools, so ifconfig and netstat simply aren't there. ip and ss are part of iproute2, which is always installed.
• ss and ip expose information the older pair cannot show at all — per-connection congestion state, the kernel's actual routing decision for a specific destination — so they aren't merely a rename.

If you learn one command from this module properly, make it ss. If you learn two, add ip.

What you'll need

Everything here assumes a Linux host (Ubuntu Server LTS, as elsewhere in this course) unless an article is explicitly about a Windows-only tool like ipconfig. Most of these tools ship by default; a couple — nmap in particular — need an explicit install:

sudo apt install nmap

None of the commands in this module modify a live network's configuration or firewall rules. Where a later module does cover something riskier — changing a routing table, opening a port in nft — that risk is called out explicitly at the point it comes up, not here.

How to use this module

Read the articles in order if you're new to all of this. The first three — ip, ss, and netcat — are the ones you'll type most often in real work, so they come first; ping and traceroute build directly on the ICMP mechanics from the previous module; and nslookup is worth seeing before dig so the jump in depth actually lands. If you already know the basics of one tool, skip straight to it; each article stands on its own. Either way, the goal by the end is the same: given a "the network's broken" report, know which single command to run first, and how to read what it tells you.

Sources

• Linux man-pages, intro(1)