@phrogger Were you observing a similar error as this issue? #2073

@brentru I don't think they are the same problem.
The issue I am reporting is that the Wiznet 5500 has no on-board long term memory for a MAC address, so if you don't give it one after boot, it makes up a random number for the MAC, and causes an IP address change every time you reboot. The Arduino API has a function to assign/force a MAC address. The CP API does not.
As far as I know, it is stable as long as power is still applied, so should not cause this issue. I didn't go beyond discovering it was hopping IP address every power cycle, and I put it back in the desk drawer.
--- graham (discord), aka phrogger(github)

Yeah, that's correct. The implementation as it is makes up a random MAC (in the appropriate range) but if there's an Adafruit-assigned MAC serial number or something we could change it to use that.

It'd also be easy enough to add an interface to set the MAC.

(check out

@nickzoic Thanks for the pointer about RMII on ESP32. I have read about some people doing that. In my case, I just switched to BBB for my application, which seems to have a well behaved network interface.

While the MAC is still changing every power cycle, calling ifconfig appears to correctly set the IP address now (v4.1.2):

# set up networking
spi = busio.SPI(clock=board.SCK, MOSI=board.MOSI, MISO=board.MISO)

eth = wiznet.WIZNET5K(spi, board.D10, board.D11)
eth.ifconfig(('10.2.1.220', '255.255.255.0', '10.2.1.1', '10.2.1.1'))

I didn't need to explicitly disable DHCP, and the correct IP shows up in eth.ifconfig() calls after a few seconds.

Yeah, the MAC thing is interesting. The random MAC function works for me, but doesn't match a lot of other people's use cases by the looks, eg: people who want to have DHCP set a stable IP.

@tannewt et al what do you think of adding:
a) a configuration method to get/set the MAC (eth.macaddr(b'\xaa\xbb\xcc\xdd\xee\xff'); print(eth.macaddr()))
and/or
b) stashing the MAC to NVRAM somewhere so it is persistent once chosen?
(the NVRAM is on the SoC not the W5500 so we'd have to work out how that fits in on various platforms though ... are there other things which require persistence at the moment?)

@nickzoic I think we should provide some way to set the address. But I was thinking it should be an optional argument the constructor so doesn't change from the very start.

We have 256 bytes of internal config storage on atmel-samd; right now a small fraction of that is used to store USB clock calibration info. On nrf we have 32kB of flash used for bonding information. In both of those cases that storage is used by the underlying native modules, and is not directly exposed to the user. But the MAC address is more "public", the user could store in some file in the file system, in the program code itself, or in microcontroller.nvm as well. I'm not sure it needs to be in a special reserved area, though we could do that.

Hey Dan! Happy New Year!

I was thinking that for 99% of users it's something they never want to think about so long as it doesn't change, so it'd make sense to stash six bytes into "hidden" non-volatile storage (eg: not the parts exposed by the filesystem or microcontroller.nvm) ...

Suppose we use the burned in serial number (available as microcontroller.cpu.uid) to generate the MAC address. It's meant to be unique, so I think it will serve the purpose well. There could still be a way to set it in the constructor if the user so desired, but we don't have to add that now.

P.S. Happy New Year to you too!

Re hashing: I don't have much experience with this, but I read some stackoverflow answer which pointed to one of the functions mentioned here: https://en.wikipedia.org/wiki/List_of_hash_functions#Non-cryptographic_hash_functions

I'd argue that we really don't want to pick random/hashed UAA addresses (eg: within Adafruit's OUI) ... they're supposed to be administratively controlled.

Better to use a LAA address where we get 46 bits of address space to play with and a much lower probability of collision.