Revision history [back]
NTPv4 Autokey protocol: pcap does not meet the standard
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: https://yadi.sk/d/hahMZm2xYJPhoQ
REM: Look at "Extensional" fields in client's requests .
NTPv4 Autokey protocol: pcap does not meet the standard
In RFC 5906: 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 .
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 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: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