Ask Your Question

NTPv4 Autokey protocol: pcap does not meet the standard

asked 2020-09-09 15:09:34 +0000

oup_job gravatar image

updated 2020-09-09 15:15:12 +0000

In RFC 5906: Section 10 standard it is written:

In Autokey the 8-bit Field Type field is interpreted as the version number, currently 2.

REM: Look at Figure 7 above.

But in fact, the version is not specified in the "Field Type" (second byte), it is parsed by Wireshark on "Flags" field (last 6 bits of first byte). By default, the "Opcode" should be in the first byte, the "Version" should be in the second byte. In fact, the opposite is true.

Is this a bug of Wireshark or ntpd or should I believe the implementation?

Link to pcap:

REM: Look at "Extensional" fields in client's requests .

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2020-09-09 15:42:46 +0000

grahamb gravatar image

updated 2020-09-10 08:28:32 +0000

Your capture doesn't seem to comply with the RFC, that field type value (0x0201) isn't on the IANA list.

The NTP dissector doesn't currently perform any dissection of Extension fields other than that specified in RFC 5905, i.e. Type (as a uint16), Length and the Value.

Edit: My tests were performed with the development version that doesn't have support for Autokey post the merge of change 38037.

edit flag offensive delete link more


"The NTP dissector doesn't currently perform any dissection of Extension fields"

This isn't true, at least not prior to

I don't know why Autokey was removed instead of fixed. So this looks like a Wireshark bug to me, and thus a bug report should be filed to not only add AutoKey dissection back but to also fix it.

See also: Bug 16640.

cmaynard gravatar imagecmaynard ( 2020-09-09 16:23:36 +0000 )edit

"The NTP dissector doesn't currently perform any dissection of Extension fields" This isn't true, at least not prior to

Lol, I forgot to add "at the time of writing".

grahamb gravatar imagegrahamb ( 2020-09-09 16:39:21 +0000 )edit

It is currently supported as of this writing in the stable releases, albeit with bugs.

cmaynard gravatar imagecmaynard ( 2020-09-09 16:45:33 +0000 )edit

Another file in which the "Field type" matches IANA list:

The problem is the same. Why "Version" is in the first byte?

oup_job gravatar imageoup_job ( 2020-09-10 08:08:17 +0000 )edit

As noted by @cmaynard, there is a bug in the dissector in the stable versions, and the Extension Field dissection was actually removed. The version I was testing your capture with (a locally built copy of the development version) doesn't have the buggy Autokey dissection.

See Issue 16640 for discussion of the removal and Issue 16222 for discussion on the Autokey replacement.

Although 16440 notes that Autokey will be replaced with NTS, there will still be Autokey implementations out in the wild and thus Wireshark should support that. Again as noted by @cmaynard, raise an Issue to request Autokey support (or better still submit a Merge Request).

grahamb gravatar imagegrahamb ( 2020-09-10 08:25:38 +0000 )edit

Your Answer

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

Add Answer

Question Tools

1 follower


Asked: 2020-09-09 15:09:34 +0000

Seen: 212 times

Last updated: Sep 10 '20