It looks like when new displays are added to the 1.8 Alpha2 CMS, the MAC address is being recorded incorrectly. The last display we added showed the MAC address as:
02:00:00:00:00:00
The Device we added is an Android Client running R58. We have not tested this with other client versions.
Very odd - they seem to be coming in correctly hereā¦ can you enable global logging and auditing for that display and see what is in the logs under the RegisterDisplay method?
??? I have audit logging turned on in the CMS.
After deleting the display and then re-adding it, the log with āPageā set to RegisterDisplay" shows this:
214221 de30cd8 2015-12-22 19:52 XMDS POST DEBUG Android RegisterDisplay Manage links to Display Group
214220 de30cd8 2015-12-22 19:52 XMDS POST DEBUG Android RegisterDisplay Updating Display Group. Android, 6
214219 de30cd8 2015-12-22 19:52 XMDS POST DEBUG RegisterDisplay serverKey: XXXXXXXX, hardwareKey: 59b73710-0e06-3872-a260-d92725e39978, displayName: Android
214218 e2cda7e 2015-12-22 19:52 XMDS POST DEBUG RegisterDisplay Manage links to Display Group
214217 e2cda7e 2015-12-22 19:52 XMDS POST DEBUG RegisterDisplay serverKey: XXXXXXXX, hardwareKey: 59b73710-0e06-3872-a260-d92725e39978, displayName: Android
I am wondering if I did that as you wanted? 
Screenshot of Displays screen:
You did exactly as I wanted, but unfortunately there isnāt enough logging in there 
Basically iām hoping to validate the incoming mac address parameter to find out what is happening: perhaps you could make these tweaks?
Dan,
I made the changes and here is the new log:
2392 0c6385f 2015-12-27 20:20 XMDS POST DEBUG Android RegisterDisplay Manage links to Display Group
2391 0c6385f 2015-12-27 20:20 XMDS POST DEBUG Android RegisterDisplay Updating Display Group. Android, 7
2390 0c6385f 2015-12-27 20:20 XMDS POST DEBUG RegisterDisplay serverKey: XXXXXXXX, hardwareKey: 59b73710-0e06-3872-a260-d92725e39978, displayName: Android, macAddress: 02:00:00:00:00:00
2389 9fbd6fb 2015-12-27 20:20 XMDS POST DEBUG Android RegisterDisplay Manage links to Display Group
2388 9fbd6fb 2015-12-27 20:20 XMDS POST DEBUG Android RegisterDisplay Updating Display Group. Android, 7
2387 9fbd6fb 2015-12-27 20:20 XMDS POST DEBUG RegisterDisplay serverKey: XXXXXXXX, hardwareKey: 59b73710-0e06-3872-a260-d92725e39978, displayName: Android, macAddress: 02:00:00:00:00:00
If I read that right, it looks like the MAC address is being sent by the client that way.
Youāve read that exactly right - so for some reason the client thinks that is the MAC address. That code hasnāt changed at all for quite some time, so its probably not specific to R58. It is happening for all your devices?
No just one device. It is not rooted, but I donāt know if that makes a difference.
Do you have anything install on there that might try and create a pseudo network adaptor? or perhaps a dongle of some description?
Is the Wifi Adaptor enabled?
AVG Anti-Virus is the only thing I can see that might do that. It is running Android 6.0.1 Security Patch Level 1 2016. But it was I think on Android 6.0 when we first saw this.
Wi-Fi Adapter is enabled.
It is a Nexus 5 we use for demonstration purposes sometimes, so not a big deal at all if it doesnāt work. But is interesting.
I could try to remove the AVG from it the next time we blow out the database and see what happens when we reconnect the device.
Weāve not tested with Android 6 as yet, although we do plan to do so once adoption on set top boxes picks up. That being said we arenāt aware of it causing any issues.
If the wifi-adaptor is enabled then it should be using the standard android calls to get the MAC address of that adaptor - I canāt see AVG blocking that, although I suppose it is possible.
Iām not sure what else to suggest at this point - it seems something odd with that device - unless of course that really is the MAC address 
I am thinking the enhanced security and a focus to prevent unauthorized tracking of devices and users, may have something to do with it as is shown here. The MAC addresses will show up as
02:00:00:00:00:00
Google says this is intentional so I would guess that on Android 6 root will be require and then the method Xibo uses to retrieve the MAC address of the adapters will also need to be changed to read
/sys/class/net/wlan0/address
and whatever other adapters may need to be read.
Broken in the name of security. 
Update - Changed the post topic to match the true problem.
That is rather unfortunate - we will have a think about how we might be able to work around that change and release something in R60.
At a minimum we will fall back on the device ID if we get this ādummyā mac address.
I am working on Android x86 6.0 with an Intel Compute Stick and VirtualBox, so the OS is already rooted. I see a ācorrectā MAC address.
Thanks for letting us know - it might be that androidx86 has provided some sort of fallback support for getting the mac address. It is good to know this and we will look into why that works.
I tested it on an actual Android 6 player (Amlogic TX8). The MAC address function also works on that one.
However: Iām building a Cordova app and there the MAC address returns 00:02 etc on iOS. So I have an if statement if I get that MAC address, I use the device.guid (which is actually an app guid on newer versions of iOS/Android) and I parse that into the MAC address.
Weāve added additional functionality to provide various fall backs for getting the wifi/ethernet MAC address from android itself or from the file system (as indicated by cslaughter).
The MAC Address is used in the CMS for informational purposes and for Wake On Lan (if supported by the device). I donāt think the device.guid would work in this case.
That being said, it does seem fairly reliable with our fall back code - I am not sure if you can do that from Cordova though.