[PATCH 1/1] ws2_32: Selectively bind UDP sockets to interfaces while still allowing broadcast packets (try 2, resend).

Erich E. Hoover ehoover at mines.edu
Thu Nov 17 10:03:45 CST 2011

On Wed, Nov 16, 2011 at 10:14 AM, Juan Lang <juan.lang at gmail.com> wrote:
> I know the style around here is to comment minimally, but I didn't
> find it clear what the behavior of this function is.  ...

The intended behavior of the function is to take bind() calls on any
name corresponding to a local network adapter and restrict the given
socket to operating only on the specified interface.  If the function
succeeds then the name for the bind() is changed to INADDR_ANY in
order to permit the receipt of broadcast sockets on the interface.
This behavior is only relevant to UDP sockets and is needed for
applications that expect to receive broadcast packets on a socket that
is bound to a specific interface.  Does that help?

> ...
> I feel a comment indicating that the function returns TRUE iff the
> function bound to a specific device, and that FALSE doesn't
> necessarily mean failure, is merited.

Fair enough, I think that by better describing the operation of the
function (like my explanation above) then that will be made clear.

> ...
> Why do all this outside the #ifdef SO_BINDTODEVICE guard?  I'd rather
> you just had a different implementation of the function when
> SO_BINDTODEVICE isn't present that issues the warning and does nothing
> else.

The idea was to only present the warning in a case where the passed
address would actually trigger an interface-specific bind.  I can
easily move the guard outside of the GetAdaptersInfo portion, but I
think at the very least the warning should only occur if the socket is
of type SOCK_DGRAM and the name is not INADDR_ANY.

> I'll let Alexandre comment on whether the approach itself is appropriate.

I believe I've addressed all the concerns he expressed with my
IP_PKTINFO approach, so I'm really hoping he'll like this approach.

Erich Hoover
ehoover at mines.edu

More information about the wine-devel mailing list