contrib/ntp/html/ntpq.htm

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