Reply by Gunther Mannigel●April 15, 20142014-04-15
Am 10.04.2014 17:29, schrieb pozzugno@gmail.com:
> 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.
None that i know of. I'm wondering too, because a lot of people do this.
> 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.
Think of requesting a block of serial numbers. First production line
gets 1 to 1000, second line 1001 to 2000 and so on. If you can afford
dropping single numbers, you can skip and use the next number after each
programming attempt. You have to think about bad units. How do you
retrieve that number, especially when it comes back for service. A
printed serial number comes in handy.
Is the testing done while on the programming fixture?
If not, the device should send its serial number to the database, as
this is the time you can increment stock count.
Maybe you should program all serial numbers as 'FF' and the device
should treat this as invalid and request a new number.
Reply by David Brown●April 15, 20142014-04-15
On 15/04/14 02:55, Les Cargill wrote:
> David Brown wrote:
>> On 14/04/14 14:23, Les Cargill wrote:
>>> David Brown wrote:
>>>> On 12/04/14 23:10, Les Cargill wrote:
<snip>
>>>>> 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 certainly possible for it to happen, but only if you are using two
>> cards from the same supplier with the same fixed MAC address.
>
> IN this case, the MAC address was the default from whatever software
> brought the thing up. You had to use the equivalent of
> ifconfig to assign a MAC address.
>
> I was all totally "whut?"? :) But it was exactly as you say.
I have seen some systems like that. The information is usually hidden
deep within the manual, in places no one looks until they are absolutely
desperate.
>
>> I have
>> certainly come across - and even made - cards where the MAC address was
>> compiled into the software or chosen from a couple of options using DIP
>> switches. These cards would not work together on the same network.
>
> Yes, they will not :)
In this case, the cards were controlling drilling machines some 12m
long, weighing several tons, and backed up by large hydraulic systems.
You'd notice if someone else connected another one to your network!
> <snip>
>>>
>>> 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.
>>>
>>
>> I don't disagree with you here - that is undoubtedly best practice. It
>> is just not the only practice used, and remember that "good enough" is
>> often good enough - you don't always have to go for "best".
>>
>
> This is also, unfortunately, true.
>
> <snip>
>>>
>>> Because somebody may or may not know the procedure for replacing a
>>> switch.
>>
>> If someone replaces the switch in the production line without checking
>> the relevant documentation and consulting the relevant people involved,
>> then we have a bigger problem than just a MAC address conflict. That's
>> what procedures and quality control rules are for. (It's also why there
>> are clear labels on the switch in question, in case someone makes a
>> mistake.)
>>
>
>
> At least in my case, I'd expect the person changing a switch to
> be more in over their head than someone assigning MAC addresses.
>
> For this and other reasons, we don't spec managed switches at all -
> a WalMart special has to work out of the box. Our guys are great
> (they are very, very sharp ) , but we have to do some
> soldier-proofing for 'em. Any risk we can eliminate... this may
> happen once a decade.
>
We don't often use managed switches either (except on the main network
for VLANs). But in this particular case, it was a huge advantage - we
don't assign real MACs until the second stage of programming, and a
managed switch with VLANs lets us do lots of cards in parallel. So it
was a definite active decision to use this setup. Normally I'd agree
with you - when you can use simple generic parts, use simple generic
parts, as it makes life much easier when something goes wrong. Here the
solution is just to have a pre-programmed backup switch on hand.
>>>
>>> This ignores IPV6 altogether - that can be a disaster on the hoof when
>>> it comes your way.
>>>
>>
>> Yes, I am ignoring IPv6 in this case - because I am not using IPv6 here.
>>
>> And even if I were using IPv6, it would be perfectly possible to use it
>> while the cards all had the same MAC address but different VLANs. IPv6
>> is not /that/ different from IPv4, and the only MAC address connection
>> is that MAC addresses are sometimes used to give an IPv6 address to a
>> port
>
> Right.
>
>> - but there is nothing hindering the DHCP server from giving each
>> card a different IPv6 address on the different VLANs, just as it
>> currently does with IPv4 addresses.
>>
>>
>
> I agree - I haven't done that either. From what I *have* seen
> the nodes all have the IPv6 address that happens to be equivalent to the
> MAC address.
>
> Oh, the irony of DHCP for IPv6 :)
>
DHCP is used for many things, not just giving an IPv4 address, so it
will still be useful with IPv6. And there are many reasons to want to
control IP addresses, as well as connect DNS servers and DHCP servers
together (or use dnsmasq, as I usually do) to control naming and IP. So
no IPv6 system is going to stop /me/ from using DHCP!
Reply by Les Cargill●April 14, 20142014-04-14
David Brown wrote:
> On 14/04/14 14:23, Les Cargill wrote:
>> 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 certainly possible for it to happen, but only if you are using two
> cards from the same supplier with the same fixed MAC address.
IN this case, the MAC address was the default from whatever software
brought the thing up. You had to use the equivalent of
ifconfig to assign a MAC address.
I was all totally "whut?"? :) But it was exactly as you say.
> I have
> certainly come across - and even made - cards where the MAC address was
> compiled into the software or chosen from a couple of options using DIP
> switches. These cards would not work together on the same network.
Yes, they will not :)
> For
> the cards I made, that was perfectly acceptable behaviour - and having
> the same MAC address meant getting the same DHCP address during testing
> and development, which was an advantage.
>
> If you are talking about a conflict between two independent cards, then
> the chances of that happening are /really/ small. It is not impossible,
> of course.
>
>>
>>> 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.
>
> Yes. And if the customer expects to be able to use the cards in a
> random network, then you have to provide a unique address or at least an
> address that is highly unlikely to be a collision. (You can never be
> /sure/ your address is unique - someone else might have randomly picked
> /your/ address - and even if it is not your fault, it might end up being
> your problem.)
>
Yep.
<snip>
>>
>> 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.
>>
>
> I don't disagree with you here - that is undoubtedly best practice. It
> is just not the only practice used, and remember that "good enough" is
> often good enough - you don't always have to go for "best".
>
This is also, unfortunately, true.
<snip>
>>
>> Because somebody may or may not know the procedure for replacing a switch.
>
> If someone replaces the switch in the production line without checking
> the relevant documentation and consulting the relevant people involved,
> then we have a bigger problem than just a MAC address conflict. That's
> what procedures and quality control rules are for. (It's also why there
> are clear labels on the switch in question, in case someone makes a
> mistake.)
>
At least in my case, I'd expect the person changing a switch to
be more in over their head than someone assigning MAC addresses.
For this and other reasons, we don't spec managed switches at all -
a WalMart special has to work out of the box. Our guys are great
(they are very, very sharp ) , but we have to do some
soldier-proofing for 'em. Any risk we can eliminate... this may
happen once a decade.
>>
>> This ignores IPV6 altogether - that can be a disaster on the hoof when
>> it comes your way.
>>
>
> Yes, I am ignoring IPv6 in this case - because I am not using IPv6 here.
>
> And even if I were using IPv6, it would be perfectly possible to use it
> while the cards all had the same MAC address but different VLANs. IPv6
> is not /that/ different from IPv4, and the only MAC address connection
> is that MAC addresses are sometimes used to give an IPv6 address to a
> port
Right.
> - but there is nothing hindering the DHCP server from giving each
> card a different IPv6 address on the different VLANs, just as it
> currently does with IPv4 addresses.
>
>
I agree - I haven't done that either. From what I *have* seen
the nodes all have the IPv6 address that happens to be equivalent to the
MAC address.
Oh, the irony of DHCP for IPv6 :)
--
Les Cargill
Reply by David Brown●April 14, 20142014-04-14
On 14/04/14 14:23, Les Cargill wrote:
> 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 certainly possible for it to happen, but only if you are using two
cards from the same supplier with the same fixed MAC address. I have
certainly come across - and even made - cards where the MAC address was
compiled into the software or chosen from a couple of options using DIP
switches. These cards would not work together on the same network. For
the cards I made, that was perfectly acceptable behaviour - and having
the same MAC address meant getting the same DHCP address during testing
and development, which was an advantage.
If you are talking about a conflict between two independent cards, then
the chances of that happening are /really/ small. It is not impossible,
of course.
>
>> 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.
Yes. And if the customer expects to be able to use the cards in a
random network, then you have to provide a unique address or at least an
address that is highly unlikely to be a collision. (You can never be
/sure/ your address is unique - someone else might have randomly picked
/your/ address - and even if it is not your fault, it might end up being
your problem.)
>
>> 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.
>
I don't disagree with you here - that is undoubtedly best practice. It
is just not the only practice used, and remember that "good enough" is
often good enough - you don't always have to go for "best".
>>>
>>> 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.
If someone replaces the switch in the production line without checking
the relevant documentation and consulting the relevant people involved,
then we have a bigger problem than just a MAC address conflict. That's
what procedures and quality control rules are for. (It's also why there
are clear labels on the switch in question, in case someone makes a
mistake.)
>
> This ignores IPV6 altogether - that can be a disaster on the hoof when
> it comes your way.
>
Yes, I am ignoring IPv6 in this case - because I am not using IPv6 here.
And even if I were using IPv6, it would be perfectly possible to use it
while the cards all had the same MAC address but different VLANs. IPv6
is not /that/ different from IPv4, and the only MAC address connection
is that MAC addresses are sometimes used to give an IPv6 address to a
port - but there is nothing hindering the DHCP server from giving each
card a different IPv6 address on the different VLANs, just as it
currently does with IPv4 addresses.
Reply by Les Cargill●April 14, 20142014-04-14
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
Reply by David Brown●April 14, 20142014-04-14
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?
Reply by Paul Rubin●April 14, 20142014-04-14
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.
Reply by John Devereux●April 14, 20142014-04-14
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
Reply by Paul●April 13, 20142014-04-13
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.
> 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.
>
>