Prevent NTP updates from failing on RPi3 wifi #327
Conversation
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 (raspberrypi/linux#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 guysoft#294 and also documented in raspberrypi/linux#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 OctoPrint/OctoPrint#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.
|
As a small update on this, my initial test against OctoPi 0.13 appears to have been faulty, because I no longer can reproduce this problem even there. According to this thread it appears to be related to the WMM setting on the router, but disabling that here also didn't allow a reproduction. It's a mystery. Still, there are lots of threads across the net relating to this issue, so even if we can't reproduce that ourselves, I think this should be part of 0.14 just to be on the safe side, especially since at least two users have already run into this and reported back, who knows how many are there that didn't report back. |
|
BTW, we might want to do this, as done in FullPageOS: |
|
Never ran into an issue with the preconfigured servers (which appear to be mirrors of pool.ntp.org?). Do you have a report that goes along with that commit from someone who ran into trouble? Why the two selected servers as fifth and sixth instead of pool.ntp.org as a fifth? The nist one is located in the US, so bad latency for the rest of the world. I can't find anything specific about ntp.ubuntu.com |
|
I had that problem. Might be our amazing DNS caching in Israel.
|
|
Man, your network must really be horrible if even NTP fails :/ |
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 (raspberrypi/linux#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 raspberrypi/linux#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 OctoPrint/OctoPrint#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.