From d536fc4ddd79157c35fcdcfec1ca0e8cdb8a13eb Mon Sep 17 00:00:00 2001 From: Tobias Klauser Date: Sun, 26 May 2013 16:17:27 +0200 Subject: man: netsniff-ng: Reword a few sentences Make the 2nd section of the description a bit easier to read by splitting and rearranging sentences. Also add a few missing punctuations or make it more consistent repectively. Signed-off-by: Tobias Klauser --- netsniff-ng.8 | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) (limited to 'netsniff-ng.8') diff --git a/netsniff-ng.8 b/netsniff-ng.8 index 5bdc6d0..bc99123 100644 --- a/netsniff-ng.8 +++ b/netsniff-ng.8 @@ -21,18 +21,17 @@ started working on netsniff-ng, the pcap(3) library did not use this zero-copy facility. .PP netsniff-ng is Linux specific, meaning there is no support for other -operating systems, thus we can keep the code footprint quite minimal and to +operating systems. Therefore we can keep the code footprint quite minimal and to the point. Linux packet(7) sockets and its RX_RING and TX_RING interfaces -bypass the normal packet processing path through the networking stack. Thus, -this is the fastest one can get out of the box in terms of capturing or -transmission performance from user space, without having to load unsupported -or non-mainline third-party kernel modules. We explicitly refuse to build -netsniff-ng on top of ntop/PF_RING. Not because we do not like it (we do find -it interesting), but because of the fact that it is not part of the mainline -kernel. Therefore, the ntop project has to maintain and sync out-of-tree drivers -to adapt them to their DNA. Eventually, we went for untainted Linux kernel, -since its code has a higher rate of review, maintenance, security and bug -fixes. +bypass the normal packet processing path through the networking stack. +This is the fastest capturing or transmission performance one can get from user +space out of the box, without having to load unsupported or non-mainline +third-party kernel modules. We explicitly refuse to build netsniff-ng on top of +ntop/PF_RING. Not because we do not like it (we do find it interesting), but +because of the fact that it is not part of the mainline kernel. Therefore, the +ntop project has to maintain and sync out-of-tree drivers to adapt them to their +DNA. Eventually, we went for untainted Linux kernel, since its code has a higher +rate of review, maintenance, security and bug fixes. .PP netsniff-ng also supports early packet filtering in the kernel. It has support for low-level and high-level packet filters that are translated into Berkeley @@ -46,7 +45,7 @@ intervals, thus, making it a useful backend tool for subsequent traffic analysis. .PP netsniff-ng itself also supports analysis, replaying, and dumping of raw 802.11 -frames. For online or offline analysis, netsniff-ng has a built in packet +frames. For online or offline analysis, netsniff-ng has a built-in packet dissector for the current 802.3 (Ethernet), 802.11* (WLAN), ARP, MPLS, 802.1Q (VLAN), 802.1QinQ, LLDP, IPv4, IPv6, ICMPv4, ICMPv6, IGMP, TCP and UDP, including GeoIP location analysis. Since netsniff-ng does not establish any @@ -66,7 +65,7 @@ eventually. .SH OPTIONS .PP .SS -i , -d , --in , --dev -Defines an input device, that can either be a networking device, a pcap file +Defines an input device. This can either be a networking device, a pcap file or stdin (\[lq]-\[rq]). In case of a pcap file, the pcap type (\[lq]-D\[rq] option) is determined automatically by the pcap file magic. In case of stdin, it is assumed that the input stream is a pcap file. @@ -170,7 +169,7 @@ to disc. .PP .SS -S , --ring-size Manually define the RX_RING resp. TX_RING size in \[lq]KiB/MiB/GiB\[rq]. By -default the size is determined based on the network connectivity rate. +default, the size is determined based on the network connectivity rate. .PP .SS -k , --kernel-pull Manually define the interval in micro-seconds where the kernel should be triggered -- cgit v1.2.3-54-g00ecf