How to manage serial numbers

Nils M Holm <news2009@t3x.org> writes:
> scaling the output of the RNG down to 32 bits will still generate
> duplicates way before exhausting the 32-bit range.

Yes, you can't use the RNG approach with 32 bit device ID's if there are
more than a few devices.  That's why I suggested 128 bit ID's.  Those
would be ok in some applications where usually only computers have to
distinguish or copy the ID's, but ID's that large are a bit inconvenient
for humans to enter into keyboards etc.  If 32 bits is a requirement,
which apparently it is, then a stateful approach is the only way I can
see.

pozzugno@gmail.com wrote:
> I don't know where to post this question, maybe here someone has
> faced the same problem in the past and could give me some good
> ideas.
>
> I have to ship products with a different 32-bits serial number saved
> in a non-volatile memory (actually it's the internal EEPROM of AVR
> microcontrollers).  Of course, I have to be sure to avoid two
> identical numbers in different devices.
>
> I was thinking to a server-side application that is responsible to
> find and release a new serial number. The programming process started
> on a client PC should be:
>
> 1. acquire a *new* (and never used) serial number from a server on
> the same LAN; 2. generate the programming file for the memory (.bin,
> .hex, .eep, ...); 3. program the memory; 4. give positive/negative
> feedback to the server; 5. in case of positive feedback the server
> should definitevely allocate the serial number saving it in a simple
> database with some useful info (date and time when the serial number
> was allocated, type of embedded device, ...)
>
> I know I can write some code (scripts or other) for the server side
> and client side applications, but I was wondering if there's a ready
> solution to use for my needs.
>
> The separation between server and client could be useful if the PC
> used for programming the device is far from the server (the database
> with serial numbers will be very important) and/or there are many PCs
> dedicated to programming.
>
> For my skills, the server side application is more difficult.
>
> Any ideas?
>

Can you use the MAC address of the Ethernet port being used to connect
to the server? You may have to put it in band since a switch can
replace the MAC address.

So you'd need a cross reference from MAC addresses to serial numbers on
the server.

If your MAC addresses are not in OTP ROM on the client nodes, you have
another problem- although having a default MAC address may actually work
out. You'd need to issue a new MAC address for new nodes.

What won't work (reliably) is having two nodes with the same MAC address
at the same time. The same IP address must also be avoided.

If the server can 1) have instrumentation to pull the DHCP tables for 
the network and 2) use that to identify nodes, then that might help.

-- 
Les Cargill

David Brown wrote:
> On 12/04/14 00:23, George Neuner wrote:
>> On Fri, 11 Apr 2014 12:56:21 -0500, "antedeluvian"
>> <63015@embeddedrelated> wrote:
>>
>>>>
>>>> Any ideas?
>>>>
>>> If you are using some form of Ethernet, how about a system using or based
>>> on the MAC address?	
>>
>> Manufacturer assigned MAC addresses are *not* guaranteed to be unique
>> ... they really only are a best effort.
>>
>> Moreover, many (most?) chips allow the MAC address to be changed by
>> software.  Multiport NICs frequently ship with all the ports set
>> identically and the software _must_ change them or network fabric will
>> be driven crazy.  Becomes interesting when you have many such NICs in
>> the same network.
>>
>> George
>>
>
> MAC addresses don't have to be unique.  They simply have to be unique
> when they are on the same physical network (and same VLAN).


They simply *HAVE* to be globally unique unless you can prove
you'll never have a collision... and IMO, you never can unless you
have significant configuration controls in deployment.

The only way you can assure uniqueness of MAC addresses is by local 
enforcement - one company used a tape of OTP parts. In this fellow's 
case, assignment of MAC addresses could be part of his server, but you
have to plan for how the deployment can handle non-unique MAC addresses
unless it's tightly controlled.

Simply RMAing "collided" nodes might be a good solution. But probably not.

> If you have
> a multiport NIC then it is highly unlikely that two ports will be
> connected to the same network (channel bundling is handled separately,
> and has no problem with non-unique MAC addresse as long as the shared
> addresses are at the same end of the link).
>

Right - dual NICs on the same node can use the same MAC, generally.

I still wouldn't. Some people's bridge implementations on switches may 
or may not work right.

> I have set up a production/programming line where the network cards are
> programmed with the OUID part of the MAC address in the first stage, and
> then are connected together in a network for second stage programming
> and unique MAC assignment.  So at that point, there can be a dozen cards
> with the same MAC address connected to the same switch - but each port
> on the switch is given a different VLAN number and everyone is happy.
>

This is fine if you can assure that VLAN configuration can be part
of the deal. Sometimes you have Randomly Purchased Switches and you
cannot do that.

-- 
Les Cargill

George Neuner wrote:
> On Fri, 11 Apr 2014 12:56:21 -0500, "antedeluvian"
> <63015@embeddedrelated> wrote:
>
>>>
>>> Any ideas?
>>>
>> If you are using some form of Ethernet, how about a system using or based
>> on the MAC address?	
>
> Manufacturer assigned MAC addresses are *not* guaranteed to be unique
> ... they really only are a best effort.
>
> Moreover, many (most?) chips allow the MAC address to be changed by
> software.  Multiport NICs frequently ship with all the ports set
> identically and the software _must_ change them or network fabric will
> be driven crazy.  Becomes interesting when you have many such NICs in
> the same network.
>
> George
>


You *HAVE* to have local controls to never allow duplicate MAC addresses 
into the wild. I suppose you can train people to recognize duplicate 
address misbehavior but that sounds more expensive.

*Shudder*

-- 
Les Cargill

Paul wrote:
> In article <7x7g6x56na.fsf@ruckus.brouhaha.com>, no.email@nospam.invalid
> says...
>>
>> David Brown <david.brown@hesbynett.no> writes:
>>> That was my first thought.  If you think it is hard to generate a
>>> sequence of unique serial numbers, you really are in the wrong
>>> business.
>>
>> Depending on the requirements, it can be harder than it sounds.
>> Client/server is one approach, but do you really want to have to stop
>> your manufacturing line just because an internet connection went down?
>> Even if the internet stays up, does its very presence mean you have to
>> deal with a bunch of resulting potential security issues?  Do you really
>> want to sign up to keep administering that database across the entire
>> production life of the product, that might be decades, just for the sake
>> of keeping the serial numbers sequential?  Etc. etc.
>
> Whats more useful is to have method barcode or embedded RFID for
> tracking batch runs (Yeild of batch, rev status, part date codes used
> etc).
>

If you can RFID them, you can print off serial numbers on barcode 
stickers. Much more manageable.

You *HAVE TO DESIGN THIS PROCESS*. You cannot just throw boxes at it.

> But make this in some way totally local to production even to extent of
> rolls of preprinted barcodes, or similar. That can be later uploaded if
> needed as a batch process to some central database. Why does it matter
> that it is issued at what second of day. Pre allocate and document in
> batch is easier to maintain and administer
>

Much.

> A tracking ID does not have to be the final serial number, which
> depending on product, market and some regulatory details means at end of
> production you may have to REPEAT that serial number to put label on
> case, label on packing box, paperwork, pallet list, shipping manifest
> certificate of conformity.......
>

But the map between the barcode and serial number must then
be maintained. If they're identical, that
cannot break...

> How much you need a serial number or some form of tracking ID depends
> on your circumstances that only you know.
>
> If in different countries what is wrong with plant number, or country
> or destination market or even year of manufacture being in the serial
> number as well.
>
>

-- 
Les Cargill

In article <lica5u$o75$1@dont-email.me>, lcargill99@comcast.com says...
> 
> Paul wrote:
> > In article <7x7g6x56na.fsf@ruckus.brouhaha.com>, no.email@nospam.invalid
> > says...
> >>
> >> David Brown <david.brown@hesbynett.no> writes:
> >>> That was my first thought.  If you think it is hard to generate a
> >>> sequence of unique serial numbers, you really are in the wrong
> >>> business.
> >>
> >> Depending on the requirements, it can be harder than it sounds.
> >> Client/server is one approach, but do you really want to have to stop
> >> your manufacturing line just because an internet connection went down?
> >> Even if the internet stays up, does its very presence mean you have to
> >> deal with a bunch of resulting potential security issues?  Do you really
> >> want to sign up to keep administering that database across the entire
> >> production life of the product, that might be decades, just for the sake
> >> of keeping the serial numbers sequential?  Etc. etc.
> >
> > Whats more useful is to have method barcode or embedded RFID for
> > tracking batch runs (Yeild of batch, rev status, part date codes used
> > etc).
> >
> 
> If you can RFID them, you can print off serial numbers on barcode 
> stickers. Much more manageable.
> 
> You *HAVE TO DESIGN THIS PROCESS*. You cannot just throw boxes at it.

Well considering for last 2 years some PCB manufacturers have been doing
this by embedding the RFID inside the PCB for example 

http://www.pcb-pool.com/ppuk/info_pcbpool_rfid.html

PCB redeisgin may not even be necessary.

As to the Process side I reckon it will be less than what is currently 
being discussed for the whole process.

> > But make this in some way totally local to production even to extent 
of
> > rolls of preprinted barcodes, or similar. That can be later uploaded if
> > needed as a batch process to some central database. Why does it matter
> > that it is issued at what second of day. Pre allocate and document in
> > batch is easier to maintain and administer
> >
> 
> Much.


-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

Les Cargill <lcargill99@comcast.com> writes:

> Paul wrote:
>> In article <7x7g6x56na.fsf@ruckus.brouhaha.com>, no.email@nospam.invalid
>> says...
>>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> That was my first thought.  If you think it is hard to generate a
>>>> sequence of unique serial numbers, you really are in the wrong
>>>> business.
>>>
>>> Depending on the requirements, it can be harder than it sounds.
>>> Client/server is one approach, but do you really want to have to stop
>>> your manufacturing line just because an internet connection went down?
>>> Even if the internet stays up, does its very presence mean you have to
>>> deal with a bunch of resulting potential security issues?  Do you really
>>> want to sign up to keep administering that database across the entire
>>> production life of the product, that might be decades, just for the sake
>>> of keeping the serial numbers sequential?  Etc. etc.
>>
>> Whats more useful is to have method barcode or embedded RFID for
>> tracking batch runs (Yeild of batch, rev status, part date codes used
>> etc).
>>
>
> If you can RFID them, you can print off serial numbers on barcode
> stickers. Much more manageable.
>
> You *HAVE TO DESIGN THIS PROCESS*. You cannot just throw boxes at it.
>
>> But make this in some way totally local to production even to extent of
>> rolls of preprinted barcodes, or similar. That can be later uploaded if
>> needed as a batch process to some central database. Why does it matter
>> that it is issued at what second of day. Pre allocate and document in
>> batch is easier to maintain and administer
>>
>
> Much.

That's what we do - the database that generates the parts list and the
stock levels also generates the serial numbers for the batch. I print
them off in A4 sheets. (Still can't find any small enough for the very
small boards, without going to those roll printer things which I find a
PITA).

So I am thinking of going to simple batch / date code tracking and
dropping the serial numbers - will be a shame since we have the serial
numbers going back to our first board, serial number 1.

[...]


-- 

John Devereux

John Devereux <john@devereux.me.uk> writes:
> That's what we do - the database that generates the parts list and the
> stock levels also generates the serial numbers for the batch. I print
> them off in A4 sheets. (Still can't find any small enough for the very
> small boards, without going to those roll printer things which I find a
> PITA).

I'd worry about them falling off.  Laser etching might or might not
be a practical alternative.

On 12/04/14 23:10, Les Cargill wrote:
> David Brown wrote:
>> On 12/04/14 00:23, George Neuner wrote:
>>> On Fri, 11 Apr 2014 12:56:21 -0500, "antedeluvian"
>>> <63015@embeddedrelated> wrote:
>>>
>>>>>
>>>>> Any ideas?
>>>>>
>>>> If you are using some form of Ethernet, how about a system using or
>>>> based
>>>> on the MAC address?   
>>>
>>> Manufacturer assigned MAC addresses are *not* guaranteed to be unique
>>> ... they really only are a best effort.
>>>
>>> Moreover, many (most?) chips allow the MAC address to be changed by
>>> software.  Multiport NICs frequently ship with all the ports set
>>> identically and the software _must_ change them or network fabric will
>>> be driven crazy.  Becomes interesting when you have many such NICs in
>>> the same network.
>>>
>>> George
>>>
>>
>> MAC addresses don't have to be unique.  They simply have to be unique
>> when they are on the same physical network (and same VLAN).
> 
> 
> They simply *HAVE* to be globally unique unless you can prove
> you'll never have a collision... and IMO, you never can unless you
> have significant configuration controls in deployment.

You are overstating the case.

It is /expected/ that MAC addresses will be globally unique - but there
is no authority or rules to enforce that.  This is unlike things like
Bluetooth or USB ids and serial numbers - if you want to be able to use
the trademarked logos for these interfaces, then you have to follow the
rules about unique ids.  And while there /is/ an authority that
registers and administers the 24-bit OUID part of MAC addresses, you are
not obliged to use one.

If you sell networked equipment to a customer without giving specific
requirements about the networking, then the customer can expect the MAC
address to be globally unique, and can reasonably claim against you if
there is a conflict.  But that's just general trade rules - if you sell
something, people expect it to work in a particular way.

There are lots of circumstances in which people can and do make
networked equipment without globally unique MACs.  For some of these,
you have enough control to be sure there is no conflict (such as in the
case I mentioned, where cards temporarily have identical MAC addresses
at one stage of production programming).  Maybe you are building systems
that each customer will only have one of, or you have other limitations
in the network.

But it is also not unreasonable to "cheat", and it is very common during
development and testing.  If you are making larger quantities of a
system, then an official OUID is not that expensive and looks more
professional.  But for earlier work, it is common to pick an OUID of
another company, or an unallocated OUID, or a "locally administered"
OUID, and then a random 24-bit number.  So you pick Ford's OUID and a
random number - what are the chances of that causing a collision during
your development?  Or just pick a full 48-bit random number - what are
your chances of collision then?  Another common trick for development is
to copy the MAC address from old and unused equipment.


Of course it is best to have a proper OUID and proper control over the
MAC addresses you allocate from it.  But don't be fooled into thinking
that MAC addresses really are globally unique, or really have to be
globally unique.

> 
> The only way you can assure uniqueness of MAC addresses is by local
> enforcement - one company used a tape of OTP parts. In this fellow's
> case, assignment of MAC addresses could be part of his server, but you
> have to plan for how the deployment can handle non-unique MAC addresses
> unless it's tightly controlled.
> 
> Simply RMAing "collided" nodes might be a good solution. But probably not.

You have to be extraordinarily incompetent to end up with collided nodes
in practice, so RMA'ing them should be fine.

> 
>> If you have
>> a multiport NIC then it is highly unlikely that two ports will be
>> connected to the same network (channel bundling is handled separately,
>> and has no problem with non-unique MAC addresse as long as the shared
>> addresses are at the same end of the link).
>>
> 
> Right - dual NICs on the same node can use the same MAC, generally.
> 
> I still wouldn't. Some people's bridge implementations on switches may
> or may not work right.
> 
>> I have set up a production/programming line where the network cards are
>> programmed with the OUID part of the MAC address in the first stage, and
>> then are connected together in a network for second stage programming
>> and unique MAC assignment.  So at that point, there can be a dozen cards
>> with the same MAC address connected to the same switch - but each port
>> on the switch is given a different VLAN number and everyone is happy.
>>
> 
> This is fine if you can assure that VLAN configuration can be part
> of the deal. Sometimes you have Randomly Purchased Switches and you
> cannot do that.
> 

Of course I can be sure that the VLAN configuration is correct - it is
part of the production and programming line.  Why would there be a
"randomly purchased switch" in a production facility - especially one
where the setup of the switch is an important component in the
programming line?

David Brown wrote:
> On 12/04/14 23:10, Les Cargill wrote:
>> David Brown wrote:
>>> On 12/04/14 00:23, George Neuner wrote:
>>>> On Fri, 11 Apr 2014 12:56:21 -0500, "antedeluvian"
>>>> <63015@embeddedrelated> wrote:
>>>>
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>> If you are using some form of Ethernet, how about a system using or
>>>>> based
>>>>> on the MAC address?
>>>>
>>>> Manufacturer assigned MAC addresses are *not* guaranteed to be unique
>>>> ... they really only are a best effort.
>>>>
>>>> Moreover, many (most?) chips allow the MAC address to be changed by
>>>> software.  Multiport NICs frequently ship with all the ports set
>>>> identically and the software _must_ change them or network fabric will
>>>> be driven crazy.  Becomes interesting when you have many such NICs in
>>>> the same network.
>>>>
>>>> George
>>>>
>>>
>>> MAC addresses don't have to be unique.  They simply have to be unique
>>> when they are on the same physical network (and same VLAN).
>>
>>
>> They simply *HAVE* to be globally unique unless you can prove
>> you'll never have a collision... and IMO, you never can unless you
>> have significant configuration controls in deployment.
>
> You are overstating the case.
>

I have been bit by it. Wasn't my doing, but I still had to untangle it.

> It is /expected/ that MAC addresses will be globally unique - but there
> is no authority or rules to enforce that.  This is unlike things like
> Bluetooth or USB ids and serial numbers - if you want to be able to use
> the trademarked logos for these interfaces, then you have to follow the
> rules about unique ids.  And while there /is/ an authority that
> registers and administers the 24-bit OUID part of MAC addresses, you are
> not obliged to use one.
>
> If you sell networked equipment to a customer without giving specific
> requirements about the networking, then the customer can expect the MAC
> address to be globally unique, and can reasonably claim against you if
> there is a conflict.  But that's just general trade rules - if you sell
> something, people expect it to work in a particular way.
>

People expect things to work. Two identical MAC addresses on the same 
collision domain or VLAN or what have you doesn't work.

> There are lots of circumstances in which people can and do make
> networked equipment without globally unique MACs.  For some of these,
> you have enough control to be sure there is no conflict (such as in the
> case I mentioned, where cards temporarily have identical MAC addresses
> at one stage of production programming).

That, I don't particularly have a problem with but it's a matter of
production control.

>  Maybe you are building systems
> that each customer will only have one of, or you have other limitations
> in the network.
>

Still...

> But it is also not unreasonable to "cheat", and it is very common during
> development and testing.

True.

> If you are making larger quantities of a
> system, then an official OUID is not that expensive and looks more
> professional.

You'll usually inherit one from an acquisition. There's always been an
acquisition...

>  But for earlier work, it is common to pick an OUID of
> another company, or an unallocated OUID, or a "locally administered"
> OUID, and then a random 24-bit number.  So you pick Ford's OUID and a
> random number - what are the chances of that causing a collision during
> your development?  Or just pick a full 48-bit random number - what are
> your chances of collision then?  Another common trick for development is
> to copy the MAC address from old and unused equipment.
>
>
> Of course it is best to have a proper OUID and proper control over the
> MAC addresses you allocate from it.  But don't be fooled into thinking
> that MAC addresses really are globally unique, or really have to be
> globally unique.
>

SFAIK, best practices still are to have them be as unique as possible
as early as possible. It's worth putting some thought into this.

>>
>> The only way you can assure uniqueness of MAC addresses is by local
>> enforcement - one company used a tape of OTP parts. In this fellow's
>> case, assignment of MAC addresses could be part of his server, but you
>> have to plan for how the deployment can handle non-unique MAC addresses
>> unless it's tightly controlled.
>>
>> Simply RMAing "collided" nodes might be a good solution. But probably not.
>
> You have to be extraordinarily incompetent to end up with collided nodes
> in practice, so RMA'ing them should be fine.
>
>>
>>> If you have
>>> a multiport NIC then it is highly unlikely that two ports will be
>>> connected to the same network (channel bundling is handled separately,
>>> and has no problem with non-unique MAC addresse as long as the shared
>>> addresses are at the same end of the link).
>>>
>>
>> Right - dual NICs on the same node can use the same MAC, generally.
>>
>> I still wouldn't. Some people's bridge implementations on switches may
>> or may not work right.
>>
>>> I have set up a production/programming line where the network cards are
>>> programmed with the OUID part of the MAC address in the first stage, and
>>> then are connected together in a network for second stage programming
>>> and unique MAC assignment.  So at that point, there can be a dozen cards
>>> with the same MAC address connected to the same switch - but each port
>>> on the switch is given a different VLAN number and everyone is happy.
>>>
>>
>> This is fine if you can assure that VLAN configuration can be part
>> of the deal. Sometimes you have Randomly Purchased Switches and you
>> cannot do that.
>>
>
> Of course I can be sure that the VLAN configuration is correct - it is
> part of the production and programming line.  Why would there be a
> "randomly purchased switch" in a production facility - especially one
> where the setup of the switch is an important component in the
> programming line?
>

Because somebody may or may not know the procedure for replacing a switch.

This ignores IPV6 altogether - that can be a disaster on the hoof when 
it comes your way.

>
>
>

-- 
Les Cargill