https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14272
--- Comment #2 from Garri <g.djavad...@gmail.com> ---
Created attachment 16032
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16032&action=edit
NTP control READVAR for Reftime variable
(In reply to Michael Mann from comment #1)
> I poked a little through the RFC. How "fixed" are those string variable
> names? RFC seems to talk about "peer.reftime" and "sys.reftime", but the
> packet only has the string "reftime". Are "peer" and "sys" effectively
> determined by other parts of the packet?
Yes, it is determined by association ID field. An association ID 0 is used for
system related commands, variables. It is well described in B.3. Commands
section of RFC 1305 (though the document markup is not ideal):
---
Read Variables (2): The command data field is empty or contains a list
of identifiers separated by commas. If the association identifier is
nonzero, the response includes the requested peer identifier and status
word, while the data field contains a list of peer variables and values
as described above. If the association identifier is zero, the data
field contains a list of system variables and values. If a peer has been
selected as the synchronization source, the response includes the peer
identifier and status word; otherwise, the response includes the system
identifier (0) and status word.
---
> Are strings case insensitive?
I checked it by requesting system 'reftime' and 'Reftime' variables from
reference NTP server using ntpq tool. I got 'A request variable unknown to the
server' for Reftime variable. The corresponding capture for both variables is
attached.
Here is what RFC says about it:
---
Commands consist of the header and optional data field shown in Figure
6. When present, the data field contains a list of identifiers or
assignments in the form
<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],...
where <<identifier>> is the ASCII name of a system or peer variable
specified in Table 2 or Table 3 and <<value>> is expressed as a decimal,
hexadecimal or string constant in the syntax of the C programming
language. Where no ambiguity exists, the <169>sys.<170> or
<169>peer.<170> prefixes shown in Table 2 or Table 4 can be suppressed.
Whitespace (ASCII nonprinting format effectors) can be added to improve
readability for simple monitoring programs that do not reformat the data
field. Internet addresses are represented as four octets in the form
[n.n.n.n], where n is in decimal notation and the brackets are optional.
Timestamps, including reference, originate, receive and transmit values,
as well as the logical clock, are represented in units of seconds and
fractions, preferably in hexadecimal notation, while delay, offset,
dispersion and distance values are represented in units of milliseconds
and fractions, preferably in decimal notation. All other values are
represented as-is, preferably in decimal notation.
---
The referenced tables could be viewed using PDF version [1].
[1] https://tools.ietf.org/pdf/rfc1305
Michael, thank you for your interest!
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
