issues with NTP behind a WPA2-Enterprise firewall

[Bill M.]

I've been trying to get a Shake 1D to work behind a firewall that uses WPA2-Enterprise.

I can reliably connect the the network via WiFi; the problem is the NTP connection.

With the Shake software (v10 and now v11), the initial ntpdate.service fails with a timeout error. Time is not set, and the list of ntp servers all remain in INIT mode.

On another Pi, with a standard install of Stretch Lite, the default
systemd-timesync service sets the correct time without issue (but this is sntp).

Disabling this service and installing ntp using apt-get also functions without issue; port 123 is open, and the ntpd can access both the internal (behind the firewall) and external ntp servers (this install uses init.d rather than systemd).

At home (now using WPA2-Personal) the Raspberry Shake (all versions up to v11) can initialize the time (using the Shake ntpdate.service) and access the ntp servers without complaint.

The problems occur only with the unique combination of the Shake software using systemd to manage ntpd and WPA2-Enterprise.

I've looked at the definitions of the services (lib/systemd/system/ntpdate.service and lib/systemd/system/ntpd.service) and they seem straightforward (except for the ntpd -t 5. option)

The ntpdate.service only waits for the network (After=network-online.target) but perhaps it needs to delay further.

The definition of the Raspian Stretch systemd-timesyncd.service waits for the filesystem and sysusers.service to allocate the system users and groups (which the Shake software doesn't have).

(That is:
After=systemd-remount-fs.service systemd-tmpfiles-setup.service systemd-sysusers.service)
It also specifies:
Restart=always
RestartSec=0

I'm not familiar enough with systemd to know where I can insert an extra delay to prevent the timeout, or even what's timing out. I'd also like to keep the Shake software as vanilla as possible. Have you encountered this problem before? Any suggestions?

Thank you in advance,
Bill

P.S. Station Name: RA151

A bit of postboot.log:
2018 109 23:18:13: We have an internet connection
2018 109 23:18:14: NTP failed to start, and we have an interent connection, trying to restart it...
Job for ntpdate.service failed. See 'systemctl status ntpdate.service' and 'journalctl -xn' for details.
2018 109 23:19:50: NTP failed to start, and we have an interent connection, trying to restart it...
Job for ntpdate.service canceled.

>>systemctl status ntpdate.service
Just reports that it failed with a timeout error

[Marco Walther]

Did you check that the NTP servers (which the Shake wants to use) are
accessible from your WPA2 Enterprise network? (/etc/ntp.conf)? That
seems likely to be the cause for a timeout:-( Compare that to the
'working' set of servers.

You could add your (known good) internal NTP servers to the list there;-)

Hope that helps,
-- Marco

>
> Thank you in advance,
> Bill
>
> P.S. Station Name: RA151
>
> A bit of postboot.log:
> 2018 109 23:18:13: We have an internet connection
> 2018 109 23:18:14: NTP failed to start, and we have an interent
> connection, trying to restart it...
> Job for ntpdate.service failed. See 'systemctl status ntpdate.service'
> and 'journalctl -xn' for details.
> 2018 109 23:19:50: NTP failed to start, and we have an interent
> connection, trying to restart it...
> Job for ntpdate.service canceled.
>
>>>systemctl status ntpdate.service
> Just reports that it failed with a timeout error
>

> --
> Some useful links:
>
> Manual: http://manual.raspberryshake.org/
> Do It YourSelf Page: http://raspberryshake.org/do-it-yourself
> Shop: https://shop.raspberryshake.org/
> Website: http://raspberryshake.org/
>
> Instagram: https://www.instagram.com/raspishake/
> Facebook: https://www.facebook.com/raspishake/
> Twitter: https://twitter.com/raspishake/
> Hashtag: #rasperryshake, @raspishake
> DOI: https://doi.org/10.7914/SN/AM
> ---
> You received this message because you are subscribed to the Google
> Groups "RaspberryShake" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to raspberryshak...@googlegroups.com
> <mailto:raspberryshak...@googlegroups.com>.
> To post to this group, send email to raspber...@googlegroups.com
> <mailto:raspber...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/raspberryshake.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/raspberryshake/9f5cc2c0-e053-45ec-ab90-9820bcead09e%40googlegroups.com
> <https://groups.google.com/d/msgid/raspberryshake/9f5cc2c0-e053-45ec-ab90-9820bcead09e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Bill M.]

Thanks for your suggestion Marco, but it must be something else:

Yes, I've edited the /etc/ntp.conf file in both cases to add both ntp servers behind the firewall and elsewhere from the North American pool. I should have been more clear:
e.g.added to ntp.conf
server 132.216.30.202 iburst
server 132.216.30.203 iburst
server 0.north-america.pool.ntp.org iburst

1) Shake software, WPA2-Enterprise: both behind the firewall and external ntp servers timeout (left in INIT state) (/etc/ntp.conf edited) (WiFi connects)

2) Raspian Stretch Light, WPA2-Enterprise: ntp servers behind the firewall and external accessible using both systemd-timesyncd.service (sntp) and ntp (init.d)

3) both Shake and Stretch Light, WPA2-Personal: external ntp servers accessible

Bill

[Branden Christensen]

Buenos días Bill:

We will be getting back with you on this issue soon. 

Yours, 

Branden Christensen

Director, OSOP & Gempa GeoServices

Director, Raspberry Shake project, Social Media: @raspishake

USA: +1-845-418-5735; Panamá: +507-6747-1427

--
Some useful links:
 
Manual: http://manual.raspberryshake.org/
Do It YourSelf Page: http://raspberryshake.org/do-it-yourself
Shop: https://shop.raspberryshake.org/
Website: http://raspberryshake.org/
 
Instagram: https://www.instagram.com/raspishake/
Facebook: https://www.facebook.com/raspishake/
Twitter: https://twitter.com/raspishake/
Hashtag: #rasperryshake, @raspishake
DOI: https://doi.org/10.7914/SN/AM
---
You received this message because you are subscribed to the Google Groups "RaspberryShake" group.

To unsubscribe from this group and stop receiving emails from it, send an email to raspberryshake+unsubscribe@googlegroups.com.
To post to this group, send email to raspberryshake@googlegroups.com.

Visit this group at https://groups.google.com/group/raspberryshake.

To view this discussion on the web visit https://groups.google.com/d/msgid/raspberryshake/194e1f1a-b07a-4145-8fb7-fa6605e4a26a%40googlegroups.com.

[Richard]

hi bill,

can you provide me some additional diagnostic information please?

• output of command 'ntpq -p'
• contents of file /etc/ntp.conf

and try a couple of things to see if there are any differences in behavior:

• in the /etc/ntp.conf file, specify *only* the NTP servers that are on the same side of the firewall as the shake unit
• restart ntp services (see below)
  

notes:

• you can restart ntpd and ntp services using the following sequence of commands:
• sudo systemctl stop ntp
• sudo systemctl restart ntpd
• sudo systemctl start ntp
• output of command 'sudo journalctl -xn' when 'restart ntpd' fails
  

(but since we're only trying to get ntpd started successfully, you can leave off the 'start ntp' command until ntpd is working properly.)

as for port 123, it needs to have both TCP and UDP protocols open in both directions, please confirm this is true.

hopefully, something from the above will further illuminate what might be going on here.

thanks in advance,

richard

[Bill M.]

Thanks Richard; our institution prohibits port scanning, so I delayed my answer until I could get an official response.

I've attached as files the:

• output of command 'ntpq -p'
• contents of file /etc/ntp.conf

and a log of various the responses from

sudo journalctl -xn

and

sudo systemctl status ntpdate.service

and

sudo systemctl status ntpd.service

during startup and then the stopping and restarting of the ntpd.service

They are not very illuminating. Working through your list,

"as for port 123, it needs to have both TCP and UDP protocols open in both directions, please confirm this is true."

I had an 'aha' moment:

The institutional firewalls block 123/TCP; the NTP daemon only works with UDP. This is because both:

the protocol definition for NTPv4 (RFC 5905) explicitly states in 7.3 that "the NTP packet is a UDP datagram".

and

because there are known 123/TCP exploits: https://www.speedguide.net/port.php?port=123

Why does the Shake software require the 123/TCP port? It violates the standard, and it doesn't seem to make much sense (why would you resend packets to correct errors on a timing signal? The resent packets will be out of date).

If 123/TCP is somehow essential, then the document:

https://manual.raspberryshake.org/firewallissues.html?highlight=tcp

should be updated. I see now (on closer reading) that:

https://manual.raspberryshake.org/ntp.html

does mention 123/TCP down near the bottom.

I haven't confirmed this, but perhaps this is why the regular ntpd works on a stock Raspian Stretch installation: it's only using 123/UDP. Likewise I was able to get GPS to work with NTP as well (despite being in the basement under a concrete bridge! Satellite technology is amazing).

So, is there a way to remove the dependance of the Shake software on the 123/TCP port?

Thanks again for your help and interest.

Cheers,

Bill

[Richard]

hi bill,

thanks for all the effort and information...

would you try something for me please?

i'd like to make a change to the ntpd command as executed by the ntpdate service and see if this makes a difference.  (i'm keying off the fact that ntp is working when executed using init.d, so the difference must be in how ntpd itself is executed differently between the two.)

please take the attached file and copy to the directory /lib/systemd/system, reboot and check again after you log in if there is any change in the the ntpdate service startup success or not.

and let me know the result.

thanks,

richard

[Bill M.]

Hello Richard:

  Thanks for the suggestion, and your interest.

  Unfortunately, removing the trusted key list addition results in no apparent change in behavior. After a while the ntpdate.service times out and enters a failed state, and the ntp servers remain in an .INIT. state (both local and external).

Cheers,
Bill