Documentation/Netsniff-ng

   1 What is netsniff-ng?
   2 ////////////////////
   3
   4 netsniff-ng is a high-performance network analyzer based on zero-copy
   5 mechanisms. It can record pcap files to disc, replay them and also do
   6 an offline and online analysis. It was the first tool of the toolkit
   7 and its initial development started back in 2009 at the Max Planck
   8 Institute. At that time, zero-copy mechanisms that were provided by the
   9 Linux kernel, namely RX_RING and TX_RING, were not used in libpcap
  10 and therefore by the majority of network analyzers. Hence, it was time
  11 to dig deeper into that topic when we started writing our own analyzer
  12 that was independant of any library except libc.
  13
  14 Later on, for writing pcap files to disc, we have implemented a write-back
  15 mechanism based on scatter/gather I/O and also based on mmap(2). Hence,
  16 the user can decide if he plans to capture a large pcap file that he needs
  17 scatter/gather I/O, or for a pcap file that fits into RAM that he needs the
  18 faster mmap(2) operation.
  19
  20 The newly introduced command line option of --in and --out allows a flexible
  21 combination for different purposes, i.e.
  22  1) --in <netdev> --out <pcap>, writes a network trace to disc
  23  2) --in <pcap> --out <netdev>, replays a network trace from disc
  24  3) --in <pcap>, performs an offline analysis of a trace file
  25  4) --in <netdev>, performs an online analysis
  26  5) --in <netdev> --out <folder>, periodically writes network trace files
  27  6) --in <netdev1> --out <netdev2>, redirects network traffic
  28  7) --in <pcap> --out <txf>, rewrites a pcap file into a txf file for trafgen
  29
  30 Those options can be combined with e.g. different filtering methods or other
  31 parameters such as printing modes.
  32
  33 The kernel API of RX_RING and TX_RING is the fastest capturing or replaying
  34 possibility that you can get out of the box from user space without modifying
  35 your kernel sources.
  36
  37 If you want to run netsniff-ng in combination with -f or --filter <file> you
  38 need to build a so called Berkeley Packet Filter program within a plaintext
  39 file (here, marked as: <file>). The Berkeley Packet Filters language
  40 description can be obtained from netsniff-ng's documentation section. One
  41 way to create a custom filter is to use our bpfc compiler. Read the 'Bpfc'
  42 documentation on how you can do this. In this case you have all the freedom
  43 to build filters for your needs. The alternative way is to use tcpdumps -dd
  44 option. Simply pipe the output into a textfile and pass this to netsniff-ng.
  45 Furthermore, we already ship some common filter examples! Most distributions
  46 will put these files into /etc/netsniff-ng/rules/.
  47
  48 If you try to create custom socket filters with tcpdump -dd, you have to edit
  49 the ret opcode (0x6) of the resulting filter, otherwise your payload will be
  50 cut off on older tcpdump versions:
  51
  52  0x6, 0, 0, 0xFFFFFFFF instead of 0x6, 0, 0, 0x00000060
  53
  54 The Linux kernel now takes skb->len instead of 0xFFFFFFFF. If you do not
  55 change it, the kernel will take 0x00000060 as buffer length and packets larger
  56 than 96 Byte will be cut off (filled with zero Bytes)! It's a bug (or feature?)
  57 in libpcap's filter compiler.
  58
  59 How do you sniff in a switched environment? I rudely refer to the dSniff
  60 documentation that says:
  61
  62 The easiest route is simply to impersonate the local gateway, stealing client
  63 traffic en route to some remote destination. Of course, the traffic must be
  64 forwarded by your attacking machine, either by enabling kernel IP forwarding
  65 or with a userland program that acccomplishes the same (fragrouter -B1).
  66
  67 Several people have reportedly destroyed connectivity on their LAN to the
  68 outside world by arpspoof'ing the gateway, and forgetting to enable IP
  69 forwarding on the attacking machine. Don't do this. You have been warned.
  70
  71 Note that in case you are saving network traces as pcap files, you can also
  72 view them in tools like Wireshark, which has a better dissector than
  73 netsniff-ng. The other way round, you can also use netsniff-ng to replay traces
  74 that have been recorded with Wireshark (or other utilities that support pcap
  75 files). In fact, we have received mails from people switching from Wireshark
  76 to netsniff-ng because of the fact that netsniff-ng seems to have less packet
  77 drops, respectively is faster than Wireshark.
  78
  79 Why not PF_RING? There are two reasons for this: First reason is, that it's
  80 not part of the Linux mainline kernel. A interesting discussion about getting
  81 PF_RING into the kernel can be found at the netdev lists
  82 (http://lists.openwall.net/netdev/2009/10/14/37) and obviously there are no
  83 further efforts (browse the netdev/LKML, also netfilter) from the ntop project
  84 to marry both architectures or add features to PF_PACKET. Second reason is
  85 that we've evaluated the PF_RING (without the commercial Direct NIC Access
  86 [DNA]) regarding its performance and came to the conclusion, that there is no
  87 significant performance enhancement on our IBM HS21 Bladeserver test system.
  88 ntop's DNA ships its own versions of some modified device drivers like
  89 Broadcoms tg3 and NetXtreme, Intels e1000(e), igb and ixgbe. Since these
  90 modifications are not official, neither to the kernel, nor to the vendors and
  91 cover only a small amout of what is out there, we're not doing further
  92 investigations at the moment. Also, netsniff-ng users have reported similar
  93 observations as our conclusions. A benchmark with PF_RING in transparent_mode
  94 0 and 1 seems even slower than netsniff-ng and in transparent_mode 2 both have
  95 comparable performance numbers. The test was done on a Dell PowerEdge 2850.
  96
  97 Netsniff-ng and trafgen performance analysis: http://bit.ly/pUFJxU
  98
  99 Supported protocols:
 100 +-------+---------------+-----------------------------------------------+
 101 | Layer |  Description  |                Supp. Protocols                |
 102 +-------+---------------+-----------------------------------------------+
 103 |  4    |   Transport   | TCP, UDP                                      |
 104 +-------+---------------+-----------------------------------------------+
 105 |  3    |   Network     | ICMPv4, ICMPv6, IGMP, IPv4, IPv6              |
 106 +-------+---------------+-----------------------------------------------+
 107 |  2    |   Data Link   | 802.3 (Ethernet), 802.11* (WLAN), ARP, MPLS,  |
 108 |       |               | 802.1Q (VLAN), 802.1QinQ                      |
 109 +-------+---------------+-----------------------------------------------+
 110 *Not fully implemented (capturing possible), work in progress
 111