netsniff-ng's known issues:
///////////////////////////
Q: When I perform a traffic capture on the Ethernet interface, the PCAP file is
created and packets are received but without 802.1Q header. If I use
tshark, I get all headers but netsniff-ng removes 802.1Q headers. Is that
normal behavior?
A: Yes and no. The way how VLAN headers are handled in PF_PACKET sockets by the
kernel is somewhat problematic [1]. The problem in the Linux kernel is that
some drivers already handle VLAN, others not. Those who handle it have
different implementations, i.e. hardware acceleration and so on. So in some
cases the VLAN tag is even stripped before entering the protocol stack, in
some cases probably not. Bottom line is that the netdev hackers introduced
a "hack" in PF_PACKET so that a VLAN ID is visible in some helper data
structure that is accessible from the RX_RING. And then it gets really messy
in the user space to artificially put the VLAN header back into the right
place. Not mentioning about the resulting performance implications on that
of /all/ libpcap tools since parts of the packet need to be copied for
reassembly. A user reported the following, just to demonstrate this mess:
Some tests were made with two machines, and it seems that results depends on
the driver ...
1) AR8131
* ethtool -k eth0 gives "rx-vlan-offload: on"
-> wireshark gets the vlan header
-> netsniff-ng doesn't get the vlan header
* ethtool -K eth0 rxvlan off
-> wireshark gets twice the same vlan header (like QinQ even though
I never sent QinQ)
-> netsniff-ng gets the vlan header
2) RTL8111/8168B
* ethtool -k eth0 gives "rx-vlan-offload: on"
-> wireshark gets the vlan header
-> netsniff-ng doesn't get the vlan header
* ethtool -K eth0 rxvlan off
-> wireshark gets the vlan header
-> netsniff-ng doesn't get the vlan header
Even if we would agree on doing the same workaround as libpcap, we still
will not be able to see QinQ, for instance, due to the fact that only /one/
VLAN tag is stored in this kernel helper data structure. We think that
there should be a good consensus on the kernel space side about what gets
transferred to the userland.
[1] http://lkml.indiana.edu/hypermail/linux/kernel/0710.3/3816.html
Update (28.11.2012): the Linux kernel and also bpfc has built-in support
for hardware accelerated VLAN filtering, even though tags might not be
visible in the payload itself as reported here. However, the filtering
for VLANs works reliable if your NIC supports it. bpfc example for filtering
for any tags:
_main:
ld #vlanp
jeq #0, drop
ret #-1
drop:
ret #0
Filtering for a particular VLAN tag:
_main:
ld #vlant
jneq #10, drop
ret #-1
drop:
ret #0
Where 10 is VLAN ID 10 in this example. Or, more pedantic:
_main:
ld #vlanp
jeq #0, drop
ld #vlant
jneq #10, drop
ret #-1
drop:
ret #0
Q: When I start trafgen, my kernel crashes! What is happening?
A: We have fixed this ``bug'' in the Linux kernel under commit
7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 (http://bit.ly/PcH5Nd). Either
update your kernel to the latest version, e.g. clone and build it from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git or don't
start multiple trafgen instances at once resp. start trafgen with flag -A
to disable temporary socket memory tuning! Although trafgen's mechanism is
written in a correct manner, some probably Linux internal side-effects
cause the tigger of the BUG macro. Why tuning? In general, if not otherwise
specified, the netsniff-ng suite tries to get a good performance on default.
For instance, this includes things like tuning the system's socket memory,
enabling the BPF JIT compiler, migrating the NIC's interrupt affinity and
so on. If you don't want netsniff-ng to do this, look at the relevant cmd
line options that disable them with ``--help'' and explicitly specify them
on the program start.
n value='9'>9
Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull DAX updates from Dan Williams:
"The completion of Jan's DAX work for 4.10.
As I mentioned in the libnvdimm-for-4.10 pull request, these are some
final fixes for the DAX dirty-cacheline-tracking invalidation work
that was merged through the -mm, ext4, and xfs trees in -rc1. These
patches were prepared prior to the merge window, but we waited for
4.10-rc1 to have a stable merge base after all the prerequisites were
merged.
Quoting Jan on the overall changes in these patches:
"So I'd like all these 6 patches to go for rc2. The first three
patches fix invalidation of exceptional DAX entries (a bug which
is there for a long time) - without these patches data loss can
occur on power failure even though user called fsync(2). The other
three patches change locking of DAX faults so that ->iomap_begin()
is called in a more relaxed locking context and we are safe to
start a transaction there for ext4"
These have received a build success notification from the kbuild
robot, and pass the latest libnvdimm unit tests. There have not been
any -next releases since -rc1, so they have not appeared there"
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
ext4: Simplify DAX fault path
dax: Call ->iomap_begin without entry lock during dax fault
dax: Finish fault completely when loading holes
dax: Avoid page invalidation races and unnecessary radix tree traversals
mm: Invalidate DAX radix tree entries only if appropriate
ext2: Return BH_New buffers for zeroed blocks