Mac Address Recorded Incorrectly On Android 6 (6 is Not Supported at this time)

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? :neutral_face:

Screenshot of Displays screen:

You did exactly as I wanted, but unfortunately there isn’t enough logging in there :frowning:

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 :smile:

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. :smirk:

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.

1 Like

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.