Missing VXLAN properties and wrong type for IP addresses
ffmancera opened this issue · comments
As reported in nispor/nispor#95, I've found out that some VXLAN properties are missing, then we cannot report them from Nispor anymore. In order to fix this I am implementing the support. About the IP address on VXLAN (Local, Local6..) they are being reported as u32 and u128 which seems wrong in my opinion. To keep consistency with the whole project they should be Vec<u8> like netlink_packet_route::rtnl::address::nlas::Nla::Address. What do you think? @little-dude @gabrik
In addition, MAC VTAP support is missing and since MAC VLAN is supported we cannot re-use code anymore.
I am doing all the work, no worries for that. This issue is for tracking and discussing the issue. Thanks!
@little-dude I am also planning to add all the "Info*" for all the supported interfaces this week. I will create a single PR for each feature. So there is no need to release after merging :-)
Thanks!
@ffmancera @gabrik sorry for not keeping up here. Lots of things happening IRL, and I can't find the time/motivation to work on this library at the moment. If you don't mind, I sent you guys an invite as maintainers so that you can review and merge code. Long term, I'd love to have people helping with code reviews so that this project does not solely depends on the amount of time and energy I have to dedicate to it.
Regarding IP addresses in general, I'm wondering whether we should use ::std::net::IpAddr or [u8; 4] and [u8; 16]. I don't remember the reason for choosing Vec when I started this library and retrospectively it seems a bit weird.
I used [u8;4] and [u8;16] just because I'm used to it and because it bounds the size of the IP addresses.
That said using ::std::net::IpAddr and from there getting the octets should always work as I expect that the size is checked in the std library
Yeah arrays or IpAddr are equivalent, since IpAddr implements From<[u8; 4]> and From<[u8; 16]>, and Ipv4Addr and Ipv6Addr have the octets() method which return the array.
@ffmancera @gabrik sorry for not keeping up here. Lots of things happening IRL, and I can't find the time/motivation to work on this library at the moment. If you don't mind, I sent you guys an invite as maintainers so that you can review and merge code. Long term, I'd love to have people helping with code reviews so that this project does not solely depends on the amount of time and energy I have to dedicate to it.
I fully understand this. I will try to help you mantaining the library :-)
I've found out another issue regarding dst_port property. #126
All issues fixed.