lkml.org 
[lkml]   [2015]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] net: Linn Ethernet Packet Sniffer driver
Hi Daniel,

On 26/01/15 10:10, Daniel Borkmann wrote:
>> Hello Daniel. Thank you for your feedback.
>> Packet sockets could also be used for the driver interface to
>> user space, however I think that both approaches would require the same
>> amount of maintenance. We need to maintain a protocol consisting of
>> a set of messages or commands that user space can use to communicate
>> with the driver in order to configure the H/W and retrieve results.
>> We could use packet sockets to send those messages too, but I thought
>> netlink already provides a message exchange framework that we could
>> make use of.
>
> When using packet sockets and your driver as a backend feeding them,
> users can see that there's an extra capturing/monitoring netdev present,
> all libpcap-based tools such as tcpdump et al would work out of the box
> w/o adapting any code, and as an admin you can also see what users/tools
> are making of use of the device through packet sockets. I couldn't parse
> the exact motivation from the commit message of why avoiding all this is
> better?
>
> Thanks,
> Daniel
>
>
Just wanted to clarify some implementation details for your approach.
- The driver would need to create and register two net_device instances.
One for sniffing Ethernet TX packets and one for RX.
- Would the control interface for the sniffer in that case need to be
through private socket ioctls (ie SIOCDEVPRIVATE + x ioctl ids)?
- For each ethernet packet that matches the command string the sniffer
returns some data bytes and optionally a timestamp (depending on the
command string). Would a new protocol need to be added in
<linux/if_ether.h> in order to deliver that data to user space through
a packet socket?

Thanks,
Stathis



\
 
 \ /
  Last update: 2015-01-27 12:21    [W:0.140 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site