Date - Time on wifi

Help and Support Help
1

Hello,

I am new to Volumio, I am trying to install it on a RPI3. I have downloaded and installed version 2.513. First boot via Ethernet cable, configuring Wifi, and since that time, I use only the Wifi.

The audio part works fine, I use an external USB DAC (Objective DAC). I can listen to music, no problem. My music is on an NAS, as flac files.

I have an issue with time synchronisation. The RPI3 keeps using the date/time of the first boot, i.e 20 Dec 2018, and does not update.

This is my first question: during the configuration phase, it was apparently able to grab time synchronisation from the cable connection, I did not do anything special for this. But, after reboot on Wifi, it seems to go back to this date, which I do not understand. From my pov, it should:

  1. be able to get accurate date time though wifi (see below, this does not work yet)
  2. go back to 1970, first “Unix date”.

How can the “20 Dec 2108” survive to a reboot? Is it stored/cached somewhere?

EDIT: I noticed there is a file named fake-hwclock.data in /etc which obviously acts as a cache, so that’s why the date does not go back to 1970 on reboot. This is the anser to the question above…

I am trying to have ntp client running to solve this issue.

ntp and timesyncd are running:

volumio@volumio:~$ ps -edf | grep timesyncd
systemd+   337     1  0 03:28 ?        00:00:00 /lib/systemd/systemd-timesyncd
volumio   1265  1082  0 03:55 pts/0    00:00:00 grep timesyncd
volumio@volumio:~$ ps -edf | grep ntp      
ntp        714     1  0 03:28 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 100:104
volumio   1267  1082  0 03:55 pts/0    00:00:00 grep ntp

I am synchronized on a ntp server, after stopping and restarting the service, and uncommenting the last line of /etc/systemd/timesyncd.conf

Servers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
volumio@volumio:~$ systemctl stop systemd-timesyncd.service
volumio@volumio:~$ systemctl start systemd-timesyncd.service
volumio@volumio:~$ sudo systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: active (running) since Thu 2018-12-20 03:59:17 CET; 3s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 1313 (systemd-timesyn)
   Status: "Using Time Server 149.202.220.144:123 (0.debian.pool.ntp.org)."
   CGroup: /system.slice/systemd-timesyncd.service
           └─1313 /lib/systemd/systemd-timesyncd

Dec 20 03:59:17 volumio systemd[1]: Started Network Time Synchronization.
Dec 20 03:59:17 volumio systemd-timesyncd[1313]: Using NTP server 149.202.220.144:123 (0.debian.pool.ntp.org).

But I’m still stuck on the same date:

Thu Dec 20 04:01:26 CET 2018

Timedatectl show that the ntp synchronisation is active, but still the wrong date… :cry:

volumio@volumio:~$ sudo timedatectl
[sudo] password for volumio: 
      Local time: Thu 2018-12-20 04:16:03 CET
  Universal time: Thu 2018-12-20 03:16:03 UTC
        RTC time: n/a
       Time zone: Europe/Paris (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2018-10-28 02:59:59 CEST
                  Sun 2018-10-28 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2019-03-31 01:59:59 CET
                  Sun 2019-03-31 03:00:00 CEST

What is wrong? Thanks for your help.

2

Hello,

I think I solved the problem :mrgreen: . Solution is described here: raspberrypi.org/forums/view … 8&t=141454

Adding the described line to /etc/rc.local and rebooting solved the issue, the date and time are now correct.

This seems to be related to the inboard wifi card driver (?), which is, if I am right, encapsulated in the image of volumio.

I have another RPI3, running a full Raspbian Jessie, and connected with Wifi, and I did not have any problem with ntp on this raspbian distro. So maybe something to update in the volumio image? The image I have is 2.513, very recent.

I have added “solved” to the title of this thread.

3

Hum, not sure it is solved. Problem is back tonight… Sorry

4

Hello all

Am I the only one that encounters this issue? NTP works on wired cable, but not on wifi on my RPI3. I don’t know today how to solve this, not being a “NTP guru”.

There is a workaround: if you have another computer on your local network with accurate time/date (a NAS for example), all you need is:

  • establish a ssh authentification with this computer (using ssh-keygen). This must be done for the root account on volumio, because it will be run as root.

  • add these lines in /etc/rc.local:

sleep 10
myping=`ping -c 4 192.168.0.21 | grep "64 byte" | wc -l`
if [ "$myping" = "4" ]
then
	mydate=`ssh pi@192.168.0.21 date`
	date -s "$mydate"
else
	echo `date` >> /tmp/myping.log
	echo "Failed ping to RPI" >> /tmp/myping.log
fi

Of course, replace the ip address and account (pi / 192.168.0.21) by the one of your “time server”. In my case, it is a RPI1 which runs 24/24, and acts as a file server. But any Unix/Linux computer will make the job.

They are executed as root, so no need for sudo in the script. This will adjust your time/date in volumio. The precision will not be better that one or 2 seconds, but I don’t care. All I need is to have the “right” time/date.

Check the file “/tmp/myping.log” if something goes wrong.

Hope this helps.

If anybody would have any elegant solution to actually solve the ntp issue (not only another workaround), I woukd be happy to read it, of course.

5

Dunno if you also need to, but I had to set my country code in /etc/default/crda to have it remember the proper timezone setup with.

6

Thanks for your reply.

Yes, I did this (this is described in another topic of this forum

unable-set-accurate-time-time-zone-t7673.html

), but this did not help. Still stuck with ntp. In Wifi, all ntp servers are scanned but run in timeout, as already described.

Today, the only acceptable workaround I found is the one described above. Not the most elegant, I must admit, but it works…

The fact that cable wired did work out of the box makes me think that the ntp configuration is correct. The trouble is with ntp through Wifi connectionn it seems.