Ports & NetworkManager

Inspecting Ports & Connections

A single machine can run many network services at once (a web server, an SSH daemon, a database) - ports are how the kernel tells their traffic apart, since they all share the same IP address. Being able to answer "what is this machine actually listening for connections on right now?" is a core troubleshooting skill.

Command	Shows
`ss -tulpn`	Listening TCP/UDP sockets + PIDs
`ss -s`	Socket summary
`ping host`	Reachability
`traceroute host`	Path to host
`curl -I url`	HTTP headers

$ ss -tulpn | grep :22
tcp  LISTEN 0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=812))

Breaking down that ss output: tcp/LISTEN says this is a TCP socket waiting for incoming connections (not yet an active conversation); 0.0.0.0:22 means it's listening on port 22 across every network interface on the machine; and the users: field names exactly which process owns it - here, sshd at PID 812. That PID is your direct link from "something is listening on this port" to "here's the actual process responsible."

NetworkManager (nmcli) - persistent config

Where ip makes live, temporary changes, NetworkManager is the service most desktop and many server distros use to manage network configuration persistently - its settings survive reboots because it owns the actual config storage, not just the kernel's live state.

Command	Action
`nmcli device status`	Interface overview
`nmcli connection show`	List connections
`nmcli con add type ethernet ...`	Create a connection
`nmcli con mod <name> ipv4.addresses 192.168.1.5/24`	Set static IP
`nmcli con up <name>`	Activate

Tip: ss ("socket statistics") is the direct, actively-maintained replacement for the deprecated netstat, and ss -tulpn is worth memorizing as a single unit: -t TCP, -u UDP, -l listening sockets only, -p show the owning process, -n show numeric ports instead of resolving service names (faster, and avoids relying on /etc/services or DNS). Together, that one flag combination answers "what's listening on this box, and what process owns it?" - one of the very first commands to run when debugging "why can't I connect to this service."