| KitsuWhooa | Hi slyon! Regarding https://github.com/canonical/netplan/pull/480#pullrequestreview-2182292260 ; I finally got the integration tests running and I'm writing ones for stable-privacy and eui64. With `ipv6-address-generation: eui64`, NetworkManager seems to use an address that's not EUI-64. Any idea what might be up with that? | 08:58 |
|---|---|---|
| KitsuWhooa | More specifically, with a mac address of 52:96:85:e2:98:e7, under NM I get inet6 2600::40f8:98ce:9bd8:901b/64 | 08:58 |
| KitsuWhooa | when it should be 2600::5096:85ff:fee2:98e7/64' | 08:58 |
| slyon | KitsuWhooa: that's great news, thanks for continuing with this work! | 09:01 |
| KitsuWhooa | happy to help :) | 09:01 |
| KitsuWhooa | Worth noting that if I remove `ipv6-address-generation` entirely, the interface gets the expected address | 09:02 |
| slyon | regarding the unexpected NM behavior... I'm not sure. Let me look into the code briefly. | 09:03 |
| KitsuWhooa | Thanks, appreciated! | 09:03 |
| slyon | KitsuWhooa: interestingly, we're using "g_key_file_set_string(kf, "ipv6", "addr-gen-mode", addr_gen_mode_str(def->ip6_addr_gen_mode));" (i.e. a STRING) | 09:10 |
| slyon | whereas we're using "g_key_file_set_integer(kf, "ipv6", "addr-gen-mode", 0);" (an int32) in other places. In the NM docs it's described as an int32 (https://www.networkmanager.dev/docs/api/1.32.8/settings-ipv6.html) | 09:10 |
| slyon | Not sure if that might be related?... Or if the string get auto-translated to an int. It would be worth a try. | 09:11 |
| KitsuWhooa | Ah! | 09:11 |
| KitsuWhooa | I'll play with it | 09:11 |
| KitsuWhooa | thanks | 09:11 |
| slyon | KitsuWhooa: Does it work correctly (i.e. use the token as IP suffix) when you set "ipv6-address-token" ? Because this sets EUI-64 addr-gen-mode properly (as int) plus the "token" | 09:12 |
| slyon | see src/nm.c lines 894++ | 09:13 |
| KitsuWhooa | one moment | 09:17 |
| KitsuWhooa | slyon: I'm even more confused now. I set the prefix to ::45. NM decided on `inet6 2600::5096:85ff:fee2:98e7/64 scope global tentative dynamic mngtmpaddr` (which is the EUI64 address, but no prefix in sight). Networkd on `inet6 2600::45/64 scope global mngtmpaddr noprefixroute` which I think is what would be expected. | 09:42 |
| KitsuWhooa | s/prefix/suffix/ | 09:42 |
| KitsuWhooa | `ipv6-address-token: "::45"` is what I added to the config basically | 09:43 |
| KitsuWhooa | I'll whip up a quick patch to use set_integer for eui64 and see if it changes anything in the original issue | 09:44 |
| slyon | right. sounds like setting "ipv6-address-token" sets eui64 correctly. But there might be a stacked issue with the "ipv6.token setting". | 09:51 |
| slyon | Kudos, your integration tests are already turining out to be useful! :) | 09:51 |
| KitsuWhooa | heh, thanks | 10:22 |
| KitsuWhooa | I printed the strings that get added to the config file, and it looks like it's literally adding the integers as strings | 10:22 |
| KitsuWhooa | so "0" and "1" | 10:22 |
| KitsuWhooa | which NM most likely does not like | 10:23 |
| KitsuWhooa | I guess the next question is, do I make them integers or proper strings like "eui64" | 10:23 |
| KitsuWhooa | I think the reason stable-privacy works is by accident, since according to the manual page it probably will default to it | 10:24 |
| KitsuWhooa | Ah, nothing else uses addr_gen_mode_str(). I'll just change that quickly | 10:29 |
| KitsuWhooa | Nope. Setting it to "eui64" still doesn't return the correct address. | 10:35 |
| slyon | KitsuWhooa: according to https://www.networkmanager.dev/docs/api/1.32.8/settings-ipv6.html I'd assume it needs to be set to (int32)0 and as you found, you can modify addr_gen_mode_str() accordingly. | 10:45 |
| KitsuWhooa | Yeah, I set it to an integer 0 and it's doing the exact same thing | 10:46 |
| KitsuWhooa | I wonder if the ipv6 privacy extensions are messing with it | 10:48 |
| KitsuWhooa | Hm, no, it can't be: "Configure IPv6 Privacy Extensions for SLAAC, described in RFC4941. If enabled, it makes the kernel generate a temporary IPv6 address in addition to the public one from MAC address via modified EUI-64." | 10:49 |
| slyon | "I wonder if the ipv6 privacy extensions are messing with it" – that was my first thought, too. But it should only add an additional address. | 10:52 |
| slyon | KitsuWhooa: are you able to make NM configure EUI-64 addresses when driven natively, without Netplan? | 10:52 |
| KitsuWhooa | I vaguely recall my 22.04 desktop being set to that via the GUI and then realising it and changing it to stable privacy | 10:53 |
| KitsuWhooa | which then led me wanting to enable stable privacy on my 24.04 server too which uses netplan and networkd, thus going down this entire path of implementing it | 10:53 |
| KitsuWhooa | but I can't verify right now | 10:54 |
| KitsuWhooa | I'll be able to check in a few hours | 10:54 |
| KitsuWhooa | Perhaps I can fire up a 24.04 VM remotely and test it | 10:56 |
| yatot | yow | 11:02 |
| yatot | whats up for you? | 11:02 |
| slyon | KitsuWhooa: I just tested it on my 24.04 desktop. Modified through NM-GUI. This is the Netplan config I end up with, which produces a proper EUI64 IP6: https://dpaste.org/CDRF9 | 11:05 |
| slyon | so it seems to be working. | 11:05 |
| KitsuWhooa | Ah, thanks. Was waiting for the ISO to download | 11:05 |
| slyon | (This is using current Netplan from git) | 11:06 |
| KitsuWhooa | I'm very confused why it's not working in my test | 11:06 |
| slyon | you're excuting the test as autopkgtest, right? | 11:06 |
| KitsuWhooa | Yup | 11:06 |
| KitsuWhooa | ~/netplan$ autopkgtest . --test-name ethernets -U --env=DPKG_GENSYMBOLS_CHECK_LEVEL=0 -- lxd autopkgtest/ubuntu/noble/amd64 | 11:07 |
| slyon | Can you try running it with "--shell" to get an interactive environment and introspect + play around with the NM & Netplan config in there? | 11:07 |
| KitsuWhooa | Ooooh, I had no idea that option existed | 11:07 |
| KitsuWhooa | very useful | 11:07 |
| KitsuWhooa | I don't have 'dhcp6: true' set | 11:08 |
| KitsuWhooa | just accept-ra and ra-only for dnsmasq | 11:08 |
| KitsuWhooa | This is SLAAC though so dhcpv6 shouldn't be relevant | 11:09 |
| slyon | there's some confusion around dhcp6: true. I think in the past it was needed to activate the DHCP client even for SLAAC. But these days it shouldn't. But maybe it's worth a try. | 11:10 |
| slyon | another thought... you're executing the test in a LXD container, which IIRC does not provide permanent MAC address. Maybe NM has some issue getting the proper MAC address for EUI64 in this environment. You might try running it in a VM, using "autopkgtest-buildvm-ubuntu-cloud -r noble", then execute the test with "autopkgtest [...] -- qemu /path/to/the/new-VM-image" | 11:11 |
| KitsuWhooa | The address is only changed when the image is generated though | 11:12 |
| KitsuWhooa | I'll leave that for later because it's already running in a VM | 11:12 |
| KitsuWhooa | As in, the LXD host is a VM | 11:12 |
| KitsuWhooa | if you feel like giving it a try, this is what I use https://tasossah.com/netplan_eui64.yaml | 11:13 |
| KitsuWhooa | Also, if the mac address was the issue, it wouldn't work when I don't specify addr-gen-mode at all | 11:14 |
| KitsuWhooa | if I comment that line in the config file above, it gets the expected EUI64 address | 11:15 |
| slyon | "it wouldn't work when I don't specify addr-gen-mode at all" – very true! | 11:25 |
| slyon | KitsuWhooa: oh.. I think I see what might be wrong here. | 11:29 |
| slyon | oh no. nvm :( | 11:29 |
| KitsuWhooa | Awh | 11:29 |
| KitsuWhooa | I had a thought that it might not be waiting long enough | 11:29 |
| KitsuWhooa | but that seems really far fetched | 11:29 |
| slyon | that's certainly possible! there are races like that in the Netplan test suite. And we implemented the "state_*()" methods to accomodate for that. You might consider adding a custom "self.state(...)" in "generate__and_settle()" to wait fot the expected token/MAC to appear. | 11:32 |
| * slyon afk for a bit | 11:32 | |
| KitsuWhooa | I have already added the ipv6 one when I noticed that sometimes I wouldn't get a v6 address at all | 11:33 |
| KitsuWhooa | but all that seems to do is just wait for any v6 | 11:33 |
| KitsuWhooa | The reason I said far fetched is because it'd mean NM would get a random address, then manually switch it to the EUI64 one | 11:33 |
| KitsuWhooa | s/manually/automatically/ | 11:33 |
| KitsuWhooa | I ran the test and interrupted it while it was running. nmcli says > ipv6.addr-gen-mode: default | 11:34 |
| KitsuWhooa | And if I manually set it to 0, it switches to the right address | 11:36 |
| KitsuWhooa | I think I figured it out | 11:41 |
| KitsuWhooa | there is a conflict | 11:41 |
| KitsuWhooa | There is '/run/NetworkManager/system-connections/Wired connection 1.nmconnection' which contains addr-gen-mode=default | 11:42 |
| KitsuWhooa | and there is '/run/NetworkManager/system-connections/netplan-eth42.nmconnection' which contains addr-gen-mode=0 | 11:42 |
| KitsuWhooa | both have interface-name=eth42 | 11:42 |
| KitsuWhooa | nmcli con doesn't show netplan-eth42 at all, despite it having id=netplan-eth42 in it | 11:43 |
| KitsuWhooa | Probably it sees 'W' first, then ignores the "duplicate" one | 11:45 |
| KitsuWhooa | Or maybe I'm wrong | 11:46 |
| KitsuWhooa | Something is definitely up with the autogenerated NM profile though as the netplan one doesn't show up | 11:46 |
| KitsuWhooa | 14:45:37 <KitsuWhooa> Probably it sees 'W' first, then ignores the "duplicate" one <-- it was after this that I remembered that NM can have multiple profiles | 11:48 |
| KitsuWhooa | I hate to say it, but dhcp6: true fixed it | 11:59 |
| KitsuWhooa | And more specifically, it's because it sets ipv6.method=auto | 12:02 |
| KitsuWhooa | without dhcp6: true, ipv6.method is set to manual, which makes the profile completely vanish from NetworkManager | 12:02 |
| slyon | ipv6.method=manual is a totally valid setting, so that's really strange.. But using "dhcp6: true" fixes your current case, at least (good job figuring it out!) – Investigation why the profile disappears when method=manual (and NM therefore autogenerating an ephemeral connection profile) is worth another investigation. | 12:19 |
| slyon | (feel free to create a bug report about that: https://launchpad.net/netplan | 12:19 |
| KitsuWhooa | I suspect it's because it's not actually specifying an address | 12:22 |
| KitsuWhooa | I'll dig into it and if I can't figure that out I'll open a bug so that it's not forgotten | 12:22 |
| KitsuWhooa | the dhcp6 property is very confusing as a name though | 12:23 |
| KitsuWhooa | I also was thinking of adding a safeguard to make sure before the tests are ran that it's not using an autogenerated profile | 12:23 |
| rrahl0 | is it intentionally, that when testing is enabled, that it still tests unit_tests (while disabled by the buildflag) | 14:44 |
| rrahl0 | trying to package netplan for opensuse, but run into the issue that unit_testing fails (afaiu because there is no network interface) | 14:45 |
| slyon | rrahl0: that's great news (netplan for opensuse)! The -Dtesting build flag is pretty recent, so there might be some cases that we didn't think about, see https://github.com/canonical/netplan/pull/493 | 14:59 |
| slyon | You're talking about a scenario where "-Dtesting=true" but "-Dunit_testing=false" right? | 15:00 |
| slyon | Overall the unit-test should not rely on any network-interface on the system, but should be able to run in isolation | 15:00 |
| slyon | If -Dunit_testing=false meson should not include anything in tests/ctests, so shouldn't run those tests | 15:01 |
| rrahl0 | slyon: yes, I have a unit_testing which fails, (only lo is available) | 15:10 |
| slyon | which one is it? I would consider this a bug in upstream Netplan | 15:11 |
| slyon | Feel free to skip it in your local packaging and file a bug report (or PR fixing it). | 15:11 |
| rrahl0 | give me a sec, I can rebuild the package, where the test fails | 15:11 |
| rrahl0 | tbf, as opensuse uses NM as the default network manager, I have already seen some other tests fail, when switching the fallback backend | 15:12 |
| rrahl0 | but for now I have left it at default | 15:12 |
| rrahl0 | oh, just realized, when testing=false and unit_testing=true, it doesn't test anything :) | 15:15 |
| rrahl0 | slyon: https://build.opensuse.org/package/live_build_log/home:rrahl0/netplan/openSUSE_Tumbleweed/x86_64 | 15:17 |
| slyon | oh, the meson "unit-tests" are unrelated to the "-Dunit_testing" build flag (that's confusing, sorry!) | 15:18 |
| slyon | the "unit-tests" can only be enabled/disabled using the new "-Dtesting" flag | 15:19 |
| rrahl0 | ahh. makes now a little bit more sense then. :) | 15:20 |
| slyon | rrahl0: I'm afraid the "last 100 lines" of the log file that are shown here do not contain the actual failure. Do you have access to the full log file? | 15:20 |
| rrahl0 | I should be able to build it locally, and hopefully I can find the log file then :) | 15:21 |
| slyon | side-note: the -Dunit_test controls the execution of the "test_netplan_*" tests, which seem to be passing for you | 15:21 |
| rrahl0 | on tumbleweed yes, still need to fix up leap though. (tbf way older codebase :D) | 15:22 |
| === slyon changed the topic of #netplan to: Netplan v1.1 | Declarative network configuration for various backends | https://netplan.io | https://github.com/canonical/netplan | https://bugs.launchpad.net/netplan | ||
| rrahl0 | slyon: found out that the build VM doesn't get booted with systemd oO. so I have a couple tests failing https://paste.opensuse.org/pastes/f553555881ba | 15:27 |
| rrahl0 | well seems like it's a opensuse issue | 15:27 |
| slyon | oh, interesting! Yeah, you probably need a systemd (build-)dependency | 15:28 |
| rrahl0 | well i do have systemd as builddependecy, but i still don't understand why the VMs are not using systemd anyway. as systemd is the only pid1 opensuse offers | 15:30 |
| rrahl0 | slyon: another question then. afaiu you can use netplan without netplan_cli? trying to figure out if I want to package dbus seperatly (to the cli tool) | 15:32 |
| slyon | that's true. You can run the netplan-generator independently of netplan_cli (avoiding the Python runtime dependency). The D-Bus daemon still (currently) has a dependency on netplan_cli, though. As it's executing some commands on the Netplan CLI in some cases. We're trying to get rid of that in the future. | 15:35 |
| slyon | here you can see the split of binary packages that I implemented for Debian: https://salsa.debian.org/debian/netplan.io/-/blob/debian/unstable/debian/control?ref_type=heads | 15:35 |
| slyon | look into netplan-generator.install especially to see learn about the minimal Netplan tooling, which can be used to bring up networking at boot time: https://salsa.debian.org/debian/netplan.io/-/blob/debian/unstable/debian/netplan-generator.install?ref_type=heads | 15:36 |
| rrahl0 | yeah, I already spied on the debian packaging :). ahh so I leave the packages seperately then, just adding a requires. hopefully the dependency is gone then. now I still have to do a PR (as the names for the python dependencies on rpm based distros is wrong) | 15:36 |
| slyon | looking forward to your PR! :) | 15:37 |
| rrahl0 | luckily we don't have that issue, as netplan was never in the repos, and as I am the first one doing the push for it, no legacy I have to care about :3 | 15:38 |
| rrahl0 | the only problem is rather that leap has a 5y old codebase, which means a lot of stuff work different than nowadays | 15:39 |
| KitsuWhooa | slyon: Sorry, one more thing; Should I have the eui64 and stable-privacy tests separate, or combine them into one with two interfaces? | 16:08 |
| slyon | KitsuWhooa: both is fine for me, I guess. But maybe having it separate is cleaner as we could see from the test_name which case is failing | 16:10 |
| KitsuWhooa | sounds good to me | 16:12 |
| fanatic26 | Hi is this an active channel? I am getting desperate trying to figure out netplan and ive been failing at it for 3 days now | 21:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!