Difference Between Netstat and Ss in Linux

difference between netstat and ss in linux?

It gets them from kernel space directly using Netlink which uses the classic sockets API.

What are the differences between lsof and netstat on linux?

I faced a similar issue today. The solution was to run the lsof command with sudo privileges.

sudo lsof -i:8086 

should print the desired output.

what's the peer and two address:port from ss -l command mean

Yes, the two "Address:Port" columns are for the IP address and port being used locally and by the other end of the connection.

"Peer" is a common term used for the machine on the other end of a network connection because, historically, all servers on the internet were originally considered to be equal peers rather than divided into "client machines" and "server machines".

In the output of ss -l, the peer is always listed as * (used as a wildcard) because the -l option tells it to show only ports which are listening for new connections, not those which have connections established. If you run ss without -l, you should get some Peer Address:Port entries such as 1.2.3.4:https, showing that you have an active https connection to a peer with IP address 1.2.3.4.

What is a non-listening socket?

A listening socket is one where the server process is waiting for someone to connect to it, for example, an idle web server. The port it is listening on is considered in use.

A non-listening socket is one where a connection has been made, for example, a web server where a web client, such as a browser, has connected, and data can be or is being transmitted. The port the socket was listening on is usually then also cycled back to be listened on by the same process or process tree.

Why is the Recv-Q value in netstat equal to socket backlog + 1?

A backlog value of N really does mean allow "N + 1" connections
to queue to a listening socket. This allows one to specify
"0" as the backlog and still get 1 connection.

Reference: NET: Revert incorrect accept queue backlog changes. · torvalds/linux@64a1465 · GitHub

Why always 5 connections with no program attached?

I've tried duplicating your problem using the following parameters:

  1. The server uses epoll to manage connections.
  2. I make 3000 connections.
  3. Connections are blocking.
  4. The server is basically 'reduced' to handling the connections only and performing very little complicated work.

I cannot duplicate the problem. Here is my server source code.

#include <stddef.h>
#include <stdint.h>
#include <stdbool.h>
#include <stdlib.h>
#include <stdio.h>

#include <errno.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/epoll.h>

#include <err.h>
#include <sysexits.h>
#include <string.h>
#include <unistd.h>

struct {
int numfds;
int numevents;
struct epoll_event *events;
} connections = { 0, 0, NULL };

static int create_srv_socket(const char *port) {
int fd = -1;
int rc;
struct addrinfo *ai = NULL, hints;

memset(&hints, 0, sizeof(hints));
hints.ai_flags = AI_PASSIVE;

if ((rc = getaddrinfo(NULL, port, &hints, &ai)) != 0)
errx(EX_UNAVAILABLE, "Cannot create socket: %s", gai_strerror(rc));

if ((fd = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol)) < 0)
err(EX_OSERR, "Cannot create socket");

if (bind(fd, ai->ai_addr, ai->ai_addrlen) < 0)
err(EX_OSERR, "Cannot bind to socket");

rc = 1;
if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &rc, sizeof(rc)) < 0)
err(EX_OSERR, "Cannot setup socket options");

if (listen(fd, 25) < 0)
err(EX_OSERR, "Cannot setup listen length on socket");

return fd;
}

static int create_epoll(void) {
int fd;
if ((fd = epoll_create1(0)) < 0)
err(EX_OSERR, "Cannot create epoll");
return fd;
}

static bool epoll_join(int epollfd, int fd, int events) {
struct epoll_event ev;
ev.events = events;
ev.data.fd = fd;

if ((connections.numfds+1) >= connections.numevents) {
connections.numevents+=1024;
connections.events = realloc(connections.events,
sizeof(connections.events)*connections.numevents);
if (!connections.events)
err(EX_OSERR, "Cannot allocate memory for events list");
}

if (epoll_ctl(epollfd, EPOLL_CTL_ADD, fd, &ev) < 0) {
warn("Cannot add socket to epoll set");
return false;
}

connections.numfds++;
return true;
}

static void epoll_leave(int epollfd, int fd) {
if (epoll_ctl(epollfd, EPOLL_CTL_DEL, fd, NULL) < 0)
err(EX_OSERR, "Could not remove entry from epoll set");

connections.numfds--;
}

static void cleanup_old_events(void) {
if ((connections.numevents - 1024) > connections.numfds) {
connections.numevents -= 1024;
connections.events = realloc(connections.events,
sizeof(connections.events)*connections.numevents);
}
}

static void disconnect(int fd) {
shutdown(fd, SHUT_RDWR);
close(fd);
return;
}

static bool read_and_reply(int fd) {
char buf[128];
int rc;
memset(buf, 0, sizeof(buf));

if ((rc = recv(fd, buf, sizeof(buf), 0)) <= 0) {
rc ? warn("Cannot read from socket") : 1;
return false;
}

if (send(fd, buf, rc, MSG_NOSIGNAL) < 0) {
warn("Cannot send to socket");
return false;
}

return true;
}

int main()
{
int srv = create_srv_socket("8558");
int ep = create_epoll();
int rc = -1;
struct epoll_event *ev = NULL;

if (!epoll_join(ep, srv, EPOLLIN))
err(EX_OSERR, "Server cannot join epollfd");

while (1) {
int i, cli;

rc = epoll_wait(ep, connections.events, connections.numfds, -1);
if (rc < 0 && errno == EINTR)
continue;
else if (rc < 0)
err(EX_OSERR, "Cannot properly perform epoll wait");

for (i=0; i < rc; i++) {
ev = &connections.events[i];

if (ev->data.fd != srv) {

if (ev->events & EPOLLIN) {
if (!read_and_reply(ev->data.fd)) {
epoll_leave(ep, ev->data.fd);
disconnect(ev->data.fd);
}
}

if (ev->events & EPOLLERR || ev->events & EPOLLHUP) {
if (ev->events & EPOLLERR)
warn("Error in in fd: %d", ev->data.fd);
else
warn("Closing disconnected fd: %d", ev->data.fd);

epoll_leave(ep, ev->data.fd);
disconnect(ev->data.fd);
}

}
else {

if (ev->events & EPOLLIN) {
if ((cli = accept(srv, NULL, 0)) < 0) {
warn("Could not add socket");
continue;
}

epoll_join(ep, cli, EPOLLIN);
}

if (ev->events & EPOLLERR || ev->events & EPOLLHUP)
err(EX_OSERR, "Server FD has failed", ev->data.fd);

}
}

cleanup_old_events();
}

}

Here is the client:

from socket import *
import time
scks = list()

for i in range(0, 3000):
s = socket(AF_INET, SOCK_STREAM)
s.connect(("localhost", 8558))
scks.append(s)

time.sleep(600)

When running this on my local machine I get 6001 sockets using port 8558 (1 listening, 3000 client side sockets and 3000 server side sockets).

$ ss -ant | grep 8558 | wc -l
6001

When checking the number of IP connections connected on the client I get 3000.

# lsof -p$(pgrep python) | grep IPv4 | wc -l
3000

I've also tried the test with the server on a remote machine with success too.

I'd suggest you attempt to do the same.

In addition try turning off iptables completely just in case its some connection tracking quirk.
Sometimes the iptables option in /proc can help too. So try sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1.

Edit: I've done another test which produces the output you see on your side. Your problem is that you are shutting down the connection on the server side pre-emptively.

I can duplicate results similar to what you are seeing doing the following:

  • After reading some data in to my server, call shutdown(fd, SHUT_RD).
  • Do send(fd, buf, sizeof(buf)) on the server.

After doing this the following behaviours are seen.

  • On the client I get 3000 connections open in netstat/ss with ESTABLISHED.
  • In lsof output I get 2880 (nature of how I was doing shutdown) connections established.
  • The remainder of the connections lsof -i:8558 | grep -v ES are in CLOSE_WAIT.

This only happens on a half-shutdown connection.

As such I suspect this is a bug in your client or server program. Either you are sending something to the server which the server objects to, or the server is invalidly closing connections down for some reason.

You need to confirm that what state the "anomalous" connections in (like close_wait or something else).

At this stage I also consider this a programming problem and not really something that belongs on serverfault. Without seeing the relevant portions of the source for the client/server it is not going to be possible for anybody to track down the cause of the fault. Albeit I am pretty confident this is nothing to do with the way the operating system is handling the connections.



Related Topics



Leave a reply



Submit