Massive NTP v4 requests from IoT devices

asked 2022-03-05 13:59:18 +0000

81 ●1 ●21 ●11

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

edit retag flag offensive close merge delete

Comments

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 ( 2022-03-05 20:59:20 +0000 )edit

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 ( 2022-03-20 11:41:04 +0000 )edit

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

Chuckc ( 2022-03-20 13:05:07 +0000 )edit

add a comment

answered 2022-03-20 13:28:30 +0000

Jim Young
196 ●18 ●4

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.

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 ( 2022-03-26 16:20:25 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Massive NTP v4 requests from IoT devices

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Massive NTP v4 requests from IoT devices edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Massive NTP v4 requests from IoT devices