DaveDDS wrote on 2026-04-15, 00:30:

If you can change it, you would want to make sure it doesn't conflict with any other on your network. I do get that given the "globally unique" nature of MACs back in the day, some vendors also used them as a unique serial number - and if features are enabled/disabled based on MAC, you might want to change it. But just copying a mac from a similar system on your network would cause conflicts.

There is a MAC address range reserved for "local use", which is: AC:DE:48:xx:xx:xx but you would be unlikely to find any such MAC which enables locked-out features.

The device is never going to be networked and the "protection" was just a simple one as the device is a nice product, nobody would have ever tried to hack it 😀 It wouldn't make sense to invest more money on a licensing protection.

I'd be happy to try AC:DE:48, I'm confident there are no checks! 😁

Thanks @shevalier
I'll try that too!

jmarsh wrote on 2026-04-15, 03:07:

It's a little bit bizarre that companies back in the day considered a MAC address static enough to tie a software licence to it, yet nowadays current platforms like android etc. randomise the wifi mac at regular intervals for privacy purposes.

Back in the day - MAC addresses were supposed to be globally unique, a MAC is 6-bytes(48 bits) which gives 2.8x10**14 possible values, and it wasn't considered that that would ever not be enough (and to be fair, I think it still is enough - that's a BIG number) - in the original design/specification, MAC addresses were NEVER supposed to change.

But that was back when networked systems weren't all that common ... in todays world most everyone has a phone in their hand all the time, constantly interacting with social-media, and "bad guys" have figured out that lots of usable/sellable information about people can be obtained by collecting enough network data from them, and the "unique identifier" has become a liability on publically accessible networks because it makes doing that easy.

"randomizing" MAC destroys the guarantee that all equipment can co-exist on the same network without conflicts ... and technically two people using their
phones on WiFi in the same coffee shop *could* conflict with each other, but this hasn't been a noticeable problem because:
- The chances of randomly picking any given 48 but number is astronomically low.
- If a conflict did occur it would only be on a local network (IP and routable protocols don't rely on MAC for id beyond local net)
- The now fully accepted/expected practice of "It's not working- turn it off and back on again" will re-pick MACs.

rasz_pl wrote on 2026-04-14, 20:46:

MAC address is software controlled in every NIC chip.

Yes, but...
The MAC address is located specifically on the NIC.
The network card consists of two parts: the PHY (physical interface(physical interface, which may be a separate chip on the motherboard or an SFP module, as in this specific example) and the NIC itself.
The NIC can also be located on the South Bridge, as is the case with the Intel 815, for example.
But on the P5P800-VM, the EEPROM chip is clearly visible, and the RTL8100C is a complete network card for the PCI interface.
Here, you specifically need the utility from Realtek itself.

shevalier wrote on 2026-04-15, 11:48:

The MAC address is located specifically on the NIC.

my point is it doesnt matter where initial MAC is stored. Every nic chip must allow programming mac. Loading MAC is a standard function of a driver.
NDIS drivers query windows registry and will load custom address if present at HKLM\SYSTEM\CurrentControlSet\Control\Class\{something?}\something\NetworkAddress https://learn.microsoft.com/en-us/windows-har … dnetworkaddress
Most also expose this functionality in adapter properties.

I found this on some Asus ROG forum:

This tutorial will show you how to change it back to the Original Mac Address
(For Asus Motherboards, or any Motherboard with a Intel NIC)

This method uses a tool called EEUPDATE to flash your Mac Address in Dos

I download those EEUPDATE.EXE versions for different Asus motherboards integrated NIC adapter models, but all of them are made by intel.

Obviously Asus gamer's ROG trash is too new compared to Tony's socket LGA775 board, but now I think there is some chance, that such tools were provided with some of the Asus motherboard's driver CDs.

aVd wrote on Yesterday, 05:16:

I found this on some Asus ROG forum: […]
Show full quote

I found this on some Asus ROG forum:

This tutorial will show you how to change it back to the Original Mac Address
(For Asus Motherboards, or any Motherboard with a Intel NIC)

This method uses a tool called EEUPDATE to flash your Mac Address in Dos

I download those EEUPDATE.EXE versions for different Asus motherboards integrated NIC adapter models, but all of them are made by intel.

Obviously Asus gamer's ROG trash is too new compared to Tony's socket LGA775 board, but now I think there is some chance, that such tools were provided with some of the Asus motherboard's driver CDs.

Why are you looking for a utility for motherboards in general, and for specific motherboards in particular?
The RTL8100C is a standalone PCI network card that is simply soldered directly onto the motherboard.
For Wake-on-LAN to work, the network card must read its MAC address before the main part of the motherboard powers on.
If the NIC (not the PHY) is located in the chipset, this happens from the main BIOS.
If it’s a separate NIC, then from the local EEPROM.
A utility from the motherboard manufacturer simply won’t be able to access it.
And this utility can only be found on the Realtek website—either as a standalone download or as part of the DOS driver bundle.

shevalier wrote on Yesterday, 05:51:

Why are you looking for a utility for motherboards in general, and for specific motherboards in particular? The RTL8100C is a st […]
Show full quote

Why are you looking for a utility for motherboards in general, and for specific motherboards in particular?
The RTL8100C is a standalone PCI network card that is simply soldered directly onto the motherboard.
For Wake-on-LAN to work, the network card must read its MAC address before the main part of the motherboard powers on.
If the NIC (not the PHY) is located in the chipset, this happens from the main BIOS.
If it’s a separate NIC, then from the local EEPROM.
A utility from the motherboard manufacturer simply won’t be able to access it.
And this utility can only be found on the Realtek website—either as a standalone download or as part of the DOS driver bundle.

Hi, @shevalier,
Because I'm not 100% sure if this motherbord integrated NIC's MAC address is stored only in the EEPROM chip, that Tony is suggesting.
I won't explain the same stories again, just read this post: Re: Permanently changing MAC address

What if the MAC address for this board is also cloned into the BIOS or into the NVRAM? Obviously, if there is a motherboard manufacturer's dedicated tool for setting the MAC address, it would be best to use it.

This is not a standard discrete PCI NIC adapter, but motherboard and we don't know for sure what the motherboard's manufacturer did for the integrated NIC to work on-board.

aVd wrote on Yesterday, 06:50:

This is not a standard discrete PCI NIC adapter, but motherboard and we don't know for sure what the motherboard's manufacturer did for the integrated NIC to work on-board.

Hi, aVd
A few posts above, rasz_pl has kindly posted a board view for this motherboard.
From which two conclusions follow:
- The EEPROM (U9) is connected to Realtek
- Realtek itself is connected to the PСI bus.
I’m afraid I have to disagree with you.
This is simply a standard RTL8100C network card, only located directly on the motherboard

there used to be quite a few programs for that NIC but unfortunately they don't seem to be available anymore. Maybe buried in one of them there was the option to write the MAC address.

https://web.archive.org/web/20060427013721/ht … px?Keyword=8100

tony359 wrote on Yesterday, 13:32:

there used to be quite a few programs for that NIC but unfortunately they don't seem to be available anymore. Maybe buried in one of them there was the option to write the MAC address.

https://web.archive.org/web/20060427013721/ht … px?Keyword=8100

I would therefore recommend the following sequence:
- The Windows diagnostic tool from the Realtek website
- The DOS diagnostic tool I mentioned on the previous page
If that doesn’t work, try downloading EEPROM
- https://rweverything.com/ Windows
- https://github.com/applerom/runiflash DOS
- UNIX + their utilities.
Here is the EEPROM layout
https://github.com/redchenjs/rtnicpg
+ datasheet.

aVd wrote on Yesterday, 06:50:

Obviously, if there is a motherboard manufacturer's dedicated tool for setting the MAC address, it would be best to use it.

Sorry for bringing this up again, it just popped into my head.
Back in the LGA775 era, Gigabyte had already made up its mind – Realtek for audio, Realtek for networking.
ASUS, on the other hand, had a veritable menagerie of solutions.
Intel, Atheros, Realtek, VIA, Marvell. Who on earth did they order a utility from that covered all those NIC chips?
As with sound chips – Realtek, VIA, C-Media, Analog Devices (later acquired by Connexant), Connexant....... If only all of this didn't require drivers.🙁

shevalier wrote on Yesterday, 16:49:

ASUS, on the other hand, had a veritable menagerie of solutions.
Intel, Atheros, Realtek, VIA, Marvell. Who on earth did they order a utility from that covered all those NIC chips?
As with sound chips – Realtek, VIA, C-Media, Analog Devices (later acquired by Connexant), Connexant....... If only all of this didn't require drivers.🙁

I have no idea why or who on Earth will do this, but if I'm not mistaken, back in the days Asrock was something like daughter company/brand of Asus releasing more budget oriented products and it seems like they've done exactly this. The example is in my post about the "lost" MAC address of my Asrock K7Upgrade600 board after a regular and successful BIOS update from DOS prompt.

shevalier wrote on Yesterday, 13:35:

- https://github.com/applerom/runiflash DOS

This is interesting. I don't have this version of UNIFLASH. Do you have any idea how to compile it from these Pascal source files?

shevalier wrote on Yesterday, 16:49:

Who on earth did they order a utility from that covered all those NIC chips?

They did not. What they provided was a hodgepodge of tools from the NIC vendor.
This, for example, is what Asrock provided

MAC.EXE is just a front-end that identifies what is your NIC and then calls the appropriate tool from the vendor

aVd wrote on Yesterday, 18:58:

shevalier wrote on Yesterday, 13:35:

- https://github.com/applerom/runiflash DOS

This is interesting. I don't have this version of UNIFLASH. Do you have any idea how to compile it from these Pascal source files?

See attachment for a compiled version. I compiled it with Borland Pascal 7.0. Needed to be compiled with 286 instructions so won't run on < 286 CPU's.

It runs but I didn't tested it further btw.

Yoghoo wrote on Yesterday, 20:02:

See attachment for a compiled version. I compiled it with Borland Pascal 7.0. Needed to be compiled with 286 instructions so won't run on < 286 CPU's.

It runs but I didn't tested it further btw.

Thank you! Just saved me another search for old DOS Pascal compiler version 😀

shevalier wrote on Yesterday, 13:35:

- https://github.com/applerom/runiflash DOS

Original program is UniFlash https://www.rainbow-software.org/uniflash/ https://theretroweb.com/drivers/75

This fork deleted uniflash.txt erasing programs history and changelog. But mainly erasing ME from "The heroes gallery" 😁
https://www.rainbow-software.org/uniflash.txt

how dare they!!1 ;P

rasz_pl wrote on Yesterday, 23:58:

Original program is UniFlash https://www.rainbow-software.org/uniflash/ https://theretroweb.com/drivers/75 […]
Show full quote

shevalier wrote on Yesterday, 13:35:

- https://github.com/applerom/runiflash DOS

Original program is UniFlash https://www.rainbow-software.org/uniflash/ https://theretroweb.com/drivers/75

This fork deleted uniflash.txt erasing programs history and changelog. But mainly erasing ME from "The heroes gallery" 😁
https://www.rainbow-software.org/uniflash.txt

how dare they!!1 ;P

To be honest, I didn’t check this
Applerom is the developer of that very BIOSpatcher from Belarus.
He used to contribute patches to the vanilla Uniflash, but he put all his projects on hold a long time ago.

I was looking for a programmer for the Compex network card’s flash memory.
It seemed that this fork supported it, but it turned out that the flash was read-only.
The chip itself was designed back in the days of UV-eraseable ICs. (Does not have a ‘write enable’ pin.)