From d2d2b5d96121ba427f6b23b64aa38a77d6bf7ace Mon Sep 17 00:00:00 2001 From: Daniel Borkmann Date: Thu, 11 Apr 2013 16:52:24 +0200 Subject: docs: move some of them to the root directory Lets move CodingStyle, SubmittingPatches, and Sponsors into the root directory of netsniff-ng and remove the Documentation folder. Some of those files are quite bloated, and most of these things should be in the man-pages anyway. They should be the only big sources of documentation, nothing else. The rest is currently put here: http://pub.netsniff-ng.org/docs/ Signed-off-by: Daniel Borkmann --- Documentation/KnownIssues | 97 ----------------------------------------------- 1 file changed, 97 deletions(-) delete mode 100644 Documentation/KnownIssues (limited to 'Documentation/KnownIssues') diff --git a/Documentation/KnownIssues b/Documentation/KnownIssues deleted file mode 100644 index eb17a3f..0000000 --- a/Documentation/KnownIssues +++ /dev/null @@ -1,97 +0,0 @@ -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. -- cgit v1.2.3-54-g00ecf