Open mllken opened 1 year ago
Hi @mllken! Thanks for opening this issue!
Yeah I agree, I think we could have a dedicated type which also allow us to work with MAC addresses with ease. Would you like to work on this? As a first iteration I think we could:
MacAddr
just as the one you shared in your comment: MacAddr([u8; 6])
.Option<String>
with Option<MacAddr>
I think now its a good time to introduce such a change due to the improvement suggested on #37, a single major release could introduce both changes!
Looking into this. It seems winapi defines PhysicalAddress as [u8; 8] (8, instead of 6). The current linux code in your crate can also handle mac addresses of any size. The proposed type might be too restrictive to support all your currently supported platforms.
Looking into this. It seems winapi defines PhysicalAddress as [u8; 8] (8, instead of 6). The current linux code in your crate can also handle mac addresses of any size. The proposed type might be too restrictive to support all your currently supported platforms.
Yeah theres two main schemes for Mac Addresses, one being the EUI-48 and the second is the EUI-64 scheme.
Theres more details in this RFC document: https://www.rfc-editor.org/rfc/rfc7042#page-6
I think we could have an approach to support both scenarios using an approach similar to std's for IpAddr
and have an enum
like:
enum MacAddress {
Eui48(Eui48),
Eui64(Eui64),
}
I think we could construct at the moment of parsing the Mac Address bytes in question.
WDYT?
Hi,
Currently, NetworkInterface's
mac_addr
member is aOption<String>
. It would be nice to have a simpleMacAddr
type, like:with a From<[u8; 6]> impl and an octets method that returns [u8; 6].
Since
mac_addr
currently uses a String, it's unclear if it's uppercase, lowercase, inxx:xx:xx:xx:xx:xx
format, or inxx-xx-xx-xx-xx-xx
format. This will make comparisons easier. I can attempt a pull request if you agree with the idea. Thanks