Open SynchronicIT opened 1 week ago
@SynchronicIT thanks for the report. You seem to have investigated this already in sources, are you able / do you plan to send PR for this?
Hi
I made a quick fix which checks the source port. I want to extend it and clean up and then provide a PR.
-- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient's and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
TERMS AND CONDITIONS : All contracts & agreements are carried out in accordance with SynchronicIT's general terms and conditions. Entry into the contract implies acceptance of the applicability of the general terms and conditions of SynchronicIT. The general terms and conditions are stated on our web page ( www.SynchronicIT.nl - click on "terms and conditions" - ), and a printed copy can be sent free of charge on request.
Op do 21 nov 2024 om 13:59 schreef Jukka Rissanen @.***>
@SynchronicIT https://github.com/SynchronicIT thanks for the report. You seem to have investigated this already in sources, are you able / do you plan to send PR for this?
— Reply to this email directly, view it on GitHub https://github.com/zephyrproject-rtos/zephyr/issues/81657#issuecomment-2491082292, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDJ3H2WKSG3SYBPVRSVPXST2BXKMNAVCNFSM6AAAAABSERXWZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJRGA4DEMRZGI . You are receiving this because you were mentioned.Message ID: @.***>
In the current mDNS implementation, all responses are sent to the multicast address. Independent of its source, unicast-response bit or one of the other cases mentioned in RFC 6732. Chapter 5.1, 5.4, 6.7 and introduction of chapter 6, derive different use-cases and when to use the unicast responses.
Unicast responses would allow lightweight clients or clients who do not have multicast access (read: docker images) to discover zephyr hosts and their services.
Changes to be made a in mdns_responder.c to send_response(..) which currently always creates a multicast destination address, but to follow the rules as specified by rfc6732. The first low hanging fruit would be to support the legacy or one-shot requests, by responding over unicast if the source port is not 5353.