Update ESP.getChipId() to take new OTP bytes into account

[whyameye]

I read in #921: "ESP sets its MAC address as a concatenation of 3 fixed bytes and 3 unique bytes." I think you mean that the 1st 3 bytes of the MAC address are the same between all 8266s. However, looking at the MAC addresses of my 12Es, some have 1st 3 bytes 18:FE:34 and some have first 3 bytes are 5C:CF:7F. Moreover I just purchased a 12F and its 1st 3 bytes are 60:01:94.

I'm concerned about this because I have been using getChipId as a unique identifier for all my 8266s. But now that I see that the 1st 3 bytes of the MAC address are perhaps not fixed after all, I wonder if it is possible that the last 3 bytes may not be unique between different runs of 12Es or between the 12E and 12F.

[kaeferfreund]

For this purpose I use the complete macadress as an id (with the separators removed). For now all have been unique.

[Humancell]

Yes ... you really MUST use the entire MAC address to ensure uniqueness. It's quite common that a vendor ID (the first three bytes) might run out ... it's only good for 16,777,215 unique IDs or less. A vendor will then go obtain a new vendor ID to use.

[igrr]

There are now more OTP bytes used to set MAC address because we have run out of space with three bytes. getChipID doesn't take these new bytes into account, it has to be updated.

Edit: using MAC address as unique ID a good approach for now.

[d-a-v]

This is a two years old thread tagged with milestone 2.5.0.
The issue is more true today with the number of esp8266s out in this world.
ESP.getChipId() is 32 bits.
We can change it to be 64 bits to return the full 48bits mac address.

[whyameye]

Ok but I wonder if at this point it would be best if we had backward compatibility on this, so maybe a bool flag that maybe defaults to the 32 bit version would be good?

[Makuna]

Is there any reason that we could not just add one that returns a 64 bit value?
Further, using the MAC address directly has complications if the sketch also changes the mac address.

There is a register for chipid, but it doesn't seem to be used for the ESP.getChipId() aka system_get_chip_id();

It would be nice to get a few samples from people who run the following simple sketch and copy their captured serial data. From my esp8266, I can see no relationship between the unmodified mac address upper bytes and any of these registers.

@igrr I also wonder why the chipid register is not used for the actual chipid?

#include <ESP8266WiFi.h>

void setup() {
  Serial.begin(115200);
  while (!Serial);
  Serial.println();
  
  uint32_t mac0 = MAC0;
  uint32_t mac1 = MAC1;
  uint32_t chipid = CHIPID;
  uint32_t apiChipId = ESP.getChipId();
  String macAddress = WiFi.macAddress();

  Serial.print("mac0 = ");
  Serial.println(mac0,HEX);
  Serial.print("mac1 = ");
  Serial.println(mac1, HEX);

  Serial.print("chipid = ");
  Serial.println(chipid, HEX);
  Serial.print("apiChipId = ");
  Serial.println(apiChipId, HEX);

  Serial.print("macaddress = ");
  Serial.println(macAddress);
}

void loop() {}

[d-a-v]

mac0 and chipid seem to not have much "entropy"
mac1 seems to be (chipid >> 8)|0x02000000

if the sketch also changes the mac address

Mac Address is hardcoded and can only be changed at runtime right ?
We could backup the STA ethernet address on boot.

mac0 =       0xc7840000
mac1 =       0x0200d1ce
chipid =     0x5a00b000
apiChipId =  0x00d1cec7
macaddress = 18:FE:34:D1:CE:C7

mac0 =       0x51500000
mac1 =       0x0200c3ad
chipid =     0x6400b000
apiChipId =  0x00c3ad51
macaddress = 5C:CF:7F:C3:AD:51

#include <ESP8266WiFi.h>
void setup() {
  Serial.begin(115200);
  Serial.println();
  uint32_t mac0 = MAC0;
  uint32_t mac1 = MAC1;
  uint32_t chipid = CHIPID;
  uint32_t apiChipId = ESP.getChipId();
  String macAddress = WiFi.macAddress();
  Serial.printf("mac0 =       0x%08x\n", mac0);
  Serial.printf("mac1 =       0x%08x\n", mac1);
  Serial.printf("chipid =     0x%08x\n", chipid);
  Serial.printf("apiChipId =  0x%08x\n", apiChipId);
  Serial.printf("macaddress = %s\n", macAddress.c_str());
}
void loop() {}

[Makuna]

The current Mac address is composed of parts of MAC0 & MAC1 (lower three bytes) and some magic numbers for the upper three bytes. The upper three bytes seem be to be one of a small set of static values (0x18fe34, 0xacd074, 0x600194, 0x5ccf7f, ?) across all esp8266.

mac address lower three bytes = ((MAC1 & 0x0000ffff) << 8) | (MAC0 & 0xFF000000) >>24)
These same ones are used for the chip id api.

There seems to be at least one byte in MAC0 that is unique but not used, (MAC0 & 0x00FF0000).

I have seen code that uses the third byte (MAC1 & 0x00FF0000) to switch which of the static sets of values are used for the upper part of the mac address. But I am pretty sure it was wrong.

Looks like the chipid register isn't very unique.

Wemos D1:
mac0 = 0x466F0000
mac1 = 0x0200100A
chipid = 0x1700B000
apiChipId = 0x00100A46
macaddress = 60:01:94 : 10:0A:46

Node MCU:
mac0 = 0xF5840000
mac1 = 0x0200F90F
chipid = 0x0000A000
apiChipId = 0x00F90FF5
macaddress = 18:FE:34 : F9:0F:F5

[d-a-v]

So what about

• using ((mac0<<40) | ((chipid>>24)<<56) | macAddress)
  your two examples would give 6F:17:60:01:94:10:0A:46 and 84:00:18:FE:34:F9:0F:F5
• prepare it before users have a chance to live-change mac address
• api: uint64_t ESP.getChipId64()