The bind() system call is frequently misunderstood. It is used to bind to a particular IP address. Only packets destined to that IP address will be received, and any transmitted packets will carry that IP address as their source. bind() does not control anything about the routing of transmitted packets. So for example, if you bound to the IP address of eth0 but you send a packet to a destination where the kernel's best route goes out eth1, it will happily send the packet out eth1 with the source IP address of eth0. This is perfectly valid for TCP/IP, where packets can traverse unrelated networks on their way to the destination.
In Linux, to control the physical topology of communication you use the SOBINDTODEVICE socket option.
I'm considering adding support for SO_BINDTODEVICE, something like:
Ok, after trying this a bit I'm coming to the conclusion this is a poor approach. It's not a portable solution and on linux, where it is supported, it requires root privileges. Also, there are enough gotchas that making it work well isn't easy. The way to support multiple NICs seems to be through the kernel's routing tables. Hence, support for this will not be implemented.
Last edit: Robert McMahon 2017-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In a case where there are multiple NICs it might be nice to support binding the output interface.
Here's an article:
The bind() system call is frequently misunderstood. It is used to bind to a particular IP address. Only packets destined to that IP address will be received, and any transmitted packets will carry that IP address as their source. bind() does not control anything about the routing of transmitted packets. So for example, if you bound to the IP address of eth0 but you send a packet to a destination where the kernel's best route goes out eth1, it will happily send the packet out eth1 with the source IP address of eth0. This is perfectly valid for TCP/IP, where packets can traverse unrelated networks on their way to the destination.
In Linux, to control the physical topology of communication you use the SOBINDTODEVICE socket option.
I'm considering adding support for SO_BINDTODEVICE, something like:
iperf -c 192.168.1.5%eth0
iperf -c 192.168.1.5%eth1
Thoughts?
Last edit: Robert McMahon 2017-09-30
Ok, after trying this a bit I'm coming to the conclusion this is a poor approach. It's not a portable solution and on linux, where it is supported, it requires root privileges. Also, there are enough gotchas that making it work well isn't easy. The way to support multiple NICs seems to be through the kernel's routing tables. Hence, support for this will not be implemented.
Last edit: Robert McMahon 2017-10-02
here's a patch that supports this. Be wary of arp not working well when used.
Last edit: Robert McMahon 2017-10-02