> It might be, that arranging a "DEBUG NETLINK socket" to direct to it,
> when enabled, copies of all netlink messages (better to exclude a
> really bulk traffic like netfilter packet log)
That emphasizes the need to know the identity of the source emitting the
packet. I see in RFC3549 :
" Process ID (PID): 32 bits
The PID of the process sending the message. The PID is used by the
kernel to multiplex to the correct sockets. A PID of zero is used
when sending messages to user space from the kernel."
However what is actually implemented is the opposite. Anyone willing to
comment that ?
Having the source pid could have be cool for filtering purpose.
> , will be a more
> "standardized" solution. Thus, the hook in netlink_sendmsg will just
> send a one more copy of a unicast and include the DEBUG_NETLINK socket
> to a multicast.
I'm not sure I get it. What do you mean by "include DEBUG_NETLINK
socket to a multicast" ? It looks like a cycling problem using another
netlink socket to transport netlink traffic.
Redirecting the traffic to a net device is interesting in a way because
you already have userspace tools (sniffers), and just need to add
netlink protocol dissectors to them.
With the ability to send to an interface, you could imagine doing stuff
like sending netlink messages over a network. Looks like one of netlink2
features...
> Sniffing kernel packets via such netlink sockets actually may be
> extended for the unix-domain traffic as well.
sure, that may be extended to unix sockets without too much
difficulties. What I wonder is if people are really interested in such
a debug feature.
Cheers.
--
Mathieu Geli
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
