1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>ntpq - standard NTP query program</title>
</head>
<body>
<h3><tt>ntpq</tt> - standard NTP query program</h3>
<img align="left" src="pic/bustardfly.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<p>A typical NTP monitoring packet.<br clear="left">
</p>
<hr>
<h4>Synopsis</h4>
<tt>ntpq [-inp] [-c <i>command</i>] [<i>host</i>] [...]</tt>
<h4>Description</h4>
The <tt>ntpq</tt> utility program is used to query NTP servers
which implement the recommended NTP mode 6 control message format
about current state and to request changes in that state. The
program may be run either in interactive mode or controlled using
command line arguments. Requests to read and write arbitrary
variables can be assembled, with raw and pretty-printed output
options being available. <tt>ntpq</tt> can also obtain and print a
list of peers in a common format by sending multiple queries to the
server.
<p>If one or more request options is included on the command line
when <tt>ntpq</tt> is executed, each of the requests will be sent
to the NTP servers running on each of the hosts given as command
line arguments, or on localhost by default. If no request options
are given, <tt>ntpq</tt> will attempt to read commands from the
standard input and execute these on the NTP server running on the
first host given on the command line, again defaulting to localhost
when no other host is specified. <tt>ntpq</tt>will prompt for
commands if the standard input is a terminal device.</p>
<p><tt>ntpq</tt> uses NTP mode 6 packets to communicate with the
NTP server, and hence can be used to query any compatible server on
the network which permits it. Note that since NTP is a UDP protocol
this communication will be somewhat unreliable, especially over
large distances in terms of network topology. <tt>ntpq</tt> makes
one attempt to retransmit requests, and will time requests out if
the remote host is not heard from within a suitable timeout
time.</p>
<p>For examples and usage, see the <a href="debug.htm">NTP
Debugging Techniques</a> page.</p>
<p>Command line options are described following. Specifying a
command line option other than <tt>-i</tt> or <tt>-n</tt> will
cause the specified query (queries) to be sent to the indicated
host(s) immediately. Otherwise, <tt>ntpq</tt> will attempt to read
interactive format commands from the standard input.</p>
<dl>
<dt><tt>-c</tt></dt>
<dd>The following argument is interpreted as an interactive format
command and is added to the list of commands to be executed on the
specified host(s). Multiple <tt>-c</tt> options may be given.</dd>
<dt><tt>-i</tt></dt>
<dd>Force <tt>ntpq</tt> to operate in interactive mode. Prompts
will be written to the standard output and commands read from the
standard input.</dd>
<dt><tt>-n</tt></dt>
<dd>Output all host addresses in dotted-quad numeric format rather
than converting to the canonical host names.</dd>
<dt><tt>-p</tt></dt>
<dd>Print a list of the peers known to the server as well as a
summary of their state. This is equivalent to the <tt>peers</tt>
interactive command.</dd>
</dl>
<h4>Internal Commands</h4>
Interactive format commands consist of a keyword followed by zero
to four arguments. Only enough characters of the full keyword to
uniquely identify the command need be typed. The output of a
command is normally sent to the standard output, but optionally the
output of individual commands may be sent to a file by appending a
<tt><</tt>, followed by a file name, to the command line. A
number of interactive format commands are executed entirely within
the <tt>ntpq</tt> program itself and do not result in NTP mode 6
requests being sent to a server. These are described following.
<dl>
<dt><tt>? [<i>command_keyword</i>]</tt><br>
<tt>helpl [<i>command_keyword</i>]</tt></dt>
<dd>A <tt>?</tt> by itself will print a list of all the command
keywords known to this incarnation of <tt>ntpq</tt>. A <tt>?</tt>
followed by a command keyword will print function and usage
information about the command. This command is probably a better
source of information about <tt>ntpq</tt> than this manual
page.</dd>
<dt><tt>addvars <i>variable_name</i> [ = <i>value</i>]
[...]</tt><br>
<tt>rmvars <i>variable_name</i> [...]</tt><br>
<tt>clearvars</tt></dt>
<dd>The data carried by NTP mode 6 messages consists of a list of
items of the form <tt><i>variable_name</i> = <i>value</i></tt>,
where the <tt>= <i>value</i></tt> is ignored, and can be omitted,
in requests to the server to read variables. <tt>ntpq</tt>
maintains an internal list in which data to be included in control
messages can be assembled, and sent using the <tt>readlist</tt> and
<tt>writelist</tt> commands described below. The <tt>addvars</tt>
command allows variables and their optional values to be added to
the list. If more than one variable is to be added, the list should
be comma-separated and not contain white space. The <tt>rmvars</tt>
command can be used to remove individual variables from the list,
while the <tt>clearlist</tt> command removes all variables from the
list.</dd>
<dt><tt>authenticate yes | no</tt></dt>
<dd>Normally <tt>ntpq</tt> does not authenticate requests unless
they are write requests. The command <tt>authenticate yes</tt>
causes <tt>ntpq</tt> to send authentication with all requests it
makes. Authenticated requests causes some servers to handle
requests slightly differently, and can occasionally melt the CPU in
fuzzballs if you turn authentication on before doing a <tt>
peer</tt> display. [I didn't know that - Ed.]</dd>
<dt><tt>cooked</tt></dt>
<dd>Causes output from query commands to be "cooked", so that
variables which are recognized by <tt>ntpq</tt> will have their
values reformatted for human consumption. Variables which <tt>
ntpq</tt> thinks should have a decodable value but didn't are
marked with a trailing <tt>?</tt>.</dd>
<dt><tt>debug more | less | off</tt></dt>
<dd>Turns internal query program debugging on and off.</dd>
<dt><tt>delay <i>milliseconds</i></tt></dt>
<dd>Specify a time interval to be added to timestamps included in
requests which require authentication. This is used to enable
(unreliable) server reconfiguration over long delay network paths
or between machines whose clocks are unsynchronized. Actually the
server does not now require timestamps in authenticated requests,
so this command may be obsolete.</dd>
<dt><tt>host <i>hostname</i></tt></dt>
<dd>Set the host to which future queries will be sent. Hostname may
be either a host name or a numeric address.</dd>
<dt><tt>hostnames [yes | no]</tt></dt>
<dd>If <tt>yes</tt> is specified, host names are printed in
information displays. If <tt>no</tt> is specified, numeric
addresses are printed instead. The default is <tt>yes</tt>, unless
modified using the command line <tt>-n</tt> switch.</dd>
<dt><tt>keyid <i>keyid</i></tt></dt>
<dd>This command allows the specification of a key number to be
used to authenticate configuration requests. This must correspond
to a key number the server has been configured to use for this
purpose.</dd>
<dt><tt>ntpversion 1 | 2 | 3 | 4</tt></dt>
<dd>Sets the NTP version number which <tt>ntpq</tt> claims in
packets. Defaults to 3, Note that mode 6 control messages (and
modes, for that matter) didn't exist in NTP version 1. There appear
to be no servers left which demand version 1.</dd>
<dt><tt>quit</tt></dt>
<dd>Exit <tt>ntpq</tt>.</dd>
<dt><tt>passwd</tt></dt>
<dd>This command prompts you to type in a password (which will not
be echoed) which will be used to authenticate configuration
requests. The password must correspond to the key configured for
use by the NTP server for this purpose if such requests are to be
successful.</dd>
<dt><tt>raw</tt></dt>
<dd>Causes all output from query commands is printed as received
from the remote server. The only formating/interpretation done on
the data is to transform nonascii data into a printable (but barely
understandable) form.</dd>
<dt><tt>timeout <i>millseconds</i></tt></dt>
<dd>Specify a timeout period for responses to server queries. The
default is about 5000 milliseconds. Note that since <tt>ntpq</tt>
retries each query once after a timeout, the total waiting time for
a timeout will be twice the timeout value set.</dd>
</dl>
<h4>Control Message Commands</h4>
Each peer known to an NTP server has a 16 bit integer association
identifier assigned to it. NTP control messages which carry peer
variables must identify the peer the values correspond to by
including its association ID. An association ID of 0 is special,
and indicates the variables are system variables, whose names are
drawn from a separate name space.
<p>Control message commands result in one or more NTP mode 6
messages being sent to the server, and cause the data returned to
be printed in some format. Most commands currently implemented send
a single message and expect a single response. The current
exceptions are the peers command, which will send a preprogrammed
series of messages to obtain the data it needs, and the mreadlist
and mreadvar commands, which will iterate over a range of
associations.</p>
<dl>
<dt><tt>associations</tt></dt>
<dd>Obtains and prints a list of association identifiers and peer
statuses for in-spec peers of the server being queried. The list is
printed in columns. The first of these is an index numbering the
associations from 1 for internal use, the second the actual
association identifier returned by the server and the third the
status word for the peer. This is followed by a number of columns
containing data decoded from the status word See the peers command
for a decode of the <tt>condition</tt> field. Note that the data
returned by the <tt>associations"</tt> command is cached internally
in <tt>ntpq</tt>. The index is then of use when dealing with stupid
servers which use association identifiers which are hard for humans
to type, in that for any subsequent commands which require an
association identifier as an argument, the form and index may be
used as an alternative.</dd>
<dt><tt>clockvar [<i>assocID</i>] [<i>variable_name</i> [ = <i>
value</i> [...]] [...]</tt></dt>
<dt><tt>cv [<i>assocID</i>] [<i>variable_name</i> [ = <i>value</i>
[...] ][...]</tt></dt>
<dd>Requests that a list of the server's clock variables be sent.
Servers which have a radio clock or other external synchronization
will respond positively to this. If the association identifier is
omitted or zero the request is for the variables of the <tt>system
clock</tt> and will generally get a positive response from all
servers with a clock. If the server treats clocks as pseudo-peers,
and hence can possibly have more than one clock connected at once,
referencing the appropriate peer association ID will show the
variables of a particular clock. Omitting the variable list will
cause the server to return a default variable display.</dd>
<dt><tt>lassocations</tt></dt>
<dd>Obtains and prints a list of association identifiers and peer
statuses for all associations for which the server is maintaining
state. This command differs from the <tt>associations</tt> command
only for servers which retain state for out-of-spec client
associations (i.e., fuzzballs). Such associations are normally
omitted from the display when the <tt>associations</tt> command is
used, but are included in the output of <tt>
lassociations</tt>.</dd>
<dt><tt>lpassociations</tt></dt>
<dd>Print data for all associations, including out-of-spec client
associations, from the internally cached list of associations. This
command differs from <tt>passociations</tt> only when dealing with
fuzzballs.</dd>
<dt><tt>lpeers</tt></dt>
<dd>Like R peers, except a summary of all associations for which
the server is maintaining state is printed. This can produce a much
longer list of peers from fuzzball servers.</dd>
<dt><tt>mreadlist <i>assocID</i> <i>assocID</i></tt><br>
<tt>mrl <i>assocID</i> <i>assocID</i></tt></dt>
<dd>Like the <tt>readlist</tt> command, except the query is done
for each of a range of (nonzero) association IDs. This range is
determined from the association list cached by the most recent <tt>
associations</tt> command.</dd>
<dt><tt>mreadvar <i>assocID</i> <i>assocID</i> [ <i>
variable_name</i> [ = <i>value</i>[ ... ]</tt><br>
<tt>mrv <i>assocID</i> <i>assocID</i> [ <i>variable_name</i> [ =
<i>value</i>[ ... ]</tt></dt>
<dd>Like the <tt>readvar</tt> command, except the query is done for
each of a range of (nonzero) association IDs. This range is
determined from the association list cached by the most recent <tt>
associations</tt> command.</dd>
<dt><tt>opeers</tt></dt>
<dd>An old form of the <tt>peers</tt> command with the reference ID
replaced by the local interface address.</dd>
<dt><tt>passociations</tt></dt>
<dd>Displays association data concerning in-spec peers from the
internally cached list of associations. This command performs
identically to the <tt>associations</tt> except that it displays
the internally stored data rather than making a new query.</dd>
<dt><tt>peers</tt></dt>
<dd>Obtains a current list peers of the server, along with a
summary of each peer's state. Summary information includes the
address of the remote peer, the reference ID (0.0.0.0 if this is
unknown), the stratum of the remote peer, the type of the peer
(local, unicast, multicast or broadcast), when the last packet was
received, the polling interval, in seconds, the reachability
register, in octal, and the current estimated delay, offset and
dispersion of the peer, all in milliseconds.</dd>
<dd>The character in the left margin indicates the fate of this
peer in the clock selection process. Following is a list of these
characters, the pigeon used in the <tt>rv</tt> command, and a short
explanation of the condition revealed.</dd>
<dd>
<dl>
<dt><tt>space reject</tt></dt>
<dd>The peer is discarded as unreachable, synchronized to this
server (synch loop) or outrageous synchronization distance.</dd>
<dt><tt>x falsetick</tt></dt>
<dd>The peer is discarded by the intersection algorithm as a
falseticker.</dd>
<dt><tt>. excess</tt></dt>
<dd>The peer is discarded as not among the first ten peers sorted
by synchronization distance and so is probably a poor candidate for
further consideration.</dd>
<dt><tt>- outlyer</tt></dt>
<dd>The peer is discarded by the clustering algorithm as an
outlyer.</dd>
<dt><tt>+ candidat</tt></dt>
<dd>The peer is a survivor and a candidate for the combining
algorithm.</dd>
<dt><tt># selected</tt></dt>
<dd>The peer is a survivor, but not among the first six peers
sorted by synchronization distance. If the assocation is ephemeral,
it may be demobilized to conserve resources.</dd>
<dt><tt>* sys.peer</tt></dt>
<dd>The peer has been declared the system peer and lends its
variables to the system variables.</dd>
<dt><tt>o pps.peer</tt></dt>
<dd>The peer has been declared the system peer and lends its
variables to thesystem variables. However, the actual system
synchronization is derived from a pulse-per-second (PPS) signal,
either indirectly via the PPS reference clock driver or directly
via kernel interface.</dd>
</dl>
</dd>
<dd>The <tt>flash</tt> variable is a valuable debugging aid. It
displays the results of the original sanity checks defined in the
NTP specification RFC-1305 and additional ones added in NTP Version
4. There are eleven tests called <tt>TEST1</tt> through <tt>
TEST11</tt>. The tests are performed in a certain order designed to
gain maximum diagnostic information while protecting against
accidental or malicious errors. The <tt>flash</tt> variable is
first initialized to zero. If after each set of tests one or more
bits are set, the packet is discarded.
<p>Tests <tt>TEST4</tt> and <tt>TEST5</tt> check the access
permissions and cryptographic message digest. If any bits are set
after that, the packet is discarded. Tests <tt>TEST10</tt> and <tt>
TEST11</tt> check the authentication state using Autokey public-key
cryptography, as described in the <a href="authopt.htm">
Authentication Options</a> page. If any bits are set and the
association has previously been marked reachable, the packet is
discarded; otherwise, the originate and receive timestamps are
saved, as required by the NTP protocol, and processing
continues.</p>
<p>Tests <tt>TEST1</tt> through <tt>TEST3</tt> check the packet
timestamps from which the offset and delay are calculated. If any
bits are set, the packet is discarded; otherwise, the packet header
variables are saved. Tests <tt>TEST6</tt> through <tt>TEST8</tt>
check the health of the server. If any bits are set, the packet is
discarded; otherwise, the offset and delay relative to the server
are calculated and saved. Test <tt>TEST9</tt> checks the health of
the association itself. If any bits are set, the packet is
discarded; otherwise, the saved variables are passed to the clock
filter and mitigation algorithms.</p>
<p>The <tt>flash</tt> bits for each test read in increasing order
from the least significant bit are defined as follows.</p>
</dd>
<dd>
<dl>
<dt><tt>TEST1</tt></dt>
<dd>Duplicate packet. The packet is at best a casual retransmission
and at worst a malicious replay.</dd>
<dt><tt>TEST2</tt></dt>
<dd>Bogus packet. The packet is not a reply to a message previously
sent. This can happen when the NTP daemon is restarted and before
somebody else notices.</dd>
<dt><tt>TEST3</tt></dt>
<dd>Unsynchronized. One or more timestamp fields are invalid. This
normally happens when the first packet from a peer is
received.</dd>
<dt><tt>TEST4</tt></dt>
<dd>Access is denied. See the <a href="accopt.htm">Access Control
Options</a> page.</dd>
<dt><tt>TEST5</tt></dt>
<dd>Cryptographic authentication fails. See the <a href=
"authopt.htm">Authentication Options</a> page.</dd>
<dt><tt>TEST6</tt></dt>
<dd>The server is unsynchronized. Wind up its clock first.</dd>
<dt><tt>TEST7</tt></dt>
<dd>The server stratum is at the maximum than 15. It is probably
unsynchronized and its clock needs to be wound up.</dd>
<dt><tt>TEST8</tt></dt>
<dd>Either the root delay or dispersion is greater than one second,
which is highly unlikely unless the peer is synchronized to
Mars.</dd>
<dt><tt>TEST9</tt></dt>
<dd>Either the peer delay or dispersion is greater than one second,
which is higly unlikely unless the peer is on Mars.</dd>
<dt><tt>TEST10</tt></dt>
<dd>The autokey protocol has detected an authentication failure.
See the <a href="authopt.htm">Authentication Options</a> page.</dd>
<dt><tt>TEST11</tt></dt>
<dd>The autokey protocol has not verified the server or peer is
authentic and has valid public key credentials. See the <a href=
"authopt.htm">Authentication Options</a> page.</dd>
<dt>Additional system variables used by the NTP Version 4 Autokey
support include the following:</dt>
<dd>
<dl>
<dt><tt>certificate <i>filestamp</i></tt></dt>
<dd>Shows the NTP seconds when the certificate file was
created.</dd>
<dt><tt>hostname <i>host</i></tt></dt>
<dd>Shows the name of the host as returned by the Unix <tt>
gethostname()</tt> library function.</dd>
<dt><tt>flags <i>hex</i></tt></dt>
<dd>Shows the current flag bits, where the <tt><i>hex</i></tt> bits
are interpreted as follows:</dd>
<dd>
<dl>
<dt><tt>0x01</tt></dt>
<dd>autokey enabled</dd>
<dt><tt>0x02</tt></dt>
<dd>RSA public/private key files present</dd>
<dt><tt>0x04</tt></dt>
<dd>PKI certificate file present</dd>
<dt><tt>0x08</tt></dt>
<dd>Diffie-Hellman parameters file present</dd>
<dt><tt>0x10</tt></dt>
<dd>NIST leapseconds table file present</dd>
</dl>
</dd>
<dt><tt>leapseconds <i>filestamp</i></tt></dt>
<dd>Shows the NTP seconds when the NIST leapseconds table file was
created.</dd>
<dt><tt>params <i>filestamp</i></tt></dt>
<dd>Shows the NTP seconds when the Diffie-Hellman agreement
parameter file was created.</dd>
<dt><tt>publickey <i>filestamp</i></tt></dt>
<dd>Shows the NTP seconds when the RSA public/private key files
were created.</dd>
<dt><tt>refresh <i>timestamp</i></tt></dt>
<dd>Shows the NTP seconds when the public cryptographic values were
refreshed and signed.</dd>
<dt><tt>tai <i>offset</i></tt></dt>
<dd>Shows the TAI-UTC offset in seconds obtained from the NIST
leapseconds table.</dd>
</dl>
</dd>
<dt>Additional peer variables used by the NTP Version 4 Autokey
support include the following:</dt>
<dd>
<dl>
<dt><tt>certificate <i>filestamp</i></tt></dt>
<dd>Shows the NTP seconds when the certificate file was
created.</dd>
<dt><tt>flags <i>hex</i></tt></dt>
<dd>Shows the current flag bits, where the <i>hex</i> bits are
interpreted as in the system variable of the same name. The bits
are set in the first autokey message received from the server and
then reset as the associated data are obtained from the server and
stored.</dd>
<dt><tt>hcookie <i>hex</i></tt></dt>
<dd>Shows the host cookie used in the key agreement algorithm.</dd>
<dt><tt>initkey <i>key</i></tt></dt>
<dd>Shows the initial key used by the key list generator in the
autokey protocol.</dd>
<dt><tt>initsequence <i>index</i></tt></dt>
<dd>Shows the initial index used by the key list generator in the
autokey protocol.</dd>
<dt><tt>pcookie <i>hex</i></tt></dt>
<dd>Specifies the peer cookie used in the key agreement
algorithm.</dd>
<dt><tt>timestamp <i>time</i></tt></dt>
<dd>Shows the NTP seconds when the last autokey key list was
generated and signed.</dd>
</dl>
</dd>
</dl>
</dd>
<dt><tt>pstatus <i>assocID</i></tt></dt>
<dd>Sends a read status request to the server for the given
association. The names and values of the peer variables returned
will be printed. Note that the status word from the header is
displayed preceding the variables, both in hexidecimal and in
pidgeon English.</dd>
<dt><tt>readlist [ <i>assocID</i> ]</tt><br>
<tt>rl [ <i>assocID</i> ]</tt></dt>
<dd>Requests that the values of the variables in the internal
variable list be returned by the server. If the association ID is
omitted or is 0 the variables are assumed to be system variables.
Otherwise they are treated as peer variables. If the internal
variable list is empty a request is sent without data, which should
induce the remote server to return a default display.</dd>
<dt><tt>readvar <i>assocID</i> <i>variable_name</i> [ = <i>
value</i> ] [ ...]</tt><br>
<tt>rv <i>assocID</i> [ <i>variable_name</i> [ = <i>value</i> ] [
...]</tt></dt>
<dd>Requests that the values of the specified variables be returned
by the server by sending a read variables request. If the
association ID is omitted or is given as zero the variables are
system variables, otherwise they are peer variables and the values
returned will be those of the corresponding peer. Omitting the
variable list will send a request with no data which should induce
the server to return a default display.</dd>
<dt><tt>writevar <i>assocID</i> <i>variable_name</i> [ = <i>
value</i> [ ...]</tt></dt>
<dd>Like the readvar request, except the specified variables are
written instead of read.</dd>
<dt><tt>writelist [ <i>assocID</i> ]</tt></dt>
<dd>Like the readlist request, except the internal list variables
are written instead of read.</dd>
</dl>
<h4>Bugs</h4>
<p>The peers command is non-atomic and may occasionally result in
spurious error messages about invalid associations occurring and
terminating the command. The timeout time is a fixed constant,
which means you wait a long time for timeouts since it assumes sort
of a worst case. The program should improve the timeout estimate as
it sends queries to a particular host, but doesn't.</p>
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
<mills@udel.edu></a></address>
</body>
</html>
|
