All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Cc: Stephen Hemminger <stephen@networkplumber.org>
Subject: [RFC 2/3] ss: warn when packet socket diag is unavailable
Date: Tue, 15 Sep 2026 14:36:03 -0700	[thread overview]
Message-ID: <20260915213646.116214-3-stephen@networkplumber.org> (raw)
In-Reply-To: <20260915213646.116214-1-stephen@networkplumber.org>

Since the /proc/net/packet fallback went away, "ss -0" on a kernel
built without CONFIG_PACKET_DIAG prints a header and nothing else,
with no indication that anything went wrong.

AF_PACKET sockets are present on essentially every system, so an
empty listing reads as "no sockets" rather than "ss could not ask".
That is unlike tipc or vsock, where an empty result is unremarkable.

rtnl_dump_error() deliberately returns ENOENT and EOPNOTSUPP silently
for NETLINK_SOCK_DIAG, precisely because callers used to fall back to
/proc.  With no fallback left, report those two at the call site.
Every other netlink error already gets perror("RTNETLINK answers"),
and rtnl_open_byproto() reports its own failures, so this does not
double up.

Only the diagnostic on stderr is new; the exit status is unchanged.

netlink_show() is left alone: CONFIG_NETLINK_DIAG is genuinely
optional and "ss -A netlink" is rarely the only thing a user asked
for.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 misc/ss.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/misc/ss.c b/misc/ss.c
index 0b7ba256..7ec72c04 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -4913,7 +4913,17 @@ static int packet_show(struct filter *f)
 	if (!filter_af_get(f, AF_PACKET) || !(f->states & (1 << SS_CLOSE)))
 		return 0;
 
-	return packet_show_netlink(f);
+	if (packet_show_netlink(f)) {
+		/*
+		 * rtnl_dump_error() swallows these two silently for
+		 * NETLINK_SOCK_DIAG; anything else already perror'd.
+		 */
+		if (errno == ENOENT || errno == EOPNOTSUPP)
+			fprintf(stderr, "ss: no packet socket information available, kernel may lack CONFIG_PACKET_DIAG\n");
+		return -1;
+	}
+
+	return 0;
 }
 
 static int xdp_stats_print(struct sockstat *s, const struct filter *f)
-- 
2.53.0


  parent reply	other threads:[~2026-09-15 21:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  3:56 [PATCH iproute2 v2] ss: drop the /proc parsers for packet and netlink sockets Prabhakar Pujeri
2026-09-15 21:34 ` Stephen Hemminger
2026-09-15 21:36 ` [RFC PATCH iproute2 0/3] ss: follow-ups to the packet/netlink /proc removal Stephen Hemminger
2026-09-15 21:36   ` [RFC 1/3] ss: drop the dead /proc fallback trigger in packet_show_sock() Stephen Hemminger
2026-09-15 21:36   ` Stephen Hemminger [this message]
2026-09-15 21:36   ` [RFC 3/3] ss: restore packet_raw/packet_dgram filtering Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260915213646.116214-3-stephen@networkplumber.org \
    --to=stephen@networkplumber.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.