[Interest] QUdpSocket, QNetworkDatagram and QNetworkInterface

[Thiago Macieira]

On Tuesday, 29 October 2019 12:12:37 PDT Nuno Santos wrote:
> Hi,
> 
> I’m trying to understand how does Qt decides which QNetworkInterface will be
> used when a writeDatagram is called.

The one you passed. Otherwise, it doesn't decide.

> I’m currently on a system that has both cable and wifi connections
> available, however, when doing a QUdpSocket writeDatagram the packets are
> being sent from the wifi adaptor, at least this is what I can infer from
> the IP address that comes on the packet when it arrives the other machine.
> What puzzles me is that supposedly, a cable connection is faster than a
> wifi connection.

You cannot infer which interface a packet was sent on from the IP address it 
included in the sender. It's entirely possible to use one interface's IP 
address while sending on another.

> While investigating the Qt documentation, it seems that I can use the
> writeDatagram function of QUdpSocket and specify on the QNetworkDatagram
> which interface I want to use by using the setInterfaceIndex function.

Or by specifying the interface index in the QNetworkDatagram at the moment of 
sending it. This allows you to send each datagram on a different interface, if 
you so choose.

> Is there anyway of knowing which network interface will be used by a
> QUdpSocket when transmitting data via writeDatagram? Or should I explicitly
> setInterfaceIndex on QNetworkDatagram and use the writeDatagram
> QNetworkDatagram variant function in order to have full control?

If you set the interface, it's the one you set.

If you didn't, then I'll argue that you shouldn't need to know. If you didn't 
need to set the interface, that means you don't care which interface gets 
used. The OS will consult the routing tables (there can be more than one!) and 
will decide how to send. It's a mix of shortest address matches and the 
route's metrics. It's supposed to have been properly configured for best 
performance.

For example, on my system:
$ ip route
default via 10.54.75.1 dev enxf8cab86aba42 proto dhcp metric 20100 
default via 10.24.8.1 dev wlp58s0 proto dhcp metric 20600 
10.24.8.0/22 dev wlp58s0 proto kernel scope link src 10.24.8.76 metric 600 
10.54.75.0/24 dev enxf8cab86aba42 proto kernel scope link src 10.54.75.138 
metric 100 
169.254.0.0/16 dev vboxnet0 proto kernel scope link src 169.254.84.110 
linkdown 

The two direct routes (via broadcast) have metrics between 100 and 1000, so 
the system will use those for sending whenever possible. the default routes 
have 20000 + the interface's own metric, so the kernel will choose to use the 
wired interface in preference over the wireless.

This of course depends on how your system was set up. If the metrics aren't 
what you wanted, please consult your network manager daemon's documentation.

You can also confirm by using the "ip route get" command:
$ ip route get 1.2.3.4
1.2.3.4 via 10.54.75.1 dev enxf8cab86aba42 src 10.54.75.138 uid 1000 
    cache 
$ ip route get 10.24.8.1
10.24.8.1 dev wlp58s0 src 10.24.8.76 uid 1000 
    cache 
$ ip route get 10.54.75.01
10.54.75.1 dev enxf8cab86aba42 src 10.54.75.138 uid 1000 
    cache 


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products