BINDTEST(1) General Commands Manual BINDTEST(1) NAME bindtest -- test bind(2) behavior on IPv6 implementation SYNOPSIS bindtest [-126APlstv] [-b IPv4broadcast] [-o IPv4address] -p port DESCRIPTION bindtest tests interaction between IPv4/IPv6 socket interface, implemented into the kernel it has underneath. RFC2553 defines socket API for IPv6, and relationship between IPv6 wildcard bind(2) socket (::.port) and IPv4 wildcard bind(2) socket (0.0.0.0.port). However, the document does not define ordering constraints between them, relationship with specific bind(2), nor relationship with speficfic bind(2) using IPv4 mapped IPv6 address (::ffff:127.0.0.1). bindtest tries to reveal the behavior implemented in the kernel, and shows some report to standard output. As RFC2553 does not define the expected behavior, we have no idea what the result should be. The following command line options are accepted. For details please see the following subsections: -1 After successful bind(2) on two sockets, try a connect(2) to the first socket. Works only when -t is specified as well. -2 Like -1, but try a connect(2) to the second socket. Works only when -t is specified as well. -6 Uses IPV6_V6ONLY socket option on AF_INET6 sockets (note that not many stacks implement this yet). -A Set SO_REUSEADDR socket option for all the sockets. -P Set SO_REUSEPORT socket option for all the sockets. -b IPv4broadcast Specifies an additional broadcast address to test if UDP datagram to IPv4broadcast, which is an IPv4 broadcast address, can be sent on an AF_INET6 socket as an IPv4-mapped IPv6 address. This option can only be specified for UDP. Currently, the -s option and this option cannot coexist. -l With TCP test, normally bindtest will issue bind(2) and listen(2) for the first socket, then bind(2) and listen(2) for the second socket. With -l, bindtest will issue two bind(2) first, then two listen(2) system calls. Works only when -t is specified as well. -o IPv4addresss Specifies an additional address to test connect(2) or sendto(2) be- havior. The address should already be assigned to the node, and should not be the loopback address (127.0.0.1). -p port port specifies the TCP/UDP port number used for the test. The port needs to be vacant. The flag is mandatory. -s Summary output. See the following subsection for details. -t By default bindtest will use SOCK_DGRAM socket for testing. With -t, bindtest will use SOCK_STREAM socket instead. -v bindtest prints its version and exits without testing anything. The test process The goal of bindtest is to detect how the implementation interpteted and coded RFC2553. More specifically, the following items are tested: * If we issue two bind(2) system calls to two sockets with the same port number, will it go successful, or either of/both of them fails? * For the failure case, does the ordering of bind(2) matter? * If the two bind(2) attemps go successful, which socket will get incom- ing traffic? * For TCP case, does the order between bind(2) and listen(2) affect the behavior? The list of addresses to be tested with bind(2) are as below: wildcard: :: and 0.0.0.0 loopback: ::1 and 127.0.0.1 IPv4 mapped wildcard and loopback: ::ffff:0.0.0.0 and ::ffff:127.0.0.1 invalid address: ::ffff:0.0.0.1 and 0.0.0.1. Their goal is to test common pro- gramming mistakes in the implementation. When two sockets become ready after bind(2), bindtest attempts to send some packets to see which socket accepts which packets. For UDP cases, it tries to issue sendto(2) for each address bound to each socket, and for the addi- tional address if specified by the -o option. For TCP cases, the program tries to issue connect(2) for one destination specified by the -1, -2, or -o IPv4address options. -1 and -2 let bindtest connect(2) to the address that the program has used for bind(2). With -o, bindtest connects to the address specified by the extra argument, IPv4address. Note that the op- tions -1 and -2 are meaningful only when -t is specified. When the -o IPv4address option is specified, the address can be any valid IPv4 address in theory, but, for the testing purpose, the address is mean- ingful only when it is an IPv4 address assigned on the testing node itself. The -l option is meaningful only when the corresponding socket is TCP. It specifies bindtest to issue bind(2) for both two sockets first, and then to issue listen(2) for the sockets. Normally, the program calls the two calls for the first socket, and then calls them for the second socket. This op- tion exists because there is an operating system that behaves differently for those two cases. Summary output With -s, bindtest generates summarized output instead of verbose output. Here is a sample output, and the legends for summarized output. starting tests, socktype = SOCK_DGRAM, SO_REUSEADDR, V6ONLY wild4 wild6 loop4 loop6 wildm loopm onem one4 wild4: x o[--1x] o[-21x] o[-21x] ?2(49) ?2(49) ?2(49) ?2(49) wild6: o[--2x] x o[-20x] o[-20x] ?2(49) ?2(49) ?2(49) ?2(49) loop4: o[1-2x] o[1-0x] x o[120x] ?2(49) ?2(49) ?2(49) ?2(49) loop6: o[1-2x] o[1-0x] o[120x] x ?2(49) ?2(49) ?2(49) ?2(49) wildm: ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) loopm: ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) onem: ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) one4: ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) ?1(49) bindtest will make a two set of socket(2) and bind(2). The first set is presented on the lefthand side. The second set is presented above the ta- ble. o The second bind(2) attempt was successful after the first bind(2). "o" is followed by three letters enclosed in square brackets. The first letter shows the test result after sendto(2) to the first socket address (listed on the topmost row). The second letter shows the test result after sendto(2) to the second socket address (listed on the leftmost column). The third letter shows the test result af- ter sendto(2) to the IPv4 additional address, when specified by the -o option, through an AF_INET socket. The fourth letter shows the test result after sendto(2) to the additional IPv4 address, when specified by the -o option, through an AF_INET6 socket using IPv4-mapped IPv6 address. - The address is wildcard (:: or 0.0.0.0) and no attempts were made to test send/recv behavior. 0 None of the sockets received the packet. 1 The first socket received the packet. 2 The second socket received the packet. b Both sockets received the packet. This result is not supposed to happen, but exists just in case. x The attempt of sendto(2) failed. UDP cases only. c The attempt of connect(2) failed. TCP cases only. The meaning of the result table is the same for TCP cases, whereas only one of the three possible cases should be tried in a single exe- cution of the test. x bind(2) failed for the second set, with EADDRINUSE. !1 socket(2) failed for the first set. Normally you will not see this, unless you run bindtest on IPv4-only/IPv6-only kernel. Will be fol- lowed by errno(2) in paren. !2 socket(2) failed for the second set. Normally you will not see this, unless you run bindtest on IPv4-only/IPv6-only kernel. Will be fol- lowed by errno(2) in paren. ?1 bind(2) failed for the first set. Will be followed by errno(2) in paren. ?2 bind(2) failed for the second set, with some error other than EADDRINUSE. Will be followed by errno(2) in paren. RETURN VALUES bindtest exits with 0 on success, and non-zero on errors. SEE ALSO R. Gilligan, S. Thomson, J. Bound, and W. Stevens, Basic Socket Interface Extensions for IPv6, RFC2553, March 1999. bind(2), tcpdump(8) HISTORY The bindtest command first appeared in WIDE/KAME IPv6 protocol stack kit. KAME June 25, 2001 BINDTEST(1)
NAME | SYNOPSIS | DESCRIPTION | RETURN VALUES | SEE ALSO | HISTORY
Want to link to this manual page? Use this URL:
<https://man.FreeBSD.org/cgi/man.cgi?query=bindtest&sektion=1&manpath=FreeBSD+Ports+15.1.quarterly>