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. 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
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 pcap files into  a  single  large
62       pcap file. 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,
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
76       -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
101       -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
113       -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
122       -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
132       -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
143       -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
149       -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
157       -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
167       -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
174       -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
180       -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
186       -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
193       -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
200       -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
204       -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
209       -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
214       -M, --no-promisc
215              The  networking interface will not be put into promiscuous mode.
216              By default, promiscuous mode is turned on.
217
218       -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
226       -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
231       -m, --mmap
232              Use mmap(2) as pcap file I/O. This is the default when replaying
233              pcap files.
234
235       -G, --sg
236              Use scatter-gather as pcap file I/O. This is  the  default  when
237              capturing pcap files.
238
239       -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
244       -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
249       -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
255       -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
261       -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
265       -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
271       -Q, --notouch-irq
272              Do not reassign the NIC's IRQ CPU affinity settings.
273
274       -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
281       -q, --less
282              Print a less verbose one-line information for each packet to the
283              terminal.
284
285       -X, --hex
286              Only dump packets in hex format to the terminal.
287
288       -l, --ascii
289              Only display ASCII printable characters.
290
291       -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
300       -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
306       -V, --verbose
307              Be  more  verbose  during  startup i.e. show detailed ring setup
308              information.
309
310       -v, --version
311              Show version information and exit.
312
313       -h, --help
314              Show user help and exit.
315

USAGE EXAMPLE

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
323       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
331       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
337       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
347       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
355       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
364       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
372       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
380       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
384       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
392       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
396       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
402                modprobe nlmon
403                ip link add type nlmon
404                ip link set nlmon0 up
405
406              To tear down the nlmon0 device, use the following commands:
407
408                ip link set nlmon0 down
409                ip link del dev nlmon0
410                rmmod nlmon
411
412       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

CONFIG FILES

427       Files under /etc/netsniff-ng/ can be modified to  extend  netsniff-ng's
428       functionality:
429
430           * 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

FILTER EXAMPLE

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
441       Low-level filters can be used with netsniff-ng in the following way:
442
443           1. bpfc foo > bar
444           2. netsniff-ng -f bar
445           3. bpfc foo | netsniff-ng -i nlmon0 -f -
446
447       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
451       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
455       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
458       host sundown
459              To select all packets arriving at or departing from sundown.
460
461       host helios and (hot or ace)
462              To select traffic between helios and either hot or ace.
463
464       ip host ace and not helios
465              To select all IP packets between ace and any host except helios.
466
467       net ucb-ether
468              To select all traffic between local hosts and hosts at Berkeley.
469
470       gateway snup and (port ftp or ftp-data)
471              To select all FTP traffic through Internet gateway snup.
472
473       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
478       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
482       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
489       gateway snup and ip[2:2] > 576
490              To  select IP packets longer than 576 bytes sent through gateway
491              snup.
492
493       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
497       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

PCAP FORMATS:

502       netsniff-ng supports a couple of pcap formats, visible  through  ``net‐
503       sniff-ng -D'':
504
505       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
510       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
515       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
522       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
530       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

NOTE

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
538       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
541       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
549       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
559       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
564       How  do you sniff in a switched environment? I rudely refer to dSniff's
565       documentation that says:
566
567       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
573       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
578       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
582       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
586       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
590       The  following netsniff-ng pcap magic numbers are compatible with other
591       tools, at least tcpdump or Wireshark:
592
593           0xa1b2c3d4 (tcpdump-capable pcap)
594           0xa1b23c4d (tcpdump-capable pcap with ns resolution)
595           0xa1b2cd34 (Alexey Kuznetzov's pcap)
596
597       Pcap files with different meta data endianness are  supported  by  net‐
598       sniff-ng as well.
599

BUGS

601       When  replaying pcap files, the timing information from the pcap packet
602       header is currently ignored.
603
604       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
608       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
613       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
623       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
628       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
632           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
640           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
648       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
654       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
660          [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

HISTORY

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

SEE ALSO

675       trafgen(8),  mausezahn(8),  ifpps(8),  bpfc(8),  flowtop(8),  astracer‐
676       oute(8), curvetun(8)
677

AUTHOR

679       Manpage was written by Daniel Borkmann.
680

COLOPHON

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/.
685
686
687
688Linux                            03 March 2013                  NETSNIFF-NG(8)
Impressum