Updating an interface via the api and sending lowercase mac_address creates a pointless changelog

[ITJamie]

Deployment Type

Self-hosted

Triage priority

N/A

NetBox Version

v4.1.4

Python Version

3.12

Steps to Reproduce

create an interface on a device. set a mac address. via the api update the interface with the same mac address but send it in lowercase form instead of uppercase form

Expected Behavior

if the mac addresses match (ignoring case), no changelog should be made

Observed Behavior

a change log is created showing the mac_address being set to lowercase. but its stored in the db in uppercase. so there was no need for the changelog being created

[ITJamie]

Example of the changelog thats created. but viewing the interface directly after this changelog shows that its stored as uppercase

[betheapi]

I would like to work on this issue

[jeremystretch]

Thanks @betheapi, I've assigned this to you. For reference, the MAC address should always be normalized to lowercase.

[atownson]

I can work on this one.

[atownson]

@jeremystretch,
Based on the comment above, MAC Addresses should be normalized to lowercase, correct? This line normalizes to uppercase: https://github.com/netbox-community/netbox/blob/f845b2cf07cd65a109c46632a2540d3647c1c492/netbox/dcim/fields.py#L43 I can change this, but wanted to confirm the desired normalization.

[jeremystretch]

I might be wrong then, sorry. Do whatever is most consistent with existing behavior.

[atownson]

Apologies for the back and forth. This issue does not affect NetBox version 4.2 with the new MACAddress model. I've tested patching the MACAddress object itself and the MAC Address associated with a VMInterface with differing variants of the mac_address value and neither results in a change log entry or an update to the object. The mac_address value is always normalized to uppercase using the dialect specification for the MACAddressField. I can look into a fix for the 4.1 version, but suspect a fix would not/could not be merged at this point. If that's not the case please let me know. Otherwise, you may consider marking this as resolved under 4.2.

[jeremystretch]

@atownson I agree that makes sense. We ended up going around the issue with the introduction of the new MACAddress model in v4.2. Thanks for digging into it.

I'm going to close this out as resolved.