[Interest] QUdpSocket, QNetworkDatagram and QNetworkInterface

[Nuno Santos]

Thiago,

>> 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.

I was trying to take advantage of this but I’m having an unpleasant surprise. Even after setting sender via QNetworkDatagram setSender API, the packet is arriving the other machine with the sender address of the router that is acting as switch in my local network. 

My local network has the main modem, which is connected to the internet. Then, there is an older wifi router from linksys only serving as a cable lan switch.

Do you have a clue why is this happening? This is completely ruining the previsibility I was expecting to have.

Thanks!

Best regards,

Nuno

> On 30 Oct 2019, at 07:13, Nuno Santos <nunosantos at imaginando.pt> wrote:
> 
> 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
>> 
>> 
>> 
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest