[PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[Vadim Kochan]

Replaced handling netlink messages by rtnl_dump_filter
from lib/libnetlink.c, also:

    - removed unused dump_fp arg;
    - added MAGIC_SEQ #define for 123456 seq id

Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
 misc/ss.c | 128 ++++++++++++++++++--------------------------------------------
 1 file changed, 36 insertions(+), 92 deletions(-)

diff --git a/misc/ss.c b/misc/ss.c
index a99294d..1c0ece2 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -41,6 +41,8 @@
 #include <linux/packet_diag.h>
 #include <linux/netlink_diag.h>
 
+#define MAGIC_SEQ 123456
+
 #define DIAG_REQUEST(_req, _r)						    \
 	struct {							    \
 		struct nlmsghdr nlh;					    \
@@ -49,7 +51,7 @@
 		.nlh = {						    \
 			.nlmsg_type = SOCK_DIAG_BY_FAMILY,		    \
 			.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST,\
-			.nlmsg_seq = 123456,				    \
+			.nlmsg_seq = MAGIC_SEQ,				    \
 			.nlmsg_len = sizeof(_req),			    \
 		},							    \
 	}
@@ -1777,7 +1779,7 @@ static int tcpdiag_send(int fd, int protocol, struct filter *f)
 		req.nlh.nlmsg_type = DCCPDIAG_GETSOCK;
 	req.nlh.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST;
 	req.nlh.nlmsg_pid = 0;
-	req.nlh.nlmsg_seq = 123456;
+	req.nlh.nlmsg_seq = MAGIC_SEQ;
 	memset(&req.r, 0, sizeof(req.r));
 	req.r.idiag_family = AF_INET;
 	req.r.idiag_states = f->states;
@@ -1937,7 +1939,7 @@ again:
 			struct inet_diag_msg *r = NLMSG_DATA(h);
 
 			if (/*h->nlmsg_pid != rth->local.nl_pid ||*/
-			    h->nlmsg_seq != 123456)
+			    h->nlmsg_seq != MAGIC_SEQ)
 				goto skip_it;
 
 			if (h->nlmsg_type == NLMSG_DONE)
@@ -2422,8 +2424,10 @@ static void unix_list_print(struct unixstat *list, struct filter *f)
 	}
 }
 
-static int unix_show_sock(struct nlmsghdr *nlh, struct filter *f)
+static int unix_show_sock(const struct sockaddr_nl *addr, struct nlmsghdr *nlh,
+		void *arg)
 {
+	struct filter *f = (struct filter *)arg;
 	struct unix_diag_msg *r = NLMSG_DATA(nlh);
 	struct rtattr *tb[UNIX_DIAG_MAX+1];
 	char name[128];
@@ -2512,90 +2516,30 @@ static int unix_show_sock(struct nlmsghdr *nlh, struct filter *f)
 	return 0;
 }
 
-static int handle_netlink_request(struct filter *f, FILE *dump_fp,
-				  struct nlmsghdr *req, size_t size,
-				  int (* show_one_sock)(struct nlmsghdr *nlh, struct filter *f))
+static int handle_netlink_request(struct filter *f, struct nlmsghdr *req,
+		size_t size, rtnl_filter_t show_one_sock)
 {
-	int fd;
-	char	buf[16384];
+	int ret = -1;
+	struct rtnl_handle rth;
 
-	if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_INET_DIAG)) < 0)
+	if (rtnl_open_byproto(&rth, 0, NETLINK_INET_DIAG))
 		return -1;
 
-	if (send(fd, req, size, 0) < 0) {
-		close(fd);
-		return -1;
-	}
+	rth.dump = MAGIC_SEQ;
 
-	while (1) {
-		ssize_t status;
-		struct nlmsghdr *h;
-		struct sockaddr_nl nladdr;
-		socklen_t slen = sizeof(nladdr);
+	if (rtnl_send(&rth, req, size) < 0)
+		goto Exit;
 
-		status = recvfrom(fd, buf, sizeof(buf), 0,
-				  (struct sockaddr *) &nladdr, &slen);
-		if (status < 0) {
-			if (errno == EINTR)
-				continue;
-			perror("OVERRUN");
-			continue;
-		}
-		if (status == 0) {
-			fprintf(stderr, "EOF on netlink\n");
-			goto close_it;
-		}
-
-		if (dump_fp)
-			fwrite(buf, 1, NLMSG_ALIGN(status), dump_fp);
-
-		h = (struct nlmsghdr*)buf;
-		while (NLMSG_OK(h, status)) {
-			int err;
+	if (rtnl_dump_filter(&rth, show_one_sock, f))
+		goto Exit;
 
-			if (/*h->nlmsg_pid != rth->local.nl_pid ||*/
-			    h->nlmsg_seq != 123456)
-				goto skip_it;
-
-			if (h->nlmsg_type == NLMSG_DONE)
-				goto close_it;
-
-			if (h->nlmsg_type == NLMSG_ERROR) {
-				struct nlmsgerr *err = (struct nlmsgerr*)NLMSG_DATA(h);
-				if (h->nlmsg_len < NLMSG_LENGTH(sizeof(struct nlmsgerr))) {
-					fprintf(stderr, "ERROR truncated\n");
-				} else {
-					errno = -err->error;
-					if (errno != ENOENT)
-						fprintf(stderr, "DIAG answers %d\n", errno);
-				}
-				close(fd);
-				return -1;
-			}
-			if (!dump_fp) {
-				err = show_one_sock(h, f);
-				if (err < 0) {
-					close(fd);
-					return err;
-				}
-			}
-
-skip_it:
-			h = NLMSG_NEXT(h, status);
-		}
-
-		if (status) {
-			fprintf(stderr, "!!!Remnant of size %zd\n", status);
-			exit(1);
-		}
-	}
-
-close_it:
-	close(fd);
-	return 0;
+	ret = 0;
+Exit:
+	rtnl_close(&rth);
+	return ret;
 }
 
-static int unix_show_netlink(struct filter *f, FILE *dump_fp)
+static int unix_show_netlink(struct filter *f)
 {
 	DIAG_REQUEST(req, struct unix_diag_req r);
 
@@ -2605,8 +2549,7 @@ static int unix_show_netlink(struct filter *f, FILE *dump_fp)
 	if (show_mem)
 		req.r.udiag_show |= UDIAG_SHOW_MEMINFO;
 
-	return handle_netlink_request(f, dump_fp, &req.nlh,
-					sizeof(req), unix_show_sock);
+	return handle_netlink_request(f, &req.nlh, sizeof(req), unix_show_sock);
 }
 
 static int unix_show(struct filter *f)
@@ -2619,7 +2562,7 @@ static int unix_show(struct filter *f)
 	struct unixstat *list = NULL;
 
 	if (!getenv("PROC_NET_UNIX") && !getenv("PROC_ROOT")
-	    && unix_show_netlink(f, NULL) == 0)
+	    && unix_show_netlink(f) == 0)
 		return 0;
 
 	if ((fp = net_unix_open()) == NULL)
@@ -2693,7 +2636,8 @@ static int unix_show(struct filter *f)
 	return 0;
 }
 
-static int packet_show_sock(struct nlmsghdr *nlh, struct filter *f)
+static int packet_show_sock(const struct sockaddr_nl *addr,
+		struct nlmsghdr *nlh, void *arg)
 {
 	struct packet_diag_msg *r = NLMSG_DATA(nlh);
 	struct rtattr *tb[PACKET_DIAG_MAX+1];
@@ -2786,15 +2730,14 @@ static int packet_show_sock(struct nlmsghdr *nlh, struct filter *f)
 	return 0;
 }
 
-static int packet_show_netlink(struct filter *f, FILE *dump_fp)
+static int packet_show_netlink(struct filter *f)
 {
 	DIAG_REQUEST(req, struct packet_diag_req r);
 
 	req.r.sdiag_family = AF_PACKET;
 	req.r.pdiag_show = PACKET_SHOW_INFO | PACKET_SHOW_MEMINFO | PACKET_SHOW_FILTER;
 
-	return handle_netlink_request(f, dump_fp, &req.nlh, sizeof(req),
-			packet_show_sock);
+	return handle_netlink_request(f, &req.nlh, sizeof(req), packet_show_sock);
 }
 
 
@@ -2811,7 +2754,7 @@ static int packet_show(struct filter *f)
 	int ino;
 	unsigned long long sk;
 
-	if (packet_show_netlink(f, NULL) == 0)
+	if (packet_show_netlink(f) == 0)
 		return 0;
 
 	if ((fp = net_packet_open()) == NULL)
@@ -2982,8 +2925,10 @@ static void netlink_show_one(struct filter *f,
 	return;
 }
 
-static int netlink_show_sock(struct nlmsghdr *nlh, struct filter *f)
+static int netlink_show_sock(const struct sockaddr_nl *addr,
+		struct nlmsghdr *nlh, void *arg)
 {
+	struct filter *f = (struct filter *)arg;
 	struct netlink_diag_msg *r = NLMSG_DATA(nlh);
 	struct rtattr *tb[NETLINK_DIAG_MAX+1];
 	int rq = 0, wq = 0;
@@ -3016,7 +2961,7 @@ static int netlink_show_sock(struct nlmsghdr *nlh, struct filter *f)
 	return 0;
 }
 
-static int netlink_show_netlink(struct filter *f, FILE *dump_fp)
+static int netlink_show_netlink(struct filter *f)
 {
 	DIAG_REQUEST(req, struct netlink_diag_req r);
 
@@ -3024,8 +2969,7 @@ static int netlink_show_netlink(struct filter *f, FILE *dump_fp)
 	req.r.sdiag_protocol = NDIAG_PROTO_ALL;
 	req.r.ndiag_show = NDIAG_SHOW_GROUPS | NDIAG_SHOW_MEMINFO;
 
-	return handle_netlink_request(f, dump_fp, &req.nlh,
-					sizeof(req), netlink_show_sock);
+	return handle_netlink_request(f, &req.nlh, sizeof(req), netlink_show_sock);
 }
 
 static int netlink_show(struct filter *f)
@@ -3038,7 +2982,7 @@ static int netlink_show(struct filter *f)
 	unsigned long long sk, cb;
 
 	if (!getenv("PROC_NET_NETLINK") && !getenv("PROC_ROOT") &&
-		netlink_show_netlink(f, NULL) == 0)
+		netlink_show_netlink(f) == 0)
 		return 0;
 
 	if ((fp = net_netlink_open()) == NULL)
-- 
2.1.3

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[vadim4j]

On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> On Tue,  2 Dec 2014 16:53:04 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
> 
> > Replaced handling netlink messages by rtnl_dump_filter
> > from lib/libnetlink.c, also:
> > 
> >     - removed unused dump_fp arg;
> >     - added MAGIC_SEQ #define for 123456 seq id
> > 
> > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> 
> This doesn't work correctly.
> 
> Simple test
>   $ misc/ss >/dev/null
> RTNETLINK answers: No such file or directory
> RTNETLINK answers: No such file or directory
> RTNETLINK answers: No such file or directory

Just tried, I did not get such errors.

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[Stephen Hemminger]

On Tue,  2 Dec 2014 16:53:04 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:

> Replaced handling netlink messages by rtnl_dump_filter
> from lib/libnetlink.c, also:
> 
>     - removed unused dump_fp arg;
>     - added MAGIC_SEQ #define for 123456 seq id
> 
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>

This doesn't work correctly.

Simple test
  $ misc/ss >/dev/null
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory
RTNETLINK answers: No such file or directory

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[vadim4j]

On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
> On Wed, 3 Dec 2014 19:20:10 +0200
> vadim4j@gmail.com wrote:
> 
> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > > On Tue,  2 Dec 2014 16:53:04 +0200
> > > Vadim Kochan <vadim4j@gmail.com> wrote:
> > > 
> > > > Replaced handling netlink messages by rtnl_dump_filter
> > > > from lib/libnetlink.c, also:
> > > > 
> > > >     - removed unused dump_fp arg;
> > > >     - added MAGIC_SEQ #define for 123456 seq id
> > > > 
> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> > > 
> > > This doesn't work correctly.
> > > 
> > > Simple test
> > >   $ misc/ss >/dev/null
> > > RTNETLINK answers: No such file or directory
> > > RTNETLINK answers: No such file or directory
> > > RTNETLINK answers: No such file or directory
> > 
> > Just tried, I did not get such errors.
> 
> I have OpenVPN running.

Hm, it is reproduced only with this patch ?
If so I will try to setup OpenVPN ... can't imagine how it can be
related ...

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[Stephen Hemminger]

On Wed, 3 Dec 2014 19:20:10 +0200
vadim4j@gmail.com wrote:

> On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > On Tue,  2 Dec 2014 16:53:04 +0200
> > Vadim Kochan <vadim4j@gmail.com> wrote:
> > 
> > > Replaced handling netlink messages by rtnl_dump_filter
> > > from lib/libnetlink.c, also:
> > > 
> > >     - removed unused dump_fp arg;
> > >     - added MAGIC_SEQ #define for 123456 seq id
> > > 
> > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> > 
> > This doesn't work correctly.
> > 
> > Simple test
> >   $ misc/ss >/dev/null
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
> > RTNETLINK answers: No such file or directory
> 
> Just tried, I did not get such errors.

I have OpenVPN running.

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[Vadim Kochan]

I established some simple OpenVPN connection (at least by the logs and
ss I see that peer is connected), but
I dont get any errors with ss.

So can you please provide some more info how did you tested this patch
? I am surprised that this is caused only
by these changes ...

On Wed, Dec 3, 2014 at 7:45 PM,  <vadim4j@gmail.com> wrote:
> On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
>> On Wed, 3 Dec 2014 19:20:10 +0200
>> vadim4j@gmail.com wrote:
>>
>> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
>> > > On Tue,  2 Dec 2014 16:53:04 +0200
>> > > Vadim Kochan <vadim4j@gmail.com> wrote:
>> > >
>> > > > Replaced handling netlink messages by rtnl_dump_filter
>> > > > from lib/libnetlink.c, also:
>> > > >
>> > > >     - removed unused dump_fp arg;
>> > > >     - added MAGIC_SEQ #define for 123456 seq id
>> > > >
>> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>> > >
>> > > This doesn't work correctly.
>> > >
>> > > Simple test
>> > >   $ misc/ss >/dev/null
>> > > RTNETLINK answers: No such file or directory
>> > > RTNETLINK answers: No such file or directory
>> > > RTNETLINK answers: No such file or directory
>> >
>> > Just tried, I did not get such errors.
>>
>> I have OpenVPN running.
>
> Hm, it is reproduced only with this patch ?
> If so I will try to setup OpenVPN ... can't imagine how it can be
> related ...

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[Stephen Hemminger]

On Thu, 4 Dec 2014 00:15:54 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:

> I established some simple OpenVPN connection (at least by the logs and
> ss I see that peer is connected), but
> I dont get any errors with ss.
> 
> So can you please provide some more info how did you tested this patch
> ? I am surprised that this is caused only
> by these changes ...
> 
> On Wed, Dec 3, 2014 at 7:45 PM,  <vadim4j@gmail.com> wrote:
> > On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
> >> On Wed, 3 Dec 2014 19:20:10 +0200
> >> vadim4j@gmail.com wrote:
> >>
> >> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> >> > > On Tue,  2 Dec 2014 16:53:04 +0200
> >> > > Vadim Kochan <vadim4j@gmail.com> wrote:
> >> > >
> >> > > > Replaced handling netlink messages by rtnl_dump_filter
> >> > > > from lib/libnetlink.c, also:
> >> > > >
> >> > > >     - removed unused dump_fp arg;
> >> > > >     - added MAGIC_SEQ #define for 123456 seq id
> >> > > >
> >> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> >> > >
> >> > > This doesn't work correctly.
> >> > >
> >> > > Simple test
> >> > >   $ misc/ss >/dev/null
> >> > > RTNETLINK answers: No such file or directory
> >> > > RTNETLINK answers: No such file or directory
> >> > > RTNETLINK answers: No such file or directory
> >> >
> >> > Just tried, I did not get such errors.
> >>
> >> I have OpenVPN running.
> >
> > Hm, it is reproduced only with this patch ?
> > If so I will try to setup OpenVPN ... can't imagine how it can be
> > related ...

I am running on 3.17.4 kernel if that helps.

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[vadim4j]

On Wed, Dec 03, 2014 at 03:07:48PM -0800, Stephen Hemminger wrote:
> On Thu, 4 Dec 2014 00:15:54 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
> 
> > I established some simple OpenVPN connection (at least by the logs and
> > ss I see that peer is connected), but
> > I dont get any errors with ss.
> > 
> > So can you please provide some more info how did you tested this patch
> > ? I am surprised that this is caused only
> > by these changes ...
> > 
> > On Wed, Dec 3, 2014 at 7:45 PM,  <vadim4j@gmail.com> wrote:
> > > On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
> > >> On Wed, 3 Dec 2014 19:20:10 +0200
> > >> vadim4j@gmail.com wrote:
> > >>
> > >> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
> > >> > > On Tue,  2 Dec 2014 16:53:04 +0200
> > >> > > Vadim Kochan <vadim4j@gmail.com> wrote:
> > >> > >
> > >> > > > Replaced handling netlink messages by rtnl_dump_filter
> > >> > > > from lib/libnetlink.c, also:
> > >> > > >
> > >> > > >     - removed unused dump_fp arg;
> > >> > > >     - added MAGIC_SEQ #define for 123456 seq id
> > >> > > >
> > >> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> > >> > >
> > >> > > This doesn't work correctly.
> > >> > >
> > >> > > Simple test
> > >> > >   $ misc/ss >/dev/null
> > >> > > RTNETLINK answers: No such file or directory
> > >> > > RTNETLINK answers: No such file or directory
> > >> > > RTNETLINK answers: No such file or directory
> > >> >
> > >> > Just tried, I did not get such errors.
> > >>
> > >> I have OpenVPN running.
> > >
> > > Hm, it is reproduced only with this patch ?
> > > If so I will try to setup OpenVPN ... can't imagine how it can be
> > > related ...
> 
> I am running on 3.17.4 kernel if that helps.

OK, thank you!

I see a reason why it was caused by this patch. So the difference is in
the way how the libnetlink/rtnl_* and original ss.c handles the
NLMSG_ERROR, ss.c netlink handler checks errno ENOENT (No such file or directory)
and silently closes file end returns -1, but rtnl_* prints the error message.

Meanwhile I dont know the real reason why ENOENT error is happaned, may
be it is OK in context of diagnostic messages. But I grepped over the
commits and found that this ENOENT checking was added by Eric in:

    commit a3fd8e58c1787af186f5c4b234ff974544f840b6
    Author: Eric Dumazet <eric.dumazet@gmail.com>
    Date:   Mon Jan 30 17:05:45 2012 +0100

    ss: should support CONFIG_INET_UDP_DIAG=n kernels

    ss -x currently fails if CONFIG_INET_UDP_DIAG=n or old kernels

    Also close file descriptors while we are at it.

    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Pavel Emelyanov <xemul@parallels.com>

Re: [PATCH iproute2] ss: Use rtnl_dump_filter in handle_netlink_request

[Vadim Kochan]

Ofcourse I think it is possible to add checking if protocol ==
NETLINK_INET_DIAG protocol
and dont print the error message in lib/netlink.c  if errno == ENOENT,
but I am not sure if you will like such approach ...

On Thu, Dec 4, 2014 at 1:28 AM,  <vadim4j@gmail.com> wrote:
> On Wed, Dec 03, 2014 at 03:07:48PM -0800, Stephen Hemminger wrote:
>> On Thu, 4 Dec 2014 00:15:54 +0200
>> Vadim Kochan <vadim4j@gmail.com> wrote:
>>
>> > I established some simple OpenVPN connection (at least by the logs and
>> > ss I see that peer is connected), but
>> > I dont get any errors with ss.
>> >
>> > So can you please provide some more info how did you tested this patch
>> > ? I am surprised that this is caused only
>> > by these changes ...
>> >
>> > On Wed, Dec 3, 2014 at 7:45 PM,  <vadim4j@gmail.com> wrote:
>> > > On Wed, Dec 03, 2014 at 09:51:23AM -0800, Stephen Hemminger wrote:
>> > >> On Wed, 3 Dec 2014 19:20:10 +0200
>> > >> vadim4j@gmail.com wrote:
>> > >>
>> > >> > On Wed, Dec 03, 2014 at 09:21:29AM -0800, Stephen Hemminger wrote:
>> > >> > > On Tue,  2 Dec 2014 16:53:04 +0200
>> > >> > > Vadim Kochan <vadim4j@gmail.com> wrote:
>> > >> > >
>> > >> > > > Replaced handling netlink messages by rtnl_dump_filter
>> > >> > > > from lib/libnetlink.c, also:
>> > >> > > >
>> > >> > > >     - removed unused dump_fp arg;
>> > >> > > >     - added MAGIC_SEQ #define for 123456 seq id
>> > >> > > >
>> > >> > > > Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>> > >> > >
>> > >> > > This doesn't work correctly.
>> > >> > >
>> > >> > > Simple test
>> > >> > >   $ misc/ss >/dev/null
>> > >> > > RTNETLINK answers: No such file or directory
>> > >> > > RTNETLINK answers: No such file or directory
>> > >> > > RTNETLINK answers: No such file or directory
>> > >> >
>> > >> > Just tried, I did not get such errors.
>> > >>
>> > >> I have OpenVPN running.
>> > >
>> > > Hm, it is reproduced only with this patch ?
>> > > If so I will try to setup OpenVPN ... can't imagine how it can be
>> > > related ...
>>
>> I am running on 3.17.4 kernel if that helps.
>
> OK, thank you!
>
> I see a reason why it was caused by this patch. So the difference is in
> the way how the libnetlink/rtnl_* and original ss.c handles the
> NLMSG_ERROR, ss.c netlink handler checks errno ENOENT (No such file or directory)
> and silently closes file end returns -1, but rtnl_* prints the error message.
>
> Meanwhile I dont know the real reason why ENOENT error is happaned, may
> be it is OK in context of diagnostic messages. But I grepped over the
> commits and found that this ENOENT checking was added by Eric in:
>
>     commit a3fd8e58c1787af186f5c4b234ff974544f840b6
>     Author: Eric Dumazet <eric.dumazet@gmail.com>
>     Date:   Mon Jan 30 17:05:45 2012 +0100
>
>     ss: should support CONFIG_INET_UDP_DIAG=n kernels
>
>     ss -x currently fails if CONFIG_INET_UDP_DIAG=n or old kernels
>
>     Also close file descriptors while we are at it.
>
>     Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>     Cc: Pavel Emelyanov <xemul@parallels.com>