First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

Massive NTP v4 requests from IoT devices

Hi folks,

I'm not very familiar with NTP, and the RFC didn't answered my questions so far. Hope that someone can help me.

We're having some Siemens IoT devices in our network for different purposes. All of them are sending a lot of NTP requests to our NTP appliance. The ammount of requests is equal for all devices (about 8.000 per hour).

The reference timestamp in the client packets is always 00:00:00, 01 Jan. 1970. Therefore I guess that the devices don't understand the NTP reply from our NTP appliance.

Could you give me a hint what's going on here?

NTP_Requests.pcapng

Thank you. Jas Man

JasMan's avatar
81
JasMan
asked 2022-03-05 13:59:18 +0000
edit flag offensive 0 remove flag close merge delete

Comments

1

Do you have a test IoT device that you could point to a public ntp server (pool.ntp.org) for testing?
Maybe the IoT is picky about the refid that Wireshark flags as being Unidentified?

(for future reference - public NTP with refid PZF: https://support.ntp.org/bin/view/Serv...)

Chuckc's avatar Chuckc (2022-03-05 20:59:20 +0000) edit
more
  • delete

I've configured the public ntp server, but the behaviour was the same.

According to our ntp appliance vendor Meinberg the non-RFC-compatible value in the refid field should be not a problem for clients. Not sure if this is true or not. But the clients time is always up-to-date, so.....

For me it seems that the ntp client of that devices are just shitty.

JasMan's avatar JasMan (2022-03-20 11:41:04 +0000) edit
more
  • delete

Thanks for the follow up. A solution would be nice but at least now know what's been tested. Thanks.

Chuckc's avatar Chuckc (2022-03-20 13:05:07 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

1

From the capture you provided, none of the "Origin Timestamp" values from the server match any of the client's "Transmit Timestamp" values. The NTP server should copy the value of the NTP client's ntp.xmt field (the "Transmit Timestamp") verbatim into the NTP server's ntp.org field (the "Origin Timestamp").

As to the quality of the IoT's NTP client:

All of the NTP client requests are sourced from the same ephemeral UDP port value of 50023. Generally NTP clients will use different ephemeral port numbers for subsequent request. But because of the "Origin Timestamp" issue, the NTP client can not match the NTP server reply with the the request. It's likely the same NTP client process keeps sending the request resulting in the the same ephemeral port. The IoT NTP client does appear to control the rate of its retries by sending a maximum of four requests before waiting about 10 seconds to try again.

Jim Young's avatar
196
Jim Young
answered 2022-03-20 13:28:30 +0000
edit flag offensive 0 remove flag delete link
more

Comments

Good points, Jim!

I've captured the NTP communication from other clients to the same NTP server, and the "Origin Timestamp" and the "Transmit Timestamp" values are the same for them.

Can anybody explain why the transmit timestamp value for the IoT device differ from the origin timestamp?

JasMan's avatar JasMan (2022-03-26 16:20:25 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer