rt resetting a MAC address for a target system

[ElliotKaplan]

I am using a Compaq EVO desktop with a pentium IV processor as a real time target. For some reason, whenever any computer of this model is booted up into safe mode or Realtime, it broadcasts a mac address which is different from that indicated in BIOS. I've had three such computers do the same thing and broadcast the exact same MAC address (starting with C0-82).

I used some of the system replication tools (found here http://digital.ni.com/softlib.nsf/websearch/52E41EB7BD91D66C862571CD007683D1?opendocument&node=132060_US ) on the  RT system, and the only potentially useful thing it spit back at me was that the computer has a Model Code 719C (which doesn't mean anything to me, but may to someone else)

Is there a way to reset the MAC address on a running Realtime Target (through MAX or otherwise), so that I might be able to put two or more such machines on a single network?

[Karunya_R]

Where is it being broadcasted? Do you have two network cards on the PC? Can you tell me what the addresses are? If you any screenshots that would be great.

Can you please go to the following folder and check if you different max address in the netconf.ini file?

ftp://(ip address of the RT PC)/ni-rt/system/ethernet/

And also check if the IP address in there match to the broadcasted one or to the one in the BIOS.

[JensT]

We have a similar problem.
We have 7 PC realtime systems (hardware: Advantech; software: LVRT 8.5, running CVI code) which all seem to have the same MAC address (system writes MAC address to c:\ni-rt\system\ethernet\netconf.ini) which is different from the MAC addresses which can be read by other operating system (e.g. Linux).
The systems write on the screen "ETS TCP/IP: device ether1: another host has the same IP address!", but the different systems have different (fixed) IP addresses.

Can somebody tell me how to fix this problem?

Thanks in advance!
Yeti0815

[Texas_Diaz]

Can you please provide the MAC addresses being read and the type of network interface it is?  For example, the ID may be:

Intel 82541 NIC : MAC Address 00:0E:0C:22:0C:5A

or

Intel Pro 1000 : MAC Address 00:80:2f:DD:BE:EF 

The MAC address is read directly from the EEPROM on the network interface (if there is one, we read the value stored in the EEPROM) or the EEPROM virtualization area (the BIOS must populate an area of device-mapped memory with the MAC Address during device enumeration).  There are several kinds of storage interfaces, and LabVIEW RT only supports a couple of them - this is, of course, depending on the chipset.

There is no way in LabVIEW RT to "spoof" or otherwise assign MAC Addresses for devices.  It could be that the drivers just cannot read the MAC Address from your device for one reason or another.  If you can tell me what the device type, manufacturer (of the board/card), and MAC address is I can see if I can determine if that board is really supported - it's likely that they used a supported network chip, but manufacturers could have cut corners and used an unsupported MAC Address storage mechanism.

-Danny

[JensT]

Hi Danny,

I was able to read some informations from 2 of the systems (systems are productive), named "E4" and "E6".

System "E4":

MAC from netconf.ini is 00:B4:C0:91:FF:BF

MAC read by Linux (booted from USB stick) is 00:D0:C9:AC:1B:DA

System "E6":

MAC from netconf.ini is 00:B4:C0:91:FF:BF

MAC read by Linux (booted from USB stick) is 00:D0:C9:AC:1B:E0

Hardware info see attachment; NIC seems to be a 8255x (on motherboard).

If you need more information I can try to get more information.

Sincerely, Yeti0815

[Texas_Diaz]

Okay, I know what's going on here.  I thought that "illegal" MAC Address vendor ID looked kinda familiar, and this issue in general, I just couldn't put my finger on it until you showed me the full MAC Address.  

There's two parts to this problem.  First, all Intel 8255x ethernet chips have a built-in "default" MAC baked into the chip from manufacturing - depending on the revision of the chip, you could have one of:

00:a4:c0:91:d2:9c
00:a4:x0:xx:xx:xx   // x's mean "anything" 0-F
00:b4:c0:91:D2:9c
00:b4:x0:xx:xx:xx   // x's mean "anything" 0-F

 Now, vendors who create network cards use the 8255x chip along with a storage mechanism of some kind - usually an EEPROM derivative (FLASH based systems weren't heavily used in 8255x chipsets).  It is the job of the ethernet driver to read the vendor-supplied MAC Address out of the EEPROM (or whatever storage is available) and program that value into the 8255x NIC - basically overriding the "default" MAC baked into the chip.  

However, if the driver cannot read the storage medium or the data read does not conform to the MAC address standards, drivers aren't allowed to "make up" a MAC Address, and the "default" MAC on the device ends up getting used.  This doesn't really pose a problem until you have more than one of these devices with the same "baked-in" MAC on the same local area network (then the non-unique MAC becomes a problem).

There have been a number of manufacturers (SuperMicro, for example) that have shipped a number of devices that either used a different EEPROM layout than the "traditionally standard" EEPROM layout - causing the driver to not be able to read a valid MAC Address off the EEPROM - or used a different storage mechanism that the driver cannot support (such as a MicroWire SEEPROM device).  If you do a little bit of research, you'll find that this was a problem in FreeBSD, Windows XP, (and other similar OS's that released around the same time) until the stock Intel drivers were updated with support for these kinds of things ... something the LabVIEW Real-Time drivers were never updated with.  

We do not currently have a way to manually set the MAC address for a device on LabVIEW Real-Time.  How many NICs are on each PC?  Maybe I can put together a driver with a "hack" that can work around this for you - maybe provide you with a driver that reads a token from the ni-rt.ini file to get its MAC address - if the systems all will only ever have one 8255x NIC on them each (single-NIC systems are so much easier to "hack" than multiple NIC systems).  

-Danny

[JensT]

Hi Danny,

we currently have 2 x 8 systems of this kind, that means 2 locations with 7 systems each. Within one location the systems can see each other.

The mentioned systems are all single NIC systems.

A driver with a configurable MAC would be great, so we could read the MAC via Linux and write it into the configuration file.

Maybe this feature could be implemented in all drivers

Sincerely, Yeti0815

[Texas_Diaz]

Hey all.

Here's a quickie for your viewing enjoyment.  Consider this an EXPERIMENTAL driver (though it's pretty much the release driver plus one or two mods) - no frills, no installer, just the "goods".  Unzip this file, and drop the .dll on your target to replace the file you already have (in /ni-rt/system/ethernet) and should be an exact replica of what you already have on your system.

Except, if you place a specific token in your ni-rt.ini file in the root of your controller, you can set the MAC address of your device.

[MAC]

macaddress = 00802F55AA33

This would set your MAC Address on your Intel 8255x device to 00:80:2F:55:AA:33.  The MAC Address is represented by six pairs of octets put together in one single string.  If you do this correctly, the driver will output this to the console:

Found MAC Address in ni-rt.ini file:  00802F55AA33,12

This is to signify that it found 12 alpha-numeric characters, and what they were.  It doesn't mean what you put in there is correct; there's no validation here other than checking the correct string length; validation is in your own hands.

DO NOT use this driver if you have more than ONE Intel 8255x NIC in your system - otherwise, ALL your NICs will have the same MAC Address.  

Will this kind of feature eventually end up in a release driver?  Hard to say.  It all depends on the need and marketing/sales benefits.  I tossed this together because (1) I could, and (2) it turns out I had a few minutes between projects to play so I did it.  

Enjoy.

-Danny

[JensT]

Hi Danny,

first I have to say sorry for the late answer.

We've been now testing the special driver for several weeks. It works fine for us, and we didn't notice any problems.

Many thanks for the work you did.

From our point of view, you can take over the feature to the regular LabView RT OS release 😉

Sincerely, Yeti0815