> I am not sure filter works, and apparently some fields are not properly > reported ? (source port for example looks wrong) > > (Note : you probably need to filter in user space, but ss should already > have support for this) Ah, good catch on the filter. It can be fixed by - if ((err = inet_show_sock(h, NULL, diag_arg->protocol)) < 0) + if ((err = inet_show_sock(h, diag_arg->f, diag_arg->protocol)) < 0) in show_one_inet_sock. I believe this worked previously because the filter determined the parameters of the netlink request, effectively causing the filtering to happen in the kernel. However, if the ssfilter defined a parameter that could not be used select sockets via the netlink request (either because it is a concept not available in the request structure or because the multicast groups have no request concept), this user space filtering parameter would be necessary. Perhaps this was an optimization to not do userspace filtering when we know we won't need it? In that case, my updated version of this patch should probably set the filter parameter of inet_diag_arg to NULL in the case of a get request and to the actual userspace filter in the case of monitoring the broadcast data.
The source port issue is a harder problem (related to the kernel patches, not this one). The point at which socket information is broadcast happens after the unhash callback of the appropriate protocol (called in sk_common_release). This process sets the source port of the socket to zero (via __inet_put_port for tcp and udp_lib_unhash for udp). If we want the source port to be returned, I believe the only options are broadcasting earlier in the destruction path (potentially missing any activity that may happen after that point) or to store the source port in an additional location for later use... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html