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

Create NETWORK_ENABLE_NTP_QUIRKS option #241

Open
wants to merge 6 commits into
base: devel
Choose a base branch
from

Conversation

jxmx
Copy link
Contributor

@jxmx jxmx commented Dec 9, 2024

There is obsolete code in modules/network that tries to force-mangle iptables for NTP purposes. This adds an option to enable that behavior if desired.

@guysoft
Copy link
Owner

guysoft commented Dec 10, 2024

Hey, looks good, but there seems to be a conflict, perhaps because I rebased the previous PR

@jxmx
Copy link
Contributor Author

jxmx commented Dec 10, 2024

Fixed

@guysoft
Copy link
Owner

guysoft commented Dec 15, 2024

Stil conflicting here

@jxmx
Copy link
Contributor Author

jxmx commented Dec 16, 2024

Not sure why that was marked as conflict. I re-saved it. Says it's merge-able again.

@guysoft
Copy link
Owner

guysoft commented Dec 19, 2024

Says its still in conflict.
Note: Thanks for making me look in to it, we will get this in eventually.

It comes from this commit:
0720d5f

@foosel If you have any input and not to busy to add it here it would help.
It says on page 3 of that forum that new rpi installs have fixed this.

Might be also worth to have the NTP comment on top of the config variable.

Prevent NTP updates from failing on RPi3 wifi
While I couldn't reproduce this issue on a current build, apparently
it doesn't necessarily have to happen always and the corresponding
ticket on the rpi bug tracker (https://github.com/raspberrypi/linux/issues/1519) is still
open as well.

Hence this change. As documented at

  https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=141454

and other locations, ntp updates on RPi3 (sometimes?) fail if the
built-in WiFi interface is used. This appears to be the same issue
or at least related to SSH not properly functioning as described
in #294 and also documented in https://github.com/raspberrypi/linux/issues/1519.

A wrong system date of the underlying OS will cause issues with
SSL handshakes, which in turn will produce fatal errors when
attempting to install plugins (see https://github.com/OctoPrint/OctoPrint/issues/1827) or
probably also when updating either OctoPrint or the system itself.
Basically anything that does certificate validity checks will fall
on its face.

Having the Pi properly set its system date is hence crucial for
operation, so we need to make sure ntp can do its job.

This might also affect RPiZeroW - I haven't observed the issue
with a current build there though.

@jxmx
Copy link
Contributor Author

jxmx commented Dec 19, 2024

I do not see this in conflict:

image

@jxmx
Copy link
Contributor Author

jxmx commented Dec 19, 2024

Regarding Pis, AllStarLink currently has hundreds if not 1000+ Pi appliance installs of Debian 12 bookworm using CustomPiOS and our setup doesn't use iptables or ntpd and there have been no reports of time sync problems. We support Pi 3, 4, 5 and Zero W2s.

@jxmx
Copy link
Contributor Author

jxmx commented Dec 28, 2024

@guysoft I merged in devel with this branch. Are the conflicts clear now?

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.

2 participants