[Interest] QUdpSocket, QNetworkDatagram and QNetworkInterface

[Nuno Santos]

Thiago,

Thanks so much for this super detailed and informative reply. All my questions are clarified now.

Thank you!

Best regards,

Nuno

> On 29 Oct 2019, at 22:06, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> 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
> 
> 
>