summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJon Schipp <jonschipp@gmail.com>2013-05-21 17:03:08 -0700
committerDaniel Borkmann <dborkman@redhat.com>2013-05-22 10:07:49 +0200
commit13fa215edf3d5aff0b0e736163a24ed0eac8ee1e (patch)
tree2e7cfb54e2e4f9f13996a3a336405400fa1f89aa
parentf8cddced1fdc246fa6432c648b887c32a1322647 (diff)
man: netsniff-ng: edits to the netsniff-ng man page
Various edits all over. Signed-off-by: Jon Schipp <jonschipp@gmail.com> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
-rw-r--r--netsniff-ng.839
1 files changed, 20 insertions, 19 deletions
diff --git a/netsniff-ng.8 b/netsniff-ng.8
index 573a360..395382f 100644
--- a/netsniff-ng.8
+++ b/netsniff-ng.8
@@ -20,7 +20,7 @@ copy and system call overhead between kernel and user address space. When we
started working on netsniff-ng, the pcap(3) library did not use this
zero-copy facility.
.PP
-netsniff-ng is Linux specific only, meaning there is no support for other
+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
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,
@@ -45,8 +45,8 @@ netsniff-ng is also able to rotate pcap files based on data size or time
intervals, thus, making it a useful backend tool for subsequent traffic
analysis.
.PP
-netsniff-ng itself also supports analysis, dumping or replay of raw 802.11
-frames. For online or offline analysis netsniff-ng has a built-in packet
+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
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
@@ -89,10 +89,10 @@ values for type are \[lq]host\[rq] (to us), \[lq]broadcast\[rq] (to all), \[lq]m
group), \[lq]others\[rq] (promiscuous mode) or \[lq]outgoing\[rq] (from us).
.PP
.SS -F, --interval <size|time>
-If the output device is a folder, with \[lq]-F\[rq] it is possible to define the pcap
+If the output device is a folder, with \[lq]-F\[rq], it is possible to define the pcap
file rotation interval either in terms of size or time. Thus, when the interval
limit has been reached, a new pcap file will be started. As size parameter, the
-following values are accepted \[lq]<num>KiB/MiB/GiB\[rq] while as a time parameter
+following values are accepted \[lq]<num>KiB/MiB/GiB\[rq]; As time parameter,
it can be \[lq]<num>s/sec/min/hrs\[rq].
.PP
.SS -J, --jumbo-support
@@ -116,7 +116,8 @@ Otherwise, a number given as an unsigned integer will limit processing.
.SS -P <name>, --prefix <name>
When dumping pcap files into a folder, a file name prefix can be defined with
this option. If not otherwise specified, the default prefix is \[lq]dump-\[rq]
-followed by a Unix timestamp.
+followed by a Unix timestamp. Use \[lq]--prefex ""\[rq] to set filename as seconds
+since the Unix Epoch e.g. 1369179203.pcap
.PP
.SS -T <pcap-magic>, --magic <pcap-magic>
Specify a pcap type for storage. Different pcap types with their various meta
@@ -144,7 +145,7 @@ promiscuous mode is turned on.
.SS -A, --no-sock-mem
On startup and shutdown, netsniff-ng tries to increase socket read and
write buffers if appropriate. This option will prevent netsniff-ng from doing
-that.
+so.
.PP
.SS -m, --mmap
Use mmap(2) as pcap file I/O. This is the default when replaying pcap files.
@@ -170,7 +171,7 @@ manually be prolonged, for instance.
.SS -b <cpu>, --bind-cpu <cpu>
Pin netsniff-ng to a specific CPU and also pin resp. migrate the NIC's IRQ
CPU affinity to this CPU. This option should be preferred in combination with
-\[lq]-s\[rq] in case a middle till high packet rate is expected.
+\[lq]-s\[rq] in case a middle to high packet rate is expected.
.PP
.SS -u <uid>, --user <uid> resp. -g <gid>, --group <gid>
After ring setup drop privileges to a non-root user/group combination.
@@ -208,7 +209,7 @@ databases (to bypass their traffic limit policy), different hosts or IP
addresses can be placed into geoip.conf, separated by a newline.
.PP
.SS -V, --verbose
-Be more verbose during startup, that is to say, show detailed ring setup information.
+Be more verbose during startup i.e. show detailed ring setup information.
.PP
.SS -v, --version
Show version information and exit.
@@ -240,7 +241,7 @@ scatter-gather I/O.
Replay the pcap file dump.pcap which is read through mmap(2) I/O and send
the packets out via the eth0 networking device. Do not dissect and print the
content to the terminal and pin the process and NIC IRQ affinity to CPU 0.
-Also trigger the kernel every 1000us to traverse the TX_RING instead of every
+Also, trigger the kernel every 1000us to traverse the TX_RING instead of every
10us. Note that the pcap magic type is detected automatically from the pcap
file header.
.PP
@@ -289,8 +290,8 @@ file to stdout.
.PP
.SH CONFIG FILES
.PP
-Under /etc/netsniff-ng/ there are stored the following files that are used
-by netsniff-ng and can be extended if so wished:
+Files under /etc/netsniff-ng/ can be modified to extend netsniff-ng's
+functionality:
.PP
* oui.conf - OUI/MAC vendor database
* ether.conf - Ethernet type descriptions
@@ -466,13 +467,13 @@ uses tshark, all headers are visible, but netsniff-ng removes 802.1Q
headers. Is that normal behavior?
.PP
Yes and no. The way VLAN headers are handled in PF_PACKET sockets by the
-kernel is somewhat \[lq]problematic\[rq] [1]. The problem in the Linux kernel is that
-some drivers already handle VLANs, others not. Those who handle it can have
-different implementations, such as hardware acceleration and so on. So in some
-cases the VLAN tag is even stripped before entering the protocol stack, in
-some cases probably not. The bottom line is that a "hack" was introduced in
-PF_PACKET so that a VLAN ID is visible in some helper data structure that is
-accessible from the RX_RING.
+kernel is somewhat \[lq]problematic\[rq] [1]. The problem in the Linux kernel
+is that some drivers already handle VLANs, others do not. Those who handle it
+can have different implementations, such as hardware acceleration and so on.
+So in some cases the VLAN tag is even stripped before entering the protocol
+stack, in some cases probably not. The bottom line is that a "hack" was
+introduced in PF_PACKET so that a VLAN ID is visible in some helper data
+structure that is accessible from the RX_RING.
.PP
Then it gets really messy in the user space to artificially put the VLAN
header back into the right place. Not to mention the resulting performance