Who is still having an issue with client names in the Meraki Dashboard?

[PhilipDAth]

Many people are affected by the MDNS (or perhaps LLMNR) name being displayed in their dashboard, which appears as a GUID rather than the actual machine name.

Who is having this issue with WINDOWS computers that can try some things out for me?

[RaphaelL]

I do , not sure I can tweak things on my side. I do not have admin rights on my computer

[Ralph_at_Sharp]

I had been seeing this issue for 6+ months. Items that I had renamed will sometimes revert. 

[PhilipDAth]

Can I get you two to run this command from PowerShell and post the ProcessNames?  It shows all the MDNS services running on your machines.

Get-NetUDPEndpoint -LocalPort 5353 | Select-Object LocalAddress,LocalPort,OwningProcess,@{ Name="ProcessName"; Expression={((Get-Process -Id $_.OwningProcess).Name )} }

This is the list of MDNS services running on my machine:

chrome

TeamViewer_Service

Of note, the Windows MDNS service is not running on my machine.  So on my machine, only chrome and TeamViewer_Service can advertise a MDNS name.

Also, are either of you running Windows Firewall?  If you are, what does it show as your current location?  Domain, private or public?

What would also be helpful, but much more painful, is whether you can leave a long-running capture on port 5353 (MDNS port).  If you can, filter it on your machine's MAC address.  Can you see the name your machine is advertising in the MDNS packet?  Can you see your machine advertising any other names, such as GUIDs, from any other MDNS service running on your machine (from the PowerShell list above)?

[RaphaelL]

LocalAddress LocalPort OwningProcess ProcessName
------------ --------- ------------- -----------
:: 5353 2800 svchost
0.0.0.0 5353 29096 chrome

Of course running Windows Firewall.

I'm going to run a pcap on port 5353

[PhilipDAth]

>Of course running Windows Firewall.

I ask that because some companies used third party products, like CrowdStrike, Sentinel One, etc.

[PhilipDAth]

I just ran the Powershell again.  This time I had svchost in the list.  So I think I DO have the Windows MDNS service active.  It just isn't running all the time.

[PhilipDAth]

What location does Windows Firewall report it is in?

What I am wondering is does the MDNS service change the information that it advertises depending on what kind of network it thinks it is attached to.  For example, does it advertise a GUID when it thinks it is attached to a "Public" network, and perhaps use the machine name when attached to a "Private" network.

[PhilipDAth]

I have left multiple captures running using a filter like:

ether host 58:1c:xx:xx:xx:xx and port 5353

I have not caught my machine sending any MDNS announcements.  I must have disabled this quite some time ago for my organisation (I can't remember).  I am also connecting via WiFi.

Did you manage to capture any MDNS packets of your machine announcing its name (GUID or otherwise)?

Do you have the issue on both WiFi and wired machines?

[grepaly]

LocalAddress LocalPort OwningProcess ProcessName
------------ --------- ------------- -----------
::1               5353          7528 mDNSResponder
::                5353         38468 chrome
192.168.108.153   5353          7528 mDNSResponder
172.25.160.1      5353          7528 mDNSResponder
172.20.10.2       5353          8952 TeamViewer_Service
10.32.142.145     5353          7528 mDNSResponder
0.0.0.0           5353         38128 chrome

 The packet capture is still running.

[PhilipDAth]

I have not seen the mDNSResponder before.  What is this process?  Have you got Apple Bonjour installed?

[grepaly]

With Chrome, this should be the feature:

[PhilipDAth]

This is interesting - if it is Chrome that is announcing the MDNS name.  I found out that Windows also has this setting.

https://learn.microsoft.com/en-us/ecdn/how-to/disable-mdns

What I want to do is capture a machine advertising a name via MDNS, and then determine what is advertising that name.  Once I understand what is sending the advertisements, then we are a significant step forward in mitigating the issue.

I don't experience this issue in our network, but we also use Chrome Enterprise, and it is possible that if it is Chrome advertising the MDNS name, we have disabled that setting.

If you are experiencing this issue, can you also try the "Resolve-DnsName" and "ping" commands that I asked RaphaelL to try below, and let's see what happens in your case as well.  After doing each of those commands, I want to know if the name in the Dashboard updates within 5 minutes.

[grepaly]

Yep, I am trying to prove what really is. It seems that my computer is not advertising it at the moment, only my sons iphone and macbook pro. Which are actually changing the name quite frequently. So it is not only random, but it is also changing. Plus I am at home, here I have only a Meraki AP, no MX. I will keep digging.

[PhilipDAth]

Could you try having a play with the Apple privacy settings for networks.  Perhaps one of these is doing it.

[PhilipDAth]

@RaphaelL , can you try running this PowerShell command on a machine whose name does not display correctly in the Meraki Dashboard?  This needs to be another machine in the network (not your local machine), as I need the packet to pass through some piece of Meraki network equipment.

Resolve-DnsName -Name <ip address>

I get a response like this on my machine:

Resolve-DnsName -Name 192.168.x.x

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
xxx.xxx.168.192.in-addr.arpa.   PTR    1200  Question   PID-2023

If that doesn't update the Merai Dashboard, can you try:

ping <machine name>.local

 That should cause the machine to respond with its name in an MDNS packet.

I suspect that one of these two options should cause a machine's name to display correctly in the dashboard.

[RaphaelL]

I'm 100% remotly so there are no other machines on my LAN currently.

To your latest question , we have user connected to MX , MS , MR.

[PhilipDAth]

I just had a user bring in a notebook from another company, and their notebook name is showing up correctly in the Meraki Dashboard.

Now I am wondering if it is related to the makeup of the kit in the Merai Dashboard, rather than the machine configuration itself.  We don't have any control over the other companies' machines or configurations.

For people experiencing this issue, how are those machines connecting to the network?  Via WiFi?  Directly to an MX?  Via a Meraki switch?

This machine was plugged in via a wired connection directly to an MX for network access.

[IronNel]

We have the issue when users are hard lined. We have 9300's as our core switches and MS210's as our end user connected switches. 

[grepaly]

Well, we don't really have devices which are directly MX connected. But through MS and MR, definitely it happens. Network with 230 clients (corporate, guest, iot), about 90 exhibit the issue, about 40 have proper company well-formed names and the other 100 is the remaining (phones, printers, etc.). I really have no idea why my devices stopped doing it.

[grepaly]

You can actually make the thing happen with this page: https://browserleaks.com/webrtc 

I mean, send the packet. Whether Meraki picks it up or not, it is another story. E.g. in my home MR only network, somehow I can not make it to pick it up. In another (big) wireless only network, most devices are having the anonymized names.

I wonder is there a way to attach here a pcap? I have some captures.

I also ran an avahi-browser in the same network, on a Linux. That does not pick it up the names either. When looking at the raw data with ngrep, I can see them incoming. But the avahi does not report them.

[PhilipDAth]

I left a long-running capture on my machine, and could not capture an MDNS broadcast with any name (mind you, I don't have the issue).  I was using Chrome.

I have a Linux machine running Avahi, and its name appears correctly in the Meraki Dashboard.

I need to hunt out a client's network where this happens now to try and collect more information.

[grepaly]

Did you check the setting in Chrome? (chrome://flags/#enable-webrtc-hide-local-ips-with-mdns)

Did you try the site I mentioned? https://browserleaks.com/webrtc

A screenshot from my captures.

[PhilipDAth]

I did try, but I was not able to capture what you have shown.

This is a really big hint that the name is coming from WebRTC sessions from Chrome.  I will give this another try.

[PhilipDAth]

As a matter of interest, do you use Chrome Enterprise:

https://chromeenterprise.google/

Or the standard user downloadable version?

We are using the Enterprise version.

I think if you go to this link:

chrome://management/

And it says it is managed by your organisation - you are using the Enterprise edition.

[PhilipDAth]

I have had a good play with this - and I think you have cracked it.

Chrome (and probably Edge) generates MDNS packets with GUID-like host names when using WebRTC.  The website you provided is the easiest way to facilitate this for testing purposes.

https://browserleaks.com/webrtc

If this setting:
chrome://flags/#enable-webrtc-hide-local-ips-with-mdns
If set to disabled, the GUID names go away.

If set to enabled, the GUID names get advertised via MDNS.

I will now consider potential solutions, now that we understand the source of these packets, which are causing issues with the Meraki Dashboard client names.

[RaphaelL]

That's odd and so random. 

Chrome is managed by enterprise. 

chrome://flags/#enable-webrtc-hide-local-ips-with-mdns  is set to default

Joined the SSID , mDNS name was correct

Launched the webRTC leak test , mDNS was correct and the same.

I don't know how and when but my mDNS name will change to a GUID and Meraki will pick it up.

[PhilipDAth]

Do you use WebRTC (Teams in a Web browser, Zoom, Google Meet) at all?

It would be great to know which specific MDNS service being advertised that Meraki responds to.

I wish there were a way in the dashboard to 'reset' the name that the Dashboard has learned to make testing easier (to allow it to re-learn).

I'll try to get my hands on a test machine that I can configure using static IP addresses (no DHCP learning) and attempt to advertise specific packets to force the confirmation of the issue.

[RaphaelL]

I don't ever use WebRTC , maybe once every few months.

I'm still trying to capture when the name will suddenly change.

[grepaly]

Guys,

let us go step by step. The update in the dashboard, I am not sure that will be instant.

When you open https://browserleaks.com/webrtc, do you see the random ID in the SDP Log window?

[PhilipDAth]

I have observed this, and it is also evident in a Wireshark capture.

I believe this is a significant cause of what causes the Meraki dashboard to display the GUID-style names.

What I want to do is set up a test machine, have the Meraki Dashboard learn a name (such as via DHCP - not sure yet), and then use your WebRTC page to try and trigger a name change.

I then want to try doing some MDNS announcements via Python to confirm I can influence it and how long it takes.

I want to create a repeatable case.

I am also curious about the impact of the "client tracking" setting on this.

https://documentation.meraki.com/MX/Monitoring_and_Reporting/Client-Tracking_Options

I am also curious if it is affected by the type of access (MX, MR and MS).

Once I have something repeatable, where I can say "this" causes "that" with "these" settings on "these" devices, and you can reproduce it by doing "this", I'll try reaching out to Meraki to seek their input.

This is the kind of information a developer wants.  Otherwise, it is "all a bit too difficult", especially when you are asking for a significant behaviour change that can have wide-ranging ramifications.

It may be that companies running into this issue may need to use managed Chrome/Edge, and configure it not to use MDNS broadcasts for WebRTC.  For larger companies, this is a simple change.

There must be a business case for Meraki to justify expending developer effort on fundamentally changing the existing system.  You must be able to clearly state what problem is being solved and what the benefits will be.  If you can shrink the "effort" component, you don't need as much justification.

I do support Meraki offering greater flexibility in this area (client naming).  I realise that to achieve this, the above must be true.  🙂

[RaphaelL]

I was able to reproduce the "issue". 

Client name was correct in the dashboard.

Launched the webRTC tools

Noticed the GUID in the webRTC tools.

Seconds later the client name was changed in Meraki to the GUID seen in webRTC.

[PhilipDAth]

That just saved me from having to set up a test environment.  That is now one conclusive cause of the issue.  This is a giant step forward; now we know one of the root causes.

I'm now pondering the potential solutions.

I'll also reach out to Meraki.

[Stuart4]

We operate a fairly large Meraki network, 334 MX's and growing.  We have around 10k workstations, all built using Intune to the same standard/policies.

This issue is very random, and very frustrating.  Some devices appear fine, majority of Windows devices do not.  I have raised a ticket with Meraki, and they confirmed to me that Meraki detects and sees the 3 fields:

Mdns_name

Netbios_name

Dhcp_name

The Netbios and the Dhcp fields contain the correct hostname information, but Meraki still uses the Mdns field to populate the client description field.

My argument to Meraki is that if the info is available, then allow us the customer to see it in the GUI.

[grepaly]

This issue happens since ages, but the guys at Meraki do not listen. They built a super nice dashboard, and then we are not able to identify most of our devices.

[PhilipDAth]

Speaking of client tracking, I am using the default "track by MAC address".

For others experiencing this issue with WINDOWS computers - what is your client tracking set to (Security / SD-WAN/IP Addressing) ?

[RaphaelL]

Also using the default here.