netplan-generate

title: netplan-generate(8)

summary: generate back\-end configuration from

text:
# netplan-generate(8)

## NAME
netplan-generate - generate back-end configuration from Netplan YAML files

## SYNOPSIS
netplan [--debug] generate -h|--help

netplan [--debug] generate [--root-dir ROOT_DIR] [--mapping MAPPING]

## DESCRIPTION
netplan generate converts Netplan YAML into configuration files understood by the back ends (systemd-networkd(8) or NetworkManager(8)). It does not apply the generated configuration.

You will not normally need to run this directly as it is run by netplan apply, netplan try, or at boot.

Only if executed during the systemd initializing phase (i.e. "Early boot, before basic.target is reached"), will it attempt to start/apply the newly created service units. **Requires feature: generate-just-in-time**

When called as a systemd.generator(7), all the parsing and validation errors will be ignored by default. If network definitions are skipped due to parsing errors, they might be incomplete. That means that the back end configuration emitted might not be fully valid.

For details of the configuration file format, see netplan(5).

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--root-dir ROOT_DIR

Instead of looking in /{lib,etc,run}/netplan, look in /ROOT_DIR/{lib,etc,run}/netplan.

--mapping MAPPING

Instead of generating output files, parse the configuration files and print some internal information about the device specified in MAPPING.

## HANDLING MULTIPLE FILES
There are 3 locations that netplan generate considers:

- /lib/netplan/*.yaml

- /etc/netplan/*.yaml

- /run/netplan/*.yaml

If there are multiple files with exactly the same name, then only one will be read. A file in /run/netplan will shadow (completely replace) a file with the same name in /etc/netplan. A file in /etc/netplan will itself shadow a file in /lib/netplan.

Or, in other words, /run/netplan is top priority, then /etc/netplan, with /lib/netplan having the lowest priority.

If there are files with different names, then they are considered in lexicographical order - regardless of the directory they are in. Later files add to or override earlier files. For example, /run/netplan/10-xyz.yaml would be updated by /lib/netplan/20-abc.yaml.

If you have two files with the same key/setting, the following rules apply:

- If the values are YAML boolean or scalar values (numbers and strings) the old value is overwritten by the new value.

- If the values are sequences, the sequences are concatenated - the new values are appended to the old list.

- If the values are mappings, Netplan will examine the elements of the mappings in turn using these rules.

## SEE ALSO
netplan(5), netplan-apply(8), netplan-try(8), systemd-networkd(8), NetworkManager(8)

## AUTHORS
Daniel Axtens (daniel.axtens@canonical.com).


netplan-get

package: netplan

title: netplan-get(8)

summary: read merged Netplan YAML configuration

text:
# netplan-get(8)

## NAME
netplan-get - read merged Netplan YAML configuration

## SYNOPSIS
netplan [--debug] get -h|--help

netplan [--debug] get [--root-dir=ROOT_DIR] [key]

## DESCRIPTION
netplan get key reads all YAML files from /{etc,lib,run}/netplan/*.yaml and returns a merged view of the current configuration.

You can specify all as a key (the default) to get the full YAML tree or extract a subtree by specifying a nested key like: [network.]ethernets.eth0.

For details of the configuration file format, see netplan(5).

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--root-dir

Read YAML files from this root instead of /.

## SEE ALSO
netplan(5), netplan-set(8), netplan-dbus(8)

## AUTHORS
Lukas Märdian (lukas.maerdian@canonical.com).

branch: sisyphus


netplan-info

title: netplan-info(8)

summary: show available features

text:
# netplan-info(8)

## NAME
netplan-info - show available features

## SYNOPSIS
netplan [--debug] info -h|--help

netplan [--debug] info [--json|--yaml]

## DESCRIPTION
netplan info displays the supported features.

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--json

Output version and features in JSON format.

--yaml

Output version and features in YAML format (default).

## SEE ALSO
netplan(5)

## AUTHORS
Danilo Egea Gondolfo (danilo.egea.gondolfo@canonical.com).


netplan-ip

title: netplan-ip(8)

text:
# netplan-ip(8)

## NAME
netplan-ip - retrieve IP information (like DHCP leases) from the system

## SYNOPSIS
netplan [--debug] ip -h|--help

netplan [--debug] ip COMMAND [--root-dir=ROOT_DIR] ARGUMENTS

## DESCRIPTION
netplan ip retrieves IP information (like DHCP leases) from the system.

## DHCP COMMANDS
leases INTERFACE

Displays DHCP IP leases

Example: netplan ip leases enp5s0

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--root-dir

Read YAML files from this root instead of /.

## SEE ALSO
netplan(5), netplan-get(8), netplan-status(8)

## AUTHORS
Danilo Egea Gondolfo (danilo.egea.gondolfo@canonical.com).


netplan-rebind

title: netplan-rebind(8)

summary: rebind SR\-IOV virtual functions to their

text:
# netplan-rebind(8)

## NAME
netplan-rebind - rebind SR-IOV virtual functions to their driver

## SYNOPSIS
netplan [--debug] rebind -h|--help

netplan [--debug] rebind [interfaces]

## DESCRIPTION
netplan rebind [interfaces] rebinds SR-IOV virtual functions of given physical functions to their driver.

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

interfaces

Space-separated list of physical-function interface names.

## SEE ALSO
netplan(5), netplan-set(8), netplan-apply(8)

## AUTHORS
Danilo Egea Gondolfo (danilo.egea.gondolfo@canonical.com).


netplan-set

title: netplan-set(8)

text:
# netplan-set(8)

## NAME
netplan-set - write Netplan YAML configuration snippets to file

## SYNOPSIS
netplan [--debug] set -h|--help

netplan [--debug] set [--root-dir=ROOT_DIR] [--origin-hint=ORIGIN_HINT] [key=value]

## DESCRIPTION
netplan set [key=value] writes a given key/value pair or YAML subtree into a YAML file in /etc/netplan/ and validates its format.

You can specify a single value as: "[network.]ethernets.eth0.addresses=[1.2.3.4/24, 5.6.7.8/24]" or a full subtree as: "[network.]ethernets.eth0={dhcp4: true, dhcp6: true}".

For details of the configuration file format, see netplan(5).

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--root-dir

Write YAML files into this root instead of /.

--origin-hint

Specify a name for the configuration file, e.g.: 70-netplan-set => /etc/netplan/70-netplan-set.yaml.

## SEE ALSO
netplan(5), netplan-get(8), netplan-dbus(8)

## AUTHORS
Lukas Märdian (lukas.maerdian@canonical.com).


netplan-status

title: netplan-status(8)

summary: query networking state of the running

text:
# netplan-status(8)

## NAME
netplan-status - query networking state of the running system

## SYNOPSIS
netplan [--debug] status -h|--help

netplan [--debug] status [interface]

## DESCRIPTION
netplan status [interface] queries the current network configuration and displays it in human-readable format.

You can specify interface to display the status of a specific interface.

Currently, netplan status depends on systemd-networkd as a source of data and will try to start it if it's not masked.

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

-a, --all

Show all interface data including inactive.

--diff

Analyse and display differences between the current system configuration and network definitions present in the YAML files. The configuration analysed includes IP addresses, routes, MAC addresses, DNS addresses, search domains and missing network interfaces.

The output format is similar to popular diff tools, such diff and git diff. Configuration present only in the system (and therefore missing in the Netplan YAML) will be displayed with a + sign and will be highlighted in green. Configuration present only in Netplan (and therefore missing in the system) will be displayed with a - sign and highlighted in red. The same is applied to network interfaces.

--diff-only

Same as --diff but omits all the information that is not a difference.

--root-dir

Read YAML files from this root instead of /.

--verbose

Show extra information.

-f FORMAT, --format FORMAT

Output in machine-readable json or yaml format.

## SEE ALSO
netplan(5), netplan-get(8), netplan-ip(8)

## AUTHORS
Danilo Egea Gondolfo (danilo.egea.gondolfo@canonical.com).


netplan-try

title: netplan-try(8)

text:
# netplan-try(8)

## NAME
netplan-try - try a configuration, optionally rolling it back

## SYNOPSIS
netplan [--debug] try -h|--help

netplan [--debug] try [--config-file CONFIG_FILE] [--timeout TIMEOUT]

## DESCRIPTION
netplan try takes a netplan(5) configuration, applies it, and automatically rolls it back if the user does not confirm the configuration within a time limit.

A configuration can be confirmed or rejected interactively or by sending the SIGUSR1 or SIGINT signals.

This may be especially useful on remote systems, to prevent an administrator being permanently locked out of systems in the case of a network configuration error.

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--config-file CONFIG_FILE

In addition to the usual configuration, apply CONFIG_FILE. It must be a YAML file in the netplan(5) format.

--timeout TIMEOUT

Wait for TIMEOUT seconds before reverting. Defaults to 120 seconds. Note that some network configurations (such as STP) may take over a minute to settle.

## KNOWN ISSUES
netplan try uses similar procedures to netplan apply, so some of the same caveats apply around virtual devices.

There are also some known bugs: if netplan try times out or is cancelled, make sure to verify if the network configuration has in fact been reverted.

As with netplan apply, a reboot should fix any issues. However, be sure to verify that the configuration on disk is in the state you expect before rebooting!

## SEE ALSO
netplan(5), netplan-generate(8), netplan-apply(8)

## AUTHORS
Daniel Axtens (daniel.axtens@canonical.com).


astraceroute

package: netsniff-ng

title: astraceroute(8)

summary: autonomous system trace route utility

text:
# astraceroute(8)

## NAME
astraceroute - autonomous system trace route utility

## SYNOPSIS
astraceroute [options]

## DESCRIPTION
astraceroute is a small utility to retrieve path information in a traceroute like way, but with additional geographical location information. It tracks the route of a packet from the local host to the remote host by successively increasing the IP's TTL field, starting from 1, in the hope that each intermediate node will send an ICMP TIME_EXCEEDED notification back to the local host when the TTL value is decremented to 0.

astraceroute supports IPv4 and IPv6 queries and will display country and city information, if available, the AS number the hop belongs to, and its ISP name. astraceroute also displays timing information and reverse DNS data.

Due to astraceroute's configurability, it is also possible to gather some more useful information about the hop regarding what it does and does not allow to pass through. This is done by using clear text strings for probing DPIs or ``great firewalls'' to determine if they will filter out blocked critical keywords. This tool might be a good start for further in-depth analysis of such systems.

## OPTIONS
-H <host>, --host <host>

Hostname or IPv4 or IPv6 address of the remote host where the AS route should be traced to. In the case of an IPv6 address or host, option -6 must be used. IPv4 is the default.

-p <port>, --port <port>

TCP port for the remote host to use. If not specified, the default port used is 80.

-i <device>, -d <device>, --dev <device>

Networking device to start the trace route from, e.g. eth0, wlan0.

-b <IP>, --bind <IP>

IP address to bind to other than the network device's address. You must specify -6 for an IPv6 address.

-f <ttl>, --init-ttl <ttl>

Initial TTL value to be used. This option might be useful if you are not interested in the first n hops, but only the following ones. The default initial TTL value is 1.

-m <ttl>, --max-ttl <ttl>

Maximum TTL value to be used. If not otherwise specified, the maximum TTL value is 30. Thus, after this has been reached astraceroute exits.

-q <num>, --num-probes <num>

Specifies the number of queries to be done on a particular hop. The default is 2 query requests.

-x <sec>, --timeout <sec>

Tells astraceroute the probe response timeout in seconds, in other words the maximum time astraceroute must wait for an ICMP response from the current hop. The default is 3 seconds.

-X <string>, --payload <string>

Places an ASCII cleartext string into the packet payload. Cleartext that contains whitespace must be put into quotes (e.g.: "censor me").

-l <len>, --totlen <len>

Specifies the total length of the packet. Payload that does not have a cleartext string in it is padded with random garbage.

-4, --ipv4

Use IPv4 only requests. This is the default.

-6, --ipv6

Use IPv6 only requests. This must be used when passing an IPv6 host as an argument.

-n, --numeric

Tells astraceroute to not perform reverse DNS lookup for hop replies. The reverse option is -N.

-u, --update

The built-in geo-database update mechanism will be invoked to get Maxmind's latest version. 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.

-L, --latitude

Also show latitude and longitude of hops.

-N, --dns

Tells astraceroute to perform reverse DNS lookup for hop replies. The reverse option is -n.

-S, --syn

Use TCP's SYN flag for the request.

-A, --ack

Use TCP's ACK flag for the request.

-F, --fin

Use TCP's FIN flag for the request.

-P, --psh

Use TCP's PSH flag for the request.

-U, --urg

Use TCP's URG flag for the request.

-R, --rst

Use TCP's RST flag for the request.

-E, --ecn-syn

Use TCP's ECN flag for the request.

-t <tos>, --tos <tos>

Explicitly specify IP's TOS.

-G, --nofrag

Set IP's no fragmentation flag.

-Z, --show-packet

Show and dissect the returned packet.

-v, --version

Show version information and exit.

-h, --help

Show user help and exit.

## USAGE EXAMPLE
astraceroute -i eth0 -N -S -H netsniff-ng.org

This sends out a TCP SYN probe via the ''eth0'' networking device to the remote IPv4 host netsniff-ng.org. This request is most likely to pass. Also, tell astraceroute to perform reverse DNS lookups for each hop.

astraceroute -6 -i eth0 -S -E -N -H www.6bone.net

In this example, a TCP SYN/ECN probe for the IPv6 host www.6bone.net is being performed. Also in this case, the ''eth0'' device is being used as well as a reverse DNS lookup for each hop.

astraceroute -i eth0 -N -F -H netsniff-ng.org

Here, we send out a TCP FIN probe to the remote host netsniff-ng.org. Again, on each hop a reverse DNS lookup is being done and the queries are transmitted from ''eth0''. IPv4 is used.

astraceroute -i eth0 -N -FPU -H netsniff-ng.org

As in most other examples, we perform a trace route to IPv4 host netsniff-ng.org and do a TCP Xmas probe this time.

astraceroute -i eth0 -N -H netsniff-ng.org -X censor-me -Z

In this example, we have a Null probe to the remote host netsniff-ng.org, port 80 (default) and this time, we append the cleartext string "censor-me" into the packet payload to test if a firewall or DPI will let this string pass. Such a trace could be done once without and once with a blocked string to gather possible information about censorship.

## NOTE
If a TCP-based probe fails after a number of retries, astraceroute will automatically fall back to ICMP-based probes to pass through firewalls and routers used in load balancing for example.

To gather more information about astraceroute's displayed AS numbers, see e.g.: http://bgp.he.net/AS<number>.

## BUGS
The geographical locations are estimated with the help of Maxmind's GeoIP database and can differ from the real physical location. To decrease the possible errors, update the database regularly using astraceroute's --update option.

At some point in time, we need a similar approach to gather more reliable path information such as in the paris-traceroute tool.

Due to the generic nature of astraceroute, it currently has a built-in mechanism to stop the trace after a fixed number of hops, since the configurable TCP flags can have anything included. It is possible to decrease this number of course. In the future, if a SYN probe is sent out, there should be a listener so that we can stop the trace if we detect a handshake in progress.

## LEGAL
astraceroute is licensed under the GNU GPL version 2.0.

## HISTORY
astraceroute was originally written for the netsniff-ng toolkit by Daniel Borkmann. It is currently maintained by Tobias Klauser <tklauser@distanz.ch> and Daniel Borkmann <dborkma@tik.ee.ethz.ch>.

## SEE ALSO
netsniff-ng(8), trafgen(8), mausezahn(8), ifpps(8), bpfc(8), flowtop(8), curvetun(8)

## AUTHOR
Manpage was written by Daniel Borkmann.

## COLOPHON
This page is part of the Linux netsniff-ng toolkit project. A description of the project, and information about reporting bugs, can be found at http://netsniff-ng.org/.


bpfc

title: bpfc(8)

text:
# bpfc(8)

## NAME
bpfc - a Berkeley Packet Filter assembler and compiler

## SYNOPSIS
bpfc { [options] | [source-file] }

## DESCRIPTION
bpfc is a small Berkeley Packet Filter assembler and 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, but also seccomp-BPF for system call sandboxing.

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, for example, 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 such as in the communication between user and kernel space like system call sand-boxing.

At the time of writing this man page, the only other available BPF compiler is part of the pcap(3) library and accessible through a high-level filter language that might be familiar to many people as tcpdump-like filters.

However, it is quite often useful to bypass that compiler and write optimized code that cannot be produced by the pcap(3) compiler, or is 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 useful to verify JIT compiler behavior 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 the first stage and parses its 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 agnostic BPF JIT image disassembler can be found in the kernel source tree under ''tools/net/bpf_jit_disasm.c'' or within the netsniff-ng Git repository.

## OPTIONS
-i <source-file/->, --input <source-file/->

Read BPF assembly instruction from an input file or from stdin.

-p, --cpp

Pass the bpf program through the C preprocessor before reading it in bpfc. This allows #define and #include directives (e.g. to include definitions from system headers) to be used in the bpf program.

-D <name>=<definition>, --define <name>=<definition>

Add macro definition for the C preprocessor to use it within bpf file. This option is used in combination with the -p/--cpp option.

-f <format>, --format <format>

Specify a different output format than the default that is netsniff-ng compatible. The <format> specifier can be: C, netsniff-ng, xt_bpf, tcpdump.

-b, --bypass

Bypass basic filter validation when emitting opcodes. This can be useful for explicitly creating malformed BPF expressions for injecting into the kernel, for example, for bug testing.

-V, --verbose

Be more verbose and display some bpfc debugging information.

-d, --dump

Dump all supported instructions to stdout.

-v, --version

Show version information and exit.

-h, --help

Show user help and exit.

## 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 bpfc's own 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 + <x>

sub 0, 4 A - <x>

mul 0, 4 A * <x>

div 0, 4 A / <x>

mod 0, 4 A % <x>

neg 0, 4 !A

and 0, 4 A & <x>

or 0, 4 A | <x>

xor 0, 4 A ^ <x>

lsh 0, 4 A << <x>

rsh 0, 4 A >> <x>

tax Copy A into X

txa Copy X into A

ret 4, 9 Return

Addressing mode Syntax Description

0 x/%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/%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

824 - Netlink

[...] 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

## SOURCE EXAMPLES
In this section, we give a couple of examples of bpfc source files, in other words, some small example filter programs:

Only return packet headers (truncate packets):

ld poff

ret a

Only allow ARP packets:

ldh [12]

jne #0x806, drop

ret #-1

drop: ret #0

Only allow IPv4 TCP packets:

ldh [12]

jne #0x800, drop

ldb [23]

jneq #6, drop

ret #-1

drop: ret #0

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

A loadable x86_64 seccomp-BPF filter to allow a given set of syscalls:

ld [4] /* offsetof(struct seccomp_data, arch) */

jne #0xc000003e, bad /* AUDIT_ARCH_X86_64 */

ld [0] /* offsetof(struct seccomp_data, nr) */

jeq #15, good /* __NR_rt_sigreturn */

jeq #231, good /* __NR_exit_group */

jeq #60, good /* __NR_exit */

jeq #0, good /* __NR_read */

jeq #1, good /* __NR_write */

jeq #5, good /* __NR_fstat */

jeq #9, good /* __NR_mmap */

jeq #14, good /* __NR_rt_sigprocmask */

jeq #13, good /* __NR_rt_sigaction */

jeq #35, good /* __NR_nanosleep */

bad: ret #0 /* SECCOMP_RET_KILL */

good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */

Allow any (hardware accelerated) VLAN:

ld vlanp

jeq #0, drop

ret #-1

drop: ret #0

Only allow traffic for (hardware accelerated) VLAN 10:

ld vlant

jneq #10, drop

ret #-1

drop: ret #0

More pedantic check for the above VLAN example:

ld vlanp

jeq #0, drop

ld vlant

jneq #10, drop

ret #-1

drop: ret #0

Filter rtnetlink messages:

ldh #proto /* A = skb->protocol */

jneq #0, skip /* check for NETLINK_ROUTE */

ldb [4] /* A = nlmsg_type */

jneq #0x10, skip /* check type == RTNL_NEWLINK */

ldx #16 /* X = offset(ifinfomsg) */

ldb [x + 4] /* offset(ifi_index) */

jneq #0x3, skip /* check ifindex == 3 */

ld #32 /* A = len(nlmsghdr) + len(ifinfomsg), payload offset */

ldx #16 /* X = IFLA_OPERSTATE */

ld #nla /* A = offset(IFLA_OPERSTATE) */

jeq #0, skip

tax

ldb [x + 4] /* A = value(IFLA_OPERSTATE) */

jneq #0x6, skip /* check oper state is UP */

ret #-1

skip: ret #0

## USAGE EXAMPLE
bpfc fubar

Compile the source file ''fubar'' into BPF opcodes. Opcodes will be directed to stdout.

bpfc -f xt_bpf -b -p -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. Note that the source file ''fubar'' is first passed to the C preprocessor for textual replacements before handing over to the bpfc compiler.

cat fubar | bpfc -

Read bpfc instruction from stdin and emit opcodes to stdout.

bpfc foo > bar && 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.

bpfc -f tcpdump -i fubar

Output opcodes from source file fubar in the same behavior as ''tcpdump -ddd''.

## LEGAL
bpfc is licensed under the GNU GPL version 2.0.

## HISTORY
bpfc was originally written for the netsniff-ng toolkit by Daniel Borkmann. It is currently maintained by Tobias Klauser <tklauser@distanz.ch> and Daniel Borkmann <dborkma@tik.ee.ethz.ch>.

## SEE ALSO
netsniff-ng(8), trafgen(8), mausezahn(8), ifpps(8), flowtop(8), astraceroute(8), curvetun(8)

## AUTHOR
Manpage was written by Daniel Borkmann.

## COLOPHON
This page is part of the Linux netsniff-ng toolkit project. A description of the project, and information about reporting bugs, can be found at http://netsniff-ng.org/.


curvetun

title: curvetun(8)

summary: a lightweight curve25519 ip4/6 tunnel

text:
# curvetun(8)

## NAME
curvetun - a lightweight curve25519 ip4/6 tunnel

## SYNOPSIS
curvetun [options]

## 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 tree, 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 efficient way, at least in the case of TCP as the carrier protocol.

For key management, public-key cryptography based on elliptic curves are 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 a further need 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 attacks. Additionally, server-side syslog event logging can also be disabled to avoid revealing critical user connection data.

1.

obfsproxy from the TOR project

https://www.torproject.org/projects/obfsproxy.html.en

2.

Telex, anti-censorship in the network infrastructure

https://telex.cc/

## OPTIONS
-d <tundev>, --dev <tundev>

Defines the name of the tunnel device that is being created. If this option is not set, then the default names, curves{0,1,2,..} for a curvetun server, and curvec{0,1,2,...} for a curvetun client are used.

-p <num>, --port <num>

Defines the port the curvetun server should listen on. There is no default port for curvetun, so setting this option for server bootstrap is mandatory. This option is for servers only.

-t <server>, --stun <server>

If needed, this options enables an STUN lookup in order to show public IP to port mapping and to punch a hole into the firewall. In case you are unsure what STUN server to use, simply use ''--stun stunserver.org''.

-c[=alias], --client[=alias]

Starts curvetun in client mode and connects to the given connection alias that is defined in the configuration file.

-k, --keygen

Generate private and public keypair. This must be done initially.

-x, --export

Export user and key combination to stdout as a one-liner.

-C, --dumpc

Dump all known clients that may connect to the local curvetun server and exit.

-S, --dumps

Dump all known servers curvetun as a client can connect to, and exit.

-D, --nofork

Do not fork off as a client or server on startup.

-s, --server

Start curvetun in server mode. Additional parameters are needed, at least the definition of the port that clients can connect to is required.

-N, --no-logging

Disable all curvetun logging of user information. This option can be used to enable curvetun users to connect more anonymously. This option is for servers only.

-u, --udp

Use UDP as a carrier protocol instead of TCP. By default, TCP is the carrier protocol. This option is for servers only.

-4, --ipv4

Defines IPv4 as the underlying network protocol to be used on the tunnel device. IPv4 is the default. This option is for servers only.

-6, --ipv6

Defines IPv6 as the underlying network protocol to be used on the tunnel device. This option is for servers only.

-v, --version

Show version information and exit.

-h, --help

Show user help and exit.

## USAGE EXAMPLE
curvetun --server -4 -u -N --port 6666 --stun stunserver.org

Starts curvetun in server mode with IPv4 as network protocol and UDP as a transport carrier protocol. The curvetun server listens for incoming connections on port 6666 and performs an STUN lookup on startup to stunserver.org.

curvetun --client=ethz

Starts curvetun in client mode and connects to the defined connection alias ''ethz'' that is defined in the curvetun ~/.curvetun/servers configuration file.

curvetun --keygen

Generates initial keypairs and stores them in the ~/.curvetun/ directory.

curvetun --export

Export user data to stdout for configuration of a curvetun server.

## CRYPTOGRAPHY
Encrypted IP tunnels are often used to create virtual private networks (VPN), where parts of the network can only be reached via an insecure or untrusted medium such as the Internet. Only a few software utilities exist 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 does not fit today's 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 is not necessarily 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 choice 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 fully understand or correctly apply, so that they form further ground for vulnerabilities of such software.

In 2010, the cryptographers Tanja Lange and Daniel J. Bernstein have therefore created and published a cryptographic library for networking, which is named NaCl (pronounced ''salt''). NaCl addresses such problems as mentioned 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, for example, 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.

1.

Security analysis of VTun

http://www.off.net/~jme/vtun_secu.html

2.

NaCl: Networking and Cryptography library

http://nacl.cr.yp.to/

## SETUP HOWTO
If you have not run curvetun before, you need to do an initial setup once.

First, make sure that the servers and clients clocks are periodically synced, for example, by running an NTP daemon. This is necessary to protect against replay attacks. Also, make sure you have read and write access to /dev/net/tun. You should not run curvetun as root! Then, after you have assured this, the first step is to generate keys and config files. On both the client and server do:

curvetun -k

You are asked for a user name. You can use an email address or whatever suits you. Here, we assume you have entered 'mysrv1' on the server and 'myclient1' on the client side.

Now, all necessary files 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 its public key data for the server

curvetun -x

where it prints a string in the following format:

myclient1;11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11

\_______/ \_____________________________________________________________________________________________/

username 32 byte public key for 'myclient1'

This line is transferred to the server admin (yes, we assume a manual on-site key exchange scenario where, for example, the admin sets up server and clients), where the admin then adds this entry into his ''clients'' file like:

server$ echo "myclient1;11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:" \

"11:11:11:11:11:11:11:11:11:11:11:11:11:11:11" >> ~/.curvetun/clients

The server admin can check if the server has registered it properly as follows:

server$ curvetun -C

which prints all parsed clients from ''~/.curvetun/clients''. This process could easily be automated or scripted with, for example, Perl and LDAP.

Now, the client ''myclient1'' is known to the server; that completes the server configuration. The next step is to tell the client where it needs to connect to the server.

We assume in this example that the tunnel server has a public IP address, e.g. 1.2.3.4, runs on port 6666 and uses UDP as a carrier protocol. In case you are behind NAT, you can use curvetun's ''--stun'' option for starting the server, to obtain your mapping. However, in this example we continue with 1.2.3.4 and 6666, UDP.

First, the server needs to export its key to the client, as follows:

server$ curvetun -x

where it prints a string in the following format:

mysrv1;22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22

\____/ \_____________________________________________________________________________________________/

username 32 byte public key for 'mysrv1'

^-- you need this public key

Thus, you now have the server IP address, server port, server transport protocol and the server's public key at hand. On the client side it can be put all together in the config as follows:

client$ echo "myfirstserver;1.2.3.4;6666;udp;22:22:22:22:22:22:22:22:22:22:" \

"22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:" \

"22:22" >> ~/.curvetun/servers

The client can check its config using:

client$ curvetun -S

Then we start the server with:

server$ curvetun -s -p 6666 -u

server# ifconfig curves0 up

server# ifconfig curves0 10.0.0.1/24

Then, we start the client with:

client$ curvetun -c=myfirstserver

client# ifconfig curvec0 up

client# ifconfig curvec0 10.0.0.2/24

Also, client-side information, errors, or warnings will appear in syslog! By now we should be able to ping the server:

client$ ping 10.0.0.1

That's it! Routing example:

Server side's public IP on eth0 is, for example, 1.2.3.4:

server$ ... start curvetun server ...

server# ifconfig curves0 up

server# ifconfig curves0 10.0.0.1/24

server# echo 1 > /proc/sys/net/ipv4/ip_forward

server# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

server# iptables -A FORWARD -i eth0 -o curves0 -m state --state RELATED,ESTABLISHED -j ACCEPT

server# iptables -A FORWARD -i curves0 -o eth0 -j ACCEPT

Client side's IP on eth0 is, for example, 5.6.7.8:

client$ ... start curvetun client ...

client# ... lookup your default gateway (e.g. via route, here: 5.6.7.9) ...

client# ifconfig curvec0 up

client# ifconfig curvec0 10.0.0.2/24

client# route add -net 1.2.3.0 netmask 255.255.255.0 gw 5.6.7.9 dev eth0

client# route add default gw 10.0.0.1

client# route del default gw 5.6.7.9

That should be it, happy browsing and emailing via curvetun tunnels!

## NOTE
This software is an experimental prototype intended for researchers. It will most likely mature over time, but it is currently not advised to use this software when life is put at risk.

## BUGS
Blackhole tunneling is currently not supported.

## LEGAL
curvetun is licensed under the GNU GPL version 2.0.

## HISTORY
curvetun was originally written for the netsniff-ng toolkit by Daniel Borkmann. It is currently maintained by Tobias Klauser <tklauser@distanz.ch> and Daniel Borkmann <dborkma@tik.ee.ethz.ch>.

## SEE ALSO
netsniff-ng(8), trafgen(8), mausezahn(8), bpfc(8), ifpps(8), flowtop(8), astraceroute(8)

## AUTHOR
Manpage was written by Daniel Borkmann.

## COLOPHON
This page is part of the Linux netsniff-ng toolkit project. A description of the project, and information about reporting bugs, can be found at http://netsniff-ng.org/.


flowtop

title: flowtop(8)

text:
# flowtop(8)

## NAME
flowtop - top-like netfilter TCP/UDP/SCTP/DCCP/ICMP(v6) flow tracking

## SYNOPSIS
flowtop { [options] }

## 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, and 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 one's router?

* I have this proprietary binary Y, to where does it connect?

* To which countries am I sending data?

* Are there any suspicious background connections on my machine?

* How many active connections does binary Y have?

* How long are connections active already?

* At which rate am I sending/receiving data?

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

* Byte/packet counters (if they are enabled)

* Connection duration (if timestamping is enabled)

* Flow send/receive rate (if byte/packet counters are enabled)

In order for flowtop to work, netfilter must be active and running on your machine, thus kernel-side connection tracking is active. If netfilter is not running, you can activate it with iptables(8):

iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

or by loading the following kernel modules:

modprobe nf_conntrack_ipv4

modprobe nf_conntrack_ipv6

To dump byte/packet counters flowtop enables the sysctl(8) parameter net.netfilter.nf_conntrack_acct via:

echo 1 > /proc/sys/net/netfilter/nf_conntrack_acct

and resets it to the previously set value on exit. These counters will only be active on connections which were created after accounting was enabled. Thus, to have these counters be active all the time the parameter should be enabled after the system is up. To automatically enable it, sysctl.conf(8) or sysctl.d(8) might be used.

To calculate the connection duration flowtop enables the sysctl(8) parameter net.netfilter.nf_conntrack_timestamp via:

echo 1 > /proc/sys/net/netfilter/nf_conntrack_timestamp

and resets it to the previously set value on exit.

flowtop's intention is just to get a quick look over your active connections. If you want logging support, have a look at netfilter's conntrack(8) tools instead.

## OPTIONS
-4, --ipv4

Display IPv4 flows. That is the default when flowtop is started without any arguments.

-6, --ipv6

Display IPv6 flows. That is the default when flowtop is started without any arguments.

-T, --tcp

Display TCP flows. That is the default when flowtop is started without any arguments.

-U, --udp

Display UDP and UDP-lite flows.

-D, --dccp

Display DCCP flows.

-I, --icmp

Display ICMP version 4 and version 6 flows.

-S, --sctp

Display SCTP flows.

-n, --no-dns

Don't perform hostname lookup. Only numeric addresses will be shown for flow endpoints.

-G, --no-geoip

Don't perform GeoIP lookup. No geographical information will be shown for flow endpoints.

-s, --show-src

Also show source information of the flow, not only destination information.

-b, --bits

Show flow rates in bits per second instead of bytes per second.

-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.

-t <time>, --interval <time>

Flow info refresh interval in seconds, default is 1s.

-v, --version

Show version information and exit.

-h, --help

Show user help and exit.

## USAGE EXAMPLE
flowtop

Default ncurses output for flowtop that tracks IPv4, IPv6 flows for TCP.

flowtop -46UTDISs

This example enables the maximum display options for flowtop.

## CONFIG FILES
Files under /etc/netsniff-ng/ can be modified to extend flowtop's service resolution and lookup information.

* tcp.conf - TCP port/services map

* udp.conf - UDP port/services map

* geoip.conf - GeoIP database mirrors

## BUGS
With a fairly high rate of connection tracking updates, flowtop can become unresponsive for short periods of time while scrolling. The right fix would be to replace flowtop's connection management backend with a better design with respect to the locking approach. This is still on the "todo" list.

## LEGAL
flowtop is licensed under the GNU GPL version 2.0.

## HISTORY
flowtop was originally written for the netsniff-ng toolkit by Daniel Borkmann. It is currently maintained by Tobias Klauser <tklauser@distanz.ch> and Daniel Borkmann <dborkma@tik.ee.ethz.ch>.

## SEE ALSO
netsniff-ng(8), trafgen(8), mausezahn(8), ifpps(8), bpfc(8), astraceroute(8), curvetun(8), iptables(8), sysctl(8), sysctl.conf(8), sysctl.d(8)

## AUTHOR
Manpage was written by Daniel Borkmann.

## COLOPHON
This page is part of the Linux netsniff-ng toolkit project. A description of the project, and information about reporting bugs, can be found at http://netsniff-ng.org/.


ifpps

title: ifpps(8)

text:
# ifpps(8)

## NAME
ifpps - top-like networking and system statistics

## SYNOPSIS
ifpps { [options] | [device] }

## 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 make use of any user space monitoring libraries which would falsify statistics under 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 which 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 packet copies and deferring statistics creation into user space, a measurement error of approximately 460 percent occurs. Tools like iptraf might display much more information such as TCP per flow statistics (hence the use of the pcap library). This is not possible with ifpps, because overall networking statistics are its focus; statistics, which are also fairly reliable under high packet load.

ifpps also periodically displays CPU load, interrupt, software interrupt data per sample interval as well as total interrupts, all per CPU. In case the number of CPUs exceeds 5 or the number specified by the user with the -n command line option, ifpps will only display this number top heavy hitters. The topmost heavy hitter CPU will be marked with “+”. The least heavy hitter will always be displayed and is marked with “-”. In addition, the average for all the above per-CPU data is shown. Optionally the median values can be displayed using the -m command line option.

ifpps also supports directly the gnuplot(1) data sample format. This facilitates creation of gnuplot figures from ifpps time series.

## OPTIONS
-d <netdev>, --dev <netdev>

Networking device to fetch statistics from, for example eth0, wlan0.

-n, --num-cpus

Set maximum number of top hitter CPUs (in terms of time spent in system/user mode) to display in ncurses mode, default is 10.

-t <time>, --interval <time>

Statistics refresh interval in milliseconds, default is 1000ms.

-c, --csv

Output (once) the ncurses data to the terminal as gnuplot(1)-ready data.

-l, --loop

Continuously output the terminal data after a refresh interval. This option is only available if option -c is given. For -l it is usually recommended to redirect the output into a file that is to be processed later with gnuplot(1).

-m, --median

Show median values across all CPUs for CPU load, interrupts (per interval and absolute) and software interrupts.

-o, --omit-header

Omit printing the CSV header. This option is only available if -c is given.

-p, --promisc

Turn on promiscuous mode for the given networking device.

-P, --percentage

Show percentage of current throughput in relation to theoretical line rate.

-W, --no-warn

Suppress possible warnings in the ncurses output, e.g. about a too low sampling interval that could cause performance regression.

-v, --version

Show version information.

-h, --help

Show user help.

## USAGE EXAMPLE
ifpps eth0

Default ncurses output for the eth0 device.

ifpps -pd eth0

Ncurses output for the eth0 device in promiscuous mode.

ifpps -lpcd wlan0 > plot.dat

Continuous terminal output for the wlan0 device in promiscuous mode.

## NOTE
On 10Gbit/s cards or higher, receive and transmit statistics are usually accumulated at a higher duration interval than 1 second. Thus, it might be advisable to alter the timing to a higher accumulation interval for such cards.

## LEGAL
ifpps is licensed under the GNU GPL version 2.0.

## HISTORY
ifpps was originally written for the netsniff-ng toolkit by Daniel Borkmann. It is currently maintained by Tobias Klauser <tklauser@distanz.ch> and Daniel Borkmann <dborkma@tik.ee.ethz.ch>.

## SEE ALSO
netsniff-ng(8), trafgen(8), mausezahn(8), bpfc(8), flowtop(8), astraceroute(8), curvetun(8)

## AUTHOR
Manpage was written by Daniel Borkmann.

## COLOPHON
This page is part of the Linux netsniff-ng toolkit project. A description of the project, and information about reporting bugs, can be found at http://netsniff-ng.org/.