From 9ea8663420e2b591ff7e43176fbfb2137aacf79c Mon Sep 17 00:00:00 2001 From: Daniel Borkmann Date: Sun, 5 May 2013 13:15:10 +0200 Subject: misc: move file to source root Only have Makefile specific folders in the project root where the binaries are stored, the rest should be part of the repository root. Signed-off-by: Daniel Borkmann --- man/bpfc.8 | 320 ----------------------------------- man/curvetun.8 | 196 --------------------- man/flowtop.8 | 132 --------------- man/ifpps.8 | 105 ------------ man/netsniff-ng.8 | 497 ------------------------------------------------------ man/trafgen.8 | 445 ------------------------------------------------ 6 files changed, 1695 deletions(-) delete mode 100644 man/bpfc.8 delete mode 100644 man/curvetun.8 delete mode 100644 man/flowtop.8 delete mode 100644 man/ifpps.8 delete mode 100644 man/netsniff-ng.8 delete mode 100644 man/trafgen.8 (limited to 'man') diff --git a/man/bpfc.8 b/man/bpfc.8 deleted file mode 100644 index 622014c..0000000 --- a/man/bpfc.8 +++ /dev/null @@ -1,320 +0,0 @@ -.\" netsniff-ng - the packet sniffing beast -.\" Copyright 2013 Daniel Borkmann. -.\" Subject to the GPL, version 2. - -.TH BPFC 8 "03 March 2013" "Linux" "netsniff-ng toolkit" -.SH NAME -bpfc \- a Berkeley Packet Filter assembler/compiler - -.SH SYNOPSIS - -\fB bpfc\fR { [\fIoptions\fR] | [\fIsource-file\fR] } - -.SH DESCRIPTION - -bpfc is a small Berkeley Packet Filter assembler/compiler which is able to -translate BPF assembler-like mnemonics into a numerical or C-like format, -that can be read by tools such as netsniff-ng, iptables (xt_bpf) and many -others. BPF is the one and only upstream filtering construct that is used -in combination with packet(7) sockets. The Linux kernel and also BSD kernels -implement ``virtual machine'' like constructs and JIT compilers that mimic -a small register-based machine in BPF architecture and execute filter code -that is e.g. composed by bpfc on a data buffer that is given by network -packets. The purpose of this is to shift computation in time, so that the -kernel can drop (or truncate) incoming packets as early as possible without -having to push them to user space for further analysis first. Meanwhile, -BPF constructs also find application in other areas like the communication -between user and kernel space. - -By the time of writing this man page, the only available BPF compiler is -part of the pcap(3) library and accessible through a high-level filter -language that might be familiar for many people as tcpdump-like filters. - -However, quite often, it is useful to bypass that compiler and write -optimized code that couldn't be produced by the pcap(3) compiler, was -wrongly optimized, or is defective on purpose in order to debug test kernel -code. Also, a reason to use bpfc could be to try out some new BPF extensions -that are not supported by other compilers. Furthermore, bpfc can be of good -use to verify JIT compiler behaviour or to find possible bugs that need -to be fixed. - -bpfc is implemented with the help of flex(1) and bison(1), tokenizes the -source file in a first stage and parses it's content into an AST. In two -code generation stages it emits target opcodes. bpfc furthermore supports -Linux kernel BPF extensions. More about that can be found in the syntax -section. - -The Linux kernel BPF JIT compiler is automatically turned on if detected -by netsniff-ng. However, it can also be manually turned on through the -command ``echo "1" > /proc/sys/net/core/bpf_jit_enable'' (normal working -mode) or ``echo "2" > /proc/sys/net/core/bpf_jit_enable'' (debug mode -where emitted opcodes of the image are printed to the kernel log). An -architecture generic BPF JIT image disassembler can be found in the kernel -source tree under: tools/net/bpf_jit_disasm.c - -.SH OPTIONS - -.SS -i , --input -Read BPF assembly instruction from an input file or from stdin. - -.SS -f , --format -Specify a different output format than the default that is netsniff-ng -compatible. The specifier can be: C, netsniff-ng, xt_bpf, tcpdump. - -.SS -b, --bypass -Bypass basic filter validation when emitting opcodes. This can be useful -for explicitly creating malformed BPF expressions that should be injected -into the kernel, e.g. for bug testing. - -.SS -V, --verbose -Be more verbose and display some bpfc debugging information. - -.SS -d, --dump -Dump all supported instructions to stdout. - -.SS -v, --version -Show versioning information. - -.SS -h, --help -Show user help. - -.SH SYNTAX - -The BPF architecture resp. register machine consists of the following -elements: - - Element Description - - A 32 bit wide accumulator - X 32 bit wide X register - M[] 16 x 32 bit wide misc registers aka ``scratch -memory store'', addressable from 0 to 15 - -A program, that is translated by bpfc into ``opcodes'' is an array that -consists of the following elements: - - o:16, jt:8, jf:8, k:32 - -The element o is a 16 bit wide opcode that has a particular instruction -encoded, jt and jf are two 8 bit wide jump targets, one for condition -``true'', one for condition ``false''. Last but not least the 32 bit wide -element k contains a miscellaneous argument that can be interpreted in -different ways depending on the given instruction resp. opcode. - -The instruction set consists of load, store, branch, alu, miscellaneous -and return instructions that are also represented in bpfc syntax. This -table also includes own bpfc extensions. All operations are based on -unsigned data structures: - - Instruction Addressing mode Description - - ld 1, 2, 3, 4, 10 Load word into A - ldi 4 Load word into A - ldh 1, 2 Load half-word into A - ldb 1, 2 Load byte into A - ldx 3, 4, 5, 10 Load word into X - ldxi 4 Load word into X - ldxb 5 Load byte into X - - st 3 Copy A into M[] - stx 3 Copy X into M[] - - jmp 6 Jump to label - ja 6 Jump to label - jeq 7, 8 Jump on k == A - jneq 8 Jump on k != A - jne 8 Jump on k != A - jlt 8 Jump on k < A - jle 8 Jump on k <= A - jgt 7, 8 Jump on k > A - jge 7, 8 Jump on k >= A - jset 7, 8 Jump on k & A - - add 0, 4 A + - sub 0, 4 A - - mul 0, 4 A * - div 0, 4 A / - mod 0, 4 A % - neg 0, 4 !A - and 0, 4 A & - or 0, 4 A | - xor 0, 4 A ^ - lsh 0, 4 A << - rsh 0, 4 A >> - - tax Copy A into X - txa Copy X into A - - ret 4, 9 Return - - Addressing mode Syntax Description - - 0 x Register X - 1 [k] BHW at byte offset k in the packet - 2 [x + k] BHW at the offset X + k in the packet - 3 M[k] Word at offset k in M[] - 4 #k Literal value stored in k - 5 4*([k]&0xf) Lower nibble * 4 at byte offset k in the packet - 6 L Jump label L - 7 #k,Lt,Lf Jump to Lt if true, otherwise jump to Lf - 8 #k,Lt Jump to Lt if predicate is true - 9 a Accumulator A - 10 extension BPF extension (see next table) - - Extension (and alias) Description - - #len, len, #pktlen, pktlen Length of packet (skb->len) - #pto, pto, #proto, proto Ethernet type field (skb->protocol) - #type, type Packet type (**) (skb->pkt_type) - #poff, poff Detected payload start offset - #ifx, ifx, #ifidx, ifidx Interface index (skb->dev->ifindex) - #nla, nla Netlink attribute of type X with offset A - #nlan, nlan Nested Netlink attribute of type X with offset A - #mark, mark Packet mark (skb->mark) - #que, que, #queue, queue, #Q, Q NIC queue index (skb->queue_mapping) - #hat, hat, #hatype, hatype NIC hardware type (**) (skb->dev->type) - #rxh, rxh, #rxhash, rxhash Receive hash (skb->rxhash) - #cpu, cpu Current CPU (raw_smp_processor_id()) - #vlant, vlant, #vlan_tci, vlan_tci VLAN TCI value (vlan_tx_tag_get(skb)) - #vlanp, vlanp VLAN present (vlan_tx_tag_present(skb)) - - Further extension details (**) Value - - #type, type 0 - to us / host - 1 - to all / broadcast - 2 - to group / multicast - 3 - to others (promiscuous mode) - 4 - outgoing of any type - - #hat, hat, #hatype, hatype 1 - Ethernet 10Mbps - 8 - APPLEtalk - 19 - ATM - 24 - IEEE 1394 IPv4 - RFC 2734 - 32 - InfiniBand - 768 - IPIP tunnel - 769 - IP6IP6 tunnel - 772 - Loopback device - 778 - GRE over IP - 783 - Linux-IrDA - 801 - IEEE 802.11 - 802 - IEEE 802.11 + Prism2 header - 803 - IEEE 802.11 + radiotap header - 823 - GRE over IP6 - [...] See include/uapi/linux/if_arp.h - -Note that the majority of BPF extensions are available on Linux only. - -There are two types of comments in bpfc source-files: - - 1. Multi-line C-style comments: /* put comment here */ - 2. Single-line ASM-style comments: ; put comment here - -Used Abbreviations: - - BHW: byte, half-word, or word - -.SH SOURCE EXAMPLES - -In this section, we give a couple of examples for bpfc source-files, in other -words, some small example filter programs: - -.SS Only return packet headers (truncate packets): - - ld poff - ret a - -.SS Only allow ARP packets: - - ldh [12] - jne #0x806, drop - ret #-1 - drop: ret #0 - -.SS Only allow IPv4 TCP packets: - - ldh [12] - jne #0x800, drop - ldb [23] - jneq #6, drop - ret #-1 - drop: ret #0 - -.SS Only allow IPv4 TCP, SSH traffic: - - ldh [12] - jne #0x800, drop - ldb [23] - jneq #6, drop - ldh [20] - jset #0x1fff, drop - ldxb 4 * ([14] & 0xf) - ldh [x + 14] - jeq #0x16, pass - ldh [x + 16] - jne #0x16, drop - pass: ret #-1 - drop: ret #0 - -.SS Allow any (hardware accelerated) VLAN: - - ld vlanp - jeq #0, drop - ret #-1 - drop: ret #0 - -.SS Only allow traffic for (hardware accelerated) VLAN 10: - - ld vlant - jneq #10, drop - ret #-1 - drop: ret #0 - -.SS More pedantic check for the above VLAN example: - - ld vlanp - jeq #0, drop - ld vlant - jneq #10, drop - ret #-1 - drop: ret #0 - -.SH USAGE EXAMPLE - -.SS bpfc fubar -Compile the source file ``fubar'' into BPF opcodes. Opcodes will be -directed to stdout. - -.SS bpfc -f xt_bpf -b -i fubar, resp. iptables -A INPUT -m bpf --bytecode "`bpfc -f xt_bpf -i fubar`" -j LOG -Compile the source file ``fubar'' into BPF opcodes, bypass basic filter -validation and emit opcodes in netfilter's xt_bpf readable format. - -.SS bpfc - -Read bpfc instruction from stdin and emit opcodes to stdout. - -.SS bpfc foo > bar, resp. netsniff-ng -f bar ... -Compile filter instructions from file foo and redirect bpfc's output into -the file bar, that can then be read by netsniff-ng(8) through option -f. - -.SS bpfc -f tcpdump -i fubar -Output opcodes from source file fubar in the same behaviour as ``tcpdump -ddd''. - -.SH LEGAL -bpfc is licensed under the GNU GPL version 2.0. - -.SH HISTORY -.B bpfc -was originally written for the netsniff-ng toolkit by Daniel Borkmann. It -is currently maintained by Tobias Klauser and Daniel -Borkmann . - -.SH SEE ALSO -.BR netsniff-ng (8), -.BR trafgen (8), -.BR mausezahn (8), -.BR ifpps (8), -.BR flowtop (8), -.BR astraceroute (8), -.BR curvetun (8) - -.SH AUTHOR -Manpage was written by Daniel Borkmann. diff --git a/man/curvetun.8 b/man/curvetun.8 deleted file mode 100644 index 37208b4..0000000 --- a/man/curvetun.8 +++ /dev/null @@ -1,196 +0,0 @@ -.\" netsniff-ng - the packet sniffing beast -.\" Copyright 2013 Daniel Borkmann. -.\" Subject to the GPL, version 2. - -.TH CURVETUN 8 "03 March 2013" "Linux" "netsniff-ng toolkit" -.SH NAME -curvetun \- a lightweight Curve25519 IP tunnel - -.SH SYNOPSIS - -\fB curvetun\fR [\fIoptions\fR] - -.SH DESCRIPTION -curvetun is a lightweight, high-speed ECDH multiuser IP tunnel for Linux -that is based on epoll(2). curvetun uses the Linux TUN/TAP interface and -supports {IPv4, IPv6} over {IPv4, IPv6} with UDP or TCP as carrier protocols. - -It has an integrated packet forwarding trie, thus multiple users with -different IPs can be handled via a single tunnel device on the server side -and flows are scheduled for processing in a CPU affine way, at least in case -of TCP as a carrier protocol. - -As key management, public-key cryptography based on elliptic curves are being -used and packets are encrypted end-to-end by the symmetric stream cipher -Salsa20 and authenticated by the MAC Poly1305, where keys have previously -been computed with the ECDH key agreement protocol Curve25519. - -Cryptography is based on Daniel J. Bernstein's networking and cryptography -library ``NaCl''. By design, curvetun does not provide any particular pattern -or default port numbers that gives certainty that the connection from a -particular flow is actually running curvetun. - -However, if you have further needs to bypass censorship, you can try using -curvetun in combination with Tor's obfsproxy or Telex. Furthermore, curvetun -also protects you against replay attacks and DH man in the middle. -Additionally, server-side syslog event logging can also be disabled to not -reveal any critical user connection data. - -.IP " 1." 4 -obfsproxy from the TOR project -.RS 4 -\%https://www.torproject.org/projects/obfsproxy.html.en -.RE - -.IP " 2." 4 -Telex, anticensorship in the network infrastructure -.RS 4 -\%https://telex.cc/ -.RE - -.SH OPTIONS - -todo - -.SH CRYPTOGRAPHY -IP tunnels are usually used to create virtual private networks (VPN), where -parts of the network can only be reached via an unsecure or untrusted underlay -network like the Internet. Only few software exists to create such tunnels, -or, VPNs. Two popular representatives of such software are OpenVPN and VTUN. - -The latter also introduced the TUN/TAP interfaces into the Linux kernel. VTUN -only has a rather basic encryption module, that doesn't fit into todays -cryptographic needs. By default MD5 is used to create 128-Bit wide keys for -the symmetric BlowFish cipher in ECB mode [1]. - -Although OpenSSL is used in both, VTUN and OpenVPN, OpenVPN is much more -feature rich regarding ciphers and user authentication. Nevertheless, letting -people choose ciphers or authentication methods does not necessarily mean a -good thing: administrators could either prefer speed over security and -therefore choose weak ciphers, so that the communication system will be as -good as without any cipher; they could choose weak passwords for symmetric -encryption or they could misconfigure the communication system by having too -much choices of ciphers and too little experience for picking the right one. - -Next to the administration issues, there are also software development issues. -Cryptographic libraries like OpenSSL are a huge mess and too low-level and -complex to probably fully understand or correctly apply, so that they form a -further ground for vulnerabilities of such software. - -In 2010, the cryptographers Tanja Lange and Daniel J. Bernstein have therefore -created and published a cryptography library for networking, which is called -NaCl (pronounced ``salt''). NaCl challenges such addressed problems as in -OpenSSL and, in contrast to the rather generic use of OpenSSL, was created -with a strong focus on public-key authenticated encryption based on elliptic -curve cryptography, which is used in curvetun. Partially quoting Daniel J. -Bernstein: - -RSA is somewhat older than elliptic-curve cryptography: RSA was introduced -in 1977, while elliptic-curve cryptography was introduced in 1985. However, -RSA has shown many more weaknesses than elliptic-curve cryptography. RSA's -effective security level was dramatically reduced by the linear sieve in the -late 1970s, by the quadratic sieve and ECM in the 1980s, and by the -number-field sieve in the 1990s. For comparison, a few attacks have been -developed against some rare elliptic curves having special algebraic -structures, and the amount of computer power available to attackers has -predictably increased, but typical elliptic curves require just as much -computer power to break today as they required twenty years ago. - -IEEE P1363 standardized elliptic-curve cryptography in the late 1990s, -including a stringent list of security criteria for elliptic curves. NIST -used the IEEE P1363 criteria to select fifteen specific elliptic curves at -five different security levels. In 2005, NSA issued a new ``Suite B'' -standard, recommending the NIST elliptic curves (at two specific security -levels) for all public-key cryptography and withdrawing previous -recommendations of RSA. - -curvetun uses a particular elliptic curve, Curve25519, introduced in the -following paper: Daniel J. Bernstein, ``Curve25519: new Diffie-Hellman speed -records,'' pages 207-228 in Proceedings of PKC 2006, edited by Moti Yung, -Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, Lecture Notes in Computer -Science 3958, Springer, 2006, ISBN 3-540-33851-9. - -This elliptic curve follows all of the standard IEEE P1363 security criteria. -It also follows new recommendations that achieve ``side-channel immunity'' -and ``twist security'' while improving speed. What this means is that secure -implementations of Curve25519 are considerably simpler and faster than secure -implementations of (e.g.) NIST P-256; there are fewer opportunities for -implementors to make mistakes that compromise security, and mistakes are -more easily caught by reviewers. - -An attacker who spends a billion dollars on special-purpose chips to attack -Curve25519, using the best attacks available today, has about 1 chance in -1000000000000000000000000000 of breaking Curve25519 after a year of computation. -One could achieve similar levels of security with 3000-bit RSA, but -encryption and authentication with 3000-bit RSA are not nearly fast enough -to handle tunnel traffic and would require much more space in network -packets. - -.IP " 1." 4 -Security analysis of VTun -.RS 4 -\%http://www.off.net/~jme/vtun_secu.html -.RE - -.IP " 2." 4 -NaCl: Networking and Cryptography library -.RS 4 -\%http://nacl.cr.yp.to/ -.RE - -.SH SETUP EXAMPLE -If you've never run curvetun before, you need to do an initial setup once. - -At first, make sure that the servers and clients clocks are periodically -synced, for instance, by running a ntp daemon. This is necessary to protect -against replay attacks. Also, make sure if you have read and write access to -/dev/net/tun. You should not run curvetun as root! Then, after you assured -this, the first step is to generate keys and config files. On both, the client -and server do: - -.B curvetun -k - -You are asked for a username. You can use an email address or whatever suits -you. Here, we assume, you've entered 'mysrv1' on the server and 'myclient1' -on the client side. - -Now, all necessary file have been created under ~/.curvetun. Files include -``priv.key'', ``pub.key'', ``username', ``clients'' and ``servers''. - -``clients'' and ``servers'' are empty at the beginning and need to be filled. -The ``clients'' file is meant for the server, so that it knows what clients -are allowed to connect. The ``servers'' file is for the client, where it can -select curvetun servers to connect to. Both files are kept very simple, so that -a single configuration line per client or server is sufficient. - -The client needs to export it's public key data for the server: - -.B curvetun -x - -todo - -.SH NOTE -This software is an experimental prototype intended for researchers. Likely, -it will mature over time, but it is currently not advised using this software -when life is put at risk. - -.SH LEGAL -curvetun is licensed under the GNU GPL version 2.0. - -.SH HISTORY -.B curvetun -was originally written for the netsniff-ng toolkit by Daniel Borkmann. It is -currently maintained by Tobias Klauser and Daniel -Borkmann . - -.SH SEE ALSO -.BR netsniff-ng (8), -.BR trafgen (8), -.BR mausezahn (8), -.BR bpfc (8), -.BR ifpps (8), -.BR flowtop (8), -.BR astraceroute (8) - -.SH AUTHOR -Manpage was written by Daniel Borkmann. diff --git a/man/flowtop.8 b/man/flowtop.8 deleted file mode 100644 index 5a4465d..0000000 --- a/man/flowtop.8 +++ /dev/null @@ -1,132 +0,0 @@ -.\" netsniff-ng - the packet sniffing beast -.\" Copyright 2013 Daniel Borkmann. -.\" Subject to the GPL, version 2. - -.TH FLOWTOP 8 "03 March 2013" "Linux" "netsniff-ng toolkit" -.SH NAME -flowtop \- top-like netfilter TCP/UDP/SCTP/DCCP/ICMP(v6) flow tracking - -.SH SYNOPSIS - -\fB flowtop\fR { [\fIoptions\fR] } - -.SH DESCRIPTION - -flowtop is a top-like connection tracking tool that can run on an end host or -small home router. It is able to present TCP, UDP/UDP-lite, SCTP, DCCP, ICMP(v6) -flows that have been collected by the kernel's netfilter connection tracking -framework, thus no packet capturing in user space needs to be done. - -flowtop is able to give you a quick overview of current connections on your -local system, e.g. for debugging purposes or to answer questions like: - - * If you access website X, what other connections are being opened in -the background that I'm not aware of? - * What connections are active that pass ones router? - * I have this proprietary binary Y, where does it connect to? - * To which countries am I sending my data? - * Are there any suspicious background connections on my machine? - * How many connections has binary Z currently active? - -The following information will be presented in flowtop's output: - - * Application name and PID when run on local machine - * Reverse DNS for source and destination - * Geo-location information (country, city) - * Used protocols (IPv4, IPv6, TCP, UDP, SCTP, ICMP, ...) - * Flow port's service name heuristic - * Transport protocol state machine information - -In order for flowtop to work, netfilter/iptables must be active resp. running -on your machine, thus kernel-side connection tracking is active. - -flowtop's intention is just to get a quick look over your active connections. -If you want to have logging, have a look at netfilter's conntrack(8) tools -instead. - -.SH OPTIONS - -.SS -4, --ipv4 -Display IPv4 flows. That's default when flowtop is started without -any arguments. - -.SS -6, --ipv6 -Display IPv6 flows. That's default when flowtop is started without -any arguments. - -.SS -T, --tcp -Display TCP flows. That's default when flowtop is started without -any arguments. - -.SS -U, --udp -Display UDP and UDP-lite flows. - -.SS -D, --dccp -Display DCCP flows. - -.SS -I, --icmp -Display ICMP version 4 and version 6 flows. - -.SS -S, --sctp -Display SCTP flows. - -.SS -s, --show-src -Also show source information of the flow, not only destination information. - -.SS -u, --update -The built-in database update mechanism will be invoked to get Maxmind's -latest database. To configure search locations for databases, the file -/etc/netsniff-ng/geoip.conf contains possible addresses. Thus, to save -bandwidth or for mirroring Maxmind's databases (to bypass their traffic -limit policy), different hosts or IP addresses can be placed into geoip.conf, -separated by a newline. - -.SS -v, --version -Show versioning information. - -.SS -h, --help -Show user help. - -.SH USAGE EXAMPLE - -.SS flowtop -Default ncurses output for flowtop that tracks IPv4, IPv6 flows for TCP. - -.SS flowtop -46UTDISs -This example enables maximum display options for flowtop. - -.SH CONFIG FILES - -Under /etc/netsniff-ng/ there are the following files stored that are used -by flowtop and can be extended if wished: - - * tcp.conf - TCP port/services map - * udp.conf - UDP port/services map - * geoip.conf - GeoIP database mirrors - -.SH BUGS -During fairly high till high connection tracking updates, flowtop's scrolling -can become shortly unresponsive. The right fix would be to replace flowtop's -connection management backend with a better design resp. locking approach. -Still on todo. - -.SH LEGAL -flowtop is licensed under the GNU GPL version 2.0. - -.SH HISTORY -.B flowtop -was originally written for the netsniff-ng toolkit by Daniel Borkmann. It -is currently maintained by Tobias Klauser and Daniel -Borkmann . - -.SH SEE ALSO -.BR netsniff-ng (8), -.BR trafgen (8), -.BR mausezahn (8), -.BR ifpps (8), -.BR bpfc (8), -.BR astraceroute (8), -.BR curvetun (8) - -.SH AUTHOR -Manpage was written by Daniel Borkmann. diff --git a/man/ifpps.8 b/man/ifpps.8 deleted file mode 100644 index 46088dd..0000000 --- a/man/ifpps.8 +++ /dev/null @@ -1,105 +0,0 @@ -.\" netsniff-ng - the packet sniffing beast -.\" Copyright 2013 Daniel Borkmann. -.\" Subject to the GPL, version 2. - -.TH IFPPS 8 "03 March 2013" "Linux" "netsniff-ng toolkit" -.SH NAME -ifpps \- top-like networking and system statistics - -.SH SYNOPSIS - -\fB ifpps\fR { [\fIoptions\fR] | [\fIdevice\fR] } - -.SH DESCRIPTION - -ifpps is a small utility which periodically provides top-like networking -and system statistics from the kernel. ifpps gathers its data directly -from procfs files and does not apply any user space monitoring libraries -which would falsify statistics on high load. - -For instance, consider the following scenario: two directly connected -Linux machines with Intel Core 2 Quad Q6600 2.40GHz CPUs, 4 GB RAM, and -an Intel 82566DC-2 Gigabit Ethernet NIC are used for performance evaluation. -One machine generates 64 byte network packets by using the kernel space -packet generator pktgen with a maximum possible packet rate. The other -machine displays statistics about incoming network packets by using i) -iptraf(8) and ii) ifpps. - -iptraf that incorporates pcap(3) shows an average packet rate of -246,000 pps while on the other hand ifpps shows an average packet rate of -1,378,000 pps. Hence, due to copying packets and deferring statistics -creation into user space, measurement error of approx. 460 per cent -occurs. Tools like iptraf might display much more information such as -TCP per flow statistics (therefore the use of the pcap library), which -is not implemented in ifpps, because overall networking statistics are -in our focus; statistics, which are also fairly reliable under high packet -load. - -.SH OPTIONS - -.SS -d , --dev -Networking device to fetch statistics from, e.g. eth0, wlan0. - -.SS -t