Joe Chisolm wrote:

> Might be able to license the VID/PID pairs as long as there was no
> transfer of owner ship.  Legal mumbo jumbo word games come into play.
> 
> Too bad.  I guess I'll have to fork over 2 grand....

I think the idea of VID/PID is very wrong. For my devices I plan to use
just one of my ids and then distinguish the devices by the Manufacturer and
Product descriptor strings.

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Fri, 03 Oct 2008 01:39:07 -0400, Blip wrote:

> This seems to me like a dumb question, but I don't know what the answer
> is...
> 
> We are building a product using the LPC2368 (which has a MAC) & a Micrel
> KSZ8721 (PHY). As part of the prototype programming effort, I include a
> random MAC address in software as part of an init sequence.
> 
> When this goes onto other networks, the MAC addresses have a chance to
> collide w/ *real* ones. It seems to me that NXP should provide the MAC
> addess pool since they provide the MAC, but that's probably not true.
> 
> Do we need to go to the IEEE & purchase our own OUI?
> 
> Thanks for the advice...

I've done this several times.  Unless you are *really* financially
constrained, just go to IEEE and get a IAB or full OUI. The cost is 
minimal compared to development cost trying to hack something together 
or pull mac addresses from old cards. You could probably look around and 
find the addresses for some old DEC or 3Com 10base2 cards but you will 
quickly burn up more than $550 or $1600 bucks worth of time.

What ever you do, remember you are going to have to have manufacturing
procedures in place to assign the unique numbers to the products.


-- 
Joe Chisolm
Marble Falls, TX

Mel wrote:

> Check the Wikipedia MAC_address article.  The MAC standard calls for a
> rather large block of locally-administered addresses.  In an emergency you
> could use those.  Then, in the long run, it would be your customer's
> look-out.

Rather not.  I think it's pretty clear from the description that 
"locally administered" addresses can never be used for devices sold to 
others, because they are then no longer locally administered by you.

Blip wrote:
> We are building a product using the LPC2368 (which has a MAC) & a
> Micrel KSZ8721 (PHY). As part of the prototype programming effort, I
> include a random MAC address in software as part of an init sequence.
>
> When this goes onto other networks, the MAC addresses have a chance to
> collide w/ *real* ones. It seems to me that NXP should provide the MAC
> addess pool since they provide the MAC, but that's probably not true.
>
> Do we need to go to the IEEE & purchase our own OUI?

One method is to use a locally assigned prefix and use something like
a DS2401 serial number chip for the lower bytes. Since MAC addresses
are only local to a subnet, the chances of a collision are pretty
close to nil. More info at http://www.certsoft.com/mac.htm

certsoft wrote:

> One method is to use a locally assigned prefix and use something like
> a DS2401 serial number chip for the lower bytes. Since MAC addresses
> are only local to a subnet, the chances of a collision are pretty
> close to nil. More info at http://www.certsoft.com/mac.htm

Interesting exchange of letters. Looks like they have added a FAQ section,
that it is not allowed to sell the MACs.

I wonder if it would be possible to program a cheap EEPROM, like this one
for $0.19 (for 100 units):

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=24AA00-I/SN-ND

with a MAC and then sell the chips. This would be even a good idea for
production, because then you don't have to manage the MAC addresses by
yourself, but you simply put the pre-programmed chip on your board (if the
flash content survives the soldering process). Would be the same as if you
buy an ethernet card and plug it in your PC, but at a smaller scale.

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Purchase enough of 5464E-I quad nics, use MACs , they are printed on boards, 
destroy NICs.

Alternatively get Sun QFE or any other boards.

Your device will be seen by sniffers as vendor's appliances.

Unless quantity is large.

Alex







"Blip" <b...@krumpli.com> wrote in message 
news:o...@4ax.com...
> This seems to me like a dumb question, but I don't know what the
> answer is...
>
> We are building a product using the LPC2368 (which has a MAC) & a
> Micrel KSZ8721 (PHY). As part of the prototype programming effort, I
> include a random MAC address in software as part of an init sequence.
>
> When this goes onto other networks, the MAC addresses have a chance to
> collide w/ *real* ones. It seems to me that NXP should provide the MAC
> addess pool since they provide the MAC, but that's probably not true.
>
> Do we need to go to the IEEE & purchase our own OUI?
>
> Thanks for the advice... 

On Fri, 3 Oct 2008 16:43:28 -0700 (PDT), certsoft <b...@certsoft.com>
wrote:

>Blip wrote:
>> We are building a product using the LPC2368 (which has a MAC) & a
>> Micrel KSZ8721 (PHY). As part of the prototype programming effort, I
>> include a random MAC address in software as part of an init sequence.
>>
>> When this goes onto other networks, the MAC addresses have a chance to
>> collide w/ *real* ones. It seems to me that NXP should provide the MAC
>> addess pool since they provide the MAC, but that's probably not true.
>>
>> Do we need to go to the IEEE & purchase our own OUI?
>
>One method is to use a locally assigned prefix and use something like
>a DS2401 serial number chip for the lower bytes. Since MAC addresses
>are only local to a subnet, the chances of a collision are pretty
>close to nil. More info at http://www.certsoft.com/mac.htm

Maxim has a device specifically for MAC addresses. It is one of the
1-Wire devices, which has a legal MAC address stored in the device.
It is the DS2502-E48 AFAICR.  For small runs, this is quite handy. It
helps a lot from the logistics point of view as well, since one does
not need a step to program a legal adress into an EEPROM or something
for each PCB.

Regards
  Anton Erasmus