I am teaching a graduate-level class in computer communications and networking in this semester. One of the first things I do in that class is review the command-line tools you have available for network configuration and troubleshooting. Y’all know I’m an Apple person and I find that, like most command-line level stuff, Apple people are not very cognizant of the power you have with the command-line. So, I thought I’d share some of the notes from my class focused on macOS networking.
macOS ships with a strong set of command-line networking tools. Many of them come from the BSD and POSIX tradition, and work almost exactly the same as they do on FreeBSD, OpenBSD, and Linux. On top of that, Apple adds a set of system configuration and diagnostics tools that integrate with macOS frameworks like System Configuration, NetworkExtension, and the Wi‑Fi stack.
This post is organized in two parts:
- Traditional BSD utilities you can expect on most Unix-like systems
- Apple-specific tools that are especially useful on macOS
Part 1: Traditional BSD utilities (the classics)
These tools are generally stable, script-friendly, and easy to combine in pipelines.
ping and ping6: basic reachability and latency
Use ping to answer two questions:
- Can I reach this host?
- What is the latency and packet loss?
Examples:
ping -c 5 1.1.1.1
ping -c 5 [example.com](<http://example.com>)
Notes:
- ICMP can be blocked by firewalls, so “no ping” does not always mean “no connectivity.”
traceroute: path discovery (where packets go)
traceroute shows the hop-by-hop path toward a destination.
traceroute [example.com](<http://example.com>)
Helpful options:
-nfor numeric output (faster; avoids DNS lookups)-wto adjust timeout
ifconfig: interfaces, addresses, and link state
On macOS, ifconfig is still the canonical interface tool.
Show all interfaces:
ifconfig
Show one interface:
ifconfig en0
Common things to look for:
- IPv4 address (
inet) - IPv6 address (
inet6) - MAC address (
ether) - Status (
status: active)
Tip: on many Macs, Wi‑Fi is often en0 and Ethernet is often en1 or another en*, but it varies.
netstat: sockets and routing info (legacy but handy)
netstat can show listening ports, established connections, and routing tables.
Show listening TCP sockets:
netstat -anv | grep LISTEN
Show routing table:
netstat -rn
macOS note: for some tasks, netstat is being superseded by tools like lsof, route, and Apple’s newer diagnostics tools, but it is still useful.
route: view and modify the routing table
View the current default route:
route -n get default
Show the route to a specific destination:
route -n get 8.8.8.8
Be cautious editing routes on a laptop. In most cases you want to inspect rather than change.
arp: inspect the ARP cache (IPv4 LAN neighbor mapping)
When troubleshooting local LAN issues (wrong gateway, duplicate IPs, suspicious devices), arp can help.
arp -a
nslookup, dig, and host: DNS troubleshooting
DNS is often the source of “the internet is down” reports. These tools confirm what your resolver is doing.
dig is the most informative:
dig [example.com](<http://example.com>) A
dig [example.com](<http://example.com>) AAAA
dig +short [example.com](<http://example.com>)
Check which DNS server is answering:
dig [example.com](<http://example.com>) @1.1.1.1
nc (netcat): quick TCP/UDP testing
nc is great for testing whether a port is reachable.
Test TCP connect:
nc -vz [example.com](<http://example.com>) 443
Listen on a port (for local testing):
nc -l 9000
tcpdump: packet capture (the gold standard)
If you want to know what is actually on the wire, use tcpdump.
Capture on Wi‑Fi (en0) and show DNS traffic:
sudo tcpdump -i en0 -n port 53
Capture HTTPS flow behavior:
sudo tcpdump -i en0 -n tcp port 443
Pro tips:
- Always start with
-nto avoid DNS lookups in your capture output. - Keep captures narrow (filter early) so you can read them.
lsof: map ports back to processes
When you see “something is listening on port 8080,” lsof answers “what process?”
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
This is often the fastest way to diagnose conflicts with dev servers, proxies, or VPN clients.
Part 2: Apple-specific tools (macOS superpowers)
These tools understand macOS network services and configuration layers better than the classic Unix utilities.
networksetup: manage network service settings
networksetup is a friendly CLI wrapper for many settings you would otherwise click through in System Settings.
List network services:
networksetup -listallnetworkservices
Show Wi‑Fi info for a service name:
networksetup -getinfo "Wi-Fi"
See DNS servers configured for a service:
networksetup -getdnsservers "Wi-Fi"
Set DNS servers (example):
sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 1.0.0.1
Tip: macOS has multiple “network services” (Wi‑Fi, Ethernet adapters, Thunderbolt bridges, VPN interfaces). Troubleshooting often gets easier once you know which service you are actually using.
scutil: System Configuration and name resolution details
scutil is lower-level than networksetup and is extremely useful when configuration looks correct in the UI but behavior is still odd.
Show current DNS resolver state (one of the best troubleshooting commands on macOS):
scutil --dns
Show proxy configuration:
scutil --proxy
Get the “primary” network interface/service in use:
scutil --nwi
ipconfig (macOS): DHCP and interface address details
On macOS, ipconfig is not the Windows tool. It is a small utility mainly for DHCP and interface state.
Get the IPv4 address of an interface:
ipconfig getifaddr en0
Renew DHCP lease:
sudo ipconfig set en0 DHCP
system_profiler: inventory network hardware (when names are confusing)
If you are unsure what hardware exists (especially with docks/adapters), system_profiler can help.
Wi‑Fi details:
system_profiler SPAirPortDataType
Network hardware list:
system_profiler SPNetworkDataType
log show: read macOS unified logs for networking clues
When problems are intermittent, the system logs can expose DHCP renewals, Wi‑Fi roam events, and VPN behavior.
Example (last hour, filtering for Wi‑Fi keywords):
log show --last 1h --predicate 'eventMessage CONTAINS[c] "Wi-Fi"'
This is powerful but can be noisy. Narrow your time window and predicate.
Wi‑Fi diagnostics: airport
Apple ships a Wi‑Fi utility called airport. It is not always on your PATH, so you typically run it via the full path.
Show Wi‑Fi link status (SSID, RSSI, channel, rates):
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I
Scan for nearby networks:
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s
If you troubleshoot Wi‑Fi often, airport -I is the quickest “is my signal bad?” check.
dns-sd: browse and test Bonjour / mDNS service discovery
macOS heavily uses Bonjour (mDNS) for printers, AirPlay, and peer discovery.
Browse services of a type (example: AirPrint):
dns-sd -B _ipp._tcp
Resolve a service instance:
dns-sd -L "Some Printer" _ipp._tcp local
A practical troubleshooting flow (putting it together)
When a Mac has “network issues,” a repeatable flow saves time:
- Link + IP
ifconfig en0ipconfig getifaddr en0
- Default route
route -n get default
- DNS
scutil --dnsdig [example.com](<http://example.com>)
- Reachability and path
ping -c 5 1.1.1.1traceroute [example.com](<http://example.com>)
- Ports and processes
nc -vz [example.com](<http://example.com>) 443sudo lsof -nP -iTCP -sTCP:LISTEN
- Packet capture (when you must prove what’s happening)
sudo tcpdump -i en0 -n ...
Closing thoughts
The biggest shift on macOS is not that the Unix tools are missing. It is that the configuration and behavior often live in higher-level macOS systems (network services, DNS resolver stacks, Wi‑Fi frameworks, VPN profiles). Knowing when to reach for scutil and networksetup is what turns “I can’t reproduce it” into actionable information.
If you only memorize three commands for macOS-specific diagnostics, make them:
scutil --dnsnetworksetup -listallnetworkservicesairport -I