From: Daniel Borkmann <dborkman@redhat.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: davem@davemloft.net, tgraf@suug.ch, netdev@vger.kernel.org
Subject: Re: [RFC PATCH net-next 3/3] packet: nlmon: virtual netlink monitoring device for packet sockets
Date: Thu, 20 Jun 2013 19:09:54 +0200 [thread overview]
Message-ID: <51C33762.3000404@redhat.com> (raw)
In-Reply-To: <20130620084653.4d11dd3e@nehalam.linuxnetplumber.net>
On 06/20/2013 05:46 PM, Stephen Hemminger wrote:
> On Thu, 20 Jun 2013 10:07:10 +0200
> Daniel Borkmann <dborkman@redhat.com> wrote:
>
>> On 06/19/2013 08:59 PM, Stephen Hemminger wrote:
>>> On Wed, 19 Jun 2013 20:04:46 +0200
>>> Daniel Borkmann <dborkman@redhat.com> wrote:
>>>
>>>> Currently, there is no good possibility to debug netlink traffic that
>>>> is being exchanged between kernel and user space. Therefore, this patch
>>>> implements a netlink virtual device, so that netlink messages will be
>>>> made visible to PF_PACKET sockets. Once there was an approach with a
>>>> similar idea [1], but it got forgotten somehow.
>>>
>>> ip monitor all
>>
>> Well, but this is only restricted to debugging rtnl and there are many other
>> subsystems using netlink. Also, it's not about low-level debugging netlink
>> in general from what I see from the code. So it's not really the same resp.
>> comparable to each other.
>
> I was thinking that having a more general monitor is great, and maybe you
> could reuse the similar concepts that already exist. I like the device idea
> or maybe teaching libpcap how to handle another input source like Patrick's
> mmap netlink would be better.
Ahh, okay, understood.
I think the device idea might be the cleanest solution. We have packet sockets
and they do exactly what we want and expect from them, they have all the features etc,
and user space would not even need to implement code. Thus adding more and more
functionality into af_netlink would be a bigger surgery and further bloat it up
with duplicate code, imho. By taking the approach with what I've proposed, we
have a clean segregation of functionality (as: packet sockets vs. netlink sockets),
thus keeping it simple and stupid, and not too complex.
prev parent reply other threads:[~2013-06-20 17:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 18:04 [RFC PATCH net-next 0/3] Virtual netlink device for packet sockets Daniel Borkmann
2013-06-19 18:04 ` [RFC PATCH net-next 1/3] net: if_arp: add ARPHRD_NETLINK type Daniel Borkmann
2013-06-19 18:04 ` [RFC PATCH net-next 2/3] net: netlink: add registration/unregistration of virtual tap devices Daniel Borkmann
2013-06-19 18:04 ` [RFC PATCH net-next 3/3] packet: nlmon: virtual netlink monitoring device for packet sockets Daniel Borkmann
2013-06-19 18:59 ` Stephen Hemminger
2013-06-20 8:07 ` Daniel Borkmann
2013-06-20 15:46 ` Stephen Hemminger
2013-06-20 17:09 ` Daniel Borkmann [this message]
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=51C33762.3000404@redhat.com \
--to=dborkman@redhat.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=tgraf@suug.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).