1NETSNIFF-NG(8) netsniff-ng toolkit NETSNIFF-NG(8)
2
6 netsniff-ng - the packet sniffing beast
7
9 netsniff-ng { [options] [filter-expression] }
10
12 netsniff-ng is a fast, minimal tool to analyze network packets, capture
13 pcap files, replay pcap files, and redirect traffic between interfaces
14 with the help of zero-copy packet(7) sockets. netsniff-ng uses both
15 Linux specific RX_RING and TX_RING interfaces to perform zero-copy.
16 This is to avoid copy and system call overhead between kernel and user
17 address space. When we started working on netsniff-ng, the pcap(3)
18 library did not use this zero-copy facility.
19 netsniff-ng is Linux specific, meaning there is no support for other
21 operating systems. Therefore we can keep the code footprint quite mini‐
22 mal and to the point. Linux packet(7) sockets and its RX_RING and
23 TX_RING interfaces bypass the normal packet processing path through the
24 networking stack. This is the fastest capturing or transmission per‐
25 formance one can get from user space out of the box, without having to
26 load unsupported or non-mainline third-party kernel modules. We explic‐
27 itly refuse to build netsniff-ng on top of ntop/PF_RING. Not because we
28 do not like it (we do find it interesting), but because of the fact
29 that it is not part of the mainline kernel. Therefore, the ntop project
30 has to maintain and sync out-of-tree drivers to adapt them to their
31 DNA. Eventually, we went for untainted Linux kernel, since its code has
32 a higher rate of review, maintenance, security and bug fixes.
33 netsniff-ng also supports early packet filtering in the kernel. It has
35 support for low-level and high-level packet filters that are translated
36 into Berkeley Packet Filter instructions.
37 netsniff-ng can capture pcap files in several different pcap formats
39 that are interoperable with other tools. The following pcap I/O methods
40 are supported for efficient to-disc capturing: scatter-gather, mmap(2),
41 read(2), and write(2). netsniff-ng is also able to rotate pcap files
42 based on data size or time intervals, thus, making it a useful backend
43 tool for subsequent traffic analysis.
44 netsniff-ng itself also supports analysis, replaying, and dumping of
46 raw 802.11 frames. For online or offline analysis, netsniff-ng has a
47 built-in packet dissector for the current 802.3 (Ethernet), 802.11*
48 (WLAN), ARP, MPLS, 802.1Q (VLAN), 802.1QinQ, LLDP, IPv4, IPv6, ICMPv4,
49 ICMPv6, IGMP, TCP and UDP, including GeoIP location analysis. Since
50 netsniff-ng does not establish any state or perform reassembly during
51 packet dissection, its memory footprint is quite low, thus, making net‐
52 sniff-ng quite efficient for offline analysis of large pcap files as
53 well.
54 Note that netsniff-ng is currently not multithreaded. However, this
56 does not prevent you from starting multiple netsniff-ng instances that
57 are pinned to different, non-overlapping CPUs and f.e. have different
58 BPF filters attached. Likely that at some point in time your harddisc
59 might become a bottleneck assuming you do not rotate such pcaps in ram
60 (and from there periodically scheduled move to slower medias). You can
61 then use mergecap(1) to transform all pcap files into a single large
62 pcap file. Thus, netsniff-ng then works multithreaded eventually.
63 netsniff-ng can also be used to debug netlink traffic.
65
67 -i <dev|pcap|->, -d <dev|pcap|->, --in <dev|pcap|->, --dev <dev|pcap|->
68 Defines an input device. This can either be a networking device,
69 a pcap file or stdin (“-”). In case of a pcap file, the pcap
70 type (-D option) is determined automatically by the pcap file
71 magic. In case of stdin, it is assumed that the input stream is
72 a pcap file. If the pcap link type is Netlink and pcap type is
73 default format (usec or nsec), then each packet will be wrapped
74 with pcap cooked header [2].
75 -o <dev|pcap|dir|cfg|->, --out <dev|pcap|dir|cfg|->
77 Defines the output device. This can either be a networking
78 device, a pcap file, a folder, a trafgen(8) configuration file
79 or stdout (“-”). If the output device is a pcap or trafgen(8)
80 configuration file, it may include a time format as defined by
81 strfime(3). If used in conjunction with the -F option, each
82 rotated file will have a unique time stamp. In the case of a
83 pcap file that should not have the default pcap type
84 (0xa1b2c3d4), the additional option -T must be provided. If a
85 directory is given, then, instead of a single pcap file, multi‐
86 ple pcap files are generated with rotation based on maximum file
87 size or a given interval (-F option). Optionally, sending the
88 SIGHUP signal to the netsniff-ng process causes a premature
89 rotation of the file. A trafgen configuration file can currently
90 only be specified if the input device is a pcap file. To specify
91 a pcap file as the output device, the file name must have
92 “.pcap” as its extension. If stdout is given as a device, then a
93 trafgen configuration will be written to stdout if the input
94 device is a pcap file, or a pcap file if the input device is a
95 networking device. If the input device is a Netlink monitor
96 device and pcap type is default (usec or nsec) then each packet
97 will be wrapped with pcap cooked header [2] to keep Netlink fam‐
98 ily number (Kuznetzov's and netsniff-ng pcap types already con‐
99 tain family number in protocol number field).
100 -C <id>, --fanout-group <id>
102 If multiple netsniff-ng instances are being started that all
103 have the same packet fanout group id, then the ingress network
104 traffic being captured is being distributed/load-balanced among
105 these group participants. This gives a much better scaling than
106 running multiple netsniff-ng processes without a fanout group
107 parameter in parallel, but only with a BPF filter attached as a
108 packet would otherwise need to be delivered to all such captur‐
109 ing processes, instead of only once to such a fanout member.
110 Naturally, each fanout member can have its own BPF filters
111 attached.
112 -K <hash|lb|cpu|rnd|roll|qm>, --fanout-type <hash|lb|cpu|rnd|roll|qm>
114 This parameter specifies the fanout discipline, in other words,
115 how the captured network traffic is dispatched to the fanout
116 group members. Options are to distribute traffic by the packet
117 hash (“hash”), in a round-robin manner (“lb”), by CPU the packet
118 arrived on (“cpu”), by random (“rnd”), by rolling over sockets
119 (“roll”) which means if one socket's queue is full, we move on
120 to the next one, or by NIC hardware queue mapping (“qm”).
121 -L <defrag|roll>, --fanout-opts <defrag|roll>
123 Defines some auxiliary fanout options to be used in addition to
124 a given fanout type. These options apply to any fanout type. In
125 case of “defrag”, the kernel is being told to defragment packets
126 before delivering to user space, and “roll” provides the same
127 roll-over option as the “roll” fanout type, so that on any dif‐
128 ferent fanout type being used (e.g. “qm”) the socket may tempo‐
129 rarily roll over to the next fanout group member in case the
130 original one's queue is full.
131 -f, --filter <bpf-file|-|expr>
133 Specifies to not dump all traffic, but to filter the network
134 packet haystack. As a filter, either a bpfc(8) compiled
135 file/stdin can be passed as a parameter or a tcpdump(1)-like
136 filter expression in quotes. For details regarding the bpf-file
137 have a look at bpfc(8), for details regarding a tcpdump(1)-like
138 filter have a look at section “filter example” or at pcap-fil‐
139 ter(7). A filter expression may also be passed to netsniff-ng
140 without option -f in case there is no subsequent option follow‐
141 ing after the command-line filter expression.
142 -t, --type <type>
144 This defines some sort of filtering mechanisms in terms of
145 addressing. Possible values for type are “host” (to us), “broad‐
146 cast” (to all), “multicast” (to group), “others” (promiscuous
147 mode) or “outgoing” (from us).
148 -F, --interval <size|time>
150 If the output device is a folder, with “-F”, it is possible to
151 define the pcap file rotation interval either in terms of size
152 or time. Thus, when the interval limit has been reached, a new
153 pcap file will be started. As size parameter, the following val‐
154 ues are accepted “<num>KiB/MiB/GiB”; As time parameter, it can
155 be “<num>s/sec/min/hrs”.
156 -J, --jumbo-support
158 By default, in pcap replay or redirect mode, netsniff-ng's ring
159 buffer frames are a fixed size of 2048 bytes. This means that if
160 you are expecting jumbo frames or even super jumbo frames to
161 pass through your network, then you need to enable support for
162 that by using this option. However, this has the disadvantage of
163 performance degradation and a bigger memory footprint for the
164 ring buffer. Note that this doesn't affect (pcap) capturing
165 mode, since tpacket in version 3 is used!
166 -R, --rfraw
168 In case the input or output networking device is a wireless
169 device, it is possible with netsniff-ng to turn this into moni‐
170 tor mode and create a mon<X> device that netsniff-ng will be
171 listening on instead of wlan<X>, for instance. This enables
172 netsniff-ng to analyze, dump, or even replay raw 802.11 frames.
173 -n <0|uint>, --num <0|uint>
175 Process a number of packets and then exit. If the number of
176 packets is 0, then this is equivalent to infinite packets resp.
177 processing until interrupted. Otherwise, a number given as an
178 unsigned integer will limit processing.
179 -O <N>, --overwrite <N>
181 A number from 0 to N-1 will be used in the file name instead of
182 a Unix timestamp. The previous file will be overwritten when
183 number wraps around. The maximum value is 2^32 - 1. Intended for
184 rotating capture files when used with options -F and -P.
185 -P <name>, --prefix <name>
187 When dumping pcap files into a folder, a file name prefix can be
188 defined with this option. If not otherwise specified, the
189 default prefix is “dump-” followed by a Unix timestamp. Use
190 “--prefex ""” to set filename as seconds since the Unix Epoch
191 e.g. 1369179203.pcap
192 -T <pcap-magic>, --magic <pcap-magic>
194 Specify a pcap type for storage. Different pcap types with their
195 various meta data capabilities are shown with option -D. If not
196 otherwise specified, the pcap-magic 0xa1b2c3d4, also known as a
197 standard tcpdump-capable pcap format, is used. Pcap files with
198 swapped endianness are also supported.
199 -D, --dump-pcap-types
201 Dump all available pcap types with their capabilities and magic
202 numbers that can be used with option “-T” to stdout and exit.
203 -B, --dump-bpf
205 If a Berkeley Packet Filter is given, for example via option
206 “-f”, then dump the BPF disassembly to stdout during ring setup.
207 This only serves for informative or verification purposes.
208 -r, --rand
210 If the input and output device are both networking devices, then
211 this option will randomize packet order in the output ring buf‐
212 fer.
213 -M, --no-promisc
215 The networking interface will not be put into promiscuous mode.
216 By default, promiscuous mode is turned on.
217 -N, --no-hwtimestamp
219 Disable taking hardware time stamps for RX packets. By default,
220 if the network device supports hardware time stamping, the hard‐
221 ware time stamps will be used when writing packets to pcap
222 files. This option disables this behavior and forces (kernel
223 based) software time stamps to be used, even if hardware time
224 stamps are available.
225 -A, --no-sock-mem
227 On startup and shutdown, netsniff-ng tries to increase socket
228 read and write buffers if appropriate. This option will prevent
229 netsniff-ng from doing so.
230 -m, --mmap
232 Use mmap(2) as pcap file I/O. This is the default when replaying
233 pcap files.
234 -G, --sg
236 Use scatter-gather as pcap file I/O. This is the default when
237 capturing pcap files.
238 -c, --clrw
240 Use slower read(2) and write(2) I/O. This is not the default
241 case anywhere, but in some situations it could be preferred as
242 it has a lower latency on write-back to disc.
243 -S <size>, --ring-size <size>
245 Manually define the RX_RING resp. TX_RING size in
246 “<num>KiB/MiB/GiB”. By default, the size is determined based on
247 the network connectivity rate.
248 -k <uint>, --kernel-pull <uint>
250 Manually define the interval in micro-seconds where the kernel
251 should be triggered to batch process the ring buffer frames. By
252 default, it is every 10us, but it can manually be prolonged, for
253 instance.
254 -b <cpu>, --bind-cpu <cpu>
256 Pin netsniff-ng to a specific CPU and also pin resp. migrate the
257 NIC's IRQ CPU affinity to this CPU. This option should be pre‐
258 ferred in combination with -s in case a middle to high packet
259 rate is expected.
260 -u <uid>, --user <uid> resp. -g <gid>, --group <gid>
262 After ring setup drop privileges to a non-root user/group combi‐
263 nation.
264 -H, --prio-high
266 Set this process as a high priority process in order to achieve
267 a higher scheduling rate resp. CPU time. This is however not the
268 default setting, since it could lead to starvation of other pro‐
269 cesses, for example low priority kernel threads.
270 -Q, --notouch-irq
272 Do not reassign the NIC's IRQ CPU affinity settings.
273 -s, --silent
275 Do not enter the packet dissector at all and do not print any
276 packet information to the terminal. Just shut up and be silent.
277 This option should be preferred in combination with pcap record‐
278 ing or replay, since it will not flood your terminal which
279 causes a significant performance degradation.
280 -q, --less
282 Print a less verbose one-line information for each packet to the
283 terminal.
284 -X, --hex
286 Only dump packets in hex format to the terminal.
287 -l, --ascii
289 Only display ASCII printable characters.
290 -U, --update
292 If geographical IP location is used, the built-in database
293 update mechanism will be invoked to get Maxmind's latest data‐
294 base. To configure search locations for databases, the file
295 /etc/netsniff-ng/geoip.conf contains possible addresses. Thus,
296 to save bandwidth or for mirroring of Maxmind's databases (to
297 bypass their traffic limit policy), different hosts or IP
298 addresses can be placed into geoip.conf, separated by a newline.
299 -w, --cooked
301 Replace each frame link header with Linux "cooked" header [3]
302 which keeps info about link type and protocol. It allows to dump
303 and dissect frames captured from different link types when -i
304 "any" was specified, for example.
305 -V, --verbose
307 Be more verbose during startup i.e. show detailed ring setup
308 information.
309 -v, --version
311 Show version information and exit.
312 -h, --help
314 Show user help and exit.
315
317 netsniff-ng
318 The most simple command is to just run “netsniff-ng”. This will
319 start listening on all available networking devices in promiscu‐
320 ous mode and dump the packet dissector output to the terminal.
321 No files will be recorded.
322 netsniff-ng --in eth0 --out dump.pcap -s -T 0xa1e2cb12 -b 0 tcp or udp
324 Capture TCP or UDP traffic from the networking device eth0 into
325 the pcap file named dump.pcap, which has netsniff-ng specific
326 pcap extensions (see “netsniff-ng -D” for capabilities). Also,
327 do not print the content to the terminal and pin the process and
328 NIC IRQ affinity to CPU 0. The pcap write method is scatter-
329 gather I/O.
330 netsniff-ng --in wlan0 --rfraw --out dump.pcap --silent --bind-cpu 0
332 Put the wlan0 device into monitoring mode and capture all raw
333 802.11 frames into the file dump.pcap. Do not dissect and print
334 the content to the terminal and pin the process and NIC IRQ
335 affinity to CPU 0. The pcap write method is scatter-gather I/O.
336 netsniff-ng --in dump.pcap --mmap --out eth0 -k1000 --silent --bind-cpu
338 0
339 Replay the pcap file dump.pcap which is read through mmap(2) I/O
340 and send the packets out via the eth0 networking device. Do not
341 dissect and print the content to the terminal and pin the
342 process and NIC IRQ affinity to CPU 0. Also, trigger the kernel
343 every 1000us to traverse the TX_RING instead of every 10us. Note
344 that the pcap magic type is detected automatically from the pcap
345 file header.
346 netsniff-ng --in eth0 --out eth1 --silent --bind-cpu 0 --type host -r
348 Redirect network traffic from the networking device eth0 to eth1
349 for traffic that is destined for our host, thus ignore broad‐
350 cast, multicast and promiscuous traffic. Randomize the order of
351 packets for the outgoing device and do not print any packet con‐
352 tents to the terminal. Also, pin the process and NIC IRQ affin‐
353 ity to CPU 0.
354 netsniff-ng --in team0 --out /opt/probe/ -s -m --interval 100MiB -b 0
356 Capture on an aggregated team0 networking device and dump pack‐
357 ets into multiple pcap files that are split into 100MiB each.
358 Use mmap(2) I/O as a pcap write method, support for super jumbo
359 frames is built-in (does not need to be configured here), and do
360 not print the captured data to the terminal. Pin netsniff-ng
361 and NIC IRQ affinity to CPU 0. The default pcap magic type is
362 0xa1b2c3d4 (tcpdump-capable pcap).
363 netsniff-ng --in vlan0 --out dump.pcap -c -u `id -u bob` -g `id -g bob`
365 Capture network traffic on device vlan0 into a pcap file called
366 dump.pcap by using normal read(2), write(2) I/O for the pcap
367 file (slower but less latency). Also, after setting up the
368 RX_RING for capture, drop privileges from root to the user and
369 group “bob”. Invoke the packet dissector and print packet con‐
370 tents to the terminal for further analysis.
371 netsniff-ng --in any --filter http.bpf -B --ascii -V
373 Capture from all available networking interfaces and install a
374 low-level filter that was previously compiled by bpfc(8) into
375 http.bpf in order to filter HTTP traffic. Super jumbo frame sup‐
376 port is automatically enabled and only print human readable
377 packet data to the terminal, and also be more verbose during
378 setup phase. Moreover, dump a BPF disassembly of http.bpf.
379 netsniff-ng --in dump.pcap --out dump.cfg --silent
381 Convert the pcap file dump.pcap into a trafgen(8) configuration
382 file dump.cfg. Do not print pcap contents to the terminal.
383 netsniff-ng -i dump.pcap -f beacon.bpf -o -
385 Convert the pcap file dump.pcap into a trafgen(8) configuration
386 file and write it to stdout. However, do not dump all of its
387 content, but only the one that passes the low-level filter for
388 raw 802.11 from beacon.bpf. The BPF engine here is invoked in
389 user space inside of netsniff-ng, so Linux extensions are not
390 available.
391 cat foo.pcap | netsniff-ng -i - -o -
393 Read a pcap file from stdin and convert it into a trafgen(8)
394 configuration file to stdout.
395 netsniff-ng -i nlmon0 -o dump.pcap -s
397 Capture netlink traffic to a pcap file. This command needs a
398 netlink monitoring device to be set up beforehand using the
399 follwing commands using ip(1) from the iproute2 utility collec‐
400 tion:
401 modprobe nlmon
403 ip link add type nlmon
404 ip link set nlmon0 up
405 To tear down the nlmon0 device, use the following commands:
407 ip link set nlmon0 down
409 ip link del dev nlmon0
410 rmmod nlmon
411 netsniff-ng --fanout-group 1 --fanout-type cpu --fanout-opts defrag
413 --bind-cpu 0 --notouch-irq --silent --in em1 --out /var/cap/cpu0/
414 --interval 120sec
415 Start two netsniff-ng fanout instances. Both are assigned into
416 the same fanout group membership and traffic is splitted among
417 them by incoming cpu. Furthermore, the kernel is supposed to
418 defragment possible incoming fragments. First instance is
419 assigned to CPU 0 and the second one to CPU 1, IRQ bindings are
420 not altered as they might have been adapted to this scenario by
421 the user a-priori, and traffic is captured on interface em1, and
422 written out in 120 second intervals as pcap files into
423 /var/cap/cpu0/. Tools like mergecap(1) will be able to merge the
424 cpu0/1 split back together if needed.
425
427 Files under /etc/netsniff-ng/ can be modified to extend netsniff-ng's
428 functionality:
429 * oui.conf - OUI/MAC vendor database
431 * ether.conf - Ethernet type descriptions
432 * tcp.conf - TCP port/services map
433 * udp.conf - UDP port/services map
434 * geoip.conf - GeoIP database mirrors
435
437 netsniff-ng supports both, low-level and high-level filters that are
438 attached to its packet(7) socket. Low-level filters are described in
439 the bpfc(8) man page.
440 Low-level filters can be used with netsniff-ng in the following way:
442 1. bpfc foo > bar
444 2. netsniff-ng -f bar
445 3. bpfc foo | netsniff-ng -i nlmon0 -f -
446 Here, foo is the bpfc program that will be translated into a netsniff-
448 ng readable “opcodes” file and passed to netsniff-ng through the -f
449 option.
450 Similarly, high-level filter can be either passed through the -f
452 option, e.g. -f "tcp or udp" or at the end of all options without the
453 “-f”.
454 The filter syntax is the same as in tcpdump(8), which is described in
456 the man page pcap-filter(7). Just to quote some examples:
457 host sundown
459 To select all packets arriving at or departing from sundown.
460 host helios and (hot or ace)
462 To select traffic between helios and either hot or ace.
463 ip host ace and not helios
465 To select all IP packets between ace and any host except helios.
466 net ucb-ether
468 To select all traffic between local hosts and hosts at Berkeley.
469 gateway snup and (port ftp or ftp-data)
471 To select all FTP traffic through Internet gateway snup.
472 ip and not net localnet
474 To select traffic neither sourced from, nor destined for, local
475 hosts. If you have a gateway to another network, this traffic
476 should never make it onto your local network.
477 tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet
479 To select the start and end packets (the SYN and FIN packets) of
480 each TCP conversation that involve a non-local host.
481 tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2))
483 != 0)
484 To select all IPv4 HTTP packets to and from port 80, that is to
485 say, print only packets that contain data, not, for example, SYN
486 and FIN packets and ACK-only packets. (IPv6 is left as an exer‐
487 cise for the reader.)
488 gateway snup and ip[2:2] > 576
490 To select IP packets longer than 576 bytes sent through gateway
491 snup.
492 ether[0] & 1 = 0 and ip[16] >= 224
494 To select IP broadcast or multicast packets that were not sent
495 via Ethernet broadcast or multicast.
496 icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply
498 To select all ICMP packets that are not echo requests or replies
499 (that is to say, not "ping" packets).
500
502 netsniff-ng supports a couple of pcap formats, visible through ``net‐
503 sniff-ng -D'':
504 tcpdump-capable pcap (default)
506 Pcap magic number is encoded as 0xa1b2c3d4 resp. 0xd4c3b2a1. As
507 packet meta data this format contains the timeval in microsec‐
508 onds, the original packet length and the captured packet length.
509 tcpdump-capable pcap with ns resolution
511 Pcap magic number is encoded as 0xa1b23c4d resp. 0x4d3cb2a1. As
512 packet meta data this format contains the timeval in nanosec‐
513 onds, the original packet length and the captured packet length.
514 Alexey Kuznetzov's pcap
516 Pcap magic number is encoded as 0xa1b2cd34 resp. 0x34cdb2a1. As
517 packet meta data this format contains the timeval in microsec‐
518 onds, the original packet length, the captured packet length,
519 the interface index (sll_ifindex), the packet's protocol
520 (sll_protocol), and the packet type (sll_pkttype).
521 netsniff-ng pcap
523 Pcap magic number is encoded as 0xa1e2cb12 resp. 0x12cbe2a1. As
524 packet meta data this format contains the timeval in nanosec‐
525 onds, the original packet length, the captured packet length,
526 the timestamp hw/sw source, the interface index (sll_ifindex),
527 the packet's protocol (sll_protocol), the packet type (sll_pkt‐
528 type) and the hardware type (sll_hatype).
529 For further implementation details or format support in your applica‐
531 tion, have a look at pcap_io.h in the netsniff-ng sources.
532
534 To avoid confusion, it should be noted that there is another network
535 analyzer with a similar name, called NetSniff, that is unrelated to the
536 netsniff-ng project.
537 For introducing bit errors, delays with random variation and more while
539 replaying pcaps, make use of tc(8) with its disciplines such as netem.
540 netsniff-ng does only some basic, architecture generic tuning on
542 startup. If you are considering to do high performance capturing, you
543 need to carefully tune your machine, both hardware and software. Sim‐
544 ply letting netsniff-ng run without thinking about your underlying sys‐
545 tem might not necessarily give you the desired performance. Note that
546 tuning your system is always a tradeoff and fine-grained balancing act
547 (throughput versus latency). You should know what you are doing!
548 One recommendation for software-based tuning is tuned(8). Besides
550 that, there are many other things to consider. Just to throw you a few
551 things that you might want to look at: NAPI networking drivers, tick‐
552 less kernel, I/OAT DMA engine, Direct Cache Access, RAM-based file sys‐
553 tems, multi-queues, and many more things. Also, you might want to read
554 the kernel's Documentation/networking/scaling.txt file regarding tech‐
555 nologies such as RSS, RPS, RFS, aRFS and XPS. Also check your eth‐
556 tool(8) settings, for example regarding offloading or Ethernet pause
557 frames.
558 Moreover, to get a deeper understanding of netsniff-ng internals and
560 how it interacts with the Linux kernel, the kernel documentation under
561 Documentation/networking/{packet_mmap.txt, filter.txt, multiqueue.txt}
562 might be of interest.
563 How do you sniff in a switched environment? I rudely refer to dSniff's
565 documentation that says:
566 The easiest route is simply to impersonate the local gateway, stealing
568 client traffic en route to some remote destination. Of course, the
569 traffic must be forwarded by your attacking machine, either by enabling
570 kernel IP forwarding or with a userland program that accomplishes the
571 same (fragrouter -B1).
572 Several people have reportedly destroyed connectivity on their LAN to
574 the outside world by ARP spoofing the gateway, and forgetting to enable
575 IP forwarding on the attacking machine. Do not do this. You have been
576 warned.
577 A safer option than ARP spoofing would be to use a "port mirror" func‐
579 tion if your switch hardware supports it and if you have access to the
580 switch.
581 If you do not need to dump all possible traffic, you have to consider
583 running netsniff-ng with a BPF filter for the ingress path. For that
584 purpose, read the bpfc(8) man page.
585 Also, to aggregate multiple NICs that you want to capture on, you
587 should consider using team devices, further explained in libteam resp.
588 teamd(8).
589 The following netsniff-ng pcap magic numbers are compatible with other
591 tools, at least tcpdump or Wireshark:
592 0xa1b2c3d4 (tcpdump-capable pcap)
594 0xa1b23c4d (tcpdump-capable pcap with ns resolution)
595 0xa1b2cd34 (Alexey Kuznetzov's pcap)
596 Pcap files with different meta data endianness are supported by net‐
598 sniff-ng as well.
599
601 When replaying pcap files, the timing information from the pcap packet
602 header is currently ignored.
603 Also, when replaying pcap files, demultiplexing traffic among multiple
605 networking interfaces does not work. Currently, it is only sent via the
606 interface that is given by the --out parameter.
607 When performing traffic capture on the Ethernet interface, the pcap
609 file is created and packets are received but without a 802.1Q header.
610 When one uses tshark, all headers are visible, but netsniff-ng removes
611 802.1Q headers. Is that normal behavior?
612 Yes and no. The way VLAN headers are handled in PF_PACKET sockets by
614 the kernel is somewhat “problematic” [1]. The problem in the Linux ker‐
615 nel is that some drivers already handle VLANs, others do not. Those who
616 handle it can have different implementations, such as hardware acceler‐
617 ation and so on. So in some cases the VLAN tag is even stripped before
618 entering the protocol stack, in some cases probably not. The bottom
619 line is that a "hack" was introduced in PF_PACKET so that a VLAN ID is
620 visible in some helper data structure that is accessible from the
621 RX_RING.
622 Then it gets really messy in the user space to artificially put the
624 VLAN header back into the right place. Not to mention the resulting
625 performance implications on all of libpcap(3) tools since parts of the
626 packet need to be copied for reassembly via memmove(3).
627 A user reported the following, just to demonstrate this mess: some
629 tests were made with two machines, and it seems that results depend on
630 the driver ...
631 AR8131:
633 ethtool -k eth0 gives "rx-vlan-offload: on"
634 - wireshark gets the vlan header
635 - netsniff-ng doesn't get the vlan header
636 ethtool -K eth0 rxvlan off
637 - wireshark gets a QinQ header even though no one sent QinQ
638 - netsniff-ng gets the vlan header
639 RTL8111/8168B:
641 ethtool -k eth0 gives "rx-vlan-offload: on"
642 - wireshark gets the vlan header
643 - netsniff-ng doesn't get the vlan header
644 ethtool -K eth0 rxvlan off
645 - wireshark gets the vlan header
646 - netsniff-ng doesn't get the vlan header
647 Even if we agreed on doing the same workaround as libpcap, we still
649 will not be able to see QinQ, for instance, due to the fact that only
650 one VLAN tag is stored in the kernel helper data structure. We think
651 that there should be a good consensus on the kernel space side about
652 what gets transferred to userland first.
653 Update (28.11.2012): the Linux kernel and also bpfc(8) has built-in
655 support for hardware accelerated VLAN filtering, even though tags might
656 not be visible in the payload itself as reported here. However, the
657 filtering for VLANs works reliable if your NIC supports it. See bpfc(8)
658 for an example.
659 [1] http://lkml.indiana.edu/hypermail/linux/kernel/0710.3/3816.html
661 [2] http://www.tcpdump.org/linktypes/LINKTYPE_NETLINK.html
662 [3] http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html
663
665 netsniff-ng is licensed under the GNU GPL version 2.0.
666
668 netsniff-ng was originally written for the netsniff-ng toolkit by
669 Daniel Borkmann. Bigger contributions were made by Emmanuel Roullit,
670 Markus Amend, Tobias Klauser and Christoph Jaeger. It is currently
671 maintained by Tobias Klauser <tklauser@distanz.ch> and Daniel Borkmann
672 <dborkma@tik.ee.ethz.ch>.
673
675 trafgen(8), mausezahn(8), ifpps(8), bpfc(8), flowtop(8), astracer‐
676 oute(8), curvetun(8)
677
679 Manpage was written by Daniel Borkmann.
680
682 This page is part of the Linux netsniff-ng toolkit project. A descrip‐
683 tion of the project, and information about reporting bugs, can be found
684 at http://netsniff-ng.org/.
685Linux 03 March 2013 NETSNIFF-NG(8)