SO_IPLINK socket option lacks important functionality of SO_BINDTODEVICE

[Martin Decky]

The currently implemented SO_IPLINK socket option in the UDP server lacks one important functionality of SO_BINDTODEVICE in Linux.

In Linux, the SO_BINDTODEVICE option is used to allow the DHCP client to configure multiple network devices by binding multiple sockets to the same source pair (INADDR_ANY, 68), but on different network devices.

[Jiri Svoboda]

DHCP would not work at all if if could not specify which link to operate on (because the outgoing datagrams must not be routed). Instead of Linux SO_BINDTODEVICE HelenOS's DHCP uses HelenOS-specific SO_IPLINK which allows you to specify the service ID of the IP link to bind the socket to.

SO_IPLINK works to the extent that it will send datagrams to the right link (when you run enable DHCP only on one link). With multiple links, we probably hit several issues:

• the socket lib / socket layer in UDP does not know about SO_IPLINK and might refuse binding the same (addr, port) pair twice
• UDP assoc module cannot route received datagram to the right association
• DHCP should probably call setsockopt(SO_IPLINK, …) before binding the socket

[Martin Decky]

Yes, the SO_IPLINK option was apparently meant as HelenOS equivalent of SO_BINDTODEVICE from Linux. I am going to edit this ticket to reflect that.

However, this does not change the actual problem:

• The DHCP client sets the SO_IPLINK option only after it tries to bind the socket to the colliding source pair (INADDR_ANY, 68). This is not very helpful.
• The SO_IPLINK option does not lift the requirement for globally unique source pairs in the UDP server.

[Jiri Svoboda]

Pushed workaround in mainline,2325 (thx Jan Buchar). We close the socket as soon as we get an address - this allows for the other DHCP instance to succeed (possibly on a retry). I am working on final solution while doing a cleanup of the transport API in ​https://code.launchpad.net/~jsvoboda/helenos/nettlapi.

[Jiri Svoboda]

Fixed in network transport layer API rewrite - mainline,2343, mainline,2345 and mainline,2346.

After these changes we don't have the BSD sockets API anymore, so we can't talk about socket options now, but there is equivalent functionality. We create an UDP association passing an endpoint pair (inet_ep2_t) as a parameter. The application can set inet_ep2_t.local_link to the service ID of the link to listen on.

In addition to bypassing routing and sending messages on the correct link (which already happened before), now we also keep track of which link packets are received on and propagate this information as far as the demux code in UDP server (i.e. AMap). Based on inet_ep2_t.local_link AMap will select the proper association to deliver the datagram to.

That means DHCP can have associations open with multiple links at once now.