=== cpaelzer_ is now known as cpaelzer [19:24] caribou: I've been looking into the IPv6 default route prefix issue and think I see where the problem is occurring === stw__ is now known as stw [22:02] minimal: whoops, sorry, just saw this now. I just put up a PR for it [22:02] (if we're talking about the same issue) [22:19] falcojr: ah ok, yes it's the same issue. I had a quick look at your PR but need to test it to understand what exactly the change does ;-) [22:20] basically, if there was a falsey value in the config, we'd strip it out. A prefix of 0 is falsey, so it'd get stripped out. Later we'd see no prefix and put in a default one [22:20] the change says "0 is valid, don't strip it out" [22:20] ah "0" as falsey rather than numeric 0, right that makes sense [22:21] yes I'd figured out the prefix was being stripped and so the big if then elseif block was falled through to the bottom and assuming /64 for IPv6 and /24 for IPv4 [22:22] I was in the middle of testing some other IPv4 & IPv6 routes to see if the problem only affected defaults or also others [22:23] if you already have them written/running, it'd be good to run them against my PR [22:23] I ran it against the current tests, but we're probably missing some use cases there [22:24] locally I've been creating a set of various static IPv4, static IPv6, static IPv4 & IPv6, SLAAC-related etc configs to test as I'm working on some other network renderering issues [22:25] so far only testing network config v2 but also want to check v1 as well [22:26] that's good. v2 probably needs more love anyway as it's the less common version [22:28] yeah, I'm trying to figure out various DHCPv6 related stuff for eni that are NOT documented as supported, e.g. privext, request_prefix, dhcp, autoconf [22:32] falcojr: I settled in v2 in general quite some time ago as there was stuff I was using that I couldn't do via v1 [22:32] minimal: Do you remember what kind of stuff? Just curious [22:33] falcojr: hmm, I'd have to dig throgh notes/files to figure out what, might have been vlan related, or renaming interface related [22:34] gotcha, not a big deal. Was just curious [22:36] falcojr: ah, maybe it was route related, with v1 you can't associate routes with particular interfaces from memory [22:37] oooh...yeah, I tried unifying how v1 and v2 get represented under the hood and ran into that [22:37] falcojr: another v2 routes issue is something I'm trying to fix currently