<br><font size=2 face="sans-serif"><br>
</font><font size=3>We *do* allow &quot;ReceivingInterfaceAddr&quot; to
be something besides INADDR_ANY. &nbsp;That's the whole point of the existing
code.</font><font size=2 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif">Re: &nbsp;But my change does not disable
the ability to change the interface from the default. &nbsp;The address
parameter on the &quot;bind&quot; call specifies what destination addresses
the socket will accept in the arriving packets. &nbsp;If you use INADDR_ANY,
you can accept data which specifies any address as the destination address.
&nbsp;If you specifiy ReceivingInterfaceAddr as, for example, 192.168.38.24,
then your socket can ONLY receive data which was sent with 192.168.38.24
as the destination. &nbsp;Data sent to that socket with a multicast address
won't be received.</font>
<br>
<br><font size=2 face="sans-serif">To my understanding, the bind() call
is not setting the local interface on which we receive data, but instead
creates a &quot;filter&quot; on the incoming data that the socket will
accept . &nbsp;From the HP site http://docs.hp.com/en/B9106-90013/IP.7P.html:</font>
<br>
<br><font size=2 face="sans-serif">&quot;</font>
<table>
<tr valign=top>
<td bgcolor=white><font size=3 face="Arial">The application must also bind
to the destination port number in order to receive datagrams that are sent
to that port number. If the application binds to the address INADDR_ANY,
it may receive all datagrams that are sent to the port number. If the application
binds to a multicast group address, it may receive only datagrams sent
to that group and port number. It is not necessary to join a multicast
group in order to send datagrams to it.</font></table>
<br><font size=2 face="sans-serif">&quot;<br>
</font>
<br><font size=2 face="sans-serif">The only thing my change does is allow
the socket to receive all data sent to it. &nbsp;The socket uses the ReceivingInterfaceAddr
correctly when it sets the socket option IP_ADD_MEMBERSHIP. &nbsp;Try this
change out, and you will see that you are able to receive both unicast
and multicast on eth1 even when eth0 and eth1 have a multicast route. &nbsp;The
code works the same as before, except now you can receive multicast on
any interface you select.</font>
<br>
<br><font size=2 face="sans-serif">Xochitl</font>