You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
netifd makes the assumption that ipv6 segments will never be any smaller than a /64; it quite often computes things like (1 << (64 - prefix->length)) which obviously won't work out very well when prefix->length > 64. (Incidentally, it looks like it's never been tested with prefixes larger than a /32, too, since things like "int32_t current = 0, asize = (1 << (64 - assign->length)) - 1;" will also not work out very well when assign->length <= 32.)
The Linux network stack itself is more than happy to operate with these smaller segments, and odhcpd happily hands out leases. I know SLAAC won't work on these segments, but that's no reason to keep netifd from believing in them, IMHO. As it stands, I have several interfaces configured that the ubus-centric tools refuse to believe are set up!
The text was updated successfully, but these errors were encountered:
nwf:
netifd makes the assumption that ipv6 segments will never be any smaller than a /64; it quite often computes things like (1 << (64 - prefix->length)) which obviously won't work out very well when prefix->length > 64. (Incidentally, it looks like it's never been tested with prefixes larger than a /32, too, since things like "int32_t current = 0, asize = (1 << (64 - assign->length)) - 1;" will also not work out very well when assign->length <= 32.)
The Linux network stack itself is more than happy to operate with these smaller segments, and odhcpd happily hands out leases. I know SLAAC won't work on these segments, but that's no reason to keep netifd from believing in them, IMHO. As it stands, I have several interfaces configured that the ubus-centric tools refuse to believe are set up!
The text was updated successfully, but these errors were encountered: