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.

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

revert e3c5de1 #425

Merged
merged 1 commit into from
Jan 15, 2025
Merged

revert e3c5de1 #425

merged 1 commit into from
Jan 15, 2025

Conversation

zacknewman
Copy link
Contributor

Fixes #407.

@zacknewman
Copy link
Contributor Author

Alternatively, we can revert the commit just for OpenBSD (i.e., I can remove defined(__FreeBSD__) || in the preprocessor directive).

@perkelix
Copy link
Contributor

I'd just revert the whole change completely. It has broken expected operation on Linux too, as I reported in #392.

@zacknewman
Copy link
Contributor Author

I'd just revert the whole change completely. It has broken expected operation on Linux too, as I reported in #392.

That's unrelated. The reverted commit only impacts OpenBSD and FreeBSD as you can see with the preprocessor directive. I don't use FreeBSD, so I can't say for certain the commit is invalid for FreeBSD. I just know it's invalid for OpenBSD. The commit also only impacts IPv6. OpenBSD does not allow IPv6 sharing; thus when a route is attempted to be added for the same interface, it forbids it causing /var/log/daemon to be spammed. Before the problematic commit, dhcpcd only attempted it if it was not an IPv6 route on OpenBSD and FreeBSD.

@rsmarples rsmarples merged commit 6d4b19d into NetworkConfiguration:master Jan 15, 2025
@rsmarples
Copy link
Member

I haven't been able to replicate it, but I'll revert as is.
I'll see if I can submit a FreeBSD kernel change at least so we can drop that test at some point.

@zacknewman
Copy link
Contributor Author

Based on the original comment, you were unable to trigger a kernel panic in FreeBSD when you first wrote that code as well. Not sure why you are unable to trigger it. Perhaps it's a case of running in a VM vs. bare-metal? The lease file I e-mailed was of no help?

@rsmarples
Copy link
Member

Ah, I lost the lease file. Do you still have it?

@zacknewman
Copy link
Contributor Author

Re-sent. Did you receive it? [email protected], correct?

@rsmarples
Copy link
Member

Yes thanks.
Note for future self, I was able to re-create it on OpenBSD-7.6 by ensuring a default route was not present.
I still feel like this is a kernel bug that should be fixed.

rsmarples added a commit that referenced this pull request Jan 15, 2025
@zacknewman
Copy link
Contributor Author

zacknewman commented Jan 15, 2025

I'm glad you were able to re-create it. You can try submitting a kernel patch, but IPv6 is unfortunately still treated with disdain by some of the community so there may be pushback. I know OpenBSD (ab)uses the fact that currently only the fe80::/64 portion of the fe80::/10 link-local block can be used; thus they use the second octet pair to embed the interface index. Point being there are likely other issues with the IPv6 stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IPv6 GUA not assigned to CPE interface on boot up
3 participants