diff --git a/hardware/disk/dosfstools/actions.py b/hardware/disk/dosfstools/actions.py new file mode 100644 index 0000000000..437983c0ca --- /dev/null +++ b/hardware/disk/dosfstools/actions.py @@ -0,0 +1,14 @@ +#!/usr/bin/python +# -*- coding: utf-8 -*- +# +# Licensed under the GNU General Public License, version 3. +# See the file http://www.gnu.org/licenses/gpl.txt + +from pisi.actionsapi import get +from pisi.actionsapi import autotools + +def build(): + autotools.make("CFLAGS='%s -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-strict-aliasing'" % get.CFLAGS()) + +def install(): + autotools.rawInstall("DESTDIR=%s install-bin install-man PREFIX=%s SBINDIR=/sbin" % (get.installDIR(), get.defaultprefixDIR())) diff --git a/hardware/disk/dosfstools/pspec.xml b/hardware/disk/dosfstools/pspec.xml new file mode 100644 index 0000000000..c4c01eb659 --- /dev/null +++ b/hardware/disk/dosfstools/pspec.xml @@ -0,0 +1,64 @@ + + + + + dosfstools + http://www.daniel-baumann.ch/software/dosfstools/ + + PisiLinux Community + admins@pisilinux.org + + GPLv3 + app:console + Tools to create and check DOS and VFAT filesystems + The dosfstools package includes the DOS and VFAT filesystem utilities like mkdosfs, mkfs.msdos, mkfs.vfat, dosfsck, dosfslabel. You can create and check MS-DOS FAT filesystems on hard drives or on floppies + http://daniel-baumann.ch/files/software/dosfstools/dosfstools-3.0.26.tar.xz + + + + dosfstools + + /sbin + /usr/share/doc + /usr/share/man + + + + + + 2014-04-03 + 3.0.26 + Version bump. + Marcin Bojara + marcin@pisilinux.org + + + 2014-01-18 + 3.0.25 + Version bump + Richard de Bruin + richdb@pisilinux.org + + + 2013-10-21 + 3.0.23 + Version bump + Richard de Bruin + richdb@pisilinux.org + + + 2013-06-13 + 3.0.20 + Version bump + Marcin Bojara + marcin@pisilinux.org + + + 2012-11-13 + 3.0.13 + First release + PisiLinux Community + admins@pisilinux.org + + + diff --git a/hardware/disk/dosfstools/translations.xml b/hardware/disk/dosfstools/translations.xml new file mode 100644 index 0000000000..8a1fa346e2 --- /dev/null +++ b/hardware/disk/dosfstools/translations.xml @@ -0,0 +1,8 @@ + + + + dosfstools + Dosfstools paketi, mkdosfs, mkfs.msdos, mkfs.vfat, dosfsck, dosfslabel gibi, DOS ve VFAT dosyasistemleri yaratmaya ve kontrol etmeye yarayan araçları içerir. + DOS dosya sistemi oluşturmaya ve kontrol etmeye yarayan komutlar + + diff --git a/network/misc/iputils/actions.py b/network/misc/iputils/actions.py new file mode 100644 index 0000000000..661fe8eba7 --- /dev/null +++ b/network/misc/iputils/actions.py @@ -0,0 +1,28 @@ +#!/usr/bin/python +# -*- coding: utf-8 -*- +# +# Licensed under the GNU General Public License, version 3. +# See the file http://www.gnu.org/licenses/gpl.txt + +from pisi.actionsapi import shelltools +from pisi.actionsapi import autotools +from pisi.actionsapi import pisitools +from pisi.actionsapi import get + +def build(): + autotools.make("CCOPT='%s -fpie' CC=%s" % (get.CFLAGS(), get.CC())) + + autotools.compile("ifenslave.c -o ifenslave") + +def install(): + for app in ["ping", "ping6"]: + pisitools.dobin(app) + + for app in ["clockdiff", "arping", "rdisc", "tracepath", "tracepath6", "traceroute6", "ifenslave"]: + pisitools.dosbin(app) + + # We will not need these if we set cap on postInstall like Fedora + shelltools.chmod("%s/usr/bin/ping" % get.installDIR(), 04711) + shelltools.chmod("%s/usr/bin/ping6" % get.installDIR(), 04711) + + pisitools.dodoc("RELNOTES") diff --git a/network/misc/iputils/files/021109-uclibc-no-ether_ntohost.patch b/network/misc/iputils/files/021109-uclibc-no-ether_ntohost.patch new file mode 100644 index 0000000000..e790d2b510 --- /dev/null +++ b/network/misc/iputils/files/021109-uclibc-no-ether_ntohost.patch @@ -0,0 +1,24 @@ +--- iputils/rarpd.c.mps 2004-06-10 15:27:01.000000000 +0200 ++++ iputils/rarpd.c 2004-06-10 15:26:29.000000000 +0200 +@@ -42,7 +42,9 @@ int listen_arp; + char *ifname; + char *tftp_dir = "/etc/tftpboot"; + ++#ifndef __UCLIBC__ + extern int ether_ntohost(char *name, unsigned char *ea); ++#endif + void usage(void) __attribute__((noreturn)); + + struct iflink +@@ -305,7 +307,11 @@ struct rarp_map *rarp_lookup(int ifindex + 6, + }; + ++#ifndef __UCLIBC__ + if (ether_ntohost(ename, lladdr) != 0 || ++#else ++ if ( ++#endif + (hp = gethostbyname(ename)) == NULL) { + if (verbose) + syslog(LOG_INFO, "not found in /etc/ethers"); diff --git a/network/misc/iputils/files/docs.patch b/network/misc/iputils/files/docs.patch new file mode 100644 index 0000000000..c2e023ec1b --- /dev/null +++ b/network/misc/iputils/files/docs.patch @@ -0,0 +1,31 @@ +--- a/doc/Makefile 2007-11-27 02:57:27.000000000 +0200 ++++ b/doc/Makefile 2007-11-27 04:55:23.000000000 +0200 +@@ -13,25 +13,17 @@ + # So, scope it to a temporary dir and clean all after each run. + + $(HTMLFILES): index.db +- @-rm -rf tmp.db2html +- @mkdir tmp.db2html +- @set -e; cd tmp.db2html; docbook2html ../$< ; mv *.html .. +- @-rm -rf tmp.db2html ++ @docbook2html $< + + iputils.html: iputils.db +- @-rm -rf tmp.db2html +- @mkdir tmp.db2html +- @set -e; cd tmp.db2html; docbook2html -u -o html ../$< ; mv html/$@ .. +- @-rm -rf tmp.db2html ++ @docbook2html -u $< + + # docbook2man produces utterly ugly output and I did not find + # any way to customize this but hacking backend perl script a little. + # Well, hence... + + $(MANFILES): index.db +- @-mkdir tmp.db2man +- @set -e; cd tmp.db2man; nsgmls ../$< | sgmlspl ../docbook2man-spec.pl ; mv $@ .. +- @-rm -rf tmp.db2man ++ @nsgmls $< |sgmlspl docbook2man-spec.pl + + clean: + @rm -rf $(MANFILES) $(HTMLFILES) iputils.html tmp.db2html tmp.db2man diff --git a/network/misc/iputils/files/fedora/iputils-20020124-countermeasures.patch b/network/misc/iputils/files/fedora/iputils-20020124-countermeasures.patch new file mode 100644 index 0000000000..5e6f4bcde3 --- /dev/null +++ b/network/misc/iputils/files/fedora/iputils-20020124-countermeasures.patch @@ -0,0 +1,12 @@ +--- iputils/ping_common.c.countermeasures Tue May 21 10:06:05 2002 ++++ iputils/ping_common.c Tue May 21 10:12:42 2002 +@@ -628,7 +628,8 @@ + tvsub(tv, &tmp_tv); + triptime = tv->tv_sec * 1000000 + tv->tv_usec; + if (triptime < 0) { +- fprintf(stderr, "Warning: time of day goes back (%ldus), taking countermeasures.\n", triptime); ++ if (options & F_VERBOSE) ++ fprintf(stderr, "Warning: time of day goes back (%ldus), taking countermeasures.\n", triptime); + triptime = 0; + if (!(options & F_LATENCY)) { + gettimeofday(tv, NULL); diff --git a/network/misc/iputils/files/fedora/iputils-20020927-ping-subint.patch b/network/misc/iputils/files/fedora/iputils-20020927-ping-subint.patch new file mode 100644 index 0000000000..e19e724ffa --- /dev/null +++ b/network/misc/iputils/files/fedora/iputils-20020927-ping-subint.patch @@ -0,0 +1,12 @@ +--- iputils-ss021109-vanilla/ping.c Thu Nov 7 23:53:21 2002 ++++ iputils/ping.c Sun Jan 12 03:39:24 2003 +@@ -285,6 +285,9 @@ + perror("ping: IP_MULTICAST_IF"); + exit(2); + } ++ } else if (icmp_sock >= 0) { ++ /* We possible tried to SO_BINDTODEVICE() a subinterface like 'eth0:1' */ ++ perror("Warning: cannot bind to specified iface, falling back"); + } + } + } diff --git a/network/misc/iputils/files/fedora/iputils-20070202-traffic_class.patch b/network/misc/iputils/files/fedora/iputils-20070202-traffic_class.patch new file mode 100644 index 0000000000..8a4ddf0f42 --- /dev/null +++ b/network/misc/iputils/files/fedora/iputils-20070202-traffic_class.patch @@ -0,0 +1,14 @@ +diff -up iputils-s20070202/ping6.c.flowlabel iputils-s20070202/ping6.c +--- iputils-s20070202/ping6.c.flowlabel 2008-02-01 11:10:53.000000000 +0100 ++++ iputils-s20070202/ping6.c 2008-02-01 11:16:47.000000000 +0100 +@@ -86,6 +86,10 @@ char copyright[] = + #define SOL_ICMPV6 IPPROTO_ICMPV6 + #endif + ++#ifndef IVP6_FLOWINFO_SEND ++#define IPV6_FLOWINFO_SEND 33 ++#endif ++ + /* RFC3542 */ + #ifndef ICMP6_DST_UNREACH_BEYONDSCOPE + #define ICMP6_DST_UNREACH_BEYONDSCOPE ICMP6_DST_UNREACH_NOTNEIGHBOR diff --git a/network/misc/iputils/files/fedora/iputils-20100418-convtoint.patch b/network/misc/iputils/files/fedora/iputils-20100418-convtoint.patch new file mode 100644 index 0000000000..77c2256c50 --- /dev/null +++ b/network/misc/iputils/files/fedora/iputils-20100418-convtoint.patch @@ -0,0 +1,24 @@ +diff -up iputils-s20100418/tracepath6.c.convtoint iputils-s20100418/tracepath6.c +--- iputils-s20100418/tracepath6.c.convtoint 2010-04-23 11:28:15.294593391 +0200 ++++ iputils-s20100418/tracepath6.c 2010-04-23 11:28:23.544605551 +0200 +@@ -89,7 +89,7 @@ void print_host(const char *a, const cha + } + if (plen >= HOST_COLUMN_SIZE) + plen = HOST_COLUMN_SIZE - 1; +- printf("%*s", HOST_COLUMN_SIZE - plen, ""); ++ printf("%*s", HOST_COLUMN_SIZE - (int)plen, ""); + } + + int recverr(int fd, int ttl) +diff -up iputils-s20100418/tracepath.c.convtoint iputils-s20100418/tracepath.c +--- iputils-s20100418/tracepath.c.convtoint 2010-04-23 11:26:20.273555629 +0200 ++++ iputils-s20100418/tracepath.c 2010-04-23 11:26:20.281562493 +0200 +@@ -77,7 +77,7 @@ void print_host(const char *a, const cha + } + if (plen >= HOST_COLUMN_SIZE) + plen = HOST_COLUMN_SIZE - 1; +- printf("%*s", HOST_COLUMN_SIZE - plen, ""); ++ printf("%*s", HOST_COLUMN_SIZE - (int)plen, ""); + } + + int recverr(int fd, int ttl) diff --git a/network/misc/iputils/files/fedora/rdisc.service b/network/misc/iputils/files/fedora/rdisc.service new file mode 100644 index 0000000000..70a3d3aae2 --- /dev/null +++ b/network/misc/iputils/files/fedora/rdisc.service @@ -0,0 +1,11 @@ +[Unit] +Description=rdisc daemon which discovers routers on the local subnet +After=syslog.target network.target + +[Service] +Type=forking +EnvironmentFile=/etc/conf.d/rdisc +ExecStart=/sbin/rdisc $RDISCOPTS + +[Install] +WantedBy=multi-user.target diff --git a/network/misc/iputils/files/fedora/rdisc.sysconfig b/network/misc/iputils/files/fedora/rdisc.sysconfig new file mode 100644 index 0000000000..bd11c2ad09 --- /dev/null +++ b/network/misc/iputils/files/fedora/rdisc.sysconfig @@ -0,0 +1 @@ +RDISCOPTS="-s" diff --git a/network/misc/iputils/files/ifenslave/README.bonding b/network/misc/iputils/files/ifenslave/README.bonding new file mode 100644 index 0000000000..61f516b135 --- /dev/null +++ b/network/misc/iputils/files/ifenslave/README.bonding @@ -0,0 +1,2440 @@ + + Linux Ethernet Bonding Driver HOWTO + + Latest update: 23 September 2009 + +Initial release : Thomas Davis +Corrections, HA extensions : 2000/10/03-15 : + - Willy Tarreau + - Constantine Gavrilov + - Chad N. Tindel + - Janice Girouard + - Jay Vosburgh + +Reorganized and updated Feb 2005 by Jay Vosburgh +Added Sysfs information: 2006/04/24 + - Mitch Williams + +Introduction +============ + + The Linux bonding driver provides a method for aggregating +multiple network interfaces into a single logical "bonded" interface. +The behavior of the bonded interfaces depends upon the mode; generally +speaking, modes provide either hot standby or load balancing services. +Additionally, link integrity monitoring may be performed. + + The bonding driver originally came from Donald Becker's +beowulf patches for kernel 2.0. It has changed quite a bit since, and +the original tools from extreme-linux and beowulf sites will not work +with this version of the driver. + + For new versions of the driver, updated userspace tools, and +who to ask for help, please follow the links at the end of this file. + +Table of Contents +================= + +1. Bonding Driver Installation + +2. Bonding Driver Options + +3. Configuring Bonding Devices +3.1 Configuration with Sysconfig Support +3.1.1 Using DHCP with Sysconfig +3.1.2 Configuring Multiple Bonds with Sysconfig +3.2 Configuration with Initscripts Support +3.2.1 Using DHCP with Initscripts +3.2.2 Configuring Multiple Bonds with Initscripts +3.3 Configuring Bonding Manually with Ifenslave +3.3.1 Configuring Multiple Bonds Manually +3.4 Configuring Bonding Manually via Sysfs + +4. Querying Bonding Configuration +4.1 Bonding Configuration +4.2 Network Configuration + +5. Switch Configuration + +6. 802.1q VLAN Support + +7. Link Monitoring +7.1 ARP Monitor Operation +7.2 Configuring Multiple ARP Targets +7.3 MII Monitor Operation + +8. Potential Trouble Sources +8.1 Adventures in Routing +8.2 Ethernet Device Renaming +8.3 Painfully Slow Or No Failed Link Detection By Miimon + +9. SNMP agents + +10. Promiscuous mode + +11. Configuring Bonding for High Availability +11.1 High Availability in a Single Switch Topology +11.2 High Availability in a Multiple Switch Topology +11.2.1 HA Bonding Mode Selection for Multiple Switch Topology +11.2.2 HA Link Monitoring for Multiple Switch Topology + +12. Configuring Bonding for Maximum Throughput +12.1 Maximum Throughput in a Single Switch Topology +12.1.1 MT Bonding Mode Selection for Single Switch Topology +12.1.2 MT Link Monitoring for Single Switch Topology +12.2 Maximum Throughput in a Multiple Switch Topology +12.2.1 MT Bonding Mode Selection for Multiple Switch Topology +12.2.2 MT Link Monitoring for Multiple Switch Topology + +13. Switch Behavior Issues +13.1 Link Establishment and Failover Delays +13.2 Duplicated Incoming Packets + +14. Hardware Specific Considerations +14.1 IBM BladeCenter + +15. Frequently Asked Questions + +16. Resources and Links + + +1. Bonding Driver Installation +============================== + + Most popular distro kernels ship with the bonding driver +already available as a module and the ifenslave user level control +program installed and ready for use. If your distro does not, or you +have need to compile bonding from source (e.g., configuring and +installing a mainline kernel from kernel.org), you'll need to perform +the following steps: + +1.1 Configure and build the kernel with bonding +----------------------------------------------- + + The current version of the bonding driver is available in the +drivers/net/bonding subdirectory of the most recent kernel source +(which is available on http://kernel.org). Most users "rolling their +own" will want to use the most recent kernel from kernel.org. + + Configure kernel with "make menuconfig" (or "make xconfig" or +"make config"), then select "Bonding driver support" in the "Network +device support" section. It is recommended that you configure the +driver as module since it is currently the only way to pass parameters +to the driver or configure more than one bonding device. + + Build and install the new kernel and modules, then continue +below to install ifenslave. + +1.2 Install ifenslave Control Utility +------------------------------------- + + The ifenslave user level control program is included in the +kernel source tree, in the file Documentation/networking/ifenslave.c. +It is generally recommended that you use the ifenslave that +corresponds to the kernel that you are using (either from the same +source tree or supplied with the distro), however, ifenslave +executables from older kernels should function (but features newer +than the ifenslave release are not supported). Running an ifenslave +that is newer than the kernel is not supported, and may or may not +work. + + To install ifenslave, do the following: + +# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave +# cp ifenslave /sbin/ifenslave + + If your kernel source is not in "/usr/src/linux," then replace +"/usr/src/linux/include" in the above with the location of your kernel +source include directory. + + You may wish to back up any existing /sbin/ifenslave, or, for +testing or informal use, tag the ifenslave to the kernel version +(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10). + +IMPORTANT NOTE: + + If you omit the "-I" or specify an incorrect directory, you +may end up with an ifenslave that is incompatible with the kernel +you're trying to build it for. Some distros (e.g., Red Hat from 7.1 +onwards) do not have /usr/include/linux symbolically linked to the +default kernel source include directory. + +SECOND IMPORTANT NOTE: + If you plan to configure bonding using sysfs, you do not need +to use ifenslave. + +2. Bonding Driver Options +========================= + + Options for the bonding driver are supplied as parameters to the +bonding module at load time, or are specified via sysfs. + + Module options may be given as command line arguments to the +insmod or modprobe command, but are usually specified in either the +/etc/modules.conf or /etc/modprobe.conf configuration file, or in a +distro-specific configuration file (some of which are detailed in the next +section). + + Details on bonding support for sysfs is provided in the +"Configuring Bonding Manually via Sysfs" section, below. + + The available bonding driver parameters are listed below. If a +parameter is not specified the default value is used. When initially +configuring a bond, it is recommended "tail -f /var/log/messages" be +run in a separate window to watch for bonding driver error messages. + + It is critical that either the miimon or arp_interval and +arp_ip_target parameters be specified, otherwise serious network +degradation will occur during link failures. Very few devices do not +support at least miimon, so there is really no reason not to use it. + + Options with textual values will accept either the text name +or, for backwards compatibility, the option value. E.g., +"mode=802.3ad" and "mode=4" set the same mode. + + The parameters are as follows: + +ad_select + + Specifies the 802.3ad aggregation selection logic to use. The + possible values and their effects are: + + stable or 0 + + The active aggregator is chosen by largest aggregate + bandwidth. + + Reselection of the active aggregator occurs only when all + slaves of the active aggregator are down or the active + aggregator has no slaves. + + This is the default value. + + bandwidth or 1 + + The active aggregator is chosen by largest aggregate + bandwidth. Reselection occurs if: + + - A slave is added to or removed from the bond + + - Any slave's link state changes + + - Any slave's 802.3ad association state changes + + - The bond's administrative state changes to up + + count or 2 + + The active aggregator is chosen by the largest number of + ports (slaves). Reselection occurs as described under the + "bandwidth" setting, above. + + The bandwidth and count selection policies permit failover of + 802.3ad aggregations when partial failure of the active aggregator + occurs. This keeps the aggregator with the highest availability + (either in bandwidth or in number of ports) active at all times. + + This option was added in bonding version 3.4.0. + +arp_interval + + Specifies the ARP link monitoring frequency in milliseconds. + + The ARP monitor works by periodically checking the slave + devices to determine whether they have sent or received + traffic recently (the precise criteria depends upon the + bonding mode, and the state of the slave). Regular traffic is + generated via ARP probes issued for the addresses specified by + the arp_ip_target option. + + This behavior can be modified by the arp_validate option, + below. + + If ARP monitoring is used in an etherchannel compatible mode + (modes 0 and 2), the switch should be configured in a mode + that evenly distributes packets across all links. If the + switch is configured to distribute the packets in an XOR + fashion, all replies from the ARP targets will be received on + the same link which could cause the other team members to + fail. ARP monitoring should not be used in conjunction with + miimon. A value of 0 disables ARP monitoring. The default + value is 0. + +arp_ip_target + + Specifies the IP addresses to use as ARP monitoring peers when + arp_interval is > 0. These are the targets of the ARP request + sent to determine the health of the link to the targets. + Specify these values in ddd.ddd.ddd.ddd format. Multiple IP + addresses must be separated by a comma. At least one IP + address must be given for ARP monitoring to function. The + maximum number of targets that can be specified is 16. The + default value is no IP addresses. + +arp_validate + + Specifies whether or not ARP probes and replies should be + validated in the active-backup mode. This causes the ARP + monitor to examine the incoming ARP requests and replies, and + only consider a slave to be up if it is receiving the + appropriate ARP traffic. + + Possible values are: + + none or 0 + + No validation is performed. This is the default. + + active or 1 + + Validation is performed only for the active slave. + + backup or 2 + + Validation is performed only for backup slaves. + + all or 3 + + Validation is performed for all slaves. + + For the active slave, the validation checks ARP replies to + confirm that they were generated by an arp_ip_target. Since + backup slaves do not typically receive these replies, the + validation performed for backup slaves is on the ARP request + sent out via the active slave. It is possible that some + switch or network configurations may result in situations + wherein the backup slaves do not receive the ARP requests; in + such a situation, validation of backup slaves must be + disabled. + + This option is useful in network configurations in which + multiple bonding hosts are concurrently issuing ARPs to one or + more targets beyond a common switch. Should the link between + the switch and target fail (but not the switch itself), the + probe traffic generated by the multiple bonding instances will + fool the standard ARP monitor into considering the links as + still up. Use of the arp_validate option can resolve this, as + the ARP monitor will only consider ARP requests and replies + associated with its own instance of bonding. + + This option was added in bonding version 3.1.0. + +downdelay + + Specifies the time, in milliseconds, to wait before disabling + a slave after a link failure has been detected. This option + is only valid for the miimon link monitor. The downdelay + value should be a multiple of the miimon value; if not, it + will be rounded down to the nearest multiple. The default + value is 0. + +fail_over_mac + + Specifies whether active-backup mode should set all slaves to + the same MAC address at enslavement (the traditional + behavior), or, when enabled, perform special handling of the + bond's MAC address in accordance with the selected policy. + + Possible values are: + + none or 0 + + This setting disables fail_over_mac, and causes + bonding to set all slaves of an active-backup bond to + the same MAC address at enslavement time. This is the + default. + + active or 1 + + The "active" fail_over_mac policy indicates that the + MAC address of the bond should always be the MAC + address of the currently active slave. The MAC + address of the slaves is not changed; instead, the MAC + address of the bond changes during a failover. + + This policy is useful for devices that cannot ever + alter their MAC address, or for devices that refuse + incoming broadcasts with their own source MAC (which + interferes with the ARP monitor). + + The down side of this policy is that every device on + the network must be updated via gratuitous ARP, + vs. just updating a switch or set of switches (which + often takes place for any traffic, not just ARP + traffic, if the switch snoops incoming traffic to + update its tables) for the traditional method. If the + gratuitous ARP is lost, communication may be + disrupted. + + When this policy is used in conjuction with the mii + monitor, devices which assert link up prior to being + able to actually transmit and receive are particularly + susceptible to loss of the gratuitous ARP, and an + appropriate updelay setting may be required. + + follow or 2 + + The "follow" fail_over_mac policy causes the MAC + address of the bond to be selected normally (normally + the MAC address of the first slave added to the bond). + However, the second and subsequent slaves are not set + to this MAC address while they are in a backup role; a + slave is programmed with the bond's MAC address at + failover time (and the formerly active slave receives + the newly active slave's MAC address). + + This policy is useful for multiport devices that + either become confused or incur a performance penalty + when multiple ports are programmed with the same MAC + address. + + + The default policy is none, unless the first slave cannot + change its MAC address, in which case the active policy is + selected by default. + + This option may be modified via sysfs only when no slaves are + present in the bond. + + This option was added in bonding version 3.2.0. The "follow" + policy was added in bonding version 3.3.0. + +lacp_rate + + Option specifying the rate in which we'll ask our link partner + to transmit LACPDU packets in 802.3ad mode. Possible values + are: + + slow or 0 + Request partner to transmit LACPDUs every 30 seconds + + fast or 1 + Request partner to transmit LACPDUs every 1 second + + The default is slow. + +max_bonds + + Specifies the number of bonding devices to create for this + instance of the bonding driver. E.g., if max_bonds is 3, and + the bonding driver is not already loaded, then bond0, bond1 + and bond2 will be created. The default value is 1. Specifying + a value of 0 will load bonding, but will not create any devices. + +miimon + + Specifies the MII link monitoring frequency in milliseconds. + This determines how often the link state of each slave is + inspected for link failures. A value of zero disables MII + link monitoring. A value of 100 is a good starting point. + The use_carrier option, below, affects how the link state is + determined. See the High Availability section for additional + information. The default value is 0. + +mode + + Specifies one of the bonding policies. The default is + balance-rr (round robin). Possible values are: + + balance-rr or 0 + + Round-robin policy: Transmit packets in sequential + order from the first available slave through the + last. This mode provides load balancing and fault + tolerance. + + active-backup or 1 + + Active-backup policy: Only one slave in the bond is + active. A different slave becomes active if, and only + if, the active slave fails. The bond's MAC address is + externally visible on only one port (network adapter) + to avoid confusing the switch. + + In bonding version 2.6.2 or later, when a failover + occurs in active-backup mode, bonding will issue one + or more gratuitous ARPs on the newly active slave. + One gratuitous ARP is issued for the bonding master + interface and each VLAN interfaces configured above + it, provided that the interface has at least one IP + address configured. Gratuitous ARPs issued for VLAN + interfaces are tagged with the appropriate VLAN id. + + This mode provides fault tolerance. The primary + option, documented below, affects the behavior of this + mode. + + balance-xor or 2 + + XOR policy: Transmit based on the selected transmit + hash policy. The default policy is a simple [(source + MAC address XOR'd with destination MAC address) modulo + slave count]. Alternate transmit policies may be + selected via the xmit_hash_policy option, described + below. + + This mode provides load balancing and fault tolerance. + + broadcast or 3 + + Broadcast policy: transmits everything on all slave + interfaces. This mode provides fault tolerance. + + 802.3ad or 4 + + IEEE 802.3ad Dynamic link aggregation. Creates + aggregation groups that share the same speed and + duplex settings. Utilizes all slaves in the active + aggregator according to the 802.3ad specification. + + Slave selection for outgoing traffic is done according + to the transmit hash policy, which may be changed from + the default simple XOR policy via the xmit_hash_policy + option, documented below. Note that not all transmit + policies may be 802.3ad compliant, particularly in + regards to the packet mis-ordering requirements of + section 43.2.4 of the 802.3ad standard. Differing + peer implementations will have varying tolerances for + noncompliance. + + Prerequisites: + + 1. Ethtool support in the base drivers for retrieving + the speed and duplex of each slave. + + 2. A switch that supports IEEE 802.3ad Dynamic link + aggregation. + + Most switches will require some type of configuration + to enable 802.3ad mode. + + balance-tlb or 5 + + Adaptive transmit load balancing: channel bonding that + does not require any special switch support. The + outgoing traffic is distributed according to the + current load (computed relative to the speed) on each + slave. Incoming traffic is received by the current + slave. If the receiving slave fails, another slave + takes over the MAC address of the failed receiving + slave. + + Prerequisite: + + Ethtool support in the base drivers for retrieving the + speed of each slave. + + balance-alb or 6 + + Adaptive load balancing: includes balance-tlb plus + receive load balancing (rlb) for IPV4 traffic, and + does not require any special switch support. The + receive load balancing is achieved by ARP negotiation. + The bonding driver intercepts the ARP Replies sent by + the local system on their way out and overwrites the + source hardware address with the unique hardware + address of one of the slaves in the bond such that + different peers use different hardware addresses for + the server. + + Receive traffic from connections created by the server + is also balanced. When the local system sends an ARP + Request the bonding driver copies and saves the peer's + IP information from the ARP packet. When the ARP + Reply arrives from the peer, its hardware address is + retrieved and the bonding driver initiates an ARP + reply to this peer assigning it to one of the slaves + in the bond. A problematic outcome of using ARP + negotiation for balancing is that each time that an + ARP request is broadcast it uses the hardware address + of the bond. Hence, peers learn the hardware address + of the bond and the balancing of receive traffic + collapses to the current slave. This is handled by + sending updates (ARP Replies) to all the peers with + their individually assigned hardware address such that + the traffic is redistributed. Receive traffic is also + redistributed when a new slave is added to the bond + and when an inactive slave is re-activated. The + receive load is distributed sequentially (round robin) + among the group of highest speed slaves in the bond. + + When a link is reconnected or a new slave joins the + bond the receive traffic is redistributed among all + active slaves in the bond by initiating ARP Replies + with the selected MAC address to each of the + clients. The updelay parameter (detailed below) must + be set to a value equal or greater than the switch's + forwarding delay so that the ARP Replies sent to the + peers will not be blocked by the switch. + + Prerequisites: + + 1. Ethtool support in the base drivers for retrieving + the speed of each slave. + + 2. Base driver support for setting the hardware + address of a device while it is open. This is + required so that there will always be one slave in the + team using the bond hardware address (the + curr_active_slave) while having a unique hardware + address for each slave in the bond. If the + curr_active_slave fails its hardware address is + swapped with the new curr_active_slave that was + chosen. + +num_grat_arp + + Specifies the number of gratuitous ARPs to be issued after a + failover event. One gratuitous ARP is issued immediately after + the failover, subsequent ARPs are sent at a rate of one per link + monitor interval (arp_interval or miimon, whichever is active). + + The valid range is 0 - 255; the default value is 1. This option + affects only the active-backup mode. This option was added for + bonding version 3.3.0. + +num_unsol_na + + Specifies the number of unsolicited IPv6 Neighbor Advertisements + to be issued after a failover event. One unsolicited NA is issued + immediately after the failover. + + The valid range is 0 - 255; the default value is 1. This option + affects only the active-backup mode. This option was added for + bonding version 3.4.0. + +primary + + A string (eth0, eth2, etc) specifying which slave is the + primary device. The specified device will always be the + active slave while it is available. Only when the primary is + off-line will alternate devices be used. This is useful when + one slave is preferred over another, e.g., when one slave has + higher throughput than another. + + The primary option is only valid for active-backup mode. + +primary_reselect + + Specifies the reselection policy for the primary slave. This + affects how the primary slave is chosen to become the active slave + when failure of the active slave or recovery of the primary slave + occurs. This option is designed to prevent flip-flopping between + the primary slave and other slaves. Possible values are: + + always or 0 (default) + + The primary slave becomes the active slave whenever it + comes back up. + + better or 1 + + The primary slave becomes the active slave when it comes + back up, if the speed and duplex of the primary slave is + better than the speed and duplex of the current active + slave. + + failure or 2 + + The primary slave becomes the active slave only if the + current active slave fails and the primary slave is up. + + The primary_reselect setting is ignored in two cases: + + If no slaves are active, the first slave to recover is + made the active slave. + + When initially enslaved, the primary slave is always made + the active slave. + + Changing the primary_reselect policy via sysfs will cause an + immediate selection of the best active slave according to the new + policy. This may or may not result in a change of the active + slave, depending upon the circumstances. + + This option was added for bonding version 3.6.0. + +updelay + + Specifies the time, in milliseconds, to wait before enabling a + slave after a link recovery has been detected. This option is + only valid for the miimon link monitor. The updelay value + should be a multiple of the miimon value; if not, it will be + rounded down to the nearest multiple. The default value is 0. + +use_carrier + + Specifies whether or not miimon should use MII or ETHTOOL + ioctls vs. netif_carrier_ok() to determine the link + status. The MII or ETHTOOL ioctls are less efficient and + utilize a deprecated calling sequence within the kernel. The + netif_carrier_ok() relies on the device driver to maintain its + state with netif_carrier_on/off; at this writing, most, but + not all, device drivers support this facility. + + If bonding insists that the link is up when it should not be, + it may be that your network device driver does not support + netif_carrier_on/off. The default state for netif_carrier is + "carrier on," so if a driver does not support netif_carrier, + it will appear as if the link is always up. In this case, + setting use_carrier to 0 will cause bonding to revert to the + MII / ETHTOOL ioctl method to determine the link state. + + A value of 1 enables the use of netif_carrier_ok(), a value of + 0 will use the deprecated MII / ETHTOOL ioctls. The default + value is 1. + +xmit_hash_policy + + Selects the transmit hash policy to use for slave selection in + balance-xor and 802.3ad modes. Possible values are: + + layer2 + + Uses XOR of hardware MAC addresses to generate the + hash. The formula is + + (source MAC XOR destination MAC) modulo slave count + + This algorithm will place all traffic to a particular + network peer on the same slave. + + This algorithm is 802.3ad compliant. + + layer2+3 + + This policy uses a combination of layer2 and layer3 + protocol information to generate the hash. + + Uses XOR of hardware MAC addresses and IP addresses to + generate the hash. The formula is + + (((source IP XOR dest IP) AND 0xffff) XOR + ( source MAC XOR destination MAC )) + modulo slave count + + This algorithm will place all traffic to a particular + network peer on the same slave. For non-IP traffic, + the formula is the same as for the layer2 transmit + hash policy. + + This policy is intended to provide a more balanced + distribution of traffic than layer2 alone, especially + in environments where a layer3 gateway device is + required to reach most destinations. + + This algorithm is 802.3ad compliant. + + layer3+4 + + This policy uses upper layer protocol information, + when available, to generate the hash. This allows for + traffic to a particular network peer to span multiple + slaves, although a single connection will not span + multiple slaves. + + The formula for unfragmented TCP and UDP packets is + + ((source port XOR dest port) XOR + ((source IP XOR dest IP) AND 0xffff) + modulo slave count + + For fragmented TCP or UDP packets and all other IP + protocol traffic, the source and destination port + information is omitted. For non-IP traffic, the + formula is the same as for the layer2 transmit hash + policy. + + This policy is intended to mimic the behavior of + certain switches, notably Cisco switches with PFC2 as + well as some Foundry and IBM products. + + This algorithm is not fully 802.3ad compliant. A + single TCP or UDP conversation containing both + fragmented and unfragmented packets will see packets + striped across two interfaces. This may result in out + of order delivery. Most traffic types will not meet + this criteria, as TCP rarely fragments traffic, and + most UDP traffic is not involved in extended + conversations. Other implementations of 802.3ad may + or may not tolerate this noncompliance. + + The default value is layer2. This option was added in bonding + version 2.6.3. In earlier versions of bonding, this parameter + does not exist, and the layer2 policy is the only policy. The + layer2+3 value was added for bonding version 3.2.2. + + +3. Configuring Bonding Devices +============================== + + You can configure bonding using either your distro's network +initialization scripts, or manually using either ifenslave or the +sysfs interface. Distros generally use one of two packages for the +network initialization scripts: initscripts or sysconfig. Recent +versions of these packages have support for bonding, while older +versions do not. + + We will first describe the options for configuring bonding for +distros using versions of initscripts and sysconfig with full or +partial support for bonding, then provide information on enabling +bonding without support from the network initialization scripts (i.e., +older versions of initscripts or sysconfig). + + If you're unsure whether your distro uses sysconfig or +initscripts, or don't know if it's new enough, have no fear. +Determining this is fairly straightforward. + + First, issue the command: + +$ rpm -qf /sbin/ifup + + It will respond with a line of text starting with either +"initscripts" or "sysconfig," followed by some numbers. This is the +package that provides your network initialization scripts. + + Next, to determine if your installation supports bonding, +issue the command: + +$ grep ifenslave /sbin/ifup + + If this returns any matches, then your initscripts or +sysconfig has support for bonding. + +3.1 Configuration with Sysconfig Support +---------------------------------------- + + This section applies to distros using a version of sysconfig +with bonding support, for example, SuSE Linux Enterprise Server 9. + + SuSE SLES 9's networking configuration system does support +bonding, however, at this writing, the YaST system configuration +front end does not provide any means to work with bonding devices. +Bonding devices can be managed by hand, however, as follows. + + First, if they have not already been configured, configure the +slave devices. On SLES 9, this is most easily done by running the +yast2 sysconfig configuration utility. The goal is for to create an +ifcfg-id file for each slave device. The simplest way to accomplish +this is to configure the devices for DHCP (this is only to get the +file ifcfg-id file created; see below for some issues with DHCP). The +name of the configuration file for each device will be of the form: + +ifcfg-id-xx:xx:xx:xx:xx:xx + + Where the "xx" portion will be replaced with the digits from +the device's permanent MAC address. + + Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been +created, it is necessary to edit the configuration files for the slave +devices (the MAC addresses correspond to those of the slave devices). +Before editing, the file will contain multiple lines, and will look +something like this: + +BOOTPROTO='dhcp' +STARTMODE='on' +USERCTL='no' +UNIQUE='XNzu.WeZGOGF+4wE' +_nm_name='bus-pci-0001:61:01.0' + + Change the BOOTPROTO and STARTMODE lines to the following: + +BOOTPROTO='none' +STARTMODE='off' + + Do not alter the UNIQUE or _nm_name lines. Remove any other +lines (USERCTL, etc). + + Once the ifcfg-id-xx:xx:xx:xx:xx:xx files have been modified, +it's time to create the configuration file for the bonding device +itself. This file is named ifcfg-bondX, where X is the number of the +bonding device to create, starting at 0. The first such file is +ifcfg-bond0, the second is ifcfg-bond1, and so on. The sysconfig +network configuration system will correctly start multiple instances +of bonding. + + The contents of the ifcfg-bondX file is as follows: + +BOOTPROTO="static" +BROADCAST="10.0.2.255" +IPADDR="10.0.2.10" +NETMASK="255.255.0.0" +NETWORK="10.0.2.0" +REMOTE_IPADDR="" +STARTMODE="onboot" +BONDING_MASTER="yes" +BONDING_MODULE_OPTS="mode=active-backup miimon=100" +BONDING_SLAVE0="eth0" +BONDING_SLAVE1="bus-pci-0000:06:08.1" + + Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK +values with the appropriate values for your network. + + The STARTMODE specifies when the device is brought online. +The possible values are: + + onboot: The device is started at boot time. If you're not + sure, this is probably what you want. + + manual: The device is started only when ifup is called + manually. Bonding devices may be configured this + way if you do not wish them to start automatically + at boot for some reason. + + hotplug: The device is started by a hotplug event. This is not + a valid choice for a bonding device. + + off or ignore: The device configuration is ignored. + + The line BONDING_MASTER='yes' indicates that the device is a +bonding master device. The only useful value is "yes." + + The contents of BONDING_MODULE_OPTS are supplied to the +instance of the bonding module for this device. Specify the options +for the bonding mode, link monitoring, and so on here. Do not include +the max_bonds bonding parameter; this will confuse the configuration +system if you have multiple bonding devices. + + Finally, supply one BONDING_SLAVEn="slave device" for each +slave. where "n" is an increasing value, one for each slave. The +"slave device" is either an interface name, e.g., "eth0", or a device +specifier for the network device. The interface name is easier to +find, but the ethN names are subject to change at boot time if, e.g., +a device early in the sequence has failed. The device specifiers +(bus-pci-0000:06:08.1 in the example above) specify the physical +network device, and will not change unless the device's bus location +changes (for example, it is moved from one PCI slot to another). The +example above uses one of each type for demonstration purposes; most +configurations will choose one or the other for all slave devices. + + When all configuration files have been modified or created, +networking must be restarted for the configuration changes to take +effect. This can be accomplished via the following: + +# /etc/init.d/network restart + + Note that the network control script (/sbin/ifdown) will +remove the bonding module as part of the network shutdown processing, +so it is not necessary to remove the module by hand if, e.g., the +module parameters have changed. + + Also, at this writing, YaST/YaST2 will not manage bonding +devices (they do not show bonding interfaces on its list of network +devices). It is necessary to edit the configuration file by hand to +change the bonding configuration. + + Additional general options and details of the ifcfg file +format can be found in an example ifcfg template file: + +/etc/sysconfig/network/ifcfg.template + + Note that the template does not document the various BONDING_ +settings described above, but does describe many of the other options. + +3.1.1 Using DHCP with Sysconfig +------------------------------- + + Under sysconfig, configuring a device with BOOTPROTO='dhcp' +will cause it to query DHCP for its IP address information. At this +writing, this does not function for bonding devices; the scripts +attempt to obtain the device address from DHCP prior to adding any of +the slave devices. Without active slaves, the DHCP requests are not +sent to the network. + +3.1.2 Configuring Multiple Bonds with Sysconfig +----------------------------------------------- + + The sysconfig network initialization system is capable of +handling multiple bonding devices. All that is necessary is for each +bonding instance to have an appropriately configured ifcfg-bondX file +(as described above). Do not specify the "max_bonds" parameter to any +instance of bonding, as this will confuse sysconfig. If you require +multiple bonding devices with identical parameters, create multiple +ifcfg-bondX files. + + Because the sysconfig scripts supply the bonding module +options in the ifcfg-bondX file, it is not necessary to add them to +the system /etc/modules.conf or /etc/modprobe.conf configuration file. + +3.2 Configuration with Initscripts Support +------------------------------------------ + + This section applies to distros using a recent version of +initscripts with bonding support, for example, Red Hat Enterprise Linux +version 3 or later, Fedora, etc. On these systems, the network +initialization scripts have knowledge of bonding, and can be configured to +control bonding devices. Note that older versions of the initscripts +package have lower levels of support for bonding; this will be noted where +applicable. + + These distros will not automatically load the network adapter +driver unless the ethX device is configured with an IP address. +Because of this constraint, users must manually configure a +network-script file for all physical adapters that will be members of +a bondX link. Network script files are located in the directory: + +/etc/sysconfig/network-scripts + + The file name must be prefixed with "ifcfg-eth" and suffixed +with the adapter's physical adapter number. For example, the script +for eth0 would be named /etc/sysconfig/network-scripts/ifcfg-eth0. +Place the following text in the file: + +DEVICE=eth0 +USERCTL=no +ONBOOT=yes +MASTER=bond0 +SLAVE=yes +BOOTPROTO=none + + The DEVICE= line will be different for every ethX device and +must correspond with the name of the file, i.e., ifcfg-eth1 must have +a device line of DEVICE=eth1. The setting of the MASTER= line will +also depend on the final bonding interface name chosen for your bond. +As with other network devices, these typically start at 0, and go up +one for each device, i.e., the first bonding instance is bond0, the +second is bond1, and so on. + + Next, create a bond network script. The file name for this +script will be /etc/sysconfig/network-scripts/ifcfg-bondX where X is +the number of the bond. For bond0 the file is named "ifcfg-bond0", +for bond1 it is named "ifcfg-bond1", and so on. Within that file, +place the following text: + +DEVICE=bond0 +IPADDR=192.168.1.1 +NETMASK=255.255.255.0 +NETWORK=192.168.1.0 +BROADCAST=192.168.1.255 +ONBOOT=yes +BOOTPROTO=none +USERCTL=no + + Be sure to change the networking specific lines (IPADDR, +NETMASK, NETWORK and BROADCAST) to match your network configuration. + + For later versions of initscripts, such as that found with Fedora +7 (or later) and Red Hat Enterprise Linux version 5 (or later), it is possible, +and, indeed, preferable, to specify the bonding options in the ifcfg-bond0 +file, e.g. a line of the format: + +BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254" + + will configure the bond with the specified options. The options +specified in BONDING_OPTS are identical to the bonding module parameters +except for the arp_ip_target field when using versions of initscripts older +than and 8.57 (Fedora 8) and 8.45.19 (Red Hat Enterprise Linux 5.2). When +using older versions each target should be included as a separate option and +should be preceded by a '+' to indicate it should be added to the list of +queried targets, e.g., + + arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2 + + is the proper syntax to specify multiple targets. When specifying +options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or +/etc/modprobe.conf. + + For even older versions of initscripts that do not support +BONDING_OPTS, it is necessary to edit /etc/modules.conf (or +/etc/modprobe.conf, depending upon your distro) to load the bonding module +with your desired options when the bond0 interface is brought up. The +following lines in /etc/modules.conf (or modprobe.conf) will load the +bonding module, and select its options: + +alias bond0 bonding +options bond0 mode=balance-alb miimon=100 + + Replace the sample parameters with the appropriate set of +options for your configuration. + + Finally run "/etc/rc.d/init.d/network restart" as root. This +will restart the networking subsystem and your bond link should be now +up and running. + +3.2.1 Using DHCP with Initscripts +--------------------------------- + + Recent versions of initscripts (the versions supplied with Fedora +Core 3 and Red Hat Enterprise Linux 4, or later versions, are reported to +work) have support for assigning IP information to bonding devices via +DHCP. + + To configure bonding for DHCP, configure it as described +above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp" +and add a line consisting of "TYPE=Bonding". Note that the TYPE value +is case sensitive. + +3.2.2 Configuring Multiple Bonds with Initscripts +------------------------------------------------- + + Initscripts packages that are included with Fedora 7 and Red Hat +Enterprise Linux 5 support multiple bonding interfaces by simply +specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is the +number of the bond. This support requires sysfs support in the kernel, +and a bonding driver of version 3.0.0 or later. Other configurations may +not support this method for specifying multiple bonding interfaces; for +those instances, see the "Configuring Multiple Bonds Manually" section, +below. + +3.3 Configuring Bonding Manually with Ifenslave +----------------------------------------------- + + This section applies to distros whose network initialization +scripts (the sysconfig or initscripts package) do not have specific +knowledge of bonding. One such distro is SuSE Linux Enterprise Server +version 8. + + The general method for these systems is to place the bonding +module parameters into /etc/modules.conf or /etc/modprobe.conf (as +appropriate for the installed distro), then add modprobe and/or +ifenslave commands to the system's global init script. The name of +the global init script differs; for sysconfig, it is +/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local. + + For example, if you wanted to make a simple bond of two e100 +devices (presumed to be eth0 and eth1), and have it persist across +reboots, edit the appropriate file (/etc/init.d/boot.local or +/etc/rc.d/rc.local), and add the following: + +modprobe bonding mode=balance-alb miimon=100 +modprobe e100 +ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up +ifenslave bond0 eth0 +ifenslave bond0 eth1 + + Replace the example bonding module parameters and bond0 +network configuration (IP address, netmask, etc) with the appropriate +values for your configuration. + + Unfortunately, this method will not provide support for the +ifup and ifdown scripts on the bond devices. To reload the bonding +configuration, it is necessary to run the initialization script, e.g., + +# /etc/init.d/boot.local + + or + +# /etc/rc.d/rc.local + + It may be desirable in such a case to create a separate script +which only initializes the bonding configuration, then call that +separate script from within boot.local. This allows for bonding to be +enabled without re-running the entire global init script. + + To shut down the bonding devices, it is necessary to first +mark the bonding device itself as being down, then remove the +appropriate device driver modules. For our example above, you can do +the following: + +# ifconfig bond0 down +# rmmod bonding +# rmmod e100 + + Again, for convenience, it may be desirable to create a script +with these commands. + + +3.3.1 Configuring Multiple Bonds Manually +----------------------------------------- + + This section contains information on configuring multiple +bonding devices with differing options for those systems whose network +initialization scripts lack support for configuring multiple bonds. + + If you require multiple bonding devices, but all with the same +options, you may wish to use the "max_bonds" module parameter, +documented above. + + To create multiple bonding devices with differing options, it is +preferrable to use bonding parameters exported by sysfs, documented in the +section below. + + For versions of bonding without sysfs support, the only means to +provide multiple instances of bonding with differing options is to load +the bonding driver multiple times. Note that current versions of the +sysconfig network initialization scripts handle this automatically; if +your distro uses these scripts, no special action is needed. See the +section Configuring Bonding Devices, above, if you're not sure about your +network initialization scripts. + + To load multiple instances of the module, it is necessary to +specify a different name for each instance (the module loading system +requires that every loaded module, even multiple instances of the same +module, have a unique name). This is accomplished by supplying multiple +sets of bonding options in /etc/modprobe.conf, for example: + +alias bond0 bonding +options bond0 -o bond0 mode=balance-rr miimon=100 + +alias bond1 bonding +options bond1 -o bond1 mode=balance-alb miimon=50 + + will load the bonding module two times. The first instance is +named "bond0" and creates the bond0 device in balance-rr mode with an +miimon of 100. The second instance is named "bond1" and creates the +bond1 device in balance-alb mode with an miimon of 50. + + In some circumstances (typically with older distributions), +the above does not work, and the second bonding instance never sees +its options. In that case, the second options line can be substituted +as follows: + +install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \ + mode=balance-alb miimon=50 + + This may be repeated any number of times, specifying a new and +unique name in place of bond1 for each subsequent instance. + + It has been observed that some Red Hat supplied kernels are unable +to rename modules at load time (the "-o bond1" part). Attempts to pass +that option to modprobe will produce an "Operation not permitted" error. +This has been reported on some Fedora Core kernels, and has been seen on +RHEL 4 as well. On kernels exhibiting this problem, it will be impossible +to configure multiple bonds with differing parameters (as they are older +kernels, and also lack sysfs support). + +3.4 Configuring Bonding Manually via Sysfs +------------------------------------------ + + Starting with version 3.0.0, Channel Bonding may be configured +via the sysfs interface. This interface allows dynamic configuration +of all bonds in the system without unloading the module. It also +allows for adding and removing bonds at runtime. Ifenslave is no +longer required, though it is still supported. + + Use of the sysfs interface allows you to use multiple bonds +with different configurations without having to reload the module. +It also allows you to use multiple, differently configured bonds when +bonding is compiled into the kernel. + + You must have the sysfs filesystem mounted to configure +bonding this way. The examples in this document assume that you +are using the standard mount point for sysfs, e.g. /sys. If your +sysfs filesystem is mounted elsewhere, you will need to adjust the +example paths accordingly. + +Creating and Destroying Bonds +----------------------------- +To add a new bond foo: +# echo +foo > /sys/class/net/bonding_masters + +To remove an existing bond bar: +# echo -bar > /sys/class/net/bonding_masters + +To show all existing bonds: +# cat /sys/class/net/bonding_masters + +NOTE: due to 4K size limitation of sysfs files, this list may be +truncated if you have more than a few hundred bonds. This is unlikely +to occur under normal operating conditions. + +Adding and Removing Slaves +-------------------------- + Interfaces may be enslaved to a bond using the file +/sys/class/net//bonding/slaves. The semantics for this file +are the same as for the bonding_masters file. + +To enslave interface eth0 to bond bond0: +# ifconfig bond0 up +# echo +eth0 > /sys/class/net/bond0/bonding/slaves + +To free slave eth0 from bond bond0: +# echo -eth0 > /sys/class/net/bond0/bonding/slaves + + When an interface is enslaved to a bond, symlinks between the +two are created in the sysfs filesystem. In this case, you would get +/sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and +/sys/class/net/eth0/master pointing to /sys/class/net/bond0. + + This means that you can tell quickly whether or not an +interface is enslaved by looking for the master symlink. Thus: +# echo -eth0 > /sys/class/net/eth0/master/bonding/slaves +will free eth0 from whatever bond it is enslaved to, regardless of +the name of the bond interface. + +Changing a Bond's Configuration +------------------------------- + Each bond may be configured individually by manipulating the +files located in /sys/class/net//bonding + + The names of these files correspond directly with the command- +line parameters described elsewhere in this file, and, with the +exception of arp_ip_target, they accept the same values. To see the +current setting, simply cat the appropriate file. + + A few examples will be given here; for specific usage +guidelines for each parameter, see the appropriate section in this +document. + +To configure bond0 for balance-alb mode: +# ifconfig bond0 down +# echo 6 > /sys/class/net/bond0/bonding/mode + - or - +# echo balance-alb > /sys/class/net/bond0/bonding/mode + NOTE: The bond interface must be down before the mode can be +changed. + +To enable MII monitoring on bond0 with a 1 second interval: +# echo 1000 > /sys/class/net/bond0/bonding/miimon + NOTE: If ARP monitoring is enabled, it will disabled when MII +monitoring is enabled, and vice-versa. + +To add ARP targets: +# echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target +# echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target + NOTE: up to 16 target addresses may be specified. + +To remove an ARP target: +# echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target + +Example Configuration +--------------------- + We begin with the same example that is shown in section 3.3, +executed with sysfs, and without using ifenslave. + + To make a simple bond of two e100 devices (presumed to be eth0 +and eth1), and have it persist across reboots, edit the appropriate +file (/etc/init.d/boot.local or /etc/rc.d/rc.local), and add the +following: + +modprobe bonding +modprobe e100 +echo balance-alb > /sys/class/net/bond0/bonding/mode +ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up +echo 100 > /sys/class/net/bond0/bonding/miimon +echo +eth0 > /sys/class/net/bond0/bonding/slaves +echo +eth1 > /sys/class/net/bond0/bonding/slaves + + To add a second bond, with two e1000 interfaces in +active-backup mode, using ARP monitoring, add the following lines to +your init script: + +modprobe e1000 +echo +bond1 > /sys/class/net/bonding_masters +echo active-backup > /sys/class/net/bond1/bonding/mode +ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up +echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target +echo 2000 > /sys/class/net/bond1/bonding/arp_interval +echo +eth2 > /sys/class/net/bond1/bonding/slaves +echo +eth3 > /sys/class/net/bond1/bonding/slaves + + +4. Querying Bonding Configuration +================================= + +4.1 Bonding Configuration +------------------------- + + Each bonding device has a read-only file residing in the +/proc/net/bonding directory. The file contents include information +about the bonding configuration, options and state of each slave. + + For example, the contents of /proc/net/bonding/bond0 after the +driver is loaded with parameters of mode=0 and miimon=1000 is +generally as follows: + + Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004) + Bonding Mode: load balancing (round-robin) + Currently Active Slave: eth0 + MII Status: up + MII Polling Interval (ms): 1000 + Up Delay (ms): 0 + Down Delay (ms): 0 + + Slave Interface: eth1 + MII Status: up + Link Failure Count: 1 + + Slave Interface: eth0 + MII Status: up + Link Failure Count: 1 + + The precise format and contents will change depending upon the +bonding configuration, state, and version of the bonding driver. + +4.2 Network configuration +------------------------- + + The network configuration can be inspected using the ifconfig +command. Bonding devices will have the MASTER flag set; Bonding slave +devices will have the SLAVE flag set. The ifconfig output does not +contain information on which slaves are associated with which masters. + + In the example below, the bond0 interface is the master +(MASTER) while eth0 and eth1 are slaves (SLAVE). Notice all slaves of +bond0 have the same MAC address (HWaddr) as bond0 for all modes except +TLB and ALB that require a unique MAC address for each slave. + +# /sbin/ifconfig +bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 + inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 + UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 + RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0 + TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0 + collisions:0 txqueuelen:0 + +eth0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 + UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 + RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0 + TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0 + collisions:0 txqueuelen:100 + Interrupt:10 Base address:0x1080 + +eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 + UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 + RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0 + TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:100 + Interrupt:9 Base address:0x1400 + +5. Switch Configuration +======================= + + For this section, "switch" refers to whatever system the +bonded devices are directly connected to (i.e., where the other end of +the cable plugs into). This may be an actual dedicated switch device, +or it may be another regular system (e.g., another computer running +Linux), + + The active-backup, balance-tlb and balance-alb modes do not +require any specific configuration of the switch. + + The 802.3ad mode requires that the switch have the appropriate +ports configured as an 802.3ad aggregation. The precise method used +to configure this varies from switch to switch, but, for example, a +Cisco 3550 series switch requires that the appropriate ports first be +grouped together in a single etherchannel instance, then that +etherchannel is set to mode "lacp" to enable 802.3ad (instead of +standard EtherChannel). + + The balance-rr, balance-xor and broadcast modes generally +require that the switch have the appropriate ports grouped together. +The nomenclature for such a group differs between switches, it may be +called an "etherchannel" (as in the Cisco example, above), a "trunk +group" or some other similar variation. For these modes, each switch +will also have its own configuration options for the switch's transmit +policy to the bond. Typical choices include XOR of either the MAC or +IP addresses. The transmit policy of the two peers does not need to +match. For these three modes, the bonding mode really selects a +transmit policy for an EtherChannel group; all three will interoperate +with another EtherChannel group. + + +6. 802.1q VLAN Support +====================== + + It is possible to configure VLAN devices over a bond interface +using the 8021q driver. However, only packets coming from the 8021q +driver and passing through bonding will be tagged by default. Self +generated packets, for example, bonding's learning packets or ARP +packets generated by either ALB mode or the ARP monitor mechanism, are +tagged internally by bonding itself. As a result, bonding must +"learn" the VLAN IDs configured above it, and use those IDs to tag +self generated packets. + + For reasons of simplicity, and to support the use of adapters +that can do VLAN hardware acceleration offloading, the bonding +interface declares itself as fully hardware offloading capable, it gets +the add_vid/kill_vid notifications to gather the necessary +information, and it propagates those actions to the slaves. In case +of mixed adapter types, hardware accelerated tagged packets that +should go through an adapter that is not offloading capable are +"un-accelerated" by the bonding driver so the VLAN tag sits in the +regular location. + + VLAN interfaces *must* be added on top of a bonding interface +only after enslaving at least one slave. The bonding interface has a +hardware address of 00:00:00:00:00:00 until the first slave is added. +If the VLAN interface is created prior to the first enslavement, it +would pick up the all-zeroes hardware address. Once the first slave +is attached to the bond, the bond device itself will pick up the +slave's hardware address, which is then available for the VLAN device. + + Also, be aware that a similar problem can occur if all slaves +are released from a bond that still has one or more VLAN interfaces on +top of it. When a new slave is added, the bonding interface will +obtain its hardware address from the first slave, which might not +match the hardware address of the VLAN interfaces (which was +ultimately copied from an earlier slave). + + There are two methods to insure that the VLAN device operates +with the correct hardware address if all slaves are removed from a +bond interface: + + 1. Remove all VLAN interfaces then recreate them + + 2. Set the bonding interface's hardware address so that it +matches the hardware address of the VLAN interfaces. + + Note that changing a VLAN interface's HW address would set the +underlying device -- i.e. the bonding interface -- to promiscuous +mode, which might not be what you want. + + +7. Link Monitoring +================== + + The bonding driver at present supports two schemes for +monitoring a slave device's link state: the ARP monitor and the MII +monitor. + + At the present time, due to implementation restrictions in the +bonding driver itself, it is not possible to enable both ARP and MII +monitoring simultaneously. + +7.1 ARP Monitor Operation +------------------------- + + The ARP monitor operates as its name suggests: it sends ARP +queries to one or more designated peer systems on the network, and +uses the response as an indication that the link is operating. This +gives some assurance that traffic is actually flowing to and from one +or more peers on the local network. + + The ARP monitor relies on the device driver itself to verify +that traffic is flowing. In particular, the driver must keep up to +date the last receive time, dev->last_rx, and transmit start time, +dev->trans_start. If these are not updated by the driver, then the +ARP monitor will immediately fail any slaves using that driver, and +those slaves will stay down. If networking monitoring (tcpdump, etc) +shows the ARP requests and replies on the network, then it may be that +your device driver is not updating last_rx and trans_start. + +7.2 Configuring Multiple ARP Targets +------------------------------------ + + While ARP monitoring can be done with just one target, it can +be useful in a High Availability setup to have several targets to +monitor. In the case of just one target, the target itself may go +down or have a problem making it unresponsive to ARP requests. Having +an additional target (or several) increases the reliability of the ARP +monitoring. + + Multiple ARP targets must be separated by commas as follows: + +# example options for ARP monitoring with three targets +alias bond0 bonding +options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9 + + For just a single target the options would resemble: + +# example options for ARP monitoring with one target +alias bond0 bonding +options bond0 arp_interval=60 arp_ip_target=192.168.0.100 + + +7.3 MII Monitor Operation +------------------------- + + The MII monitor monitors only the carrier state of the local +network interface. It accomplishes this in one of three ways: by +depending upon the device driver to maintain its carrier state, by +querying the device's MII registers, or by making an ethtool query to +the device. + + If the use_carrier module parameter is 1 (the default value), +then the MII monitor will rely on the driver for carrier state +information (via the netif_carrier subsystem). As explained in the +use_carrier parameter information, above, if the MII monitor fails to +detect carrier loss on the device (e.g., when the cable is physically +disconnected), it may be that the driver does not support +netif_carrier. + + If use_carrier is 0, then the MII monitor will first query the +device's (via ioctl) MII registers and check the link state. If that +request fails (not just that it returns carrier down), then the MII +monitor will make an ethtool ETHOOL_GLINK request to attempt to obtain +the same information. If both methods fail (i.e., the driver either +does not support or had some error in processing both the MII register +and ethtool requests), then the MII monitor will assume the link is +up. + +8. Potential Sources of Trouble +=============================== + +8.1 Adventures in Routing +------------------------- + + When bonding is configured, it is important that the slave +devices not have routes that supersede routes of the master (or, +generally, not have routes at all). For example, suppose the bonding +device bond0 has two slaves, eth0 and eth1, and the routing table is +as follows: + +Kernel IP routing table +Destination Gateway Genmask Flags MSS Window irtt Iface +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth0 +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 bond0 +127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo + + This routing configuration will likely still update the +receive/transmit times in the driver (needed by the ARP monitor), but +may bypass the bonding driver (because outgoing traffic to, in this +case, another host on network 10 would use eth0 or eth1 before bond0). + + The ARP monitor (and ARP itself) may become confused by this +configuration, because ARP requests (generated by the ARP monitor) +will be sent on one interface (bond0), but the corresponding reply +will arrive on a different interface (eth0). This reply looks to ARP +as an unsolicited ARP reply (because ARP matches replies on an +interface basis), and is discarded. The MII monitor is not affected +by the state of the routing table. + + The solution here is simply to insure that slaves do not have +routes of their own, and if for some reason they must, those routes do +not supersede routes of their master. This should generally be the +case, but unusual configurations or errant manual or automatic static +route additions may cause trouble. + +8.2 Ethernet Device Renaming +---------------------------- + + On systems with network configuration scripts that do not +associate physical devices directly with network interface names (so +that the same physical device always has the same "ethX" name), it may +be necessary to add some special logic to either /etc/modules.conf or +/etc/modprobe.conf (depending upon which is installed on the system). + + For example, given a modules.conf containing the following: + +alias bond0 bonding +options bond0 mode=some-mode miimon=50 +alias eth0 tg3 +alias eth1 tg3 +alias eth2 e1000 +alias eth3 e1000 + + If neither eth0 and eth1 are slaves to bond0, then when the +bond0 interface comes up, the devices may end up reordered. This +happens because bonding is loaded first, then its slave device's +drivers are loaded next. Since no other drivers have been loaded, +when the e1000 driver loads, it will receive eth0 and eth1 for its +devices, but the bonding configuration tries to enslave eth2 and eth3 +(which may later be assigned to the tg3 devices). + + Adding the following: + +add above bonding e1000 tg3 + + causes modprobe to load e1000 then tg3, in that order, when +bonding is loaded. This command is fully documented in the +modules.conf manual page. + + On systems utilizing modprobe.conf (or modprobe.conf.local), +an equivalent problem can occur. In this case, the following can be +added to modprobe.conf (or modprobe.conf.local, as appropriate), as +follows (all on one line; it has been split here for clarity): + +install bonding /sbin/modprobe tg3; /sbin/modprobe e1000; + /sbin/modprobe --ignore-install bonding + + This will, when loading the bonding module, rather than +performing the normal action, instead execute the provided command. +This command loads the device drivers in the order needed, then calls +modprobe with --ignore-install to cause the normal action to then take +place. Full documentation on this can be found in the modprobe.conf +and modprobe manual pages. + +8.3. Painfully Slow Or No Failed Link Detection By Miimon +--------------------------------------------------------- + + By default, bonding enables the use_carrier option, which +instructs bonding to trust the driver to maintain carrier state. + + As discussed in the options section, above, some drivers do +not support the netif_carrier_on/_off link state tracking system. +With use_carrier enabled, bonding will always see these links as up, +regardless of their actual state. + + Additionally, other drivers do support netif_carrier, but do +not maintain it in real time, e.g., only polling the link state at +some fixed interval. In this case, miimon will detect failures, but +only after some long period of time has expired. If it appears that +miimon is very slow in detecting link failures, try specifying +use_carrier=0 to see if that improves the failure detection time. If +it does, then it may be that the driver checks the carrier state at a +fixed interval, but does not cache the MII register values (so the +use_carrier=0 method of querying the registers directly works). If +use_carrier=0 does not improve the failover, then the driver may cache +the registers, or the problem may be elsewhere. + + Also, remember that miimon only checks for the device's +carrier state. It has no way to determine the state of devices on or +beyond other ports of a switch, or if a switch is refusing to pass +traffic while still maintaining carrier on. + +9. SNMP agents +=============== + + If running SNMP agents, the bonding driver should be loaded +before any network drivers participating in a bond. This requirement +is due to the interface index (ipAdEntIfIndex) being associated to +the first interface found with a given IP address. That is, there is +only one ipAdEntIfIndex for each IP address. For example, if eth0 and +eth1 are slaves of bond0 and the driver for eth0 is loaded before the +bonding driver, the interface for the IP address will be associated +with the eth0 interface. This configuration is shown below, the IP +address 192.168.1.1 has an interface index of 2 which indexes to eth0 +in the ifDescr table (ifDescr.2). + + interfaces.ifTable.ifEntry.ifDescr.1 = lo + interfaces.ifTable.ifEntry.ifDescr.2 = eth0 + interfaces.ifTable.ifEntry.ifDescr.3 = eth1 + interfaces.ifTable.ifEntry.ifDescr.4 = eth2 + interfaces.ifTable.ifEntry.ifDescr.5 = eth3 + interfaces.ifTable.ifEntry.ifDescr.6 = bond0 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 + + This problem is avoided by loading the bonding driver before +any network drivers participating in a bond. Below is an example of +loading the bonding driver first, the IP address 192.168.1.1 is +correctly associated with ifDescr.2. + + interfaces.ifTable.ifEntry.ifDescr.1 = lo + interfaces.ifTable.ifEntry.ifDescr.2 = bond0 + interfaces.ifTable.ifEntry.ifDescr.3 = eth0 + interfaces.ifTable.ifEntry.ifDescr.4 = eth1 + interfaces.ifTable.ifEntry.ifDescr.5 = eth2 + interfaces.ifTable.ifEntry.ifDescr.6 = eth3 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 + + While some distributions may not report the interface name in +ifDescr, the association between the IP address and IfIndex remains +and SNMP functions such as Interface_Scan_Next will report that +association. + +10. Promiscuous mode +==================== + + When running network monitoring tools, e.g., tcpdump, it is +common to enable promiscuous mode on the device, so that all traffic +is seen (instead of seeing only traffic destined for the local host). +The bonding driver handles promiscuous mode changes to the bonding +master device (e.g., bond0), and propagates the setting to the slave +devices. + + For the balance-rr, balance-xor, broadcast, and 802.3ad modes, +the promiscuous mode setting is propagated to all slaves. + + For the active-backup, balance-tlb and balance-alb modes, the +promiscuous mode setting is propagated only to the active slave. + + For balance-tlb mode, the active slave is the slave currently +receiving inbound traffic. + + For balance-alb mode, the active slave is the slave used as a +"primary." This slave is used for mode-specific control traffic, for +sending to peers that are unassigned or if the load is unbalanced. + + For the active-backup, balance-tlb and balance-alb modes, when +the active slave changes (e.g., due to a link failure), the +promiscuous setting will be propagated to the new active slave. + +11. Configuring Bonding for High Availability +============================================= + + High Availability refers to configurations that provide +maximum network availability by having redundant or backup devices, +links or switches between the host and the rest of the world. The +goal is to provide the maximum availability of network connectivity +(i.e., the network always works), even though other configurations +could provide higher throughput. + +11.1 High Availability in a Single Switch Topology +-------------------------------------------------- + + If two hosts (or a host and a single switch) are directly +connected via multiple physical links, then there is no availability +penalty to optimizing for maximum bandwidth. In this case, there is +only one switch (or peer), so if it fails, there is no alternative +access to fail over to. Additionally, the bonding load balance modes +support link monitoring of their members, so if individual links fail, +the load will be rebalanced across the remaining devices. + + See Section 13, "Configuring Bonding for Maximum Throughput" +for information on configuring bonding with one peer device. + +11.2 High Availability in a Multiple Switch Topology +---------------------------------------------------- + + With multiple switches, the configuration of bonding and the +network changes dramatically. In multiple switch topologies, there is +a trade off between network availability and usable bandwidth. + + Below is a sample network, configured to maximize the +availability of the network: + + | | + |port3 port3| + +-----+----+ +-----+----+ + | |port2 ISL port2| | + | switch A +--------------------------+ switch B | + | | | | + +-----+----+ +-----++---+ + |port1 port1| + | +-------+ | + +-------------+ host1 +---------------+ + eth0 +-------+ eth1 + + In this configuration, there is a link between the two +switches (ISL, or inter switch link), and multiple ports connecting to +the outside world ("port3" on each switch). There is no technical +reason that this could not be extended to a third switch. + +11.2.1 HA Bonding Mode Selection for Multiple Switch Topology +------------------------------------------------------------- + + In a topology such as the example above, the active-backup and +broadcast modes are the only useful bonding modes when optimizing for +availability; the other modes require all links to terminate on the +same peer for them to behave rationally. + +active-backup: This is generally the preferred mode, particularly if + the switches have an ISL and play together well. If the + network configuration is such that one switch is specifically + a backup switch (e.g., has lower capacity, higher cost, etc), + then the primary option can be used to insure that the + preferred link is always used when it is available. + +broadcast: This mode is really a special purpose mode, and is suitable + only for very specific needs. For example, if the two + switches are not connected (no ISL), and the networks beyond + them are totally independent. In this case, if it is + necessary for some specific one-way traffic to reach both + independent networks, then the broadcast mode may be suitable. + +11.2.2 HA Link Monitoring Selection for Multiple Switch Topology +---------------------------------------------------------------- + + The choice of link monitoring ultimately depends upon your +switch. If the switch can reliably fail ports in response to other +failures, then either the MII or ARP monitors should work. For +example, in the above example, if the "port3" link fails at the remote +end, the MII monitor has no direct means to detect this. The ARP +monitor could be configured with a target at the remote end of port3, +thus detecting that failure without switch support. + + In general, however, in a multiple switch topology, the ARP +monitor can provide a higher level of reliability in detecting end to +end connectivity failures (which may be caused by the failure of any +individual component to pass traffic for any reason). Additionally, +the ARP monitor should be configured with multiple targets (at least +one for each switch in the network). This will insure that, +regardless of which switch is active, the ARP monitor has a suitable +target to query. + + Note, also, that of late many switches now support a functionality +generally referred to as "trunk failover." This is a feature of the +switch that causes the link state of a particular switch port to be set +down (or up) when the state of another switch port goes down (or up). +Its purpose is to propagate link failures from logically "exterior" ports +to the logically "interior" ports that bonding is able to monitor via +miimon. Availability and configuration for trunk failover varies by +switch, but this can be a viable alternative to the ARP monitor when using +suitable switches. + +12. Configuring Bonding for Maximum Throughput +============================================== + +12.1 Maximizing Throughput in a Single Switch Topology +------------------------------------------------------ + + In a single switch configuration, the best method to maximize +throughput depends upon the application and network environment. The +various load balancing modes each have strengths and weaknesses in +different environments, as detailed below. + + For this discussion, we will break down the topologies into +two categories. Depending upon the destination of most traffic, we +categorize them into either "gatewayed" or "local" configurations. + + In a gatewayed configuration, the "switch" is acting primarily +as a router, and the majority of traffic passes through this router to +other networks. An example would be the following: + + + +----------+ +----------+ + | |eth0 port1| | to other networks + | Host A +---------------------+ router +-------------------> + | +---------------------+ | Hosts B and C are out + | |eth1 port2| | here somewhere + +----------+ +----------+ + + The router may be a dedicated router device, or another host +acting as a gateway. For our discussion, the important point is that +the majority of traffic from Host A will pass through the router to +some other network before reaching its final destination. + + In a gatewayed network configuration, although Host A may +communicate with many other systems, all of its traffic will be sent +and received via one other peer on the local network, the router. + + Note that the case of two systems connected directly via +multiple physical links is, for purposes of configuring bonding, the +same as a gatewayed configuration. In that case, it happens that all +traffic is destined for the "gateway" itself, not some other network +beyond the gateway. + + In a local configuration, the "switch" is acting primarily as +a switch, and the majority of traffic passes through this switch to +reach other stations on the same network. An example would be the +following: + + +----------+ +----------+ +--------+ + | |eth0 port1| +-------+ Host B | + | Host A +------------+ switch |port3 +--------+ + | +------------+ | +--------+ + | |eth1 port2| +------------------+ Host C | + +----------+ +----------+port4 +--------+ + + + Again, the switch may be a dedicated switch device, or another +host acting as a gateway. For our discussion, the important point is +that the majority of traffic from Host A is destined for other hosts +on the same local network (Hosts B and C in the above example). + + In summary, in a gatewayed configuration, traffic to and from +the bonded device will be to the same MAC level peer on the network +(the gateway itself, i.e., the router), regardless of its final +destination. In a local configuration, traffic flows directly to and +from the final destinations, thus, each destination (Host B, Host C) +will be addressed directly by their individual MAC addresses. + + This distinction between a gatewayed and a local network +configuration is important because many of the load balancing modes +available use the MAC addresses of the local network source and +destination to make load balancing decisions. The behavior of each +mode is described below. + + +12.1.1 MT Bonding Mode Selection for Single Switch Topology +----------------------------------------------------------- + + This configuration is the easiest to set up and to understand, +although you will have to decide which bonding mode best suits your +needs. The trade offs for each mode are detailed below: + +balance-rr: This mode is the only mode that will permit a single + TCP/IP connection to stripe traffic across multiple + interfaces. It is therefore the only mode that will allow a + single TCP/IP stream to utilize more than one interface's + worth of throughput. This comes at a cost, however: the + striping generally results in peer systems receiving packets out + of order, causing TCP/IP's congestion control system to kick + in, often by retransmitting segments. + + It is possible to adjust TCP/IP's congestion limits by + altering the net.ipv4.tcp_reordering sysctl parameter. The + usual default value is 3, and the maximum useful value is 127. + For a four interface balance-rr bond, expect that a single + TCP/IP stream will utilize no more than approximately 2.3 + interface's worth of throughput, even after adjusting + tcp_reordering. + + Note that the fraction of packets that will be delivered out of + order is highly variable, and is unlikely to be zero. The level + of reordering depends upon a variety of factors, including the + networking interfaces, the switch, and the topology of the + configuration. Speaking in general terms, higher speed network + cards produce more reordering (due to factors such as packet + coalescing), and a "many to many" topology will reorder at a + higher rate than a "many slow to one fast" configuration. + + Many switches do not support any modes that stripe traffic + (instead choosing a port based upon IP or MAC level addresses); + for those devices, traffic for a particular connection flowing + through the switch to a balance-rr bond will not utilize greater + than one interface's worth of bandwidth. + + If you are utilizing protocols other than TCP/IP, UDP for + example, and your application can tolerate out of order + delivery, then this mode can allow for single stream datagram + performance that scales near linearly as interfaces are added + to the bond. + + This mode requires the switch to have the appropriate ports + configured for "etherchannel" or "trunking." + +active-backup: There is not much advantage in this network topology to + the active-backup mode, as the inactive backup devices are all + connected to the same peer as the primary. In this case, a + load balancing mode (with link monitoring) will provide the + same level of network availability, but with increased + available bandwidth. On the plus side, active-backup mode + does not require any configuration of the switch, so it may + have value if the hardware available does not support any of + the load balance modes. + +balance-xor: This mode will limit traffic such that packets destined + for specific peers will always be sent over the same + interface. Since the destination is determined by the MAC + addresses involved, this mode works best in a "local" network + configuration (as described above), with destinations all on + the same local network. This mode is likely to be suboptimal + if all your traffic is passed through a single router (i.e., a + "gatewayed" network configuration, as described above). + + As with balance-rr, the switch ports need to be configured for + "etherchannel" or "trunking." + +broadcast: Like active-backup, there is not much advantage to this + mode in this type of network topology. + +802.3ad: This mode can be a good choice for this type of network + topology. The 802.3ad mode is an IEEE standard, so all peers + that implement 802.3ad should interoperate well. The 802.3ad + protocol includes automatic configuration of the aggregates, + so minimal manual configuration of the switch is needed + (typically only to designate that some set of devices is + available for 802.3ad). The 802.3ad standard also mandates + that frames be delivered in order (within certain limits), so + in general single connections will not see misordering of + packets. The 802.3ad mode does have some drawbacks: the + standard mandates that all devices in the aggregate operate at + the same speed and duplex. Also, as with all bonding load + balance modes other than balance-rr, no single connection will + be able to utilize more than a single interface's worth of + bandwidth. + + Additionally, the linux bonding 802.3ad implementation + distributes traffic by peer (using an XOR of MAC addresses), + so in a "gatewayed" configuration, all outgoing traffic will + generally use the same device. Incoming traffic may also end + up on a single device, but that is dependent upon the + balancing policy of the peer's 8023.ad implementation. In a + "local" configuration, traffic will be distributed across the + devices in the bond. + + Finally, the 802.3ad mode mandates the use of the MII monitor, + therefore, the ARP monitor is not available in this mode. + +balance-tlb: The balance-tlb mode balances outgoing traffic by peer. + Since the balancing is done according to MAC address, in a + "gatewayed" configuration (as described above), this mode will + send all traffic across a single device. However, in a + "local" network configuration, this mode balances multiple + local network peers across devices in a vaguely intelligent + manner (not a simple XOR as in balance-xor or 802.3ad mode), + so that mathematically unlucky MAC addresses (i.e., ones that + XOR to the same value) will not all "bunch up" on a single + interface. + + Unlike 802.3ad, interfaces may be of differing speeds, and no + special switch configuration is required. On the down side, + in this mode all incoming traffic arrives over a single + interface, this mode requires certain ethtool support in the + network device driver of the slave interfaces, and the ARP + monitor is not available. + +balance-alb: This mode is everything that balance-tlb is, and more. + It has all of the features (and restrictions) of balance-tlb, + and will also balance incoming traffic from local network + peers (as described in the Bonding Module Options section, + above). + + The only additional down side to this mode is that the network + device driver must support changing the hardware address while + the device is open. + +12.1.2 MT Link Monitoring for Single Switch Topology +---------------------------------------------------- + + The choice of link monitoring may largely depend upon which +mode you choose to use. The more advanced load balancing modes do not +support the use of the ARP monitor, and are thus restricted to using +the MII monitor (which does not provide as high a level of end to end +assurance as the ARP monitor). + +12.2 Maximum Throughput in a Multiple Switch Topology +----------------------------------------------------- + + Multiple switches may be utilized to optimize for throughput +when they are configured in parallel as part of an isolated network +between two or more systems, for example: + + +-----------+ + | Host A | + +-+---+---+-+ + | | | + +--------+ | +---------+ + | | | + +------+---+ +-----+----+ +-----+----+ + | Switch A | | Switch B | | Switch C | + +------+---+ +-----+----+ +-----+----+ + | | | + +--------+ | +---------+ + | | | + +-+---+---+-+ + | Host B | + +-----------+ + + In this configuration, the switches are isolated from one +another. One reason to employ a topology such as this is for an +isolated network with many hosts (a cluster configured for high +performance, for example), using multiple smaller switches can be more +cost effective than a single larger switch, e.g., on a network with 24 +hosts, three 24 port switches can be significantly less expensive than +a single 72 port switch. + + If access beyond the network is required, an individual host +can be equipped with an additional network device connected to an +external network; this host then additionally acts as a gateway. + +12.2.1 MT Bonding Mode Selection for Multiple Switch Topology +------------------------------------------------------------- + + In actual practice, the bonding mode typically employed in +configurations of this type is balance-rr. Historically, in this +network configuration, the usual caveats about out of order packet +delivery are mitigated by the use of network adapters that do not do +any kind of packet coalescing (via the use of NAPI, or because the +device itself does not generate interrupts until some number of +packets has arrived). When employed in this fashion, the balance-rr +mode allows individual connections between two hosts to effectively +utilize greater than one interface's bandwidth. + +12.2.2 MT Link Monitoring for Multiple Switch Topology +------------------------------------------------------ + + Again, in actual practice, the MII monitor is most often used +in this configuration, as performance is given preference over +availability. The ARP monitor will function in this topology, but its +advantages over the MII monitor are mitigated by the volume of probes +needed as the number of systems involved grows (remember that each +host in the network is configured with bonding). + +13. Switch Behavior Issues +========================== + +13.1 Link Establishment and Failover Delays +------------------------------------------- + + Some switches exhibit undesirable behavior with regard to the +timing of link up and down reporting by the switch. + + First, when a link comes up, some switches may indicate that +the link is up (carrier available), but not pass traffic over the +interface for some period of time. This delay is typically due to +some type of autonegotiation or routing protocol, but may also occur +during switch initialization (e.g., during recovery after a switch +failure). If you find this to be a problem, specify an appropriate +value to the updelay bonding module option to delay the use of the +relevant interface(s). + + Second, some switches may "bounce" the link state one or more +times while a link is changing state. This occurs most commonly while +the switch is initializing. Again, an appropriate updelay value may +help. + + Note that when a bonding interface has no active links, the +driver will immediately reuse the first link that goes up, even if the +updelay parameter has been specified (the updelay is ignored in this +case). If there are slave interfaces waiting for the updelay timeout +to expire, the interface that first went into that state will be +immediately reused. This reduces down time of the network if the +value of updelay has been overestimated, and since this occurs only in +cases with no connectivity, there is no additional penalty for +ignoring the updelay. + + In addition to the concerns about switch timings, if your +switches take a long time to go into backup mode, it may be desirable +to not activate a backup interface immediately after a link goes down. +Failover may be delayed via the downdelay bonding module option. + +13.2 Duplicated Incoming Packets +-------------------------------- + + NOTE: Starting with version 3.0.2, the bonding driver has logic to +suppress duplicate packets, which should largely eliminate this problem. +The following description is kept for reference. + + It is not uncommon to observe a short burst of duplicated +traffic when the bonding device is first used, or after it has been +idle for some period of time. This is most easily observed by issuing +a "ping" to some other host on the network, and noticing that the +output from ping flags duplicates (typically one per slave). + + For example, on a bond in active-backup mode with five slaves +all connected to one switch, the output may appear as follows: + +# ping -n 10.0.4.2 +PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data. +64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms +64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) +64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) +64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) +64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!) +64 bytes from 10.0.4.2: icmp_seq=2 ttl=64 time=0.216 ms +64 bytes from 10.0.4.2: icmp_seq=3 ttl=64 time=0.267 ms +64 bytes from 10.0.4.2: icmp_seq=4 ttl=64 time=0.222 ms + + This is not due to an error in the bonding driver, rather, it +is a side effect of how many switches update their MAC forwarding +tables. Initially, the switch does not associate the MAC address in +the packet with a particular switch port, and so it may send the +traffic to all ports until its MAC forwarding table is updated. Since +the interfaces attached to the bond may occupy multiple ports on a +single switch, when the switch (temporarily) floods the traffic to all +ports, the bond device receives multiple copies of the same packet +(one per slave device). + + The duplicated packet behavior is switch dependent, some +switches exhibit this, and some do not. On switches that display this +behavior, it can be induced by clearing the MAC forwarding table (on +most Cisco switches, the privileged command "clear mac address-table +dynamic" will accomplish this). + +14. Hardware Specific Considerations +==================================== + + This section contains additional information for configuring +bonding on specific hardware platforms, or for interfacing bonding +with particular switches or other devices. + +14.1 IBM BladeCenter +-------------------- + + This applies to the JS20 and similar systems. + + On the JS20 blades, the bonding driver supports only +balance-rr, active-backup, balance-tlb and balance-alb modes. This is +largely due to the network topology inside the BladeCenter, detailed +below. + +JS20 network adapter information +-------------------------------- + + All JS20s come with two Broadcom Gigabit Ethernet ports +integrated on the planar (that's "motherboard" in IBM-speak). In the +BladeCenter chassis, the eth0 port of all JS20 blades is hard wired to +I/O Module #1; similarly, all eth1 ports are wired to I/O Module #2. +An add-on Broadcom daughter card can be installed on a JS20 to provide +two more Gigabit Ethernet ports. These ports, eth2 and eth3, are +wired to I/O Modules 3 and 4, respectively. + + Each I/O Module may contain either a switch or a passthrough +module (which allows ports to be directly connected to an external +switch). Some bonding modes require a specific BladeCenter internal +network topology in order to function; these are detailed below. + + Additional BladeCenter-specific networking information can be +found in two IBM Redbooks (www.ibm.com/redbooks): + +"IBM eServer BladeCenter Networking Options" +"IBM eServer BladeCenter Layer 2-7 Network Switching" + +BladeCenter networking configuration +------------------------------------ + + Because a BladeCenter can be configured in a very large number +of ways, this discussion will be confined to describing basic +configurations. + + Normally, Ethernet Switch Modules (ESMs) are used in I/O +modules 1 and 2. In this configuration, the eth0 and eth1 ports of a +JS20 will be connected to different internal switches (in the +respective I/O modules). + + A passthrough module (OPM or CPM, optical or copper, +passthrough module) connects the I/O module directly to an external +switch. By using PMs in I/O module #1 and #2, the eth0 and eth1 +interfaces of a JS20 can be redirected to the outside world and +connected to a common external switch. + + Depending upon the mix of ESMs and PMs, the network will +appear to bonding as either a single switch topology (all PMs) or as a +multiple switch topology (one or more ESMs, zero or more PMs). It is +also possible to connect ESMs together, resulting in a configuration +much like the example in "High Availability in a Multiple Switch +Topology," above. + +Requirements for specific modes +------------------------------- + + The balance-rr mode requires the use of passthrough modules +for devices in the bond, all connected to an common external switch. +That switch must be configured for "etherchannel" or "trunking" on the +appropriate ports, as is usual for balance-rr. + + The balance-alb and balance-tlb modes will function with +either switch modules or passthrough modules (or a mix). The only +specific requirement for these modes is that all network interfaces +must be able to reach all destinations for traffic sent over the +bonding device (i.e., the network must converge at some point outside +the BladeCenter). + + The active-backup mode has no additional requirements. + +Link monitoring issues +---------------------- + + When an Ethernet Switch Module is in place, only the ARP +monitor will reliably detect link loss to an external switch. This is +nothing unusual, but examination of the BladeCenter cabinet would +suggest that the "external" network ports are the ethernet ports for +the system, when it fact there is a switch between these "external" +ports and the devices on the JS20 system itself. The MII monitor is +only able to detect link failures between the ESM and the JS20 system. + + When a passthrough module is in place, the MII monitor does +detect failures to the "external" port, which is then directly +connected to the JS20 system. + +Other concerns +-------------- + + The Serial Over LAN (SoL) link is established over the primary +ethernet (eth0) only, therefore, any loss of link to eth0 will result +in losing your SoL connection. It will not fail over with other +network traffic, as the SoL system is beyond the control of the +bonding driver. + + It may be desirable to disable spanning tree on the switch +(either the internal Ethernet Switch Module, or an external switch) to +avoid fail-over delay issues when using bonding. + + +15. Frequently Asked Questions +============================== + +1. Is it SMP safe? + + Yes. The old 2.0.xx channel bonding patch was not SMP safe. +The new driver was designed to be SMP safe from the start. + +2. What type of cards will work with it? + + Any Ethernet type cards (you can even mix cards - a Intel +EtherExpress PRO/100 and a 3com 3c905b, for example). For most modes, +devices need not be of the same speed. + + Starting with version 3.2.1, bonding also supports Infiniband +slaves in active-backup mode. + +3. How many bonding devices can I have? + + There is no limit. + +4. How many slaves can a bonding device have? + + This is limited only by the number of network interfaces Linux +supports and/or the number of network cards you can place in your +system. + +5. What happens when a slave link dies? + + If link monitoring is enabled, then the failing device will be +disabled. The active-backup mode will fail over to a backup link, and +other modes will ignore the failed link. The link will continue to be +monitored, and should it recover, it will rejoin the bond (in whatever +manner is appropriate for the mode). See the sections on High +Availability and the documentation for each mode for additional +information. + + Link monitoring can be enabled via either the miimon or +arp_interval parameters (described in the module parameters section, +above). In general, miimon monitors the carrier state as sensed by +the underlying network device, and the arp monitor (arp_interval) +monitors connectivity to another host on the local network. + + If no link monitoring is configured, the bonding driver will +be unable to detect link failures, and will assume that all links are +always available. This will likely result in lost packets, and a +resulting degradation of performance. The precise performance loss +depends upon the bonding mode and network configuration. + +6. Can bonding be used for High Availability? + + Yes. See the section on High Availability for details. + +7. Which switches/systems does it work with? + + The full answer to this depends upon the desired mode. + + In the basic balance modes (balance-rr and balance-xor), it +works with any system that supports etherchannel (also called +trunking). Most managed switches currently available have such +support, and many unmanaged switches as well. + + The advanced balance modes (balance-tlb and balance-alb) do +not have special switch requirements, but do need device drivers that +support specific features (described in the appropriate section under +module parameters, above). + + In 802.3ad mode, it works with systems that support IEEE +802.3ad Dynamic Link Aggregation. Most managed and many unmanaged +switches currently available support 802.3ad. + + The active-backup mode should work with any Layer-II switch. + +8. Where does a bonding device get its MAC address from? + + When using slave devices that have fixed MAC addresses, or when +the fail_over_mac option is enabled, the bonding device's MAC address is +the MAC address of the active slave. + + For other configurations, if not explicitly configured (with +ifconfig or ip link), the MAC address of the bonding device is taken from +its first slave device. This MAC address is then passed to all following +slaves and remains persistent (even if the first slave is removed) until +the bonding device is brought down or reconfigured. + + If you wish to change the MAC address, you can set it with +ifconfig or ip link: + +# ifconfig bond0 hw ether 00:11:22:33:44:55 + +# ip link set bond0 address 66:77:88:99:aa:bb + + The MAC address can be also changed by bringing down/up the +device and then changing its slaves (or their order): + +# ifconfig bond0 down ; modprobe -r bonding +# ifconfig bond0 .... up +# ifenslave bond0 eth... + + This method will automatically take the address from the next +slave that is added. + + To restore your slaves' MAC addresses, you need to detach them +from the bond (`ifenslave -d bond0 eth0'). The bonding driver will +then restore the MAC addresses that the slaves had before they were +enslaved. + +16. Resources and Links +======================= + +The latest version of the bonding driver can be found in the latest +version of the linux kernel, found on http://kernel.org + +The latest version of this document can be found in either the latest +kernel source (named Documentation/networking/bonding.txt), or on the +bonding sourceforge site: + +http://www.sourceforge.net/projects/bonding + +Discussions regarding the bonding driver take place primarily on the +bonding-devel mailing list, hosted at sourceforge.net. If you have +questions or problems, post them to the list. The list address is: + +bonding-devel@lists.sourceforge.net + + The administrative interface (to subscribe or unsubscribe) can +be found at: + +https://lists.sourceforge.net/lists/listinfo/bonding-devel + +Donald Becker's Ethernet Drivers and diag programs may be found at : + - http://www.scyld.com/network/ + +You will also find a lot of information regarding Ethernet, NWay, MII, +etc. at www.scyld.com. + +-- END -- diff --git a/network/misc/iputils/files/ifenslave/ifenslave.8 b/network/misc/iputils/files/ifenslave/ifenslave.8 new file mode 100644 index 0000000000..89998923e6 --- /dev/null +++ b/network/misc/iputils/files/ifenslave/ifenslave.8 @@ -0,0 +1,68 @@ +.Dd 2004-04-09 +.Dt IFENSLAVE 8 +.\" Manual page created by Guus Sliepen +.Sh NAME +.Nm ifenslave +.Nd Attach and detach slave network devices to a bonding device. +.Sh SYNOPSIS +.Nm +.Op Fl acdfhuvV +.Op Fl -all-interfaces +.Op Fl -change-active +.Op Fl -detach +.Op Fl -force +.Op Fl -help +.Op Fl -usage +.Op Fl -verbose +.Op Fl -version +.Ar master +.Ar slave +.No ... +.Sh DESCRIPTION +.Nm +is a tool to attach and detach slave network devices to a bonding device. +A bonding device will act like a normal Ethernet network device to the kernel, +but will send out the packets via the slave devices using a simple round-robin scheduler. +This allows for simple load-balancing, +identical to "channel bonding" or "trunking" techniques used in switches. +.Pp +The kernel must have support for bonding devices for +.Nm +to be useful. +.Sh OPTIONS +.Bl -tag -width indent +.It Fl a, -all-interfaces +Show information about all interfaces. +.It Fl c, -change-active +Change active slave. +.It Fl d, -detach +Removes slave interfaces from the bonding device. +.It Fl f, -force +Force actions to be taken if one of the specified interfaces appears not to belong to an Ethernet device. +.It Fl h, -help +Display a help message and exit. +.It Fl u, -usage +Show usage information and exit. +.It Fl v, -verbose +Print warning and debug messages. +.It Fl V, -version +Show version information and exit. +.El +If not options are given, the default action will be to enslave interfaces. +.Sh EXAMPLE +The following example shows how to setup a bonding device and +enslave two real Ethernet devices to it: +.Bd -literal +# modprobe bonding +# ifconfig bond0 192.168.0.1 netmask 255.255.0.0 +# ifenslave bond0 eth0 eth1 +.Ed +.Sh AUTHOR +.Nm +was originally written by +.An Donald Becker Aq becker@cesdis.gsfc.nasa.gov , +and has since been updated by various kernel developers. +.Pp +This manual page was written by +.An Guus Sliepen Aq guus@debian.org +for the Debian GNU/Linux system. diff --git a/network/misc/iputils/files/ifenslave/ifenslave.c b/network/misc/iputils/files/ifenslave/ifenslave.c new file mode 100644 index 0000000000..bd375058b7 --- /dev/null +++ b/network/misc/iputils/files/ifenslave/ifenslave.c @@ -0,0 +1,1103 @@ +/* Mode: C; + * ifenslave.c: Configure network interfaces for parallel routing. + * + * This program controls the Linux implementation of running multiple + * network interfaces in parallel. + * + * Author: Donald Becker + * Copyright 1994-1996 Donald Becker + * + * This program is free software; you can redistribute it + * and/or modify it under the terms of the GNU General Public + * License as published by the Free Software Foundation. + * + * The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O + * Center of Excellence in Space Data and Information Sciences + * Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771 + * + * Changes : + * - 2000/10/02 Willy Tarreau : + * - few fixes. Master's MAC address is now correctly taken from + * the first device when not previously set ; + * - detach support : call BOND_RELEASE to detach an enslaved interface. + * - give a mini-howto from command-line help : # ifenslave -h + * + * - 2001/02/16 Chad N. Tindel : + * - Master is now brought down before setting the MAC address. In + * the 2.4 kernel you can't change the MAC address while the device is + * up because you get EBUSY. + * + * - 2001/09/13 Takao Indoh + * - Added the ability to change the active interface on a mode 1 bond + * at runtime. + * + * - 2001/10/23 Chad N. Tindel : + * - No longer set the MAC address of the master. The bond device will + * take care of this itself + * - Try the SIOC*** versions of the bonding ioctls before using the + * old versions + * - 2002/02/18 Erik Habbinga : + * - ifr2.ifr_flags was not initialized in the hwaddr_notset case, + * SIOCGIFFLAGS now called before hwaddr_notset test + * + * - 2002/10/31 Tony Cureington : + * - If the master does not have a hardware address when the first slave + * is enslaved, the master is assigned the hardware address of that + * slave - there is a comment in bonding.c stating "ifenslave takes + * care of this now." This corrects the problem of slaves having + * different hardware addresses in active-backup mode when + * multiple interfaces are specified on a single ifenslave command + * (ifenslave bond0 eth0 eth1). + * + * - 2003/03/18 - Tsippy Mendelson and + * Shmulik Hen + * - Moved setting the slave's mac address and openning it, from + * the application to the driver. This enables support of modes + * that need to use the unique mac address of each slave. + * The driver also takes care of closing the slave and restoring its + * original mac address upon release. + * In addition, block possibility of enslaving before the master is up. + * This prevents putting the system in an undefined state. + * + * - 2003/05/01 - Amir Noam + * - Added ABI version control to restore compatibility between + * new/old ifenslave and new/old bonding. + * - Prevent adding an adapter that is already a slave. + * Fixes the problem of stalling the transmission and leaving + * the slave in a down state. + * + * - 2003/05/01 - Shmulik Hen + * - Prevent enslaving if the bond device is down. + * Fixes the problem of leaving the system in unstable state and + * halting when trying to remove the module. + * - Close socket on all abnormal exists. + * - Add versioning scheme that follows that of the bonding driver. + * current version is 1.0.0 as a base line. + * + * - 2003/05/22 - Jay Vosburgh + * - ifenslave -c was broken; it's now fixed + * - Fixed problem with routes vanishing from master during enslave + * processing. + * + * - 2003/05/27 - Amir Noam + * - Fix backward compatibility issues: + * For drivers not using ABI versions, slave was set down while + * it should be left up before enslaving. + * Also, master was not set down and the default set_mac_address() + * would fail and generate an error message in the system log. + * - For opt_c: slave should not be set to the master's setting + * while it is running. It was already set during enslave. To + * simplify things, it is now handled separately. + * + * - 2003/12/01 - Shmulik Hen + * - Code cleanup and style changes + * set version to 1.1.0 + */ + +#define APP_VERSION "1.1.0" +#define APP_RELDATE "December 1, 2003" +#define APP_NAME "ifenslave" + +static char *version = +APP_NAME ".c:v" APP_VERSION " (" APP_RELDATE ")\n" +"o Donald Becker (becker@cesdis.gsfc.nasa.gov).\n" +"o Detach support added on 2000/10/02 by Willy Tarreau (willy at meta-x.org).\n" +"o 2.4 kernel support added on 2001/02/16 by Chad N. Tindel\n" +" (ctindel at ieee dot org).\n"; + +static const char *usage_msg = +"Usage: ifenslave [-f] [...]\n" +" ifenslave -d [...]\n" +" ifenslave -c \n" +" ifenslave --help\n"; + +static const char *help_msg = +"\n" +" To create a bond device, simply follow these three steps :\n" +" - ensure that the required drivers are properly loaded :\n" +" # modprobe bonding ; modprobe <3c59x|eepro100|pcnet32|tulip|...>\n" +" - assign an IP address to the bond device :\n" +" # ifconfig bond0 netmask broadcast \n" +" - attach all the interfaces you need to the bond device :\n" +" # ifenslave [{-f|--force}] bond0 eth0 [eth1 [eth2]...]\n" +" If bond0 didn't have a MAC address, it will take eth0's. Then, all\n" +" interfaces attached AFTER this assignment will get the same MAC addr.\n" +" (except for ALB/TLB modes)\n" +"\n" +" To set the bond device down and automatically release all the slaves :\n" +" # ifconfig bond0 down\n" +"\n" +" To detach a dead interface without setting the bond device down :\n" +" # ifenslave {-d|--detach} bond0 eth0 [eth1 [eth2]...]\n" +"\n" +" To change active slave :\n" +" # ifenslave {-c|--change-active} bond0 eth0\n" +"\n" +" To show master interface info\n" +" # ifenslave bond0\n" +"\n" +" To show all interfaces info\n" +" # ifenslave {-a|--all-interfaces}\n" +"\n" +" To be more verbose\n" +" # ifenslave {-v|--verbose} ...\n" +"\n" +" # ifenslave {-u|--usage} Show usage\n" +" # ifenslave {-V|--version} Show version\n" +" # ifenslave {-h|--help} This message\n" +"\n"; + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +typedef unsigned long long u64; /* hack, so we may include kernel's ethtool.h */ +typedef __uint32_t u32; /* ditto */ +typedef __uint16_t u16; /* ditto */ +typedef __uint8_t u8; /* ditto */ +#include + +struct option longopts[] = { + /* { name has_arg *flag val } */ + {"all-interfaces", 0, 0, 'a'}, /* Show all interfaces. */ + {"change-active", 0, 0, 'c'}, /* Change the active slave. */ + {"detach", 0, 0, 'd'}, /* Detach a slave interface. */ + {"force", 0, 0, 'f'}, /* Force the operation. */ + {"help", 0, 0, 'h'}, /* Give help */ + {"usage", 0, 0, 'u'}, /* Give usage */ + {"verbose", 0, 0, 'v'}, /* Report each action taken. */ + {"version", 0, 0, 'V'}, /* Emit version information. */ + { 0, 0, 0, 0} +}; + +/* Command-line flags. */ +unsigned int +opt_a = 0, /* Show-all-interfaces flag. */ +opt_c = 0, /* Change-active-slave flag. */ +opt_d = 0, /* Detach a slave interface. */ +opt_f = 0, /* Force the operation. */ +opt_h = 0, /* Help */ +opt_u = 0, /* Usage */ +opt_v = 0, /* Verbose flag. */ +opt_V = 0; /* Version */ + +int skfd = -1; /* AF_INET socket for ioctl() calls.*/ +int abi_ver = 0; /* userland - kernel ABI version */ +int hwaddr_set = 0; /* Master's hwaddr is set */ +int saved_errno; + +struct ifreq master_mtu, master_flags, master_hwaddr; +struct ifreq slave_mtu, slave_flags, slave_hwaddr; + +struct dev_ifr { + struct ifreq *req_ifr; + char *req_name; + int req_type; +}; + +struct dev_ifr master_ifra[] = { + {&master_mtu, "SIOCGIFMTU", SIOCGIFMTU}, + {&master_flags, "SIOCGIFFLAGS", SIOCGIFFLAGS}, + {&master_hwaddr, "SIOCGIFHWADDR", SIOCGIFHWADDR}, + {NULL, "", 0} +}; + +struct dev_ifr slave_ifra[] = { + {&slave_mtu, "SIOCGIFMTU", SIOCGIFMTU}, + {&slave_flags, "SIOCGIFFLAGS", SIOCGIFFLAGS}, + {&slave_hwaddr, "SIOCGIFHWADDR", SIOCGIFHWADDR}, + {NULL, "", 0} +}; + +static void if_print(char *ifname); +static int get_drv_info(char *master_ifname); +static int get_if_settings(char *ifname, struct dev_ifr ifra[]); +static int get_slave_flags(char *slave_ifname); +static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr); +static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr); +static int set_slave_mtu(char *slave_ifname, int mtu); +static int set_if_flags(char *ifname, short flags); +static int set_if_up(char *ifname, short flags); +static int set_if_down(char *ifname, short flags); +static int clear_if_addr(char *ifname); +static int set_if_addr(char *master_ifname, char *slave_ifname); +static int change_active(char *master_ifname, char *slave_ifname); +static int enslave(char *master_ifname, char *slave_ifname); +static int release(char *master_ifname, char *slave_ifname); +#define v_print(fmt, args...) \ + if (opt_v) \ + fprintf(stderr, fmt, ## args ) + +int main(int argc, char *argv[]) +{ + char **spp, *master_ifname, *slave_ifname; + int c, i, rv; + int res = 0; + int exclusive = 0; + + while ((c = getopt_long(argc, argv, "acdfhuvV", longopts, 0)) != EOF) { + switch (c) { + case 'a': opt_a++; exclusive++; break; + case 'c': opt_c++; exclusive++; break; + case 'd': opt_d++; exclusive++; break; + case 'f': opt_f++; exclusive++; break; + case 'h': opt_h++; exclusive++; break; + case 'u': opt_u++; exclusive++; break; + case 'v': opt_v++; break; + case 'V': opt_V++; exclusive++; break; + + case '?': + fprintf(stderr, usage_msg); + res = 2; + goto out; + } + } + + /* options check */ + if (exclusive > 1) { + fprintf(stderr, usage_msg); + res = 2; + goto out; + } + + if (opt_v || opt_V) { + printf(version); + if (opt_V) { + res = 0; + goto out; + } + } + + if (opt_u) { + printf(usage_msg); + res = 0; + goto out; + } + + if (opt_h) { + printf(usage_msg); + printf(help_msg); + res = 0; + goto out; + } + + /* Open a basic socket */ + if ((skfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { + perror("socket"); + res = 1; + goto out; + } + + if (opt_a) { + if (optind == argc) { + /* No remaining args */ + /* show all interfaces */ + if_print((char *)NULL); + goto out; + } else { + /* Just show usage */ + fprintf(stderr, usage_msg); + res = 2; + goto out; + } + } + + /* Copy the interface name */ + spp = argv + optind; + master_ifname = *spp++; + + if (master_ifname == NULL) { + fprintf(stderr, usage_msg); + res = 2; + goto out; + } + + /* exchange abi version with bonding module */ + res = get_drv_info(master_ifname); + if (res) { + fprintf(stderr, + "Master '%s': Error: handshake with driver failed. " + "Aborting\n", + master_ifname); + goto out; + } + + slave_ifname = *spp++; + + if (slave_ifname == NULL) { + if (opt_d || opt_c) { + fprintf(stderr, usage_msg); + res = 2; + goto out; + } + + /* A single arg means show the + * configuration for this interface + */ + if_print(master_ifname); + goto out; + } + + res = get_if_settings(master_ifname, master_ifra); + if (res) { + /* Probably a good reason not to go on */ + fprintf(stderr, + "Master '%s': Error: get settings failed: %s. " + "Aborting\n", + master_ifname, strerror(res)); + goto out; + } + + /* check if master is indeed a master; + * if not then fail any operation + */ + if (!(master_flags.ifr_flags & IFF_MASTER)) { + fprintf(stderr, + "Illegal operation; the specified interface '%s' " + "is not a master. Aborting\n", + master_ifname); + res = 1; + goto out; + } + + /* check if master is up; if not then fail any operation */ + if (!(master_flags.ifr_flags & IFF_UP)) { + fprintf(stderr, + "Illegal operation; the specified master interface " + "'%s' is not up.\n", + master_ifname); + res = 1; + goto out; + } + + /* Only for enslaving */ + if (!opt_c && !opt_d) { + sa_family_t master_family = master_hwaddr.ifr_hwaddr.sa_family; + unsigned char *hwaddr = + (unsigned char *)master_hwaddr.ifr_hwaddr.sa_data; + + /* The family '1' is ARPHRD_ETHER for ethernet. */ + if (master_family != 1 && !opt_f) { + fprintf(stderr, + "Illegal operation: The specified master " + "interface '%s' is not ethernet-like.\n " + "This program is designed to work with " + "ethernet-like network interfaces.\n " + "Use the '-f' option to force the " + "operation.\n", + master_ifname); + res = 1; + goto out; + } + + /* Check master's hw addr */ + for (i = 0; i < 6; i++) { + if (hwaddr[i] != 0) { + hwaddr_set = 1; + break; + } + } + + if (hwaddr_set) { + v_print("current hardware address of master '%s' " + "is %2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, " + "type %d\n", + master_ifname, + hwaddr[0], hwaddr[1], + hwaddr[2], hwaddr[3], + hwaddr[4], hwaddr[5], + master_family); + } + } + + /* Accepts only one slave */ + if (opt_c) { + /* change active slave */ + res = get_slave_flags(slave_ifname); + if (res) { + fprintf(stderr, + "Slave '%s': Error: get flags failed. " + "Aborting\n", + slave_ifname); + goto out; + } + res = change_active(master_ifname, slave_ifname); + if (res) { + fprintf(stderr, + "Master '%s', Slave '%s': Error: " + "Change active failed\n", + master_ifname, slave_ifname); + } + } else { + /* Accept multiple slaves */ + do { + if (opt_d) { + /* detach a slave interface from the master */ + rv = get_slave_flags(slave_ifname); + if (rv) { + /* Can't work with this slave. */ + /* remember the error and skip it*/ + fprintf(stderr, + "Slave '%s': Error: get flags " + "failed. Skipping\n", + slave_ifname); + res = rv; + continue; + } + rv = release(master_ifname, slave_ifname); + if (rv) { + fprintf(stderr, + "Master '%s', Slave '%s': Error: " + "Release failed\n", + master_ifname, slave_ifname); + res = rv; + } + } else { + /* attach a slave interface to the master */ + rv = get_if_settings(slave_ifname, slave_ifra); + if (rv) { + /* Can't work with this slave. */ + /* remember the error and skip it*/ + fprintf(stderr, + "Slave '%s': Error: get " + "settings failed: %s. " + "Skipping\n", + slave_ifname, strerror(rv)); + res = rv; + continue; + } + rv = enslave(master_ifname, slave_ifname); + if (rv) { + fprintf(stderr, + "Master '%s', Slave '%s': Error: " + "Enslave failed\n", + master_ifname, slave_ifname); + res = rv; + } + } + } while ((slave_ifname = *spp++) != NULL); + } + +out: + if (skfd >= 0) { + close(skfd); + } + + return res; +} + +static short mif_flags; + +/* Get the inteface configuration from the kernel. */ +static int if_getconfig(char *ifname) +{ + struct ifreq ifr; + int metric, mtu; /* Parameters of the master interface. */ + struct sockaddr dstaddr, broadaddr, netmask; + unsigned char *hwaddr; + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFFLAGS, &ifr) < 0) + return -1; + mif_flags = ifr.ifr_flags; + printf("The result of SIOCGIFFLAGS on %s is %x.\n", + ifname, ifr.ifr_flags); + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFADDR, &ifr) < 0) + return -1; + printf("The result of SIOCGIFADDR is %2.2x.%2.2x.%2.2x.%2.2x.\n", + ifr.ifr_addr.sa_data[2], ifr.ifr_addr.sa_data[3], + ifr.ifr_addr.sa_data[4], ifr.ifr_addr.sa_data[5]); + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFHWADDR, &ifr) < 0) + return -1; + + /* Gotta convert from 'char' to unsigned for printf(). */ + hwaddr = (unsigned char *)ifr.ifr_hwaddr.sa_data; + printf("The result of SIOCGIFHWADDR is type %d " + "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n", + ifr.ifr_hwaddr.sa_family, hwaddr[0], hwaddr[1], + hwaddr[2], hwaddr[3], hwaddr[4], hwaddr[5]); + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFMETRIC, &ifr) < 0) { + metric = 0; + } else + metric = ifr.ifr_metric; + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFMTU, &ifr) < 0) + mtu = 0; + else + mtu = ifr.ifr_mtu; + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFDSTADDR, &ifr) < 0) { + memset(&dstaddr, 0, sizeof(struct sockaddr)); + } else + dstaddr = ifr.ifr_dstaddr; + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFBRDADDR, &ifr) < 0) { + memset(&broadaddr, 0, sizeof(struct sockaddr)); + } else + broadaddr = ifr.ifr_broadaddr; + + strcpy(ifr.ifr_name, ifname); + if (ioctl(skfd, SIOCGIFNETMASK, &ifr) < 0) { + memset(&netmask, 0, sizeof(struct sockaddr)); + } else + netmask = ifr.ifr_netmask; + + return 0; +} + +static void if_print(char *ifname) +{ + char buff[1024]; + struct ifconf ifc; + struct ifreq *ifr; + int i; + + if (ifname == (char *)NULL) { + ifc.ifc_len = sizeof(buff); + ifc.ifc_buf = buff; + if (ioctl(skfd, SIOCGIFCONF, &ifc) < 0) { + perror("SIOCGIFCONF failed"); + return; + } + + ifr = ifc.ifc_req; + for (i = ifc.ifc_len / sizeof(struct ifreq); --i >= 0; ifr++) { + if (if_getconfig(ifr->ifr_name) < 0) { + fprintf(stderr, + "%s: unknown interface.\n", + ifr->ifr_name); + continue; + } + + if (((mif_flags & IFF_UP) == 0) && !opt_a) continue; + /*ife_print(&ife);*/ + } + } else { + if (if_getconfig(ifname) < 0) { + fprintf(stderr, + "%s: unknown interface.\n", ifname); + } + } +} + +static int get_drv_info(char *master_ifname) +{ + struct ifreq ifr; + struct ethtool_drvinfo info; + char *endptr; + + memset(&ifr, 0, sizeof(ifr)); + strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); + ifr.ifr_data = (caddr_t)&info; + + info.cmd = ETHTOOL_GDRVINFO; + strncpy(info.driver, "ifenslave", 32); + snprintf(info.fw_version, 32, "%d", BOND_ABI_VERSION); + + if (ioctl(skfd, SIOCETHTOOL, &ifr) < 0) { + if (errno == EOPNOTSUPP) { + goto out; + } + + saved_errno = errno; + v_print("Master '%s': Error: get bonding info failed %s\n", + master_ifname, strerror(saved_errno)); + return 1; + } + + abi_ver = strtoul(info.fw_version, &endptr, 0); + if (*endptr) { + v_print("Master '%s': Error: got invalid string as an ABI " + "version from the bonding module\n", + master_ifname); + return 1; + } + +out: + v_print("ABI ver is %d\n", abi_ver); + + return 0; +} + +static int change_active(char *master_ifname, char *slave_ifname) +{ + struct ifreq ifr; + int res = 0; + + if (!(slave_flags.ifr_flags & IFF_SLAVE)) { + fprintf(stderr, + "Illegal operation: The specified slave interface " + "'%s' is not a slave\n", + slave_ifname); + return 1; + } + + strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); + strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ); + if ((ioctl(skfd, SIOCBONDCHANGEACTIVE, &ifr) < 0) && + (ioctl(skfd, BOND_CHANGE_ACTIVE_OLD, &ifr) < 0)) { + saved_errno = errno; + v_print("Master '%s': Error: SIOCBONDCHANGEACTIVE failed: " + "%s\n", + master_ifname, strerror(saved_errno)); + res = 1; + } + + return res; +} + +static int enslave(char *master_ifname, char *slave_ifname) +{ + struct ifreq ifr; + int res = 0; + + if (slave_flags.ifr_flags & IFF_SLAVE) { + fprintf(stderr, + "Illegal operation: The specified slave interface " + "'%s' is already a slave\n", + slave_ifname); + return 1; + } + + res = set_if_down(slave_ifname, slave_flags.ifr_flags); + if (res) { + fprintf(stderr, + "Slave '%s': Error: bring interface down failed\n", + slave_ifname); + return res; + } + + if (abi_ver < 2) { + /* Older bonding versions would panic if the slave has no IP + * address, so get the IP setting from the master. + */ + set_if_addr(master_ifname, slave_ifname); + } else { + res = clear_if_addr(slave_ifname); + if (res) { + fprintf(stderr, + "Slave '%s': Error: clear address failed\n", + slave_ifname); + return res; + } + } + + if (master_mtu.ifr_mtu != slave_mtu.ifr_mtu) { + res = set_slave_mtu(slave_ifname, master_mtu.ifr_mtu); + if (res) { + fprintf(stderr, + "Slave '%s': Error: set MTU failed\n", + slave_ifname); + return res; + } + } + + if (hwaddr_set) { + /* Master already has an hwaddr + * so set it's hwaddr to the slave + */ + if (abi_ver < 1) { + /* The driver is using an old ABI, so + * the application sets the slave's + * hwaddr + */ + res = set_slave_hwaddr(slave_ifname, + &(master_hwaddr.ifr_hwaddr)); + if (res) { + fprintf(stderr, + "Slave '%s': Error: set hw address " + "failed\n", + slave_ifname); + goto undo_mtu; + } + + /* For old ABI the application needs to bring the + * slave back up + */ + res = set_if_up(slave_ifname, slave_flags.ifr_flags); + if (res) { + fprintf(stderr, + "Slave '%s': Error: bring interface " + "down failed\n", + slave_ifname); + goto undo_slave_mac; + } + } + /* The driver is using a new ABI, + * so the driver takes care of setting + * the slave's hwaddr and bringing + * it up again + */ + } else { + /* No hwaddr for master yet, so + * set the slave's hwaddr to it + */ + if (abi_ver < 1) { + /* For old ABI, the master needs to be + * down before setting it's hwaddr + */ + res = set_if_down(master_ifname, master_flags.ifr_flags); + if (res) { + fprintf(stderr, + "Master '%s': Error: bring interface " + "down failed\n", + master_ifname); + goto undo_mtu; + } + } + + res = set_master_hwaddr(master_ifname, + &(slave_hwaddr.ifr_hwaddr)); + if (res) { + fprintf(stderr, + "Master '%s': Error: set hw address " + "failed\n", + master_ifname); + goto undo_mtu; + } + + if (abi_ver < 1) { + /* For old ABI, bring the master + * back up + */ + res = set_if_up(master_ifname, master_flags.ifr_flags); + if (res) { + fprintf(stderr, + "Master '%s': Error: bring interface " + "up failed\n", + master_ifname); + goto undo_master_mac; + } + } + + hwaddr_set = 1; + } + + /* Do the real thing */ + strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); + strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ); + if ((ioctl(skfd, SIOCBONDENSLAVE, &ifr) < 0) && + (ioctl(skfd, BOND_ENSLAVE_OLD, &ifr) < 0)) { + saved_errno = errno; + v_print("Master '%s': Error: SIOCBONDENSLAVE failed: %s\n", + master_ifname, strerror(saved_errno)); + res = 1; + } + + if (res) { + goto undo_master_mac; + } + + return 0; + +/* rollback (best effort) */ +undo_master_mac: + set_master_hwaddr(master_ifname, &(master_hwaddr.ifr_hwaddr)); + hwaddr_set = 0; + goto undo_mtu; +undo_slave_mac: + set_slave_hwaddr(slave_ifname, &(slave_hwaddr.ifr_hwaddr)); +undo_mtu: + set_slave_mtu(slave_ifname, slave_mtu.ifr_mtu); + return res; +} + +static int release(char *master_ifname, char *slave_ifname) +{ + struct ifreq ifr; + int res = 0; + + if (!(slave_flags.ifr_flags & IFF_SLAVE)) { + fprintf(stderr, + "Illegal operation: The specified slave interface " + "'%s' is not a slave\n", + slave_ifname); + return 1; + } + + strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); + strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ); + if ((ioctl(skfd, SIOCBONDRELEASE, &ifr) < 0) && + (ioctl(skfd, BOND_RELEASE_OLD, &ifr) < 0)) { + saved_errno = errno; + v_print("Master '%s': Error: SIOCBONDRELEASE failed: %s\n", + master_ifname, strerror(saved_errno)); + return 1; + } else if (abi_ver < 1) { + /* The driver is using an old ABI, so we'll set the interface + * down to avoid any conflicts due to same MAC/IP + */ + res = set_if_down(slave_ifname, slave_flags.ifr_flags); + if (res) { + fprintf(stderr, + "Slave '%s': Error: bring interface " + "down failed\n", + slave_ifname); + } + } + + /* set to default mtu */ + set_slave_mtu(slave_ifname, 1500); + + return res; +} + +static int get_if_settings(char *ifname, struct dev_ifr ifra[]) +{ + int i; + int res = 0; + + for (i = 0; ifra[i].req_ifr; i++) { + strncpy(ifra[i].req_ifr->ifr_name, ifname, IFNAMSIZ); + res = ioctl(skfd, ifra[i].req_type, ifra[i].req_ifr); + if (res < 0) { + saved_errno = errno; + v_print("Interface '%s': Error: %s failed: %s\n", + ifname, ifra[i].req_name, + strerror(saved_errno)); + + return saved_errno; + } + } + + return 0; +} + +static int get_slave_flags(char *slave_ifname) +{ + int res = 0; + + strncpy(slave_flags.ifr_name, slave_ifname, IFNAMSIZ); + res = ioctl(skfd, SIOCGIFFLAGS, &slave_flags); + if (res < 0) { + saved_errno = errno; + v_print("Slave '%s': Error: SIOCGIFFLAGS failed: %s\n", + slave_ifname, strerror(saved_errno)); + } else { + v_print("Slave %s: flags %04X.\n", + slave_ifname, slave_flags.ifr_flags); + } + + return res; +} + +static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr) +{ + unsigned char *addr = (unsigned char *)hwaddr->sa_data; + struct ifreq ifr; + int res = 0; + + strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); + memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr)); + res = ioctl(skfd, SIOCSIFHWADDR, &ifr); + if (res < 0) { + saved_errno = errno; + v_print("Master '%s': Error: SIOCSIFHWADDR failed: %s\n", + master_ifname, strerror(saved_errno)); + return res; + } else { + v_print("Master '%s': hardware address set to " + "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n", + master_ifname, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + } + + return res; +} + +static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr) +{ + unsigned char *addr = (unsigned char *)hwaddr->sa_data; + struct ifreq ifr; + int res = 0; + + strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ); + memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr)); + res = ioctl(skfd, SIOCSIFHWADDR, &ifr); + if (res < 0) { + saved_errno = errno; + + v_print("Slave '%s': Error: SIOCSIFHWADDR failed: %s\n", + slave_ifname, strerror(saved_errno)); + + if (saved_errno == EBUSY) { + v_print(" The device is busy: it must be idle " + "before running this command.\n"); + } else if (saved_errno == EOPNOTSUPP) { + v_print(" The device does not support setting " + "the MAC address.\n" + " Your kernel likely does not support slave " + "devices.\n"); + } else if (saved_errno == EINVAL) { + v_print(" The device's address type does not match " + "the master's address type.\n"); + } + return res; + } else { + v_print("Slave '%s': hardware address set to " + "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n", + slave_ifname, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + } + + return res; +} + +static int set_slave_mtu(char *slave_ifname, int mtu) +{ + struct ifreq ifr; + int res = 0; + + ifr.ifr_mtu = mtu; + strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ); + + res = ioctl(skfd, SIOCSIFMTU, &ifr); + if (res < 0) { + saved_errno = errno; + v_print("Slave '%s': Error: SIOCSIFMTU failed: %s\n", + slave_ifname, strerror(saved_errno)); + } else { + v_print("Slave '%s': MTU set to %d.\n", slave_ifname, mtu); + } + + return res; +} + +static int set_if_flags(char *ifname, short flags) +{ + struct ifreq ifr; + int res = 0; + + ifr.ifr_flags = flags; + strncpy(ifr.ifr_name, ifname, IFNAMSIZ); + + res = ioctl(skfd, SIOCSIFFLAGS, &ifr); + if (res < 0) { + saved_errno = errno; + v_print("Interface '%s': Error: SIOCSIFFLAGS failed: %s\n", + ifname, strerror(saved_errno)); + } else { + v_print("Interface '%s': flags set to %04X.\n", ifname, flags); + } + + return res; +} + +static int set_if_up(char *ifname, short flags) +{ + return set_if_flags(ifname, flags | IFF_UP); +} + +static int set_if_down(char *ifname, short flags) +{ + return set_if_flags(ifname, flags & ~IFF_UP); +} + +static int clear_if_addr(char *ifname) +{ + struct ifreq ifr; + int res = 0; + + strncpy(ifr.ifr_name, ifname, IFNAMSIZ); + ifr.ifr_addr.sa_family = AF_INET; + memset(ifr.ifr_addr.sa_data, 0, sizeof(ifr.ifr_addr.sa_data)); + + res = ioctl(skfd, SIOCSIFADDR, &ifr); + if (res < 0) { + saved_errno = errno; + v_print("Interface '%s': Error: SIOCSIFADDR failed: %s\n", + ifname, strerror(saved_errno)); + } else { + v_print("Interface '%s': address cleared\n", ifname); + } + + return res; +} + +static int set_if_addr(char *master_ifname, char *slave_ifname) +{ + struct ifreq ifr; + int res; + unsigned char *ipaddr; + int i; + struct { + char *req_name; + char *desc; + int g_ioctl; + int s_ioctl; + } ifra[] = { + {"IFADDR", "addr", SIOCGIFADDR, SIOCSIFADDR}, + {"DSTADDR", "destination addr", SIOCGIFDSTADDR, SIOCSIFDSTADDR}, + {"BRDADDR", "broadcast addr", SIOCGIFBRDADDR, SIOCSIFBRDADDR}, + {"NETMASK", "netmask", SIOCGIFNETMASK, SIOCSIFNETMASK}, + {NULL, NULL, 0, 0}, + }; + + for (i = 0; ifra[i].req_name; i++) { + strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); + res = ioctl(skfd, ifra[i].g_ioctl, &ifr); + if (res < 0) { + int saved_errno = errno; + + v_print("Interface '%s': Error: SIOCG%s failed: %s\n", + master_ifname, ifra[i].req_name, + strerror(saved_errno)); + + ifr.ifr_addr.sa_family = AF_INET; + memset(ifr.ifr_addr.sa_data, 0, + sizeof(ifr.ifr_addr.sa_data)); + } + + strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ); + res = ioctl(skfd, ifra[i].s_ioctl, &ifr); + if (res < 0) { + int saved_errno = errno; + + v_print("Interface '%s': Error: SIOCS%s failed: %s\n", + slave_ifname, ifra[i].req_name, + strerror(saved_errno)); + + } + + ipaddr = (unsigned char *)ifr.ifr_addr.sa_data; + v_print("Interface '%s': set IP %s to %d.%d.%d.%d\n", + slave_ifname, ifra[i].desc, + ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]); + } + + return 0; +} + +/* + * Local variables: + * version-control: t + * kept-new-versions: 5 + * c-indent-level: 4 + * c-basic-offset: 4 + * tab-width: 4 + * compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave" + * End: + */ + diff --git a/network/misc/iputils/files/iputils-20071127-kernel-ifaddr.patch b/network/misc/iputils/files/iputils-20071127-kernel-ifaddr.patch new file mode 100644 index 0000000000..9c13f7e1a0 --- /dev/null +++ b/network/misc/iputils/files/iputils-20071127-kernel-ifaddr.patch @@ -0,0 +1,55 @@ +--- a/rarpd.c ++++ b/rarpd.c +@@ -55,10 +55,10 @@ struct iflink + unsigned char lladdr[16]; + char name[IFNAMSIZ]; +- struct ifaddr *ifa_list; ++ struct kern_ifaddr *ifa_list; + } *ifl_list; + +-struct ifaddr ++struct kern_ifaddr + { +- struct ifaddr *next; ++ struct kern_ifaddr *next; + __u32 prefix; + __u32 mask; +@@ -92,5 +92,5 @@ void load_if(void) + struct ifreq *ifrp, *ifend; + struct iflink *ifl; +- struct ifaddr *ifa; ++ struct kern_ifaddr *ifa; + struct ifconf ifc; + struct ifreq ibuf[256]; +@@ -183,5 +183,5 @@ void load_if(void) + if (mask == 0 || prefix == 0) + continue; +- ifa = (struct ifaddr*)malloc(sizeof(*ifa)); ++ ifa = (struct kern_ifaddr*)malloc(sizeof(*ifa)); + memset(ifa, 0, sizeof(*ifa)); + ifa->local = addr; +@@ -239,8 +239,8 @@ int bootable(__u32 addr) + } + +-struct ifaddr *select_ipaddr(int ifindex, __u32 *sel_addr, __u32 **alist) ++struct kern_ifaddr *select_ipaddr(int ifindex, __u32 *sel_addr, __u32 **alist) + { + struct iflink *ifl; +- struct ifaddr *ifa; ++ struct kern_ifaddr *ifa; + int retry = 0; + int i; +@@ -298,5 +298,5 @@ struct rarp_map *rarp_lookup(int ifindex + if (r == NULL) { + if (hatype == ARPHRD_ETHER && halen == 6) { +- struct ifaddr *ifa; ++ struct kern_ifaddr *ifa; + struct hostent *hp; + char ename[256]; +@@ -371,5 +371,5 @@ int put_myipaddr(unsigned char **ptr_p, + __u32 laddr = 0; + struct iflink *ifl; +- struct ifaddr *ifa; ++ struct kern_ifaddr *ifa; + + for (ifl=ifl_list; ifl; ifl = ifl->next) diff --git a/network/misc/iputils/files/iputils-20071127-nonroot-floodping.patch b/network/misc/iputils/files/iputils-20071127-nonroot-floodping.patch new file mode 100644 index 0000000000..cae87791dc --- /dev/null +++ b/network/misc/iputils/files/iputils-20071127-nonroot-floodping.patch @@ -0,0 +1,11 @@ +--- iputils-s20071127/ping_common.h.orig 2008-06-10 11:16:06.000000000 +0100 ++++ iputils-s20071127/ping_common.h 2008-06-10 11:16:18.000000000 +0100 +@@ -28,7 +28,7 @@ + + #define MAXWAIT 10 /* max seconds to wait for response */ + #define MININTERVAL 10 /* Minimal interpacket gap */ +-#define MINUSERINTERVAL 200 /* Minimal allowed interval for non-root */ ++#define MINUSERINTERVAL 0 /* Minimal allowed interval for non-root */ + + #define SCHINT(a) (((a) <= MININTERVAL) ? MININTERVAL : (a)) + diff --git a/network/misc/iputils/files/iputils-20100418-so_mark.patch b/network/misc/iputils/files/iputils-20100418-so_mark.patch new file mode 100644 index 0000000000..0d7c7860e8 --- /dev/null +++ b/network/misc/iputils/files/iputils-20100418-so_mark.patch @@ -0,0 +1,22 @@ +https://bugs.gentoo.org/335347 + +fix building with older linux headers that don't define SO_MARK + +--- ping_common.c.org ++++ ping_common.c +@@ -485,6 +485,7 @@ + fprintf(stderr, "Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP\n"); + } + #endif ++#ifdef SO_MARK + if (options & F_MARK) { + if (setsockopt(icmp_sock, SOL_SOCKET, SO_MARK, + &mark, sizeof(mark)) == -1) { +@@ -494,6 +495,7 @@ + fprintf(stderr, "Warning: Failed to set mark %d\n", mark); + } + } ++#endif + + /* Set some SNDTIMEO to prevent blocking forever + * on sends, when device is too slow or stalls. Just put limit diff --git a/network/misc/iputils/files/iputils-20121221-crypto-build.patch b/network/misc/iputils/files/iputils-20121221-crypto-build.patch new file mode 100644 index 0000000000..1ec3c101d5 --- /dev/null +++ b/network/misc/iputils/files/iputils-20121221-crypto-build.patch @@ -0,0 +1,35 @@ +From 568e990d30fc7e9416e0a6f8c74ea5013921eaec Mon Sep 17 00:00:00 2001 +From: Arjan van de Ven +Date: Wed, 16 Jan 2013 03:12:15 +0900 +Subject: [PATCH [iputils]] ping6: Fix build command line argument with gnutls. + +The ping6 command can use either openssl or gnutls... +and the Makefile has a bunch of setup for defining which of the two to use. + +Unfortunately, the final -D define on the commandline to enable gnutls +inside the ping6.c file didn't actually make it onto the gcc +commandline. +This patch adds the $(DEF_CRYPTO) Makefile variable to fix this gap. + +Signed-off-by: Arjan van de Ven +Signed-off-by: YOSHIFUJI Hideaki +--- + Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/Makefile b/Makefile +index c62d9df..89249f5 100644 +--- a/Makefile ++++ b/Makefile +@@ -149,7 +149,7 @@ LIB_clockdiff = $(LIB_CAP) + DEF_ping_common = $(DEF_CAP) $(DEF_IDN) + DEF_ping = $(DEF_CAP) $(DEF_IDN) $(DEF_WITHOUT_IFADDRS) + LIB_ping = $(LIB_CAP) $(LIB_IDN) +-DEF_ping6 = $(DEF_CAP) $(DEF_IDN) $(DEF_WITHOUT_IFADDRS) $(DEF_ENABLE_PING6_RTHDR) ++DEF_ping6 = $(DEF_CAP) $(DEF_IDN) $(DEF_WITHOUT_IFADDRS) $(DEF_ENABLE_PING6_RTHDR) $(DEF_CRYPTO) + LIB_ping6 = $(LIB_CAP) $(LIB_IDN) $(LIB_RESOLV) $(LIB_CRYPTO) + + ping: ping_common.o +-- +1.8.0.2 + diff --git a/network/misc/iputils/files/iputils-20121221-makefile.patch b/network/misc/iputils/files/iputils-20121221-makefile.patch new file mode 100644 index 0000000000..66424c85cf --- /dev/null +++ b/network/misc/iputils/files/iputils-20121221-makefile.patch @@ -0,0 +1,61 @@ +From c66609d2c830d6fe06f48f5d38c54eb5cc6f2975 Mon Sep 17 00:00:00 2001 +From: Mike Frysinger +Date: Thu, 24 Jan 2013 23:36:16 -0500 +Subject: [PATCH [iputils]] fix handling of CFLAGS + +This defaults CFLAGS to -O3 without clobbering settings people have set +up in the environment already. + +Signed-off-by: Mike Frysinger +--- + Makefile | 13 +++++-------- + 1 file changed, 5 insertions(+), 8 deletions(-) + +diff --git a/Makefile b/Makefile +index 2c49940..ecabac3 100644 +--- a/Makefile ++++ b/Makefile +@@ -2,8 +2,6 @@ + # Configuration + # + +-# CC +-CC=gcc + # Path to parent kernel include files directory + LIBC_INCLUDE=/usr/include + # Libraries +@@ -48,11 +46,10 @@ ENABLE_RDISC_SERVER=no + + # ------------------------------------- + # What a pity, all new gccs are buggy and -Werror does not work. Sigh. +-# CCOPT=-fno-strict-aliasing -Wstrict-prototypes -Wall -Werror -g +-CCOPT=-fno-strict-aliasing -Wstrict-prototypes -Wall -g +-CCOPTOPT=-O3 +-GLIBCFIX=-D_GNU_SOURCE +-DEFINES= ++# CFLAGS+=-fno-strict-aliasing -Wstrict-prototypes -Wall -Werror -g ++CFLAGS?=-O3 -g ++CFLAGS+=-fno-strict-aliasing -Wstrict-prototypes -Wall ++CPPFLAGS+=-D_GNU_SOURCE + LDLIB= + + FUNC_LIB = $(if $(filter static,$(1)),$(LDFLAG_STATIC) $(2) $(LDFLAG_DYNAMIC),$(2)) +@@ -113,7 +110,6 @@ IPV4_TARGETS=tracepath ping clockdiff rdisc arping tftpd rarpd + IPV6_TARGETS=tracepath6 traceroute6 ping6 + TARGETS=$(IPV4_TARGETS) $(IPV6_TARGETS) + +-CFLAGS=$(CCOPTOPT) $(CCOPT) $(GLIBCFIX) $(DEFINES) + LDLIBS=$(LDLIB) $(ADDLIB) + + UNAME_N:=$(shell uname -n) +@@ -132,6 +128,7 @@ all: $(TARGETS) + $(COMPILE.c) $< $(DEF_$(patsubst %.o,%,$@)) -S -o $@ + %.o: %.c + $(COMPILE.c) $< $(DEF_$(patsubst %.o,%,$@)) -o $@ ++LINK.o += $(CFLAGS) + $(TARGETS): %: %.o + $(LINK.o) $^ $(LIB_$@) $(LDLIBS) -o $@ + +-- +1.8.0.2 + diff --git a/network/misc/iputils/files/iputils-20121221-openssl.patch b/network/misc/iputils/files/iputils-20121221-openssl.patch new file mode 100644 index 0000000000..1c6ba81dab --- /dev/null +++ b/network/misc/iputils/files/iputils-20121221-openssl.patch @@ -0,0 +1,92 @@ +From b57d77dcfa5cb363b7eba5b331324669a8505ac4 Mon Sep 17 00:00:00 2001 +From: Mike Frysinger +Date: Thu, 24 Jan 2013 23:32:39 -0500 +Subject: [PATCH [iputils]] ping6: allow disabling of openssl support + +Signed-off-by: Mike Frysinger +--- + Makefile | 5 ++++- + ping6.c | 14 +++++++++++++- + 2 files changed, 17 insertions(+), 2 deletions(-) + +diff --git a/Makefile b/Makefile +index 89249f5..2c49940 100644 +--- a/Makefile ++++ b/Makefile +@@ -36,7 +36,7 @@ ARPING_DEFAULT_DEVICE= + + # GNU TLS library for ping6 [yes|no|static] + USE_GNUTLS=yes +-# Crypto library for ping6 [shared|static] ++# Crypto library for ping6 [shared|static|no] + USE_CRYPTO=shared + # Resolv library for ping6 [yes|static] + USE_RESOLV=yes +@@ -63,7 +63,10 @@ ifneq ($(USE_GNUTLS),no) + LIB_CRYPTO = $(call FUNC_LIB,$(USE_GNUTLS),$(LDFLAG_GNUTLS)) + DEF_CRYPTO = -DUSE_GNUTLS + else ++ifneq ($(USE_CRYPTO),no) + LIB_CRYPTO = $(call FUNC_LIB,$(USE_CRYPTO),$(LDFLAG_CRYPTO)) ++ DEF_CRYPTO = -DUSE_OPENSSL ++endif + endif + + # USE_RESOLV: LIB_RESOLV +diff --git a/ping6.c b/ping6.c +index c39864d..f2f90af 100644 +--- a/ping6.c ++++ b/ping6.c +@@ -168,8 +168,10 @@ static int icmp_sock; + + #ifdef USE_GNUTLS + # include +-#else ++# define USE_CRYPTO ++#elif defined USE_OPENSSL + # include ++# define USE_CRYPTO + #endif + + /* Node Information query */ +@@ -326,6 +328,7 @@ static void niquery_init_nonce(void) + #if !PING6_NONCE_MEMORY + static int niquery_nonce(__u8 *nonce, int fill) + { ++# ifdef USE_CRYPTO + static __u8 digest[MD5_DIGEST_LENGTH]; + static int seq = -1; + +@@ -348,6 +351,10 @@ static int niquery_nonce(__u8 *nonce, int fill) + return -1; + return ntohsp((__u16 *)nonce); + } ++# else ++ fprintf(stderr, "ping6: function not available; crypto disabled\n"); ++ exit(3); ++# endif + } + #endif + +@@ -502,6 +509,7 @@ static int niquery_option_subject_addr_handler(int index, const char *arg) + + static int niquery_option_subject_name_handler(int index, const char *arg) + { ++#ifdef USE_CRYPTO + static char nigroup_buf[INET6_ADDRSTRLEN + 1 + IFNAMSIZ]; + unsigned char *dnptrs[2], **dpp, **lastdnptr; + int n; +@@ -627,6 +635,10 @@ errexit: + free(idn); + free(name); + exit(1); ++#else ++ fprintf(stderr, "ping6: function not available; crypto disabled\n"); ++ exit(3); ++#endif + } + + int niquery_option_help_handler(int index, const char *arg) +-- +1.8.0.2 + diff --git a/network/misc/iputils/files/iputils-20121221-owl-pingsock.diff b/network/misc/iputils/files/iputils-20121221-owl-pingsock.diff new file mode 100644 index 0000000000..283aa989f3 --- /dev/null +++ b/network/misc/iputils/files/iputils-20121221-owl-pingsock.diff @@ -0,0 +1,224 @@ +http://openwall.info/wiki/people/segoon/ping + +--- iputils-s20101006/ping.c ++++ iputils-s20101006/ping.c +@@ -88,6 +88,7 @@ struct sockaddr_in whereto; /* who to pi + int optlen = 0; + int settos = 0; /* Set TOS, Precendence or other QOS options */ + int icmp_sock; /* socket file descriptor */ ++int using_ping_socket = 0; + u_char outpack[0x10000]; + int maxpacket = sizeof(outpack); + +@@ -123,7 +124,11 @@ main(int argc, char **argv) + char *target, hnamebuf[MAX_HOSTNAMELEN]; + char rspace[3 + 4 * NROUTES + 1]; /* record route space */ + +- icmp_sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); ++ icmp_sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP); ++ if (icmp_sock != -1) ++ using_ping_socket = 1; ++ else ++ icmp_sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); + socket_errno = errno; + + uid = getuid(); +@@ -377,13 +382,35 @@ main(int argc, char **argv) + } + } + +- if ((options&F_STRICTSOURCE) && +- bind(icmp_sock, (struct sockaddr*)&source, sizeof(source)) == -1) { +- perror("bind"); +- exit(2); ++ if (!using_ping_socket) { ++ if ((options&F_STRICTSOURCE) && ++ bind(icmp_sock, (struct sockaddr*)&source, sizeof(source)) == -1) { ++ perror("bind"); ++ exit(2); ++ } ++ } else { ++ struct sockaddr_in sa; ++ socklen_t sl; ++ ++ sa.sin_family = AF_INET; ++ sa.sin_port = 0; ++ sa.sin_addr.s_addr = (options&F_STRICTSOURCE) ? ++ source.sin_addr.s_addr : 0; ++ sl = sizeof(sa); ++ ++ if (bind(icmp_sock, (struct sockaddr *) &sa, sl) == -1) { ++ perror("bind"); ++ exit(2); ++ } ++ ++ if (getsockname(icmp_sock, (struct sockaddr *) &sa, &sl) == -1) { ++ perror("getsockname"); ++ exit(2); ++ } ++ ident = sa.sin_port; + } + +- if (1) { ++ if (!using_ping_socket) { + struct icmp_filter filt; + filt.data = ~((1<ee_origin == SO_EE_ORIGIN_ICMP) { + struct sockaddr_in *sin = (struct sockaddr_in*)(e+1); ++ int error_pkt; + + if (res < sizeof(icmph) || + target.sin_addr.s_addr != whereto.sin_addr.s_addr || +@@ -576,9 +610,18 @@ int receive_error_msg() + goto out; + } + +- acknowledge(ntohs(icmph.un.echo.sequence)); ++ error_pkt = (e->ee_type != ICMP_REDIRECT && ++ e->ee_type != ICMP_SOURCE_QUENCH); ++ if (error_pkt) { ++ acknowledge(ntohs(icmph.un.echo.sequence)); ++ net_errors++; ++ nerrors++; ++ } ++ else { ++ saved_errno = 0; ++ } + +- if (!working_recverr) { ++ if (!using_ping_socket && !working_recverr) { + struct icmp_filter filt; + working_recverr = 1; + /* OK, it works. Add stronger filter. */ +@@ -589,15 +632,14 @@ int receive_error_msg() + perror("\rWARNING: setsockopt(ICMP_FILTER)"); + } + +- net_errors++; +- nerrors++; + if (options & F_QUIET) + goto out; + if (options & F_FLOOD) { +- write_stdout("\bE", 2); ++ if (error_pkt) ++ write_stdout("\bE", 2); + } else { + print_timestamp(); +- printf("From %s icmp_seq=%u ", pr_addr(sin->sin_addr.s_addr), ntohs(icmph.un.echo.sequence)); ++ printf("From %s: icmp_seq=%u ", pr_addr(sin->sin_addr.s_addr), ntohs(icmph.un.echo.sequence)); + pr_icmph(e->ee_type, e->ee_code, e->ee_info, NULL); + fflush(stdout); + } +@@ -695,15 +737,41 @@ parse_reply(struct msghdr *msg, int cc, + struct iphdr *ip; + int hlen; + int csfailed; ++ struct cmsghdr *cmsg; ++ int ttl; ++ __u8 *opts; ++ int optlen; + + /* Check the IP header */ + ip = (struct iphdr *)buf; +- hlen = ip->ihl*4; +- if (cc < hlen + 8 || ip->ihl < 5) { +- if (options & F_VERBOSE) +- fprintf(stderr, "ping: packet too short (%d bytes) from %s\n", cc, +- pr_addr(from->sin_addr.s_addr)); +- return 1; ++ if (!using_ping_socket) { ++ hlen = ip->ihl*4; ++ if (cc < hlen + 8 || ip->ihl < 5) { ++ if (options & F_VERBOSE) ++ fprintf(stderr, "ping: packet too short (%d bytes) from %s\n", cc, ++ pr_addr(from->sin_addr.s_addr)); ++ return 1; ++ } ++ ttl = ip->ttl; ++ opts = buf + sizeof(struct iphdr); ++ optlen = hlen - sizeof(struct iphdr); ++ } else { ++ hlen = 0; ++ ttl = 0; ++ opts = buf; ++ optlen = 0; ++ for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) { ++ if (cmsg->cmsg_level != SOL_IP) ++ continue; ++ if (cmsg->cmsg_type == IP_TTL) { ++ if (cmsg->cmsg_len < sizeof(int)) ++ continue; ++ ttl = *(int *) CMSG_DATA(cmsg); ++ } else if (cmsg->cmsg_type == IP_RETOPTS) { ++ opts = (__u8 *) CMSG_DATA(cmsg); ++ optlen = cmsg->cmsg_len; ++ } ++ } + } + + /* Now the ICMP part */ +@@ -716,7 +784,7 @@ parse_reply(struct msghdr *msg, int cc, + return 1; /* 'Twas not our ECHO */ + if (gather_statistics((__u8*)icp, sizeof(*icp), cc, + ntohs(icp->un.echo.sequence), +- ip->ttl, 0, tv, pr_addr(from->sin_addr.s_addr), ++ ttl, 0, tv, pr_addr(from->sin_addr.s_addr), + pr_echo_reply)) + return 0; + } else { +@@ -807,7 +875,7 @@ parse_reply(struct msghdr *msg, int cc, + } + + if (!(options & F_FLOOD)) { +- pr_options(buf + sizeof(struct iphdr), hlen); ++ pr_options(opts, optlen + sizeof(struct iphdr)); + + if (options & F_AUDIBLE) + putchar('\a'); +@@ -916,8 +984,7 @@ void pr_icmph(__u8 type, __u8 code, __u3 + printf("Redirect, Bad Code: %d", code); + break; + } +- if (icp) +- printf("(New nexthop: %s)\n", pr_addr(icp->un.gateway)); ++ printf("(New nexthop: %s)\n", pr_addr(icp ? icp->un.gateway : info)); + if (icp && (options & F_VERBOSE)) + pr_iph((struct iphdr*)(icp + 1)); + break; +@@ -1217,7 +1284,7 @@ void install_filter(void) + insns + }; + +- if (once) ++ if (once || using_ping_socket) + return; + once = 1; + +--- iputils-s20101006/ping_common.c ++++ iputils-s20101006/ping_common.c +@@ -515,7 +515,8 @@ void setup(int icmp_sock) + *p++ = i; + } + +- ident = htons(getpid() & 0xFFFF); ++ if (!ident) ++ ident = htons(getpid() & 0xFFFF); + + set_signal(SIGINT, sigexit); + set_signal(SIGALRM, sigexit); diff --git a/network/misc/iputils/files/iputils-20121221-printf-size.patch b/network/misc/iputils/files/iputils-20121221-printf-size.patch new file mode 100644 index 0000000000..6d6c3b7d25 --- /dev/null +++ b/network/misc/iputils/files/iputils-20121221-printf-size.patch @@ -0,0 +1,64 @@ +From 23fcb10ae15a96aa9e5a823cfe0b612d9522691c Mon Sep 17 00:00:00 2001 +From: Mike Frysinger +Date: Sat, 14 Aug 2010 01:16:42 -0400 +Subject: [PATCH [iputils]] tracepath: re-use printf return in print_host + +Since the printf funcs already return the length of chars displayed, +use that value instead of re-calculating the length with strlen. + +This also fixes the handling of the strlen return -- it's a size_t, +not an int. + +Signed-off-by: Mike Frysinger +--- + tracepath.c | 11 ++++------- + tracepath6.c | 11 ++++------- + 2 files changed, 8 insertions(+), 14 deletions(-) + +diff --git a/tracepath.c b/tracepath.c +index 8a08f1d..f155816 100644 +--- a/tracepath.c ++++ b/tracepath.c +@@ -73,13 +73,10 @@ void data_wait(int fd) + + void print_host(const char *a, const char *b, int both) + { +- int plen = 0; +- printf("%s", a); +- plen = strlen(a); +- if (both) { +- printf(" (%s)", b); +- plen += strlen(b) + 3; +- } ++ int plen; ++ plen = printf("%s", a); ++ if (both) ++ plen += printf(" (%s)", b); + if (plen >= HOST_COLUMN_SIZE) + plen = HOST_COLUMN_SIZE - 1; + printf("%*s", HOST_COLUMN_SIZE - plen, ""); +diff --git a/tracepath6.c b/tracepath6.c +index 126fadf..bee95c3 100644 +--- a/tracepath6.c ++++ b/tracepath6.c +@@ -86,13 +86,10 @@ void data_wait(int fd) + + void print_host(const char *a, const char *b, int both) + { +- int plen = 0; +- printf("%s", a); +- plen = strlen(a); +- if (both) { +- printf(" (%s)", b); +- plen += strlen(b) + 3; +- } ++ int plen; ++ plen = printf("%s", a); ++ if (both) ++ plen += printf(" (%s)", b); + if (plen >= HOST_COLUMN_SIZE) + plen = HOST_COLUMN_SIZE - 1; + printf("%*s", HOST_COLUMN_SIZE - plen, ""); +-- +1.8.0.2 + diff --git a/network/misc/iputils/files/man/arping.8 b/network/misc/iputils/files/man/arping.8 new file mode 100644 index 0000000000..af98087a14 --- /dev/null +++ b/network/misc/iputils/files/man/arping.8 @@ -0,0 +1,110 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "ARPING" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +arping \- send ARP REQUEST to a neighbour host +.SH SYNOPSIS + +\fBarping\fR [ \fB-AbDfhqUV\fR] [ \fB-c \fIcount\fB\fR] [ \fB-w \fIdeadline\fB\fR] [ \fB-s \fIsource\fB\fR] \fB-I \fIinterface\fB\fR \fB\fIdestination\fB\fR + +.SH "DESCRIPTION" +.PP +Ping \fIdestination\fR on device \fIinterface\fR by ARP packets, +using source address \fIsource\fR. +.SH "OPTIONS" +.TP +\fB-A\fR +The same as \fB-U\fR, but ARP REPLY packets used instead +of ARP REQUEST. +.TP +\fB-b\fR +Send only MAC level broadcasts. Normally \fBarping\fR starts +from sending broadcast, and switch to unicast after reply received. +.TP +\fB-c \fIcount\fB\fR +Stop after sending \fIcount\fR ARP REQUEST +packets. With +\fIdeadline\fR +option, \fBarping\fR waits for +\fIcount\fR ARP REPLY packets, until the timeout expires. +.TP +\fB-D\fR +Duplicate address detection mode (DAD). See +RFC2131, 4.4.1. +Returns 0, if DAD succeeded i.e. no replies are received +.TP +\fB-f\fR +Finish after the first reply confirming that target is alive. +.TP +\fB-I \fIinterface\fB\fR +Name of network device where to send ARP REQUEST packets. This option +is required. +.TP +\fB-h\fR +Print help page and exit. +.TP +\fB-q\fR +Quiet output. Nothing is displayed. +.TP +\fB-s \fIsource\fB\fR +IP source address to use in ARP packets. +If this option is absent, source address is: +.RS +.TP 0.2i +\(bu +In DAD mode (with option \fB-D\fR) set to 0.0.0.0. +.TP 0.2i +\(bu +In Unsolicited ARP mode (with options \fB-U\fR or \fB-A\fR) +set to \fIdestination\fR. +.TP 0.2i +\(bu +Otherwise, it is calculated from routing tables. +.RE +.TP +\fB-U\fR +Unsolicited ARP mode to update neighbours' ARP caches. +No replies are expected. +.TP +\fB-V\fR +Print version of the program and exit. +.TP +\fB-w \fIdeadline\fB\fR +Specify a timeout, in seconds, before +\fBarping\fR +exits regardless of how many +packets have been sent or received. In this case +\fBarping\fR +does not stop after +\fIcount\fR +packet are sent, it waits either for +\fIdeadline\fR +expire or until +\fIcount\fR +probes are answered. +.SH "SEE ALSO" +.PP +\fBping\fR(8), +\fBclockdiff\fR(8), +\fBtracepath\fR(8). +.SH "AUTHOR" +.PP +\fBarping\fR was written by +Alexey Kuznetsov +. +It is now maintained by +YOSHIFUJI Hideaki +. +.SH "SECURITY" +.PP +\fBarping\fR requires CAP_NET_RAWIO capability +to be executed. It is not recommended to be used as set-uid root, +because it allows user to modify ARP caches of neighbour hosts. +.SH "AVAILABILITY" +.PP +\fBarping\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff --git a/network/misc/iputils/files/man/clockdiff.8 b/network/misc/iputils/files/man/clockdiff.8 new file mode 100644 index 0000000000..764dcd5eb1 --- /dev/null +++ b/network/misc/iputils/files/man/clockdiff.8 @@ -0,0 +1,81 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "CLOCKDIFF" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +clockdiff \- measure clock difference between hosts +.SH SYNOPSIS + +\fBclockdiff\fR [ \fB-o\fR] [ \fB-o1\fR] \fB\fIdestination\fB\fR + +.SH "DESCRIPTION" +.PP +\fBclockdiff\fR Measures clock difference between us and +\fIdestination\fR with 1 msec resolution using ICMP TIMESTAMP +[2] +packets or, optionally, IP TIMESTAMP option +[3] +option added to ICMP ECHO. +[1] +.SH "OPTIONS" +.TP +\fB-o\fR +Use IP TIMESTAMP with ICMP ECHO instead of ICMP TIMESTAMP +messages. It is useful with some destinations, which do not support +ICMP TIMESTAMP (f.e. Solaris <2.4). +.TP +\fB-o1\fR +Slightly different form of \fB-o\fR, namely it uses three-term +IP TIMESTAMP with prespecified hop addresses instead of four term one. +What flavor works better depends on target host. Particularly, +\fB-o\fR is better for Linux. +.SH "WARNINGS" +.TP 0.2i +\(bu +Some nodes (Cisco) use non-standard timestamps, which is allowed +by RFC, but makes timestamps mostly useless. +.TP 0.2i +\(bu +Some nodes generate messed timestamps (Solaris>2.4), when +run \fBxntpd\fR. Seems, its IP stack uses a corrupted clock source, +which is synchronized to time-of-day clock periodically and jumps +randomly making timestamps mostly useless. Good news is that you can +use NTP in this case, which is even better. +.TP 0.2i +\(bu +\fBclockdiff\fR shows difference in time modulo 24 days. +.SH "SEE ALSO" +.PP +\fBping\fR(8), +\fBarping\fR(8), +\fBtracepath\fR(8). +.SH "REFERENCES" +.PP +[1] ICMP ECHO, +RFC0792, page 14. +.PP +[2] ICMP TIMESTAMP, +RFC0792, page 16. +.PP +[3] IP TIMESTAMP option, +RFC0791, 3.1, page 16. +.SH "AUTHOR" +.PP +\fBclockdiff\fR was compiled by +Alexey Kuznetsov +. It was based on code borrowed +from BSD \fBtimed\fR daemon. +It is now maintained by +YOSHIFUJI Hideaki +. +.SH "SECURITY" +.PP +\fBclockdiff\fR requires CAP_NET_RAWIO capability +to be executed. It is safe to be used as set-uid root. +.SH "AVAILABILITY" +.PP +\fBclockdiff\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff --git a/network/misc/iputils/files/man/ping.8 b/network/misc/iputils/files/man/ping.8 new file mode 100644 index 0000000000..d0615b11dd --- /dev/null +++ b/network/misc/iputils/files/man/ping.8 @@ -0,0 +1,408 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "PING" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +ping, ping6 \- send ICMP ECHO_REQUEST to network hosts +.SH SYNOPSIS + +\fBping\fR [ \fB-LRUbdfnqrvVaAB\fR] [ \fB-c \fIcount\fB\fR] [ \fB-m \fImark\fB\fR] [ \fB-i \fIinterval\fB\fR] [ \fB-l \fIpreload\fB\fR] [ \fB-p \fIpattern\fB\fR] [ \fB-s \fIpacketsize\fB\fR] [ \fB-t \fIttl\fB\fR] [ \fB-w \fIdeadline\fB\fR] [ \fB-F \fIflowlabel\fB\fR] [ \fB-I \fIinterface\fB\fR] [ \fB-M \fIhint\fB\fR] [ \fB-N \fInioption\fB\fR] [ \fB-Q \fItos\fB\fR] [ \fB-S \fIsndbuf\fB\fR] [ \fB-T \fItimestamp option\fB\fR] [ \fB-W \fItimeout\fB\fR] [ \fB\fIhop\fB\fR\fI ...\fR] \fB\fIdestination\fB\fR + +.SH "DESCRIPTION" +.PP +\fBping\fR uses the ICMP protocol's mandatory ECHO_REQUEST +datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. +ECHO_REQUEST datagrams (``pings'') have an IP and ICMP +header, followed by a struct timeval and then an arbitrary +number of ``pad'' bytes used to fill out the packet. +.PP +\fBping6\fR can also send Node Information Queries (RFC4620). +.SH "OPTIONS" +.TP +\fB-a\fR +Audible ping. +.TP +\fB-A\fR +Adaptive ping. Interpacket interval adapts to round-trip time, so that +effectively not more than one (or more, if preload is set) unanswered probe +is present in the network. Minimal interval is 200msec for not super-user. +On networks with low rtt this mode is essentially equivalent to flood mode. +.TP +\fB-b\fR +Allow pinging a broadcast address. +.TP +\fB-B\fR +Do not allow \fBping\fR to change source address of probes. +The address is bound to one selected when \fBping\fR starts. +.TP +\fB-m \fImark\fB\fR +use \fImark\fR to tag the packets going out. This is useful +for variety of reasons within the kernel such as using policy +routing to select specific outbound processing. +.TP +\fB-c \fIcount\fB\fR +Stop after sending \fIcount\fR ECHO_REQUEST +packets. With +\fIdeadline\fR +option, \fBping\fR waits for +\fIcount\fR ECHO_REPLY packets, until the timeout expires. +.TP +\fB-d\fR +Set the SO_DEBUG option on the socket being used. +Essentially, this socket option is not used by Linux kernel. +.TP +\fB-F \fIflow label\fB\fR +Allocate and set 20 bit flow label on echo request packets. +(Only \fBping6\fR). If value is zero, kernel allocates random flow label. +.TP +\fB-f\fR +Flood ping. For every ECHO_REQUEST sent a period ``.'' is printed, +while for ever ECHO_REPLY received a backspace is printed. +This provides a rapid display of how many packets are being dropped. +If interval is not given, it sets interval to zero and +outputs packets as fast as they come back or one hundred times per second, +whichever is more. +Only the super-user may use this option with zero interval. +.TP +\fB-i \fIinterval\fB\fR +Wait \fIinterval\fR seconds between sending each packet. +The default is to wait for one second between each packet normally, +or not to wait in flood mode. Only super-user may set interval +to values less 0.2 seconds. +.TP +\fB-I \fIinterface address\fB\fR +Set source address to specified interface address. Argument +may be numeric IP address or name of device. When pinging IPv6 +link-local address this option is required. +.TP +\fB-l \fIpreload\fB\fR +If \fIpreload\fR is specified, +\fBping\fR sends that many packets not waiting for reply. +Only the super-user may select preload more than 3. +.TP +\fB-L\fR +Suppress loopback of multicast packets. This flag only applies if the ping +destination is a multicast address. +.TP +\fB-N \fInioption\fB\fR +Send ICMPv6 Node Information Queries (RFC4620), instead of Echo Request. +.RS +.TP +\fBname\fR +Queries for Node Names. +.RE +.RS +.TP +\fBipv6\fR +Queries for IPv6 Addresses. There are several IPv6 specific flags. +.RS +.TP +\fBipv6-global\fR +Request IPv6 global-scope addresses. +.RE +.RS +.TP +\fBipv6-sitelocal\fR +Request IPv6 site-local addresses. +.RE +.RS +.TP +\fBipv6-linklocal\fR +Request IPv6 link-local addresses. +.RE +.RS +.TP +\fBipv6-all\fR +Request IPv6 addresses on other interfaces. +.RE +.RE +.RS +.TP +\fBipv4\fR +Queries for IPv4 Addresses. There is one IPv4 specific flag. +.RS +.TP +\fBipv4-all\fR +Request IPv4 addresses on other interfaces. +.RE +.RE +.RS +.TP +\fBsubject-ipv6=\fIipv6addr\fB\fR +IPv6 subject address. +.RE +.RS +.TP +\fBsubject-ipv4=\fIipv4addr\fB\fR +IPv4 subject address. +.RE +.RS +.TP +\fBsubject-name=\fInodename\fB\fR +Subject name. If it contains more than one dot, +fully-qualified domain name is assumed. +.RE +.RS +.TP +\fBsubject-fqdn=\fInodename\fB\fR +Subject name. Fully-qualified domain name is +always assumed. +.RE +.TP +\fB-n\fR +Numeric output only. +No attempt will be made to lookup symbolic names for host addresses. +.TP +\fB-p \fIpattern\fB\fR +You may specify up to 16 ``pad'' bytes to fill out the packet you send. +This is useful for diagnosing data-dependent problems in a network. +For example, \fB-p ff\fR will cause the sent packet +to be filled with all ones. +.TP +\fB-D\fR +Print timestamp (unix time + microseconds as in gettimeofday) before +each line. +.TP +\fB-Q \fItos\fB\fR +Set Quality of Service -related bits in ICMP datagrams. +\fItos\fR can be either decimal or hex number. +Traditionally (RFC1349), these have been interpreted as: 0 for reserved +(currently being redefined as congestion control), 1-4 for Type of Service +and 5-7 for Precedence. +Possible settings for Type of Service are: minimal cost: 0x02, +reliability: 0x04, throughput: 0x08, low delay: 0x10. Multiple TOS bits +should not be set simultaneously. Possible settings for +special Precedence range from priority (0x20) to net control (0xe0). You +must be root (CAP_NET_ADMIN capability) to use Critical or +higher precedence value. You cannot set +bit 0x01 (reserved) unless ECN has been enabled in the kernel. +In RFC2474, these fields has been redefined as 8-bit Differentiated +Services (DS), consisting of: bits 0-1 of separate data (ECN will be used, +here), and bits 2-7 of Differentiated Services Codepoint (DSCP). +.TP +\fB-q\fR +Quiet output. +Nothing is displayed except the summary lines at startup time and +when finished. +.TP +\fB-R\fR +Record route. +Includes the RECORD_ROUTE option in the ECHO_REQUEST +packet and displays the route buffer on returned packets. +Note that the IP header is only large enough for nine such routes. +Many hosts ignore or discard this option. +.TP +\fB-r\fR +Bypass the normal routing tables and send directly to a host on an attached +interface. +If the host is not on a directly-attached network, an error is returned. +This option can be used to ping a local host through an interface +that has no route through it provided the option \fB-I\fR is also +used. +.TP +\fB-s \fIpacketsize\fB\fR +Specifies the number of data bytes to be sent. +The default is 56, which translates into 64 ICMP +data bytes when combined with the 8 bytes of ICMP header data. +.TP +\fB-S \fIsndbuf\fB\fR +Set socket sndbuf. If not specified, it is selected to buffer +not more than one packet. +.TP +\fB-t \fIttl\fB\fR +Set the IP Time to Live. +.TP +\fB-T \fItimestamp option\fB\fR +Set special IP timestamp options. +\fItimestamp option\fR may be either +\fItsonly\fR (only timestamps), +\fItsandaddr\fR (timestamps and addresses) or +\fItsprespec host1 [host2 [host3 [host4]]]\fR +(timestamp prespecified hops). +.TP +\fB-M \fIhint\fB\fR +Select Path MTU Discovery strategy. +\fIhint\fR may be either \fIdo\fR +(prohibit fragmentation, even local one), +\fIwant\fR (do PMTU discovery, fragment locally when packet size +is large), or \fIdont\fR (do not set DF flag). +.TP +\fB-U\fR +Print full user-to-user latency (the old behaviour). Normally +\fBping\fR +prints network round trip time, which can be different +f.e. due to DNS failures. +.TP +\fB-v\fR +Verbose output. +.TP +\fB-V\fR +Show version and exit. +.TP +\fB-w \fIdeadline\fB\fR +Specify a timeout, in seconds, before +\fBping\fR +exits regardless of how many +packets have been sent or received. In this case +\fBping\fR +does not stop after +\fIcount\fR +packet are sent, it waits either for +\fIdeadline\fR +expire or until +\fIcount\fR +probes are answered or for some error notification from network. +.TP +\fB-W \fItimeout\fB\fR +Time to wait for a response, in seconds. The option affects only timeout +in absence of any responses, otherwise \fBping\fR waits for two RTTs. +.PP +When using \fBping\fR for fault isolation, it should first be run +on the local host, to verify that the local network interface is up +and running. Then, hosts and gateways further and further away should be +``pinged''. Round-trip times and packet loss statistics are computed. +If duplicate packets are received, they are not included in the packet +loss calculation, although the round trip time of these packets is used +in calculating the minimum/average/maximum round-trip time numbers. +When the specified number of packets have been sent (and received) or +if the program is terminated with a +SIGINT, a brief summary is displayed. Shorter current statistics +can be obtained without termination of process with signal +SIGQUIT. +.PP +If \fBping\fR does not receive any reply packets at all it will +exit with code 1. If a packet +\fIcount\fR +and +\fIdeadline\fR +are both specified, and fewer than +\fIcount\fR +packets are received by the time the +\fIdeadline\fR +has arrived, it will also exit with code 1. +On other error it exits with code 2. Otherwise it exits with code 0. This +makes it possible to use the exit code to see if a host is alive or +not. +.PP +This program is intended for use in network testing, measurement and +management. +Because of the load it can impose on the network, it is unwise to use +\fBping\fR during normal operations or from automated scripts. +.SH "ICMP PACKET DETAILS" +.PP +An IP header without options is 20 bytes. +An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth +of ICMP header followed by an arbitrary amount of data. +When a \fIpacketsize\fR is given, this indicated the size of this +extra piece of data (the default is 56). Thus the amount of data received +inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes +more than the requested data space (the ICMP header). +.PP +If the data space is at least of size of struct timeval +\fBping\fR uses the beginning bytes of this space to include +a timestamp which it uses in the computation of round trip times. +If the data space is shorter, no round trip times are given. +.SH "DUPLICATE AND DAMAGED PACKETS" +.PP +\fBping\fR will report duplicate and damaged packets. +Duplicate packets should never occur, and seem to be caused by +inappropriate link-level retransmissions. +Duplicates may occur in many situations and are rarely (if ever) a +good sign, although the presence of low levels of duplicates may not +always be cause for alarm. +.PP +Damaged packets are obviously serious cause for alarm and often +indicate broken hardware somewhere in the +\fBping\fR packet's path (in the network or in the hosts). +.SH "TRYING DIFFERENT DATA PATTERNS" +.PP +The (inter)network layer should never treat packets differently depending +on the data contained in the data portion. +Unfortunately, data-dependent problems have been known to sneak into +networks and remain undetected for long periods of time. +In many cases the particular pattern that will have problems is something +that doesn't have sufficient ``transitions'', such as all ones or all +zeros, or a pattern right at the edge, such as almost all zeros. +It isn't necessarily enough to specify a data pattern of all zeros (for +example) on the command line because the pattern that is of interest is +at the data link level, and the relationship between what you type and +what the controllers transmit can be complicated. +.PP +This means that if you have a data-dependent problem you will probably +have to do a lot of testing to find it. +If you are lucky, you may manage to find a file that either can't be sent +across your network or that takes much longer to transfer than other +similar length files. +You can then examine this file for repeated patterns that you can test +using the \fB-p\fR option of \fBping\fR. +.SH "TTL DETAILS" +.PP +The TTL value of an IP packet represents the maximum number of IP routers +that the packet can go through before being thrown away. +In current practice you can expect each router in the Internet to decrement +the TTL field by exactly one. +.PP +The TCP/IP specification states that the TTL field for TCP +packets should be set to 60, but many systems use smaller values +(4.3 BSD uses 30, 4.2 used 15). +.PP +The maximum possible value of this field is 255, and most Unix systems set +the TTL field of ICMP ECHO_REQUEST packets to 255. +This is why you will find you can ``ping'' some hosts, but not reach them +with +\fBtelnet\fR(1) +or +\fBftp\fR(1). +.PP +In normal operation ping prints the TTL value from the packet it receives. +When a remote system receives a ping packet, it can do one of three things +with the TTL field in its response: +.TP 0.2i +\(bu +Not change it; this is what Berkeley Unix systems did before the +4.3BSD Tahoe release. In this case the TTL value in the received packet +will be 255 minus the number of routers in the round-trip path. +.TP 0.2i +\(bu +Set it to 255; this is what current Berkeley Unix systems do. +In this case the TTL value in the received packet will be 255 minus the +number of routers in the path \fBfrom\fR +the remote system \fBto\fR the \fBping\fRing host. +.TP 0.2i +\(bu +Set it to some other value. Some machines use the same value for +ICMP packets that they use for TCP packets, for example either 30 or 60. +Others may use completely wild values. +.SH "BUGS" +.TP 0.2i +\(bu +Many Hosts and Gateways ignore the RECORD_ROUTE option. +.TP 0.2i +\(bu +The maximum IP header length is too small for options like +RECORD_ROUTE to be completely useful. +There's not much that that can be done about this, however. +.TP 0.2i +\(bu +Flood pinging is not recommended in general, and flood pinging the +broadcast address should only be done under very controlled conditions. +.SH "SEE ALSO" +.PP +\fBnetstat\fR(1), +\fBifconfig\fR(8). +.SH "HISTORY" +.PP +The \fBping\fR command appeared in 4.3BSD. +.PP +The version described here is its descendant specific to Linux. +.SH "SECURITY" +.PP +\fBping\fR requires CAP_NET_RAWIO capability +to be executed. It may be used as set-uid root. +.SH "AVAILABILITY" +.PP +\fBping\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff --git a/network/misc/iputils/files/man/rarpd.8 b/network/misc/iputils/files/man/rarpd.8 new file mode 100644 index 0000000000..0e68d54900 --- /dev/null +++ b/network/misc/iputils/files/man/rarpd.8 @@ -0,0 +1,84 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "RARPD" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +rarpd \- answer RARP REQUESTs +.SH SYNOPSIS + +\fBarping\fR [ \fB-aAvde\fR] [ \fB-b \fIbootdir\fB\fR] [ \fB\fIinterface\fB\fR] + +.SH "DESCRIPTION" +.PP +Listens +RARP +requests from clients. Provided MAC address of client +is found in \fI/etc/ethers\fR database and +obtained host name is resolvable to an IP address appropriate +for attached network, \fBrarpd\fR answers to client with RARPD +reply carrying an IP address. +.PP +To allow multiple boot servers on the network \fBrarpd\fR +optionally checks for presence Sun-like bootable image in TFTP directory. +It should have form \fBHexadecimal_IP.ARCH\fR, f.e. to load +sparc 193.233.7.98 \fIC1E90762.SUN4M\fR is linked to +an image appropriate for SUM4M in directory \fI/etc/tftpboot\fR. +.SH "WARNING" +.PP +This facility is deeply obsoleted by +BOOTP +and later +DHCP protocols. +However, some clients really still need this to boot. +.SH "OPTIONS" +.TP +\fB-a\fR +Listen on all the interfaces. Currently it is an internal +option, its function is overridden with \fIinterface\fR +argument. It should not be used. +.TP +\fB-A\fR +Listen not only RARP but also ARP messages, some rare clients +use ARP by some unknown reason. +.TP +\fB-v\fR +Be verbose. +.TP +\fB-d\fR +Debug mode. Do not go to background. +.TP +\fB-e\fR +Do not check for presence of a boot image, reply if MAC address +resolves to a valid IP address using \fI/etc/ethers\fR +database and DNS. +.TP +\fB-b \fIbootdir\fB\fR +TFTP boot directory. Default is \fI/etc/tftpboot\fR +.SH "SEE ALSO" +.PP +\fBarping\fR(8), +\fBtftpd\fR(8). +.SH "AUTHOR" +.PP +\fBrarpd\fR was written by +Alexey Kuznetsov +. +It is now maintained by +YOSHIFUJI Hideaki +. +.SH "SECURITY" +.PP +\fBrarpd\fR requires CAP_NET_RAWIO capability +to listen and send RARP and ARP packets. It also needs CAP_NET_ADMIN +to give to kernel hint for ARP resolution; this is not strictly required, +but some (most of, to be more exact) clients are so badly broken that +are not able to answer ARP before they are finally booted. This is +not wonderful taking into account that clients using RARPD in 2002 +are all unsupported relic creatures of 90's and even earlier. +.SH "AVAILABILITY" +.PP +\fBrarpd\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff --git a/network/misc/iputils/files/man/rdisc.8 b/network/misc/iputils/files/man/rdisc.8 new file mode 100644 index 0000000000..b8acca5618 --- /dev/null +++ b/network/misc/iputils/files/man/rdisc.8 @@ -0,0 +1,110 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "RDISC" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +rdisc \- network router discovery daemon +.SH SYNOPSIS + +\fBrdisc\fR [ \fB-abdfstvV\fR] [ \fB\fIsend_address\fB\fR] [ \fB\fIreceive_address\fB\fR] + +.SH "DESCRIPTION" +.PP +\fBrdisc\fR implements client side of the ICMP router discover protocol. +\fBrdisc\fR is invoked at boot time to populate the network +routing tables with default routes. +.PP +\fBrdisc\fR listens on the ALL_HOSTS (224.0.0.1) multicast address +(or \fIreceive_address\fR provided it is given) +for ROUTER_ADVERTISE messages from routers. The received +messages are handled by first ignoring those listed router addresses +with which the host does not share a network. Among the remaining addresses +the ones with the highest preference are selected as default routers +and a default route is entered in the kernel routing table +for each one of them. +.PP +Optionally, \fBrdisc\fR can avoid waiting for routers to announce +themselves by sending out a few ROUTER_SOLICITATION messages +to the ALL_ROUTERS (224.0.0.2) multicast address +(or \fIsend_address\fR provided it is given) +when it is started. +.PP +A timer is associated with each router address and the address will +no longer be considered for inclusion in the the routing tables if the +timer expires before a new +\fBadvertise\fR message is received from the router. +The address will also be excluded from consideration if the host receives an +\fBadvertise\fR +message with the preference being maximally negative. +.PP +Server side of router discovery protocol is supported by Cisco IOS +and by any more or less complete UNIX routing daemon, f.e \fBgated\fR. +.SH "OPTIONS" +.TP +\fB-a\fR +Accept all routers independently of the preference they have in their +\fBadvertise\fR messages. +Normally \fBrdisc\fR only accepts (and enters in the kernel routing +tables) the router or routers with the highest preference. +.TP +\fB-b\fR +Opposite to \fB-a\fR, i.e. install only router with the best +preference value. It is default behaviour. +.TP +\fB-d\fR +Send debugging messages to syslog. +.TP +\fB-f\fR +Run \fBrdisc\fR forever even if no routers are found. +Normally \fBrdisc\fR gives up if it has not received any +\fBadvertise\fR message after after soliciting three times, +in which case it exits with a non-zero exit code. +If \fB-f\fR is not specified in the first form then +\fB-s\fR must be specified. +.TP +\fB-s\fR +Send three \fBsolicitation\fR messages initially to quickly discover +the routers when the system is booted. +When \fB-s\fR is specified \fBrdisc\fR +exits with a non-zero exit code if it can not find any routers. +This can be overridden with the \fB-f\fR option. +.TP +\fB-t\fR +Test mode. Do not go to background. +.TP +\fB-v\fR +Be verbose i.e. send lots of debugging messages to syslog. +.TP +\fB-V\fR +Print version and exit. +.SH "HISTORY" +.PP +This program was developed by Sun Microsystems (see copyright +notice in source file). It was ported to Linux by +Alexey Kuznetsov +. +It is now maintained by +YOSHIFUJI Hideaki +. +.SH "SEE ALSO" +.PP +\fBicmp\fR(7), +\fBinet\fR(7), +\fBping\fR(8). +.SH "REFERENCES" +.PP +Deering, S.E.,ed "ICMP Router Discovery Messages", +RFC1256, Network Information Center, SRI International, +Menlo Park, Calif., September 1991. +.SH "SECURITY" +.PP +\fBrdisc\fR requires CAP_NET_RAWIO to listen +and send ICMP messages and capability CAP_NET_ADMIN +to update routing tables. +.SH "AVAILABILITY" +.PP +\fBrdisc\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff --git a/network/misc/iputils/files/man/tracepath.8 b/network/misc/iputils/files/man/tracepath.8 new file mode 100644 index 0000000000..ed780bf96f --- /dev/null +++ b/network/misc/iputils/files/man/tracepath.8 @@ -0,0 +1,97 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "TRACEPATH" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +tracepath, tracepath6 \- traces path to a network host discovering MTU along this path +.SH SYNOPSIS + +\fBtracepath\fR [ \fB-n\fR] [ \fB-b\fR] [ \fB-l \fIpktlen\fB\fR] \fB\fIdestination\fB\fR [ \fB\fIport\fB\fR] + +.SH "DESCRIPTION" +.PP +It traces path to \fIdestination\fR discovering MTU along this path. +It uses UDP port \fIport\fR or some random port. +It is similar to \fBtraceroute\fR, only does not require superuser +privileges and has no fancy options. +.PP +\fBtracepath6\fR is good replacement for \fBtraceroute6\fR +and classic example of application of Linux error queues. +The situation with IPv4 is worse, because commercial +IP routers do not return enough information in ICMP error messages. +Probably, it will change, when they will be updated. +For now it uses Van Jacobson's trick, sweeping a range +of UDP ports to maintain trace history. +.SH "OPTIONS" +.TP +\fB-n\fR +Print primarily IP addresses numerically. +.TP +\fB-b\fR +Print both of host names and IP addresses. +.TP +\fB-l\fR +Sets the initial packet length to \fIpktlen\fR instead of +65536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR. +.SH "OUTPUT" +.PP + +.nf +root@mops:~ # tracepath6 3ffe:2400:0:109::2 + 1?: [LOCALHOST] pmtu 1500 + 1: dust.inr.ac.ru 0.411ms + 2: dust.inr.ac.ru asymm 1 0.390ms pmtu 1480 + 2: 3ffe:2400:0:109::2 463.514ms reached + Resume: pmtu 1480 hops 2 back 2 +.fi +.PP +The first column shows TTL of the probe, followed by colon. +Usually value of TTL is obtained from reply from network, +but sometimes reply does not contain necessary information and +we have to guess it. In this case the number is followed by ?. +.PP +The second column shows the network hop, which replied to the probe. +It is either address of router or word [LOCALHOST], if +the probe was not sent to the network. +.PP +The rest of line shows miscellaneous information about path to +the correspinding network hop. As rule it contains value of RTT. +Additionally, it can show Path MTU, when it changes. +If the path is asymmetric +or the probe finishes before it reach prescribed hop, difference +between number of hops in forward and backward direction is shown +following keyword async. This information is not reliable. +F.e. the third line shows asymmetry of 1, it is because the first probe +with TTL of 2 was rejected at the first hop due to Path MTU Discovery. +.PP +The last line summarizes information about all the path to the destination, +it shows detected Path MTU, amount of hops to the destination and our +guess about amount of hops from the destination to us, which can be +different when the path is asymmetric. +.SH "SEE ALSO" +.PP +\fBtraceroute\fR(8), +\fBtraceroute6\fR(8), +\fBping\fR(8). +.SH "AUTHOR" +.PP +\fBtracepath\fR was written by +Alexey Kuznetsov +. +.SH "SECURITY" +.PP +No security issues. +.PP +This lapidary deserves to be elaborated. +\fBtracepath\fR is not a privileged program, unlike +\fBtraceroute\fR, \fBping\fR and other beasts of this kind. +\fBtracepath\fR may be executed by everyone who has some access +to network, enough to send UDP datagrams to investigated destination +using given port. +.SH "AVAILABILITY" +.PP +\fBtracepath\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff --git a/network/misc/iputils/files/man/traceroute6.8 b/network/misc/iputils/files/man/traceroute6.8 new file mode 100644 index 0000000000..7dfe99d332 --- /dev/null +++ b/network/misc/iputils/files/man/traceroute6.8 @@ -0,0 +1,42 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "TRACEROUTE6" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +traceroute6 \- traces path to a network host +.SH SYNOPSIS + +\fBtraceroute6\fR [ \fB-dnrvV\fR] [ \fB-i \fIinterface\fB\fR] [ \fB-m \fImax_ttl\fB\fR] [ \fB-p \fIport\fB\fR] [ \fB-q \fImax_probes\fB\fR] [ \fB-s \fIsource\fB\fR] [ \fB-w \fIwait time\fB\fR] \fB\fIdestination\fB\fR [ \fB\fIsize\fB\fR] + +.SH "DESCRIPTION" +.PP +Description can be found in +\fBtraceroute\fR(8), +all the references to IP replaced to IPv6. It is needless to copy +the description from there. +.SH "SEE ALSO" +.PP +\fBtraceroute\fR(8), +\fBtracepath\fR(8), +\fBping\fR(8). +.SH "HISTORY" +.PP +This program has long history. Author of \fBtraceroute\fR +is Van Jacobson and it first appeared in 1988. This clone is +based on a port of \fBtraceroute\fR to IPv6 published +in NRL IPv6 distribution in 1996. In turn, it was ported +to Linux by Pedro Roque. After this it was kept in sync by +Alexey Kuznetsov +. And eventually entered +\fBiputils\fR package. +.SH "SECURITY" +.PP +\fBtracepath6\fR requires CAP_NET_RAWIO capability +to be executed. It is safe to be used as set-uid root. +.SH "AVAILABILITY" +.PP +\fBtraceroute6\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff --git a/network/misc/iputils/pspec.xml b/network/misc/iputils/pspec.xml new file mode 100644 index 0000000000..d0870317c1 --- /dev/null +++ b/network/misc/iputils/pspec.xml @@ -0,0 +1,131 @@ + + + + + iputils + http://www.linux-ipv6.org + + PisiLinux Community + admins@pisilinux.org + + BSD + app:console + Network monitoring tools including ping and ping6 + iputils contains network monitoring tools including ping and ping6. + http://www.skbuff.net/iputils/iputils-s20121221.tar.bz2 + + + ifenslave/ifenslave.c + + + openssl-devel + libidn-devel + gnutls-devel + libcap-devel + + + + 021109-uclibc-no-ether_ntohost.patch + + iputils-20121221-printf-size.patch + iputils-20121221-owl-pingsock.diff + iputils-20121221-openssl.patch + iputils-20121221-makefile.patch + iputils-20121221-crypto-build.patch + iputils-20100418-so_mark.patch + iputils-20071127-nonroot-floodping.patch + iputils-20071127-kernel-ifaddr.patch + + + + fedora/iputils-20020124-countermeasures.patch + + fedora/iputils-20020927-ping-subint.patch + + fedora/iputils-20070202-traffic_class.patch + + fedora/iputils-20100418-convtoint.patch + + + + + + + docs.patch + + + + + iputils + + libcap + gnutls + + + /bin + /usr/bin + /usr/sbin + /sbin + /lib/systemd/system + /etc/conf.d/rdisc + /usr/share/doc + /usr/share/man + + + + man/arping.8 + man/clockdiff.8 + man/ping.8 + man/rarpd.8 + man/rdisc.8 + man/tracepath.8 + man/traceroute6.8 + ifenslave/ifenslave.8 + ifenslave/README.bonding + + + fedora/rdisc.sysconfig + fedora/rdisc.service + + + + + + 2014-05-11 + 20121221 + Release bump. + Marcin Bojara + marcin@pisilinux.org + + + 2013-07-26 + 20121221 + Fix dep, release bump. + PisiLinux Community + admins@pisilinux.org + + + 2013-01-14 + 20121221 + New release + PisiLinux Community + admins@pisilinux.org + + + 2012-08-23 + 20101006 + First release + PisiLinux Community + admins@pisilinux.org + + + diff --git a/network/misc/iputils/translations.xml b/network/misc/iputils/translations.xml new file mode 100644 index 0000000000..ed28e7236f --- /dev/null +++ b/network/misc/iputils/translations.xml @@ -0,0 +1,9 @@ + + + + iputils + ping ve ping6 uygulamalarını da içeren ağ izleme araçları + Iputils, ping ve ping6 gibi ağ izleme araçlarını içeren bir pakettir. + Iputils contient les outils de surveillance réseau incluant ping et ping6. + + diff --git a/programming/language/python/python-lxml/actions.py b/programming/language/python/python-lxml/actions.py new file mode 100644 index 0000000000..11d759962a --- /dev/null +++ b/programming/language/python/python-lxml/actions.py @@ -0,0 +1,27 @@ +#!/usr/bin/python +# -*- coding: utf-8 -*- +# +# Licensed under the GNU General Public License, version 3. +# See the file http://www.gnu.org/copyleft/gpl.txt. + +from pisi.actionsapi import pythonmodules +from pisi.actionsapi import shelltools +from pisi.actionsapi import pisitools +from pisi.actionsapi import get + +WorkDir = "lxml-%s" % get.srcVERSION() + +def build(): + # remove the C extension so that it will be rebuild using the latest Cython + shelltools.unlink("src/lxml/lxml.etree.c") + shelltools.unlink("src/lxml/lxml.etree_api.h") + shelltools.unlink("src/lxml/lxml.objectify.c") + + pythonmodules.compile() + +def install(): + pythonmodules.install() + + pisitools.insinto("%s/%s" % (get.docDIR(), get.srcNAME()),"doc/*") + + pisitools.dodoc("CHANGES.txt", "LICENSES.txt", "TODO.txt") diff --git a/programming/language/python/python-lxml/pspec.xml b/programming/language/python/python-lxml/pspec.xml new file mode 100644 index 0000000000..99b96e51a5 --- /dev/null +++ b/programming/language/python/python-lxml/pspec.xml @@ -0,0 +1,81 @@ + + + + + python-lxml + http://codespeak.net/lxml + + PisiLinux Community + admins@pisilinux.org + + GPLv2 + BSD + library + lxml is the most feature-rich and easy-to-use library + lxml is the most feature-rich and easy-to-use library for working with XML and HTML in the Python language. + http://lxml.de/files/lxml-3.3.5.tgz + + libxml2-devel + python-devel + cython + libxslt-devel + + + + + + + + python-lxml + + libxslt + libxml2 + python + + + /usr/lib + + + + + python-lxml-docs + API documentation of python-lxml + + python-lxml + + + /usr/share/doc + + + + + + 2014-07-05 + 3.3.5 + Version bump + Vedat Demir + vedat@pisilinux.org + + + 2013-11-07 + 3.2.4 + Version bump + Burak Fazıl Ertürk + burakerturk@pisilinux.org + + + 2013-07-28 + 3.0.1 + Dep Fixed + Osman Erkan + osman.erkan@pisilinux.org + + + 2012-10-24 + 3.0.1 + First release + Yusuf Aydemir + yusuf.aydemir@pisilinux.org + + + \ No newline at end of file diff --git a/programming/language/python/python-lxml/translations.xml b/programming/language/python/python-lxml/translations.xml new file mode 100644 index 0000000000..e9d8f95dae --- /dev/null +++ b/programming/language/python/python-lxml/translations.xml @@ -0,0 +1,13 @@ + + + + python-lxml + Zengin içerikli ve kolay kullanımlı bir kütüphane. + Python dilinde xml ve html ile çalışmak için, zengin içerikli ve kolay kullanımlı bir kütüphane. + + + + python-lxml-docs + python-lxml paketine ait API belgeleri + +