diff options
| -rw-r--r-- | astraceroute.8 | 8 | ||||
| -rw-r--r-- | bpfc.8 | 6 | ||||
| -rw-r--r-- | curvetun.8 | 20 | ||||
| -rw-r--r-- | ifpps.8 | 6 | ||||
| -rw-r--r-- | mausezahn.8 | 22 | ||||
| -rw-r--r-- | netsniff-ng.8 | 26 | ||||
| -rw-r--r-- | trafgen.8 | 8 |
7 files changed, 48 insertions, 48 deletions
diff --git a/astraceroute.8 b/astraceroute.8 index d006281..34dbc54 100644 --- a/astraceroute.8 +++ b/astraceroute.8 @@ -31,7 +31,7 @@ tool might be a good start for further in-depth analysis of such systems. .PP .SS -H <host>, --host <host> Hostname or IPv4 or IPv6 address of the remote host where the AS route should -be traced to. In case of an IPv6 address or host, option ``-6'' must be +be traced to. In case of an IPv6 address or host, option ``\-6'' must be used. IPv4 is the default. .PP .SS -p <port>, --port <port> @@ -76,7 +76,7 @@ argument. .PP .SS -n, --numeric Tells astraceroute to not perform reverse DNS lookup for hop replies. The -reverse option is ``-N''. +reverse option is ``\-N''. .PP .SS -u, --update The built-in geo-database update mechanism will be invoked to get Maxmind's @@ -91,7 +91,7 @@ Also show latitude and longtitude of hops. .PP .SS -N, --dns Tells astraceroute to perform reverse DNS lookup for hop replies. The -reverse option is ``-n''. +reverse option is ``\-n''. .PP .SS -S, --syn Use TCP's SYN flag for the request. @@ -169,7 +169,7 @@ http://bgp.he.net/AS<number>. The geographical locations are estimated with the help of Maxmind's GeoIP database and can or cannot deviate from the actual real physical location. What one can do to decrease a possible error rate is to update the database -regularly e.g. with astraceroute's --update option. +regularly e.g. with astraceroute's \-\-update option. .PP At some point in time, we need a similar approach to gather more reliable path information such as in paris-traceroute. @@ -293,17 +293,17 @@ directed to stdout. 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 replacments before handing over to the bpfc compiler. +textual replacements before handing over to the bpfc compiler. .PP .SS bpfc - Read bpfc instruction from stdin and emit opcodes to stdout. .PP .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. +the file bar, that can then be read by netsniff-ng(8) through option \-f. .PP .SS bpfc -f tcpdump -i fubar -Output opcodes from source file fubar in the same behavior as ''tcpdump -ddd''. +Output opcodes from source file fubar in the same behavior as ''tcpdump \-ddd''. .PP .SH LEGAL bpfc is licensed under the GNU GPL version 2.0. @@ -63,7 +63,7 @@ mandatory. This option is for servers only. .SS -t <server>, --stun <server> If needed, this options enables an STUN lookup in order to show public IP/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''. +server to use, simply use ``\-\-stun stunserver.org''. .PP .SS -c[=alias], --client[=alias] Starts curvetun in client mode and connects to the given connection alias that is @@ -260,7 +260,7 @@ the admin then adds this entry into his ``clients'' file like: .PP The server admin can check, if the server has registered it properly by .PP - server$ curvetun -C + server$ curvetun \-C .PP which prints all parsed clients from ``~/.curvetun/clients''. This process could easily be automated/scripted with f.e. Perl and LDAP. @@ -271,13 +271,13 @@ the server. .PP We assume in this example that the tunnel server has a public IP i.e. 1.2.3.4, runs on port 6666 and uses UDP as a carrier protocol. In case you are behind -a NAT, you can use curvetun's ``--stun'' option for starting the server, to +a 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. .PP First, the server needs to export its key to the client, as .PP - server$ curvetun -x + server$ curvetun \-x .PP where it prints sth like: .PP @@ -296,17 +296,17 @@ in the config like .PP where the client can check its config via: .PP - client$ curvetun -S + client$ curvetun \-S .PP Okay, assuming we've made it, then we start the server with: .PP - server$ curvetun -s -p 6666 -u + server$ curvetun \-s \-p 6666 \-u server# ifconfig curves0 up server# ifconfig curves0 10.0.0.1/24 .PP Then, we start the client with: .PP - client$ curvetun -c=myfirstserver + client$ curvetun \-c=myfirstserver client# ifconfig curvec0 up client# ifconfig curvec0 10.0.0.2/24 .PP @@ -323,9 +323,9 @@ Server side's public IP on eth0 is i.e. 1.2.3.4: 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 + 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 .PP Client side's IP on eth0 is i.e. 5.6.7.8: .PP @@ -55,9 +55,9 @@ Output (once) the ncurses data to the terminal as gnuplot(1)-ready data. .PP .SS -l, --loop Continuously output the terminal data after a refresh interval. This option -is only available, if option \[lq]-c\[rq] is given. For \[lq]-l\[rq] it is usually -recommended to redirect the output into a file that is to be be processed -later with gnuplot(1). +is only available, if option \[lq]\-c\[rq] is given. For \[lq]\-l\[rq] it is +usually recommended to redirect the output into a file that is to be be +processed later with gnuplot(1). .PP .SS -v, --version Show version information. diff --git a/mausezahn.8 b/mausezahn.8 index 0554753..1e67562 100644 --- a/mausezahn.8 +++ b/mausezahn.8 @@ -38,7 +38,7 @@ The interactive mode utilizes a completely redesigned and more flexible protocol framework called ``mops'' (mausezahn's own packet system). The look and feel of the cli is very close to the Cisco IOS^tm command line. .PP -You can start the interactive mode by executing mausezahn with the ``-x'' +You can start the interactive mode by executing mausezahn with the ``\-x'' argument (an optional port number may follow, otherwise it is 25542). Then use telnet(1) to connect to this mausezahn instance. If not otherwise specified, the default login/password combination is mz:mz, enable password is: mops. @@ -46,7 +46,7 @@ This can be changed in /etc/netsniff-ng/mausezahn.conf. .PP The direct mode supports two specification schemes: The ``raw-layer-2'' scheme, where every single byte to be sent can be specified, and ``higher-layer'' scheme, -where packet builder interfaces are used (using the ``-t'' option). +where packet builder interfaces are used (using the ``\-t'' option). .PP To use the ``raw-layer-2'' scheme, simply specify the desired frame as hexadecimal sequence (the ``hex-string''), such as: @@ -55,10 +55,10 @@ hexadecimal sequence (the ``hex-string''), such as: .PP In this example, whitespaces within the byte string are optional and separate the Ethernet fields (destination and source address, type field, and a short -payload). The only additional options supported are ``-a'', ``-b'', ``-c'', and -``-p''. The frame length must be greater or equal 15 bytes. +payload). The only additional options supported are ``\-a'', ``\-b'', ``\-c'', +and ``\-p''. The frame length must be greater or equal 15 bytes. .PP -The ``higher-layer'' scheme is enabled using the ``-t <packet-type>'' option. +The ``higher-layer'' scheme is enabled using the ``\-t <packet-type>'' option. This option activates a packet builder and besides the ``packet-type'' an optional ``arg-string'' can be specified. The ``arg-string'' contains packet-specific parameters, such as TCP flags, port numbers, etc (see example @@ -76,7 +76,7 @@ into the local mausezahn instance. If no port has been specified, port 25542 is used as default. .PP .SS -v -Verbose mode. Capital -V is even more verbose. +Verbose mode. Capital \-V is even more verbose. .PP .SS -S Simulation mode, i.e. don't put anything on the wire. This is typically combined @@ -129,9 +129,9 @@ As with the source address (see above) you can also specify a range or a DNS nam Create the specified packet type using the built-in packet builder. Currently, supported packet types are: ``arp'', ``bpdu'', ``ip'', ``udp'', ``tcp'', ``rtp'', and ``dns''. There is currently also a limited support for ``icmp''. Type -``-t help'' to verify which packet builders your actual mausezahn version +``\-t help'' to verify which packet builders your actual mausezahn version supports. Also, for any particular packet type, for example ``tcp'' type -``mausezahn -t tcp help'' to receive a more in-depth context specific help. +``mausezahn \-t tcp help'' to receive a more in-depth context specific help. .PP .SS -T <packet-type> Make this mausezahn instance the receiving station. Currently, only ``rtp'' is @@ -152,12 +152,12 @@ experimental bits (usually the Class of Service, CoS) and the Time To Live (TTL) can be specified. And if you are really crazy you can set/unset the Bottom of Stack (BoS) bit at each label using the ``S'' (set) and ``s'' (unset) option. By default, the BoS is set automatically and correct. Any other -setting will lead to invalid frames. Enter ``-M help'' for detailed instructions +setting will lead to invalid frames. Enter ``\-M help'' for detailed instructions and examples. .PP .SS -P <ascii-payload> Specify a cleartext payload. Alternatively, each packet type supports a -hexadecimal specification of the payload (see for example ``-t udp help''). +hexadecimal specification of the payload (see for example ``\-t udp help''). .PP .SS -f <filename> Read the ascii payload from the specified file. @@ -923,7 +923,7 @@ Send a DNS request as local broadcast (often a local router replies): mausezahn eth0 -t udp dp=53,p=c5-2f-01-00-00-01-00-00-00-00-00-00-03-77-77-\\ 77-03-78-79-7a-03-63-6f-6d-00-00-01-00-01" .PP -Additionally you may specify the lenght and checksum using the len and sum +Additionally you may specify the length and checksum using the len and sum arguments (will be set correctly by default). Note: several protocols have same arguments such as len (length) and sum (checksum). If you specified a udp type packet (via -t udp) and want to modify the IP length, then use the alternate diff --git a/netsniff-ng.8 b/netsniff-ng.8 index bc99123..7b6f9a4 100644 --- a/netsniff-ng.8 +++ b/netsniff-ng.8 @@ -66,17 +66,17 @@ eventually. .PP .SS -i <dev|pcap|->, -d <dev|pcap|->, --in <dev|pcap|->, --dev <dev|pcap|-> Defines an input device. This can either be a networking device, a pcap file -or stdin (\[lq]-\[rq]). In case of a pcap file, the pcap type (\[lq]-D\[rq] option) is -determined automatically by the pcap file magic. In case of stdin, it is -assumed that the input stream is a pcap file. +or stdin (\[lq]\-\[rq]). In case of a pcap file, the pcap type (\[lq]\-D\[rq] +option) is determined automatically by the pcap file magic. In case of stdin, +it is assumed that the input stream is a pcap file. .PP .SS -o <dev|pcap|dir|cfg|->, --out <dev|pcap|dir|cfg|-> Defines the output device. This can either be a networking device, a pcap file, a folder, a trafgen(8) configuration file or stdout (\[lq]-\[rq]). In the case of a pcap file that should not have the default pcap type (0xa1b2c3d4), the additional -option \[lq]-T\[rq] must be provided. If a directory is given, then, instead of a +option \[lq]\-T\[rq] must be provided. If a directory is given, then, instead of a single pcap file, multiple pcap files are generated with rotation based on -maximum file size or a given interval (\[lq]-F\[rq] option). A trafgen configuration +maximum file size or a given interval (\[lq]\-F\[rq] option). A trafgen configuration file can currently only be specified if the input device is a pcap file. If stdout is given as a device, then a trafgen configuration will be written to stdout if the input device is a pcap file, or a pcap file if the input device @@ -88,7 +88,7 @@ As a filter, either a bpfc(8) compiled file can be passed as a parameter or a tcpdump(1)-like filter expression in quotes. For details regarding the bpf-file have a look at bpfc(8), for details regarding a tcpdump(1)-like filter have a look at section \[lq]filter example\[rq] or at pcap-filter(7). A filter -expression may also be passed to netsniff-ng without option \[lq]-f\[rq] in case +expression may also be passed to netsniff-ng without option \[lq]\-f\[rq] in case there is no subsequent option following after the command-line filter expression. .PP .SS -t, --type <type> @@ -97,7 +97,7 @@ values for type are \[lq]host\[rq] (to us), \[lq]broadcast\[rq] (to all), \[lq]m group), \[lq]others\[rq] (promiscuous mode) or \[lq]outgoing\[rq] (from us). .PP .SS -F, --interval <size|time> -If the output device is a folder, with \[lq]-F\[rq], it is possible to define the pcap +If the output device is a folder, with \[lq]\-F\[rq], it is possible to define the pcap file rotation interval either in terms of size or time. Thus, when the interval limit has been reached, a new pcap file will be started. As size parameter, the following values are accepted \[lq]<num>KiB/MiB/GiB\[rq]; As time parameter, @@ -123,7 +123,7 @@ Otherwise, a number given as an unsigned integer will limit processing. .PP .SS -P <name>, --prefix <name> When dumping pcap files into a folder, a file name prefix can be defined with -this option. If not otherwise specified, the default prefix is \[lq]dump-\[rq] +this option. If not otherwise specified, the default prefix is \[lq]dump\-\[rq] followed by a Unix timestamp. Use \[lq]--prefex ""\[rq] to set filename as seconds since the Unix Epoch e.g. 1369179203.pcap .PP @@ -131,14 +131,14 @@ since the Unix Epoch e.g. 1369179203.pcap Specify a pcap type for storage. Different pcap types with their various meta data capabilities are shown with option \[lq]-D\[rq]. If not otherwise specified, the pcap-magic 0xa1b2c3d4, also known as a standard tcpdump-capable pcap format, is -used. Pcap files with swapped endianess are also supported. +used. Pcap files with swapped endianness are also supported. .PP .SS -D, --dump-pcap-types Dump all available pcap types with their capabilities and magic numbers that -can be used with option \[lq]-T\[rq] to stdout and exit. +can be used with option \[lq]\-T\[rq] to stdout and exit. .PP .SS -B, --dump-bpf -If a Berkeley Packet Filter is given, for example via option \[lq]-f\[rq], then +If a Berkeley Packet Filter is given, for example via option \[lq]\-f\[rq], then dump the BPF disassembly to stdout during ring setup. This only serves for informative or verification purposes. .PP @@ -179,7 +179,7 @@ manually be prolonged, for instance. .SS -b <cpu>, --bind-cpu <cpu> Pin netsniff-ng to a specific CPU and also pin resp. migrate the NIC's IRQ CPU affinity to this CPU. This option should be preferred in combination with -\[lq]-s\[rq] in case a middle to high packet rate is expected. +\[lq]\-s\[rq] in case a middle to high packet rate is expected. .PP .SS -u <uid>, --user <uid> resp. -g <gid>, --group <gid> After ring setup drop privileges to a non-root user/group combination. @@ -457,7 +457,7 @@ tools, at least tcpdump or Wireshark: 0xa1b23c4d (tcpdump-capable pcap with ns resolution) 0xa1b2cd34 (Alexey Kuznetzov's pcap) .PP -Pcap files with different meta data endianess are supported by netsniff-ng +Pcap files with different meta data endianness are supported by netsniff-ng as well. .PP .SH BUGS @@ -182,7 +182,7 @@ to tell trafgen to schedule a packet only on a particular CPU: cpu(2-3): { /* packet 2 content goes here ... */ } .PP Thus, in case we have a 4 core machine with CPU0-CPU3, packet 1 will be scheduled -only on CPU1, packet 2 on CPU2 and CPU3. When using trafgen with --num option, +only on CPU1, packet 2 on CPU2 and CPU3. When using trafgen with \-\-num option, then these constraints will still be valid and the packet is fairly distributed among those CPUs. .PP @@ -201,7 +201,7 @@ Packet content can be of the following: shellcode: "\\x31\\xdb\\x8d\\x43\\x17\\x99\\xcd\\x80\\x31\\xc9" .PP Thus, a quite useless packet packet configuration might look like this (one can -verify this when running this with trafgen in combination with -V): +verify this when running this with trafgen in combination with \-V): .PP { 0xca, 42, 0b11110000, 011, 'a', "hello world", "\\x31\\xdb\\x8d\\x43\\x17\\x99\\xcd\\x80\\x31\\xc9" } @@ -241,8 +241,8 @@ Furthermore, there are two types of comments in trafgen configuration files: 2. Single-line Shell-style comments: # put comment here .PP Next to all of this, a configuration can be passed through the C preprocessor -before the trafgen compiler gets to see it with option --cpp. To give you a -taste of a more advanced example, run ``trafgen -e'', fields are commented: +before the trafgen compiler gets to see it with option \-\-cpp. To give you a +taste of a more advanced example, run ``trafgen \-e'', fields are commented: .PP /* Note: dynamic elements make trafgen slower! */ #include <stddef.h> |