Hey there, fellow tech explorers and Linux enthusiasts! Ever found yourself scratching your head, wondering what’s *really* going on with your network connections on a Linux machine? Maybe you’re trying to figure out why a service isn’t responding, which program is hogging a specific port, or just curious about the digital conversations happening under the hood. Well, you’re in luck! Today, we’re diving deep into a classic, yet powerful, command-line utility: netstat.

Think of netstat as your network detective kit for Linux. It helps you peer into the intricate web of network connections, listening ports, interface statistics, routing tables, and more. While newer tools are emerging (and we’ll touch on those!), understanding netstat is still incredibly valuable, especially since you’ll find it on countless systems. Get ready to unravel the mysteries of your Linux networking with practical examples and clear explanations!

What Exactly is the Netstat Command in Linux?

At its core, netstat stands for Network Statistics. It’s a command-line tool that displays a whole bunch of information related to network activities on your system. It’s like getting a detailed report card on how your machine is communicating over the network, both internally (talking to itself) and externally (talking to the world).

Defining “Network Statistics”

What kind of statistics are we talking about? Netstat can show you:

1. Active Connections: Which computers or services your machine is currently talking to (both incoming and outgoing).
2. Listening Ports: Which ports on your machine are open and waiting for incoming connections (like open doors waiting for visitors).
3. Routing Tables: The rules your system uses to decide where to send network traffic.
4. Interface Statistics: How much data has been sent and received on your network cards (Ethernet, Wi-Fi).
5. Masquerade Connections: Specific to network address translation (NAT).
6. Multicast Memberships: Information about joining multicast groups.

Essentially, it provides visibility into the TCP/IP networking subsystem.

A Quick History and Its Modern Context (Mentioning Deprecation)

Netstat has been a trusty companion for system administrators and developers for decades. It’s part of the traditional net-tools package, which was the standard suite for network configuration and analysis on Linux for a very long time.

However, technology marches on! In modern Linux distributions, the net-tools package, including netstat, is often considered deprecated. This doesn’t mean it’s useless or completely gone (many systems still include it for compatibility), but it means there’s a newer, generally better alternative. The modern replacement is the iproute2 suite, which includes the ss command (Socket Statistics) as the successor to netstat. We’ll explore ss later, but learning netstat is still important because:

• You’ll encounter it on older systems.
• Many tutorials and legacy scripts still use it.
• Its concepts directly translate to understanding ss.

So, let’s treat learning netstat as building a strong foundation.

Why Should You Care About Netstat? (Its Importance)

You might be thinking, “Okay, it shows network stuff, but why is that *important* for me?” Great question! Understanding netstat (or its successor ss) is crucial for several reasons:

Network Monitoring and Troubleshooting

This is perhaps the most common use case. When something goes wrong with network connectivity – a website won’t load, an application can’t reach its server, your database connection fails – netstat is often one of the first tools you’ll reach for. It helps answer questions like:

• Is the service I’m trying to reach actually *listening* for connections on the expected port?
• Is my machine successfully establishing a connection to the remote server?
• Are there too many connections overwhelming a service?
• Is there a firewall blocking the connection (indicated by connection states)?

Security Auditing

From a security perspective, netstat is invaluable. You can use it to:

• Identify unexpected open ports that could be security vulnerabilities.
• Spot unusual or unauthorized connections to remote machines.
• See which programs are responsible for specific network activity (potentially identifying malware or misconfigured applications).

Regularly checking your network state with netstat can be a vital part of securing your system. A sudden appearance of a listening port you didn’t configure warrants immediate investigation!

Understanding Application Behavior

For developers, netstat helps understand how their applications interact with the network.

• Is your web server binding to the correct IP address and port?
• Is your microservice making the outbound connections you expect?
• How many connections is your application handling?

It provides empirical evidence of the network footprint of your software.

Understanding the Basic Netstat Syntax

Using netstat is generally straightforward. The basic structure is:

netstat [options]

You run the netstat command followed by one or more options (flags) that tell it *what* information you want to see and *how* you want to see it. Without any options, netstat usually displays open sockets (connections). However, its real power comes from using its various flags.

Let’s start exploring some of the most useful options with examples. Remember, you’ll likely run these commands in your Linux terminal.

Exploring Network Connections (The Core Functionality)

One of the primary jobs of netstat is to show you the active network connections.

Listing All Connections (TCP & UDP): netstat -a

The -a (all) option tells netstat to show both listening and non-listening sockets (connections). This gives you a comprehensive overview of TCP and UDP ports.

netstat -a

Sample Output (abbreviated):

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:smtp          0.0.0.0:*               LISTEN
tcp        0      0 my-server:ssh           client-ip:51234         ESTABLISHED
tcp6       0      0 [::]:http              [::]:*                  LISTEN
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*
udp        0      0 my-server:ntp           0.0.0.0:*
...
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  2      [ ]         DGRAM                    12345    /run/systemd/notify
unix  3      [ ]         STREAM     CONNECTED      15678    /run/dbus/system_bus_socket
...

This output shows TCP connections (some listening, one established), listening IPv6 ports, open UDP ports, and also Unix domain sockets (used for inter-process communication on the same machine). It’s a lot of information!

Focusing on TCP Connections: netstat -at

Often, you’re primarily interested in TCP connections (used for web browsing, SSH, FTP, etc.). You can combine the -a (all) option with -t (TCP) to filter for only TCP sockets.

netstat -at

Sample Output (TCP only):

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:smtp          0.0.0.0:*               LISTEN
tcp        0      0 my-server:ssh           client-ip:51234         ESTABLISHED
tcp6       0      0 [::]:http              [::]:*                  LISTEN
...

This is much cleaner if you only care about TCP.

Zeroing in on UDP Connections: netstat -au

Similarly, if you need to investigate UDP (User Datagram Protocol) connections, often used for DNS, DHCP, NTP, and streaming, you use the -a (all) and -u (UDP) flags.

netstat -au

Sample Output (UDP only):

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*
udp        0      0 my-server:ntp           0.0.0.0:*
udp        0      0 localhost:domain        0.0.0.0:*
udp6       0      0 [::]:mdns              [::]:*
...

This shows which UDP ports are open and potentially receiving data. Note that UDP is connectionless, so you won’t see states like ESTABLISHED.

Identifying Listening Ports

Sometimes, you don’t need to see *all* connections; you specifically want to know which ports are open and *listening* for incoming connections. This is crucial for verifying if a server process (like a web server or database) has started correctly.

Finding Services Waiting for Connections: netstat -l

The -l (listening) option filters the output to show only sockets that are in the LISTEN state.

netstat -l

Sample Output (Listening Sockets):

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:smtp          0.0.0.0:*               LISTEN
tcp6       0      0 [::]:http              [::]:*                  LISTEN
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*
udp        0      0 my-server:ntp           0.0.0.0:*
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  2      [ ACC ]     STREAM     LISTENING      9876     /var/run/docker.sock
...

This output clearly shows which TCP and UDP ports are ready to accept new connections. If you expected your web server (port 80/http or 443/https) to be running, you should see it listed here.

Listing Listening TCP Ports: netstat -lt

To see only *TCP* ports that are listening, combine -l and -t:

netstat -lt

Sample Output (Listening TCP):

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:smtp          0.0.0.0:*               LISTEN
tcp6       0      0 [::]:http              [::]:*                  LISTEN

Listing Listening UDP Ports: netstat -lu

And for listening *UDP* ports, combine -l and -u:

netstat -lu

Sample Output (Listening UDP):

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*
udp        0      0 my-server:ntp           0.0.0.0:*

Showing Process IDs (PIDs) and Program Names

Okay, so you see a port is listening or a connection is established. But *which application* is responsible for it? This is where the -p (program) option comes in. It shows the Process ID (PID) and the name of the program associated with each socket.

Important Note: Due to security restrictions in Linux, retrieving the process name associated with a socket usually requires root privileges. You’ll likely need to run this command using sudo.

Connecting Ports to Processes: netstat -p (Requires Root/Sudo)

sudo netstat -p

Sample Output (with PIDs/Programs – Requires sudo):

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 my-server:ssh           client-ip:51234         ESTABLISHED 1234/sshd: user [pr
...
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  3      [ ]         STREAM     CONNECTED      15678    456/systemd         /run/dbus/system_bus_socket
...

Now, next to each connection or socket, you see the PID/Program name column. For example, 1234/sshd: user [pr tells you that the SSH daemon (sshd) with process ID 1234 is handling that established SSH connection. This is incredibly useful for identifying exactly what’s using a network port. If you see an unexpected program listening on a port, it’s time to investigate!

Displaying Numerical Addresses (Avoiding DNS Lookups)

By default, netstat tries to be helpful by resolving IP addresses and port numbers into hostnames and service names (e.g., showing my-server:ssh instead of 192.168.1.100:22). While this can be readable, it involves performing DNS lookups, which can significantly slow down the command, especially if DNS is slow or unresponsive.

Speeding Things Up with Numerical Output: netstat -n

The -n (numeric) option tells netstat *not* to resolve names. It will display raw IP addresses and port numbers. This makes the command run much faster and is often preferred for scripting or quick checks.

netstat -n

Sample Output (Numerical):

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 192.168.1.100:22        192.168.1.50:51234      ESTABLISHED
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
udp        0      0 0.0.0.0:68              0.0.0.0:*
...

Notice how my-server:ssh is now 192.168.1.100:22, and localhost:smtp is 127.0.0.1:25. This is often much more useful for technical analysis.

Viewing the Kernel Routing Table

Your Linux system uses a routing table to decide where to send network packets. Netstat can display this table, helping you understand how traffic flows from your machine to other networks (including the internet).

Understanding How Your System Routes Traffic: netstat -r

The -r (route) option displays the kernel’s IP routing table.

netstat -r

Sample Output (Routing Table):

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Let’s break down the key columns:

• Destination: The destination network or host. 0.0.0.0 represents the default route (for any destination not explicitly listed).
• Gateway: The router or next hop address to reach the destination. 0.0.0.0 means the destination is directly connected.
• Genmask: The netmask for the destination network. 255.255.255.255 for a specific host, 0.0.0.0 for the default route.
• Flags: Indicate properties of the route (U=Up, G=Gateway, H=Host).
• Iface: The network interface (e.g., eth0, wlan0) used for this route.

In this example:

1. Traffic to any destination not on the local network (0.0.0.0) is sent via the gateway 192.168.1.1 using the eth0 interface. This is your default internet route.
2. Traffic destined for the local 192.168.1.0 network (subnet mask 255.255.255.0) is sent directly out the eth0 interface (no gateway needed).

You can also use netstat -rn to see the routing table with numerical addresses, which is generally faster and more common.

Inspecting Network Interface Statistics

Want to see how busy your network cards are? Netstat can provide a summary of packet counts, errors, and dropped packets for each network interface.

Checking Interface Health and Traffic: netstat -i

The -i (interfaces) option displays statistics for network interfaces configured on your system.

netstat -i

Sample Output (Interface Statistics):

Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500  1234567      0      0      0   987654      0      0      0 BMRU
lo       65536    54321      0      0      0    54321      0      0      0 LRU
wlan0     1500   876543      5     12      0   654321      0      0      0 BMRU

Key columns explained:

• Iface: Interface name (lo is the loopback interface).
• MTU: Maximum Transmission Unit (maximum packet size).
• RX-OK: Packets successfully received.
• RX-ERR: Received packets with errors.
• RX-DRP: Received packets dropped (likely due to buffer issues).
• RX-OVR: Received packets dropped due to overruns.
• TX-OK: Packets successfully transmitted.
• TX-ERR: Transmitted packets with errors.
• TX-DRP: Transmitted packets dropped.
• TX-OVR: Transmitted packets dropped due to overruns.
• Flg: Interface flags (B=Broadcast, M=Multicast, R=Running, U=Up, L=Loopback).

High error (RX-ERR, TX-ERR) or dropped (RX-DRP, TX-DRP) counts might indicate network hardware problems, driver issues, or network congestion.

Combining Options for Powerful Queries

The real magic of netstat (and many Linux commands) happens when you combine options to get precisely the information you need. We’ve already seen -at, -au, -lt, -lu, and -rn.

Let’s look at a very common and powerful combination:

Example: Finding Listening TCP Ports with PIDs (Numerical): netstat -ltnp

This command combines:

• -l: Show only listening sockets.
• -t: Show only TCP sockets.
• -n: Show numerical addresses and port numbers.
• -p: Show the PID and program name (requires sudo).

sudo netstat -ltnp

Sample Output:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      987/sshd
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      777/cupsd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1100/master
tcp6       0      0 :::80                   :::*                    LISTEN      1500/apache2
tcp6       0      0 :::443                  :::*                    LISTEN      1500/apache2

This output is incredibly informative for administrators:

• You see *only* the TCP ports that are actively listening for connections.
• Everything is numerical, making it fast and unambiguous.
• Crucially, you see *exactly which program* (with its PID) is responsible for each listening port.

This is perfect for verifying your services (SSH on port 22 by sshd, CUPS printing on 631 by cupsd, Postfix mail on 25 by master, Apache web server on 80 and 443 by apache2) are running correctly and listening on the expected ports. If you saw something unexpected here, like 1234/unknown_malware listening on port 6666, you’d know you have a problem!

Decoding Netstat’s Output Columns

When you look at netstat output, especially for connections (-a, -t, -u), you see several columns. Understanding these is key to interpreting the results:

Proto, Recv-Q, Send-Q

• Proto: The protocol used by the socket (e.g., tcp, udp, tcp6, udp6, unix).
• Recv-Q: The count of bytes not yet copied by the user program connected to this socket. Ideally, this should be 0. A non-zero value might indicate the application is slow in processing incoming data.
• Send-Q: The count of bytes not yet acknowledged by the remote host. Ideally, this should also be 0 after a connection is established and stable. A non-zero value could mean the remote end isn’t acknowledging data quickly or there’s network congestion.

Local Address, Foreign Address

• Local Address: The IP address and port number on *your* machine. 0.0.0.0 means listening on all available network interfaces for IPv4. [::] means the same for IPv6. 127.0.0.1 (or localhost) means listening only for connections originating from the machine itself.
• Foreign Address: The IP address and port number of the *remote* machine connected to the socket. For listening sockets (LISTEN state), this is usually 0.0.0.0:* or [::]:*, indicating it’s waiting for a connection from any address on any port.

State (LISTEN, ESTABLISHED, TIME_WAIT, etc.)

This column, primarily relevant for TCP connections, shows the current status of the connection. Some common states include:

• LISTEN: The socket is waiting for an incoming connection request (typical for server processes).
• SYN_SENT: Your machine has sent a connection request (SYN packet) and is waiting for a matching acknowledgment (SYN-ACK).
• SYN_RECV: The socket has received a connection request (SYN) and sent back an acknowledgment (SYN-ACK), now waiting for the final acknowledgment (ACK) from the client. (Often seen during SYN flood attacks if many connections linger here).
• ESTABLISHED: The connection is fully established, and data can be exchanged. This is the normal state for an active connection.
• FIN_WAIT1: Your application has closed the connection, and the socket is waiting for an acknowledgment (FIN-ACK) or a connection termination request (FIN) from the remote end.
• FIN_WAIT2: The socket has received acknowledgment (FIN-ACK) for its close request and is now waiting for the remote end to send its connection termination request (FIN).
• CLOSE_WAIT: The remote end has closed the connection (sent a FIN), and your system has acknowledged it (sent an ACK). The socket is waiting for the local application to close its end of the connection. If many connections stay in CLOSE_WAIT, it often indicates the local application isn’t properly closing its sockets.
• LAST_ACK: The local system has sent its connection termination request (FIN) after being in CLOSE_WAIT, and is waiting for the final acknowledgment (ACK) from the remote end.
• TIME_WAIT: The socket has closed, but it’s kept around for a short period (typically 60 seconds) to handle any delayed packets still in the network, preventing potential issues if a new connection uses the same port numbers immediately. Seeing many TIME_WAIT connections is often normal for busy servers but can sometimes exhaust resources if the rate is excessively high.
• CLOSED: The connection is fully terminated. Netstat usually doesn’t show sockets in this state unless using specific options.

Understanding these states is crucial for diagnosing connection problems. For instance, if a connection attempt seems stuck in SYN_SENT, it might mean a firewall is blocking the connection or the remote server isn’t responding.

PID/Program name

As discussed earlier (requires -p option and often sudo), this shows the Process ID and name of the program owning the socket. Invaluable for mapping network activity back to specific applications.

The Modern Successor: ss Command

Alright, we’ve sung the praises of netstat, but it’s time to talk about the elephant in the room: its deprecation and the rise of ss. The ss command is part of the iproute2 package, which is the modern standard for network configuration and monitoring in Linux.

Why netstat is Being Replaced

The primary reasons for moving away from netstat (and the net-tools package) are:

1. Performance: Netstat often works by reading information from the /proc filesystem, which can be relatively slow, especially on systems with a vast number of connections. ss communicates directly with the kernel via the netlink socket interface, which is significantly faster and more efficient.
2. Information: ss can often provide more detailed TCP state information and internal kernel networking details than netstat.
3. Maintenance: The net-tools package is largely unmaintained, while iproute2 is actively developed alongside the Linux kernel.

Key Advantages of ss

• Speed: Noticeably faster, especially on busy systems.
• More Data: Can display more detailed socket information (e.g., TCP congestion control algorithm, timers).
• Filtering: Offers more powerful and flexible filtering capabilities directly within the command.
• Actively Developed: Aligns better with modern kernel features.

Quick ss Equivalents for Common netstat Tasks

If you’ve learned netstat, transitioning to ss is quite easy as the concepts are similar, and the options often mirror netstat‘s.

As you can see, for many common tasks, just replacing netstat with ss works! The main differences are for routing (ip route) and interface stats (ip link). ss also has powerful state filtering (e.g., ss state established, ss state time-wait).

While netstat might still be present, getting comfortable with ss and ip is highly recommended for modern Linux administration.

Troubleshooting Common Network Issues with Netstat

Let’s put netstat into action with a few troubleshooting scenarios.

Scenario 1: Is My Web Server Running and Listening?

You’ve installed Apache or Nginx, but you can’t access the website.

1. Check for Listening Ports: Run sudo netstat -ltnp | grep -E ':80|:443' (or sudo ss -ltnp | grep -E ':80|:443').
   • This command specifically looks for listening (-l), TCP (-t), numerical (-n) ports with process info (-p), and then uses grep to filter for lines containing the standard HTTP (:80) or HTTPS (:443) ports.
2. Analyze:
   • If you see your web server process (e.g., apache2, nginx) listening on 0.0.0.0:80 or [::]:80: The server *is* running and listening correctly. The problem likely lies elsewhere (firewall, DNS, client issue).
   • If you see it listening only on 127.0.0.1:80: The server is running but only accepting connections from the local machine. You need to reconfigure it to listen on the public IP address or 0.0.0.0.
   • If you don’t see *any* process listening on port 80/443: The web server process isn’t running or failed to bind to the port (maybe another service is already using it, or there was a configuration error). Check the server’s status and logs (systemctl status apache2, journalctl -u nginx).

Scenario 2: Why Can’t I Connect to a Remote Service?

You’re trying to SSH to a remote server (ssh user@remote-server) but the connection times out or is refused.

1. Check Connection State on *Your* Machine: Immediately after trying to connect, run netstat -ant | grep <remote-server-ip>:22 (replace <remote-server-ip> with the actual IP).
2. Analyze:
   • If you see a connection in SYN_SENT state: Your machine is sending the request, but it’s not getting a response. This strongly suggests a firewall (either on your machine, the remote server, or somewhere in between) is blocking the connection, or the remote server isn’t running the SSH service on port 22.
   • If the connection attempt disappears quickly or you see Connection refused: The remote server *is* reachable, but there’s no process listening on port 22, or a firewall on the *remote* server actively rejected the connection.
   • If you see ESTABLISHED: The connection *was* made! If SSH still isn’t working, the issue might be with authentication or the SSH daemon configuration on the server.

Scenario 3: Identifying Unexpected or Suspicious Connections

You suspect your machine might be compromised or running unauthorized software.

1. List All Connections with Processes: Run sudo netstat -antp or sudo netstat -anup (or use ss -antp, ss -anup).
2. Analyze: Carefully examine the list:
   • Look at the Foreign Address column. Are there connections to IP addresses you don’t recognize or trust?
   • Look at the PID/Program name column. Are there processes listening on strange ports (high-numbered ports, ports associated with known malware)? Are there programs making outbound connections that shouldn’t be (e.g., a simple text editor making network connections)?
   • Cross-reference PIDs with ps aux | grep <PID> to get more details about suspicious processes.
   • Pay attention to connections in states like ESTABLISHED to unknown destinations or unexpected LISTEN ports.

This requires some judgment and knowledge of what’s normal for *your* system, but netstat provides the raw data needed for such security investigations.

Wrapping Up: Netstat – Still a Handy Tool (But Know Its Successor)

Phew! We’ve journeyed through the ins and outs of the netstat command in Linux. From listing connections and listening ports to checking routes and interface statistics, it’s a versatile tool for anyone managing or developing on Linux. We saw how combining options like -l, -t, -n, and -p creates incredibly useful one-liners for diagnostics.

While netstat is being phased out in favor of the faster and more modern ss command from the iproute2 suite, the fundamental concepts remain the same. Understanding netstat provides a solid foundation for network troubleshooting and gives you the skills to work on systems both old and new. Knowing how to quickly check listening ports, identify processes using the network, and interpret connection states is an essential skill for any Linux power user.

So, whether you stick with netstat for now or embrace the future with ss, you’re now better equipped to demystify the network activity on your Linux systems!

Frequently Asked Questions (FAQs)

Q1: Is the netstat command available on all Linux distributions?

A: Mostly, yes, especially on older or long-term support releases. However, many modern, minimal distributions might not include the net-tools package (which contains netstat) by default anymore, preferring the iproute2 package (ss, ip commands). You can usually install net-tools manually if needed (sudo apt install net-tools on Debian/Ubuntu, sudo yum install net-tools on CentOS/RHEL), but learning ss is recommended for newer systems.

Q2: Why do I need sudo or root privileges for some netstat options like -p?

A: The -p option reveals which process (PID and name) is associated with a network socket. Accessing information about processes owned by other users or system processes requires elevated privileges (root or sudo) for security reasons. Without sudo, netstat -p will typically only show information for processes running under your own user account, which is often less useful for system-wide diagnostics.

Q3: What’s the main difference between netstat and the ss command?

A: The primary differences are performance and source of information. ss interacts directly with the kernel via the netlink interface, making it significantly faster than netstat, which traditionally parses information from the /proc filesystem. ss can also often provide more detailed socket information and has more advanced filtering capabilities. ss is the modern, preferred tool.

Q4: What does the “State” column (e.g., LISTEN, ESTABLISHED) mean in netstat output?

A: The “State” column indicates the current status of a TCP connection. LISTEN means the socket is waiting for incoming connection requests (a server ready to accept clients). ESTABLISHED means a connection is active, and data transfer can occur. Other states like SYN_SENT, TIME_WAIT, or CLOSE_WAIT represent various stages of connection setup or teardown and are crucial for diagnosing connection problems.

Q5: Can I use netstat to see bandwidth usage per connection?

A: No, netstat itself doesn’t directly show real-time bandwidth usage per connection or per process. It primarily shows connection states, interface statistics (total packets/bytes), and routing information. For detailed, real-time bandwidth monitoring per process or connection, you’d typically use other specialized tools like nethogs, iftop, iptraf-ng, or system monitoring suites like htop (with network columns enabled) or glances.