Time does not sync on Pi 3 and with official dongle [Solved]

[dobra-dobra]

I'm running Raspbian Jessie with all recent updates. When using Pi 2 or 3 time/date is not synchronizing at boot. When I placed the same SD card in Pi Zero time was updated correctly. What may be the problem?

Edit
Problem only occurs when using official WiFi dongle (no matter what Pi) or on Pi 3 when using WiFi connection. When I switched to other, Chinese dongle (which was plugged to Pi Zero in my first test) time was updated correctly.

[DougieLawson]

What channel is your AP running on?

Try the following:
ip route
ping -c3 $(ip route | awk '/default/ {print $3}')
ping -c3 8.8.8.8
ping -c3 google.com
cat /etc/resolv.conf

Do it both ways once with your dongle, once with the on-board WiFi and note the differences.

Edit: added the missing $.

[dobra-dobra]

Thank you for your response.

My AP runs on channel 6. Output from ip route and cat /etc/resolv.conf is exactly the same no matter what dongle I use and I receive ping responses (except ping -c3 (ip route | awk '/default/ {print $3}') which does not work - syntax error near unexpected token `(', but if it should ping my AP adress I have response from it). Still for official dongle with Broadcom chip there is no time sync (and the same is true for RPi 3 connected using build in WiFi), while for dongle with RTL8192CU chip time is updated just after reboot.

[chrisoh]

I don't know if it is related, but I also noticed that the system time did not update using the Pi 3 onboard WiFi. It updates normally with a (Ralink based) dongle though. I only got as far as identifying that UDP communication (used to update NTP) was not working as expected. IIRC, installing ntpdate 'fixed' it, despite being deprecated. There's a bunch more info in the 'Pi 3 SSH over WiFi not working' threads in Troubleshooting. I'm not familiar enough with linux routing to understand how it all fits together and what could be wrong though so haven't got any further it.

[DougieLawson]

Run the commands above and note the differences. Also beware that ntpd may start before the network is running and then your clock will be wrong. Restart ntpd and the problem should go away.

[dobra-dobra]

Here are the outputs: http://pastebin.com/Ys1GWWrm, I can't see any differences.

I tried new option in raspi-config to wait for network during boot but issue still occurs. I also tried to restart NTP server using /etc/init.d/ntp restart without any luck.

Edit
Here is output of /etc/init.d/ntp status: http://pastebin.com/hayrXJq0 It seems to me that NTP server is running, but time is not set (it's close to acurate because I'm switching between both dongles).

[DougieLawson]

You have no apparent connectivty problems, you can get to Google's servers and you can turn http://google.com into an IPv4 address.

sudo /etc/init.d/ntp stop
sudo ntpd -qg
sudo /etc/init.d/ntp start
will get your clock set right.

[chrisoh]

@Dougie, what's your take on this output:

Pi 3

Code: Select all

[email protected]:~ $ sudo ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 bwntp2.bluewin. .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 head1.mirror.ca .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 funky.fuchsi.de .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 main.macht.org  .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Pi Zero

Code: Select all

[email protected]rypizero:~ $ sudo ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.karneval.c 116.49.102.213   2 u   19   64  357   50.221    1.170   0.706
*stratum2-2.NTP. 129.70.130.71    2 u   55   64  377   49.913   -2.280   1.722
-s1.vlns.de      129.70.132.36    3 u   49   64  377   46.850   -3.015   0.606
+tilia.zsx.hu    192.53.103.108   2 u   25   64  377   68.430    2.838   0.820

Both clean Jessie installs.

@dobra-dobra, what's your ouput using:

Code: Select all

sudo ntpq -p

[DougieLawson]

Your RPi3 isn't connected to the public internet or you've got a badly configured firewall blocking NTP.

[dobra-dobra]

I left Pi 2 with official dongle (Broadcom chip) on for 5 hours and time is still incorrect.

@DougieLawson
I tried these commands already. I have a freeze after sudo ntpd -qg when using official dongle. Waited about 10 minutes to complete without any luck. When I switched to dongle with Realtek chip I got response after about 10 seconds.

@chrisoh
I have similar results - zeroes for Broadcom dongle and non-zero values for Realtek.

[DougieLawson]

If ntpd -qg hangs then your network isn't configured correctly.

[dobra-dobra]

But how it is possible that it works for one dongle, and does not work for other? Setup is exactly the same.

[chrisoh]

If ntpd -qg hangs then your network isn't configured correctly.

So you're basically saying my network isn't configured correctly for the Pi 3 WiFi chipset? Since all other wireless devices (and a nano dongle plugged into the Pi 3) work without problem. Is it just me or does that not sound quite backwards?

[DougieLawson]

Try running sudo apt-get update && sudo apt-get -y upgrade && sudo reboot.

If you're using NOOBS then trash your SDCard and try again with NOOBS 1.9.

[chrisoh]

It's already up to date. I've never used NOOBs and get the same result with Jessie, Jessie lite and DietPi; doesn't work with onboard WiFi and does work with a variety of nano dongles. All other Pi's work fine too. Android phones work, iPhones work, OSX and Windows work. Just the Pi 3 onboard WiFi that doesn't. Bemused is an understatement.

[DougieLawson]

Try
sudo BRANCH=next rpi-update

If that doesn't work then RMA the board as it's most likely a hardware fault.

[chrisoh]

Try
sudo BRANCH=next rpi-update

If that doesn't work then RMA the board as it's most likely a hardware fault.

I'll give the rpi-update a go tomorrow ta.

But can it really be a hardware fault if it's only NTP and IPv4 SSH that are exhibiting problems? That resembles a firmware/driver issue to me rather than hardware

[dobra-dobra]

It's not a hardware issue. I have two official RPi dongles with Broadcom chips and RPi 3. All of them do not sync time (but there is internet connection, I can ssh to them, make update or ping Google), while when I switch to other dongle in the same setup time is set just after boot. Moreover, in older Raspbian versions (before RPi 3 release) Broadcom-based dongles were working just fine, so to me it seems like software regression.

I tried sudo BRANCH=next rpi-update but problem still occurs. Freeze after sudo ntpd -qg is also still present.

[DougieLawson]

In that case I suspect you may have faulty hardware.

[SR-71]

Hi all,

ntpd emits IP/UDP packets with ToS field set to 0xc0.
So that is quite similar to the other issue I (and many others) have with RPI3 when operated over WiFi internal interface.

EDIT:

As workaround, add the following command

Code: Select all

/sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p udp --dport 123 -j TOS --set-tos 0x00

to the file

/etc/rc.local

before the exit 0 line.
Next reboot and check the sync state of NTP daemon as follows

Code: Select all

ntpq -cpeers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-kazan.admin.sar 212.45.144.3     3 u    7   64    3   20.413    1.826   2.975
+vodka.sublink.O 193.204.114.233  2 u    7   64    3   29.012    0.479   1.871
+kraken2.bilink. 193.204.114.232  2 u    7   64    3   29.342    1.270   3.581
*nettuno.ntp.irh 193.204.114.232  2 u    7   64    3   26.978    0.728   3.038

That points to some firmware/driver defect in RPI3 (it seems unable to forward IP packets with ToS != 0).

[chrisoh]

Hi all,

ntpd emits IP/UDP packets with ToS field set to 0xc0.
So that is quite similar to the other issue I (and many others) have with RPI3 when operated over WiFi internal interface.
Try to reconfigure ntpd in such way it uses ToS = 0.

If confirmed, that definitively points to some firmware/driver defect in RPI3 (it seems unable to forward IP packets with ToS != 0).

I came back to the computer to ask this very same question as I was just wondering if it was all somehow related, and here you are

[SR-71]

Hi all,

ntpd emits IP/UDP packets with ToS field set to 0xc0.
So that is quite similar to the other issue I (and many others) have with RPI3 when operated over WiFi internal interface.
Try to reconfigure ntpd in such way it uses ToS = 0.

If confirmed, that definitively points to some firmware/driver defect in RPI3 (it seems unable to forward IP packets with ToS != 0).

I came back to the computer to ask this very same question as I was just wondering if it was all somehow related, and here you are

I edited my previous message, if feasible, please give a try to the workaround suggested there.

[dobra-dobra]

I confirm that workaround presented by @SR-71 worked for both RPi 3 connected with built-in WiFi and RPi A+ with official WiFi dongle. Yay!

Thank you all for help with this issue.

[chrisoh]

I edited my previous message, if feasible, please give a try to the workaround suggested there.

Spot on mate, can confirm this work-around is working here too.

[oeffoeff]

That points to some firmware/driver defect in RPI3 (it seems unable to forward IP packets with ToS != 0).

Tyvm dude. Is there a bugtracker or something where we could report this issue?