net: dns: mDNS resolving fails when responder is also enabled #21970
Assignees
Labels
area: Networking
bug
The issue is a bug, or the PR is fixing a bug
priority: low
Low impact/importance bug
Comments
jukkar
added
area: Ethernet
priority: low
rveerama1
added a commit
to rveerama1/zephyr
that referenced
this issue
Feb 21, 2020
net_pkt_clone() initializes the original packet cursor and clone the packet. But it doesn't restore the cursor back to original position. Issue noticed when mDNS resolving fails when mdns responder is also enabled. net_conn_input(), in case of multicast packet, connection handler clone the packet and deliver to matching handler. Example case: dns_resolver and mdns_responder both register handlers for 5353 port. After first clone original packet cursor moved back to starting position. But first cloned packet cursor is set properly. Second time cloning makes cursor position to set to zero. Which makes second packet handler header unpacking goes wrong. Fixes zephyrproject-rtos#21970. Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
jhedberg
pushed a commit
that referenced
this issue
Feb 21, 2020
net_pkt_clone() initializes the original packet cursor and clone the packet. But it doesn't restore the cursor back to original position. Issue noticed when mDNS resolving fails when mdns responder is also enabled. net_conn_input(), in case of multicast packet, connection handler clone the packet and deliver to matching handler. Example case: dns_resolver and mdns_responder both register handlers for 5353 port. After first clone original packet cursor moved back to starting position. But first cloned packet cursor is set properly. Second time cloning makes cursor position to set to zero. Which makes second packet handler header unpacking goes wrong. Fixes #21970. Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#18797 introduced the possibility to enable both mDNS responder and resolver at the same time. Now all multicast packets are correctly received by each subsystem.
There is an issue now with a setup with 2 zephyr nodes with both resolver and responder enabled and actively resolving names. The resolver submodule will receive mDNS queries instead of only answers this will make name resolving fail.
The following call will fail because it only excepts to receive mDNS answers and not queries.
zephyr/subsys/net/lib/dns/resolve.c
Line 409 in 3d5c911
zephyr/subsys/net/lib/dns/dns_pack.c
Line 195 in 3d5c911
It will then call the mDNS resolver callback with a failed status.
The text was updated successfully, but these errors were encountered: