Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

NTPv4 Autokey protocol: pcap does not meet the standard

In RFC 5905 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: https://yadi.sk/d/hahMZm2xYJPhoQ

NTPv4 Autokey protocol: pcap does not meet the standard

In RFC 5905 Section 10 standard it is written:

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

REM: 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: https://yadi.sk/d/hahMZm2xYJPhoQ

NTPv4 Autokey protocol: pcap does not meet the standard

In RFC 5905 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: https://yadi.sk/d/hahMZm2xYJPhoQ

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

NTPv4 Autokey protocol: pcap does not meet the standard

In RFC 5905 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: https://yadi.sk/d/hahMZm2xYJPhoQ

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

NTPv4 Autokey protocol: pcap does not meet the standard

In RFC 5905 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: https://yadi.sk/d/hahMZm2xYJPhoQ

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