[T106][ZXW-22]7520V3SCV2.01.01.02P42U09_VEC_V0.8_AP_VEC origin source commit
Change-Id: Ic6e05d89ecd62fc34f82b23dcf306c93764aec4b
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/Makefile b/ap/app/iproute2/iproute2-3.4.0/man/man8/Makefile
new file mode 100755
index 0000000..6873a4b
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/Makefile
@@ -0,0 +1,32 @@
+TARGETS = ip-address.8 ip-link.8 ip-route.8
+
+MAN8PAGES = $(TARGETS) ip.8 arpd.8 lnstat.8 routel.8 rtacct.8 rtmon.8 ss.8 \
+ tc-bfifo.8 tc-cbq-details.8 tc-cbq.8 tc-drr.8 tc-htb.8 \
+ tc-pfifo.8 tc-pfifo_fast.8 tc-prio.8 tc-red.8 tc-sfq.8 \
+ tc-tbf.8 tc.8 rtstat.8 ctstat.8 nstat.8 routef.8 \
+ tc-sfb.8 tc-netem.8 tc-choke.8 ip-tunnel.8 ip-rule.8 ip-ntable.8 \
+ ip-monitor.8 tc-stab.8 tc-hfsc.8 ip-xfrm.8 ip-netns.8 \
+ ip-neighbour.8 ip-mroute.8 ip-maddress.8 ip-addrlabel.8
+
+
+all: $(TARGETS)
+
+ip-address.8: ip-address.8.in
+ sed "s|@SYSCONFDIR@|$(CONFDIR)|g" $< > $@
+
+ip-link.8: ip-link.8.in
+ sed "s|@SYSCONFDIR@|$(CONFDIR)|g" $< > $@
+
+ip-route.8: ip-route.8.in
+ sed "s|@SYSCONFDIR@|$(CONFDIR)|g" $< > $@
+
+distclean: clean
+
+clean:
+ @rm -f $(TARGETS)
+
+install:
+ $(INSTALLDIR) $(DESTDIR)$(MANDIR)/man8
+ $(INSTALLMAN) $(MAN8PAGES) $(DESTDIR)$(MANDIR)/man8
+
+.PHONY: install clean distclean
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/arpd.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/arpd.8
new file mode 100755
index 0000000..a14044b
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/arpd.8
@@ -0,0 +1,69 @@
+.TH ARPD 8 "28 June, 2007"
+
+.SH NAME
+arpd \- userspace arp daemon.
+
+.SH SYNOPSIS
+Usage: arpd [ -lkh? ] [ -a N ] [ -b dbase ] [ -B number ] [ -f file ] [-p interval ] [ -n time ] [ -R rate ] [ interfaces ]
+
+.SH DESCRIPTION
+The
+.B arpd
+daemon collects gratuitous ARP information, saving it on local disk and feeding it to kernel on demand to avoid redundant broadcasting due to limited size of kernel ARP cache.
+
+.SH OPTIONS
+.TP
+-h -?
+Print help
+.TP
+-l
+Dump arpd database to stdout and exit. Output consists of three columns: interface index, IP address and MAC address. Negative entries for dead hosts are also shown, in this case MAC address is replaced by word FAILED followed by colon and time when the fact that host is dead was proven the last time.
+.TP
+-f <FILE>
+Read and load arpd database from FILE in text format similar dumped by option -l. Exit after load, probably listing resulting database, if option -l is also given. If FILE is -, stdin is read to get ARP table.
+.TP
+-b <DATABASE>
+location of database file. Default location is /var/lib/arpd/arpd.db
+.TP
+-a <NUMBER>
+arpd not only passively listens ARP on wire, but also send brodcast queries itself. NUMBER is number of such queries to make before destination is considered as dead. When arpd is started as kernel helper (i.e. with app_solicit enabled in sysctl or even with option -k) without this option and still did not learn enough information, you can observe 1 second gaps in service. Not fatal, but not good.
+.TP
+-k
+Suppress sending broadcast queries by kernel. It takes sense together with option -a.
+.TP
+-n <TIME>
+Timeout of negative cache. When resolution fails arpd suppresses further attempts to resolve for this period. It makes sense only together with option -k This timeout should not be too much longer than boot time of a typical host not supporting gratuitous ARP. Default value is 60 seconds.
+.TP
+-p <TIME>
+Time to wait in seconds between polling attempts to the kernel ARP table. TIME may be a floating point number. The default value is 30.
+.TP
+-R <RATE>
+Maximal steady rate of broadcasts sent by arpd in packets per second. Default value is 1.
+.TP
+-B <NUMBER>
+Number of broadcasts sent by <tt/arpd/ back to back. Default value is 3. Together with option <tt/-R/ this option allows to police broadcasting not to exceed B+R*T over any interval of time T.
+.P
+<INTERFACE> is the name of networking interface to watch. If no interfaces given, arpd monitors all the interfaces. In this case arpd does not adjust sysctl parameters, it is supposed user does this himself after arpd is started.
+.P
+Signals
+.br
+arpd exits gracefully syncing database and restoring adjusted sysctl parameters, when receives SIGINT or SIGTERM. SIGHUP syncs database to disk. SIGUSR1 sends some statistics to syslog. Effect of another signals is undefined, they may corrupt database and leave sysctl praameters in an unpredictable state.
+.P
+Note
+.br
+In order for arpd to be able to serve as ARP resolver, kernel must be compiled with the option CONFIG_ARPD and, in the case when interface list in not given on command line, variable app_solicit on interfaces of interest should be in /proc/sys/net/ipv4/neigh/*. If this is not made arpd still collects gratuitous ARP information in its database.
+.SH EXAMPLES
+.TP
+arpd -b /var/tmp/arpd.db
+Start arpd to collect gratuitous ARP, but not messing with kernel functionality.
+.TP
+killall arpd ; arpd -l -b /var/tmp/arpd.db
+Look at result after some time.
+.TP
+arpd -b /var/tmp/arpd.db -a 1 eth0 eth1
+Enable kernel helper, leaving leading role to kernel.
+.TP
+arpd -b /var/tmp/arpd.db -a 3 -k eth0 eth1
+Completely replace kernel resolution on interfaces eth0 and eth1. In this case kernel still does unicast probing to validate entries, but all the broadcast activity is suppressed and made under authority of arpd.
+.PP
+This is mode which arpd is supposed to work normally. It is not default just to prevent occasional enabling of too aggressive mode occasionally.
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ctstat.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ctstat.8
new file mode 100755
index 0000000..080e2b2
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ctstat.8
@@ -0,0 +1 @@
+.so man8/lnstat.8
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-address.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-address.8
new file mode 100755
index 0000000..2eb0709
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-address.8
@@ -0,0 +1,280 @@
+.TH "IP\-ADDRESS" 8 "04 March 2012" "iproute2" "Linux"
+.SH "NAME"
+ip-address \- protocol address management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B address
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.BR "ip address" " { " add " | " change " | " replace " } "
+.IB IFADDR " dev " STRING
+.RI "[ " LIFETIME " ] [ " CONFFLAG-LIST " ]"
+
+.ti -8
+.BR "ip address del"
+.IB IFADDR " dev " STRING
+
+.ti -8
+.BR "ip address" " { " show " | " flush " } [ " dev
+.IR STRING " ] [ "
+.B scope
+.IR SCOPE-ID " ] [ "
+.B to
+.IR PREFIX " ] [ " FLAG-LIST " ] [ "
+.B label
+.IR PATTERN " ]"
+
+.ti -8
+.IR IFADDR " := " PREFIX " | " ADDR
+.B peer
+.IR PREFIX " [ "
+.B broadcast
+.IR ADDR " ] [ "
+.B anycast
+.IR ADDR " ] [ "
+.B label
+.IR STRING " ] [ "
+.B scope
+.IR SCOPE-ID " ]"
+
+.ti -8
+.IR SCOPE-ID " := "
+.RB "[ " host " | " link " | " global " | "
+.IR NUMBER " ]"
+
+.ti -8
+.IR FLAG-LIST " := [ " FLAG-LIST " ] " FLAG
+
+.ti -8
+.IR FLAG " := "
+.RB "[ " permanent " | " dynamic " | " secondary " | " primary " | "\
+tentative " | " deprecated " | " dadfailed " | " temporary " | " CONFFLAG-LIST " ]"
+
+.ti -8
+.IR CONFFLAG-LIST " := [ " CONFFLAG-LIST " ] " CONFFLAG
+
+.ti -8
+.IR CONFFLAG " := "
+.RB "[ " home " | " nodad " ]"
+
+.ti -8
+.IR LIFETIME " := [ "
+.BI valid_lft " LFT"
+.RB "| " preferred_lft
+.IR LFT " ]"
+
+.ti -8
+.IR LFT " := [ "
+.BR forever " |"
+.IR SECONDS " ]"
+
+.SH "DESCRIPTION"
+The
+.B address
+is a protocol (IPv4 or IPv6) address attached
+to a network device. Each device must have at least one address
+to use the corresponding protocol. It is possible to have several
+different addresses attached to one device. These addresses are not
+discriminated, so that the term
+.B alias
+is not quite appropriate for them and we do not use it in this document.
+.sp
+The
+.B ip address
+command displays addresses and their properties, adds new addresses
+and deletes old ones.
+
+.SS ip address add - add new protocol address.
+
+.TP
+.BI dev " NAME"
+the name of the device to add the address to.
+
+.TP
+.BI local " ADDRESS " (default)
+the address of the interface. The format of the address depends
+on the protocol. It is a dotted quad for IP and a sequence of
+hexadecimal halfwords separated by colons for IPv6. The
+.I ADDRESS
+may be followed by a slash and a decimal number which encodes
+the network prefix length.
+
+.TP
+.BI peer " ADDRESS"
+the address of the remote endpoint for pointopoint interfaces.
+Again, the
+.I ADDRESS
+may be followed by a slash and a decimal number, encoding the network
+prefix length. If a peer address is specified, the local address
+cannot have a prefix length. The network prefix is associated
+with the peer rather than with the local address.
+
+.TP
+.BI broadcast " ADDRESS"
+the broadcast address on the interface.
+.sp
+It is possible to use the special symbols
+.B '+'
+and
+.B '-'
+instead of the broadcast address. In this case, the broadcast address
+is derived by setting/resetting the host bits of the interface prefix.
+
+.TP
+.BI label " NAME"
+Each address may be tagged with a label string.
+In order to preserve compatibility with Linux-2.0 net aliases,
+this string must coincide with the name of the device or must be prefixed
+with the device name followed by colon.
+
+.TP
+.BI scope " SCOPE_VALUE"
+the scope of the area where this address is valid.
+The available scopes are listed in file
+.BR "/etc/iproute2/rt_scopes" .
+Predefined scope values are:
+
+.in +8
+.B global
+- the address is globally valid.
+.sp
+.B link
+- the address is link local, i.e. it is valid only on this device.
+.sp
+.B host
+- the address is valid only inside this host.
+.in -8
+
+.TP
+.BI valid_lft " LFT"
+(IPv6 only) the valid lifetime of this address; see section 5.5.4 of
+RFC 4862. Defaults to
+.BR "forever" .
+
+.TP
+.BI preferred_lft " LFT"
+(IPv6 only) the preferred lifetime of this address; see section 5.5.4
+of RFC 4862. Defaults to
+.BR "forever" .
+
+.TP
+.B home
+(IPv6 only) designates this address the "home address" as defined in
+RFC 6275.
+
+.TP
+.B nodad
+(IPv6 only) do not perform Duplicate Address Detection (RFC 4862) when
+adding this address.
+
+.SS ip address delete - delete protocol address
+.B Arguments:
+coincide with the arguments of
+.B ip addr add.
+The device name is a required argument. The rest are optional.
+If no arguments are given, the first address is deleted.
+
+.SS ip address show - look at protocol addresses
+
+.TP
+.BI dev " NAME " (default)
+name of device.
+
+.TP
+.BI scope " SCOPE_VAL"
+only list addresses with this scope.
+
+.TP
+.BI to " PREFIX"
+only list addresses matching this prefix.
+
+.TP
+.BI label " PATTERN"
+only list addresses with labels matching the
+.IR "PATTERN" .
+.I PATTERN
+is a usual shell style pattern.
+
+.TP
+.BR dynamic " and " permanent
+(IPv6 only) only list addresses installed due to stateless
+address configuration or only list permanent (not dynamic)
+addresses.
+
+.TP
+.B tentative
+(IPv6 only) only list addresses which have not yet passed duplicate
+address detection.
+
+.TP
+.B deprecated
+(IPv6 only) only list deprecated addresses.
+
+.TP
+.B dadfailed
+(IPv6 only) only list addresses which have failed duplicate
+address detection.
+
+.TP
+.B temporary
+(IPv6 only) only list temporary addresses.
+
+.TP
+.BR primary " and " secondary
+only list primary (or secondary) addresses.
+
+.SS ip address flush - flush protocol addresses
+This command flushes the protocol addresses selected by some criteria.
+
+.PP
+This command has the same arguments as
+.B show.
+The difference is that it does not run when no arguments are given.
+
+.PP
+.B Warning:
+This command and other
+.B flush
+commands are unforgiving. They will cruelly purge all the addresses.
+
+.PP
+With the
+.B -statistics
+option, the command becomes verbose. It prints out the number of deleted
+addresses and the number of rounds made to flush the address list.
+If this option is given twice,
+.B ip address flush
+also dumps all the deleted addresses in the format described in the
+previous subsection.
+
+.SH "EXAMPLES"
+.PP
+ip address show dev eth0
+.RS 4
+Shows the addresses assigned to network interface eth0
+.RE
+.PP
+ip addr add 2001:0db8:85a3::0370:7334/64 dev eth1
+.RS 4
+Adds an IPv6 address to network interface eth1
+.RE
+.PP
+ip addr flush dev eth4
+.RS 4
+Removes all addresses from device eth4
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-address.8.in b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-address.8.in
new file mode 100755
index 0000000..63bf9cb
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-address.8.in
@@ -0,0 +1,240 @@
+.TH "IP\-ADDRESS" 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-address \- protocol address management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B address
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.BR "ip address" " { " add " | " del " } "
+.IB IFADDR " dev " STRING
+
+.ti -8
+.BR "ip address" " { " show " | " flush " } [ " dev
+.IR STRING " ] [ "
+.B scope
+.IR SCOPE-ID " ] [ "
+.B to
+.IR PREFIX " ] [ " FLAG-LIST " ] [ "
+.B label
+.IR PATTERN " ]"
+
+.ti -8
+.IR IFADDR " := " PREFIX " | " ADDR
+.B peer
+.IR PREFIX " [ "
+.B broadcast
+.IR ADDR " ] [ "
+.B anycast
+.IR ADDR " ] [ "
+.B label
+.IR STRING " ] [ "
+.B scope
+.IR SCOPE-ID " ]"
+
+.ti -8
+.IR SCOPE-ID " := "
+.RB "[ " host " | " link " | " global " | "
+.IR NUMBER " ]"
+
+.ti -8
+.IR FLAG-LIST " := [ " FLAG-LIST " ] " FLAG
+
+.ti -8
+.IR FLAG " := "
+.RB "[ " permanent " | " dynamic " | " secondary " | " primary " | "\
+tentative " | " deprecated " | " dadfailed " | " temporary " ]"
+
+.SH "DESCRIPTION"
+The
+.B address
+is a protocol (IP or IPv6) address attached
+to a network device. Each device must have at least one address
+to use the corresponding protocol. It is possible to have several
+different addresses attached to one device. These addresses are not
+discriminated, so that the term
+.B alias
+is not quite appropriate for them and we do not use it in this document.
+.sp
+The
+.B ip address
+command displays addresses and their properties, adds new addresses
+and deletes old ones.
+
+.SS ip address add - add new protocol address.
+
+.TP
+.BI dev " NAME"
+the name of the device to add the address to.
+
+.TP
+.BI local " ADDRESS " (default)
+the address of the interface. The format of the address depends
+on the protocol. It is a dotted quad for IP and a sequence of
+hexadecimal halfwords separated by colons for IPv6. The
+.I ADDRESS
+may be followed by a slash and a decimal number which encodes
+the network prefix length.
+
+.TP
+.BI peer " ADDRESS"
+the address of the remote endpoint for pointopoint interfaces.
+Again, the
+.I ADDRESS
+may be followed by a slash and a decimal number, encoding the network
+prefix length. If a peer address is specified, the local address
+cannot have a prefix length. The network prefix is associated
+with the peer rather than with the local address.
+
+.TP
+.BI broadcast " ADDRESS"
+the broadcast address on the interface.
+.sp
+It is possible to use the special symbols
+.B '+'
+and
+.B '-'
+instead of the broadcast address. In this case, the broadcast address
+is derived by setting/resetting the host bits of the interface prefix.
+
+.TP
+.BI label " NAME"
+Each address may be tagged with a label string.
+In order to preserve compatibility with Linux-2.0 net aliases,
+this string must coincide with the name of the device or must be prefixed
+with the device name followed by colon.
+
+.TP
+.BI scope " SCOPE_VALUE"
+the scope of the area where this address is valid.
+The available scopes are listed in file
+.BR "@SYSCONFDIR@/rt_scopes" .
+Predefined scope values are:
+
+.in +8
+.B global
+- the address is globally valid.
+.sp
+.B site
+- (IPv6 only) the address is site local, i.e. it is
+valid inside this site.
+.sp
+.B link
+- the address is link local, i.e. it is valid only on this device.
+.sp
+.B host
+- the address is valid only inside this host.
+.in -8
+
+.SS ip address delete - delete protocol address
+.B Arguments:
+coincide with the arguments of
+.B ip addr add.
+The device name is a required argument. The rest are optional.
+If no arguments are given, the first address is deleted.
+
+.SS ip address show - look at protocol addresses
+
+.TP
+.BI dev " NAME " (default)
+name of device.
+
+.TP
+.BI scope " SCOPE_VAL"
+only list addresses with this scope.
+
+.TP
+.BI to " PREFIX"
+only list addresses matching this prefix.
+
+.TP
+.BI label " PATTERN"
+only list addresses with labels matching the
+.IR "PATTERN" .
+.I PATTERN
+is a usual shell style pattern.
+
+.TP
+.BR dynamic " and " permanent
+(IPv6 only) only list addresses installed due to stateless
+address configuration or only list permanent (not dynamic)
+addresses.
+
+.TP
+.B tentative
+(IPv6 only) only list addresses which have not yet passed duplicate
+address detection.
+
+.TP
+.B deprecated
+(IPv6 only) only list deprecated addresses.
+
+.TP
+.B dadfailed
+(IPv6 only) only list addresses which have failed duplicate
+address detection.
+
+.TP
+.B temporary
+(IPv6 only) only list temporary addresses.
+
+.TP
+.BR primary " and " secondary
+only list primary (or secondary) addresses.
+
+.SS ip address flush - flush protocol addresses
+This command flushes the protocol addresses selected by some criteria.
+
+.PP
+This command has the same arguments as
+.B show.
+The difference is that it does not run when no arguments are given.
+
+.PP
+.B Warning:
+This command (and other
+.B flush
+commands described below) is pretty dangerous. If you make a mistake,
+it will not forgive it, but will cruelly purge all the addresses.
+
+.PP
+With the
+.B -statistics
+option, the command becomes verbose. It prints out the number of deleted
+addresses and the number of rounds made to flush the address list. If
+this option is given twice,
+.B ip address flush
+also dumps all the deleted addresses in the format described in the
+previous subsection.
+
+.SH "EXAMPLES"
+.PP
+ip address show dev eth0
+.RS 4
+Shows the addresses assigned to network interface eth0
+.RE
+.PP
+ip addr add 2001:0db8:85a3::0370:7334/64 dev eth1
+.RS 4
+Adds an IPv6 address to network interface eth1
+.RE
+.PP
+ip addr flush dev eth4
+.RS 4
+Removes all addresses from device eth4
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-addrlabel.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-addrlabel.8
new file mode 100755
index 0000000..3252bd2
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-addrlabel.8
@@ -0,0 +1,69 @@
+.TH IP\-ADDRLABEL 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-addrlabel \- protocol address label management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B addrlabel
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.IR OPTIONS " := { "
+\fB\-V\fR[\fIersion\fR] |
+\fB\-s\fR[\fItatistics\fR] |
+\fB\-r\fR[\fIesolve\fR] |
+\fB\-f\fR[\fIamily\fR] {
+.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
+\fB\-o\fR[\fIneline\fR] }
+
+.ti -8
+.BR "ip addrlabel" " { " add " | " del " } " prefix
+.BR PREFIX " [ "
+.B dev
+.IR DEV " ] [ "
+.B label
+.IR NUMBER " ]"
+
+.ti -8
+.BR "ip addrlabel" " { " list " | " flush " }"
+
+.SH "DESCRIPTION"
+IPv6 address label is used for address selection
+described in RFC 3484. Precedence is managed by userspace,
+and only label is stored in kernel.
+
+.SS ip addrlabel add - add an address label
+the command adds an address label entry to the kernel.
+.TP
+.BI prefix " PREFIX"
+.TP
+.BI dev " DEV"
+the outgoing interface.
+.TP
+.BI label " NUMBER"
+the label for the prefix.
+0xffffffff is reserved.
+.SS ip addrlabel del - delete an address label
+the command deletes an address label entry in the kernel.
+.B Arguments:
+coincide with the arguments of
+.B ip addrlabel add
+but label is not required.
+.SS ip addrlabel list - list address labels
+the command show contents of address labels.
+.SS ip addrlabel flush - flush address labels
+the command flushes the contents of address labels and it does not restore default settings.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Manpage by Yoshifuji Hideaki / 吉藤英明
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-l2tp.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-l2tp.8
new file mode 100755
index 0000000..18a83d4
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-l2tp.8
@@ -0,0 +1,376 @@
+.TH IP\-L2TP 8 "19 Apr 2012" "iproute2" "Linux"
+.SH "NAME"
+ip-l2tp - L2TPv3 static unmanaged tunnel configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B l2tp
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+.BR "ip l2tp add tunnel"
+.br
+.B remote
+.RI "[ " ADDR " ]"
+.B local
+.RI "[ " ADDR " ]"
+.br
+.B tunnel_id
+.IR ID
+.B peer_tunnel_id
+.IR ID
+.br
+.RB "[ " encap " { " ip " | " udp " } ]"
+.br
+.RB "[ " udp_sport
+.IR PORT
+.RB " ] [ " udp_dport
+.IR PORT
+.RB " ]"
+.br
+.ti -8
+.BR "ip l2tp add session"
+.RB "[ " name
+.IR NAME
+.RB " ]"
+.br
+.B tunnel_id
+.IR ID
+.B session_id
+.IR ID
+.B peer_session_id
+.IR ID
+.br
+.RB "[ " cookie
+.IR HEXSTR
+.RB " ] [ " peer_cookie
+.IR HEXSTR
+.RB " ]"
+.br
+.RB "[ " offset
+.IR OFFSET
+.RB " ] [ " peer_offset
+.IR OFFSET
+.RB " ]"
+.br
+.ti -8
+.BR "ip l2tp del tunnel"
+.B tunnel_id
+.IR ID
+.br
+.ti -8
+.BR "ip l2tp del session"
+.B tunnel_id
+.IR ID
+.B session_id
+.IR ID
+.br
+.ti -8
+.BR "ip l2tp show tunnel"
+.B "[" tunnel_id
+.IR ID
+.B "]"
+.br
+.ti -8
+.BR "ip l2tp show session"
+.B "[" tunnel_id
+.IR ID
+.B "] [" session_id
+.IR ID
+.B "]"
+.br
+.ti -8
+.IR NAME " := "
+.IR STRING
+.ti -8
+.IR ADDR " := { " IP_ADDRESS " }"
+.ti -8
+.IR PORT " := { " NUMBER " }"
+.ti -8
+.IR ID " := { " NUMBER " }"
+.ti -8
+.ti -8
+.IR HEXSTR " := { 8 or 16 hex digits (4 / 8 bytes) }"
+.SH DESCRIPTION
+The
+.B ip l2tp
+commands are used to establish static, or so-called
+.I unmanaged
+L2TPv3 ethernet tunnels. For unmanaged tunnels, there is no L2TP
+control protocol so no userspace daemon is required - tunnels are
+manually created by issuing commands at a local system and at a remote
+peer.
+.PP
+L2TPv3 is suitable for Layer-2 tunnelling. Static tunnels are useful
+to establish network links across IP networks when the tunnels are
+fixed. L2TPv3 tunnels can carry data of more than one session. Each
+session is identified by a session_id and its parent tunnel's
+tunnel_id. A tunnel must be created before a session can be created in
+the tunnel.
+.PP
+When creating an L2TP tunnel, the IP address of the remote peer is
+specified, which can be either an IPv4 or IPv6 address. The local IP
+address to be used to reach the peer must also be specified. This is
+the address on which the local system will listen for and accept
+received L2TP data packets from the peer.
+.PP
+L2TPv3 defines two packet encapsulation formats: UDP or IP. UDP
+encapsulation is most common. IP encapsulation uses a dedicated IP
+protocol value to carry L2TP data without the overhead of UDP. Use IP
+encapsulation only when there are no NAT devices or firewalls in the
+network path.
+.PP
+When an L2TPv3 ethernet session is created, a virtual network
+interface is created for the session, which must then be configured
+and brought up, just like any other network interface. When data is
+passed through the interface, it is carried over the L2TP tunnel to
+the peer. By configuring the system's routing tables or adding the
+interface to a bridge, the L2TP interface is like a virtual wire
+(pseudowire) connected to the peer.
+.PP
+Establishing an unmanaged L2TPv3 ethernet pseudowire involves manually
+creating L2TP contexts on the local system and at the peer. Parameters
+used at each site must correspond or no data will be passed. No
+consistency checks are possible since there is no control protocol
+used to establish unmanaged L2TP tunnels. Once the virtual network
+interface of a given L2TP session is configured and enabled, data can
+be transmitted, even if the peer isn't yet configured. If the peer
+isn't configured, the L2TP data packets will be discarded by
+the peer.
+.PP
+To establish an unmanaged L2TP tunnel, use
+.B l2tp add tunnel
+and
+.B l2tp add session
+commands described in this document. Then configure and enable the
+tunnel's virtual network interface, as required.
+.PP
+Note that unmanaged tunnels carry only ethernet frames. If you need to
+carry PPP traffic (L2TPv2) or your peer doesn't support unmanaged
+L2TPv3 tunnels, you will need an L2TP server which implements the L2TP
+control protocol. The L2TP control protocol allows dynamic L2TP
+tunnels and sessions to be established and provides for detecting and
+acting upon network failures.
+.SS ip l2tp add tunnel - add a new tunnel
+.TP
+.BI name " NAME "
+sets the session network interface name. Default is l2tpethN.
+.TP
+.BI tunnel_id " ID"
+set the tunnel id, which is a 32-bit integer value. Uniquely
+identifies the tunnel. The value used must match the peer_tunnel_id
+value being used at the peer.
+.TP
+.BI peer_tunnel_id " ID"
+set the peer tunnel id, which is a 32-bit integer value assigned to
+the tunnel by the peer. The value used must match the tunnel_id value
+being used at the peer.
+.TP
+.BI remote " ADDR"
+set the IP address of the remote peer. May be specified as an IPv4
+address or an IPv6 address.
+.TP
+.BI local " ADDR"
+set the IP address of the local interface to be used for the
+tunnel. This address must be the address of a local interface. May be
+specified as an IPv4 address or an IPv6 address.
+.TP
+.BI encap " ENCAP"
+set the encapsulation type of the tunnel.
+.br
+Valid values for encapsulation are:
+.BR udp ", " ip "."
+.TP
+.BI udp_sport " PORT"
+set the UDP source port to be used for the tunnel. Must be present
+when udp encapsulation is selected. Ignored when ip encapsulation is
+selected.
+.TP
+.BI udp_dport " PORT"
+set the UDP destination port to be used for the tunnel. Must be
+present when udp encapsulation is selected. Ignored when ip
+encapsulation is selected.
+.SS ip l2tp del tunnel - destroy a tunnel
+.TP
+.BI tunnel_id " ID"
+set the tunnel id of the tunnel to be deleted. All sessions within the
+tunnel must be deleted first.
+.SS ip l2tp show tunnel - show information about tunnels
+.TP
+.BI tunnel_id " ID"
+set the tunnel id of the tunnel to be shown. If not specified,
+information about all tunnels is printed.
+.SS ip l2tp add session - add a new session to a tunnel
+.TP
+.BI name " NAME "
+sets the session network interface name. Default is l2tpethN.
+.TP
+.BI tunnel_id " ID"
+set the tunnel id, which is a 32-bit integer value. Uniquely
+identifies the tunnel into which the session will be created. The
+tunnel must already exist.
+.TP
+.BI session_id " ID"
+set the session id, which is a 32-bit integer value. Uniquely
+identifies the session being created. The value used must match the
+peer_session_id value being used at the peer.
+.TP
+.BI peer_session_id " ID"
+set the peer session id, which is a 32-bit integer value assigned to
+the session by the peer. The value used must match the session_id
+value being used at the peer.
+.TP
+.BI cookie " HEXSTR"
+sets an optional cookie value to be assigned to the session. This is a
+4 or 8 byte value, specified as 8 or 16 hex digits,
+e.g. 014d3636deadbeef. The value must match the peer_cookie value set
+at the peer. The cookie value is carried in L2TP data packets and is
+checked for expected value at the peer. Default is to use no cookie.
+.TP
+.BI peer_cookie " HEXSTR"
+sets an optional peer cookie value to be assigned to the session. This
+is a 4 or 8 byte value, specified as 8 or 16 hex digits,
+e.g. 014d3636deadbeef. The value must match the cookie value set at
+the peer. It tells the local system what cookie value to expect to
+find in received L2TP packets. Default is to use no cookie.
+.TP
+.BI offset " OFFSET"
+sets the byte offset from the L2TP header where user data starts in
+transmitted L2TP data packets. This is hardly ever used. If set, the
+value must match the peer_offset value used at the peer. Default is 0.
+.TP
+.BI peer_offset " OFFSET"
+sets the byte offset from the L2TP header where user data starts in
+received L2TP data packets. This is hardly ever used. If set, the
+value must match the offset value used at the peer. Default is 0.
+.SS ip l2tp del session - destroy a session
+.TP
+.BI tunnel_id " ID"
+set the tunnel id in which the session to be deleted is located.
+.TP
+.BI session_id " ID"
+set the session id of the session to be deleted.
+.SS ip l2tp show session - show information about sessions
+.TP
+.BI tunnel_id " ID"
+set the tunnel id of the session(s) to be shown. If not specified,
+information about sessions in all tunnels is printed.
+.TP
+.BI session_id " ID"
+set the session id of the session to be shown. If not specified,
+information about all sessions is printed.
+.SH EXAMPLES
+.PP
+.SS Setup L2TP tunnels and sessions
+.nf
+site-A:# ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 \\
+ encap udp local 1.2.3.4 remote 5.6.7.8 \\
+ udp_sport 5000 udp_dport 6000
+site-A:# ip l2tp add session tunnel_id 3000 session_id 1000 \\
+ peer_session_id 2000
+
+site-B:# ip l2tp add tunnel tunnel_id 4000 peer_tunnel_id 3000 \\
+ encap udp local 5.6.7.8 remote 1.2.3.4 \\
+ udp_sport 6000 udp_dport 5000
+site-B:# ip l2tp add session tunnel_id 4000 session_id 2000 \\
+ peer_session_id 1000
+
+site-A:# ip link set l2tpeth0 up mtu 1488
+
+site-B:# ip link set l2tpeth0 up mtu 1488
+.fi
+.PP
+Notice that the IP addresses, UDP ports and tunnel / session ids are
+matched and reversed at each site.
+.SS Configure as IP interfaces
+The two interfaces can be configured with IP addresses if only IP data
+is to be carried. This is perhaps the simplest configuration.
+.PP
+.nf
+site-A:# ip addr add 10.42.1.1 peer 10.42.1.2 dev l2tpeth0
+
+site-B:# ip addr add 10.42.1.2 peer 10.42.1.1 dev l2tpeth0
+
+site-A:# ping 10.42.1.2
+.fi
+.PP
+Now the link should be usable. Add static routes as needed to have
+data sent over the new link.
+.PP
+.SS Configure as bridged interfaces
+To carry non-IP data, the L2TP network interface is added to a bridge
+instead of being assigned its own IP address, using standard Linux
+utilities. Since raw ethernet frames are then carried inside the
+tunnel, the MTU of the L2TP interfaces must be set to allow space for
+those headers.
+.PP
+.nf
+site-A:# ip link set l2tpeth0 up mtu 1446
+site-A:# brctl addbr br0
+site-A:# brctl addif br0 l2tpeth0
+site-A:# brctl addif br0 eth0
+site-A:# ip link set br0 up
+.fi
+.PP
+If you are using VLANs, setup a bridge per VLAN and bridge each VLAN
+over a separate L2TP session. For example, to bridge VLAN ID 5 on eth1
+over an L2TP pseudowire:
+.PP
+.nf
+site-A:# ip link set l2tpeth0 up mtu 1446
+site-A:# brctl addbr brvlan5
+site-A:# brctl addif brvlan5 l2tpeth0.5
+site-A:# brctl addif brvlan5 eth1.5
+site-A:# ip link set brvlan5 up
+.fi
+.PP
+Adding the L2TP interface to a bridge causes the bridge to forward
+traffic over the L2TP pseudowire just like it forwards over any other
+interface. The bridge learns MAC addresses of hosts attached to each
+interface and intelligently forwards frames from one bridge port to
+another. IP addresses are not assigned to the l2tpethN interfaces. If
+the bridge is correctly configured at both sides of the L2TP
+pseudowire, it should be possible to reach hosts in the peer's bridged
+network.
+.PP
+When raw ethernet frames are bridged across an L2TP tunnel, large
+frames may be fragmented and forwarded as individual IP fragments to
+the recipient, depending on the MTU of the physical interface used by
+the tunnel. When the ethernet frames carry protocols which are
+reassembled by the recipient, like IP, this isn't a problem. However,
+such fragmentation can cause problems for protocols like PPPoE where
+the recipient expects to receive ethernet frames exactly as
+transmitted. In such cases, it is important that frames leaving the
+tunnel are reassembled back into a single frame before being
+forwarded on. To do so, enable netfilter connection tracking
+(conntrack) or manually load the Linux netfilter degrag modules at
+each tunnel endpoint.
+.PP
+.nf
+site-A:# modprobe nf_degrag_ipv4
+
+site-B:# modprobe nf_degrag_ipv4
+.fi
+.PP
+If L2TP is being used over IPv6, use the IPv6 degrag module.
+.SH INTEROPABILITY
+.PP
+Unmanaged (static) L2TPv3 tunnels are supported by some network
+equipment equipment vendors such as Cisco.
+.PP
+In Linux, L2TP Hello messages are not supported in unmanaged
+tunnels. Hello messages are used by L2TP clients and servers to detect
+link failures in order to automate tearing down and reestablishing
+dynamic tunnels. If a non-Linux peer supports Hello messages in
+unmanaged tunnels, it must be turned off to interoperate with Linux.
+.SH SEE ALSO
+.br
+.BR brctl (8)
+.BR ip (8)
+.SH AUTHOR
+James Chapman <jchapman@katalix.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-link.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-link.8
new file mode 100755
index 0000000..24d2ec7
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-link.8
@@ -0,0 +1,394 @@
+.TH IP\-LINK 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-link \- network device configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B link
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.IR OPTIONS " := { "
+\fB\-V\fR[\fIersion\fR] |
+\fB\-s\fR[\fItatistics\fR] |
+\fB\-r\fR[\fIesolve\fR] |
+\fB\-f\fR[\fIamily\fR] {
+.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
+\fB\-o\fR[\fIneline\fR] }
+
+.ti -8
+.BI "ip link add"
+.RB "[ " link
+.IR DEVICE " ]"
+.RB "[ " name " ]"
+.I NAME
+.br
+.RB "[ " txqueuelen
+.IR PACKETS " ]"
+.br
+.RB "[ " address
+.IR LLADDR " ]"
+.RB "[ " broadcast
+.IR LLADDR " ]"
+.br
+.RB "[ " mtu
+.IR MTU " ]"
+.br
+.BR type " TYPE"
+.RI "[ " ARGS " ]"
+
+.ti -8
+.IR TYPE " := [ "
+.BR vlan " | " veth " | " vcan " | " dummy " | " ifb " | " macvlan " | " can " | " bridge " ]"
+
+.ti -8
+.BI "ip link delete " DEVICE
+.BI type " TYPE"
+.RI "[ " ARGS " ]"
+
+.ti -8
+.BR "ip link set " {
+.IR DEVICE " | "
+.BI "group " GROUP
+.RB "} { " up " | " down " | " arp " { " on " | " off " } |"
+.br
+.BR promisc " { " on " | " off " } |"
+.br
+.BR allmulticast " { " on " | " off " } |"
+.br
+.BR dynamic " { " on " | " off " } |"
+.br
+.BR multicast " { " on " | " off " } |"
+.br
+.B txqueuelen
+.IR PACKETS " |"
+.br
+.B name
+.IR NEWNAME " |"
+.br
+.B address
+.IR LLADDR " |"
+.B broadcast
+.IR LLADDR " |"
+.br
+.B mtu
+.IR MTU " |"
+.br
+.B netns
+.IR PID " |"
+.br
+.B netns
+.IR NETNSNAME " |"
+.br
+.B alias
+.IR NAME " |"
+.br
+.B vf
+.IR NUM " ["
+.B mac
+.IR LLADDR " ] ["
+.B vlan
+.IR VLANID " [ "
+.B qos
+.IR VLAN-QOS " ] ] ["
+.B rate
+.IR TXRATE " ] ["
+.B spoofchk { on | off }
+] |
+.br
+.B mode
+.IR LINKMODE " |"
+.br
+.B state
+.IR LINKSTATE " |"
+.br
+.B master
+.IR DEVICE
+.br
+.B nomaster
+.BR " }"
+
+
+.ti -8
+.B ip link show
+.RI "[ " DEVICE " | "
+.B group
+.IR GROUP " ]"
+
+.SH "DESCRIPTION"
+.SS ip link add - add virtual link
+
+.TP
+.BI link " DEVICE "
+specifies the physical device to act operate on.
+
+.I NAME
+specifies the name of the new virtual device.
+
+.I TYPE
+specifies the type of the new device.
+.sp
+Link types:
+
+.in +8
+.B vlan
+- 802.1q tagged virtual LAN interface
+.sp
+.B veth
+- Virtual ethernet interface
+.sp
+.B vcan
+- Virtual Local CAN interface
+.sp
+.B dummy
+- Dummy network interface
+.sp
+.B ifb
+- Intermediate Functional Block device
+.sp
+.B macvlan
+- virtual interface base on link layer address (MAC)
+.sp
+.B can
+- Controller Area Network interface
+.sp
+.B bridge
+- Ethernet Bridge device
+.in -8
+
+.SS ip link delete - delete virtual link
+.I DEVICE
+specifies the virtual device to act operate on.
+.I TYPE
+specifies the type of the device.
+
+
+.TP
+.BI dev " DEVICE "
+specifies the physical device to act operate on.
+
+.SS ip link set - change device attributes
+
+.TP
+.BI dev " DEVICE "
+.I DEVICE
+specifies network device to operate on. When configuring SR-IOV Virtual Fuction
+(VF) devices, this keyword should specify the associated Physical Function (PF)
+device.
+
+.TP
+.BI group " GROUP "
+.I GROUP
+has a dual role: If both group and dev are present, then move the device to the
+specified group. If only a group is specified, then the command operates on
+all devices in that group.
+
+.TP
+.BR up " and " down
+change the state of the device to
+.B UP
+or
+.BR "DOWN" .
+
+.TP
+.BR "arp on " or " arp off"
+change the
+.B NOARP
+flag on the device.
+
+.TP
+.BR "multicast on " or " multicast off"
+change the
+.B MULTICAST
+flag on the device.
+
+.TP
+.BR "dynamic on " or " dynamic off"
+change the
+.B DYNAMIC
+flag on the device.
+
+.TP
+.BI name " NAME"
+change the name of the device. This operation is not
+recommended if the device is running or has some addresses
+already configured.
+
+.TP
+.BI txqueuelen " NUMBER"
+.TP
+.BI txqlen " NUMBER"
+change the transmit queue length of the device.
+
+.TP
+.BI mtu " NUMBER"
+change the
+.I MTU
+of the device.
+
+.TP
+.BI address " LLADDRESS"
+change the station address of the interface.
+
+.TP
+.BI broadcast " LLADDRESS"
+.TP
+.BI brd " LLADDRESS"
+.TP
+.BI peer " LLADDRESS"
+change the link layer broadcast address or the peer address when
+the interface is
+.IR "POINTOPOINT" .
+
+.TP
+.BI netns " PID"
+move the device to the network namespace associated with the process
+.IR "PID".
+
+.TP
+.BI netns " NETNSNAME"
+move the device to the network namespace associated with name
+.IR "NETNSNAME".
+
+.TP
+.BI mode " LINKMODE"
+allows setting link mode which determines which RFC2863 operational state
+the device will transistion to when it is brought up. Setting
+.I dormant
+mode changes the behaviour so that device goes into DORMANT state instead
+of UP when driver is ready.
+
+.TP
+.BI state " LINKSTATE"
+allows setting the operational link state. The values (defined in RFC2863)
+are: UP, DOWN, TESTING, UNKNOWN, DORMANT, NOTPRESENT, LOWERLAYERDOWN.
+.TP
+.BI alias " NAME"
+give the device a symbolic name for easy reference.
+
+.TP
+.BI group " GROUP"
+specify the group the device belongs to.
+The available groups are listed in file
+.BR "/etc/iproute2/group" .
+
+.TP
+.BI vf " NUM"
+specify a Virtual Function device to be configured. The associated PF device
+must be specified using the
+.B dev
+parameter.
+
+.in +8
+.BI mac " LLADDRESS"
+- change the station address for the specified VF. The
+.B vf
+parameter must be specified.
+
+.sp
+.BI vlan " VLANID"
+- change the assigned VLAN for the specified VF. When specified, all traffic
+sent from the VF will be tagged with the specified VLAN ID. Incoming traffic
+will be filtered for the specified VLAN ID, and will have all VLAN tags
+stripped before being passed to the VF. Setting this parameter to 0 disables
+VLAN tagging and filtering. The
+.B vf
+parameter must be specified.
+
+.sp
+.BI qos " VLAN-QOS"
+- assign VLAN QOS (priority) bits for the VLAN tag. When specified, all VLAN
+tags transmitted by the VF will include the specified priority bits in the
+VLAN tag. If not specified, the value is assumed to be 0. Both the
+.B vf
+and
+.B vlan
+parameters must be specified. Setting both
+.B vlan
+and
+.B qos
+as 0 disables VLAN tagging and filtering for the VF.
+
+.sp
+.BI rate " TXRATE"
+- change the allowed transmit bandwidth, in Mbps, for the specified VF.
+Setting this parameter to 0 disables rate limiting. The
+.B vf
+parameter must be specified.
+
+.sp
+.BI spoofchk " on|off"
+- turn packet spoof checking on or off for the specified VF.
+.in -8
+
+.TP
+.BI master " DEVICE"
+set master device of the device (enslave device).
+
+.TP
+.BI nomaster
+unset master device of the device (release device).
+
+.PP
+.B Warning:
+If multiple parameter changes are requested,
+.B ip
+aborts immediately after any of the changes have failed.
+This is the only case when
+.B ip
+can move the system to an unpredictable state. The solution
+is to avoid changing several parameters with one
+.B ip link set
+call.
+
+.SS ip link show - display device attributes
+
+.TP
+.BI dev " NAME " (default)
+.I NAME
+specifies the network device to show.
+If this argument is omitted all devices in the default group are listed.
+
+.TP
+.BI group " GROUP "
+.I GROUP
+specifies what group of devices to show.
+
+.TP
+.B up
+only display running interfaces.
+
+.SH "EXAMPLES"
+.PP
+ip link show
+.RS 4
+Shows the state of all network interfaces on the system.
+.RE
+.PP
+ip link set dev ppp0 mtu 1400
+.RS 4
+Change the MTU the ppp0 device.
+.RE
+.PP
+ip link add link eth0 name eth0.10 type vlan id 10
+.RS 4
+Creates a new vlan device eth0.10 on device eth0.
+.RE
+.PP
+ip link delete dev eth0.10
+.RS 4
+Removes vlan device.
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-link.8.in b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-link.8.in
new file mode 100755
index 0000000..9386cc6
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-link.8.in
@@ -0,0 +1,376 @@
+.TH IP\-LINK 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-link \- network device configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B link
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.IR OPTIONS " := { "
+\fB\-V\fR[\fIersion\fR] |
+\fB\-s\fR[\fItatistics\fR] |
+\fB\-r\fR[\fIesolve\fR] |
+\fB\-f\fR[\fIamily\fR] {
+.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
+\fB\-o\fR[\fIneline\fR] }
+
+.ti -8
+.BI "ip link add"
+.RB "[ " link
+.IR DEVICE " ]"
+.RB "[ " name " ]"
+.I NAME
+.br
+.RB "[ " txqueuelen
+.IR PACKETS " ]"
+.br
+.RB "[ " address
+.IR LLADDR " ]"
+.RB "[ " broadcast
+.IR LLADDR " ]"
+.br
+.RB "[ " mtu
+.IR MTU " ]"
+.br
+.BR type " TYPE"
+.RI "[ " ARGS " ]"
+
+.ti -8
+.IR TYPE " := [ "
+.BR vlan " | " veth " | " vcan " | " dummy " | " ifb " | " macvlan " | " can " | " bridge " ]"
+
+.ti -8
+.BI "ip link delete " DEVICE
+.BI type " TYPE"
+.RI "[ " ARGS " ]"
+
+.ti -8
+.BR "ip link set " {
+.IR DEVICE " | "
+.BI "group " GROUP
+.RB "} { " up " | " down " | " arp " { " on " | " off " } |"
+.br
+.BR promisc " { " on " | " off " } |"
+.br
+.BR allmulticast " { " on " | " off " } |"
+.br
+.BR dynamic " { " on " | " off " } |"
+.br
+.BR multicast " { " on " | " off " } |"
+.br
+.B txqueuelen
+.IR PACKETS " |"
+.br
+.B name
+.IR NEWNAME " |"
+.br
+.B address
+.IR LLADDR " |"
+.B broadcast
+.IR LLADDR " |"
+.br
+.B mtu
+.IR MTU " |"
+.br
+.B netns
+.IR PID " |"
+.br
+.B netns
+.IR NETNSNAME " |"
+.br
+.B alias
+.IR NAME " |"
+.br
+.B vf
+.IR NUM " ["
+.B mac
+.IR LLADDR " ] ["
+.B vlan
+.IR VLANID " [ "
+.B qos
+.IR VLAN-QOS " ] ] ["
+.B rate
+.IR TXRATE " ] ["
+.B spoofchk { on | off }
+] |
+.br
+.B master
+.IR DEVICE
+.br
+.B nomaster
+.BR " }"
+
+
+.ti -8
+.B ip link show
+.RI "[ " DEVICE " | "
+.B group
+.IR GROUP " ]"
+
+.SH "DESCRIPTION"
+.SS ip link add - add virtual link
+
+.TP
+.BI link " DEVICE "
+specifies the physical device to act operate on.
+
+.I NAME
+specifies the name of the new virtual device.
+
+.I TYPE
+specifies the type of the new device.
+.sp
+Link types:
+
+.in +8
+.B vlan
+- 802.1q tagged virtual LAN interface
+.sp
+.B veth
+- Virtual ethernet interface
+.sp
+.B vcan
+- Virtual Local CAN interface
+.sp
+.B dummy
+- Dummy network interface
+.sp
+.B ifb
+- Intermediate Functional Block device
+.sp
+.B macvlan
+- virtual interface base on link layer address (MAC)
+.sp
+.B can
+- Controller Area Network interface
+.sp
+.B bridge
+- Ethernet Bridge device
+.in -8
+
+.SS ip link delete - delete virtual link
+.I DEVICE
+specifies the virtual device to act operate on.
+.I TYPE
+specifies the type of the device.
+
+
+.TP
+.BI dev " DEVICE "
+specifies the physical device to act operate on.
+
+.SS ip link set - change device attributes
+
+.TP
+.BI dev " DEVICE "
+.I DEVICE
+specifies network device to operate on. When configuring SR-IOV Virtual Fuction
+(VF) devices, this keyword should specify the associated Physical Function (PF)
+device.
+
+.TP
+.BI group " GROUP "
+.I GROUP
+has a dual role: If both group and dev are present, then move the device to the
+specified group. If only a group is specified, then the command operates on
+all devices in that group.
+
+.TP
+.BR up " and " down
+change the state of the device to
+.B UP
+or
+.BR "DOWN" .
+
+.TP
+.BR "arp on " or " arp off"
+change the
+.B NOARP
+flag on the device.
+
+.TP
+.BR "multicast on " or " multicast off"
+change the
+.B MULTICAST
+flag on the device.
+
+.TP
+.BR "dynamic on " or " dynamic off"
+change the
+.B DYNAMIC
+flag on the device.
+
+.TP
+.BI name " NAME"
+change the name of the device. This operation is not
+recommended if the device is running or has some addresses
+already configured.
+
+.TP
+.BI txqueuelen " NUMBER"
+.TP
+.BI txqlen " NUMBER"
+change the transmit queue length of the device.
+
+.TP
+.BI mtu " NUMBER"
+change the
+.I MTU
+of the device.
+
+.TP
+.BI address " LLADDRESS"
+change the station address of the interface.
+
+.TP
+.BI broadcast " LLADDRESS"
+.TP
+.BI brd " LLADDRESS"
+.TP
+.BI peer " LLADDRESS"
+change the link layer broadcast address or the peer address when
+the interface is
+.IR "POINTOPOINT" .
+
+.TP
+.BI netns " PID"
+move the device to the network namespace associated with the process
+.IR "PID".
+
+.TP
+.BI netns " NETNSNAME"
+move the device to the network namespace associated with name
+.IR "NETNSNAME".
+
+.TP
+.BI alias " NAME"
+give the device a symbolic name for easy reference.
+
+.TP
+.BI group " GROUP"
+specify the group the device belongs to.
+The available groups are listed in file
+.BR "@SYSCONFDIR@/group" .
+
+.TP
+.BI vf " NUM"
+specify a Virtual Function device to be configured. The associated PF device
+must be specified using the
+.B dev
+parameter.
+
+.in +8
+.BI mac " LLADDRESS"
+- change the station address for the specified VF. The
+.B vf
+parameter must be specified.
+
+.sp
+.BI vlan " VLANID"
+- change the assigned VLAN for the specified VF. When specified, all traffic
+sent from the VF will be tagged with the specified VLAN ID. Incoming traffic
+will be filtered for the specified VLAN ID, and will have all VLAN tags
+stripped before being passed to the VF. Setting this parameter to 0 disables
+VLAN tagging and filtering. The
+.B vf
+parameter must be specified.
+
+.sp
+.BI qos " VLAN-QOS"
+- assign VLAN QOS (priority) bits for the VLAN tag. When specified, all VLAN
+tags transmitted by the VF will include the specified priority bits in the
+VLAN tag. If not specified, the value is assumed to be 0. Both the
+.B vf
+and
+.B vlan
+parameters must be specified. Setting both
+.B vlan
+and
+.B qos
+as 0 disables VLAN tagging and filtering for the VF.
+
+.sp
+.BI rate " TXRATE"
+- change the allowed transmit bandwidth, in Mbps, for the specified VF.
+Setting this parameter to 0 disables rate limiting. The
+.B vf
+parameter must be specified.
+
+.sp
+.BI spoofchk " on|off"
+- turn packet spoof checking on or off for the specified VF.
+.in -8
+
+.TP
+.BI master " DEVICE"
+set master device of the device (enslave device).
+
+.TP
+.BI nomaster
+unset master device of the device (release device).
+
+.PP
+.B Warning:
+If multiple parameter changes are requested,
+.B ip
+aborts immediately after any of the changes have failed.
+This is the only case when
+.B ip
+can move the system to an unpredictable state. The solution
+is to avoid changing several parameters with one
+.B ip link set
+call.
+
+.SS ip link show - display device attributes
+
+.TP
+.BI dev " NAME " (default)
+.I NAME
+specifies the network device to show.
+If this argument is omitted all devices in the default group are listed.
+
+.TP
+.BI group " GROUP "
+.I GROUP
+specifies what group of devices to show.
+
+.TP
+.B up
+only display running interfaces.
+
+.SH "EXAMPLES"
+.PP
+ip link show
+.RS 4
+Shows the state of all network interfaces on the system.
+.RE
+.PP
+ip link set dev ppp0 mtu 1400
+.RS 4
+Change the MTU the ppp0 device.
+.RE
+.PP
+ip link add link eth0 name eth0.10 type vlan id 10
+.RS 4
+Creates a new vlan device eth0.10 on device eth0.
+.RE
+.PP
+ip link delete dev eth0.10
+.RS 4
+Removes vlan device.
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-maddress.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-maddress.8
new file mode 100755
index 0000000..afae551
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-maddress.8
@@ -0,0 +1,54 @@
+.TH IP\-MADDRESS 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-maddress \- multicast addresses management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B maddress
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+
+.BR "ip maddress" " [ " add " | " del " ]"
+.IB MULTIADDR " dev " STRING
+
+.ti -8
+.BR "ip maddress show" " [ " dev
+.IR STRING " ]"
+
+.SH DESCRIPTION
+.B maddress
+objects are multicast addresses.
+
+.SS ip maddress show - list multicast addresses
+
+.TP
+.BI dev " NAME " (default)
+the device name.
+
+.SS ip maddress add - add a multicast address
+.SS ip maddress delete - delete a multicast address
+these commands attach/detach a static link layer multicast address
+to listen on the interface.
+Note that it is impossible to join protocol multicast groups
+statically. This command only manages link layer addresses.
+
+.TP
+.BI address " LLADDRESS " (default)
+the link layer multicast address.
+
+.TP
+.BI dev " NAME"
+the device to join/leave this multicast address.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-monitor.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-monitor.8
new file mode 100755
index 0000000..351a744
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-monitor.8
@@ -0,0 +1,67 @@
+.TH IP\-MONITOR 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-monitor, rtmon \- state monitoring
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.BR "ip monitor" " [ " all " |"
+.IR LISTofOBJECTS " ]"
+.sp
+
+.SH DESCRIPTION
+The
+.B ip
+utility can monitor the state of devices, addresses
+and routes continuously. This option has a slightly different format.
+Namely, the
+.B monitor
+command is the first in the command line and then the object list follows:
+
+.BR "ip monitor" " [ " all " |"
+.IR LISTofOBJECTS " ]"
+
+.I OBJECT-LIST
+is the list of object types that we want to monitor.
+It may contain
+.BR link ", " address " and " route "."
+If no
+.B file
+argument is given,
+.B ip
+opens RTNETLINK, listens on it and dumps state changes in the format
+described in previous sections.
+
+.P
+If a file name is given, it does not listen on RTNETLINK,
+but opens the file containing RTNETLINK messages saved in binary format
+and dumps them. Such a history file can be generated with the
+.B rtmon
+utility. This utility has a command line syntax similar to
+.BR "ip monitor" .
+Ideally,
+.B rtmon
+should be started before the first network configuration command
+is issued. F.e. if you insert:
+.sp
+.in +8
+rtmon file /var/log/rtmon.log
+.in -8
+.sp
+in a startup script, you will be able to view the full history
+later.
+
+.P
+Certainly, it is possible to start
+.B rtmon
+at any time.
+It prepends the history with the state snapshot dumped at the moment
+of starting.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-mroute.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-mroute.8
new file mode 100755
index 0000000..98aab88
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-mroute.8
@@ -0,0 +1,50 @@
+.TH IP\-MROUTE 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-mroute \- multicast routing cache management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.BR "ip mroute show" " ["
+.IR PREFIX " ] [ "
+.B from
+.IR PREFIX " ] [ "
+.B iif
+.IR DEVICE " ]"
+
+.SH DESCRIPTION
+.B mroute
+objects are multicast routing cache entries created by a user level
+mrouting daemon (f.e.
+.B pimd
+or
+.B mrouted
+).
+
+Due to the limitations of the current interface to the multicast routing
+engine, it is impossible to change
+.B mroute
+objects administratively, so we may only display them. This limitation
+will be removed in the future.
+
+.SS ip mroute show - list mroute cache entries
+
+.TP
+.BI to " PREFIX " (default)
+the prefix selecting the destination multicast addresses to list.
+
+.TP
+.BI iif " NAME"
+the interface on which multicast packets are received.
+
+.TP
+.BI from " PREFIX"
+the prefix selecting the IP source addresses of the multicast route.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-neighbour.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-neighbour.8
new file mode 100755
index 0000000..34980c5
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-neighbour.8
@@ -0,0 +1,197 @@
+.TH IP\-NEIGHBOUR 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-neighbour \- neighbour/arp tables management.
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B neigh
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.BR "ip neigh" " { " add " | " del " | " change " | " replace " } { "
+.IR ADDR " [ "
+.B lladdr
+.IR LLADDR " ] [ "
+.BR nud " { " permanent " | " noarp " | " stale " | " reachable " } ] | " proxy
+.IR ADDR " } [ "
+.B dev
+.IR DEV " ]"
+
+.ti -8
+.BR "ip neigh" " { " show " | " flush " } [ " proxy " ] [ " to
+.IR PREFIX " ] [ "
+.B dev
+.IR DEV " ] [ "
+.B nud
+.IR STATE " ]"
+
+
+.SH DESCRIPTION
+The
+.B ip neigh
+command manipulates
+.I neighbour
+objects that establish bindings between protocol addresses and
+link layer addresses for hosts sharing the same link.
+Neighbour entries are organized into tables. The IPv4 neighbour table
+is known by another name - the ARP table.
+
+.P
+The corresponding commands display neighbour bindings
+and their properties, add new neighbour entries and delete old ones.
+
+.SS ip neighbour add - add a new neighbour entry
+.SS ip neighbour change - change an existing entry
+.SS ip neighbour replace - add a new entry or change an existing one
+
+These commands create new neighbour records or update existing ones.
+
+.TP
+.BI to " ADDRESS " (default)
+the protocol address of the neighbour. It is either an IPv4 or IPv6 address.
+
+.TP
+.BI dev " NAME"
+the interface to which this neighbour is attached.
+
+.TP
+.BI lladdr " LLADDRESS"
+the link layer address of the neighbour.
+.I LLADDRESS
+can also be
+.BR "null" .
+
+.TP
+.BI nud " NUD_STATE"
+the state of the neighbour entry.
+.B nud
+is an abbreviation for 'Neighbour Unreachability Detection'.
+The state can take one of the following values:
+
+.in +8
+.B permanent
+- the neighbour entry is valid forever and can be only
+be removed administratively.
+.sp
+
+.B noarp
+- the neighbour entry is valid. No attempts to validate
+this entry will be made but it can be removed when its lifetime expires.
+.sp
+
+.B reachable
+- the neighbour entry is valid until the reachability
+timeout expires.
+.sp
+
+.B stale
+- the neighbour entry is valid but suspicious.
+This option to
+.B ip neigh
+does not change the neighbour state if it was valid and the address
+is not changed by this command.
+.in -8
+
+.SS ip neighbour delete - delete a neighbour entry
+This command invalidates a neighbour entry.
+
+.PP
+The arguments are the same as with
+.BR "ip neigh add" ,
+except that
+.B lladdr
+and
+.B nud
+are ignored.
+
+.PP
+.B Warning:
+Attempts to delete or manually change a
+.B noarp
+entry created by the kernel may result in unpredictable behaviour.
+Particularly, the kernel may try to resolve this address even
+on a
+.B NOARP
+interface or if the address is multicast or broadcast.
+
+.SS ip neighbour show - list neighbour entries
+
+This commands displays neighbour tables.
+
+.TP
+.BI to " ADDRESS " (default)
+the prefix selecting the neighbours to list.
+
+.TP
+.BI dev " NAME"
+only list the neighbours attached to this device.
+
+.TP
+.BI proxy
+list neighbour proxies.
+
+.TP
+.B unused
+only list neighbours which are not currently in use.
+
+.TP
+.BI nud " NUD_STATE"
+only list neighbour entries in this state.
+.I NUD_STATE
+takes values listed below or the special value
+.B all
+which means all states. This option may occur more than once.
+If this option is absent,
+.B ip
+lists all entries except for
+.B none
+and
+.BR "noarp" .
+
+.SS ip neighbour flush - flush neighbour entries
+This command flushes neighbour tables, selecting
+entries to flush by some criteria.
+
+.PP
+This command has the same arguments as
+.B show.
+The differences are that it does not run when no arguments are given,
+and that the default neighbour states to be flushed do not include
+.B permanent
+and
+.BR "noarp" .
+
+.PP
+With the
+.B -statistics
+option, the command becomes verbose. It prints out the number of
+deleted neighbours and the number of rounds made to flush the
+neighbour table. If the option is given
+twice,
+.B ip neigh flush
+also dumps all the deleted neighbours.
+
+.SH EXAMPLES
+.PP
+ip neighbour
+.RS
+Shows the current neighbour table in kernel.
+.RE
+.PP
+ip neigh flush dev eth0
+.RS
+Removes entries in the neighbour table on device eth0.
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-netns.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-netns.8
new file mode 100755
index 0000000..7fe9eb9
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-netns.8
@@ -0,0 +1,68 @@
+.TH IP\-NETNS 8 "20 Dec 2011" "iproute2" "Linux"
+.SH NAME
+ip-netns \- process network namespace management
+.SH SYNOPSIS
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B netns
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+.BR "ip netns" " { " list " } "
+
+.ti -8
+.BR "ip netns" " { " add " | " delete " } "
+.I NETNSNAME
+
+.ti -8
+.BR "ip netns exec "
+.I NETNSNAME command ...
+
+.SH DESCRIPTION
+A network namespace is logically another copy of the network stack,
+with it's own routes, firewall rules, and network devices.
+
+By convention a named network namespace is an object at
+.BR "/var/run/netns/" NAME
+that can be opened. The file descriptor resulting from opening
+.BR "/var/run/netns/" NAME
+refers to the specified network namespace. Holding that file
+descriptor open keeps the network namespace alive. The file
+descriptor can be used with the
+.B setns(2)
+system call to change the network namespace associated with a task.
+
+The convention for network namespace aware applications is to look
+for global network configuration files first in
+.BR "/etc/netns/" NAME "/"
+then in
+.BR "/etc/".
+For example, if you want a different version of
+.BR /etc/resolv.conf
+for a network namespace used to isolate your vpn you would name it
+.BR /etc/netns/myvpn/resolv.conf.
+
+.B ip netns exec
+automates handling of this configuration, file convention for network
+namespace unaware applications, by creating a mount namespace and
+bind mounting all of the per network namespace configure files into
+their traditional location in /etc.
+
+.SS ip netns list - show all of the named network namespaces
+.SS ip netns add NAME - create a new named network namespace
+.SS ip netns delete NAME - delete the name of a network namespace
+.SS ip netns exec NAME cmd ... - Run cmd in the named network namespace
+
+.SH EXAMPLES
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Eric W. Biederman
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-ntable.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-ntable.8
new file mode 100755
index 0000000..d903a17
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-ntable.8
@@ -0,0 +1,101 @@
+.TH IP\-NTABLE 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-ntable - neighbour table configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B address
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.BR "ip ntable change name"
+.IR NAME " [ "
+.B dev
+.IR DEV " ] " PARMS
+
+.ti -8
+.IR PARMS " := { "
+.B thresh1
+.IR VAL " | "
+.B thresh2
+.IR VAL " | "
+.B thresh3
+.IR VAL " | "
+.B gc_int
+.IR MSEC " | "
+.B base_reachable
+.IR MSEC " | "
+.B retrans
+.IR MSEC " | " "gc_stale MSEC " " | "
+.B delay_probe
+.IR MSEC " | " "queue LEN " " | "
+.B app_probs
+.IR VAL " | "
+.B ucast_probes
+.IR VAL " | " "mcast_probes VAL " " | "
+.B anycast_delay
+.IR MSEC " | "
+.B proxy_delay
+.IR MSEC " | " "proxy_queue LEN " " | "
+.B locktime
+.IR MSEC " }"
+
+.ti -8
+.BR "ip ntable show" " [ "
+.B dev
+.IR DEV " ] [ "
+.B name
+.IR NAME " ]"
+
+.SH DESCRIPTION
+.I ip ntable
+controls the parameters for the neighbour tables.
+
+.SS ip ntable show - list the ip neighbour tables
+
+This commands displays neighbour table parameters and statistics.
+
+.TP
+.BI dev " DEV"
+only list the table attached to this device.
+
+.TP
+.BI name " NAME"
+only lists the table with the given name.
+
+.SS ip ntable change - modify table parameter
+
+This command allows modifying table parameters such as timers and queue lengths.
+.TP
+.BI name " NAME"
+the name of the table to modify.
+
+.TP
+.BI dev " DEV"
+the name of the device to modify the table values.
+
+.SH EXAMPLES
+.PP
+ip ntable show dev eth0
+.RS 4
+Shows the neighbour table (IPv4 ARP and IPv6 ndisc) parameters on device eth0.
+.RE
+.PP
+ip ntable change name arp_cache queue 8 dev eth0
+.RS 4
+Changes the number of packets queued while address is being resolved from the
+default value (3) to 8 packets.
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Manpage by Stephen Hemminger
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-route.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-route.8
new file mode 100755
index 0000000..91c1a0b
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-route.8
@@ -0,0 +1,744 @@
+.TH IP\-ROUTE 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-route \- routing table management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B route
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+
+.ti -8
+.BR "ip route" " { "
+.BR list " | " flush " } "
+.I SELECTOR
+
+.ti -8
+.BR "ip route save"
+.I SELECTOR
+
+.ti -8
+.BR "ip route restore"
+
+.ti -8
+.B ip route get
+.IR ADDRESS " [ "
+.BI from " ADDRESS " iif " STRING"
+.RB " ] [ " oif
+.IR STRING " ] [ "
+.B tos
+.IR TOS " ]"
+
+.ti -8
+.BR "ip route" " { " add " | " del " | " change " | " append " | "\
+replace " } "
+.I ROUTE
+
+.ti -8
+.IR SELECTOR " := "
+.RB "[ " root
+.IR PREFIX " ] [ "
+.B match
+.IR PREFIX " ] [ "
+.B exact
+.IR PREFIX " ] [ "
+.B table
+.IR TABLE_ID " ] [ "
+.B proto
+.IR RTPROTO " ] [ "
+.B type
+.IR TYPE " ] [ "
+.B scope
+.IR SCOPE " ]"
+
+.ti -8
+.IR ROUTE " := " NODE_SPEC " [ " INFO_SPEC " ]"
+
+.ti -8
+.IR NODE_SPEC " := [ " TYPE " ] " PREFIX " ["
+.B tos
+.IR TOS " ] [ "
+.B table
+.IR TABLE_ID " ] [ "
+.B proto
+.IR RTPROTO " ] [ "
+.B scope
+.IR SCOPE " ] [ "
+.B metric
+.IR METRIC " ]"
+
+.ti -8
+.IR INFO_SPEC " := " "NH OPTIONS FLAGS" " ["
+.B nexthop
+.IR NH " ] ..."
+
+.ti -8
+.IR NH " := [ "
+.B via
+.IR ADDRESS " ] [ "
+.B dev
+.IR STRING " ] [ "
+.B weight
+.IR NUMBER " ] " NHFLAGS
+
+.ti -8
+.IR OPTIONS " := " FLAGS " [ "
+.B mtu
+.IR NUMBER " ] [ "
+.B advmss
+.IR NUMBER " ] [ "
+.B rtt
+.IR TIME " ] [ "
+.B rttvar
+.IR TIME " ] [ "
+.B window
+.IR NUMBER " ] [ "
+.B cwnd
+.IR NUMBER " ] [ "
+.B ssthresh
+.IR REALM " ] [ "
+.B realms
+.IR REALM " ] [ "
+.B rto_min
+.IR TIME " ] [ "
+.B initcwnd
+.IR NUMBER " ] [ "
+.B initrwnd
+.IR NUMBER " ]"
+
+.ti -8
+.IR TYPE " := [ "
+.BR unicast " | " local " | " broadcast " | " multicast " | "\
+throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
+
+.ti -8
+.IR TABLE_ID " := [ "
+.BR local "| " main " | " default " | " all " |"
+.IR NUMBER " ]"
+
+.ti -8
+.IR SCOPE " := [ "
+.BR host " | " link " | " global " |"
+.IR NUMBER " ]"
+
+.ti -8
+.IR NHFLAGS " := [ "
+.BR onlink " | " pervasive " ]"
+
+.ti -8
+.IR RTPROTO " := [ "
+.BR kernel " | " boot " | " static " |"
+.IR NUMBER " ]"
+
+
+.SH DESCRIPTION
+.B ip route
+is used to manipulate entries in the kernel routing tables.
+.sp
+.B Route types:
+
+.in +8
+.B unicast
+- the route entry describes real paths to the destinations covered
+by the route prefix.
+
+.sp
+.B unreachable
+- these destinations are unreachable. Packets are discarded and the
+ICMP message
+.I host unreachable
+is generated.
+The local senders get an
+.I EHOSTUNREACH
+error.
+
+.sp
+.B blackhole
+- these destinations are unreachable. Packets are discarded silently.
+The local senders get an
+.I EINVAL
+error.
+
+.sp
+.B prohibit
+- these destinations are unreachable. Packets are discarded and the
+ICMP message
+.I communication administratively prohibited
+is generated. The local senders get an
+.I EACCES
+error.
+
+.sp
+.B local
+- the destinations are assigned to this host. The packets are looped
+back and delivered locally.
+
+.sp
+.B broadcast
+- the destinations are broadcast addresses. The packets are sent as
+link broadcasts.
+
+.sp
+.B throw
+- a special control route used together with policy rules. If such a
+route is selected, lookup in this table is terminated pretending that
+no route was found. Without policy routing it is equivalent to the
+absence of the route in the routing table. The packets are dropped
+and the ICMP message
+.I net unreachable
+is generated. The local senders get an
+.I ENETUNREACH
+error.
+
+.sp
+.B nat
+- a special NAT route. Destinations covered by the prefix
+are considered to be dummy (or external) addresses which require translation
+to real (or internal) ones before forwarding. The addresses to translate to
+are selected with the attribute
+.B Warning:
+Route NAT is no longer supported in Linux 2.6.
+
+
+.BR "via" .
+.sp
+.B anycast
+.RI "- " "not implemented"
+the destinations are
+.I anycast
+addresses assigned to this host. They are mainly equivalent
+to
+.B local
+with one difference: such addresses are invalid when used
+as the source address of any packet.
+
+.sp
+.B multicast
+- a special type used for multicast routing. It is not present in
+normal routing tables.
+.in -8
+
+.P
+.B Route tables:
+Linux-2.x can pack routes into several routing tables identified
+by a number in the range from 1 to 2^31 or by name from the file
+.B /etc/iproute2/rt_tables
+By default all normal routes are inserted into the
+.B main
+table (ID 254) and the kernel only uses this table when calculating routes.
+Values (0, 253, 254, and 255) are reserved for built-in use.
+
+.sp
+Actually, one other table always exists, which is invisible but
+even more important. It is the
+.B local
+table (ID 255). This table
+consists of routes for local and broadcast addresses. The kernel maintains
+this table automatically and the administrator usually need not modify it
+or even look at it.
+
+The multiple routing tables enter the game when
+.I policy routing
+is used.
+
+.SS ip route add - add new route
+.SS ip route change - change route
+.SS ip route replace - change or add new one
+
+.TP
+.BI to " TYPE PREFIX " (default)
+the destination prefix of the route. If
+.I TYPE
+is omitted,
+.B ip
+assumes type
+.BR "unicast" .
+Other values of
+.I TYPE
+are listed above.
+.I PREFIX
+is an IP or IPv6 address optionally followed by a slash and the
+prefix length. If the length of the prefix is missing,
+.B ip
+assumes a full-length host route. There is also a special
+.I PREFIX
+.B default
+- which is equivalent to IP
+.B 0/0
+or to IPv6
+.BR "::/0" .
+
+.TP
+.BI tos " TOS"
+.TP
+.BI dsfield " TOS"
+the Type Of Service (TOS) key. This key has no associated mask and
+the longest match is understood as: First, compare the TOS
+of the route and of the packet. If they are not equal, then the packet
+may still match a route with a zero TOS.
+.I TOS
+is either an 8 bit hexadecimal number or an identifier
+from
+.BR "/etc/iproute2/rt_dsfield" .
+
+.TP
+.BI metric " NUMBER"
+.TP
+.BI preference " NUMBER"
+the preference value of the route.
+.I NUMBER
+is an arbitrary 32bit number.
+
+.TP
+.BI table " TABLEID"
+the table to add this route to.
+.I TABLEID
+may be a number or a string from the file
+.BR "/etc/iproute2/rt_tables" .
+If this parameter is omitted,
+.B ip
+assumes the
+.B main
+table, with the exception of
+.BR local " , " broadcast " and " nat
+routes, which are put into the
+.B local
+table by default.
+
+.TP
+.BI dev " NAME"
+the output device name.
+
+.TP
+.BI via " ADDRESS"
+the address of the nexthop router. Actually, the sense of this field
+depends on the route type. For normal
+.B unicast
+routes it is either the true next hop router or, if it is a direct
+route installed in BSD compatibility mode, it can be a local address
+of the interface. For NAT routes it is the first address of the block
+of translated IP destinations.
+
+.TP
+.BI src " ADDRESS"
+the source address to prefer when sending to the destinations
+covered by the route prefix.
+
+.TP
+.BI realm " REALMID"
+the realm to which this route is assigned.
+.I REALMID
+may be a number or a string from the file
+.BR "/etc/iproute2/rt_realms" .
+
+.TP
+.BI mtu " MTU"
+.TP
+.BI "mtu lock" " MTU"
+the MTU along the path to the destination. If the modifier
+.B lock
+is not used, the MTU may be updated by the kernel due to
+Path MTU Discovery. If the modifier
+.B lock
+is used, no path MTU discovery will be tried, all packets
+will be sent without the DF bit in IPv4 case or fragmented
+to MTU for IPv6.
+
+.TP
+.BI window " NUMBER"
+the maximal window for TCP to advertise to these destinations,
+measured in bytes. It limits maximal data bursts that our TCP
+peers are allowed to send to us.
+
+.TP
+.BI rtt " TIME"
+the initial RTT ('Round Trip Time') estimate. If no suffix is
+specified the units are raw values passed directly to the
+routing code to maintain compatibility with previous releases.
+Otherwise if a suffix of s, sec or secs is used to specify
+seconds and ms, msec or msecs to specify milliseconds.
+
+
+.TP
+.BI rttvar " TIME " "(2.3.15+ only)"
+the initial RTT variance estimate. Values are specified as with
+.BI rtt
+above.
+
+.TP
+.BI rto_min " TIME " "(2.6.23+ only)"
+the minimum TCP Retransmission TimeOut to use when communicating with this
+destination. Values are specified as with
+.BI rtt
+above.
+
+.TP
+.BI ssthresh " NUMBER " "(2.3.15+ only)"
+an estimate for the initial slow start threshold.
+
+.TP
+.BI cwnd " NUMBER " "(2.3.15+ only)"
+the clamp for congestion window. It is ignored if the
+.B lock
+flag is not used.
+
+.TP
+.BI initcwnd " NUMBER " "(2.5.70+ only)"
+the initial congestion window size for connections to this destination.
+Actual window size is this value multiplied by the MSS
+(``Maximal Segment Size'') for same connection. The default is
+zero, meaning to use the values specified in RFC2414.
+
+.TP
+.BI initrwnd " NUMBER " "(2.6.33+ only)"
+the initial receive window size for connections to this destination.
+Actual window size is this value multiplied by the MSS of the connection.
+The default value is zero, meaning to use Slow Start value.
+
+.TP
+.BI advmss " NUMBER " "(2.3.15+ only)"
+the MSS ('Maximal Segment Size') to advertise to these
+destinations when establishing TCP connections. If it is not given,
+Linux uses a default value calculated from the first hop device MTU.
+(If the path to these destination is asymmetric, this guess may be wrong.)
+
+.TP
+.BI reordering " NUMBER " "(2.3.15+ only)"
+Maximal reordering on the path to this destination.
+If it is not given, Linux uses the value selected with
+.B sysctl
+variable
+.BR "net/ipv4/tcp_reordering" .
+
+.TP
+.BI nexthop " NEXTHOP"
+the nexthop of a multipath route.
+.I NEXTHOP
+is a complex value with its own syntax similar to the top level
+argument lists:
+
+.in +8
+.BI via " ADDRESS"
+- is the nexthop router.
+.sp
+
+.BI dev " NAME"
+- is the output device.
+.sp
+
+.BI weight " NUMBER"
+- is a weight for this element of a multipath
+route reflecting its relative bandwidth or quality.
+.in -8
+
+.TP
+.BI scope " SCOPE_VAL"
+the scope of the destinations covered by the route prefix.
+.I SCOPE_VAL
+may be a number or a string from the file
+.BR "/etc/iproute2/rt_scopes" .
+If this parameter is omitted,
+.B ip
+assumes scope
+.B global
+for all gatewayed
+.B unicast
+routes, scope
+.B link
+for direct
+.BR unicast " and " broadcast
+routes and scope
+.BR host " for " local
+routes.
+
+.TP
+.BI protocol " RTPROTO"
+the routing protocol identifier of this route.
+.I RTPROTO
+may be a number or a string from the file
+.BR "/etc/iproute2/rt_protos" .
+If the routing protocol ID is not given,
+.B ip assumes protocol
+.B boot
+(i.e. it assumes the route was added by someone who doesn't
+understand what they are doing). Several protocol values have
+a fixed interpretation.
+Namely:
+
+.in +8
+.B redirect
+- the route was installed due to an ICMP redirect.
+.sp
+
+.B kernel
+- the route was installed by the kernel during autoconfiguration.
+.sp
+
+.B boot
+- the route was installed during the bootup sequence.
+If a routing daemon starts, it will purge all of them.
+.sp
+
+.B static
+- the route was installed by the administrator
+to override dynamic routing. Routing daemon will respect them
+and, probably, even advertise them to its peers.
+.sp
+
+.B ra
+- the route was installed by Router Discovery protocol.
+.in -8
+
+.sp
+The rest of the values are not reserved and the administrator is free
+to assign (or not to assign) protocol tags.
+
+.TP
+.B onlink
+pretend that the nexthop is directly attached to this link,
+even if it does not match any interface prefix.
+
+.SS ip route delete - delete route
+
+.B ip route del
+has the same arguments as
+.BR "ip route add" ,
+but their semantics are a bit different.
+
+Key values
+.RB "(" to ", " tos ", " preference " and " table ")"
+select the route to delete. If optional attributes are present,
+.B ip
+verifies that they coincide with the attributes of the route to delete.
+If no route with the given key and attributes was found,
+.B ip route del
+fails.
+
+.SS ip route show - list routes
+the command displays the contents of the routing tables or the route(s)
+selected by some criteria.
+
+.TP
+.BI to " SELECTOR " (default)
+only select routes from the given range of destinations.
+.I SELECTOR
+consists of an optional modifier
+.RB "(" root ", " match " or " exact ")"
+and a prefix.
+.BI root " PREFIX"
+selects routes with prefixes not shorter than
+.IR PREFIX "."
+F.e.
+.BI root " 0/0"
+selects the entire routing table.
+.BI match " PREFIX"
+selects routes with prefixes not longer than
+.IR PREFIX "."
+F.e.
+.BI match " 10.0/16"
+selects
+.IR 10.0/16 ","
+.IR 10/8 " and " 0/0 ,
+but it does not select
+.IR 10.1/16 " and " 10.0.0/24 .
+And
+.BI exact " PREFIX"
+(or just
+.IR PREFIX ")"
+selects routes with this exact prefix. If neither of these options
+are present,
+.B ip
+assumes
+.BI root " 0/0"
+i.e. it lists the entire table.
+
+.TP
+.BI tos " TOS"
+.BI dsfield " TOS"
+only select routes with the given TOS.
+
+.TP
+.BI table " TABLEID"
+show the routes from this table(s). The default setting is to show
+.BR table main "."
+.I TABLEID
+may either be the ID of a real table or one of the special values:
+.sp
+.in +8
+.B all
+- list all of the tables.
+.sp
+.B cache
+- dump the routing cache.
+.in -8
+
+.TP
+.B cloned
+.TP
+.B cached
+list cloned routes i.e. routes which were dynamically forked from
+other routes because some route attribute (f.e. MTU) was updated.
+Actually, it is equivalent to
+.BR "table cache" "."
+
+.TP
+.BI from " SELECTOR"
+the same syntax as for
+.BR to ","
+but it binds the source address range rather than destinations.
+Note that the
+.B from
+option only works with cloned routes.
+
+.TP
+.BI protocol " RTPROTO"
+only list routes of this protocol.
+
+.TP
+.BI scope " SCOPE_VAL"
+only list routes with this scope.
+
+.TP
+.BI type " TYPE"
+only list routes of this type.
+
+.TP
+.BI dev " NAME"
+only list routes going via this device.
+
+.TP
+.BI via " PREFIX"
+only list routes going via the nexthop routers selected by
+.IR PREFIX "."
+
+.TP
+.BI src " PREFIX"
+only list routes with preferred source addresses selected
+by
+.IR PREFIX "."
+
+.TP
+.BI realm " REALMID"
+.TP
+.BI realms " FROMREALM/TOREALM"
+only list routes with these realms.
+
+.SS ip route flush - flush routing tables
+this command flushes routes selected by some criteria.
+
+.sp
+The arguments have the same syntax and semantics as the arguments of
+.BR "ip route show" ,
+but routing tables are not listed but purged. The only difference is
+the default action:
+.B show
+dumps all the IP main routing table but
+.B flush
+prints the helper page.
+
+.sp
+With the
+.B -statistics
+option, the command becomes verbose. It prints out the number of
+deleted routes and the number of rounds made to flush the routing
+table. If the option is given
+twice,
+.B ip route flush
+also dumps all the deleted routes in the format described in the
+previous subsection.
+
+.SS ip route get - get a single route
+this command gets a single route to a destination and prints its
+contents exactly as the kernel sees it.
+
+.TP
+.BI to " ADDRESS " (default)
+the destination address.
+
+.TP
+.BI from " ADDRESS"
+the source address.
+
+.TP
+.BI tos " TOS"
+.TP
+.BI dsfield " TOS"
+the Type Of Service.
+
+.TP
+.BI iif " NAME"
+the device from which this packet is expected to arrive.
+
+.TP
+.BI oif " NAME"
+force the output device on which this packet will be routed.
+
+.TP
+.B connected
+if no source address
+.RB "(option " from ")"
+was given, relookup the route with the source set to the preferred
+address received from the first lookup.
+If policy routing is used, it may be a different route.
+
+.P
+Note that this operation is not equivalent to
+.BR "ip route show" .
+.B show
+shows existing routes.
+.B get
+resolves them and creates new clones if necessary. Essentially,
+.B get
+is equivalent to sending a packet along this path.
+If the
+.B iif
+argument is not given, the kernel creates a route
+to output packets towards the requested destination.
+This is equivalent to pinging the destination
+with a subsequent
+.BR "ip route ls cache" ,
+however, no packets are actually sent. With the
+.B iif
+argument, the kernel pretends that a packet arrived from this interface
+and searches for a path to forward the packet.
+
+.SS ip route save - save routing table information to stdout
+this command behaves like
+.BR "ip route show"
+except that the output is raw data suitable for passing to
+.BR "ip route restore" .
+
+.SS ip route restore - restore routing table information from stdin
+this command expects to read a data stream as returned from
+.BR "ip route save" .
+It will attempt to restore the routing table information exactly as
+it was at the time of the save, so any translation of information
+in the stream (such as device indexes) must be done first. Any existing
+routes are left unchanged. Any routes specified in the data stream that
+already exist in the table will be ignored.
+
+.SH EXAMPLES
+.PP
+ip ro
+.RS 4
+Show all route entries in the kernel.
+.RE
+.PP
+ip route add default via 192.168.1.1 dev eth0
+.RS 4
+Adds a default route (for all addresses) via the local gateway 192.168.1.1 that can
+be reached on device eth0.
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-route.8.in b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-route.8.in
new file mode 100755
index 0000000..0ca6107
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-route.8.in
@@ -0,0 +1,744 @@
+.TH IP\-ROUTE 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-route \- routing table management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B route
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+
+.ti -8
+.BR "ip route" " { "
+.BR list " | " flush " } "
+.I SELECTOR
+
+.ti -8
+.BR "ip route save"
+.I SELECTOR
+
+.ti -8
+.BR "ip route restore"
+
+.ti -8
+.B ip route get
+.IR ADDRESS " [ "
+.BI from " ADDRESS " iif " STRING"
+.RB " ] [ " oif
+.IR STRING " ] [ "
+.B tos
+.IR TOS " ]"
+
+.ti -8
+.BR "ip route" " { " add " | " del " | " change " | " append " | "\
+replace " } "
+.I ROUTE
+
+.ti -8
+.IR SELECTOR " := "
+.RB "[ " root
+.IR PREFIX " ] [ "
+.B match
+.IR PREFIX " ] [ "
+.B exact
+.IR PREFIX " ] [ "
+.B table
+.IR TABLE_ID " ] [ "
+.B proto
+.IR RTPROTO " ] [ "
+.B type
+.IR TYPE " ] [ "
+.B scope
+.IR SCOPE " ]"
+
+.ti -8
+.IR ROUTE " := " NODE_SPEC " [ " INFO_SPEC " ]"
+
+.ti -8
+.IR NODE_SPEC " := [ " TYPE " ] " PREFIX " ["
+.B tos
+.IR TOS " ] [ "
+.B table
+.IR TABLE_ID " ] [ "
+.B proto
+.IR RTPROTO " ] [ "
+.B scope
+.IR SCOPE " ] [ "
+.B metric
+.IR METRIC " ]"
+
+.ti -8
+.IR INFO_SPEC " := " "NH OPTIONS FLAGS" " ["
+.B nexthop
+.IR NH " ] ..."
+
+.ti -8
+.IR NH " := [ "
+.B via
+.IR ADDRESS " ] [ "
+.B dev
+.IR STRING " ] [ "
+.B weight
+.IR NUMBER " ] " NHFLAGS
+
+.ti -8
+.IR OPTIONS " := " FLAGS " [ "
+.B mtu
+.IR NUMBER " ] [ "
+.B advmss
+.IR NUMBER " ] [ "
+.B rtt
+.IR TIME " ] [ "
+.B rttvar
+.IR TIME " ] [ "
+.B window
+.IR NUMBER " ] [ "
+.B cwnd
+.IR NUMBER " ] [ "
+.B ssthresh
+.IR REALM " ] [ "
+.B realms
+.IR REALM " ] [ "
+.B rto_min
+.IR TIME " ] [ "
+.B initcwnd
+.IR NUMBER " ] [ "
+.B initrwnd
+.IR NUMBER " ]"
+
+.ti -8
+.IR TYPE " := [ "
+.BR unicast " | " local " | " broadcast " | " multicast " | "\
+throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
+
+.ti -8
+.IR TABLE_ID " := [ "
+.BR local "| " main " | " default " | " all " |"
+.IR NUMBER " ]"
+
+.ti -8
+.IR SCOPE " := [ "
+.BR host " | " link " | " global " |"
+.IR NUMBER " ]"
+
+.ti -8
+.IR NHFLAGS " := [ "
+.BR onlink " | " pervasive " ]"
+
+.ti -8
+.IR RTPROTO " := [ "
+.BR kernel " | " boot " | " static " |"
+.IR NUMBER " ]"
+
+
+.SH DESCRIPTION
+.B ip route
+is used to manipulate entries in the kernel routing tables.
+.sp
+.B Route types:
+
+.in +8
+.B unicast
+- the route entry describes real paths to the destinations covered
+by the route prefix.
+
+.sp
+.B unreachable
+- these destinations are unreachable. Packets are discarded and the
+ICMP message
+.I host unreachable
+is generated.
+The local senders get an
+.I EHOSTUNREACH
+error.
+
+.sp
+.B blackhole
+- these destinations are unreachable. Packets are discarded silently.
+The local senders get an
+.I EINVAL
+error.
+
+.sp
+.B prohibit
+- these destinations are unreachable. Packets are discarded and the
+ICMP message
+.I communication administratively prohibited
+is generated. The local senders get an
+.I EACCES
+error.
+
+.sp
+.B local
+- the destinations are assigned to this host. The packets are looped
+back and delivered locally.
+
+.sp
+.B broadcast
+- the destinations are broadcast addresses. The packets are sent as
+link broadcasts.
+
+.sp
+.B throw
+- a special control route used together with policy rules. If such a
+route is selected, lookup in this table is terminated pretending that
+no route was found. Without policy routing it is equivalent to the
+absence of the route in the routing table. The packets are dropped
+and the ICMP message
+.I net unreachable
+is generated. The local senders get an
+.I ENETUNREACH
+error.
+
+.sp
+.B nat
+- a special NAT route. Destinations covered by the prefix
+are considered to be dummy (or external) addresses which require translation
+to real (or internal) ones before forwarding. The addresses to translate to
+are selected with the attribute
+.B Warning:
+Route NAT is no longer supported in Linux 2.6.
+
+
+.BR "via" .
+.sp
+.B anycast
+.RI "- " "not implemented"
+the destinations are
+.I anycast
+addresses assigned to this host. They are mainly equivalent
+to
+.B local
+with one difference: such addresses are invalid when used
+as the source address of any packet.
+
+.sp
+.B multicast
+- a special type used for multicast routing. It is not present in
+normal routing tables.
+.in -8
+
+.P
+.B Route tables:
+Linux-2.x can pack routes into several routing tables identified
+by a number in the range from 1 to 2^31 or by name from the file
+.B @SYSCONFDIR@/rt_tables
+By default all normal routes are inserted into the
+.B main
+table (ID 254) and the kernel only uses this table when calculating routes.
+Values (0, 253, 254, and 255) are reserved for built-in use.
+
+.sp
+Actually, one other table always exists, which is invisible but
+even more important. It is the
+.B local
+table (ID 255). This table
+consists of routes for local and broadcast addresses. The kernel maintains
+this table automatically and the administrator usually need not modify it
+or even look at it.
+
+The multiple routing tables enter the game when
+.I policy routing
+is used.
+
+.SS ip route add - add new route
+.SS ip route change - change route
+.SS ip route replace - change or add new one
+
+.TP
+.BI to " TYPE PREFIX " (default)
+the destination prefix of the route. If
+.I TYPE
+is omitted,
+.B ip
+assumes type
+.BR "unicast" .
+Other values of
+.I TYPE
+are listed above.
+.I PREFIX
+is an IP or IPv6 address optionally followed by a slash and the
+prefix length. If the length of the prefix is missing,
+.B ip
+assumes a full-length host route. There is also a special
+.I PREFIX
+.B default
+- which is equivalent to IP
+.B 0/0
+or to IPv6
+.BR "::/0" .
+
+.TP
+.BI tos " TOS"
+.TP
+.BI dsfield " TOS"
+the Type Of Service (TOS) key. This key has no associated mask and
+the longest match is understood as: First, compare the TOS
+of the route and of the packet. If they are not equal, then the packet
+may still match a route with a zero TOS.
+.I TOS
+is either an 8 bit hexadecimal number or an identifier
+from
+.BR "@SYSCONFDIR@/rt_dsfield" .
+
+.TP
+.BI metric " NUMBER"
+.TP
+.BI preference " NUMBER"
+the preference value of the route.
+.I NUMBER
+is an arbitrary 32bit number.
+
+.TP
+.BI table " TABLEID"
+the table to add this route to.
+.I TABLEID
+may be a number or a string from the file
+.BR "@SYSCONFDIR@/rt_tables" .
+If this parameter is omitted,
+.B ip
+assumes the
+.B main
+table, with the exception of
+.BR local " , " broadcast " and " nat
+routes, which are put into the
+.B local
+table by default.
+
+.TP
+.BI dev " NAME"
+the output device name.
+
+.TP
+.BI via " ADDRESS"
+the address of the nexthop router. Actually, the sense of this field
+depends on the route type. For normal
+.B unicast
+routes it is either the true next hop router or, if it is a direct
+route installed in BSD compatibility mode, it can be a local address
+of the interface. For NAT routes it is the first address of the block
+of translated IP destinations.
+
+.TP
+.BI src " ADDRESS"
+the source address to prefer when sending to the destinations
+covered by the route prefix.
+
+.TP
+.BI realm " REALMID"
+the realm to which this route is assigned.
+.I REALMID
+may be a number or a string from the file
+.BR "@SYSCONFDIR@/rt_realms" .
+
+.TP
+.BI mtu " MTU"
+.TP
+.BI "mtu lock" " MTU"
+the MTU along the path to the destination. If the modifier
+.B lock
+is not used, the MTU may be updated by the kernel due to
+Path MTU Discovery. If the modifier
+.B lock
+is used, no path MTU discovery will be tried, all packets
+will be sent without the DF bit in IPv4 case or fragmented
+to MTU for IPv6.
+
+.TP
+.BI window " NUMBER"
+the maximal window for TCP to advertise to these destinations,
+measured in bytes. It limits maximal data bursts that our TCP
+peers are allowed to send to us.
+
+.TP
+.BI rtt " TIME"
+the initial RTT ('Round Trip Time') estimate. If no suffix is
+specified the units are raw values passed directly to the
+routing code to maintain compatibility with previous releases.
+Otherwise if a suffix of s, sec or secs is used to specify
+seconds and ms, msec or msecs to specify milliseconds.
+
+
+.TP
+.BI rttvar " TIME " "(2.3.15+ only)"
+the initial RTT variance estimate. Values are specified as with
+.BI rtt
+above.
+
+.TP
+.BI rto_min " TIME " "(2.6.23+ only)"
+the minimum TCP Retransmission TimeOut to use when communicating with this
+destination. Values are specified as with
+.BI rtt
+above.
+
+.TP
+.BI ssthresh " NUMBER " "(2.3.15+ only)"
+an estimate for the initial slow start threshold.
+
+.TP
+.BI cwnd " NUMBER " "(2.3.15+ only)"
+the clamp for congestion window. It is ignored if the
+.B lock
+flag is not used.
+
+.TP
+.BI initcwnd " NUMBER " "(2.5.70+ only)"
+the initial congestion window size for connections to this destination.
+Actual window size is this value multiplied by the MSS
+(``Maximal Segment Size'') for same connection. The default is
+zero, meaning to use the values specified in RFC2414.
+
+.TP
+.BI initrwnd " NUMBER " "(2.6.33+ only)"
+the initial receive window size for connections to this destination.
+Actual window size is this value multiplied by the MSS of the connection.
+The default value is zero, meaning to use Slow Start value.
+
+.TP
+.BI advmss " NUMBER " "(2.3.15+ only)"
+the MSS ('Maximal Segment Size') to advertise to these
+destinations when establishing TCP connections. If it is not given,
+Linux uses a default value calculated from the first hop device MTU.
+(If the path to these destination is asymmetric, this guess may be wrong.)
+
+.TP
+.BI reordering " NUMBER " "(2.3.15+ only)"
+Maximal reordering on the path to this destination.
+If it is not given, Linux uses the value selected with
+.B sysctl
+variable
+.BR "net/ipv4/tcp_reordering" .
+
+.TP
+.BI nexthop " NEXTHOP"
+the nexthop of a multipath route.
+.I NEXTHOP
+is a complex value with its own syntax similar to the top level
+argument lists:
+
+.in +8
+.BI via " ADDRESS"
+- is the nexthop router.
+.sp
+
+.BI dev " NAME"
+- is the output device.
+.sp
+
+.BI weight " NUMBER"
+- is a weight for this element of a multipath
+route reflecting its relative bandwidth or quality.
+.in -8
+
+.TP
+.BI scope " SCOPE_VAL"
+the scope of the destinations covered by the route prefix.
+.I SCOPE_VAL
+may be a number or a string from the file
+.BR "@SYSCONFDIR@/rt_scopes" .
+If this parameter is omitted,
+.B ip
+assumes scope
+.B global
+for all gatewayed
+.B unicast
+routes, scope
+.B link
+for direct
+.BR unicast " and " broadcast
+routes and scope
+.BR host " for " local
+routes.
+
+.TP
+.BI protocol " RTPROTO"
+the routing protocol identifier of this route.
+.I RTPROTO
+may be a number or a string from the file
+.BR "@SYSCONFDIR@/rt_protos" .
+If the routing protocol ID is not given,
+.B ip assumes protocol
+.B boot
+(i.e. it assumes the route was added by someone who doesn't
+understand what they are doing). Several protocol values have
+a fixed interpretation.
+Namely:
+
+.in +8
+.B redirect
+- the route was installed due to an ICMP redirect.
+.sp
+
+.B kernel
+- the route was installed by the kernel during autoconfiguration.
+.sp
+
+.B boot
+- the route was installed during the bootup sequence.
+If a routing daemon starts, it will purge all of them.
+.sp
+
+.B static
+- the route was installed by the administrator
+to override dynamic routing. Routing daemon will respect them
+and, probably, even advertise them to its peers.
+.sp
+
+.B ra
+- the route was installed by Router Discovery protocol.
+.in -8
+
+.sp
+The rest of the values are not reserved and the administrator is free
+to assign (or not to assign) protocol tags.
+
+.TP
+.B onlink
+pretend that the nexthop is directly attached to this link,
+even if it does not match any interface prefix.
+
+.SS ip route delete - delete route
+
+.B ip route del
+has the same arguments as
+.BR "ip route add" ,
+but their semantics are a bit different.
+
+Key values
+.RB "(" to ", " tos ", " preference " and " table ")"
+select the route to delete. If optional attributes are present,
+.B ip
+verifies that they coincide with the attributes of the route to delete.
+If no route with the given key and attributes was found,
+.B ip route del
+fails.
+
+.SS ip route show - list routes
+the command displays the contents of the routing tables or the route(s)
+selected by some criteria.
+
+.TP
+.BI to " SELECTOR " (default)
+only select routes from the given range of destinations.
+.I SELECTOR
+consists of an optional modifier
+.RB "(" root ", " match " or " exact ")"
+and a prefix.
+.BI root " PREFIX"
+selects routes with prefixes not shorter than
+.IR PREFIX "."
+F.e.
+.BI root " 0/0"
+selects the entire routing table.
+.BI match " PREFIX"
+selects routes with prefixes not longer than
+.IR PREFIX "."
+F.e.
+.BI match " 10.0/16"
+selects
+.IR 10.0/16 ","
+.IR 10/8 " and " 0/0 ,
+but it does not select
+.IR 10.1/16 " and " 10.0.0/24 .
+And
+.BI exact " PREFIX"
+(or just
+.IR PREFIX ")"
+selects routes with this exact prefix. If neither of these options
+are present,
+.B ip
+assumes
+.BI root " 0/0"
+i.e. it lists the entire table.
+
+.TP
+.BI tos " TOS"
+.BI dsfield " TOS"
+only select routes with the given TOS.
+
+.TP
+.BI table " TABLEID"
+show the routes from this table(s). The default setting is to show
+.BR table main "."
+.I TABLEID
+may either be the ID of a real table or one of the special values:
+.sp
+.in +8
+.B all
+- list all of the tables.
+.sp
+.B cache
+- dump the routing cache.
+.in -8
+
+.TP
+.B cloned
+.TP
+.B cached
+list cloned routes i.e. routes which were dynamically forked from
+other routes because some route attribute (f.e. MTU) was updated.
+Actually, it is equivalent to
+.BR "table cache" "."
+
+.TP
+.BI from " SELECTOR"
+the same syntax as for
+.BR to ","
+but it binds the source address range rather than destinations.
+Note that the
+.B from
+option only works with cloned routes.
+
+.TP
+.BI protocol " RTPROTO"
+only list routes of this protocol.
+
+.TP
+.BI scope " SCOPE_VAL"
+only list routes with this scope.
+
+.TP
+.BI type " TYPE"
+only list routes of this type.
+
+.TP
+.BI dev " NAME"
+only list routes going via this device.
+
+.TP
+.BI via " PREFIX"
+only list routes going via the nexthop routers selected by
+.IR PREFIX "."
+
+.TP
+.BI src " PREFIX"
+only list routes with preferred source addresses selected
+by
+.IR PREFIX "."
+
+.TP
+.BI realm " REALMID"
+.TP
+.BI realms " FROMREALM/TOREALM"
+only list routes with these realms.
+
+.SS ip route flush - flush routing tables
+this command flushes routes selected by some criteria.
+
+.sp
+The arguments have the same syntax and semantics as the arguments of
+.BR "ip route show" ,
+but routing tables are not listed but purged. The only difference is
+the default action:
+.B show
+dumps all the IP main routing table but
+.B flush
+prints the helper page.
+
+.sp
+With the
+.B -statistics
+option, the command becomes verbose. It prints out the number of
+deleted routes and the number of rounds made to flush the routing
+table. If the option is given
+twice,
+.B ip route flush
+also dumps all the deleted routes in the format described in the
+previous subsection.
+
+.SS ip route get - get a single route
+this command gets a single route to a destination and prints its
+contents exactly as the kernel sees it.
+
+.TP
+.BI to " ADDRESS " (default)
+the destination address.
+
+.TP
+.BI from " ADDRESS"
+the source address.
+
+.TP
+.BI tos " TOS"
+.TP
+.BI dsfield " TOS"
+the Type Of Service.
+
+.TP
+.BI iif " NAME"
+the device from which this packet is expected to arrive.
+
+.TP
+.BI oif " NAME"
+force the output device on which this packet will be routed.
+
+.TP
+.B connected
+if no source address
+.RB "(option " from ")"
+was given, relookup the route with the source set to the preferred
+address received from the first lookup.
+If policy routing is used, it may be a different route.
+
+.P
+Note that this operation is not equivalent to
+.BR "ip route show" .
+.B show
+shows existing routes.
+.B get
+resolves them and creates new clones if necessary. Essentially,
+.B get
+is equivalent to sending a packet along this path.
+If the
+.B iif
+argument is not given, the kernel creates a route
+to output packets towards the requested destination.
+This is equivalent to pinging the destination
+with a subsequent
+.BR "ip route ls cache" ,
+however, no packets are actually sent. With the
+.B iif
+argument, the kernel pretends that a packet arrived from this interface
+and searches for a path to forward the packet.
+
+.SS ip route save - save routing table information to stdout
+this command behaves like
+.BR "ip route show"
+except that the output is raw data suitable for passing to
+.BR "ip route restore" .
+
+.SS ip route restore - restore routing table information from stdin
+this command expects to read a data stream as returned from
+.BR "ip route save" .
+It will attempt to restore the routing table information exactly as
+it was at the time of the save, so any translation of information
+in the stream (such as device indexes) must be done first. Any existing
+routes are left unchanged. Any routes specified in the data stream that
+already exist in the table will be ignored.
+
+.SH EXAMPLES
+.PP
+ip ro
+.RS 4
+Show all route entries in the kernel.
+.RE
+.PP
+ip route add default via 192.168.1.1 dev eth0
+.RS 4
+Adds a default route (for all addresses) via the local gateway 192.168.1.1 that can
+be reached on device eth0.
+.RE
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-rule.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-rule.8
new file mode 100755
index 0000000..0f62a53
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-rule.8
@@ -0,0 +1,253 @@
+.TH IP\-RULE 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-rule \- routing policy database management
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B rule
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.B ip rule
+.RB " [ " list " | " add " | " del " | " flush " ]"
+.I SELECTOR ACTION
+
+.ti -8
+.IR SELECTOR " := [ "
+.B from
+.IR PREFIX " ] [ "
+.B to
+.IR PREFIX " ] [ "
+.B tos
+.IR TOS " ] [ "
+.B fwmark
+.IR FWMARK[/MASK] " ] [ "
+.B iif
+.IR STRING " ] [ "
+.B oif
+.IR STRING " ] [ "
+.B pref
+.IR NUMBER " ]"
+
+.ti -8
+.IR ACTION " := [ "
+.B table
+.IR TABLE_ID " ] [ "
+.B nat
+.IR ADDRESS " ] [ "
+.BR prohibit " | " reject " | " unreachable " ] [ " realms
+.RI "[" SRCREALM "/]" DSTREALM " ]"
+
+.ti -8
+.IR TABLE_ID " := [ "
+.BR local " | " main " | " default " |"
+.IR NUMBER " ]"
+
+.SH DESCRIPTION
+.I ip rule
+manipulates rules
+in the routing policy database control the route selection algorithm.
+
+.P
+Classic routing algorithms used in the Internet make routing decisions
+based only on the destination address of packets (and in theory,
+but not in practice, on the TOS field).
+
+.P
+In some circumstances we want to route packets differently depending not only
+on destination addresses, but also on other packet fields: source address,
+IP protocol, transport protocol ports or even packet payload.
+This task is called 'policy routing'.
+
+.P
+To solve this task, the conventional destination based routing table, ordered
+according to the longest match rule, is replaced with a 'routing policy
+database' (or RPDB), which selects routes by executing some set of rules.
+
+.P
+Each policy routing rule consists of a
+.B selector
+and an
+.B action predicate.
+The RPDB is scanned in the order of increasing priority. The selector
+of each rule is applied to {source address, destination address, incoming
+interface, tos, fwmark} and, if the selector matches the packet,
+the action is performed. The action predicate may return with success.
+In this case, it will either give a route or failure indication
+and the RPDB lookup is terminated. Otherwise, the RPDB program
+continues on the next rule.
+
+.P
+Semantically, natural action is to select the nexthop and the output device.
+
+.P
+At startup time the kernel configures the default RPDB consisting of three
+rules:
+
+.TP
+1.
+Priority: 0, Selector: match anything, Action: lookup routing
+table
+.B local
+(ID 255).
+The
+.B local
+table is a special routing table containing
+high priority control routes for local and broadcast addresses.
+.sp
+Rule 0 is special. It cannot be deleted or overridden.
+
+.TP
+2.
+Priority: 32766, Selector: match anything, Action: lookup routing
+table
+.B main
+(ID 254).
+The
+.B main
+table is the normal routing table containing all non-policy
+routes. This rule may be deleted and/or overridden with other
+ones by the administrator.
+
+.TP
+3.
+Priority: 32767, Selector: match anything, Action: lookup routing
+table
+.B default
+(ID 253).
+The
+.B default
+table is empty. It is reserved for some post-processing if no previous
+default rules selected the packet.
+This rule may also be deleted.
+
+.P
+Each RPDB entry has additional
+attributes. F.e. each rule has a pointer to some routing
+table. NAT and masquerading rules have an attribute to select new IP
+address to translate/masquerade. Besides that, rules have some
+optional attributes, which routes have, namely
+.BR "realms" .
+These values do not override those contained in the routing tables. They
+are only used if the route did not select any attributes.
+
+.sp
+The RPDB may contain rules of the following types:
+
+.in +8
+.B unicast
+- the rule prescribes to return the route found
+in the routing table referenced by the rule.
+
+.B blackhole
+- the rule prescribes to silently drop the packet.
+
+.B unreachable
+- the rule prescribes to generate a 'Network is unreachable' error.
+
+.B prohibit
+- the rule prescribes to generate 'Communication is administratively
+prohibited' error.
+
+.B nat
+- the rule prescribes to translate the source address
+of the IP packet into some other value.
+.in -8
+
+.SS ip rule add - insert a new rule
+.SS ip rule delete - delete a rule
+
+.TP
+.BI type " TYPE " (default)
+the type of this rule. The list of valid types was given in the previous
+subsection.
+
+.TP
+.BI from " PREFIX"
+select the source prefix to match.
+
+.TP
+.BI to " PREFIX"
+select the destination prefix to match.
+
+.TP
+.BI iif " NAME"
+select the incoming device to match. If the interface is loopback,
+the rule only matches packets originating from this host. This means
+that you may create separate routing tables for forwarded and local
+packets and, hence, completely segregate them.
+
+.TP
+.BI oif " NAME"
+select the outgoing device to match. The outgoing interface is only
+available for packets originating from local sockets that are bound to
+a device.
+
+.TP
+.BI tos " TOS"
+.TP
+.BI dsfield " TOS"
+select the TOS value to match.
+
+.TP
+.BI fwmark " MARK"
+select the
+.B fwmark
+value to match.
+
+.TP
+.BI priority " PREFERENCE"
+the priority of this rule. Each rule should have an explicitly
+set
+.I unique
+priority value.
+The options preference and order are synonyms with priority.
+
+.TP
+.BI table " TABLEID"
+the routing table identifier to lookup if the rule selector matches.
+It is also possible to use lookup instead of table.
+
+.TP
+.BI realms " FROM/TO"
+Realms to select if the rule matched and the routing table lookup
+succeeded. Realm
+.I TO
+is only used if the route did not select any realm.
+
+.TP
+.BI nat " ADDRESS"
+The base of the IP address block to translate (for source addresses).
+The
+.I ADDRESS
+may be either the start of the block of NAT addresses (selected by NAT
+routes) or a local host address (or even zero).
+In the last case the router does not translate the packets, but
+masquerades them to this address.
+Using map-to instead of nat means the same thing.
+
+.B Warning:
+Changes to the RPDB made with these commands do not become active
+immediately. It is assumed that after a script finishes a batch of
+updates, it flushes the routing cache with
+.BR "ip route flush cache" .
+
+.SS ip rule flush - also dumps all the deleted rules.
+This command has no arguments.
+
+.SS ip rule show - list rules
+This command has no arguments.
+The options list or lst are synonyms with show.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-tunnel.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-tunnel.8
new file mode 100755
index 0000000..37ba542
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-tunnel.8
@@ -0,0 +1,242 @@
+.TH IP\-TUNNEL 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-tunnel - tunnel configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B tunnel
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+.BR "ip tunnel" " { " add " | " change " | " del " | " show " | " prl " }"
+.RI "[ " NAME " ]"
+.br
+.RB "[ " mode
+.IR MODE " ] [ "
+.B remote
+.IR ADDR " ] [ "
+.B local
+.IR ADDR " ]"
+.br
+.RB "[ [" i "|" o "]" seq " ] [ [" i "|" o "]" key
+.IR KEY " ] [ "
+.RB "[" i "|" o "]" csum " ] ]"
+.br
+.RB "[ " encaplimit
+.IR ELIM " ]"
+.RB "[ " ttl
+.IR TTL " ]"
+.br
+.RB "[ " tos
+.IR TOS " ] [ "
+.B flowlabel
+.IR FLOWLABEL " ]"
+.br
+.RB "[ " prl-default
+.IR ADDR " ] [ "
+.B prl-nodefault
+.IR ADDR " ] [ "
+.B prl-delete
+.IR ADDR " ]"
+.br
+.RB "[ [" no "]" pmtudisc " ]"
+.RB "[ " dev
+.IR PHYS_DEV " ]"
+.RB "[ " "dscp inherit" " ]"
+
+.ti -8
+.IR MODE " := "
+.RB " { " ipip " | " gre " | " sit " | " isatap " | " ip6ip6 " | " ipip6 " | " any " }"
+
+.ti -8
+.IR ADDR " := { " IP_ADDRESS " |"
+.BR any " }"
+
+.ti -8
+.IR TOS " := { " NUMBER " |"
+.BR inherit " }"
+
+.ti -8
+.IR ELIM " := {"
+.BR none " | "
+.IR 0 ".." 255 " }"
+
+.ti -8
+.ti -8
+.IR TTL " := { " 1 ".." 255 " | "
+.BR inherit " }"
+
+.ti -8
+.IR KEY " := { " DOTTED_QUAD " | " NUMBER " }"
+
+.ti -8
+.IR TIME " := " NUMBER "[s|ms]"
+
+.SH DESCRIPTION
+.B tunnel
+objects are tunnels, encapsulating packets in IP packets and then
+sending them over the IP infrastructure.
+The encapulating (or outer) address family is specified by the
+.B -f
+option. The default is IPv4.
+
+.SS ip tunnel add - add a new tunnel
+.SS ip tunnel change - change an existing tunnel
+.SS ip tunnel delete - destroy a tunnel
+
+.TP
+.BI name " NAME " (default)
+select the tunnel device name.
+
+.TP
+.BI mode " MODE"
+set the tunnel mode. Available modes depend on the encapsulating address family.
+.br
+Modes for IPv4 encapsulation available:
+.BR ipip ", " sit ", " isatap " and " gre "."
+.br
+Modes for IPv6 encapsulation available:
+.BR ip6ip6 ", " ipip6 " and " any "."
+
+.TP
+.BI remote " ADDRESS"
+set the remote endpoint of the tunnel.
+
+.TP
+.BI local " ADDRESS"
+set the fixed local address for tunneled packets.
+It must be an address on another interface of this host.
+
+.TP
+.BI ttl " N"
+set a fixed TTL
+.I N
+on tunneled packets.
+.I N
+is a number in the range 1--255. 0 is a special value
+meaning that packets inherit the TTL value.
+The default value for IPv4 tunnels is:
+.BR "inherit" .
+The default value for IPv6 tunnels is:
+.BR "64" .
+
+
+.TP
+.BI tos " T"
+.TP
+.BI dsfield " T"
+.TP
+.BI tclass " T"
+set a fixed TOS (or traffic class in IPv6)
+.I T
+on tunneled packets.
+The default value is:
+.BR "inherit" .
+
+.TP
+.BI dev " NAME"
+bind the tunnel to the device
+.I NAME
+so that tunneled packets will only be routed via this device and will
+not be able to escape to another device when the route to endpoint
+changes.
+
+.TP
+.B nopmtudisc
+disable Path MTU Discovery on this tunnel.
+It is enabled by default. Note that a fixed ttl is incompatible
+with this option: tunnelling with a fixed ttl always makes pmtu
+discovery.
+
+.TP
+.BI key " K"
+.TP
+.BI ikey " K"
+.TP
+.BI okey " K"
+.RB ( " only GRE tunnels " )
+use keyed GRE with key
+.IR K ". " K
+is either a number or an IP address-like dotted quad.
+The
+.B key
+parameter sets the key to use in both directions.
+The
+.BR ikey " and " okey
+parameters set different keys for input and output.
+
+.TP
+.BR csum ", " icsum ", " ocsum
+.RB ( " only GRE tunnels " )
+generate/require checksums for tunneled packets.
+The
+.B ocsum
+flag calculates checksums for outgoing packets.
+The
+.B icsum
+flag requires that all input packets have the correct
+checksum. The
+.B csum
+flag is equivalent to the combination
+.BR "icsum ocsum" .
+
+.TP
+.BR seq ", " iseq ", " oseq
+.RB ( " only GRE tunnels " )
+serialize packets.
+The
+.B oseq
+flag enables sequencing of outgoing packets.
+The
+.B iseq
+flag requires that all input packets are serialized.
+The
+.B seq
+flag is equivalent to the combination
+.BR "iseq oseq" .
+.B It isn't work. Don't use it.
+
+.TP
+.BR "dscp inherit"
+.RB ( " only IPv6 tunnels " )
+Inherit DS field between inner and outer header.
+
+.TP
+.BI encaplim " ELIM"
+.RB ( " only IPv6 tunnels " )
+set a fixed encapsulation limit. Default is 4.
+
+.TP
+.BI flowlabel " FLOWLABEL"
+.RB ( " only IPv6 tunnels " )
+set a fixed flowlabel.
+
+.SS ip tunnel prl - potential router list (ISATAP only)
+
+.TP
+.BI dev " NAME"
+mandatory device name.
+
+.TP
+.BI prl-default " ADDR"
+.TP
+.BI prl-nodefault " ADDR"
+.TP
+.BI prl-delete " ADDR"
+.RB "Add or delete " ADDR
+as a potential router or default router.
+
+.SS ip tunnel show - list tunnels
+This command has no arguments.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-xfrm.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-xfrm.8
new file mode 100755
index 0000000..f359773
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip-xfrm.8
@@ -0,0 +1,581 @@
+.TH IP\-XFRM 8 "20 Dec 2011" "iproute2" "Linux"
+.SH "NAME"
+ip-xfrm \- transform configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B xfrm
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.B "ip xfrm"
+.IR XFRM-OBJECT " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.IR XFRM-OBJECT " :="
+.BR state " | " policy " | " monitor
+.sp
+
+.ti -8
+.BR "ip xfrm state" " { " add " | " update " } "
+.IR ID " [ " ALGO-LIST " ]"
+.RB "[ " mode
+.IR MODE " ]"
+.RB "[ " mark
+.I MARK
+.RB "[ " mask
+.IR MASK " ] ]"
+.RB "[ " reqid
+.IR REQID " ]"
+.RB "[ " seq
+.IR SEQ " ]"
+.RB "[ " replay-window
+.IR SIZE " ]"
+.RB "[ " replay-seq
+.IR SEQ " ]"
+.RB "[ " replay-oseq
+.IR SEQ " ]"
+.RB "[ " flag
+.IR FLAG-LIST " ]"
+.RB "[ " sel
+.IR SELECTOR " ] [ " LIMIT-LIST " ]"
+.RB "[ " encap
+.IR ENCAP " ]"
+.RB "[ " coa
+.IR ADDR "[/" PLEN "] ]"
+.RB "[ " ctx
+.IR CTX " ]"
+
+.ti -8
+.B "ip xfrm state allocspi"
+.I ID
+.RB "[ " mode
+.IR MODE " ]"
+.RB "[ " mark
+.I MARK
+.RB "[ " mask
+.IR MASK " ] ]"
+.RB "[ " reqid
+.IR REQID " ]"
+.RB "[ " seq
+.IR SEQ " ]"
+.RB "[ " min
+.I SPI
+.B max
+.IR SPI " ]"
+
+.ti -8
+.BR "ip xfrm state" " { " delete " | " get " } "
+.I ID
+.RB "[ " mark
+.I MARK
+.RB "[ " mask
+.IR MASK " ] ]"
+
+.ti -8
+.BR "ip xfrm state" " { " deleteall " | " list " } ["
+.IR ID " ]"
+.RB "[ " mode
+.IR MODE " ]"
+.RB "[ " reqid
+.IR REQID " ]"
+.RB "[ " flag
+.IR FLAG-LIST " ]"
+
+.ti -8
+.BR "ip xfrm state flush" " [ " proto
+.IR XFRM-PROTO " ]"
+
+.ti -8
+.BR "ip xfrm state count"
+
+.ti -8
+.IR ID " :="
+.RB "[ " src
+.IR ADDR " ]"
+.RB "[ " dst
+.IR ADDR " ]"
+.RB "[ " proto
+.IR XFRM-PROTO " ]"
+.RB "[ " spi
+.IR SPI " ]"
+
+.ti -8
+.IR XFRM-PROTO " :="
+.BR esp " | " ah " | " comp " | " route2 " | " hao
+
+.ti -8
+.IR ALGO-LIST " := [ " ALGO-LIST " ] " ALGO
+
+.ti -8
+.IR ALGO " :="
+.RB "{ " enc " | " auth " | " comp " } "
+.IR ALGO-NAME " " ALGO-KEY " |"
+.br
+.B aead
+.IR ALGO-NAME " " ALGO-KEY " " ALGO-ICV-LEN " |"
+.br
+.B auth-trunc
+.IR ALGO-NAME " " ALGO-KEY " " ALGO-TRUNC-LEN
+
+.ti -8
+.IR MODE " := "
+.BR transport " | " tunnel " | " ro " | " in_trigger " | " beet
+
+.ti -8
+.IR FLAG-LIST " := [ " FLAG-LIST " ] " FLAG
+
+.ti -8
+.IR FLAG " :="
+.BR noecn " | " decap-dscp " | " nopmtudisc " | " wildrecv " | " icmp " | " af-unspec " | " align4
+
+.ti -8
+.IR SELECTOR " :="
+.RB "[ " src
+.IR ADDR "[/" PLEN "] ]"
+.RB "[ " dst
+.IR ADDR "[/" PLEN "] ]"
+.RB "[ " dev
+.IR DEV " ]"
+.br
+.RI "[ " UPSPEC " ]"
+
+.ti -8
+.IR UPSPEC " := "
+.BR proto " {"
+.IR PROTO " |"
+.br
+.RB "{ " tcp " | " udp " | " sctp " | " dccp " } [ " sport
+.IR PORT " ]"
+.RB "[ " dport
+.IR PORT " ] |"
+.br
+.RB "{ " icmp " | " ipv6-icmp " | " mobility-header " } [ " type
+.IR NUMBER " ]"
+.RB "[ " code
+.IR NUMBER " ] |"
+.br
+.BR gre " [ " key
+.RI "{ " DOTTED-QUAD " | " NUMBER " } ] }"
+
+.ti -8
+.IR LIMIT-LIST " := [ " LIMIT-LIST " ]"
+.B limit
+.I LIMIT
+
+.ti -8
+.IR LIMIT " :="
+.RB "{ " time-soft " | " time-hard " | " time-use-soft " | " time-use-hard " }"
+.IR "SECONDS" " |"
+.br
+.RB "{ " byte-soft " | " byte-hard " }"
+.IR SIZE " |"
+.br
+.RB "{ " packet-soft " | " packet-hard " }"
+.I COUNT
+
+.ti -8
+.IR ENCAP " :="
+.RB "{ " espinudp " | " espinudp-nonike " }"
+.IR SPORT " " DPORT " " OADDR
+
+.ti -8
+.BR "ip xfrm policy" " { " add " | " update " }"
+.I SELECTOR
+.B dir
+.I DIR
+.RB "[ " ctx
+.IR CTX " ]"
+.RB "[ " mark
+.I MARK
+.RB "[ " mask
+.IR MASK " ] ]"
+.RB "[ " index
+.IR INDEX " ]"
+.RB "[ " ptype
+.IR PTYPE " ]"
+.RB "[ " action
+.IR ACTION " ]"
+.RB "[ " priority
+.IR PRIORITY " ]"
+.RB "[ " flag
+.IR FLAG-LIST " ]"
+.RI "[ " LIMIT-LIST " ] [ " TMPL-LIST " ]"
+
+.ti -8
+.BR "ip xfrm policy" " { " delete " | " get " }"
+.RI "{ " SELECTOR " | "
+.B index
+.IR INDEX " }"
+.B dir
+.I DIR
+.RB "[ " ctx
+.IR CTX " ]"
+.RB "[ " mark
+.I MARK
+.RB "[ " mask
+.IR MASK " ] ]"
+.RB "[ " ptype
+.IR PTYPE " ]"
+
+.ti -8
+.BR "ip xfrm policy" " { " deleteall " | " list " }"
+.RI "[ " SELECTOR " ]"
+.RB "[ " dir
+.IR DIR " ]"
+.RB "[ " index
+.IR INDEX " ]"
+.RB "[ " ptype
+.IR PTYPE " ]"
+.RB "[ " action
+.IR ACTION " ]"
+.RB "[ " priority
+.IR PRIORITY " ]"
+
+.ti -8
+.B "ip xfrm policy flush"
+.RB "[ " ptype
+.IR PTYPE " ]"
+
+.ti -8
+.B "ip xfrm policy count"
+
+.ti -8
+.IR SELECTOR " :="
+.RB "[ " src
+.IR ADDR "[/" PLEN "] ]"
+.RB "[ " dst
+.IR ADDR "[/" PLEN "] ]"
+.RB "[ " dev
+.IR DEV " ]"
+.RI "[ " UPSPEC " ]"
+
+.ti -8
+.IR UPSPEC " := "
+.BR proto " {"
+.IR PROTO " |"
+.br
+.RB "{ " tcp " | " udp " | " sctp " | " dccp " } [ " sport
+.IR PORT " ]"
+.RB "[ " dport
+.IR PORT " ] |"
+.br
+.RB "{ " icmp " | " ipv6-icmp " | " mobility-header " } [ " type
+.IR NUMBER " ]"
+.RB "[ " code
+.IR NUMBER " ] |"
+.br
+.BR gre " [ " key
+.RI "{ " DOTTED-QUAD " | " NUMBER " } ] }"
+
+.ti -8
+.IR DIR " := "
+.BR in " | " out " | " fwd
+
+.ti -8
+.IR PTYPE " := "
+.BR main " | " sub
+
+.ti -8
+.IR ACTION " := "
+.BR allow " | " block
+
+.ti -8
+.IR FLAG-LIST " := [ " FLAG-LIST " ] " FLAG
+
+.ti -8
+.IR FLAG " :="
+.BR localok " | " icmp
+
+.ti -8
+.IR LIMIT-LIST " := [ " LIMIT-LIST " ]"
+.B limit
+.I LIMIT
+
+.ti -8
+.IR LIMIT " :="
+.RB "{ " time-soft " | " time-hard " | " time-use-soft " | " time-use-hard " }"
+.IR "SECONDS" " |"
+.br
+.RB "{ " byte-soft " | " byte-hard " }"
+.IR SIZE " |"
+.br
+.RB "{ " packet-soft " | " packet-hard " }"
+.I COUNT
+
+.ti -8
+.IR TMPL-LIST " := [ " TMPL-LIST " ]"
+.B tmpl
+.I TMPL
+
+.ti -8
+.IR TMPL " := " ID
+.RB "[ " mode
+.IR MODE " ]"
+.RB "[ " reqid
+.IR REQID " ]"
+.RB "[ " level
+.IR LEVEL " ]"
+
+.ti -8
+.IR ID " :="
+.RB "[ " src
+.IR ADDR " ]"
+.RB "[ " dst
+.IR ADDR " ]"
+.RB "[ " proto
+.IR XFRM-PROTO " ]"
+.RB "[ " spi
+.IR SPI " ]"
+
+.ti -8
+.IR XFRM-PROTO " :="
+.BR esp " | " ah " | " comp " | " route2 " | " hao
+
+.ti -8
+.IR MODE " := "
+.BR transport " | " tunnel " | " ro " | " in_trigger " | " beet
+
+.ti -8
+.IR LEVEL " :="
+.BR required " | " use
+
+.ti -8
+.BR "ip xfrm monitor" " [ " all " |"
+.IR LISTofXFRM-OBJECTS " ]"
+
+.in -8
+.ad b
+
+.SH DESCRIPTION
+
+xfrm is an IP framework for transforming packets (such as encrypting
+their payloads). This framework is used to implement the IPsec protocol
+suite (with the
+.B state
+object operating on the Security Association Database, and the
+.B policy
+object operating on the Security Policy Database). It is also used for
+the IP Payload Compression Protocol and features of Mobile IPv6.
+
+.SS ip xfrm state add - add new state into xfrm
+
+.SS ip xfrm state update - update existing state in xfrm
+
+.SS ip xfrm state allocspi - allocate an SPI value
+
+.SS ip xfrm state delete - delete existing state in xfrm
+
+.SS ip xfrm state get - get existing state in xfrm
+
+.SS ip xfrm state deleteall - delete all existing state in xfrm
+
+.SS ip xfrm state list - print out the list of existing state in xfrm
+
+.SS ip xfrm state flush - flush all state in xfrm
+
+.SS ip xfrm state count - count all existing state in xfrm
+
+.TP
+.IR ID
+is specified by a source address, destination address,
+.RI "transform protocol " XFRM-PROTO ","
+and/or Security Parameter Index
+.IR SPI "."
+
+.TP
+.I XFRM-PROTO
+specifies a transform protocol:
+.RB "IPsec Encapsulating Security Payload (" esp "),"
+.RB "IPsec Authentication Header (" ah "),"
+.RB "IP Payload Compression (" comp "),"
+.RB "Mobile IPv6 Type 2 Routing Header (" route2 "), or"
+.RB "Mobile IPv6 Home Address Option (" hao ")."
+
+.TP
+.I ALGO-LIST
+specifies one or more algorithms
+.IR ALGO
+to use. Algorithm types include
+.RB "encryption (" enc "),"
+.RB "authentication (" auth "),"
+.RB "authentication with a specified truncation length (" auth-trunc "),"
+.RB "authenticated encryption with associated data (" aead "), and"
+.RB "compression (" comp ")."
+For each algorithm used, the algorithm type, the algorithm name
+.IR ALGO-NAME ","
+and the key
+.I ALGO-KEY
+must be specified. For
+.BR aead ","
+the Integrity Check Value length
+.I ALGO-ICV-LEN
+must additionally be specified.
+For
+.BR auth-trunc ","
+the signature truncation length
+.I ALGO-TRUNC-LEN
+must additionally be specified.
+
+.TP
+.I MODE
+specifies a mode of operation:
+.RB "IPsec transport mode (" transport "), "
+.RB "IPsec tunnel mode (" tunnel "), "
+.RB "Mobile IPv6 route optimization mode (" ro "), "
+.RB "Mobile IPv6 inbound trigger mode (" in_trigger "), or "
+.RB "IPsec ESP Bound End-to-End Tunnel Mode (" beet ")."
+
+.TP
+.I FLAG-LIST
+contains one or more of the following optional flags:
+.BR noecn ", " decap-dscp ", " nopmtudisc ", " wildrecv ", " icmp ", "
+.BR af-unspec ", or " align4 "."
+
+.TP
+.IR SELECTOR
+selects the traffic that will be controlled by the policy, based on the source
+address, the destination address, the network device, and/or
+.IR UPSPEC "."
+
+.TP
+.IR UPSPEC
+selects traffic by protocol. For the
+.BR tcp ", " udp ", " sctp ", or " dccp
+protocols, the source and destination port can optionally be specified.
+For the
+.BR icmp ", " ipv6-icmp ", or " mobility-header
+protocols, the type and code numbers can optionally be specified.
+For the
+.B gre
+protocol, the key can optionally be specified as a dotted-quad or number.
+Other protocols can be selected by name or number
+.IR PROTO "."
+
+.TP
+.I LIMIT-LIST
+sets limits in seconds, bytes, or numbers of packets.
+
+.TP
+.I ENCAP
+encapsulates packets with protocol
+.BR espinudp " or " espinudp-nonike ","
+.RI "using source port " SPORT ", destination port " DPORT
+.RI ", and original address " OADDR "."
+
+.SS ip xfrm policy add - add a new policy
+
+.SS ip xfrm policy update - update an existing policy
+
+.SS ip xfrm policy delete - delete an existing policy
+
+.SS ip xfrm policy get - get an existing policy
+
+.SS ip xfrm policy deleteall - delete all existing xfrm policies
+
+.SS ip xfrm policy list - print out the list of xfrm policies
+
+.SS ip xfrm policy flush - flush policies
+
+.SS ip xfrm policy count - count existing policies
+
+.TP
+.IR SELECTOR
+selects the traffic that will be controlled by the policy, based on the source
+address, the destination address, the network device, and/or
+.IR UPSPEC "."
+
+.TP
+.IR UPSPEC
+selects traffic by protocol. For the
+.BR tcp ", " udp ", " sctp ", or " dccp
+protocols, the source and destination port can optionally be specified.
+For the
+.BR icmp ", " ipv6-icmp ", or " mobility-header
+protocols, the type and code numbers can optionally be specified.
+For the
+.B gre
+protocol, the key can optionally be specified as a dotted-quad or number.
+Other protocols can be selected by name or number
+.IR PROTO "."
+
+.TP
+.I DIR
+selects the policy direction as
+.BR in ", " out ", or " fwd "."
+
+.TP
+.I CTX
+sets the security context.
+
+.TP
+.I PTYPE
+can be
+.BR main " (default) or " sub "."
+
+.TP
+.I ACTION
+can be
+.BR allow " (default) or " block "."
+
+.TP
+.I PRIORITY
+is a number that defaults to zero.
+
+.TP
+.I FLAG-LIST
+contains one or both of the following optional flags:
+.BR local " or " icmp "."
+
+.TP
+.I LIMIT-LIST
+sets limits in seconds, bytes, or numbers of packets.
+
+.TP
+.I TMPL-LIST
+is a template list specified using
+.IR ID ", " MODE ", " REQID ", and/or " LEVEL ". "
+
+.TP
+.IR ID
+is specified by a source address, destination address,
+.RI "transform protocol " XFRM-PROTO ","
+and/or Security Parameter Index
+.IR SPI "."
+
+.TP
+.I XFRM-PROTO
+specifies a transform protocol:
+.RB "IPsec Encapsulating Security Payload (" esp "),"
+.RB "IPsec Authentication Header (" ah "),"
+.RB "IP Payload Compression (" comp "),"
+.RB "Mobile IPv6 Type 2 Routing Header (" route2 "), or"
+.RB "Mobile IPv6 Home Address Option (" hao ")."
+
+.TP
+.I MODE
+specifies a mode of operation:
+.RB "IPsec transport mode (" transport "), "
+.RB "IPsec tunnel mode (" tunnel "), "
+.RB "Mobile IPv6 route optimization mode (" ro "), "
+.RB "Mobile IPv6 inbound trigger mode (" in_trigger "), or "
+.RB "IPsec ESP Bound End-to-End Tunnel Mode (" beet ")."
+
+.TP
+.I LEVEL
+can be
+.BR required " (default) or " use "."
+
+.SS ip xfrm monitor - state monitoring for xfrm objects
+The xfrm objects to monitor can be optionally specified.
+
+.SH AUTHOR
+Manpage by David Ward
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ip.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip.8
new file mode 100755
index 0000000..ede3d12
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ip.8
@@ -0,0 +1,229 @@
+.TH IP 8 "20 Dec 2011" "iproute2" "Linux"
+.SH NAME
+ip \- show / manipulate routing, devices, policy routing and tunnels
+.SH SYNOPSIS
+
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
+.BR help " }"
+.sp
+
+.ti -8
+.IR OBJECT " := { "
+.BR link " | " addr " | " addrlabel " | " route " | " rule " | " neigh " | "\
+ ntable " | " tunnel " | " tuntap " | " maddr " | " mroute " | " mrule " | "\
+ monitor " | " xfrm " | " netns " | " l2tp " }"
+.sp
+
+.ti -8
+.IR OPTIONS " := { "
+\fB\-V\fR[\fIersion\fR] |
+\fB\-s\fR[\fItatistics\fR] |
+\fB\-r\fR[\fIesolve\fR] |
+\fB\-f\fR[\fIamily\fR] {
+.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
+\fB\-o\fR[\fIneline\fR] }
+
+.SH OPTIONS
+
+.TP
+.BR "\-V" , " -Version"
+print the version of the
+.B ip
+utility and exit.
+
+.TP
+.BR "\-s" , " \-stats", " \-statistics"
+output more information. If the option
+appears twice or more, the amount of information increases.
+As a rule, the information is statistics or some time values.
+
+.TP
+.BR "\-l" , " \-loops"
+Specify maximum number of loops the 'ip addr flush' logic
+will attempt before giving up. The default is 10.
+Zero (0) means loop until all addresses are removed.
+
+.TP
+.BR "\-f" , " \-family"
+followed by protocol family identifier:
+.BR "inet" , " inet6"
+or
+.B link
+,enforce the protocol family to use. If the option is not present,
+the protocol family is guessed from other arguments. If the rest
+of the command line does not give enough information to guess the
+family,
+.B ip
+falls back to the default one, usually
+.B inet
+or
+.BR "any" .
+.B link
+is a special family identifier meaning that no networking protocol
+is involved.
+
+.TP
+.B \-4
+shortcut for
+.BR "-family inet" .
+
+.TP
+.B \-6
+shortcut for
+.BR "\-family inet6" .
+
+.TP
+.B \-0
+shortcut for
+.BR "\-family link" .
+
+.TP
+.BR "\-o" , " \-oneline"
+output each record on a single line, replacing line feeds
+with the
+.B '\e\'
+character. This is convenient when you want to count records
+with
+.BR wc (1)
+ or to
+.BR grep (1)
+the output.
+
+.TP
+.BR "\-r" , " \-resolve"
+use the system's name resolver to print DNS names instead of
+host addresses.
+
+.SH IP - COMMAND SYNTAX
+
+.SS
+.I OBJECT
+
+.TP
+.B address
+- protocol (IP or IPv6) address on a device.
+
+.TP
+.B addrlabel
+- label configuration for protocol address selection.
+
+.TP
+.B l2tp
+- tunnel ethernet over IP (L2TPv3).
+
+.TP
+.B link
+- network device.
+
+.TP
+.B maddress
+- multicast address.
+
+.TP
+.B monitor
+- watch for netlink messages.
+
+.TP
+.B mroute
+- multicast routing cache entry.
+
+.TP
+.B mrule
+- rule in multicast routing policy database.
+
+.TP
+.B neighbour
+- manage ARP or NDISC cache entries.
+
+.TP
+.B netns
+- manage network namespaces.
+
+.TP
+.B ntable
+- manage the neighbor cache's operation.
+
+.TP
+.B route
+- routing table entry.
+
+.TP
+.B rule
+- rule in routing policy database.
+
+.TP
+.B tunnel
+- tunnel over IP.
+
+.TP
+.B tuntap
+- manage TUN/TAP devices.
+
+.TP
+.B xfrm
+- manage IPSec policies.
+
+.PP
+The names of all objects may be written in full or
+abbreviated form, f.e.
+.B address
+is abbreviated as
+.B addr
+or just
+.B a.
+
+.SS
+.I COMMAND
+
+Specifies the action to perform on the object.
+The set of possible actions depends on the object type.
+As a rule, it is possible to
+.BR "add" , " delete"
+and
+.B show
+(or
+.B list
+) objects, but some objects do not allow all of these operations
+or have some additional commands. The
+.B help
+command is available for all objects. It prints
+out a list of available commands and argument syntax conventions.
+.sp
+If no command is given, some default command is assumed.
+Usually it is
+.B list
+or, if the objects of this class cannot be listed,
+.BR "help" .
+
+.SH HISTORY
+.B ip
+was written by Alexey N. Kuznetsov and added in Linux 2.2.
+.SH SEE ALSO
+.BR ip-address (8),
+.BR ip-addrlabel (8),
+.BR ip-l2tp (8),
+.BR ip-link (8),
+.BR ip-maddress (8),
+.BR ip-monitor (8),
+.BR ip-mroute (8),
+.BR ip-neighbour (8),
+.BR ip-netns (8),
+.BR ip-ntable (8),
+.BR ip-route (8),
+.BR ip-rule (8),
+.BR ip-tunnel (8),
+.BR ip-xfrm (8)
+.br
+.RB "IP Command reference " ip-cref.ps
+.SH REPORTING BUGS
+Report bug to the Network Developers mailing list
+.B <netdev@vger.kernel.org>
+where the development and maintenance is primarily done.
+You do not have to be subscribed to the list to send a message there.
+
+.SH AUTHOR
+Original Manpage by Michail Litvak <mci@owl.openwall.com>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/lnstat.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/lnstat.8
new file mode 100755
index 0000000..315a8e5
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/lnstat.8
@@ -0,0 +1,75 @@
+.TH LNSTAT 8
+.SH NAME
+lnstat \- unified linux network statistics
+.SH SYNOPSIS
+.B lnstat
+.RI [ options ]
+.SH DESCRIPTION
+This manual page documents briefly the
+.B lnstat
+command.
+.PP
+\fBlnstat\fP is a generalized and more feature-complete replacement for the old rtstat program.
+In addition to routing cache statistics, it supports any kind of statistics the linux kernel
+exports via a file in /proc/net/stat/.
+.SH OPTIONS
+These programs follow the usual GNU command line syntax, with long
+options starting with two dashes (`-').
+lnstat supports the following options.
+.TP
+.B \-h, \-\-help
+Show summary of options.
+.TP
+.B \-V, \-\-version
+Show version of program.
+.TP
+.B \-c, \-\-count <count>
+Print <count> number of intervals.
+.TP
+.B \-d, \-\-dump
+Dump list of available files/keys.
+.TP
+.B \-f, \-\-file <file>
+Statistics file to use.
+.TP
+.B \-i, \-\-interval <intv>
+Set interval to 'intv' seconds.
+.TP
+.B \-k, \-\-keys k,k,k,...
+Display only keys specified.
+.TP
+.B \-s, \-\-subject [0-2]
+Specify display of subject/header. '0' means no header at all, '1' prints a header only at start of the program and '2' prints a header every 20 lines.
+.TP
+.B \-w, \-\-width n,n,n,...
+Width for each field.
+.SH USAGE EXAMPLES
+.TP
+.B # lnstat -d
+Get a list of supported statistics files.
+.TP
+.B # lnstat -k arp_cache:entries,rt_cache:in_hit,arp_cache:destroys
+Select the specified files and keys.
+.TP
+.B # lnstat -i 10
+Use an interval of 10 seconds.
+.TP
+.B # lnstat -f ip_conntrack
+Use only the specified file for statistics.
+.TP
+.B # lnstat -s 0
+Do not print a header at all.
+.TP
+.B # lnstat -s 20
+Print a header at start and every 20 lines.
+.TP
+.B # lnstat -c -1 -i 1 -f rt_cache -k entries,in_hit,in_slow_tot
+Display statistics for keys entries, in_hit and in_slow_tot of field rt_cache every second.
+.SH SEE ALSO
+.BR ip (8),
+and /usr/share/doc/iproute-doc/README.lnstat (package iproute-doc on Debian)
+.br
+.SH AUTHOR
+lnstat was written by Harald Welte <laforge@gnumonks.org>.
+.PP
+This manual page was written by Michael Prokop <mika@grml.org> for the Debian project (but may be used by others).
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/nstat.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/nstat.8
new file mode 100755
index 0000000..c703cc8
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/nstat.8
@@ -0,0 +1 @@
+.so man8/rtacct.8
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/routef.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/routef.8
new file mode 100755
index 0000000..c2a7059
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/routef.8
@@ -0,0 +1 @@
+.so man8/routel.8
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/routel.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/routel.8
new file mode 100755
index 0000000..cdf8f55
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/routel.8
@@ -0,0 +1,32 @@
+.TH "ROUTEL" "8" "3 Jan, 2008" "iproute2" "Linux"
+.SH "NAME"
+.LP
+routel \- list routes with pretty output format
+.br
+routef \- flush routes
+.SH "SYNTAX"
+.LP
+routel [\fItablenr\fP [\fIraw ip args...\fP]]
+.br
+routef
+.SH "DESCRIPTION"
+.LP
+These programs are a set of helper scripts you can use instead of raw iproute2 commands.
+.br
+The routel script will list routes in a format that some might consider easier to interpret then the ip route list equivalent.
+.br
+The routef script does not take any arguments and will simply flush the routing table down the drain. Beware! This means deleting all routes which will make your network unusable!
+
+.SH "FILES"
+.LP
+\fI/usr/bin/routef\fP
+.br
+\fI/usr/bin/routel\fP
+.SH "AUTHORS"
+.LP
+The routel script was written by Stephen R. van den Berg <srb@cuci.nl>, 1999/04/18 and donated to the public domain.
+.br
+This manual page was written by Andreas Henriksson <andreas@fatal.se>, for the Debian GNU/Linux system.
+.SH "SEE ALSO"
+.LP
+ip(8)
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/rtacct.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/rtacct.8
new file mode 100755
index 0000000..fb9afe8
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/rtacct.8
@@ -0,0 +1,48 @@
+.TH RTACCT 8 "27 June, 2007"
+
+.SH NAME
+nstat, rtacct - network statistics tools.
+
+.SH SYNOPSIS
+Usage: nstat [ -h?vVzrnasd:t: ] [ PATTERN [ PATTERN ] ]
+.br
+Usage: rtacct [ -h?vVzrnasd:t: ] [ ListOfRealms ]
+
+.SH DESCRIPTION
+.B nstat
+and
+.B rtacct
+are simple tools to monitor kernel snmp counters and network interface statistics.
+
+.SH OPTIONS
+.TP
+-h -?
+Print help
+.TP
+-v -V
+Print version
+.TP
+-z
+Dump zero counters too. By default they are not shown.
+.TP
+-r
+Reset history.
+.TP
+-n
+Do not display anything, only update history.
+.TP
+-a
+Dump absolute values of counters. The default is to calculate increments since the previous use.
+.TP
+-s
+Do not update history, so that the next time you will see counters including values accumulated to the moment of this measurement too.
+.TP
+-d <INTERVAL>
+Run in daemon mode collecting statistics. <INTERVAL> is interval between measurements in seconds.
+.TP
+-t <INTERVAL>
+Time interval to average rates. Default value is 60 seconds.
+
+.SH SEE ALSO
+lnstat(8)
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/rtmon.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/rtmon.8
new file mode 100755
index 0000000..c9359d8
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/rtmon.8
@@ -0,0 +1,68 @@
+.TH RTMON 8
+.SH NAME
+rtmon \- listens to and monitors RTnetlink
+.SH SYNOPSIS
+.B rtmon
+.RI "[ options ] file FILE [ all | LISTofOBJECTS ]"
+.SH DESCRIPTION
+This manual page documents briefly the
+.B rtmon
+command.
+.PP
+.B rtmon
+listens on
+.I netlink
+socket and monitors routing table changes.
+
+.I rtmon
+can be started before the first network configuration command is issued.
+For example if you insert:
+
+.B rtmon file /var/log/rtmon.log
+
+in a startup script, you will be able to view the full history later.
+Certainly, it is possible to start rtmon at any time. It prepends the history with the state snapshot dumped at the moment of starting.
+
+.SH OPTIONS
+.I rtmon supports the following options:
+.TP
+.B \-Version
+Print version and exit.
+.TP
+.B help
+Show summary of options.
+.TP
+.B file FILE [ all | LISTofOBJECTS ]
+Log output to FILE. LISTofOBJECTS is the list of object types that we
+want to monitor. It may contain 'link', 'address', 'route'
+and 'all'. 'link' specifies the network device, 'address' the protocol
+(IP or IPv6) address on a device, 'route' the routing table entry
+and 'all' does what the name says.
+.TP
+.B \-family [ inet | inet6 | link | help ]
+Specify protocol family. 'inet' is IPv4, 'inet6' is IPv6, 'link'
+means that no networking protocol is involved and 'help' prints usage information.
+.TP
+.B \-4
+Use IPv4. Shortcut for -family inet.
+.TP
+.B \-6
+Use IPv6. Shortcut for -family inet6.
+.TP
+.B \-0
+Use a special family identifier meaning that no networking protocol is involved. Shortcut for -family link.
+.SH USAGE EXAMPLES
+.TP
+.B # rtmon file /var/log/rtmon.log
+Log to file /var/log/rtmon.log, then run:
+.TP
+.B # ip monitor file /var/log/rtmon.log
+to display logged output from file.
+.SH SEE ALSO
+.BR ip (8)
+.SH AUTHOR
+.B rtmon
+was written by Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>.
+.PP
+This manual page was written by Michael Prokop <mika@grml.org>,
+for the Debian project (but may be used by others).
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/rtstat.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/rtstat.8
new file mode 100755
index 0000000..080e2b2
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/rtstat.8
@@ -0,0 +1 @@
+.so man8/lnstat.8
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/ss.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/ss.8
new file mode 100755
index 0000000..0b9a8c4
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/ss.8
@@ -0,0 +1,126 @@
+.TH SS 8
+.SH NAME
+ss \- another utility to investigate sockets
+.SH SYNOPSIS
+.B ss
+.RI [ options ] " [ FILTER ]"
+.SH DESCRIPTION
+.B ss
+is used to dump socket statistics. It allows showing information similar
+to
+.IR netstat .
+It can display more TCP and state informations than other tools.
+
+.SH OPTIONS
+When no option is used ss displays a list of
+open non-listening TCP sockets that have established connection.
+.TP
+These programs follow the usual GNU command line syntax, with long
+options starting with two dashes (`-').
+A summary of options is included below.
+.TP
+.B \-h, \-\-help
+Show summary of options.
+.TP
+.B \-V, \-\-version
+Output version information.
+.TP
+.B \-n, \-\-numeric
+Do not try to resolve service names.
+.TP
+.B \-r, \-\-resolve
+Try to resolve numeric address/ports.
+.TP
+.B \-a, \-\-all
+Display both listening and non-listening (for TCP this means established connections) sockets.
+.TP
+.B \-l, \-\-listening
+Display only listening sockets (these are omitted by default).
+.TP
+.B \-o, \-\-options
+Show timer information.
+.TP
+.B \-e, \-\-extended
+Show detailed socket information
+.TP
+.B \-m, \-\-memory
+Show socket memory usage.
+.TP
+.B \-p, \-\-processes
+Show process using socket.
+.TP
+.B \-i, \-\-info
+Show internal TCP information.
+.TP
+.B \-s, \-\-summary
+Print summary statistics. This option does not parse socket lists obtaining
+summary from various sources. It is useful when amount of sockets is so huge
+that parsing /proc/net/tcp is painful.
+.TP
+.B \-4, \-\-ipv4
+Display only IP version 4 sockets (alias for -f inet).
+.TP
+.B \-6, \-\-ipv6
+Display only IP version 6 sockets (alias for -f inet6).
+.TP
+.B \-0, \-\-packet
+Display PACKET sockets (alias for -f link).
+.TP
+.B \-t, \-\-tcp
+Display TCP sockets.
+.TP
+.B \-u, \-\-udp
+Display UDP sockets.
+.TP
+.B \-d, \-\-dccp
+Display DCCP sockets.
+.TP
+.B \-w, \-\-raw
+Display RAW sockets.
+.TP
+.B \-x, \-\-unix
+Display Unix domain sockets (alias for -f unix).
+.TP
+.B \-f FAMILY, \-\-family=FAMILY
+Display sockets of type FAMILY.
+Currently the following families are supported: unix, inet, inet6, link, netlink.
+.TP
+.B \-A QUERY, \-\-query=QUERY, \-\-socket=QUERY
+List of socket tables to dump, separated by commas. The following identifiers
+are understood: all, inet, tcp, udp, raw, unix, packet, netlink, unix_dgram,
+unix_stream, packet_raw, packet_dgram.
+.TP
+.B \-D FILE, \-\-diag=FILE
+Do not display anything, just dump raw information about TCP sockets to FILE after applying filters. If FILE is - stdout is used.
+.TP
+.B \-F FILE, \-\-filter=FILE
+Read filter information from FILE.
+Each line of FILE is interpreted like single command line option. If FILE is - stdin is used.
+.TP
+.B FILTER := [ state TCP-STATE ] [ EXPRESSION ]
+Please take a look at the official documentation (Debian package iproute-doc) for details regarding filters.
+.SH USAGE EXAMPLES
+.TP
+.B ss -t -a
+Display all TCP sockets.
+.TP
+.B ss -u -a
+Display all UDP sockets.
+.TP
+.B ss -o state established '( dport = :ssh or sport = :ssh )'
+Display all established ssh connections.
+.TP
+.B ss -x src /tmp/.X11-unix/*
+Find all local processes connected to X server.
+.TP
+.B ss -o state fin-wait-1 '( sport = :http or sport = :https )' dst 193.233.7/24
+List all the tcp sockets in state FIN-WAIT-1 for our apache to network 193.233.7/24 and look at their timers.
+.SH SEE ALSO
+.BR ip (8),
+.BR /usr/share/doc/iproute-doc/ss.html " (package iproutedoc)"
+.SH AUTHOR
+.I ss
+was written by Alexey Kuznetosv, <kuznet@ms2.inr.ac.ru>.
+.PP
+This manual page was written by Michael Prokop <mika@grml.org>
+for the Debian project (but may be used by others).
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-bfifo.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-bfifo.8
new file mode 100755
index 0000000..8dda4bb
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-bfifo.8
@@ -0,0 +1,72 @@
+.TH PBFIFO 8 "10 January 2002" "iproute2" "Linux"
+.SH NAME
+pfifo \- Packet limited First In, First Out queue
+.P
+bfifo \- Byte limited First In, First Out queue
+
+.SH SYNOPSIS
+.B tc qdisc ... add pfifo
+.B [ limit
+packets
+.B ]
+.P
+.B tc qdisc ... add bfifo
+.B [ limit
+bytes
+.B ]
+
+.SH DESCRIPTION
+The pfifo and bfifo qdiscs are unadorned First In, First Out queues. They are the
+simplest queues possible and therefore have no overhead.
+.B pfifo
+constrains the queue size as measured in packets.
+.B bfifo
+does so as measured in bytes.
+
+Like all non-default qdiscs, they maintain statistics. This might be a reason to prefer
+pfifo or bfifo over the default.
+
+.SH ALGORITHM
+A list of packets is maintained, when a packet is enqueued it gets inserted at the tail of
+a list. When a packet needs to be sent out to the network, it is taken from the head of the list.
+
+If the list is too long, no further packets are allowed on. This is called 'tail drop'.
+
+.SH PARAMETERS
+.TP
+limit
+Maximum queue size. Specified in bytes for bfifo, in packets for pfifo. For pfifo, defaults
+to the interface txqueuelen, as specified with
+.BR ifconfig (8)
+or
+.BR ip (8).
+
+For bfifo, it defaults to the txqueuelen multiplied by the interface MTU.
+
+.SH OUTPUT
+The output of
+.B tc -s qdisc ls
+contains the limit, either in packets or in bytes, and the number of bytes
+and packets actually sent. An unsent and dropped packet only appears between braces
+and is not counted as 'Sent'.
+
+In this example, the queue length is 100 packets, 45894 bytes were sent over 681 packets.
+No packets were dropped, and as the pfifo queue does not slow down packets, there were also no
+overlimits:
+.P
+.nf
+# tc -s qdisc ls dev eth0
+qdisc pfifo 8001: dev eth0 limit 100p
+ Sent 45894 bytes 681 pkts (dropped 0, overlimits 0)
+.fi
+
+If a backlog occurs, this is displayed as well.
+.SH SEE ALSO
+.BR tc (8)
+
+.SH AUTHORS
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
+
+This manpage maintained by bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-cbq-details.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-cbq-details.8
new file mode 100755
index 0000000..09badb9
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-cbq-details.8
@@ -0,0 +1,425 @@
+.TH CBQ 8 "8 December 2001" "iproute2" "Linux"
+.SH NAME
+CBQ \- Class Based Queueing
+.SH SYNOPSIS
+.B tc qdisc ... dev
+dev
+.B ( parent
+classid
+.B | root) [ handle
+major:
+.B ] cbq avpkt
+bytes
+.B bandwidth
+rate
+.B [ cell
+bytes
+.B ] [ ewma
+log
+.B ] [ mpu
+bytes
+.B ]
+
+.B tc class ... dev
+dev
+.B parent
+major:[minor]
+.B [ classid
+major:minor
+.B ] cbq allot
+bytes
+.B [ bandwidth
+rate
+.B ] [ rate
+rate
+.B ] prio
+priority
+.B [ weight
+weight
+.B ] [ minburst
+packets
+.B ] [ maxburst
+packets
+.B ] [ ewma
+log
+.B ] [ cell
+bytes
+.B ] avpkt
+bytes
+.B [ mpu
+bytes
+.B ] [ bounded isolated ] [ split
+handle
+.B & defmap
+defmap
+.B ] [ estimator
+interval timeconstant
+.B ]
+
+.SH DESCRIPTION
+Class Based Queueing is a classful qdisc that implements a rich
+linksharing hierarchy of classes. It contains shaping elements as
+well as prioritizing capabilities. Shaping is performed using link
+idle time calculations based on the timing of dequeue events and
+underlying link bandwidth.
+
+.SH SHAPING ALGORITHM
+Shaping is done using link idle time calculations, and actions taken if
+these calculations deviate from set limits.
+
+When shaping a 10mbit/s connection to 1mbit/s, the link will
+be idle 90% of the time. If it isn't, it needs to be throttled so that it
+IS idle 90% of the time.
+
+From the kernel's perspective, this is hard to measure, so CBQ instead
+derives the idle time from the number of microseconds (in fact, jiffies)
+that elapse between requests from the device driver for more data. Combined
+with the knowledge of packet sizes, this is used to approximate how full or
+empty the link is.
+
+This is rather circumspect and doesn't always arrive at proper
+results. For example, what is the actual link speed of an interface
+that is not really able to transmit the full 100mbit/s of data,
+perhaps because of a badly implemented driver? A PCMCIA network card
+will also never achieve 100mbit/s because of the way the bus is
+designed - again, how do we calculate the idle time?
+
+The physical link bandwidth may be ill defined in case of not-quite-real
+network devices like PPP over Ethernet or PPTP over TCP/IP. The effective
+bandwidth in that case is probably determined by the efficiency of pipes
+to userspace - which not defined.
+
+During operations, the effective idletime is measured using an
+exponential weighted moving average (EWMA), which considers recent
+packets to be exponentially more important than past ones. The Unix
+loadaverage is calculated in the same way.
+
+The calculated idle time is subtracted from the EWMA measured one,
+the resulting number is called 'avgidle'. A perfectly loaded link has
+an avgidle of zero: packets arrive exactly at the calculated
+interval.
+
+An overloaded link has a negative avgidle and if it gets too negative,
+CBQ throttles and is then 'overlimit'.
+
+Conversely, an idle link might amass a huge avgidle, which would then
+allow infinite bandwidths after a few hours of silence. To prevent
+this, avgidle is capped at
+.B maxidle.
+
+If overlimit, in theory, the CBQ could throttle itself for exactly the
+amount of time that was calculated to pass between packets, and then
+pass one packet, and throttle again. Due to timer resolution constraints,
+this may not be feasible, see the
+.B minburst
+parameter below.
+
+.SH CLASSIFICATION
+Within the one CBQ instance many classes may exist. Each of these classes
+contains another qdisc, by default
+.BR tc-pfifo (8).
+
+When enqueueing a packet, CBQ starts at the root and uses various methods to
+determine which class should receive the data. If a verdict is reached, this
+process is repeated for the recipient class which might have further
+means of classifying traffic to its children, if any.
+
+CBQ has the following methods available to classify a packet to any child
+classes.
+.TP
+(i)
+.B skb->priority class encoding.
+Can be set from userspace by an application with the
+.B SO_PRIORITY
+setsockopt.
+The
+.B skb->priority class encoding
+only applies if the skb->priority holds a major:minor handle of an existing
+class within this qdisc.
+.TP
+(ii)
+tc filters attached to the class.
+.TP
+(iii)
+The defmap of a class, as set with the
+.B split & defmap
+parameters. The defmap may contain instructions for each possible Linux packet
+priority.
+
+.P
+Each class also has a
+.B level.
+Leaf nodes, attached to the bottom of the class hierarchy, have a level of 0.
+.SH CLASSIFICATION ALGORITHM
+
+Classification is a loop, which terminates when a leaf class is found. At any
+point the loop may jump to the fallback algorithm.
+
+The loop consists of the following steps:
+.TP
+(i)
+If the packet is generated locally and has a valid classid encoded within its
+.B skb->priority,
+choose it and terminate.
+
+.TP
+(ii)
+Consult the tc filters, if any, attached to this child. If these return
+a class which is not a leaf class, restart loop from the class returned.
+If it is a leaf, choose it and terminate.
+.TP
+(iii)
+If the tc filters did not return a class, but did return a classid,
+try to find a class with that id within this qdisc.
+Check if the found class is of a lower
+.B level
+than the current class. If so, and the returned class is not a leaf node,
+restart the loop at the found class. If it is a leaf node, terminate.
+If we found an upward reference to a higher level, enter the fallback
+algorithm.
+.TP
+(iv)
+If the tc filters did not return a class, nor a valid reference to one,
+consider the minor number of the reference to be the priority. Retrieve
+a class from the defmap of this class for the priority. If this did not
+contain a class, consult the defmap of this class for the
+.B BEST_EFFORT
+class. If this is an upward reference, or no
+.B BEST_EFFORT
+class was defined,
+enter the fallback algorithm. If a valid class was found, and it is not a
+leaf node, restart the loop at this class. If it is a leaf, choose it and
+terminate. If
+neither the priority distilled from the classid, nor the
+.B BEST_EFFORT
+priority yielded a class, enter the fallback algorithm.
+.P
+The fallback algorithm resides outside of the loop and is as follows.
+.TP
+(i)
+Consult the defmap of the class at which the jump to fallback occured. If
+the defmap contains a class for the
+.B
+priority
+of the class (which is related to the TOS field), choose this class and
+terminate.
+.TP
+(ii)
+Consult the map for a class for the
+.B BEST_EFFORT
+priority. If found, choose it, and terminate.
+.TP
+(iii)
+Choose the class at which break out to the fallback algorithm occurred. Terminate.
+.P
+The packet is enqueued to the class which was chosen when either algorithm
+terminated. It is therefore possible for a packet to be enqueued *not* at a
+leaf node, but in the middle of the hierarchy.
+
+.SH LINK SHARING ALGORITHM
+When dequeuing for sending to the network device, CBQ decides which of its
+classes will be allowed to send. It does so with a Weighted Round Robin process
+in which each class with packets gets a chance to send in turn. The WRR process
+starts by asking the highest priority classes (lowest numerically -
+highest semantically) for packets, and will continue to do so until they
+have no more data to offer, in which case the process repeats for lower
+priorities.
+
+.B CERTAINTY ENDS HERE, ANK PLEASE HELP
+
+Each class is not allowed to send at length though - they can only dequeue a
+configurable amount of data during each round.
+
+If a class is about to go overlimit, and it is not
+.B bounded
+it will try to borrow avgidle from siblings that are not
+.B isolated.
+This process is repeated from the bottom upwards. If a class is unable
+to borrow enough avgidle to send a packet, it is throttled and not asked
+for a packet for enough time for the avgidle to increase above zero.
+
+.B I REALLY NEED HELP FIGURING THIS OUT. REST OF DOCUMENT IS PRETTY CERTAIN
+.B AGAIN.
+
+.SH QDISC
+The root qdisc of a CBQ class tree has the following parameters:
+
+.TP
+parent major:minor | root
+This mandatory parameter determines the place of the CBQ instance, either at the
+.B root
+of an interface or within an existing class.
+.TP
+handle major:
+Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
+of a major number, followed by a colon. Optional.
+.TP
+avpkt bytes
+For calculations, the average packet size must be known. It is silently capped
+at a minimum of 2/3 of the interface MTU. Mandatory.
+.TP
+bandwidth rate
+To determine the idle time, CBQ must know the bandwidth of your underlying
+physical interface, or parent qdisc. This is a vital parameter, more about it
+later. Mandatory.
+.TP
+cell
+The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
+.TP
+mpu
+A zero sized packet may still take time to transmit. This value is the lower
+cap for packet transmission time calculations - packets smaller than this value
+are still deemed to have this size. Defaults to zero.
+.TP
+ewma log
+When CBQ needs to measure the average idle time, it does so using an
+Exponentially Weighted Moving Average which smoothes out measurements into
+a moving average. The EWMA LOG determines how much smoothing occurs. Defaults
+to 5. Lower values imply greater sensitivity. Must be between 0 and 31.
+.P
+A CBQ qdisc does not shape out of its own accord. It only needs to know certain
+parameters about the underlying link. Actual shaping is done in classes.
+
+.SH CLASSES
+Classes have a host of parameters to configure their operation.
+
+.TP
+parent major:minor
+Place of this class within the hierarchy. If attached directly to a qdisc
+and not to another class, minor can be omitted. Mandatory.
+.TP
+classid major:minor
+Like qdiscs, classes can be named. The major number must be equal to the
+major number of the qdisc to which it belongs. Optional, but needed if this
+class is going to have children.
+.TP
+weight weight
+When dequeuing to the interface, classes are tried for traffic in a
+round-robin fashion. Classes with a higher configured qdisc will generally
+have more traffic to offer during each round, so it makes sense to allow
+it to dequeue more traffic. All weights under a class are normalized, so
+only the ratios matter. Defaults to the configured rate, unless the priority
+of this class is maximal, in which case it is set to 1.
+.TP
+allot bytes
+Allot specifies how many bytes a qdisc can dequeue
+during each round of the process. This parameter is weighted using the
+renormalized class weight described above.
+
+.TP
+priority priority
+In the round-robin process, classes with the lowest priority field are tried
+for packets first. Mandatory.
+
+.TP
+rate rate
+Maximum rate this class and all its children combined can send at. Mandatory.
+
+.TP
+bandwidth rate
+This is different from the bandwidth specified when creating a CBQ disc. Only
+used to determine maxidle and offtime, which are only calculated when
+specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
+
+.TP
+maxburst
+This number of packets is used to calculate maxidle so that when
+avgidle is at maxidle, this number of average packets can be burst
+before avgidle drops to 0. Set it higher to be more tolerant of
+bursts. You can't set maxidle directly, only via this parameter.
+
+.TP
+minburst
+As mentioned before, CBQ needs to throttle in case of
+overlimit. The ideal solution is to do so for exactly the calculated
+idle time, and pass 1 packet. However, Unix kernels generally have a
+hard time scheduling events shorter than 10ms, so it is better to
+throttle for a longer period, and then pass minburst packets in one
+go, and then sleep minburst times longer.
+
+The time to wait is called the offtime. Higher values of minburst lead
+to more accurate shaping in the long term, but to bigger bursts at
+millisecond timescales.
+
+.TP
+minidle
+If avgidle is below 0, we are overlimits and need to wait until
+avgidle will be big enough to send one packet. To prevent a sudden
+burst from shutting down the link for a prolonged period of time,
+avgidle is reset to minidle if it gets too low.
+
+Minidle is specified in negative microseconds, so 10 means that
+avgidle is capped at -10us.
+
+.TP
+bounded
+Signifies that this class will not borrow bandwidth from its siblings.
+.TP
+isolated
+Means that this class will not borrow bandwidth to its siblings
+
+.TP
+split major:minor & defmap bitmap[/bitmap]
+If consulting filters attached to a class did not give a verdict,
+CBQ can also classify based on the packet's priority. There are 16
+priorities available, numbered from 0 to 15.
+
+The defmap specifies which priorities this class wants to receive,
+specified as a bitmap. The Least Significant Bit corresponds to priority
+zero. The
+.B split
+parameter tells CBQ at which class the decision must be made, which should
+be a (grand)parent of the class you are adding.
+
+As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
+configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
+
+The complimentary configuration would then
+be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
+Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
+.TP
+estimator interval timeconstant
+CBQ can measure how much bandwidth each class is using, which tc filters
+can use to classify packets with. In order to determine the bandwidth
+it uses a very simple estimator that measures once every
+.B interval
+microseconds how much traffic has passed. This again is a EWMA, for which
+the time constant can be specified, also in microseconds. The
+.B time constant
+corresponds to the sluggishness of the measurement or, conversely, to the
+sensitivity of the average to short bursts. Higher values mean less
+sensitivity.
+
+
+
+.SH SOURCES
+.TP
+o
+Sally Floyd and Van Jacobson, "Link-sharing and Resource
+Management Models for Packet Networks",
+IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
+
+.TP
+o
+Sally Floyd, "Notes on CBQ and Guarantee Service", 1995
+
+.TP
+o
+Sally Floyd, "Notes on Class-Based Queueing: Setting
+Parameters", 1996
+
+.TP
+o
+Sally Floyd and Michael Speer, "Experimental Results
+for Class-Based Queueing", 1998, not published.
+
+
+
+.SH SEE ALSO
+.BR tc (8)
+
+.SH AUTHOR
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
+bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-cbq.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-cbq.8
new file mode 100755
index 0000000..79fb93b
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-cbq.8
@@ -0,0 +1,353 @@
+.TH CBQ 8 "16 December 2001" "iproute2" "Linux"
+.SH NAME
+CBQ \- Class Based Queueing
+.SH SYNOPSIS
+.B tc qdisc ... dev
+dev
+.B ( parent
+classid
+.B | root) [ handle
+major:
+.B ] cbq [ allot
+bytes
+.B ] avpkt
+bytes
+.B bandwidth
+rate
+.B [ cell
+bytes
+.B ] [ ewma
+log
+.B ] [ mpu
+bytes
+.B ]
+
+.B tc class ... dev
+dev
+.B parent
+major:[minor]
+.B [ classid
+major:minor
+.B ] cbq allot
+bytes
+.B [ bandwidth
+rate
+.B ] [ rate
+rate
+.B ] prio
+priority
+.B [ weight
+weight
+.B ] [ minburst
+packets
+.B ] [ maxburst
+packets
+.B ] [ ewma
+log
+.B ] [ cell
+bytes
+.B ] avpkt
+bytes
+.B [ mpu
+bytes
+.B ] [ bounded isolated ] [ split
+handle
+.B & defmap
+defmap
+.B ] [ estimator
+interval timeconstant
+.B ]
+
+.SH DESCRIPTION
+Class Based Queueing is a classful qdisc that implements a rich
+linksharing hierarchy of classes. It contains shaping elements as
+well as prioritizing capabilities. Shaping is performed using link
+idle time calculations based on the timing of dequeue events and
+underlying link bandwidth.
+
+.SH SHAPING ALGORITHM
+When shaping a 10mbit/s connection to 1mbit/s, the link will
+be idle 90% of the time. If it isn't, it needs to be throttled so that it
+IS idle 90% of the time.
+
+During operations, the effective idletime is measured using an
+exponential weighted moving average (EWMA), which considers recent
+packets to be exponentially more important than past ones. The Unix
+loadaverage is calculated in the same way.
+
+The calculated idle time is subtracted from the EWMA measured one,
+the resulting number is called 'avgidle'. A perfectly loaded link has
+an avgidle of zero: packets arrive exactly at the calculated
+interval.
+
+An overloaded link has a negative avgidle and if it gets too negative,
+CBQ throttles and is then 'overlimit'.
+
+Conversely, an idle link might amass a huge avgidle, which would then
+allow infinite bandwidths after a few hours of silence. To prevent
+this, avgidle is capped at
+.B maxidle.
+
+If overlimit, in theory, the CBQ could throttle itself for exactly the
+amount of time that was calculated to pass between packets, and then
+pass one packet, and throttle again. Due to timer resolution constraints,
+this may not be feasible, see the
+.B minburst
+parameter below.
+
+.SH CLASSIFICATION
+Within the one CBQ instance many classes may exist. Each of these classes
+contains another qdisc, by default
+.BR tc-pfifo (8).
+
+When enqueueing a packet, CBQ starts at the root and uses various methods to
+determine which class should receive the data.
+
+In the absence of uncommon configuration options, the process is rather easy.
+At each node we look for an instruction, and then go to the class the
+instruction refers us to. If the class found is a barren leaf-node (without
+children), we enqueue the packet there. If it is not yet a leaf node, we do
+the whole thing over again starting from that node.
+
+The following actions are performed, in order at each node we visit, until one
+sends us to another node, or terminates the process.
+.TP
+(i)
+Consult filters attached to the class. If sent to a leafnode, we are done.
+Otherwise, restart.
+.TP
+(ii)
+Consult the defmap for the priority assigned to this packet, which depends
+on the TOS bits. Check if the referral is leafless, otherwise restart.
+.TP
+(iii)
+Ask the defmap for instructions for the 'best effort' priority. Check the
+answer for leafness, otherwise restart.
+.TP
+(iv)
+If none of the above returned with an instruction, enqueue at this node.
+.P
+This algorithm makes sure that a packet always ends up somewhere, even while
+you are busy building your configuration.
+
+For more details, see
+.BR tc-cbq-details(8).
+
+.SH LINK SHARING ALGORITHM
+When dequeuing for sending to the network device, CBQ decides which of its
+classes will be allowed to send. It does so with a Weighted Round Robin process
+in which each class with packets gets a chance to send in turn. The WRR process
+starts by asking the highest priority classes (lowest numerically -
+highest semantically) for packets, and will continue to do so until they
+have no more data to offer, in which case the process repeats for lower
+priorities.
+
+Classes by default borrow bandwidth from their siblings. A class can be
+prevented from doing so by declaring it 'bounded'. A class can also indicate
+its unwillingness to lend out bandwidth by being 'isolated'.
+
+.SH QDISC
+The root of a CBQ qdisc class tree has the following parameters:
+
+.TP
+parent major:minor | root
+This mandatory parameter determines the place of the CBQ instance, either at the
+.B root
+of an interface or within an existing class.
+.TP
+handle major:
+Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
+of a major number, followed by a colon. Optional, but very useful if classes
+will be generated within this qdisc.
+.TP
+allot bytes
+This allotment is the 'chunkiness' of link sharing and is used for determining packet
+transmission time tables. The qdisc allot differs slightly from the class allot discussed
+below. Optional. Defaults to a reasonable value, related to avpkt.
+.TP
+avpkt bytes
+The average size of a packet is needed for calculating maxidle, and is also used
+for making sure 'allot' has a safe value. Mandatory.
+.TP
+bandwidth rate
+To determine the idle time, CBQ must know the bandwidth of your underlying
+physical interface, or parent qdisc. This is a vital parameter, more about it
+later. Mandatory.
+.TP
+cell
+The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
+.TP
+mpu
+A zero sized packet may still take time to transmit. This value is the lower
+cap for packet transmission time calculations - packets smaller than this value
+are still deemed to have this size. Defaults to zero.
+.TP
+ewma log
+When CBQ needs to measure the average idle time, it does so using an
+Exponentially Weighted Moving Average which smoothes out measurements into
+a moving average. The EWMA LOG determines how much smoothing occurs. Lower
+values imply greater sensitivity. Must be between 0 and 31. Defaults
+to 5.
+.P
+A CBQ qdisc does not shape out of its own accord. It only needs to know certain
+parameters about the underlying link. Actual shaping is done in classes.
+
+.SH CLASSES
+Classes have a host of parameters to configure their operation.
+
+.TP
+parent major:minor
+Place of this class within the hierarchy. If attached directly to a qdisc
+and not to another class, minor can be omitted. Mandatory.
+.TP
+classid major:minor
+Like qdiscs, classes can be named. The major number must be equal to the
+major number of the qdisc to which it belongs. Optional, but needed if this
+class is going to have children.
+.TP
+weight weight
+When dequeuing to the interface, classes are tried for traffic in a
+round-robin fashion. Classes with a higher configured qdisc will generally
+have more traffic to offer during each round, so it makes sense to allow
+it to dequeue more traffic. All weights under a class are normalized, so
+only the ratios matter. Defaults to the configured rate, unless the priority
+of this class is maximal, in which case it is set to 1.
+.TP
+allot bytes
+Allot specifies how many bytes a qdisc can dequeue
+during each round of the process. This parameter is weighted using the
+renormalized class weight described above. Silently capped at a minimum of
+3/2 avpkt. Mandatory.
+
+.TP
+prio priority
+In the round-robin process, classes with the lowest priority field are tried
+for packets first. Mandatory.
+
+.TP
+avpkt
+See the QDISC section.
+
+.TP
+rate rate
+Maximum rate this class and all its children combined can send at. Mandatory.
+
+.TP
+bandwidth rate
+This is different from the bandwidth specified when creating a CBQ disc! Only
+used to determine maxidle and offtime, which are only calculated when
+specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
+
+.TP
+maxburst
+This number of packets is used to calculate maxidle so that when
+avgidle is at maxidle, this number of average packets can be burst
+before avgidle drops to 0. Set it higher to be more tolerant of
+bursts. You can't set maxidle directly, only via this parameter.
+
+.TP
+minburst
+As mentioned before, CBQ needs to throttle in case of
+overlimit. The ideal solution is to do so for exactly the calculated
+idle time, and pass 1 packet. However, Unix kernels generally have a
+hard time scheduling events shorter than 10ms, so it is better to
+throttle for a longer period, and then pass minburst packets in one
+go, and then sleep minburst times longer.
+
+The time to wait is called the offtime. Higher values of minburst lead
+to more accurate shaping in the long term, but to bigger bursts at
+millisecond timescales. Optional.
+
+.TP
+minidle
+If avgidle is below 0, we are overlimits and need to wait until
+avgidle will be big enough to send one packet. To prevent a sudden
+burst from shutting down the link for a prolonged period of time,
+avgidle is reset to minidle if it gets too low.
+
+Minidle is specified in negative microseconds, so 10 means that
+avgidle is capped at -10us. Optional.
+
+.TP
+bounded
+Signifies that this class will not borrow bandwidth from its siblings.
+.TP
+isolated
+Means that this class will not borrow bandwidth to its siblings
+
+.TP
+split major:minor & defmap bitmap[/bitmap]
+If consulting filters attached to a class did not give a verdict,
+CBQ can also classify based on the packet's priority. There are 16
+priorities available, numbered from 0 to 15.
+
+The defmap specifies which priorities this class wants to receive,
+specified as a bitmap. The Least Significant Bit corresponds to priority
+zero. The
+.B split
+parameter tells CBQ at which class the decision must be made, which should
+be a (grand)parent of the class you are adding.
+
+As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
+configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
+
+The complimentary configuration would then
+be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
+Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
+.TP
+estimator interval timeconstant
+CBQ can measure how much bandwidth each class is using, which tc filters
+can use to classify packets with. In order to determine the bandwidth
+it uses a very simple estimator that measures once every
+.B interval
+microseconds how much traffic has passed. This again is a EWMA, for which
+the time constant can be specified, also in microseconds. The
+.B time constant
+corresponds to the sluggishness of the measurement or, conversely, to the
+sensitivity of the average to short bursts. Higher values mean less
+sensitivity.
+
+.SH BUGS
+The actual bandwidth of the underlying link may not be known, for example
+in the case of PPoE or PPTP connections which in fact may send over a
+pipe, instead of over a physical device. CBQ is quite resilient to major
+errors in the configured bandwidth, probably a the cost of coarser shaping.
+
+Default kernels rely on coarse timing information for making decisions. These
+may make shaping precise in the long term, but inaccurate on second long scales.
+
+See
+.BR tc-cbq-details(8)
+for hints on how to improve this.
+
+.SH SOURCES
+.TP
+o
+Sally Floyd and Van Jacobson, "Link-sharing and Resource
+Management Models for Packet Networks",
+IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
+
+.TP
+o
+Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
+
+.TP
+o
+Sally Floyd, "Notes on Class-Based Queueing: Setting
+Parameters", 1996
+
+.TP
+o
+Sally Floyd and Michael Speer, "Experimental Results
+for Class-Based Queueing", 1998, not published.
+
+
+
+.SH SEE ALSO
+.BR tc (8)
+
+.SH AUTHOR
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
+bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-choke.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-choke.8
new file mode 100755
index 0000000..620c7f6
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-choke.8
@@ -0,0 +1,63 @@
+.TH TC 8 "August 2011" "iproute2" "Linux"
+.SH NAME
+choke \- choose and keep scheduler
+.SH SYNOPSIS
+.B tc qdisc ... choke
+.B limit
+packets
+.B min
+packets
+.B max
+packets
+.B avpkt
+bytes
+.B burst
+packets
+.B [ ecn ] [ bandwidth
+rate
+.B ] probability
+chance
+
+.SH DESCRIPTION
+
+CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for unresponsive flows)
+is a classless qdisc designed to both identify and penalize flows that monopolize the
+queue. CHOKe is a variation of RED, and the configuration is similar to RED.
+
+.SH ALGORITHM
+Once the queue hits a certain average length, a random packet is drawn from the
+queue. If both the to-be-queued and the drawn packet belong to the same flow,
+both packets are dropped. Otherwise, if the queue length is still below the maximum length,
+the new packet has a configurable chance of being marked (which may mean dropped).
+If the queue length exceeds
+.B max
+, the new packet will always be marked (or dropped).
+If the queue length exceeds
+.B limit
+, the new packet is always dropped.
+
+The marking probability computation is the same as used by the RED qdisc.
+
+.SH PARAMETERS
+The parameters are the same as for RED, except that RED uses bytes whereas choke
+counts packets. See
+.BR tc-red (8)
+for a description.
+
+.SH SOURCE
+.TP
+o
+R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
+Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
+IEEE INFOCOM, 2000.
+.TP
+o
+A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
+Characteristics", IEEE/ACM Transactions on Networking, 2004
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-red (8)
+
+.SH AUTHOR
+sched_choke was contributed by Stephen Hemminger.
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-drr.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-drr.8
new file mode 100755
index 0000000..16a8ec0
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-drr.8
@@ -0,0 +1,94 @@
+.TH TC 8 "January 2010" "iproute2" "Linux"
+.SH NAME
+drr \- deficit round robin scheduler
+.SH SYNOPSIS
+.B tc qdisc ... add drr
+.B [ quantum
+bytes
+.B ]
+
+.SH DESCRIPTION
+
+The Deficit Round Robin Scheduler is a classful queuing discipline as
+a more flexible replacement for Stochastic Fairness Queuing.
+
+Unlike SFQ, there are no built-in queues \-\- you need to add classes
+and then set up filters to classify packets accordingly.
+This can be useful e.g. for using RED qdiscs with different settings for particular
+traffic. There is no default class \-\- if a packet cannot be classified,
+it is dropped.
+
+.SH ALGORITHM
+Each class is assigned a deficit counter, initialized to
+.B quantum.
+
+DRR maintains an (internal) ''active'' list of classes whose qdiscs are
+non-empty. This list is used for dequeuing. A packet is dequeued from
+the class at the head of the list if the packet size is smaller or equal
+to the deficit counter. If the counter is too small, it is increased by
+.B quantum
+and the scheduler moves on to the next class in the active list.
+
+
+.SH PARAMETERS
+.TP
+quantum
+Amount of bytes a flow is allowed to dequeue before the scheduler moves to
+the next class. Defaults to the MTU of the interface. The minimum value is 1.
+
+.SH EXAMPLE & USAGE
+
+To attach to device eth0, using the interface MTU as its quantum:
+.P
+# tc qdisc add dev eth0 handle 1 root drr
+.P
+Adding two classes:
+.P
+# tc class add dev eth0 parent 1: classid 1:1 drr
+# tc class add dev eth0 parent 1: classid 1:2 drr
+.P
+You also need to add at least one filter to classify packets.
+.P
+# tc filter add dev eth0 protocol .. classid 1:1
+.P
+
+Like SFQ, DRR is only useful when it owns the queue \-\- it is a pure scheduler and does
+not delay packets. Attaching non-work-conserving qdiscs like tbf to it does not make
+sense \-\- other qdiscs in the active list will also become inactive until the dequeue
+operation succeeds. Embed DRR within another qdisc like HTB or HFSC to ensure it owns the queue.
+.P
+You can mimic SFQ behavior by assigning packets to the attached classes using the
+flow filter:
+
+.B tc qdisc add dev .. drr
+
+.B for i in .. 1024;do
+.br
+.B \ttc class add dev .. classid $handle:$(print %x $i)
+.br
+.B \ttc qdisc add dev .. fifo limit 16
+.br
+.B done
+
+.B tc filter add .. protocol ip .. $handle flow hash keys src,dst,proto,proto-src,proto-dst divisor 1024 perturb 10
+
+
+.SH SOURCE
+.TP
+o
+M. Shreedhar and George Varghese "Efficient Fair
+Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
+
+.SH NOTES
+
+This implementation does not drop packets from the longest queue on overrun,
+as limits are handled by the individual child qdiscs.
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-htb (8),
+.BR tc-sfq (8)
+
+.SH AUTHOR
+sched_drr was written by Patrick McHardy.
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-hfsc.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-hfsc.8
new file mode 100755
index 0000000..c5ff331
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-hfsc.8
@@ -0,0 +1,61 @@
+.TH HFSC 8 "31 October 2011" iproute2 Linux
+.
+.SH NAME
+HFSC \- Hierarchical Fair Service Curve's control under linux
+.
+.SH SYNOPSIS
+.nf
+tc qdisc add ... hfsc [ \fBdefault\fR CLASSID ]
+
+tc class add ... hfsc [ [ \fBrt\fR SC ] [ \fBls\fR SC ] | [ \fBsc\fR SC ] ] [ \fBul\fR SC ]
+
+\fBrt\fR : realtime service curve
+\fBls\fR : linkshare service curve
+\fBsc\fR : rt+ls service curve
+\fBul\fR : upperlimit service curve
+
+\(bu at least one of \fBrt\fR, \fBls\fR or \fBsc\fR must be specified
+\(bu \fBul\fR can only be specified with \fBls\fR or \fBsc\fR
+.
+.IP "SC := [ [ \fBm1\fR BPS ] \fBd\fR SEC ] \fBm2\fR BPS"
+\fBm1\fR : slope of the first segment
+\fBd\fR : x\-coordinate of intersection
+\fBm2\fR : slope of the second segment
+.PP
+.IP "SC := [ [ \fBumax\fR BYTE ] \fBdmax\fR SEC ] \fBrate\fR BPS"
+\fBumax\fR : maximum unit of work
+\fBdmax\fR : maximum delay
+\fBrate\fR : rate
+.PP
+.fi
+For description of BYTE, BPS and SEC \- please see \fBUNITS\fR
+section of \fBtc\fR(8).
+.
+.SH DESCRIPTION (qdisc)
+HFSC qdisc has only one optional parameter \- \fBdefault\fR. CLASSID specifies
+the minor part of the default classid, where packets not classified by other
+means (e.g. u32 filter, CLASSIFY target of iptables) will be enqueued. If
+\fBdefault\fR is not specified, unclassified packets will be dropped.
+.
+.SH DESCRIPTION (class)
+HFSC class is used to create a class hierarchy for HFSC scheduler. For
+explanation of the algorithm, and the meaning behind \fBrt\fR, \fBls\fR,
+\fBsc\fR and \fBul\fR service curves \- please refer to \fBtc\-hfsc\fR(7).
+
+As you can see in \fBSYNOPSIS\fR, service curve (SC) can be specified in two
+ways. Either as maximum delay for certain amount of work, or as a bandwidth
+assigned for certain amount of time. Obviously, \fBm1\fR is simply
+\fBumax\fR/\fBdmax\fR.
+
+Both \fBm2\fR and \fBrate\fR are mandatory. If you omit other
+parameters, you will specify linear service curve.
+.
+.SH "SEE ALSO"
+.
+\fBtc\fR(8), \fBtc\-hfsc\fR(7), \fBtc\-stab\fR(8)
+
+Please direct bugreports and patches to: <net...@vger.kernel.org>
+.
+.SH "AUTHOR"
+.
+Manpage created by Michal Soltys (sol...@ziu.info)
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-htb.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-htb.8
new file mode 100755
index 0000000..d196ecd
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-htb.8
@@ -0,0 +1,150 @@
+.TH HTB 8 "10 January 2002" "iproute2" "Linux"
+.SH NAME
+HTB \- Hierarchy Token Bucket
+.SH SYNOPSIS
+.B tc qdisc ... dev
+dev
+.B ( parent
+classid
+.B | root) [ handle
+major:
+.B ] htb [ default
+minor-id
+.B ]
+
+.B tc class ... dev
+dev
+.B parent
+major:[minor]
+.B [ classid
+major:minor
+.B ] htb rate
+rate
+.B [ ceil
+rate
+.B ] burst
+bytes
+.B [ cburst
+bytes
+.B ] [ prio
+priority
+.B ]
+
+.SH DESCRIPTION
+HTB is meant as a more understandable and intuitive replacement for
+the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
+of the outbound bandwidth on a given link. Both allow you to use one
+physical link to simulate several slower links and to send different
+kinds of traffic on different simulated links. In both cases, you have
+to specify how to divide the physical link into simulated links and
+how to decide which simulated link to use for a given packet to be sent.
+
+Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm
+which does not depend on interface characteristics and so does not need to
+know the underlying bandwidth of the outgoing interface.
+
+.SH SHAPING ALGORITHM
+Shaping works as documented in
+.B tc-tbf (8).
+
+.SH CLASSIFICATION
+Within the one HRB instance many classes may exist. Each of these classes
+contains another qdisc, by default
+.BR tc-pfifo (8).
+
+When enqueueing a packet, HTB starts at the root and uses various methods to
+determine which class should receive the data.
+
+In the absence of uncommon configuration options, the process is rather easy.
+At each node we look for an instruction, and then go to the class the
+instruction refers us to. If the class found is a barren leaf-node (without
+children), we enqueue the packet there. If it is not yet a leaf node, we do
+the whole thing over again starting from that node.
+
+The following actions are performed, in order at each node we visit, until one
+sends us to another node, or terminates the process.
+.TP
+(i)
+Consult filters attached to the class. If sent to a leafnode, we are done.
+Otherwise, restart.
+.TP
+(ii)
+If none of the above returned with an instruction, enqueue at this node.
+.P
+This algorithm makes sure that a packet always ends up somewhere, even while
+you are busy building your configuration.
+
+.SH LINK SHARING ALGORITHM
+FIXME
+
+.SH QDISC
+The root of a HTB qdisc class tree has the following parameters:
+
+.TP
+parent major:minor | root
+This mandatory parameter determines the place of the HTB instance, either at the
+.B root
+of an interface or within an existing class.
+.TP
+handle major:
+Like all other qdiscs, the HTB can be assigned a handle. Should consist only
+of a major number, followed by a colon. Optional, but very useful if classes
+will be generated within this qdisc.
+.TP
+default minor-id
+Unclassified traffic gets sent to the class with this minor-id.
+
+.SH CLASSES
+Classes have a host of parameters to configure their operation.
+
+.TP
+parent major:minor
+Place of this class within the hierarchy. If attached directly to a qdisc
+and not to another class, minor can be omitted. Mandatory.
+.TP
+classid major:minor
+Like qdiscs, classes can be named. The major number must be equal to the
+major number of the qdisc to which it belongs. Optional, but needed if this
+class is going to have children.
+.TP
+prio priority
+In the round-robin process, classes with the lowest priority field are tried
+for packets first. Mandatory.
+
+.TP
+rate rate
+Maximum rate this class and all its children are guaranteed. Mandatory.
+
+.TP
+ceil rate
+Maximum rate at which a class can send, if its parent has bandwidth to spare.
+Defaults to the configured rate, which implies no borrowing
+
+.TP
+burst bytes
+Amount of bytes that can be burst at
+.B ceil
+speed, in excess of the configured
+.B rate.
+Should be at least as high as the highest burst of all children.
+
+.TP
+cburst bytes
+Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
+as the interface can transmit them. For perfect evening out, should be equal to at most one average
+packet. Should be at least as high as the highest cburst of all children.
+
+.SH NOTES
+Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel,
+there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
+From this, the minimum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte
+burst as 100*12kb*8 equals 10mbit.
+
+.SH SEE ALSO
+.BR tc (8)
+.P
+HTB website: http://luxik.cdi.cz/~devik/qos/htb/
+.SH AUTHOR
+Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-netem.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-netem.8
new file mode 100755
index 0000000..39f8454
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-netem.8
@@ -0,0 +1,194 @@
+.TH NETEM 8 "25 November 2011" "iproute2" "Linux"
+.SH NAME
+NetEm \- Network Emulator
+.SH SYNOPSIS
+.B "tc qdisc ... dev"
+.IR DEVICE " ] "
+.BR "add netem"
+.I OPTIONS
+
+.IR OPTIONS " := [ " LIMIT " ] [ " DELAY " ] [ " LOSS \
+" ] [ " CORRUPT " ] [ " DUPLICATION " ] [ " REORDERING " ][ " RATE " ]"
+
+.IR LIMIT " := "
+.B limit
+.I packets
+
+.IR DELAY " := "
+.BI delay
+.IR TIME " [ " JITTER " [ " CORRELATION " ]]]"
+.br
+ [
+.BR distribution " { "uniform " | " normal " | " pareto " | " paretonormal " } ]"
+
+.IR LOSS " := "
+.BR loss " { "
+.BI random
+.IR PERCENT " [ " CORRELATION " ] |"
+.br
+.RB " " state
+.IR p13 " [ " p31 " [ " p32 " [ " p23 " [ " p14 "]]]] |"
+.br
+.RB " " gemodel
+.IR p " [ " r " [ " 1-h " [ " 1-k " ]]]"
+.BR " }"
+
+.IR CORRUPT " := "
+.B corrupt
+.IR PERCENT " [ " CORRELATION " ]]"
+
+.IR DUPLICATION " := "
+.B duplicate
+.IR PERCENT " [ " CORRELATION " ]]"
+
+.IR REORDERING " := "
+.B reorder
+.IR PERCENT " [ " CORRELATION " ] [ "
+.B gap
+.IR DISTANCE " ]"
+
+.IR RATE " := "
+.B rate
+.IR RATE " [ " PACKETOVERHEAD " [ " CELLSIZE " [ " CELLOVERHEAD " ]]]]"
+
+
+.SH DESCRIPTION
+NetEm is an enhancement of the Linux traffic control facilities
+that allow to add delay, packet loss, duplication and more other
+characteristics to packets outgoing from a selected network
+interface. NetEm is built using the existing Quality Of Service (QOS)
+and Differentiated Services (diffserv) facilities in the Linux
+kernel.
+
+.SH netem OPTIONS
+netem has the following options:
+
+.SS limit packets
+
+limits the effect of selected options to the indicated number of next packets.
+
+.SS delay
+adds the chosen delay to the packets outgoing to chosen network interface. The
+optional parameters allows to introduce a delay variation and a correlation.
+Delay and jitter values are expressed in ms while correlation is percentage.
+
+.SS distribution
+allow the user to choose the delay distribution. If not specified, the default
+distribution is Normal. Additional parameters allow to consider situations in
+which network has variable delays depending on traffic flows concurring on the
+same path, that causes several delay peaks and a tail.
+
+.SS loss random
+adds an independent loss probability to the packets outgoing from the chosen
+network interface. It is also possible to add a correlation, but this option
+is now deprecated due to the noticed bad behavior.
+
+.SS loss state
+adds packet losses according to the 4-state Markov using the transition
+probabilities as input parameters. The parameter p13 is mandatory and if used
+alone corresponds to the Bernoulli model. The optional parameters allows to
+extend the model to 2-state (p31), 3-state (p23 and p32) and 4-state (p14).
+State 1 corresponds to good reception, State 4 to independent losses, State 3
+to burst losses and State 2 to good reception within a burst.
+
+.SS loss gemodel
+adds packet losses according to the Gilbert-Elliot loss model or its special
+cases (Gilbert, Simple Gilbert and Bernoulli). To use the Bernoulli model, the
+only needed parameter is p while the others will be set to the default
+values r=1-p, 1-h=1 and 1-k=0. The parameters needed for the Simple Gilbert
+model are two (p and r), while three parameters (p, r, 1-h) are needed for the
+Gilbert model and four (p, r, 1-h and 1-k) are needed for the Gilbert-Elliot
+model. As known, p and r are the transition probabilities between the bad and
+the good states, 1-h is the loss probability in the bad state and 1-k is the
+loss probability in the good state.
+
+.SS corrupt
+allows the emulation of random noise introducing an error in a random position
+for a chosen percent of packets. It is also possible to add a correlation
+through the proper parameter.
+
+.SS duplicate
+using this option the chosen percent of packets is duplicated before queuing
+them. It is also possible to add a correlation through the proper parameter.
+
+.SS reorder
+to use reordering, a delay option must be specified. There are two ways to use
+this option (assuming 'delay 10ms' in the options list).
+
+.B "reorder "
+.I 25% 50%
+.B "gap"
+.I 5
+.br
+in this first example, the first 4 (gap - 1) packets are delayed by 10ms and
+subsequent packets are sent immediately with a probability of 0.25 (with
+correlation of 50% ) or delayed with a probability of 0.75. After a packet is
+reordered, the process restarts i.e. the next 4 packets are delayed and
+subsequent packets are sent immediately or delayed based on reordering
+probability. To cause a repeatable pattern where every 5th packet is reordered
+reliably, a reorder probability of 100% can be used.
+
+.B reorder
+.I 25% 50%
+.br
+in this second example 25% of packets are sent immediately (with correlation of
+50%) while the others are delayed by 10 ms.
+
+.SS rate
+delay packets based on packet size and is a replacement for
+.IR TBF .
+Rate can be
+specified in common units (e.g. 100kbit). Optional
+.I PACKETOVERHEAD
+(in bytes) specify an per packet overhead and can be negative. A positive value can be
+used to simulate additional link layer headers. A negative value can be used to
+artificial strip the Ethernet header (e.g. -14) and/or simulate a link layer
+header compression scheme. The third parameter - an unsigned value - specify
+the cellsize. Cellsize can be used to simulate link layer schemes. ATM for
+example has an payload cellsize of 48 bytes and 5 byte per cell header. If a
+packet is 50 byte then ATM must use two cells: 2 * 48 bytes payload including 2
+* 5 byte header, thus consume 106 byte on the wire. The last optional value
+.I CELLOVERHEAD
+can be used to specify per cell overhead - for our ATM example 5.
+.I CELLOVERHEAD
+can be negative, but use negative values with caution.
+
+Note that rate throttling is limited by several factors: the kernel clock
+granularity avoid a perfect shaping at a specific level. This will show up in
+an artificial packet compression (bursts). Another influence factor are network
+adapter buffers which can also add artificial delay.
+
+.SH LIMITATIONS
+The main known limitation of Netem are related to timer granularity, since
+Linux is not a real-time operating system.
+
+.SH EXAMPLES
+.PP
+tc qdisc add dev eth0 root netem rate 5kbit 20 100 5
+.RS 4
+delay all outgoing packets on device eth0 with a rate of 5kbit, a per packet
+overhead of 20 byte, a cellsize of 100 byte and a per celloverhead of 5 byte:
+.RE
+
+.SH SOURCES
+.IP " 1. " 4
+Hemminger S. , "Network Emulation with NetEm", Open Source Development Lab,
+April 2005
+(http://devresources.linux-foundation.org/shemminger/netem/LCA2005_paper.pdf)
+
+.IP " 2. " 4
+Netem page from Linux foundation, (http://www.linuxfoundation.org/en/Net:Netem)
+
+.IP " 3. " 4
+Salsano S., Ludovici F., Ordine A., "Definition of a general and intuitive loss
+model for packet networks and its implementation in the Netem module in the
+Linux kernel", available at http://netgroup.uniroma2.it/NetemCLG
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-tbf (8)
+
+.SH AUTHOR
+Netem was written by Stephen Hemminger at Linux foundation and is based on NISTnet.
+This manpage was created by Fabio Ludovici <fabio.ludovici at yahoo dot it> and
+Hagen Paul Pfeifer <hagen@jauu.net>
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-pfifo.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-pfifo.8
new file mode 100755
index 0000000..ed23850
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-pfifo.8
@@ -0,0 +1 @@
+.so man8/tc-bfifo.8
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-pfifo_fast.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-pfifo_fast.8
new file mode 100755
index 0000000..43ab166
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-pfifo_fast.8
@@ -0,0 +1,59 @@
+.TH PFIFO_FAST 8 "10 January 2002" "iproute2" "Linux"
+.SH NAME
+pfifo_fast \- three-band first in, first out queue
+
+.SH DESCRIPTION
+pfifo_fast is the default qdisc of each interface.
+
+Whenever an interface is created, the pfifo_fast qdisc is automatically used
+as a queue. If another qdisc is attached, it preempts the default
+pfifo_fast, which automatically returns to function when an existing qdisc
+is detached.
+
+In this sense this qdisc is magic, and unlike other qdiscs.
+
+.SH ALGORITHM
+The algorithm is very similar to that of the classful
+.BR tc-prio (8)
+qdisc.
+.B pfifo_fast
+is like three
+.BR tc-pfifo (8)
+queues side by side, where packets can be enqueued in any of the three bands
+based on their Type of Service bits or assigned priority.
+
+Not all three bands are dequeued simultaneously - as long as lower bands
+have traffic, higher bands are never dequeued. This can be used to
+prioritize interactive traffic or penalize 'lowest cost' traffic.
+
+Each band can be txqueuelen packets long, as configured with
+.BR ifconfig (8)
+or
+.BR ip (8).
+Additional packets coming in are not enqueued but are instead dropped.
+
+See
+.BR tc-prio (8)
+for complete details on how TOS bits are translated into bands.
+.SH PARAMETERS
+.TP
+txqueuelen
+The length of the three bands depends on the interface txqueuelen, as
+specified with
+.BR ifconfig (8)
+or
+.BR ip (8).
+
+.SH BUGS
+Does not maintain statistics and does not show up in tc qdisc ls. This is because
+it is the automatic default in the absence of a configured qdisc.
+
+.SH SEE ALSO
+.BR tc (8)
+
+.SH AUTHORS
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
+
+This manpage maintained by bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-prio.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-prio.8
new file mode 100755
index 0000000..1625fcc
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-prio.8
@@ -0,0 +1,187 @@
+.TH PRIO 8 "16 December 2001" "iproute2" "Linux"
+.SH NAME
+PRIO \- Priority qdisc
+.SH SYNOPSIS
+.B tc qdisc ... dev
+dev
+.B ( parent
+classid
+.B | root) [ handle
+major:
+.B ] prio [ bands
+bands
+.B ] [ priomap
+band,band,band...
+.B ] [ estimator
+interval timeconstant
+.B ]
+
+.SH DESCRIPTION
+The PRIO qdisc is a simple classful queueing discipline that contains
+an arbitrary number of classes of differing priority. The classes are
+dequeued in numerical descending order of priority. PRIO is a scheduler
+and never delays packets - it is a work-conserving qdisc, though the qdiscs
+contained in the classes may not be.
+
+Very useful for lowering latency when there is no need for slowing down
+traffic.
+
+.SH ALGORITHM
+On creation with 'tc qdisc add', a fixed number of bands is created. Each
+band is a class, although is not possible to add classes with 'tc qdisc
+add', the number of bands to be created must instead be specified on the
+command line attaching PRIO to its root.
+
+When dequeueing, band 0 is tried first and only if it did not deliver a
+packet does PRIO try band 1, and so onwards. Maximum reliability packets
+should therefore go to band 0, minimum delay to band 1 and the rest to band
+2.
+
+As the PRIO qdisc itself will have minor number 0, band 0 is actually
+major:1, band 1 is major:2, etc. For major, substitute the major number
+assigned to the qdisc on 'tc qdisc add' with the
+.B handle
+parameter.
+
+.SH CLASSIFICATION
+Three methods are available to PRIO to determine in which band a packet will
+be enqueued.
+.TP
+From userspace
+A process with sufficient privileges can encode the destination class
+directly with SO_PRIORITY, see
+.BR socket(7).
+.TP
+with a tc filter
+A tc filter attached to the root qdisc can point traffic directly to a class
+.TP
+with the priomap
+Based on the packet priority, which in turn is derived from the Type of
+Service assigned to the packet.
+.P
+Only the priomap is specific to this qdisc.
+.SH QDISC PARAMETERS
+.TP
+bands
+Number of bands. If changed from the default of 3,
+.B priomap
+must be updated as well.
+.TP
+priomap
+The priomap maps the priority of
+a packet to a class. The priority can either be set directly from userspace,
+or be derived from the Type of Service of the packet.
+
+Determines how packet priorities, as assigned by the kernel, map to
+bands. Mapping occurs based on the TOS octet of the packet, which looks like
+this:
+
+.nf
+0 1 2 3 4 5 6 7
++---+---+---+---+---+---+---+---+
+| | | |
+|PRECEDENCE | TOS |MBZ|
+| | | |
++---+---+---+---+---+---+---+---+
+.fi
+
+The four TOS bits (the 'TOS field') are defined as:
+
+.nf
+Binary Decimal Meaning
+-----------------------------------------
+1000 8 Minimize delay (md)
+0100 4 Maximize throughput (mt)
+0010 2 Maximize reliability (mr)
+0001 1 Minimize monetary cost (mmc)
+0000 0 Normal Service
+.fi
+
+As there is 1 bit to the right of these four bits, the actual value of the
+TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the
+value of the entire TOS field, not just the four bits. It is the value you
+see in the first column of this table:
+
+.nf
+TOS Bits Means Linux Priority Band
+------------------------------------------------------------
+0x0 0 Normal Service 0 Best Effort 1
+0x2 1 Minimize Monetary Cost 1 Filler 2
+0x4 2 Maximize Reliability 0 Best Effort 1
+0x6 3 mmc+mr 0 Best Effort 1
+0x8 4 Maximize Throughput 2 Bulk 2
+0xa 5 mmc+mt 2 Bulk 2
+0xc 6 mr+mt 2 Bulk 2
+0xe 7 mmc+mr+mt 2 Bulk 2
+0x10 8 Minimize Delay 6 Interactive 0
+0x12 9 mmc+md 6 Interactive 0
+0x14 10 mr+md 6 Interactive 0
+0x16 11 mmc+mr+md 6 Interactive 0
+0x18 12 mt+md 4 Int. Bulk 1
+0x1a 13 mmc+mt+md 4 Int. Bulk 1
+0x1c 14 mr+mt+md 4 Int. Bulk 1
+0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1
+.fi
+
+The second column contains the value of the relevant
+four TOS bits, followed by their translated meaning. For example, 15 stands
+for a packet wanting Minimal Monetary Cost, Maximum Reliability, Maximum
+Throughput AND Minimum Delay.
+
+The fourth column lists the way the Linux kernel interprets the TOS bits, by
+showing to which Priority they are mapped.
+
+The last column shows the result of the default priomap. On the command line,
+the default priomap looks like this:
+
+ 1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
+
+This means that priority 4, for example, gets mapped to band number 1.
+The priomap also allows you to list higher priorities (> 7) which do not
+correspond to TOS mappings, but which are set by other means.
+
+This table from RFC 1349 (read it for more details) explains how
+applications might very well set their TOS bits:
+
+.nf
+TELNET 1000 (minimize delay)
+FTP
+ Control 1000 (minimize delay)
+ Data 0100 (maximize throughput)
+
+TFTP 1000 (minimize delay)
+
+SMTP
+ Command phase 1000 (minimize delay)
+ DATA phase 0100 (maximize throughput)
+
+Domain Name Service
+ UDP Query 1000 (minimize delay)
+ TCP Query 0000
+ Zone Transfer 0100 (maximize throughput)
+
+NNTP 0001 (minimize monetary cost)
+
+ICMP
+ Errors 0000
+ Requests 0000 (mostly)
+ Responses <same as request> (mostly)
+.fi
+
+
+.SH CLASSES
+PRIO classes cannot be configured further - they are automatically created
+when the PRIO qdisc is attached. Each class however can contain yet a
+further qdisc.
+
+.SH BUGS
+Large amounts of traffic in the lower bands can cause starvation of higher
+bands. Can be prevented by attaching a shaper (for example,
+.BR tc-tbf(8)
+to these bands to make sure they cannot dominate the link.
+
+.SH AUTHORS
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, J Hadi Salim
+<hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-red.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-red.8
new file mode 100755
index 0000000..f410d15
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-red.8
@@ -0,0 +1,162 @@
+.TH RED 8 "13 December 2001" "iproute2" "Linux"
+.SH NAME
+red \- Random Early Detection
+.SH SYNOPSIS
+.B tc qdisc ... red
+.B limit
+bytes
+.B [ min
+bytes
+.B ] [ max
+bytes
+.B ] avpkt
+bytes
+.B [ burst
+packets
+.B ] [ ecn ] [ harddrop] [ bandwidth
+rate
+.B ] [ probability
+chance
+.B ] [ adaptive ]
+
+.SH DESCRIPTION
+Random Early Detection is a classless qdisc which manages its queue size
+smartly. Regular queues simply drop packets from the tail when they are
+full, which may not be the optimal behaviour. RED also performs tail drop,
+but does so in a more gradual way.
+
+Once the queue hits a certain average length, packets enqueued have a
+configurable chance of being marked (which may mean dropped). This chance
+increases linearly up to a point called the
+.B max
+average queue length, although the queue might get bigger.
+
+This has a host of benefits over simple taildrop, while not being processor
+intensive. It prevents synchronous retransmits after a burst in traffic,
+which cause further retransmits, etc.
+
+The goal is to have a small queue size, which is good for interactivity
+while not disturbing TCP/IP traffic with too many sudden drops after a burst
+of traffic.
+
+Depending on if ECN is configured, marking either means dropping or
+purely marking a packet as overlimit.
+.SH ALGORITHM
+The average queue size is used for determining the marking
+probability. This is calculated using an Exponential Weighted Moving
+Average, which can be more or less sensitive to bursts.
+
+When the average queue size is below
+.B min
+bytes, no packet will ever be marked. When it exceeds
+.B min,
+the probability of doing so climbs linearly up
+to
+.B probability,
+until the average queue size hits
+.B max
+bytes. Because
+.B probability
+is normally not set to 100%, the queue size might
+conceivably rise above
+.B max
+bytes, so the
+.B limit
+parameter is provided to set a hard maximum for the size of the queue.
+
+.SH PARAMETERS
+.TP
+min
+Average queue size at which marking becomes a possibility. Defaults to
+.B max
+/3
+
+.TP
+max
+At this average queue size, the marking probability is maximal. Should be at
+least twice
+.B min
+to prevent synchronous retransmits, higher for low
+.B min.
+Default to
+.B limit
+/4
+.TP
+probability
+Maximum probability for marking, specified as a floating point
+number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
+respectively). Default : 0.02
+.TP
+limit
+Hard limit on the real (not average) queue size in bytes. Further packets
+are dropped. Should be set higher than max+burst. It is advised to set this
+a few times higher than
+.B max.
+.TP
+burst
+Used for determining how fast the average queue size is influenced by the
+real queue size. Larger values make the calculation more sluggish, allowing
+longer bursts of traffic before marking starts. Real life experiments
+support the following guideline: (min+min+max)/(3*avpkt).
+.TP
+avpkt
+Specified in bytes. Used with burst to determine the time constant for
+average queue size calculations. 1000 is a good value.
+.TP
+bandwidth
+This rate is used for calculating the average queue size after some
+idle time. Should be set to the bandwidth of your interface. Does not mean
+that RED will shape for you! Optional. Default : 10Mbit
+.TP
+ecn
+As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion
+Notification allows RED to notify remote hosts that their rate exceeds the
+amount of bandwidth available. Non-ECN capable hosts can only be notified by
+dropping a packet. If this parameter is specified, packets which indicate
+that their hosts honor ECN will only be marked and not dropped, unless the
+queue size hits
+.B limit
+bytes. Recommended.
+.TP
+harddrop
+If average flow queue size is above
+.B max
+bytes, this parameter forces a drop instead of ecn marking.
+.TP
+adaptive
+(Added in linux-3.3) Sets RED in adaptive mode as described in http://icir.org/floyd/papers/adaptiveRed.pdf
+.nf
+Goal of Adaptive RED is to make 'probability' dynamic value between 1% and 50% to reach the target average queue :
+.B (max - min) / 2
+.fi
+
+.SH EXAMPLE
+
+.P
+# tc qdisc add dev eth0 parent 1:1 handle 10: red
+ limit 400000 min 30000 max 90000 avpkt 1000
+ burst 55 ecn adaptive bandwidth 10Mbit
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-choke (8)
+
+.SH SOURCES
+.TP
+o
+Floyd, S., and Jacobson, V., Random Early Detection gateways for
+Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html
+.TP
+o
+Some changes to the algorithm by Alexey N. Kuznetsov.
+.TP
+o
+Adaptive RED : http://icir.org/floyd/papers/adaptiveRed.pdf
+
+.SH AUTHORS
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, Alexey Makarenko
+<makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>,
+Eric Dumazet <eric.dumazet@gmail.com>.
+This manpage maintained by bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-sfb.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-sfb.8
new file mode 100755
index 0000000..e7634d2
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-sfb.8
@@ -0,0 +1,213 @@
+.TH SFB 8 "August 2011" "iproute2" "Linux"
+.SH NAME
+sfb \- Stochastic Fair Blue
+.SH SYNOPSIS
+.B tc qdisc ... blue
+.B rehash
+milliseconds
+.B db
+milliseconds
+.B limit
+packets
+.B max
+packets
+.B target
+packets
+.B increment
+float
+.B decrement
+float
+.B penalty_rate
+packets per second
+.B penalty_burst
+packets
+
+.SH DESCRIPTION
+Stochastic Fair Blue is a classless qdisc to manage congestion based on
+packet loss and link utilization history while trying to prevent
+non-responsive flows (i.e. flows that do not react to congestion marking
+or dropped packets) from impacting performance of responsive flows.
+Unlike RED, where the marking probability has to be configured, BLUE
+tries to determine the ideal marking probability automatically.
+
+.SH ALGORITHM
+
+The
+.B BLUE
+algorithm maintains a probability which is used to mark or drop packets
+that are to be queued. If the queue overflows, the mark/drop probability
+is increased. If the queue becomes empty, the probability is decreased. The
+.B Stochastic Fair Blue
+(SFB) algorithm is designed to protect TCP flows against non-responsive flows.
+
+This SFB implementation maintains 8 levels of 16 bins each for accounting.
+Each flow is mapped into a bin of each level using a per-level hash value.
+
+Every bin maintains a marking probability, which gets increased or decreased
+based on bin occupancy. If the number of packets exceeds the size of that
+bin, the marking probability is increased. If the number drops to zero, it
+is decreased.
+
+The marking probability is based on the minimum value of all bins a flow is
+mapped into, thus, when a flow does not respond to marking or gradual packet
+drops, the marking probability quickly reaches one.
+
+In this case, the flow is rate-limited to
+.B penalty_rate
+packets per second.
+
+.SH LIMITATIONS
+
+Due to SFBs nature, it is possible for responsive flows to share all of its bins
+with a non-responsive flow, causing the responsive flow to be misidentified as
+being non-responsive.
+
+The probability of a responsive flow to be misidentified is dependent on
+the number of non-responsive flows, M. It is (1 - (1 - (1 / 16.0)) ** M) **8,
+so for example with 10 non-responsive flows approximately 0.2% of responsive flows
+will be misidentified.
+
+To mitigate this, SFB performs performs periodic re-hashing to avoid
+misclassification for prolonged periods of time.
+
+The default hashing method will use source and destination ip addresses and port numbers
+if possible, and also supports tunneling protocols.
+Alternatively, an external classifier can be configured, too.
+
+.SH PARAMETERS
+.TP
+rehash
+Time interval in milliseconds when queue perturbation occurs to avoid erroneously
+detecting unrelated, responsive flows as being part of a non-responsive flow for
+prolonged periods of time.
+Defaults to 10 minutes.
+.TP
+db
+Double buffering warmup wait time, in milliseconds.
+To avoid destroying the probability history when rehashing is performed, this
+implementation maintains a second set of levels/bins as described in section
+4.4 of the SFB reference.
+While one set is used to manage the queue, a second set is warmed up:
+Whenever a flow is then determined to be non-responsive, the marking
+probabilities in the second set are updated. When the rehashing
+happens, these bins will be used to manage the queue and all non-responsive
+flows can be rate-limited immediately.
+This value determines how much time has to pass before the 2nd set
+will start to be warmed up.
+Defaults to one minute, should be lower than
+.B
+rehash.
+.TP
+limit
+Hard limit on the real (not average) total queue size in packets.
+Further packets are dropped. Defaults to the transmit queue length of the
+device the qdisc is attached to.
+.TP
+max
+Maximum length of a buckets queue, in packets, before packets start being
+dropped. Should be sightly larger than
+.B target
+, but should not be set to values exceeding 1.5 times that of
+.B target .
+Defaults to 25.
+.TP
+target
+The desired average bin length. If the bin queue length reaches this value,
+the marking probability is increased by
+.B increment.
+The default value depends on the
+.B max
+setting, with max set to 25
+.B target
+will default to 20.
+.TP
+increment
+A value used to increase the marking probability when the queue appears
+to be over-used. Must be between 0 and 1.0. Defaults to 0.00050.
+.TP
+decrement
+Value used to decrease the marking probability when the queue is found
+to be empty. Must be between 0 and 1.0.
+Defaults to 0.00005.
+.TP
+penalty_rate
+The maximum number of packets belonging to flows identified as being
+non-responsive that can be enqueued per second. Once this number has been
+reached, further packets of such non-responsive flows are dropped.
+Set this to a reasonable fraction of your uplink throughput; the
+default value of 10 packets is probably too small.
+.TP
+penalty_burst
+The number of packets a flow is permitted to exceed the penalty rate before packets
+start being dropped.
+Defaults to 20 packets.
+
+.SH STATISTICS
+
+This qdisc exposes additional statistics via 'tc -s qdisc' output.
+These are:
+.TP
+earlydrop
+The number of packets dropped before a per-flow queue was full.
+.TP
+ratedrop
+The number of packets dropped because of rate-limiting.
+If this value is high, there are many non-reactive flows being
+sent through sfb. In such cases, it might be better to
+embed sfb within a classful qdisc to better control such
+flows using a different, shaping qdisc.
+.TP
+bucketdrop
+The number of packets dropped because a per-flow queue was full.
+High bucketdrop may point to a high number of aggressive, short-lived
+flows.
+.TP
+queuedrop
+The number of packets dropped due to reaching limit. This should normally be 0.
+.TP
+marked
+The number of packets marked with ECN.
+.TP
+maxqlen
+The length of the current longest per-flow (virtual) queue.
+.TP
+maxprob
+The maximum per-flow drop probability. 1 means that some
+flows have been detected as non-reactive.
+
+.SH NOTES
+
+SFB automatically enables use of Explicit Congestion Notification (ECN).
+Also, this SFB implementation does not queue packets itself.
+Rather, packets are enqueued to the inner qdisc (defaults to pfifo).
+Because sfb maintains virtual queue states, the inner qdisc must not
+drop a packet previously queued.
+Furthermore, if a buckets queue has a very high marking rate,
+this implementation will start dropping packets instead of
+marking them, as such a situation points to either bad congestion, or an
+unresponsive flow.
+
+.SH EXAMPLE & USAGE
+
+To attach to interface $DEV, using default options:
+.P
+# tc qdisc add dev $DEV handle 1: root sfb
+
+Only use destination ip addresses for assigning packets to bins, perturbing
+hash results every 10 minutes:
+.P
+# tc filter add dev $DEV parent 1: handle 1 flow hash keys dst perturb 600
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-red (8),
+.BR tc-sfq (8)
+.SH SOURCES
+.TP
+o
+W. Feng, D. Kandlur, D. Saha, K. Shin, BLUE: A New Class of Active Queue Management Algorithms,
+U. Michigan CSE-TR-387-99, April 1999.
+
+.SH AUTHORS
+
+This SFB implementation was contributed by Juliusz Chroboczek and Eric Dumazet.
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-sfq.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-sfq.8
new file mode 100755
index 0000000..5a651ff
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-sfq.8
@@ -0,0 +1,224 @@
+.TH TC 8 "24 January 2012" "iproute2" "Linux"
+.SH NAME
+sfq \- Stochastic Fairness Queueing
+.SH SYNOPSIS
+.B tc qdisc ...
+.B [ divisor
+hashtablesize
+.B ] [ limit
+packets
+.B ] [ perturb
+seconds
+.B ] [ quantum
+bytes
+.B ] [ flows
+number
+.B ] [ depth
+number
+.B ] [ headdrop
+.B ] [ redflowlimit
+bytes
+.B ] [ min
+bytes
+.B ] [ max
+bytes
+.B ] [ avpkt
+bytes
+.B ] [ burst
+packets
+.B ] [ probability
+P
+.B ] [ ecn
+.B ] [ harddrop ]
+.SH DESCRIPTION
+
+Stochastic Fairness Queueing is a classless queueing discipline available for
+traffic control with the
+.BR tc (8)
+command.
+
+SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'.
+The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing
+any single flow from drowning out the rest.
+
+This may in fact have some effect in mitigating a Denial of Service attempt.
+
+SFQ is work-conserving and therefore always delivers a packet if it has one available.
+.SH ALGORITHM
+On enqueueing, each packet is assigned to a hash bucket, based on the packets hash value.
+This hash value is either obtained from an external flow classifier (use
+.B
+tc filter
+to set them), or a default internal classifier if no external classifier has been configured.
+
+When the internal classifier is used, sfq uses
+.TP
+(i)
+Source address
+.TP
+(ii)
+Destination address
+.TP
+(iii)
+Source and Destination port
+.P
+If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP.
+Packets with other protocols are hashed based on the 32bits representation of their
+destination and source. A flow corresponds mostly to a TCP/IP connection.
+
+Each of these buckets should represent a unique flow. Because multiple flows may
+get hashed to the same bucket, sfqs internal hashing algorithm may be perturbed at configurable
+intervals so that the unfairness lasts only for a short while. Perturbation may
+however cause some inadvertent packet reordering to occur. After linux-3.3, there is
+no packet reordering problem, but possible packet drops if rehashing hits one limit
+(number of flows or packets per flow)
+
+When dequeuing, each hashbucket with data is queried in a round robin fashion.
+
+Before linux-3.3, the compile time maximum length of the SFQ is 128 packets, which can be spread over
+at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed
+on the fullest bucket, thus maintaining fairness.
+
+After linux-3.3, maximum length of SFQ is 65535 packets, and divisor limit is 65536.
+In case of overflow, tail-drop is performed on the fullest bucket, unless headdrop was requested.
+
+.SH PARAMETERS
+.TP
+divisor
+Can be used to set a different hash table size, available from kernel 2.6.39 onwards.
+The specified divisor must be a power of two and cannot be larger than 65536.
+Default value: 1024.
+.TP
+limit
+Upper limit of the SFQ. Can be used to reduce the default length of 127 packets.
+After linux-3.3, it can be raised.
+.TP
+depth
+Limit of packets per flow (after linux-3.3). Default to 127 and can be lowered.
+.TP
+perturb
+Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that
+no perturbation occurs. Do not set too low for each perturbation may cause some packet
+reordering or losses. Advised value: 60
+This value has no effect when external flow classification is used.
+Its better to increase divisor value to lower risk of hash collisions.
+.TP
+quantum
+Amount of bytes a flow is allowed to dequeue during a round of the round robin process.
+Defaults to the MTU of the interface which is also the advised value and the minimum value.
+.TP
+flows
+After linux-3.3, it is possible to change the default limit of flows.
+Default value is 127
+.TP
+headdrop
+Default SFQ behavior is to perform tail-drop of packets from a flow.
+You can ask a headdrop instead, as this is known to provide a better feedback for TCP flows.
+.TP
+redflowlimit
+Configure the optional RED module on top of each SFQ flow.
+Random Early Detection principle is to perform packet marks or drops in a probabilistic way.
+(man tc-red for details about RED)
+.nf
+redflowlimit configures the hard limit on the real (not average) queue size per SFQ flow in bytes.
+.fi
+.TP
+min
+Average queue size at which marking becomes a possibility. Defaults to
+.B max
+/3
+.TP
+max
+At this average queue size, the marking probability is maximal. Defaults to
+.B redflowlimit
+/4
+.TP
+probability
+Maximum probability for marking, specified as a floating point number from 0.0 to 1.0. Default value is 0.02
+.TP
+avpkt
+Specified in bytes. Used with burst to determine the time constant for average queue size calculations. Default value is 1000
+.TP
+burst
+Used for determining how fast the average queue size is influenced by the real queue size.
+.nf
+Default value is :
+.B (2 * min + max) / (3 * avpkt)
+.fi
+.TP
+ecn
+RED can either 'mark' or 'drop'. Explicit Congestion
+Notification allows RED to notify remote hosts that their rate exceeds the
+amount of bandwidth available. Non-ECN capable hosts can only be notified by
+dropping a packet. If this parameter is specified, packets which indicate
+that their hosts honor ECN will only be marked and not dropped, unless the
+queue size hits
+.B depth
+packets.
+.TP
+harddrop
+If average flow queue size is above
+.B max
+bytes, this parameter forces a drop instead of ecn marking.
+.SH EXAMPLE & USAGE
+
+To attach to device ppp0:
+.P
+# tc qdisc add dev ppp0 root sfq
+.P
+Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful
+if it owns the queue.
+This is the case when the link speed equals the actually available bandwidth. This holds
+for regular phone modems, ISDN connections and direct non-switched ethernet links.
+.P
+Most often, cable modems and DSL devices do not fall into this category. The same holds
+for when connected to a switch and trying to send data to a congested segment also
+connected to the switch.
+.P
+In this case, the effective queue does not reside within Linux and is therefore not
+available for scheduling.
+.P
+Embed SFQ in a classful qdisc to make sure it owns the queue.
+
+It is possible to use external classifiers with sfq, for example to hash traffic based only
+on source/destination ip addresses:
+.P
+# tc filter add ... flow hash keys src,dst perturb 30 divisor 1024
+.P
+Note that the given divisor should match the one used by sfq. If you have
+changed the sfq default of 1024, use the same value for the flow hash filter, too.
+
+.P
+Example of sfq with optional RED mode :
+.P
+# tc qdisc add dev eth0 parent 1:1 handle 10: sfq limit 3000 flows 512 divisor 16384
+ redflowlimit 100000 min 8000 max 60000 probability 0.20 ecn headdrop
+
+.SH SOURCE
+.TP
+o
+Paul E. McKenney "Stochastic Fairness Queuing",
+IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.
+
+.TP
+o
+Paul E. McKenney "Stochastic Fairness Queuing",
+"Interworking: Research and Experience", v.2, 1991, p.113-131.
+
+.TP
+o
+See also:
+M. Shreedhar and George Varghese "Efficient Fair
+Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-red (8)
+
+.SH AUTHORS
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>,
+Eric Dumazet <eric.dumazet@gmail.com>.
+.P
+This manpage maintained by bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-stab.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-stab.8
new file mode 100755
index 0000000..522ea00
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-stab.8
@@ -0,0 +1,163 @@
+.TH STAB 8 "31 October 2011" iproute2 Linux
+.
+.SH NAME
+tc\-stab \- Generic size table manipulations
+.
+.SH SYNOPSIS
+.nf
+tc qdisc add ... stab \\
+.RS 4
+[ \fBmtu\fR BYTES ] [ \fBtsize\fR SLOTS ] \\
+[ \fBmpu\fR BYTES ] [ \fBoverhead\fR BYTES ] [ \fBlinklayer\fR TYPE ] ...
+.RE
+
+TYPE := adsl | atm | ethernet
+.fi
+
+For the description of BYTES \- please refer to the \fBUNITS\fR
+section of \fBtc\fR(8).
+
+.IP \fBmtu\fR 4
+.br
+maximum packet size we create size table for, assumed 2048 if not specified explicitly
+.IP \fBtsize\fR
+.br
+required table size, assumed 512 if not specified explicitly
+.IP \fBmpu\fR
+.br
+minimum packet size used in computations
+.IP \fBoverhead\fR
+.br
+per\-packet size overhead (can be negative) used in computations
+.IP \fBlinklayer\fR
+.br
+required linklayer adaptation.
+.PP
+.
+.SH DESCRIPTION
+.
+Size tables allow manipulation of packet size, as seen by whole scheduler
+framework (of course, the actual packet size remains the same). Adjusted packet
+size is calculated only once \- when a qdisc enqueues the packet. Initial root
+enqueue initializes it to the real packet's size.
+
+Each qdisc can use different size table, but the adjusted size is stored in
+area shared by whole qdisc hierarchy attached to the interface. The effect is,
+that if you have such setup, the last qdisc with a stab in a chain "wins". For
+example, consider HFSC with simple pfifo attached to one of its leaf classes.
+If that pfifo qdisc has stab defined, it will override lengths calculated
+during HFSC's enqueue, and in turn, whenever HFSC tries to dequeue a packet, it
+will use potentially invalid size in its calculations. Normal setups will
+usually include stab defined only on root qdisc, but further overriding gives
+extra flexibility for less usual setups.
+
+Initial size table is calculated by \fBtc\fR tool using \fBmtu\fR and
+\fBtsize\fR parameters. The algorithm sets each slot's size to the smallest
+power of 2 value, so the whole \fBmtu\fR is covered by the size table. Neither
+\fBtsize\fR, nor \fBmtu\fR have to be power of 2 value, so the size
+table will usually support more than is required by \fBmtu\fR.
+
+For example, with \fBmtu\fR\~=\~1500 and \fBtsize\fR\~=\~128, a table with 128
+slots will be created, where slot 0 will correspond to sizes 0\-16, slot 1 to
+17\~\-\~32, \&..., slot 127 to 2033\~\-\~2048. Sizes assigned to each slot
+depend on \fBlinklayer\fR parameter.
+
+Stab calculation is also safe for an unusual case, when a size assigned to a
+slot would be larger than 2^16\-1 (you will lose the accuracy though).
+
+During kernel part of packet size adjustment, \fBoverhead\fR will be added to
+original size, and then slot will be calculated. If the size would cause
+overflow, more than 1 slot will be used to get the final size. It of course
+will affect accuracy, but it's only a guard against unusual situations.
+
+Currently there're two methods of creating values stored in the size table \-
+ethernet and atm (adsl):
+
+.IP ethernet 4
+.br
+This is basically 1\-1 mapping, so following our example from above
+(disregarding \fBmpu\fR for a moment) slot 0 would have 8, slot 1 would have 16
+and so on, up to slot 127 with 2048. Note, that \fBmpu\fR\~>\~0 must be
+specified, and slots that would get less than specified by \fBmpu\fR, will get
+\fBmpu\fR instead. If you don't specify \fBmpu\fR, the size table will not be
+created at all (it wouldn't make any difference), although any \fBoverhead\fR
+value will be respected during calculations.
+.IP "atm, adsl"
+.br
+ATM linklayer consists of 53 byte cells, where each of them provides 48 bytes
+for payload. Also all the cells must be fully utilized, thus the last one is
+padded if/as necessary.
+
+When size table is calculated, adjusted size that fits properly into lowest
+amount of cells is assigned to a slot. For example, a 100 byte long packet
+requires three 48\-byte payloads, so the final size would require 3 ATM cells
+\- 159 bytes.
+
+For ATM size tables, 16\~bytes sized slots are perfectly enough. The default
+values of \fBmtu\fR and \fBtsize\fR create 4\~bytes sized slots.
+.PP
+.
+.SH "TYPICAL OVERHEADS"
+The following values are typical for different adsl scenarios (based on
+\fB[1]\fR and \fB[2]\fR):
+
+.nf
+LLC based:
+.RS 4
+PPPoA \- 14 (PPP \- 2, ATM \- 12)
+PPPoE \- 40+ (PPPoE \- 8, ATM \- 18, ethernet 14, possibly FCS \- 4+padding)
+Bridged \- 32 (ATM \- 18, ethernet 14, possibly FCS \- 4+padding)
+IPoA \- 16 (ATM \- 16)
+.RE
+
+VC Mux based:
+.RS 4
+PPPoA \- 10 (PPP \- 2, ATM \- 8)
+PPPoE \- 32+ (PPPoE \- 8, ATM \- 10, ethernet 14, possibly FCS \- 4+padding)
+Bridged \- 24+ (ATM \- 10, ethernet 14, possibly FCS \- 4+padding)
+IPoA \- 8 (ATM \- 8)
+.RE
+.fi
+\p There're few important things regarding the above overheads:
+.
+.IP \(bu 4
+IPoA in LLC case requires SNAP, instead of LLC\-NLPID (see rfc2684) \- this is
+the reason, why it actually takes more space than PPPoA.
+.IP \(bu
+In rare cases, FCS might be preserved on protocols that include ethernet frame
+(Bridged and PPPoE). In such situation, any ethernet specific padding
+guaranteeing 64 bytes long frame size has to be included as well (see rfc2684).
+In the other words, it also guarantees that any packet you send will take
+minimum 2 atm cells. You should set \fBmpu\fR accordingly for that.
+.IP \(bu
+When size table is consulted, and you're shaping traffic for the sake of
+another modem/router, ethernet header (without padding) will already be added
+to initial packet's length. You should compensate for that by subtracting 14
+from the above overheads in such case. If you're shaping directly on the router
+(for example, with speedtouch usb modem) using ppp daemon, you're using raw ip
+interface without underlying layer2, so nothing will be added.
+
+For more thorough explanations, please see \fB[1]\fR and \fB[2]\fR.
+.
+.SH "ETHERNET CARDS CONSIDERATIONS"
+.
+It's often forgotten, that modern network cards (even cheap ones on desktop
+motherboards) and/or their drivers often support different offloading
+mechanisms. In context of traffic shaping, 'tso' and 'gso' might cause
+undesirable effects, due to massive tcp segments being considered during
+traffic shaping (including stab calculations). For slow uplink interfaces,
+it's good to use \fBethtool\fR to turn off offloading features.
+.
+.SH "SEE ALSO"
+.
+\fBtc\fR(8), \fBtc\-hfsc\fR(7), \fBtc\-hfsc\fR(8),
+.br
+\fB[1]\fR http://ace\-host.stuart.id.au/russell/files/tc/tc\-atm/
+.br
+\fB[2]\fR http://www.faqs.org/rfcs/rfc2684.html
+
+Please direct bugreports and patches to: <net...@vger.kernel.org>
+.
+.SH "AUTHOR"
+.
+Manpage created by Michal Soltys (sol...@ziu.info)
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-tbf.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-tbf.8
new file mode 100755
index 0000000..3abb238
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc-tbf.8
@@ -0,0 +1,138 @@
+.TH TC 8 "13 December 2001" "iproute2" "Linux"
+.SH NAME
+tbf \- Token Bucket Filter
+.SH SYNOPSIS
+.B tc qdisc ... tbf rate
+rate
+.B burst
+bytes/cell
+.B ( latency
+ms
+.B | limit
+bytes
+.B ) [ mpu
+bytes
+.B [ peakrate
+rate
+.B mtu
+bytes/cell
+.B ] ]
+.P
+burst is also known as buffer and maxburst. mtu is also known as minburst.
+.SH DESCRIPTION
+
+The Token Bucket Filter is a classless queueing discipline available for
+traffic control with the
+.BR tc (8)
+command.
+
+TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle
+itself, although packets are available, to ensure that the configured rate is not exceeded.
+On all platforms except for Alpha,
+it is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness,
+sending out data exactly at the configured rates.
+
+Much higher rates are possible but at the cost of losing the minimal burstiness. In that
+case, data is on average dequeued at the configured rate but may be sent much faster at millisecond
+timescales. Because of further queues living in network adaptors, this is often not a problem.
+
+Kernels with a higher 'HZ' can achieve higher rates with perfect burstiness. On Alpha, HZ is ten
+times higher, leading to a 10mbit/s limit to perfection. These calculations hold for packets of on
+average 1000 bytes.
+
+.SH ALGORITHM
+As the name implies, traffic is filtered based on the expenditure of
+.B tokens.
+Tokens roughly correspond to bytes, with the additional constraint that each packet consumes
+some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies
+the link for some time.
+
+On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst
+in one go. Tokens arrive at a steady rate, until the bucket is full.
+
+If no tokens are available, packets are queued, up to a configured limit. The TBF now
+calculates the token deficit, and throttles until the first packet in the queue can be sent.
+
+If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured
+to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF
+with a very small bucket, so that it doesn't burst.
+
+To achieve perfection, the second bucket may contain only a single packet, which leads to
+the earlier mentioned 1mbit/s limit.
+
+This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends
+on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100
+packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.
+
+.SH PARAMETERS
+See
+.BR tc (8)
+for how to specify the units of these values.
+.TP
+limit or latency
+Limit is the number of bytes that can be queued waiting for tokens to become
+available. You can also specify this the other way around by setting the
+latency parameter, which specifies the maximum amount of time a packet can
+sit in the TBF. The latter calculation takes into account the size of the
+bucket, the rate and possibly the peakrate (if set). These two parameters
+are mutually exclusive.
+.TP
+burst
+Also known as buffer or maxburst.
+Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously.
+In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer
+if you want to reach your configured rate!
+
+If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
+The minimum buffer size can be calculated by dividing the rate by HZ.
+
+Token usage calculations are performed using a table which by default has a resolution of 8 packets.
+This resolution can be changed by specifying the
+.B cell
+size with the burst. For example, to specify a 6000 byte buffer with a 16
+byte cell size, set a burst of 6000/16. You will probably never have to set
+this. Must be an integral power of 2.
+.TP
+mpu
+A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit
+determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
+.TP
+rate
+The speed knob. See remarks above about limits! See
+.BR tc (8)
+for units.
+.PP
+Furthermore, if a peakrate is desired, the following parameters are available:
+
+.TP
+peakrate
+Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does
+not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
+
+.TP
+mtu/minburst
+Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
+If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
+allows around 3mbit/s of peakrate, given 1000 byte packets.
+
+Like the regular burstsize you can also specify a
+.B cell
+size.
+.SH EXAMPLE & USAGE
+
+To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s,
+a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes
+at most 70ms of latency, with perfect peakrate behaviour, issue:
+.P
+# tc qdisc add dev eth0 root tbf rate 0.5mbit \\
+ burst 5kb latency 70ms peakrate 1mbit \\
+ minburst 1540
+
+.SH SEE ALSO
+.BR tc (8)
+
+.SH AUTHOR
+Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
+bert hubert <ahu@ds9a.nl>
+
+
diff --git a/ap/app/iproute2/iproute2-3.4.0/man/man8/tc.8 b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc.8
new file mode 100755
index 0000000..fc8095e
--- /dev/null
+++ b/ap/app/iproute2/iproute2-3.4.0/man/man8/tc.8
@@ -0,0 +1,388 @@
+.TH TC 8 "16 December 2001" "iproute2" "Linux"
+.SH NAME
+tc \- show / manipulate traffic control settings
+.SH SYNOPSIS
+.B tc qdisc [ add | change | replace | link ] dev
+DEV
+.B
+[ parent
+qdisc-id
+.B | root ]
+.B [ handle
+qdisc-id ] qdisc
+[ qdisc specific parameters ]
+.P
+
+.B tc class [ add | change | replace ] dev
+DEV
+.B parent
+qdisc-id
+.B [ classid
+class-id ] qdisc
+[ qdisc specific parameters ]
+.P
+
+.B tc filter [ add | change | replace ] dev
+DEV
+.B [ parent
+qdisc-id
+.B | root ] protocol
+protocol
+.B prio
+priority filtertype
+[ filtertype specific parameters ]
+.B flowid
+flow-id
+
+.B tc
+.RI "[ " FORMAT " ]"
+.B qdisc show [ dev
+DEV
+.B ]
+.P
+.B tc
+.RI "[ " FORMAT " ]"
+.B class show dev
+DEV
+.P
+.B tc filter show dev
+DEV
+
+.ti -8
+.IR FORMAT " := {"
+\fB\-s\fR[\fItatistics\fR] |
+\fB\-d\fR[\fIetails\fR] |
+\fB\-r\fR[\fIaw\fR] |
+\fB\-p\fR[\fIretty\fR] |
+\fB\i\fR[\fIec\fR] }
+
+.SH DESCRIPTION
+.B Tc
+is used to configure Traffic Control in the Linux kernel. Traffic Control consists
+of the following:
+
+.TP
+SHAPING
+When traffic is shaped, its rate of transmission is under control. Shaping may
+be more than lowering the available bandwidth - it is also used to smooth out
+bursts in traffic for better network behaviour. Shaping occurs on egress.
+
+.TP
+SCHEDULING
+By scheduling the transmission of packets it is possible to improve interactivity
+for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
+is also called prioritizing, and happens only on egress.
+
+.TP
+POLICING
+Where shaping deals with transmission of traffic, policing pertains to traffic
+arriving. Policing thus occurs on ingress.
+
+.TP
+DROPPING
+Traffic exceeding a set bandwidth may also be dropped forthwith, both on
+ingress and on egress.
+
+.P
+Processing of traffic is controlled by three kinds of objects: qdiscs,
+classes and filters.
+
+.SH QDISCS
+.B qdisc
+is short for 'queueing discipline' and it is elementary to
+understanding traffic control. Whenever the kernel needs to send a
+packet to an interface, it is
+.B enqueued
+to the qdisc configured for that interface. Immediately afterwards, the kernel
+tries to get as many packets as possible from the qdisc, for giving them
+to the network adaptor driver.
+
+A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure
+First In, First Out queue. It does however store traffic when the network interface
+can't handle it momentarily.
+
+.SH CLASSES
+Some qdiscs can contain classes, which contain further qdiscs - traffic may
+then be enqueued in any of the inner qdiscs, which are within the
+.B classes.
+When the kernel tries to dequeue a packet from such a
+.B classful qdisc
+it can come from any of the classes. A qdisc may for example prioritize
+certain kinds of traffic by trying to dequeue from certain classes
+before others.
+
+.SH FILTERS
+A
+.B filter
+is used by a classful qdisc to determine in which class a packet will
+be enqueued. Whenever traffic arrives at a class with subclasses, it needs
+to be classified. Various methods may be employed to do so, one of these
+are the filters. All filters attached to the class are called, until one of
+them returns with a verdict. If no verdict was made, other criteria may be
+available. This differs per qdisc.
+
+It is important to notice that filters reside
+.B within
+qdiscs - they are not masters of what happens.
+
+.SH CLASSLESS QDISCS
+The classless qdiscs are:
+.TP
+[p|b]fifo
+Simplest usable qdisc, pure First In, First Out behaviour. Limited in
+packets or in bytes.
+.TP
+pfifo_fast
+Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
+queue which honors Type of Service flags, as well as the priority that may be
+assigned to a packet.
+.TP
+red
+Random Early Detection simulates physical congestion by randomly dropping
+packets when nearing configured bandwidth allocation. Well suited to very
+large bandwidth applications.
+.TP
+sfq
+Stochastic Fairness Queueing reorders queued traffic so each 'session'
+gets to send a packet in turn.
+.TP
+tbf
+The Token Bucket Filter is suited for slowing traffic down to a precisely
+configured rate. Scales well to large bandwidths.
+.SH CONFIGURING CLASSLESS QDISCS
+In the absence of classful qdiscs, classless qdiscs can only be attached at
+the root of a device. Full syntax:
+.P
+.B tc qdisc add dev
+DEV
+.B root
+QDISC QDISC-PARAMETERS
+
+To remove, issue
+.P
+.B tc qdisc del dev
+DEV
+.B root
+
+The
+.B pfifo_fast
+qdisc is the automatic default in the absence of a configured qdisc.
+
+.SH CLASSFUL QDISCS
+The classful qdiscs are:
+.TP
+CBQ
+Class Based Queueing implements a rich linksharing hierarchy of classes.
+It contains shaping elements as well as prioritizing capabilities. Shaping is
+performed using link idle time calculations based on average packet size and
+underlying link bandwidth. The latter may be ill-defined for some interfaces.
+.TP
+HTB
+The Hierarchy Token Bucket implements a rich linksharing hierarchy of
+classes with an emphasis on conforming to existing practices. HTB facilitates
+guaranteeing bandwidth to classes, while also allowing specification of upper
+limits to inter-class sharing. It contains shaping elements, based on TBF and
+can prioritize classes.
+.TP
+PRIO
+The PRIO qdisc is a non-shaping container for a configurable number of
+classes which are dequeued in order. This allows for easy prioritization
+of traffic, where lower classes are only able to send if higher ones have
+no packets available. To facilitate configuration, Type Of Service bits are
+honored by default.
+.SH THEORY OF OPERATION
+Classes form a tree, where each class has a single parent.
+A class may have multiple children. Some qdiscs allow for runtime addition
+of classes (CBQ, HTB) while others (PRIO) are created with a static number of
+children.
+
+Qdiscs which allow dynamic addition of classes can have zero or more
+subclasses to which traffic may be enqueued.
+
+Furthermore, each class contains a
+.B leaf qdisc
+which by default has
+.B pfifo
+behaviour though another qdisc can be attached in place. This qdisc may again
+contain classes, but each class can have only one leaf qdisc.
+
+When a packet enters a classful qdisc it can be
+.B classified
+to one of the classes within. Three criteria are available, although not all
+qdiscs will use all three:
+.TP
+tc filters
+If tc filters are attached to a class, they are consulted first
+for relevant instructions. Filters can match on all fields of a packet header,
+as well as on the firewall mark applied by ipchains or iptables.
+.TP
+Type of Service
+Some qdiscs have built in rules for classifying packets based on the TOS field.
+.TP
+skb->priority
+Userspace programs can encode a class-id in the 'skb->priority' field using
+the SO_PRIORITY option.
+.P
+Each node within the tree can have its own filters but higher level filters
+may also point directly to lower classes.
+
+If classification did not succeed, packets are enqueued to the leaf qdisc
+attached to that class. Check qdisc specific manpages for details, however.
+
+.SH NAMING
+All qdiscs, classes and filters have IDs, which can either be specified
+or be automatically assigned.
+
+IDs consist of a major number and a minor number, separated by a colon.
+
+.TP
+QDISCS
+A qdisc, which potentially can have children,
+gets assigned a major number, called a 'handle', leaving the minor
+number namespace available for classes. The handle is expressed as '10:'.
+It is customary to explicitly assign a handle to qdiscs expected to have
+children.
+
+.TP
+CLASSES
+Classes residing under a qdisc share their qdisc major number, but each have
+a separate minor number called a 'classid' that has no relation to their
+parent classes, only to their parent qdisc. The same naming custom as for
+qdiscs applies.
+
+.TP
+FILTERS
+Filters have a three part ID, which is only needed when using a hashed
+filter hierarchy.
+.SH UNITS
+All parameters accept a floating point number, possibly followed by a unit.
+.P
+Bandwidths or rates can be specified in:
+.TP
+kbps
+Kilobytes per second
+.TP
+mbps
+Megabytes per second
+.TP
+kbit
+Kilobits per second
+.TP
+mbit
+Megabits per second
+.TP
+bps or a bare number
+Bytes per second
+.P
+Amounts of data can be specified in:
+.TP
+kb or k
+Kilobytes
+.TP
+mb or m
+Megabytes
+.TP
+mbit
+Megabits
+.TP
+kbit
+Kilobits
+.TP
+b or a bare number
+Bytes.
+.P
+Lengths of time can be specified in:
+.TP
+s, sec or secs
+Whole seconds
+.TP
+ms, msec or msecs
+Milliseconds
+.TP
+us, usec, usecs or a bare number
+Microseconds.
+
+.SH TC COMMANDS
+The following commands are available for qdiscs, classes and filter:
+.TP
+add
+Add a qdisc, class or filter to a node. For all entities, a
+.B parent
+must be passed, either by passing its ID or by attaching directly to the root of a device.
+When creating a qdisc or a filter, it can be named with the
+.B handle
+parameter. A class is named with the
+.B classid
+parameter.
+
+.TP
+remove
+A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs
+are automatically deleted, as well as any filters attached to them.
+
+.TP
+change
+Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
+that the handle cannot be changed and neither can the parent. In other words,
+.B
+change
+cannot move a node.
+
+.TP
+replace
+Performs a nearly atomic remove/add on an existing node id. If the node does not exist yet
+it is created.
+
+.TP
+link
+Only available for qdiscs and performs a replace where the node
+must exist already.
+
+.SH FORMAT
+The show command has additional formatting options:
+
+.TP
+.BR "\-s" , " \-stats", " \-statistics"
+output more statistics about packet usage.
+
+.TP
+.BR "\-d", " \-details"
+output more detailed information about rates and cell sizes.
+
+.TP
+.BR "\-r", " \-raw"
+output raw hex values for handles.
+
+.TP
+.BR "\-p", " \-pretty"
+decode filter offset and mask values to equivalent filter commands based on TCP/IP.
+
+.TP
+.BR "\-iec"
+print rates in IEC units (ie. 1K = 1024).
+
+
+.SH HISTORY
+.B tc
+was written by Alexey N. Kuznetsov and added in Linux 2.2.
+.SH SEE ALSO
+.BR tc-cbq (8),
+.BR tc-choke (8),
+.BR tc-drr (8),
+.BR tc-htb (8),
+.BR tc-hfsc (8),
+.BR tc-hfsc (7),
+.BR tc-sfb (8),
+.BR tc-sfq (8),
+.BR tc-red (8),
+.BR tc-tbf (8),
+.BR tc-pfifo (8),
+.BR tc-bfifo (8),
+.BR tc-pfifo_fast (8),
+.BR tc-stab (8),
+.br
+.RB "User documentation at " http://lartc.org/ ", but please direct bugreports and patches to: " <netdev@vger.kernel.org>
+
+.SH AUTHOR
+Manpage maintained by bert hubert (ahu@ds9a.nl)
+