Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable network on ipv6-only hosts #208

Closed
wants to merge 2 commits into from
Closed

enable network on ipv6-only hosts #208

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5b92004
enable network on ipv6-only hosts
helmutg May 14, 2024
42bacc8
fakemachine.service should wait for network-online.target
helmutg Nov 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 2 additions & 5 deletions machine.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -301,9 +301,6 @@ Type=ether

[Network]
DHCP=ipv4
# Disable link-local address to speedup boot
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this cause any slow-down as per the comment above ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It quite definitely causes a slow-down. Not sure how much. To me the question is more of whether it works at all. I cannot use debos at all as a result of this problem.

Copy link
Member

@obbardc obbardc Oct 29, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late reply - I've been too busy to do any debos maintainance. Can you check if adding MaxAttempts=10 (with the original LinkLocalAddressing=no) and possibly IPv6AcceptRA=yes works for ipv6-only host & for regular host ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LinkLocal=no with IPv6AcceptRA seems wrong; Just doing ipv6 link local addressing would make more sense;

Mind ofcourse this change was done in 2017 so things in systemd might have changed quite a bit. In particular the behaviour of networkd-wait-online could well have changed to not wait for all address families (which i think was the reason for the slowdown)

@helmutg when you say definitely a slowdown; Is that something that you actually noticed during usage or more an expectation :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay.

I cannot actually observe any delay with these settings, because fakemachine does not actually work in any way unless I change them. It is only that I expect a slowdown.

So I did some more testing. With both IPv6AcceptRA=yes and LinkLocalAddressing=yes, it works most of the time. I had at least one failure and suspect that fakemachine.service was being run before the network interface succeeded in configuring. Just setting MaxAttempts=10 does not improve the situation in any way.

Adding MaxAttempts=10 and IPv6AcceptRA=yes also does not work. Neither IPv6AccptRA=yes nor LinkLocalAddressing=yes make it work in isolation. It is only when we combine them that it starts to work. Without the former, we don't get a default route and without the latter we don't get an IPv6 address assigned that could be routed.

In all of this, when I say "does not work", what I mean is "Network is unreachable" being part of the error message.

Given further debugging, I think this is not the full solution. Network interfaces are not reliably configured when systemd-networkd.service is started. What is really needed here is network-online.target, but that's not WantedBy or Before fakemachine.service in any way. Of course adding network-online.target will make things even slower (again not measured in any way, just an expectation that adding more dependencies will take longer). But then in the context I am trying to use it, it currently does not work at all (due to not supplying any working IPv4 connectivity).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The command wrapper does run /lib/systemd/systemd-networkd-wait-online -q --interface=ethernet0 to wait for network connectivity, so adding network-online shouldn't be needed. Looks like your change make our CI tests fail for some reason (which tbh is surprising).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your argument sounds reasonable to me, but we migrated away from debos towards debvm, which solves our niche use case way faster and more reliably (by not spinning up a secondary linux kernel). I'll leave things up to you here. If the MR stops being productive, please close it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries; I'll close it for now :) Thanks for the quick response!

LinkLocalAddressing=no
IPv6AcceptRA=no
`

const networkdLinkTemplate = `
Expand Down Expand Up @@ -340,8 +337,8 @@ Description=fakemachine runner
Conflicts=shutdown.target
Before=shutdown.target
Requires=basic.target
Wants=systemd-resolved.service binfmt-support.service systemd-networkd.service
After=basic.target systemd-resolved.service binfmt-support.service systemd-networkd.service
Wants=systemd-resolved.service binfmt-support.service network-online.target
After=basic.target systemd-resolved.service binfmt-support.service network-online.target
OnFailure=poweroff.target

[Service]
Expand Down
Loading