Documentation/KnownIssues

   1 netsniff-ng's known issues:
   2 ///////////////////////////
   3
   4 Q: When I perform a traffic capture on the Ethernet interface, the PCAP file is
   5    created and packets are received but without 802.1Q header. If I use
   6    tshark, I get all headers but netsniff-ng removes 802.1Q headers. Is that
   7    normal behavior?
   8 A: Yes and no. The way how VLAN headers are handled in PF_PACKET sockets by the
   9    kernel is somewhat problematic [1]. The problem in the Linux kernel is that
  10    some drivers already handle VLAN, others not. Those who handle it have
  11    different implementations, i.e. hardware acceleration and so on. So in some
  12    cases the VLAN tag is even stripped before entering the protocol stack, in
  13    some cases probably not. Bottom line is that the netdev hackers introduced
  14    a "hack" in PF_PACKET so that a VLAN ID is visible in some helper data
  15    structure that is accessible from the RX_RING. And then it gets really messy
  16    in the user space to artificially put the VLAN header back into the right
  17    place. Not mentioning about the resulting performance implications on that
  18    of /all/ libpcap tools since parts of the packet need to be copied for
  19    reassembly. A user reported the following, just to demonstrate this mess:
  20    Some tests were made with two machines, and it seems that results depends on
  21    the driver ...
  22
  23     1) AR8131
  24         * ethtool -k eth0 gives "rx-vlan-offload: on"
  25         -> wireshark gets the vlan header
  26         -> netsniff-ng doesn't get the vlan header
  27
  28         * ethtool -K eth0 rxvlan off
  29         -> wireshark gets twice the same vlan header (like QinQ even though
  30            I never sent QinQ)
  31         -> netsniff-ng gets the vlan header
  32
  33     2) RTL8111/8168B
  34         * ethtool -k eth0 gives "rx-vlan-offload: on"
  35         -> wireshark gets the vlan header
  36         -> netsniff-ng doesn't get the vlan header
  37
  38         * ethtool -K eth0 rxvlan off
  39         -> wireshark gets the vlan header
  40         -> netsniff-ng doesn't get the vlan header
  41
  42     Even if we would agree on doing the same workaround as libpcap, we still
  43     will not be able to see QinQ, for instance, due to the fact that only /one/
  44     VLAN tag is stored in this kernel helper data structure. We think that
  45     there should be a good consensus on the kernel space side about what gets
  46     transferred to the userland.
  47
  48     [1] http://lkml.indiana.edu/hypermail/linux/kernel/0710.3/3816.html
  49
  50 Q: When I start trafgen, my kernel crashes! What is happening?
  51 A: We have fixed this ``bug'' in the Linux kernel under commit
  52    7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 (http://bit.ly/PcH5Nd). Either
  53    update your kernel to the latest version, e.g. clone and build it from
  54    git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git or don't
  55    start multiple trafgen instances at once resp. start trafgen with flag -A
  56    to disable temporary socket memory tuning! Although trafgen's mechanism is
  57    written in a correct manner, some probably Linux internal side-effects
  58    cause the tigger of the BUG macro. Why tuning? In general, if not otherwise
  59    specified, the netsniff-ng suite tries to get a good performance on default.
  60    For instance, this includes things like tuning the system's socket memory,
  61    enabling the BPF JIT compiler, migrating the NIC's interrupt affinity and
  62    so on. If you don't want netsniff-ng to do this, look at the relevant cmd
  63    line options that disable them with ``--help'' and explicitly specify them
  64    on the program start.