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

Local name resolution (mDNS) is not working with fresh install of WSL 2 on Windows 11 #12354

Closed
1 of 2 tasks
solarslurpi opened this issue Dec 7, 2024 · 4 comments
Closed
1 of 2 tasks

Comments

@solarslurpi
Copy link

Windows Version

Microsoft Windows [Version 10.0.22631.4541]

WSL Version

2.3.26.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

Linux version 5.15.167.4-microsoft-standard-WSL2 (root@f9c826d3017f) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Tue Nov 5 00:21:55 UTC 2024

Distro Version

24.04

Other Software

On a fresh install of Windows 11 with WSL 2, local IP names ( e.g.: beanie.local) resolved correctly in PowerShell but not within WSL 2.

Steps Taken:

  1. Works in PS not in WSL:

    • Attempted to ping beanie.local insode Powershell, ping succeeded.
    • Attempted to ping beanie.local inside WSL 2, but the ping failed.
  2. Avahi Daemon - is this the problem?:

    • Installed and started avahi-daemon in WSL 2 to enable mDNS resolution.
    • Ran avahi-browse to check if the mDNS service was working, but the command hung and did not return any results.
    • Checked the avahi-daemon logs via journalctl and saw no errors during startup, but it didn't help with mDNS resolution in WSL 2.
  3. Firewall Configuration - is this the problem?:

    • Attempted to enable mDNS by opening ports in Windows Firewall:
      • Inbound Port: Allowed UDP traffic on port 5353 for mDNS.
      • Outbound Port: Allowed outbound traffic on port 5353 for mDNS.
    • Despite these changes, mDNS resolution still didn’t work within WSL 2.
  4. Manual Workaround - bummer...why is this so...frustrating?:

    • Edit /etc/hosts in WSL 2: As a workaround, manually added an entry for beanie.local in the WSL /etc/hosts file, mapping it to its IP address.
    • Configure /etc/wsl.conf: Adjusted DNS settings in /etc/wsl.conf to try to improve name resolution and restarted WSL after modifications.
  5. Issue with mDNS Service in WSL 2:

    • Despite configuring avahi-daemon and adjusting firewall settings, mDNS still didn't resolve .local addresses within WSL 2.
    • The issue is that mDNS multicast packets are not natively supported in WSL 2, and avahi-daemon or similar services cannot fully resolve .local addresses.

Resolution:

While manual entries in /etc/hosts provided a workaround, the mDNS service didn't work as expected within WSL 2, even after opening the necessary ports. The firewall changes were tested (allowing inbound and outbound UDP traffic on port 5353), but they did not enable mDNS support in WSL 2.

Conclusion - Huh? Please help?:

The problem was temporarily fixed by:

  • Editing /etc/hosts: Manually adding an entry for beanie.local in WSL 2's /etc/hosts file, mapping it to the correct IP address.
  • **Editing /etc/wsl.conf: add the following entry to /etc/wsl.conf:
# [network]
# generateHosts = false

Request for Help on Stack Overflow:

Any advice on getting full mDNS support working inside WSL 2 would be greatly appreciated."

Repro Steps

see above..

Expected Behavior

ping beanie.local resolves without having to modify a hosts file. All locals just resolve.

Actual Behavior

ping beanie.local does nto resolve unless added to hosts file and 3 chickesn are spun clockwise over my head.

Diagnostic Logs

No response

Copy link

github-actions bot commented Dec 7, 2024

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@LakhveerChahal
Copy link

Facing the same issue, I have created a script to manually update etc/hosts and added it in .bashrc as an alias. This way whenever the ip changes for .local domain, I can update the etc/hosts file manually through command.

@CatalinFetoiu
Copy link
Collaborator

thanks for reporting the issue. can you please check if the documentation we have about mDNS resolution resolves your issue? (https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#resolve-local-names-in-wsl)

Copy link
Contributor

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-file it as a new issue.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants