-
Hello, friends!
Tell me, please, does someone know the order of UID allocation in STM32? Which bits of 96 are the least significant and are they unique?
I want to use the UID part to set the MAC address of the device.
There is a desire to buy a MA-M block of 1M addresses in IEEE and I will need 20 unique bits.
Or should I not register my own OUI at all, use a locally administered MAC address with unique 46 bits? -
Buy off the shelf chips with preprogrammed Mac addresses. They're cheap as chips and save a lot of hassle. Normally they have an i2c interface. Those 96 bits are only unique when compared against another 96 bits
-
Buy off the shelf chips with preprogrammed Mac addresses. They're cheap as chips and save a lot of hassle. Normally they have an i2c interface.
What kind of chips are you talking about? -
I use EUI-48 I2C EEPROMs from Microchip and they work well: https://www.microchip.com/en-us/products/memory/serial-eeprom/mac-address-and-unique-id-eeproms
-
If your product has volume, it may be economically viable to use your own MAC block. If so, You can use whatever mathematical method you find appropriate to condense the whole 96 bits into 20 bits. One idea would be using the onboard CRC hardware to generate a CRC32 from the UID, then use the lowest x bits from it.
If it is a small-run product, you should use some EEPROM with preprogrammed MAC address in it - 24AA025E48, 25AA256E48, etc. Those chips have a permanently locked sector holding the preprogrammed MAC address, while the rest of the chip is useable as a standard I2C or SPI EEPROM holding configuration data.
p.s. Octavo Systems, can you guys replace the 24AA32 in your SiP products with 24AA025E48 in the future? Having a MAC address preprogrammed would be very useful, and all your products have Ethernet support. -
Friends, I figured out the UID in STM - it's not a serial number, it's a mixture of production data: the position of the future chip on the plate, the plate number in the order and and the order number. Moreover, all this is in a funny mixture of formats: BCD, BIN, ASCII.
Separating any part gives a high probability of getting the same values in a short period of time.
As a result, I came to the conclusion: can not use the UID, the most reliable use of EEPROM with a sector of the global OID, the easiest way is to use a locally administrable OID and form it during firmware. -
Friends, I figured out the UID in STM - it's not a serial number, it's a mixture of production data: the position of the future chip on the plate, the plate number in the order and and the order number. Moreover, all this is in a funny mixture of formats: BCD, BIN, ASCII.
Once again, you can use UID, but you can not pick out its parts, instead some math has to be done to mix all of them down - basically hashing the whole thing. You can use the onboard CRC32 hardware for this, or you can invent your own math. Separating any part gives a high probability of getting the same values in a short period of time.
As a result, I came to the conclusion: can not use the UID, the most reliable use of EEPROM with a sector of the global OID, the easiest way is to use a locally administrable OID and form it during firmware.
If you are using those dedicated UID EEPROM chips, they come pre-programmed with complete MAC addresses ready to be used. If you are skipping the EEPROM, you need that algorithm and a constant OID. -
NuttX uses the CRC of the UID to get a locally administered MAC:Code: [Select]
stm32_get_uniqueid(uid);
crc = crc64(uid, 12);
/* Specify as localy administrated address */
priv->dev.d_mac.ether.ether_addr_octet[0] = (crc >> 0) | 0x02;
priv->dev.d_mac.ether.ether_addr_octet[0] &= ~0x1;
priv->dev.d_mac.ether.ether_addr_octet[1] = crc >> 8;
priv->dev.d_mac.ether.ether_addr_octet[2] = crc >> 16;
priv->dev.d_mac.ether.ether_addr_octet[3] = crc >> 24;
priv->dev.d_mac.ether.ether_addr_octet[4] = crc >> 32;
priv->dev.d_mac.ether.ether_addr_octet[5] = crc >> 40;
Don't forget that the MAC doesn't have to be unique globally, locally unique within a broadcast domain is enough.
fchk
-
p.s. Octavo Systems, can you guys replace the 24AA32 in your SiP products with 24AA025E48 in the future? Having a MAC address preprogrammed would be very useful, and all your products have Ethernet support.
I prefer the ex-Atmel AT24MAC402 over the Microchip 24AA025E48. The Atmel part gives you the full 256 byte EEPROM area and moves the read only UUID and MAC onto a second I2C address (eepromID+8).
fchk
-
NuttX uses the CRC of the UID to get a locally administered MAC:
Code: [Select]stm32_get_uniqueid(uid);
crc = crc64(uid, 12);
/* Specify as localy administrated address */
priv->dev.d_mac.ether.ether_addr_octet[0] = (crc >> 0) | 0x02;
priv->dev.d_mac.ether.ether_addr_octet[0] &= ~0x1;
priv->dev.d_mac.ether.ether_addr_octet[1] = crc >> 8;
priv->dev.d_mac.ether.ether_addr_octet[2] = crc >> 16;
priv->dev.d_mac.ether.ether_addr_octet[3] = crc >> 24;
priv->dev.d_mac.ether.ether_addr_octet[4] = crc >> 32;
priv->dev.d_mac.ether.ether_addr_octet[5] = crc >> 40;
Don't forget that the MAC doesn't have to be unique globally, locally unique within a broadcast domain is enough.
fchk
I think there is a danger of getting 2 identical numbers from 46 bits from crc64 from 96 bits. It's unreliable.
-
Totally unreliable. You will have a significant chance of a duplicate every few billion units.
If the whole 48 bits are random, you'd more likely conflict with a completely different device on the same network than two of your own conflicting with each other. -
Totally unreliable. You will have a significant chance of a duplicate every few billion units.
The CRC can give the same values, the distribution of the UID when buying an MCU is almost random, so the probability is much less than billions.
-
Totally unreliable. You will have a significant chance of a duplicate every few billion units.
If the whole 48 bits are random, you'd more likely conflict with a completely different device on the same network than two of your own conflicting with each other.
For several billion units you will see many collisions.
With 48 random bits you have a 50% chance of a duplicate with 20 million units - it's the classic birthday problem - people forget that they are not dealing with a \$n\$ objects but with \$\frac{n^2}{2}\$ pairs of objects to be compared for collisions. Twenty million units considered as pairs => \$2 x 10^{14}\$ pairs => \$2^{47.5}\$ pairs. You have to use the same thinking whenever you deal with the possibility of collisions in random/pseudo-random processes.
With a 32 bit hash/CRC the number of units before you hit the 50% probability level for a collision/duplicate is only 77,000 units. -
You can program sequential MAC addresses during firmware programming or device testing.
-
You only have to worry about a Mac collision when the units are in the same subnet, no? Outside the subnet packets are routed via the gateway, not the local arp tables.
It's not quite the same as the birthday paradox, because you're only ever selecting a small fraction of the set at once, unless 77,000 of these will be installed on the same subnet, then you've got the 50% chance of a duplicate mac. -
Don't think a collision is likely but IEEE probably don't like duplicate Mac addresses out there.
I'm sure there are though -
You only have to worry about a Mac collision when the units are in the same subnet, no? Outside the subnet packets are routed via the gateway, not the local arp tables.
It's not quite the same as the birthday paradox, because you're only ever selecting a small fraction of the set at once, unless 77,000 of these will be installed on the same subnet, then you've got the 50% chance of a duplicate mac.
You're not considering schemes like IPv6 stateless addressing where the globally routable address is partially based on the MAC address - one could in theory have a huge address range (64 - 80 bits) as one's collision domain. Also MAC addresses get reused in other ways as globally unique identifiers, one standard form of UUIDs for a start. Some ISPs on DOCSIS rely on end machines having unique MAC addresses.
MACs are meant to be globally unique (or marked as 'locally administered addresses' but the uniqueness property still applies to the 'locally administered' space), and you're meant to be able to rely on that property. If you're going to use a probabilistic scheme for MAC address generation instead of genuine uniqueness you'd better use a really good one. -
A few rules I apply to my Ethernet projects, which are never exposed or routed to the public internet:
1. A unique 32bit per device MAC address is generally plenty in my experience. It's highly unlikely you'll run > 2^16 devices on the same subnet and/or fully routed out. The chances of collisions are really more theoretical.
2. I use the other 16bits to mark off a unique product id and set LAA. You'll make ITs work much easier that way if they plan to deploy a bunch of your devices. For instance they could configure a DHCP server to assign special IP address ranges for your product only. And it makes firewall/filter configurations much easier.
3. Add the unique 32bit number as a hex value to your default hostname. Super useful if you need to support OTA firmware updates via a web/rest interface.
Examples:
MAC: 1ed5b182cd7e
hostname: shinyiot-b182cd7e
MAC: 1ed5f7198460
hostname: shinyiot-f7198460
MAC: 1ed544a1af98
hostname: shinyiot-44a1af98
I use murmur3_32 (https://en.wikipedia.org/wiki/MurmurHash) to generate a reasonably (
) collision free 32-bit hash from the 96-bit device UID.
Also, I humbly plea to you not to design fixed firmware devices which are attached to the public internet unless you know exactly what you are getting into security wise
ALL STM32 devices fall into this category IMO.
-
Are you aware of any specific vulnerabilities in the STM 32F4 ethernet implementation?
-
Are you aware of any specific vulnerabilities in the STM 32F4 ethernet implementation?
AFAIK all vulnerabilities are at the driver layer and up. If you are creating a mass product that faces Internet, you may want to set up a bug bounty and/or hire penetration testers. Basically you pay white hat hackers to intentionally break your product and tell you how they broke it so you can fix it. -
That is a problem only if the box is externally discoverable and is running some sort of a server or something which responds, and is a lot more likely if you run a web server on it.
I wondered if the hardware and ST drivers have particular issues... the only way I can think of is if the DMA controller is misconfigured and is capable of overwriting the buffer if an oversized packet is received. That would be truly dumb, even by ST driver standards, given that buffer overruns have been the #1 vulnerability in Windoze since "hacking" was invented
Getting back to the MAC address cost, a quick google shows that a block of 16M MAC addresses (OUI = Organizationally Unique Identifier, also referred to as 'company id') from IEEE Registration Authority, is $1,650.00. The current cost of an IAB is $550.00 and that gets you 4096 addresses, and that is cheaper than buying any of the little devices mentioned AFAICT.
Is there anyone selling small blocks of MAC addresses?
I looked around the Microchip devices and the SST26VF032BEUI looks interesting since I also need 4MB FLASH storage, but it isn't available until late 2021. -
Is there anyone selling small blocks of MAC addresses?
AFAIK none.
That is why for hobbyist, small-run projects and projects that otherwise needs additional memory chips anyway such MAC chips are useful, but for projects with any kind of volume you need your own OUI block. -
Is there any downside to buying the 4096-MAC block?
-
Is there any downside to buying the 4096-MAC block?
If your whole production run of all your Ethernet-based projects is around ~4000, you are okay. Otherwise you will need multiple 4K blocks or even go to larger blocks if your production scales up. -
The funny thing is that if you just made your widget and created the MAC address by some crypto hash of the date/time, nobody in the remaining age of the universe would detect it
The MAC uniqueness is relevant only on a single LAN (including different branches coming off a switch); as soon as it goes through a router, it disappears.
I bet the chinese are doing it
Remember that many ethernet cards have a user-programmable MAC. That is really handy if you need to duplicate a FLEX-LM server, which everybody should do to protect their (usually huge) investment in some CAD/EDA software
I have totally avoided FLEX-LM stuff, despite having got umpteen sales calls from CADENCE or whatever they are called now.