Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: net: allow ParseMAC to handle pure base-16 numerical representation without hyphens #66682

steabert opened this issue Apr 4, 2024 · 0 comments


Copy link

steabert commented Apr 4, 2024

Proposal Details

The ParseMac function in says:

// ParseMAC parses s as an IEEE 802 MAC-48, EUI-48, EUI-64, or a 20-octet
// IP over InfiniBand link-layer address using one of the following formats:
//	00:00:5e:00:53:01
//	02:00:5e:10:00:00:00:01
//	00:00:00:00:fe:80:00:00:00:00:00:00:02:00:5e:10:00:00:00:01
//	00-00-5e-00-53-01
//	02-00-5e-10-00-00-00-01
//	00-00-00-00-fe-80-00-00-00-00-00-00-02-00-5e-10-00-00-00-01
//	0000.5e00.5301
//	0200.5e10.0000.0001
//	0000.0000.fe80.0000.0000.0000.0200.5e10.0000.0001

When reading the EUI guidelines however, it states in section "EUI Structure and Representation":

...[EUI-48/EUI-64] can be represented in the IEEE RA hexadecimal (hex) form with the octets separated by hyphens, or as a pure base-16 numerical representation without hyphens. It may also be represented as a binary number or sequence, as illustrated.

And on Wikipedia:

As typically represented, MAC addresses are recognizable as six groups of two hexadecimal digits, separated by hyphens, colons, or without a separator.

I haven't come across binary representations as the guidelines say are allowed, but it does happen (frequently enough) that the octets don't have a separator. In those cases I had to resort to a custom implementation of HardwareAddr just to deal with that case. I was not sure if this would be considered a bug (since the docs do state it should support EUI-48/EUI-64, but there does not seem to be an official required representation). However, this would slightly change the behaviour of ParseMAC in that it would accept a format without separators where it previously would return an error. So I filed this proposal instead of a bug report.

I think that extending ParseMAC to allow for a format without separators (only for the shorter formats EUI-48 and EUI-64) would at least (1) match what's stated in the documentation and (2) resolve the need for custom implementation at least for a use case that is frequent enough for me personally to care about (but of course I have no idea how common this is in general).

This would then allow the following formats in addition to those already mentioned:

//      00005e005301
//      02005e1000000001
@gopherbot gopherbot added this to the Proposal milestone Apr 4, 2024
@seankhliao seankhliao changed the title proposal: net: extend ParseMac to allow the EUI-48 and EUI-64 formats that it's docs claims are accepted proposal: net: allow ParseMAC to handle pure base-16 numerical representation without hyphens Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Status: Incoming

No branches or pull requests

3 participants