Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mDNS Resolver and mDNS Responder cannot be used simultaneously due to both attempting to bind port 5353 #72553

Open
besmarsh opened this issue May 10, 2024 · 0 comments
Assignees
Labels
area: Networking bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug

Comments

@besmarsh
Copy link
Contributor

Describe the bug
The Networking subsystem has support for mDNS, through the mDNS Resolver (part of more general DNS Resolver) and the mDNS Repsonder (specifically mDNS). Each of these work individually, but the two cannot be used together. This is due to both Resolver and Responder trying to bind the same port 5353 independently. Whichever one attempts the bind after the other (mDNS Responder) fails as the port is already in use.

It should be possible to enble the mDNS Resolver and mDNS Responder simultaneously.

  • What target platform are you using?

    • Target platform is a custom board based on the STM32H723VGT6
  • What have you tried to diagnose or workaround this issue?

    • Enabling logging for mDNS Responder (CONFIG_MDNS_RESPONDER_LOG_LEVEL_DBG) shows:
      <err> net_ctx: Port 5353 is in use!
      <dbg> net_mdns_responder: bind_ctx: (main): Cannot bind to mDNS IPv4 port (-112)

    • Debugging the networking subsystem shows that during initialisation:

      1. The DNS Resolver binds port 5353 (dns_init_solver() -> dns_resolve_init_default() -> dns_resolve_init() -> dns_resolve_init_locked() -> net_context_bind())
      2. The mDNS Responder attempts to bind port 5353 (mdns_responder_init() -> init_listener() -> bind_ctx() -> net_context_bind()) but fails with -EADDRINUSE (112) as the port is already bound.

To Reproduce
Steps to reproduce the behavior:

  1. cd zephyrproject
  2. west build -b <BOARD> -d build_mdns_sample zephyr/samples/net/mdns_responder/ -- -DCONFIG_DNS_RESOLVER=y -DCONFIG_MDNS_RESOLVER=y -DCONFIG_DNS_SERVER_IP_ADDRESSES=y -DCONFIG_CONSOLE=y -DCONFIG_LOG=y -DCONFIG_MDNS_RESPONDER_LOG_LEVEL_DBG=y (plus any options needed for logging backend)
  3. Flash target and run application

Expected behavior
mDNS Resolver and mDNS Responder should be able to co-exist. The port should probably only be bound once, with incoming traffic dispatched to Resolver or Responder handlers as appropriate, rather than the two subsystems existing independently and both attempting to bind the port.

Impact
Showstopper for applications requiring full mDNS functionality (Resolver and Responder)

Logs and console output

*** Booting Zephyr OS build v3.6.0 ***
[00:00:00.003,000] <inf> net_config: Initializing network
[00:00:00.003,000] <inf> net_config: IPv4 address: 192.0.2.1
[00:00:00.003,000] <dbg> net_mdns_responder: init_listener: (main): Setting mDNS listener to 1 interface
[00:00:00.006,000] <err> net_ctx: Port 5353 is in use!
[00:00:00.006,000] <dbg> net_mdns_responder: bind_ctx: (main): Cannot bind to mDNS IPv6 port (-112)
[00:00:00.006,000] <err> net_ctx: Port 5353 is in use!
[00:00:00.006,000] <dbg> net_mdns_responder: bind_ctx: (main): Cannot bind to mDNS IPv4 port (-112)
[00:00:00.006,000] <wrn> net_mdns_responder: Cannot start mDNS responder

Environment (please complete the following information):

  • OS: Windows
  • Toolchain Zephyr SDK v0.16.3
  • Commit SHA or Version used: Zephyr v3.6
@besmarsh besmarsh added the bug The issue is a bug, or the PR is fixing a bug label May 10, 2024
@aescolar aescolar added the priority: medium Medium impact/importance bug label May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Networking bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug
Projects
None yet
Development

No branches or pull requests

5 participants