net: dns: Fix DNS dispatcher for multiple network interfaces

[kica-z]

When having multiple interfaces the dns dispatcher falsely flags interfaces with the same port and address_family as duplicates. This leads to problems when for example using MDNS.

@NilsRuf-EH thanks for pointing that out.

[rlubos]

Doesn't explicit check for socket FD make other checks kind of pointless? It's not that you can have a socket that is bound to two different ports...

[jukkar]

We should probably check the addresses instead of socket descriptor values.

[kica-z]

@rlubos i think you are right.

@jukkar so we would compare net_sin(&ctx->local_addr)->sin_addr.s_addr == net_sin(&entry->local_addr)->sin_addr.s_addr as well as the port right? And since no two interfaces should have the same IP assigned this would also solve the issue.

[kica-z]

Will this also be called for interfaces that are down or have no address assigned?

[jukkar]

we would compare net_sin(&ctx->local_addr)->sin_addr.s_addr == net_sin(&entry->local_addr)->sin_addr.s_addr as well as the port right? And since no two interfaces should have the same IP assigned this would also solve the issue.

It needs to be a bit more complicated as IPv6 needs to be checked too. Your example address check only validates IPv4 address.

[kica-z]

In short: The second interface was detected as a duplicate by the dispatcher since it had the same address family and port as the first interface (due to MDNS multicast).

@NilsRuf-EH as I will be absent the next few days could you have a look again at what the log output was in detail?

[jukkar]

If we have ports and family the same, then to separate them, the network interface is the only left thing that we can use.

[NilsRuf-EH]

In short: The second interface was detected as a duplicate by the dispatcher since it had the same address family and port as the first interface (due to MDNS multicast).

@NilsRuf-EH as I will be absent the next few days could you have a look again at what the log output was in detail?

Sorry for the late reply. I am trying to debug this issue further. Below is a part of the log showing how the system should respond (with our current patch).
Especially the last line is relevant where the net context is bound to UDP 5353.

[00:00:00.056,000] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Service WEST_TOPDIR/zephyr/subsys/net/lib/dns/mdns_responder.c:47 has 2 pollable sockets
[00:00:00.074,000] <dbg> net_sock_svc: socket_service_thread: (net_socket_service): Monitoring 2 socket entries
[00:00:00.086,000] <inf> net_mdns_responder: REGISTER DISPATCHER STARTS HERE
[00:00:00.094,000] <dbg> net_sock: zsock_socket_internal: (main): socket: ctx=0x2000740c, fd=5
[00:00:00.105,000] <dbg> net_ctx: net_context_bind: (main): Context 0x2000740c binding to UDP 224.0.0.251:5353 iface 2 (0x200018b8)

However, with the current (unpatched) code this never happens and incoming mDNS requests are not being forwarded to the responder.

As discussed above, comparing addresses and ports is not sufficient in this case.
Using the sockets to distinguish the entries works (although it might not be that clean).
I will try to use the network interfaces for that.

[kica-z]

@jukkar do you think comparing sockets will be sufficient? Those should be interface, protocol and port specific so the distinction can be made as required. Might there be a reason why we shouldn't just compare the fds of the two sockets in question?

[jukkar]

Socket numbers are unique, how could that help here as mentioned in #79588 (comment)

[jukkar]

@kica-z I have alternate implementation proposal at #79917. I did not test it much but verified that it can now listen to multiple network interfaces. If possible please try it and report if it works for you.