1NETSNIFF-NG(8)                netsniff-ng toolkit               NETSNIFF-NG(8)
2
3
4

NAME

6       netsniff-ng - the packet sniffing beast
7

SYNOPSIS

9       netsniff-ng { [options] [filter-expression] }
10

DESCRIPTION

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
20       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
34       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
38       netsniff-ng  can  capture  pcap files in several different pcap formats
39       that are interoperable with other tools.  It  has  different  pcap  I/O
40       methods  supported (scatter-gather, mmap(2), read(2), and write(2)) for
41       efficient to-disc capturing.  netsniff-ng is also able to  rotate  pcap
42       files  based  on  data size or time intervals, thus, making it a useful
43       backend tool for subsequent traffic analysis.
44
45       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
55       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 pcaps into a single  large  pcap.
62       Thus, netsniff-ng then works multithreaded eventually.
63
64       netsniff-ng can also be used to debug netlink traffic.
65

OPTIONS

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, a pcap
69       file or stdin (“-”). In case of  a  pcap  file,  the  pcap  type  (“-D”
70       option)  is determined automatically by the pcap file magic. In case of
71       stdin, it is assumed that the input stream is a pcap file.
72
73   -o <dev|pcap|dir|cfg|->, --out <dev|pcap|dir|cfg|->
74       Defines the output device. This can either be a  networking  device,  a
75       pcap  file,  a folder, a trafgen(8) configuration file or stdout (“-”).
76       In the case of a pcap file that should not have the default  pcap  type
77       (0xa1b2c3d4),  the additional option “-T” must be provided. If a direc‐
78       tory is given, then, instead of a single pcap file, multiple pcap files
79       are  generated  with  rotation  based  on  maximum file size or a given
80       interval (“-F” option). A trafgen configuration file can currently only
81       be  specified if the input device is a pcap file. If stdout is given as
82       a device, then a trafgen configuration will be written to stdout if the
83       input  device  is  a pcap file, or a pcap file if the input device is a
84       networking device.
85
86   -C <id>, --fanout-group <id>
87       If multiple netsniff-ng instances are being started that all  have  the
88       same  packet  fanout  group  id, then the ingress network traffic being
89       captured is being distributed/load-balanced among these group  partici‐
90       pants. This gives a much better scaling than running multiple netsniff-
91       ng processes without a fanout group parameter  in  parallel,  but  only
92       with  a  BPF  filter  attached  as  a packet would otherwise need to be
93       delivered to all such capturing processes, instead of only once to such
94       a  fanout  member.  Naturally,  each fanout member can have its own BPF
95       filters attached.
96
97   -K <hash|lb|cpu|rnd|roll|qm>, --fanout-type <hash|lb|cpu|rnd|roll|qm>
98       This parameter specifies the fanout discipline, in other words, how the
99       captured  network  traffic  is  dispatched to the fanout group members.
100       Options are to distribute traffic by the packet  hash  (“hash”),  in  a
101       round-robin  manner  (“lb”),  by  CPU the packet arrived on (“cpu”), by
102       random (“rnd”), by rolling over sockets (“roll”)  which  means  if  one
103       socket's  queue is full, we move on to the next one, or by NIC hardware
104       queue mapping (“qm”).
105
106   -L <defrag|roll>, --fanout-opts <defrag|roll>
107       Defines some auxillary fanout options to be used in addition to a given
108       fanout  type.   These  options  apply  to  any  fanout type. In case of
109       “defrag”, the kernel is being told to defragment packets before  deliv‐
110       ering  to  user space, and “roll” provides the same roll-over option as
111       the “roll” fanout type, so that on any different fanout type being used
112       (e.g.  “qm”)  the  socket  may temporarily roll over to the next fanout
113       group member in case the original one's queue is full.
114
115   -f, --filter <bpf-file|expr>
116       Specifies to not dump all traffic, but to  filter  the  network  packet
117       haystack.  As a filter, either a bpfc(8) compiled file can be passed as
118       a parameter or a  tcpdump(1)-like  filter  expression  in  quotes.  For
119       details  regarding  the  bpf-file  have  a look at bpfc(8), for details
120       regarding a tcpdump(1)-like filter have a look at section “filter exam‐
121       ple”  or  at  pcap-filter(7). A filter expression may also be passed to
122       netsniff-ng without option “-f” in case there is no  subsequent  option
123       following after the command-line filter expression.
124
125   -t, --type <type>
126       This  defines some sort of filtering mechanisms in terms of addressing.
127       Possible values for type are “host”  (to  us),  “broadcast”  (to  all),
128       “multicast” (to group), “others” (promiscuous mode) or “outgoing” (from
129       us).
130
131   -F, --interval <size|time>
132       If the output device is a folder, with “-F”, it is possible  to  define
133       the  pcap file rotation interval either in terms of size or time. Thus,
134       when the interval limit has been reached,  a  new  pcap  file  will  be
135       started.   As   size  parameter,  the  following  values  are  accepted
136       “<num>KiB/MiB/GiB”; As time parameter, it can be “<num>s/sec/min/hrs”.
137
138   -J, --jumbo-support
139       By default, in pcap replay or redirect mode, netsniff-ng's ring  buffer
140       frames  are  a  fixed  size  of  2048 bytes. This means that if you are
141       expecting jumbo frames or even super jumbo frames to pass through  your
142       network, then you need to enable support for that by using this option.
143       However, this has the disadvantage of  performance  degradation  and  a
144       bigger  memory  footprint  for  the ring buffer. Note that this doesn't
145       affect (pcap) capturing mode, since tpacket in version 3 is used!
146
147   -R, --rfraw
148       In case the input or output networking device is a wireless device,  it
149       is  possible with netsniff-ng to turn this into monitor mode and create
150       a mon<X> device that  netsniff-ng  will  be  listening  on  instead  of
151       wlan<X>,  for  instance.  This enables netsniff-ng to analyze, dump, or
152       even replay raw 802.11 frames.
153
154   -n <0|uint>, --num <0|uint>
155       Process a number of packets and then exit. If the number of packets  is
156       0,  then  this is equivalent to infinite packets resp. processing until
157       interrupted.  Otherwise, a number given as  an  unsigned  integer  will
158       limit processing.
159
160   -P <name>, --prefix <name>
161       When  dumping  pcap  files  into  a  folder,  a file name prefix can be
162       defined with this option. If not otherwise specified, the default  pre‐
163       fix  is  “dump-” followed by a Unix timestamp. Use “--prefex ""” to set
164       filename as seconds since the Unix Epoch e.g. 1369179203.pcap
165
166   -T <pcap-magic>, --magic <pcap-magic>
167       Specify a pcap type for storage. Different pcap types with their  vari‐
168       ous meta data capabilities are shown with option “-D”. If not otherwise
169       specified, the pcap-magic 0xa1b2c3d4, also known as a standard tcpdump-
170       capable  pcap  format,  is used. Pcap files with swapped endianness are
171       also supported.
172
173   -D, --dump-pcap-types
174       Dump all available pcap types with their capabilities and magic numbers
175       that can be used with option “-T” to stdout and exit.
176
177   -B, --dump-bpf
178       If a Berkeley Packet Filter is given, for example via option “-f”, then
179       dump the BPF disassembly to stdout during ring setup. This only  serves
180       for informative or verification purposes.
181
182   -r, --rand
183       If  the  input and output device are both networking devices, then this
184       option will randomize packet order in the output ring buffer.
185
186   -M, --no-promisc
187       The networking interface will not be  put  into  promiscuous  mode.  By
188       default, promiscuous mode is turned on.
189
190   -A, --no-sock-mem
191       On  startup and shutdown, netsniff-ng tries to increase socket read and
192       write buffers if appropriate. This option will prevent netsniff-ng from
193       doing so.
194
195   -m, --mmap
196       Use  mmap(2)  as pcap file I/O. This is the default when replaying pcap
197       files.
198
199   -G, --sg
200       Use scatter-gather as pcap file I/O. This is the default when capturing
201       pcap files.
202
203   -c, --clrw
204       Use  slower read(2) and write(2) I/O. This is not the default case any‐
205       where, but in some situations it could be preferred as it has  a  lower
206       latency on write-back to disc.
207
208   -S <size>, --ring-size <size>
209       Manually  define  the RX_RING resp. TX_RING size in “<num>KiB/MiB/GiB”.
210       By default, the size is determined based on  the  network  connectivity
211       rate.
212
213   -k <uint>, --kernel-pull <uint>
214       Manually  define  the interval in micro-seconds where the kernel should
215       be triggered to batch process the ring buffer frames. By default, it is
216       every 10us, but it can manually be prolonged, for instance.
217
218   -b <cpu>, --bind-cpu <cpu>
219       Pin  netsniff-ng to a specific CPU and also pin resp. migrate the NIC's
220       IRQ CPU affinity to this CPU. This option should be preferred in combi‐
221       nation with “-s” in case a middle to high packet rate is expected.
222
223   -u <uid>, --user <uid> resp. -g <gid>, --group <gid>
224       After ring setup drop privileges to a non-root user/group combination.
225
226   -H, --prio-high
227       Set  this  process  as  a  high  priority process in order to achieve a
228       higher scheduling rate resp. CPU time. This is however not the  default
229       setting,  since  it  could  lead  to starvation of other processes, for
230       example low priority kernel threads.
231
232   -Q, --notouch-irq
233       Do not reassign the NIC's IRQ CPU affinity settings.
234
235   -s, --silent
236       Do not enter the packet dissector at all and do not  print  any  packet
237       information  to  the  terminal. Just shut up and be silent. This option
238       should be preferred in combination with pcap recording or replay, since
239       it  will not flood your terminal which causes a significant performance
240       degradation.
241
242   -q, --less
243       Print a less verbose one-line information for each packet to the termi‐
244       nal.
245
246   -X, --hex
247       Only dump packets in hex format to the terminal.
248
249   -l, --ascii
250       Only display ASCII printable characters.
251
252   -U, --update
253       If geographical IP location is used, the built-in database update mech‐
254       anism will be invoked to get Maxmind's latest  database.  To  configure
255       search  locations  for  databases, the file /etc/netsniff-ng/geoip.conf
256       contains possible addresses. Thus, to save bandwidth or  for  mirroring
257       of  Maxmind's databases (to bypass their traffic limit policy), differ‐
258       ent hosts or IP addresses can be placed into geoip.conf, separated by a
259       newline.
260
261   -V, --verbose
262       Be  more  verbose during startup i.e. show detailed ring setup informa‐
263       tion.
264
265   -v, --version
266       Show version information and exit.
267
268   -h, --help
269       Show user help and exit.
270

USAGE EXAMPLE

272   netsniff-ng
273       The most simple command is to just run “netsniff-ng”. This  will  start
274       listening  on  all available networking devices in promiscuous mode and
275       dump the packet dissector output to the  terminal.  No  files  will  be
276       recorded.
277
278   netsniff-ng --in eth0 --out dump.pcap -s -T 0xa1e2cb12 -b 0 tcp or udp
279       Capture  TCP  or  UDP  traffic from the networking device eth0 into the
280       pcap file named dump.pcap, which has netsniff-ng specific  pcap  exten‐
281       sions  (see  “netsniff-ng -D” for capabilities). Also, do not print the
282       content to the terminal and pin the process and NIC IRQ affinity to CPU
283       0. The pcap write method is scatter-gather I/O.
284
285   netsniff-ng --in wlan0 --rfraw --out dump.pcap --silent --bind-cpu 0
286       Put  the  wlan0  device into monitoring mode and capture all raw 802.11
287       frames into the file dump.pcap. Do not dissect and print the content to
288       the  terminal  and  pin  the process and NIC IRQ affinity to CPU 0. The
289       pcap write method is scatter-gather I/O.
290
291   netsniff-ng --in dump.pcap --mmap --out eth0 -k1000 --silent --bind-cpu 0
292       Replay the pcap file dump.pcap which is read through  mmap(2)  I/O  and
293       send the packets out via the eth0 networking device. Do not dissect and
294       print the content to the terminal and  pin  the  process  and  NIC  IRQ
295       affinity  to  CPU 0.  Also, trigger the kernel every 1000us to traverse
296       the TX_RING instead of every 10us. Note that the  pcap  magic  type  is
297       detected automatically from the pcap file header.
298
299   netsniff-ng --in eth0 --out eth1 --silent --bind-cpu 0 --type host -r
300       Redirect  network  traffic  from the networking device eth0 to eth1 for
301       traffic that is destined for our host, thus ignore broadcast, multicast
302       and  promiscuous traffic. Randomize the order of packets for the outgo‐
303       ing device and do not print any packet contents to the terminal.  Also,
304       pin the process and NIC IRQ affinity to CPU 0.
305
306   netsniff-ng --in team0 --out /opt/probe/ -s -m --interval 100MiB -b 0
307       Capture  on an aggregated team0 networking device and dump packets into
308       multiple pcap files that are split into 100MiB each. Use mmap(2) I/O as
309       a  pcap  write method, support for super jumbo frames is built-in (does
310       not need to be configured here), and do not print the captured data  to
311       the  terminal.  Pin  netsniff-ng  and  NIC  IRQ  affinity to CPU 0. The
312       default pcap magic type is 0xa1b2c3d4 (tcpdump-capable pcap).
313
314   netsniff-ng --in vlan0 --out dump.pcap -c -u `id -u bob` -g `id -g bob`
315       Capture network traffic  on  device  wlan0  into  a  pcap  file  called
316       dump.pcap  by  using  normal  read(2),  write(2)  I/O for the pcap file
317       (slower but less latency). Also, after setting up the RX_RING for  cap‐
318       ture, drop privileges from root to the user and group “bob”. Invoke the
319       packet dissector and print packet contents to the terminal for  further
320       analysis.
321
322   netsniff-ng --in any --filter http.bpf -B --ascii -V
323       Capture  from  all  available  networking interfaces and install a low-
324       level filter that was previously compiled by bpfc(8) into  http.bpf  in
325       order  to  filter  HTTP traffic. Super jumbo frame support is automati‐
326       cally enabled and only print human readable packet data to  the  termi‐
327       nal,  and also be more verbose during setup phase. Moreover, dump a BPF
328       disassembly of http.bpf.
329
330   netsniff-ng --in dump.pcap --out dump.cfg --silent
331       Convert the pcap file dump.pcap into a  trafgen(8)  configuration  file
332       dump.cfg.  Do not print pcap contents to the terminal.
333
334   netsniff-ng -i dump.pcap -f beacon.bpf -o -
335       Convert  the  pcap  file dump.pcap into a trafgen(8) configuration file
336       and write it to stdout. However, do not dump all of  its  content,  but
337       only  the one that passes the low-level filter for raw 802.11 from bea‐
338       con.bpf. The BPF engine here is invoked in user space  inside  of  net‐
339       sniff-ng, so Linux extensions are not available.
340
341   cat foo.pcap | netsniff-ng -i - -o -
342       Read a pcap file from stdin and convert it into a trafgen(8) configura‐
343       tion file to stdout.
344
345   modprobe nlmon
346   ip link add type nlmon
347   ip link set nlmon0 up
348   netsniff-ng -i nlmon0 -o dump.pcap -s
349   ip link set nlmon0 down
350   ip link del dev nlmon0
351   rmmod nlmon
352       In this example, netlink traffic is  being  captured.  If  not  already
353       done,  a  netlink monitoring device needs to be set up before it can be
354       used to capture netlink socket buffers (iproute2's ip(1)  commands  are
355       given  for  nlmon device setup and teardown). netsniff-ng can then make
356       use of the nlmon device as an input device. In this example a pcap file
357       with netlink traffic is being recorded.
358
359   netsniff-ng --fanout-group 1 --fanout-type cpu --fanout-opts defrag --bind-
360       cpu 0 --notouch-irq --silent --in em1 --out  /var/cap/cpu0/  --interval
361       120sec
362   netsniff-ng --fanout-group 1 --fanout-type cpu --fanout-opts defrag --bind-
363       cpu 1 --notouch-irq --silent --in em1 --out  /var/cap/cpu1/  --interval
364       120sec
365       Starts  two  netsniff-ng  fanout  instances. Both are assigned into the
366       same fanout group membership and traffic  is  splitted  among  them  by
367       incoming  cpu. Furthermore, the kernel is supposed to defragment possi‐
368       ble incoming fragments. First instance is assigned to  CPU  0  and  the
369       second  one  to  CPU 1, IRQ bindings are not altered as they might have
370       been adapted to this scenario by the user a-priori, and traffic is cap‐
371       tured on interface em1, and written out in 120 second intervals as pcap
372       files into /var/cap/cpu0/. Tools like mergecap(1) will be able to merge
373       the cpu0/1 split back together if needed.
374

CONFIG FILES

376       Files  under  /etc/netsniff-ng/ can be modified to extend netsniff-ng's
377       functionality:
378
379           * oui.conf - OUI/MAC vendor database
380           * ether.conf - Ethernet type descriptions
381           * tcp.conf - TCP port/services map
382           * udp.conf - UDP port/services map
383           * geoip.conf - GeoIP database mirrors
384

FILTER EXAMPLE

386       netsniff-ng supports both, low-level and high-level  filters  that  are
387       attached  to  its  packet(7) socket. Low-level filters are described in
388       the bpfc(8) man page.
389
390       Low-level filters can be used with netsniff-ng in the following way:
391
392           1. bpfc foo > bar
393           2. netsniff-ng -f bar
394
395       Here, foo is the bpfc program that will be translated into a  netsniff-
396       ng  readable  “opcodes”  file  and passed to netsniff-ng through the -f
397       option.
398
399       Similarly, high-level filter  can  be  either  passed  through  the  -f
400       option,  e.g.  -f "tcp or udp" or at the end of all options without the
401       “-f”.
402
403       The filter syntax is the same as in tcpdump(8), which is  described  in
404       the man page pcap-filter(7). Just to quote some examples from pcap-fil‐
405       ter(7):
406
407   host sundown
408       To select all packets arriving at or departing from sundown.
409
410   host helios and hot or ace
411       To select traffic between helios and either hot or ace.
412
413   ip host ace and not helios
414       To select all IP packets between ace and any host except helios.
415
416   net ucb-ether
417       To select all traffic between local hosts and hosts at Berkeley.
418
419   gateway snup and (port ftp or ftp-data)
420       To select all FTP traffic through Internet gateway snup.
421
422   ip and not net localnet
423       To select traffic neither sourced from, nor destined for, local  hosts.
424       If  you  have  a  gateway to another network, this traffic should never
425       make it onto your local network.
426
427   tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet
428       To select the start and end packets (the SYN and FIN packets)  of  each
429       TCP conversation that involve a non-local host.
430
431   tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)
432       To  select  all  IPv4 HTTP packets to and from port 80, that is to say,
433       print only packets that contain data, not, for  example,  SYN  and  FIN
434       packets  and  ACK-only  packets.   (IPv6 is left as an exercise for the
435       reader.)
436
437   gateway snup and ip[2:2] > 576
438       To select IP packets longer than 576 bytes sent through gateway snup.
439
440   ether[0] & 1 = 0 and ip[16] >= 224
441       To select IP broadcast or multicast packets that were not sent via Eth‐
442       ernet broadcast or multicast.
443
444   icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply
445       To  select all ICMP packets that are not echo requests or replies (that
446       is to say, not "ping" packets).
447

PCAP FORMATS:

449       netsniff-ng supports a couple of pcap formats, visible  through  ``net‐
450       sniff-ng -D'':
451
452   tcpdump-capable pcap (default)
453       Pcap  magic number is encoded as 0xa1b2c3d4 resp. 0xd4c3b2a1. As packet
454       meta data this format contains the timeval in microseconds, the  origi‐
455       nal packet length and the captured packet length.
456
457   tcpdump-capable pcap with ns resolution
458       Pcap  magic number is encoded as 0xa1b23c4d resp. 0x4d3cb2a1. As packet
459       meta data this format contains the timeval in nanoseconds, the original
460       packet length and the captured packet length.
461
462   Alexey Kuznetzov's pcap
463       Pcap  magic number is encoded as 0xa1b2cd34 resp. 0x34cdb2a1. As packet
464       meta data this format contains the timeval in microseconds, the  origi‐
465       nal  packet  length,  the  captured  packet length, the interface index
466       (sll_ifindex), the packet's protocol  (sll_protocol),  and  the  packet
467       type (sll_pkttype).
468
469   netsniff-ng pcap
470       Pcap  magic number is encoded as 0xa1e2cb12 resp. 0x12cbe2a1. As packet
471       meta data this format contains the timeval in nanoseconds, the original
472       packet  length, the captured packet length, the timestamp hw/sw source,
473       the interface index (sll_ifindex), the  packet's  protocol  (sll_proto‐
474       col), the packet type (sll_pkttype) and the hardware type (sll_hatype).
475
476       For  further  implementation details or format support in your applica‐
477       tion, have a look at pcap_io.h.
478

NOTE

480       For introducing bit errors, delays with random variation and more while
481       replaying pcaps, make use of tc(8) with its disciplines such as netem.
482
483       netsniff-ng  does  only  some  basic,  architecture  generic  tuning on
484       startup. If you are considering to do high performance  capturing,  you
485       need  to carefully tune your machine, both hardware and software.  Sim‐
486       ply letting netsniff-ng run without thinking about your underlying sys‐
487       tem  might  not necessarily give you the desired performance. Note that
488       tuning your system is always a tradeoff and fine-grained balancing  act
489       (throughput versus latency). You should know what you are doing!
490
491       One recommendation for software-based tuning is tuned(8). Besides that,
492       there are many other things to consider. Just to throw you a few things
493       that  you might want to look at: NAPI networking drivers, tickless ker‐
494       nel, I/OAT DMA engine, Direct Cache  Access,  RAM-based  file  systems,
495       multi-queues,  and  many  more things. Also, you might want to read the
496       kernel's Documentation/networking/scaling.txt file regarding  technolo‐
497       gies  such  as  RSS, RPS, RFS, aRFS and XPS. Also check your ethtool(8)
498       settings, for example regarding offloading or Ethernet pause frames.
499
500       Moreover, to get a deeper understanding of  netsniff-ng  internals  and
501       how  it interacts with the Linux kernel, the kernel documentation under
502       Documentation/networking/{packet_mmap.txt, filter.txt,  multiqueue.txt}
503       might be of interest.
504
505       How  do you sniff in a switched environment? I rudely refer to dSniff's
506       documentation that says:
507
508       The easiest route is simply to impersonate the local gateway,  stealing
509       client  traffic  en  route  to  some remote destination. Of course, the
510       traffic must be forwarded by your attacking machine, either by enabling
511       kernel  IP  forwarding or with a userland program that accomplishes the
512       same (fragrouter -B1).
513
514       Several people have reportedly destroyed connectivity on their  LAN  to
515       the outside world by ARP spoofing the gateway, and forgetting to enable
516       IP forwarding on the attacking machine. Do not do this. You  have  been
517       warned.
518
519       A  safer option than ARP spoofing would be to use a "port mirror" func‐
520       tion if your switch hardware supports it and if you have access to  the
521       switch.
522
523       If  you  do not need to dump all possible traffic, you have to consider
524       running netsniff-ng with a BPF filter for the ingress  path.  For  that
525       purpose, read the bpfc(8) man page.
526
527       Also,  to  aggregate  multiple  NICs  that  you want to capture on, you
528       should consider using team devices, further explained in libteam  resp.
529       teamd(8).
530
531       The  following netsniff-ng pcap magic numbers are compatible with other
532       tools, at least tcpdump or Wireshark:
533
534           0xa1b2c3d4 (tcpdump-capable pcap)
535           0xa1b23c4d (tcpdump-capable pcap with ns resolution)
536           0xa1b2cd34 (Alexey Kuznetzov's pcap)
537
538       Pcap files with different meta data endianness are  supported  by  net‐
539       sniff-ng as well.
540

BUGS

542       When  replaying pcap files, the timing information from the pcap packet
543       header is currently ignored.
544
545       Also, when replaying pcap files, demultiplexing traffic among  multiple
546       networking interfaces does not work. Currently, it is only sent via the
547       interface that is given by the --out parameter.
548
549       When performing traffic capture on the  Ethernet  interface,  the  pcap
550       file  is  created and packets are received but without a 802.1Q header.
551       When one uses tshark, all headers are visible, but netsniff-ng  removes
552       802.1Q headers. Is that normal behavior?
553
554       Yes  and  no.  The way VLAN headers are handled in PF_PACKET sockets by
555       the kernel is somewhat “problematic” [1]. The problem in the Linux ker‐
556       nel is that some drivers already handle VLANs, others do not. Those who
557       handle it can have different implementations, such as hardware acceler‐
558       ation and so on.  So in some cases the VLAN tag is even stripped before
559       entering the protocol stack, in some cases  probably  not.  The  bottom
560       line  is that a "hack" was introduced in PF_PACKET so that a VLAN ID is
561       visible in some helper data  structure  that  is  accessible  from  the
562       RX_RING.
563
564       Then  it  gets  really  messy in the user space to artificially put the
565       VLAN header back into the right place. Not  to  mention  the  resulting
566       performance  implications on all of libpcap(3) tools since parts of the
567       packet need to be copied for reassembly via memmove(3).
568
569       A user reported the following, just  to  demonstrate  this  mess:  some
570       tests  were made with two machines, and it seems that results depend on
571       the driver ...
572
573           AR8131:
574             ethtool -k eth0 gives "rx-vlan-offload: on"
575             - wireshark gets the vlan header
576             - netsniff-ng doesn't get the vlan header
577             ethtool -K eth0 rxvlan off
578             - wireshark gets a QinQ header even though noone sent QinQ
579             - netsniff-ng gets the vlan header
580
581           RTL8111/8168B:
582             ethtool -k eth0 gives "rx-vlan-offload: on"
583             - wireshark gets the vlan header
584             - netsniff-ng doesn't get the vlan header
585             ethtool -K eth0 rxvlan off
586             - wireshark gets the vlan header
587             - netsniff-ng doesn't get the vlan header
588
589       Even if we agreed on doing the same workaround  as  libpcap,  we  still
590       will  not  be able to see QinQ, for instance, due to the fact that only
591       one VLAN tag is stored in the kernel helper data  structure.  We  think
592       that  there  should  be a good consensus on the kernel space side about
593       what gets transferred to userland first.
594
595       Update (28.11.2012): the Linux kernel and  also  bpfc(8)  has  built-in
596       support for hardware accelerated VLAN filtering, even though tags might
597       not be visible in the payload itself as  reported  here.  However,  the
598       filtering for VLANs works reliable if your NIC supports it. See bpfc(8)
599       for an example.
600
601          [1] http://lkml.indiana.edu/hypermail/linux/kernel/0710.3/3816.html
602
604       netsniff-ng is licensed under the GNU GPL version 2.0.
605

HISTORY

607       netsniff-ng was originally  written  for  the  netsniff-ng  toolkit  by
608       Daniel  Borkmann.  Bigger  contributions were made by Emmanuel Roullit,
609       Markus Amend, Tobias Klauser and  Christoph  Jaeger.  It  is  currently
610       maintained  by Tobias Klauser <tklauser@distanz.ch> and Daniel Borkmann
611       <dborkma@tik.ee.ethz.ch>.
612

SEE ALSO

614       trafgen(8),  mausezahn(8),  ifpps(8),  bpfc(8),  flowtop(8),  astracer‐
615       oute(8), curvetun(8)
616

AUTHOR

618       Manpage was written by Daniel Borkmann.
619

COLOPHON

621       This  page is part of the Linux netsniff-ng toolkit project. A descrip‐
622       tion of the project, and information about reporting bugs, can be found
623       at http://netsniff-ng.org/.
624
625
626
627Linux                            03 March 2013                  NETSNIFF-NG(8)
Impressum