https://bugzilla.kernel.org/show_bug.cgi?id=43249 Summary: connect(2) changes INADDR_ANY meaning for UDP sockets Product: Documentation Version: unspecified Kernel Version: 3.0.0 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: man-pages AssignedTo: documentation_man-pages@xxxxxxxxxxxxxxxxxxxx ReportedBy: sebastian.lauwers@xxxxxxxxx Regression: No Created an attachment (id=73297) --> (https://bugzilla.kernel.org/attachment.cgi?id=73297) Testcase which demonstrates the bug scenario The POSIX man page for connect(2) [1] specifies that: > If the socket has not already been bound to a local address, connect() > shall bind it to an address which, unless the socket's address family > is AF_UNIX, is an unused local address. The Linux man page for connect(2) does not provide this information, and this may be confusing, regarding the following behaviour: After creating a socket of type SOCK_DGRAM through socket(2), and calling bind(2) on it to have it "listen" on all interfaces (through the use of INADDR_ANY as value of sockaddr_in.sin_addr.s_addr), it is possible to call connect(2) on said socket. This behaviour is correctly explained by the connect(2) Linux man page [2]: > If the socket sockfd is of type SOCK_DGRAM then addr is the address to > which datagrams are sent by default, and the only address from which data‐ > grams are received. However, upon doing so, the socket is no longer "bound" to any interface (as could be assumed through the usage of INADDR_ANY), but one in particular (and it is apparently not possible to know which one, before calling connect(2)). This seems to contradict the information provided by the ip(7) man page [3]: > When a process wants to receive new incoming packets or connections, it > should bind a socket to a local interface address using bind(2). Only > one IP socket may be bound to any given local (address, port) pair. When > INADDR_ANY is specified in the bind call, the socket will be bound to > all local interfaces. I have attached a test-case which demonstrates this apparently conflicting behaviour. I would suggest adding a paragraph or comment that would explain this subtlety, as it can cause difficult to diagnose issues when using connected UDP sockets. [1]: http://www.unix.com/man-page/posix/3posix/connect/ [2]: http://linux.die.net/man/2/connect [3]: http://linux.die.net/man/7/ip -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.-- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
