Directing outgoing traffic

As explained in section 3.6.1 one has to be able to transmit individual HELLO packets on every network interface due to link-sensing. A problematic scenario would be if a node was to run olsrd on two interfaces that are configured with IP addresses in the same subnet range. Transmitting to a broadcast-address in this subnet using one UDP socket^6.2 would result in traffic only being sent on the interface that has the first entry for this subnet in the routing-table. Say a node wishes to run OLSR on the interfaces eth0 and eth1. The interfaces are configured as follows:

eth0: IP:        192.168.1.1
      NETMASK:   255.255.255.0
      BROADCAST: 192.168.1.255
eth1: IP:        192.168.1.2
      NETMASK:   255.255.255.0
      BROADCAST: 192.168.1.255

The routing table contains the following entries:

DESTINATION     GATEWAY     NETMASK         INTERFACE
192.168.0.0     0.0.0.0     255.255.255.0   eth0
192.168.0.0     0.0.0.0     255.255.255.0   eth1

If the host sends a UDP packet to 192.168.1.255, it will now be transmitted through eth0 only.

Another problem would be a situation where one uses the 255.255.255.255 broadcast address or as we will later see, when IPv6 multicast is to be used. In these cases, all messages will always be transmitted on all interfaces. Clearly the ability to direct traffic explicitly to interfaces is needed. To be able to gain such control of traffic, the sockets used for transmission has to be mapped to physical interfaces. One socket is created for every interface that participates in the OLSR routing domain. This socket is bound to the interface using the SO_BINDTODEVICE setsockopt(2) call. In Linux one can bind several sockets to the same UDP port if they are bound to different interfaces using this setsockopt call. Unfortunately, this is a Linux specific way to do this, and this issue is one of the biggest problems if one is to port olsrd to other platforms. There is no standard POSIX way to bind sockets to devices.