Ethernet MAC address is showing up instead of Wireless LAN MAC address

API Endpoint(s) and/or Zoom API Event(s)
v2/metrics/meetings/93221128976/participants?type=past
v2/metrics/meetings/93221128976/participants/16778240/qos?type=past

Description
*I am trying to get Zoom meeting details between 2 clients who have both ethernet & Wi-Fi connections. In the data response to the above mentioned APIs, the “*mac_addr” field in the response is that of the ethernet MAC address instead of the Wireless adapter MAC address. Please note the “network_type=Wifi” returned corresponds to Wi-Fi though in the same response.

Zoom Version: version=6.5.9.11873
network_type=Wifi
connection_type=P2P

Error?
Ethernet MAC address is returned instead of Wi-Fi MAC address in the API responses.

Please let me know how is the MAC address decided while responding when both ethernet/LAN & Wireless/WLAN MAC addresses are present?
And in this case when the “network” returned is “Wifi”, it’s expected to return Wireless MAC address.

Please let me know.

Hey @ucczoomaruba , looking into this for you!

Hi @gianni.zoom , any update on this?

Hi @ucczoomaruba , I haven’t heard back, but I’m going to try a different resource and need a bit more info from you. Please address the following in the private message I’m opening for you that you’ll see in your notifications:

Can you please query these endpoints again and provide the following:

  • zm-tracking-id from the response headers for each
  • screenshot showing the response mac_addr and network_type
  • production client id for app
  • proof that the ethernet MAC address is being returned vs. the wifi one

Hi @gianni.zoom , I have replied with necessary information over the private message.

Thanks so much @ucczoomaruba , investigating this.

Opened a service engineering ticket since I was not able to get the answers I need through internal knowledge bases. Waiting to hear back (ZSEE-180772).

1 Like

Hi @ucczoomaruba ,

Confirmed this is a flaw in the design. The designated team is working on resolving with respect to other design considerations, but there is no immediate fix date provided at this time. I will follow up with them next week after they’ve done some more assessing. Apologies there isn’t a proper fix or work around at this time.

Thanks @gianni.zoom for the updates.
Sure, I will wait for the next update.

1 Like

Hi @gianni.zoom
Any update on the issue: ZSEE-180772?

Hi @ucczoomaruba ,

The ETA for this update was Nov 15. It’s currently awaiting security sign off. Should see in the next changelog. The fix only works for new meetings once it’s in production. Thanks for following up and thanks for bringing up this up which resulted in a feature enhancement :slight_smile:

Thank you for the update @gianni.zoom . And glad my query helped’; a win-win :slight_smile: