Skip to main content

SO_BINDTODEVICE

7 replies [Last post]
ralphdj
Offline
Joined: 2009-07-22

Would it be possible to add this to SocketOptions ?

For example:

Under Linux packets will be forwarded to all multicast listening sockets (joined to the same group), regardless of the interface they joined on. For received UDP packets the Linux code loops over all sockets comparing the incoming interface id with the bound one: if the socket does not have the bound interface set then it will skip this test.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ralphdj
Offline
Joined: 2009-07-22

The problem relates to a multi-homed Upnp / DLNA device on a Linux box which needs to put different URLs on different interfaces.

For SSDP the server needs to listen on all interfaces i.e. it joins the same multicast group / port combination on each interface and then reply on the particular interface
when a message comes in.

Binding to the multicast address would be the solution, but Linux does not allow binding to the multicast address only the wildcard address - which results in the mutlicast traffic being replicated to all listening socket on different interfaces when a packet comes in on one interface (even the Loopback !). If the interface is set (or the bind to the multicast address worked) that would not happen.

I've tried the IPv4 Stack option to no avail.

ralphdj
Offline
Joined: 2009-07-22

It isn't possible to do this using the current API.

The workaround is a JNI to call IP_PKTINFO. No portability between Linux / Windows.

ralphdj
Offline
Joined: 2009-07-22

Yes - this is true: on Linux the BINDTODEVICE is only available on a raw socket and raw sockets are only allowed when running as root.

The problem is that "joinGroup(groupSocket, interface)" on Linux does not result in the socket receiving multicast on a particular interface ... would it be possible to see how that code is implemented ?

It seems that (on Linux) the only way to request the socket to receive only incoming packets on a particular interface is to use the BINDTODEVICE option.

A multicast receive socket on Linux cannot be bound to the local IP as it would then only receive unicast. It therefore must bind to INADDR_ANY .. setting other options like MULTICAST_IF do not affect the receiver.

alanb
Offline
Joined: 2005-08-08

If your issue is that the MULTICAST_IF option (set via the setNetworkInterface method) isn't effective then try disabling IPv6 (by running with the java.net.preferIPv4Stack system property set to "true"). If that fixes your problem then you should find that it works as expected on jdk7 without setting the property.

On the other hand, if your issue relates to when there are multiple services on the same port (but different interfaces) then it is awkward on Linux due to the way that multicast support is implemented. You can workaround it by binding to the multicast address (although it more portable to bind to the wildcard address).

ralphdj
Offline
Joined: 2009-07-22

The problem relates to a multi-homed Upnp / DLNA device on a Linux box which needs to put different URLs on different interfaces.

For SSDP the server needs to listen on all interfaces i.e. it joins the same multicast group / port combination on each interface and then reply on the particular interface
when a message comes in.

Binding to the multicast address would be the solution, but Linux does not allow binding to the multicast address only the wildcard address - which results in the mutlicast traffic being replicated to all listening socket on different interfaces when a packet comes in on one interface (even the Loopback !). If the interface is set (or the bind to the multicast address worked) that would not happen.

I've tried the IPv4 Stack option to no avail.

alanb
Offline
Joined: 2005-08-08

I assume you mean StandardSocketOption enum rather than the legacy SocketOptions interface. In any case, doesn't SO_BINDTODEVICE require root privileges? Furthermore, it's not a socket option that is supported on many operating systems. It seems more suited to be an implementation specific socket options (not something for the standard socket options).

ralphdj
Offline
Joined: 2009-07-22

Ye