1. Home
  2. Embedded Programming
  3. How to manage serial numbers
  4. Page 3

How to manage serial numbers

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.

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.)

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".

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.)

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 to
David Brown
Loading thread data ...

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.

Yes, they will not :)

Yep.

This is also, unfortunately, true.

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.

Right.

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 to
Les Cargill

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.

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!

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.

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 to
David Brown

Am 10.04.2014 17:29, schrieb snipped-for-privacy@gmail.com:

None that i know of. I'm wondering too, because a lot of people do this.

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 to
Gunther Mannigel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.