[Interest] QUdpSocket, QNetworkDatagram and QNetworkInterface

Jason H jhihn at gmx.com
Wed Oct 30 15:58:56 CET 2019 

Relevant RFCs:
https://tools.ietf.org/html/rfc2663 (1999 most popular)
https://tools.ietf.org/html/rfc1631 (1994)
https://tools.ietf.org/html/rfc3022 (2001)


> Sent: Wednesday, October 30, 2019 at 9:23 AM
> From: "Jason H" <jhihn at gmx.com>
> To: "Nuno Santos" <nunosantos at imaginando.pt>
> Cc: "Thiago Macieira" <thiago.macieira at intel.com>, interest at qt-project.org
> Subject: Re: [Interest] QUdpSocket, QNetworkDatagram and QNetworkInterface
>
> I think you're running into a NAT router (network address translation)
> You can configure your router to not do this, but that requires you to have an addressable network. NAT is generally used with cable modems because you only get the IP pf the modem. Then the kernel on the router takes care of distributing packets from where they came. Not sure how that works with UDP though.
> If you can't get your router of out NAT mode, you can normally configure a destination host for all of that stuff to be sent to. Also SOCKS5 proxies work, and I think there's some uPnP specs so applications can tell routers what they need (popular with games).
> 
> You might be able to fix the issue just by including the source IP in the UDP packet though.
> 
> 
> > Sent: Wednesday, October 30, 2019 at 4:42 AM
> > From: "Nuno Santos" <nunosantos at imaginando.pt>
> > To: "Thiago Macieira" <thiago.macieira at intel.com>
> > Cc: interest at qt-project.org
> > Subject: Re: [Interest] QUdpSocket, QNetworkDatagram and QNetworkInterface
> >
> > 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
> > 
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>

More information about the Interest mailing list