UID STM32 and MAC address - Page 1
Forum section: electronics / general

author: S. Petrukhin
author_rank: Super Contributor
timestamp: May 15, 2021, 08:02:41 pm
content: 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?

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: May 16, 2021, 09:01:41 am
content: 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

author: S. Petrukhin
author_rank: Super Contributor
timestamp: May 16, 2021, 09:13:52 am
content: Quote from: JOEBOBSICLE on May 16, 2021, 09:01:41 amWhat kind of chips are you talking about?

author: nudge
author_rank: Contributor
timestamp: May 16, 2021, 09:21:38 am
content: 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

author: technix
author_rank: Super Contributor
timestamp: May 16, 2021, 10:46:20 am
content: 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.

author: S. Petrukhin
author_rank: Super Contributor
timestamp: May 16, 2021, 11:49:43 am
content: 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.

author: technix
author_rank: Super Contributor
timestamp: May 16, 2021, 01:15:03 pm
content: Quote from: S. Petrukhin on May 16, 2021, 11:49:43 amOnce 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.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.

author: fchk
author_rank: Frequent Contributor
timestamp: May 16, 2021, 06:45:00 pm
content: NuttX uses the CRC of the UID to get a locally administered MAC:Code:stm32_get_uniqueid(uid);crc = crc64(uid, 12);/* Specify as localy administrated address */priv->dev.d_mac.ether.ether_addr_octet = (crc >> 0) | 0x02;priv->dev.d_mac.ether.ether_addr_octet &= ~0x1;priv->dev.d_mac.ether.ether_addr_octet = crc >> 8;priv->dev.d_mac.ether.ether_addr_octet = crc >> 16;priv->dev.d_mac.ether.ether_addr_octet = crc >> 24;priv->dev.d_mac.ether.ether_addr_octet = crc >> 32;priv->dev.d_mac.ether.ether_addr_octet = crc >> 40;Don't forget that the MAC doesn't have to be unique globally, locally unique within a broadcast domain is enough.fchk

author: fchk
author_rank: Frequent Contributor
timestamp: May 16, 2021, 06:50:17 pm
content: Quote from: technix on May 16, 2021, 10:46:20 amI 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

author: S. Petrukhin
author_rank: Super Contributor
timestamp: May 16, 2021, 07:57:34 pm
content: Quote from: fchk on May 16, 2021, 06:45:00 pmI think there is a danger of getting 2 identical numbers from 46 bits from crc64 from 96 bits. It's unreliable.

author: viperidae
author_rank: Frequent Contributor
timestamp: May 16, 2021, 09:36:14 pm
content: 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.

author: S. Petrukhin
author_rank: Super Contributor
timestamp: May 16, 2021, 10:02:01 pm
content: Quote from: viperidae on May 16, 2021, 09:36:14 pmThe 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.

author: Cerebus
author_rank: Super Contributor
timestamp: May 16, 2021, 10:16:09 pm
content: Quote from: viperidae on May 16, 2021, 09:36:14 pmFor several billion units you will seemanycollisions.With 48 random bits you have a 50% chance of a duplicate with 20 million units - it's the classicbirthday problem- people forget that they are not dealing with a \$n\$ objects but with \$\frac{n^2}{2}\$pairsof 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: May 16, 2021, 11:35:59 pm
content: You can program sequential MAC addresses during firmware programming or device testing.

author: viperidae
author_rank: Frequent Contributor
timestamp: May 17, 2021, 03:55:17 am
content: 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.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: May 17, 2021, 10:58:07 am
content: Don't think a collision is likely but IEEE probably don't like duplicate Mac addresses out there.I'm sure there are though

author: Cerebus
author_rank: Super Contributor
timestamp: May 17, 2021, 03:41:02 pm
content: Quote from: viperidae on May 17, 2021, 03:55:17 amYou'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.

author: ttt
author_rank: Regular Contributor
timestamp: May 17, 2021, 10:51:11 pm
content: 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: 1ed5b182cd7ehostname: shinyiot-b182cd7eMAC: 1ed5f7198460hostname: shinyiot-f7198460MAC: 1ed544a1af98hostname: shinyiot-44a1af98I 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 wiseALL STM32 devices fall into this category IMO.

author: peter-h
author_rank: Super Contributor
timestamp: May 18, 2021, 06:43:15 am
content: Are you aware of any specific vulnerabilities in the STM 32F4 ethernet implementation?

author: technix
author_rank: Super Contributor
timestamp: May 18, 2021, 08:30:24 am
content: Quote from: peter-h on May 18, 2021, 06:43:15 amAFAIK 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 18, 2021, 11:34:36 am
content: That is a problem only if the box is externally discoverableandis 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 inventedGetting 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.00and 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.

author: technix
author_rank: Super Contributor
timestamp: May 19, 2021, 03:19:43 am
content: Quote from: peter-h on May 18, 2021, 11:34:36 amAFAIK 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 19, 2021, 06:04:33 am
content: Is there any downside to buying the 4096-MAC block?

author: technix
author_rank: Super Contributor
timestamp: May 19, 2021, 09:49:34 am
content: Quote from: peter-h on May 19, 2021, 06:04:33 amIf 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 19, 2021, 01:55:58 pm
content: 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 itThe 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 itRemember 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 softwareI have totally avoided FLEX-LM stuff, despite having got umpteen sales calls from CADENCE or whatever they are called now.