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

Prevent NTP updates from failing on RPi3 wifi #327

Merged
merged 1 commit into from Mar 25, 2017

Conversation

Projects
None yet
2 participants
@foosel
Collaborator

foosel commented Mar 24, 2017

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 foosel/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.

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 (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 foosel/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.
@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Mar 24, 2017

Collaborator

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.

Collaborator

foosel commented Mar 24, 2017

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.

@guysoft guysoft merged commit e1d1ead into guysoft:devel Mar 25, 2017

@guysoft

This comment has been minimized.

Show comment
Hide comment
@guysoft

guysoft Mar 25, 2017

Owner

BTW, we might want to do this, as done in FullPageOS:
guysoft/FullPageOS@6518244

Owner

guysoft commented Mar 25, 2017

BTW, we might want to do this, as done in FullPageOS:
guysoft/FullPageOS@6518244

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Mar 27, 2017

Collaborator

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

Collaborator

foosel commented Mar 27, 2017

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

@guysoft

This comment has been minimized.

Show comment
Hide comment
@guysoft

guysoft Mar 27, 2017

Owner
Owner

guysoft commented Mar 27, 2017

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Mar 27, 2017

Collaborator

Man, your network must really be horrible if even NTP fails :/

Collaborator

foosel commented Mar 27, 2017

Man, your network must really be horrible if even NTP fails :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment