--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Trusted Hosts and Groups</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3>Trusted Hosts and Groups</h3>
+ <img src="pic/alice23.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>Alice holds the key.</p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">00:12</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="299">Tuesday, November 08, 2005</csobj></p>
+ <br clear="left">
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li class="inline"><a href="#idexp">Identity Schemes</a>
+ <li class="inline"><a href="#exam">Example</a>
+ <li class="inline"><a href="#cmd">Command Line Options</a>
+ <li class="inline"><a href="#rand">Random Seed File</a>
+ <li class="inline"><a href="#fmt">Cryptographic Data Files</a>
+ <li class="inline"><a href="#bug">Bugs</a>
+ </ul>
+ <hr>
+ <h4 id="synop">Trusted Hosts and Groups</h4>
+ <p>Each cryptographic configuration involves selection of a signature scheme and identification scheme, called a cryptotype, as explained in the <a href="authopt.html">Authentication Options</a> page. The default cryptotype uses RSA encryption, MD5 message digest and TC identification. First, configure a NTP subnet including one or more low-stratum trusted hosts from which all other hosts derive synchronization directly or indirectly. Trusted hosts have trusted certificates; all other hosts have nontrusted certificates. These hosts will automatically and dynamically build authoritative certificate trails to one or more trusted hosts. A trusted group is the set of all hosts that have, directly or indirectly, a certificate trail ending at a trusted host. The trail is defined by static configuration file entries or dynamic means described on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
+ <p>On each trusted host as root, change to the keys directory. To insure a fresh fileset, remove all <tt>ntpkey</tt> files. Then run <tt>ntp-keygen -T</tt> to generate keys and a trusted certificate. On all other hosts do the same, but leave off the <tt>-T</tt> flag to generate keys and nontrusted certificates. When complete, start the NTP daemons beginning at the lowest stratum and working up the tree. It may take some time for Autokey to instantiate the certificate trails throughout the subnet, but setting up the environment is completely automatic.</p>
+ <p>If it is necessary to use a different sign key or different digest/signature scheme than the default, run <tt>ntp-keygen</tt> with the <tt>-S</tt><i><tt> type</tt></i> option, where <i><tt>type</tt></i> is either <tt>RSA</tt> or <tt>DSA</tt>. The most often need to do this is when a DSA-signed certificate is used. If it is necessary to use a different certificate scheme than the default, run <tt>ntp-keygen</tt> with the <tt>-c <i>scheme</i></tt> option and selected <i><tt>scheme</tt></i> as needed. If <tt>ntp-keygen</tt> is run again without these options, it generates a new certificate using the same scheme and sign key.</p>
+ <p>After setting up the environment it is advisable to update certificates from time to time, if only to extend the validity interval. Simply run <tt>ntp-keygen</tt> with the same flags as before to generate new certificates using existing keys. However, if the host or sign key is changed, <tt>ntpd</tt> should be restarted. When ntpd is restarted, it loads any new files and restarts the protocol. Other dependent hosts will continue as usual until signatures are refreshed, at which time the protocol is restarted.</p>
+ <h4 id="idexp">Identity Schemes</h4>
+ <p>As mentioned on the Autonomous Authentication page, the default TC identity scheme is vulnerable to a middleman attack. However, there are more secure identity schemes available, including PC, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/%7emills/keygen.html">Identification Schemes</a> page. These schemes are based on a TA, one or more trusted hosts and some number of nontrusted hosts. Trusted hosts prove identity using values provided by the TA, while the remaining hosts prove identity using values provided by a trusted host and certificate trails that end on that host. The name of a trusted host is also the name of its sugroup and also the subject and issuer name on its trusted certificate. The TA is not necessarily a trusted host in this sense, but often is.</p>
+ <p>In some schemes there are separate keys for servers and clients. A server can also be a client of another server, but a client can never be a server for another client. In general, trusted hosts and nontrusted hosts that operate as both server and client have parameter files that contain both server and client keys. Hosts that operate only as clients have key files that contain only client keys.</p>
+ <p>The PC scheme supports only one trusted host in the group. On trusted host <i>alice</i> run <tt>ntp-keygen -P -p <i>password</i></tt> to generate the host key file <tt>ntpkey_RSAkey_<i>alice.filestamp</i></tt> and trusted private certificate file <tt>ntpkey_RSA-MD5_cert_<i>alice.filestamp</i></tt>. Copy both files to all group hosts; they replace the files which would be generated in other schemes. On each host <i>bob</i> install a soft link from the generic name <tt>ntpkey_host_<i>bob</i></tt> to the host key file and soft link <tt>ntpkey_cert_<i>bob</i></tt> to the private certificate file. Note the generic links are on <i>bob</i>, but point to files generated by trusted host <i>alice</i>. In this scheme it is not possible to refresh either the keys or certificates without copying them to all other hosts in the group.</p>
+ <p>For the IFF scheme proceed as in the TC scheme to generate keys and certificates for all group hosts, then for every trusted host in the group, generate the IFF parameter file. On trusted host <i>alice</i> run <tt>ntp-keygen -T </tt><tt>-I -p <i>password</i></tt> to produce her parameter file <tt>ntpkey_IFFpar_<i>alice.filestamp</i></tt>, which includes both server and client keys. Copy this file to all group hosts that operate as both servers and clients and install a soft link from the generic <tt>ntpkey_iff_<i>alice</i></tt> to this file. If there are no hosts restricted to operate only as clients, there is nothing further to do. As the IFF scheme is independent of keys and certificates, these files can be refreshed as needed.</p>
+ <p>If a rogue client has the parameter file, it could masquerade as a legitimate server and present a middleman threat. To eliminate this threat, the client keys can be extracted from the parameter file and distributed to all restricted clients. After generating the parameter file, on <i>alice</i> run <tt>ntp-keygen</tt> <tt>-e</tt> and pipe the output to a file or mail program. Copy or mail this file to all restricted clients. On these clients install a soft link from the generic <tt>ntpkey_iff_<i>alice</i></tt> to this file. To further protect the integrity of the keys, each file can be encrypted with a secret password.</p>
+ <p>For the GQ scheme proceed as in the TC scheme to generate keys and certificates for all group hosts, then for every trusted host in the group, generate the IFF parameter file. On trusted host <i>alice</i> run <tt>ntp-keygen -T </tt><tt>-G -p <i>password</i></tt> to produce her parameter file <tt>ntpkey_GQpar_<i>alice.filestamp</i></tt>, which includes both server and client keys. Copy this file to all group hosts and install a soft link from the generic <tt>ntpkey_gq_<i>alice</i></tt> to this file. In addition, on each host <i>bob</i> install a soft link from generic <tt>ntpkey_gq_<i>bob</i></tt> to this file. As the GQ scheme updates the GQ parameters file and certificate at the same time, keys and certificates can be regenerated as needed.</p>
+ <p>For the MV scheme, proceed as in the TC scheme to generate keys and certificates for all group hosts. For illustration assume <i>trish</i> is the TA, <i>alice</i> one of several trusted hosts and <i>bob</i> one of her clients. On TA <i>trish</i> run <tt>ntp-keygen </tt><tt>-V <i>n</i> -p <i>password</i></tt>, where <i>n</i> is the number of revokable keys (typically 5) to produce the parameter file <tt>ntpkeys_MVpar_<i>trish.filestamp </i></tt>and client key files <tt>ntpkeys_MVkey<i>d</i>_<i>trish.filestamp</i></tt> where <i><tt>d</tt></i> is the key number (0 < <i><tt>d</tt></i> < <i>n</i>). Copy the parameter file to <i>alice</i> and install a soft link from the generic <tt>ntpkey_mv_<i>alice</i></tt> to this file. Copy one of the client key files to <i>alice</i> for later distribution to her clients. It doesn't matter which client key file goes to <i>alice</i>, since they all work the same way. <i>Alice</i> copies the client key file to all of her cliens. On client <i>bob</i> install a soft link from generic <tt>ntpkey_mvkey_<i>bob </i></tt>to the client key file. As the MV scheme is independent of keys and certificates, these files can be refreshed as needed.</p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Configuration File Definition (Advanced)</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3>Configuration File Definition (Advanced)</h3>
+ <img src="pic/bustardfly.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <p>A typical NTP monitoring packet</p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:46</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="223">Friday, June 16, 2006</csobj></p>
+ <br clear="left">
+ <hr>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li class="inline"><a href="#synopsis">Synopsis</a><br>
+ <li class="inline"><a href="#files">Files</a>
+ <li class="inline"><a href="#high-level">High-Level Description</a>
+ <li class="inline"><a href="#detailed">Detailed Description</a>
+ <li class="inline"><a href="#guidelines">Guidelines for Adding Configuration Commands </a>
+ </ul>
+ <h4 id="synopsis">Synopsis</h4>
+ <p>The NTP configuration process is driven by a phrase-structure grammar which is used to specify the format of the configuration commands and the actions needed to build an abstract syntax tree (AST). The grammar is fed to a parser generator (Bison) which produces a parser for the configuration file.</p>
+ <p>The generated parser is used to parse an NTP configuration file and check it for syntax and semantic errors. The result of the parse is an AST, which contains a representation of the various commands and options. This AST is then traversed to set up the NTP daemon to the correct configuration.</p>
+ <p>This document is intended for developers who wish to modify the configuration code and/or add configuration commands and options. It contains a description of the files used in the configuration process as well as guidelines on how to construct them.</p>
+ <h4 id="files">Files</h4>
+ <p>A brief description of the files used by the configuration code is given below:</p>
+ <table border="1">
+ <tbody>
+ <tr>
+ <th width="179">File</th>
+ <th width="537">Description</th>
+ </tr>
+ <tr>
+ <td valign="top"><b>ntp_config.y</b></td>
+ <td>This file is a Bison source file that contains the phrase-structure grammar and the actions that need to be performed to generate an AST.</td>
+ </tr>
+ <tr>
+ <td valign="top"><b>ntp_config.c</b></td>
+ <td>This file contains the major chunk of the configuration code. It contains all the functions that are called for building the AST as well as the functions that are needed for traversing the AST.</td>
+ </tr>
+ <tr>
+ <td valign="top"><b>ntp_config.h</b></td>
+ <td>This file is the header file for <b>ntp_config.c</b>. It mainly contains the structure definitions needed to build the AST. </td>
+ </tr>
+ <tr>
+ <td valign="top"><b>ntp_scanner.c</b></td>
+ <td>This file contains the code for a simple lexical analyzer. This file is directly included into the <b>ntp_config.c</b> file since this code is only used by the configuration code. The most important function in this file is <tt>yylex</tt>, which is called by the generated parser to get the next token on the input line.</td>
+ </tr>
+ <tr>
+ <td valign="top"><b>ntp_data_structures.c</b></td>
+ <td>This file contains a generic implementation of a priority queue and a simple queue. This code can be used to create a queue for any structure.</td>
+ </tr>
+ <tr>
+ <td valign="top"><b>ntp_data_structures.h</b></td>
+ <td>This header file contains the structure declarations and function prototypes needed to use the data structures defined in <b>ntp_data_structures.c</b>. This file forms the public interface of the data structures.</td>
+ </tr>
+ <tr>
+ <td valign="top"><b>ntp_config.tab.c</b></td>
+ <td>This file is generated by Bison from the <b>ntp_config.y</b> file. This file is also included directly into the configuration code.</td>
+ </tr>
+ </tbody>
+ </table>
+ <h4 id="high-level">High-Level Description</h4>
+ <p>A high-level description of the configuration process showing where all the files fit in is given below:</p>
+ <p><img src="pic/description.jpg" alt="JPEG" border="0"></p>
+ <p>The scanner reads in an NTP configuration file and converts it into tokens. The Bison generated parser reads these tokens and converts them into an AST. The AST traverser consists of a set of functions that configure parts of NTP on the basis of what is on the tree. A more detailed description of these parts and the files used is given below:</p>
+ <h4 id="detailed">Detailed Description</h4>
+ <dl>
+ <dt><b>ntp_scanner.c</b>
+ <dd>This file contains the scanner. The scanner is a small program that converts an input NTP configuration file into a set of <b>tokens</b> that correspond to <b>lexemes</b> in the input. Lexemes are strings in the input, delimited by whitespace and/or special characters. Tokens are basically unique integers that represent these lexemes. A different token is generated for each reserved word and special character in the input. There are two main functions in the public interface of this file:
+ <dt><tt>int yylex</tt>()
+ <dd>This function is called <tt>yylex</tt> for historical reasons; <tt>lex</tt> is a program that takes a set of regular expressions and generates a scanner that returns tokens corresponding to those regular expressions. The name of the generated function is called <tt>yylex</tt>. We aren't using<b> </b><tt>lex</tt><b> </b>because it requires linking against an external library and we didn't want to increase the compile-time requirements of NTP.
+ <dd>History lessons aside, this function basically checks to see if the next input character is a special character as defined in the array <tt>char special_char[]</tt>. (The function <tt>int is_special(char ch)</tt>, can be used for this.) If yes, the special character is returned as the token. If not, a set of characters is read until the next whitespace or special character is encountered. This set of characters forms the lexeme; <tt>yylex</tt> then checks whether this lexeme is an integer, a double, an IP address or a reserved word. If yes, the corresponding token is returned. If not, a token for a string is returned as the default token.
+ <dt><tt>struct state *create_keyword_scanner(struct key_tok *<i>keyword_list</i>)</tt>
+ <dd>This function takes a list of (<i>keyword, token</i>) pairs and converts them into a trie that can recognize the keywords (reserved words). Every time the scanner reads a lexeme, it compares it against the list of reserved words. If it finds a match, it returns the corresponding token for that keyword.
+ <dt><b>ntp_data_structures.c</b>
+ <dd>This file contains an implementation of a generic priority queue and FIFO queue. By generic, we mean that these queues can hold element of any type (integers, user-defined structs, etc.), provided that these elements are allocated on the heap using the function <tt>void</tt> *<tt>get_node(size_t size)</tt>. Note that the prototype for this function is exactly the same as that of <tt>malloc</tt> and that it can be used in the exact same way. Behind the scenes, <tt>get_node</tt> calls <tt>malloc</tt> to allocate <i>size</i> plus some extra memory needed for bookkeeping. The allocated memory can be freed using the function <tt>void free_node (void *<i>my_node</i>)</tt>. In addition to these two functions, the public interface of this file contains the following functions:
+ <dt><tt>queue *create_priority_queue(int (*get_order)(void *, void*))</tt>
+ <dd>This function creates a priority queue in which the order of the elements is determined by the <tt>get_order</tt><b> </b>function that is passed as input to the priority queue. The <tt>get_order</tt><b> </b>function should return positive if the priority of the first element is less than the priority of the second element.
+ <dt><tt>queue *create_queue(void)</tt>
+ <dd>This function creates a FIFO queue. It basically calls the <tt>create_priority_queue</tt> function with the <tt>get_fifo_order</tt><b> </b>function as its argument.
+ <dt><tt>void destroy_queue(queue *<i>my_queue</i>)</tt>
+ <dd>This function deletes <tt><i>my_queue</i></tt><b> </b>and frees up all the memory allocated to it an its elements.
+ <dt><tt>int empty(queue *</tt><i><tt>my_queue</tt></i><tt>)</tt>
+ <dd>This function checks to see if <i><tt>my_queue</tt></i> is empty. Returns <tt>true</tt> if <tt><i>my_queue</i></tt> does not have any elements, else it returns false.
+ <dt><tt>queue *enqueue(queue *<i>my_queue</i>, void *<i>my_node</i>)</tt>
+ <dd>This function adds an element, <i><tt>my_node</tt></i>, to a queue, <i><tt>my_queue</tt></i>. <i><tt>my_node</tt></i> must be allocated on the heap using the <tt>get_node</tt> function instead of <tt>malloc</tt>.
+ <dt><tt>void *dequeue(queue *<i>my_queue</i>)</tt>
+ <dd>This function returns the element at the front of the queue. This element will be element with the highest priority.
+ <dt><tt>int get_no_of_elements(queue *<i>my_queue</i>)</tt>
+ <dd>This function returns the number of elements in <tt><i>my_queue</i></tt>.
+ <dt><tt>void append_queue(queue *<i>q</i>1, queue *<i>q</i>2)</tt>
+ <dd>This function adds all the elements of <tt><i>q</i>2</tt> to <tt><i>q</i>1</tt>. The queue <tt><i>q</i>2</tt> is destroyed in the process.
+ <dt><b>ntp_config.y</b>
+ <dd>This file is structured as a standard Bison file and consists of three main parts, separated by <tt>%%</tt>:
+ </dl>
+ <ol>
+ <li>The prologue and bison declarations: This section contains a list of the terminal symbols, the non-terminal symbols and the types of these symbols.<li>The rules section: This section contains a description of the actual phrase-structure rules that are used to parse the configuration commands. Each rule consists of a left-hand side (LHS), a right-hand side (RHS) and an optional action. As is standard with phrase-structure grammars, the LHS consists of a single non-terminal symbol. The RHS can contain both terminal and non-terminal symbols, while the optional action can consist of any arbitrary C code.
+ <li>The epilogue: This section is left empty on purpose. It is traditionally used to code the support functions needed to build the ASTs Since, we have moved all the support functions to <b>ntp_config.c</b>, this section is left empty.
+ </ol>
+ <h4>Prologue and Bison Declarations</h4>
+ <p>All the terminal symbols (also known as tokens) have to be declared in the prologue section. Note that terminals and non-terminals may have values associated with them and these values have types. (More on this later). An unnamed union has to be declared with all the possible types at the start of the prologue section. For example, we declare the following union at the start of the <b>ntp_config.y</b> file:</p>
+ <p class="style1"><tt>%union {<br>
+ char *String;<br>
+ double Double;<br>
+ int Integer;<br>
+ void *VoidPtr;<br>
+ queue *Queue;<br>
+ struct attr_val *Attr_val;<br>
+ struct address_node *Address_node;<br>
+ struct setvar_node *Set_var;<br>
+ /* Simulation types */<br>
+ server_info *Sim_server;<br>
+ script_info *Sim_script;<br>
+ }</tt></p>
+ <p>Some tokens may not have any types. For example, tokens that correspond to reserved words do not usually have types as they simply indicate that a reserved word has been read in the input file. Such tokens have to be declared as follows:</p>
+ <p><tt>%token T_Discard<br>
+ %token T_Dispersion</tt></p>
+ <p>Other tokens do have types. For example, a <tt>T_Double</tt> token is returned by the scanner whenever it sees a floating-point double in the configuration file. The value associated with the token is the actual number that was read in the configuration file and its type (after conversion) is double. Hence, the token <tt>T_Double</tt> will have to be declared as follows in the prologue of <b>ntp_config.y</b> file:</p>
+ <p><tt>%token <Double> T_Double </tt></p>
+ <p>Note that the declaration given in the angled brackets is not <tt>double</tt> but <tt>Double</tt>, which is the name of the variable given in the <tt>%union {}</tt> declaration above.</p>
+ <p>Finally, non-terminal symbols may also have values associated with them, which have types. This is because Bison allows non-terminal symbols to have actions associated with them. Actions may be thought of as small functions which get executed whenever the RHS of a non-terminal is detected. The return values of these functions are the values associated with the non-terminals. The types of the non-terminals are specified with a <tt>%type</tt> declaration as shown below:</p>
+ <p><tt>%type <Queue> address_list<br>
+ %type <Integer> boolean</tt></p>
+ <p>The <tt>%type</tt> declaration may be omitted for non-terminals that do not return any value and do not have type information associated with them.</p>
+ <h4>The Rules Section </h4>
+ <p>The rule section only consists of phrase-structure grammar rules. Each rule typically has the following format:</p>
+ <p><tt>LHS : RHS [{ Actions }]<br>
+ ;</tt></p>
+ <p>where LHS consists of a single non-terminal symbol and the RHS consists of one or more terminal and non-terminal symbols. The <tt>Actions</tt> are optional and may consist of any number of arbitrary C statements. Note that Bison can only process LALR(1) grammars, which imposes additional restrictions on the kind of rules that can be specified. Examples of rules are shown below:</p>
+ <p><tt>orphan_mode_command<br>
+ : T_Tos tos_option_list<br>
+ { append_queue(my_config.orphan_cmds, $2); }<br>
+ ;</tt></p>
+ <p><tt>tos_option_list<br>
+ : tos_option_list tos_option { $$ = enqueue($1, $2); }<br>
+ | tos_option { $$ = enqueue_in_new_queue($1); }<br>
+ ;</tt></p>
+ <p>The <tt>$n</tt> notation, where <tt>n</tt> is an integer, is used to refer to the value of a terminal or non-terminal symbol. All terminals and non-terminal symbols within a particular rule are numbered (starting from 1) according to the order in which they appear within the RHS of a rule. <tt>$$</tt> is used to refer to the value of the LHS terminal symbol - it is used to return a value for the non-terminal symbol specified in the LHS of the rule.</p>
+ <h4>Invoking Bison </h4>
+ <p>Bison needs to be invoked in order to convert the <b>ntp_config.y</b> file into a C source file. To invoke Bison, simply enter the command:</p>
+ <p><tt>bison ntp_config.y</tt></p>
+ <p>at the command prompt. If no errors are detected, an <b>ntp_config.tab.c</b> file will be generated by default. This generated file can be directly included into the <b>ntp_config.c</b> file.</p>
+ <p>If Bison report shift-reduce errors or reduce-reduce errors, it means that the grammar specified using the rules in not LALR(1). To debug such a grammar, invoke Bison with a <tt>-v</tt> switch, as shown below. This will generate a <b>ntp_config.output</b> file, which will contain a description of the generated state machine, together with a list of states that have shift-reduce/reduce-reduce conflicts. You can then change the rules to remove such conflicts.</p>
+ <p><tt>bison -v ntp_config.y</tt></p>
+ <p>For more information, refer to the <a href="http://www.gnu.org/software/bison/manual/html_mono/bison.html">Bison manual</a>.</p>
+ <p><b>ntp_config.c</b></p>
+ <p>This file contains the major chunk of the configuration code including all the support functions needed for building and traversing the ASTs. As such, most of the functions in this file can be divided into two groups:</p>
+ <ol>
+ <li>Functions that have a <tt>create_</tt> prefix. These functions are used to build a node of the AST.
+ <li>Functions that have a <tt>config_</tt> prefix. These functions are used to traverse the AST and configure NTP according to the nodes present on the tree.
+ </ol>
+ <h4>Guidelines for Adding Configuration Commands</h4>
+ <p>The following steps may be used to add a new configuration command to the NTP reference implementation:</p>
+ <ol>
+ <li>Write phrase-structure grammar rules for the syntax of the new command. Add these rules to the rules section of the <b>ntp_config.y</b> file.
+ <li>Write the action to be performed on recognizing the rules. These actions will be used to build the AST.
+ <li>If new reserved words are needed, add these to the <tt>struct key_tok keyword_list[]</tt>structure in the <b>ntp_config.c </b>file. This will allow the scanner to recognize these reserved words and generate the desired tokens on recognizing them.
+ <li>Specify the types of all the terminals and non-terminal symbols in the prologue section of the <b>ntp_config.c</b> file.
+ <li>Write a function with a <tt>config_</tt> prefix that will be executed for this new command. Make sure this function is called in the <tt>config_ntpd()</tt>function.
+ </ol>
+ <hr>
+ <address><a href="mailto:skamboj@udel.edu">Sachin Kamboj</a></address>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>ntpdsim - Network Time Protocol (NTP) simulator</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</h3>
+ <img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>The mushroom knows all the command line options.</p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:32</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="223">Friday, June 16, 2006</csobj></p>
+ <br clear="left">
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li><a href="#description">Description</a><br>
+ <li><a href="#configuration">Configuration</a>
+ <li><a href="#sample">Sample Configuration File</a>
+ </ul>
+ <h4 id="description">Description</h4>
+ <p>The ntpdsim program is used to simulate and study the behavior of an NTP daemon that derives its time from a number of different simulated time sources (servers). Each simulated server can be configured to have a different time offset, frequency offset, propagation delay, processing delay, network jitter and oscillator wander.</p>
+ <p>The ntpdsim program runs all the same selection, mitigation, and discipline algorithms as the actual ntpd daemon at the client. (It actually uses the same code). However, the input/output routines and servers are simulated. That is, instead of sending the client messages over the network to the actual servers, the client messages are intercepted by the ntpdsim program, which then generates the replies to those messages. The reply messages are carefully "inserted" into the input queue of the client at the right time according to the specified server properties (like propagation delay).</p>
+ <p>Each simulated server runs according to a specified script that describes the server properties at a particular time. Each script consists of a series of consecutive acts. Each act runs for a particular duration and specifies the frequency offset, propagation delay, processing delay, network jitter and oscillator wander of the server for that duration. Once the duration of an act expires, the simulated server reconfigures itself according to the properties specified in the next act.</p>
+ <h4 id="configuration">Configuration</h4>
+ <p>The ntpdsim program is configured by providing a configuration file at startup. The crux of the simulator configuration is specified using a <tt>simulate</tt> command, the syntax of which is given below. Note that all time quantities are in seconds and all frequency quantities are in parts per million (PPM):</p>
+ <p><<i>simulate_command</i>> ::= <tt>simulate</tt> { <<i>init_statement_list</i>> <<i>server_list</i>> }<br>
+ <<i>init_statement_list</i>> ::= <init_statement_list> <init_statement> | <init_statement><br>
+ <<i>init_statement</i>> ::= <tt>beep_delay</tt> = <number> | <tt>simulation_duration</tt> = <number><br>
+ <<i>server_list</i>> ::= <<i>server_list</i>> <server> | <server><br>
+ <<i>server_list</i>> ::= <tt>server</tt> = <address> { <tt>server_offset</tt> = <number> <act_list> }<br>
+ <<i>act_list</i>> ::= <<i>act_list</i>> <<i>act</i>> | <<i>act</i>><br>
+ <<i>act</i>> ::= <tt>duration</tt> = <number> { <<i>act_stmt_list</i>> }<br>
+ <<i>act_stmt_list</i>> ::= <<i>act_stmt_list</i>> <<i>act_stmt</i>> | <<i>act_stmt</i>><br>
+ <<i>act_stmt</i>> ::= <tt>freq_offset</tt> = <number> | <tt>wander</tt> = <number> | <tt>jitter</tt> = <number> | <tt>prop_delay</tt> = <number> | <tt>proc_delay</tt> = <number></p>
+ <p>In addition to the simulate command, other standard NTP configuration commands can be specified. These commands have the same meaning as in the ntpd configuration. Note that newlines are <b>not</b> significant within the simulate command even though they are used to mark the end of a normal NTP configuration command.</p>
+ <h4 id="sample">Sample Configuration File</h4>
+ <p>A sample ntpdsim configuration file is given below. It specifies two simulated servers, each of which has two acts.</p>
+ <pre>
+ # Client configuration
+ disable kernel
+ server pogo
+ driftfile ./ntp.drift
+ statsdir ./ntpstats/
+ filegen loopstats type day enable
+ filegen peerstats type day enable
+
+ # Simulation configuration
+ simulate {
+ simulation_duration = 86400
+ beep_delay = 3600
+
+ # Server 1
+ server = louie.udel.edu {
+ server_offset = 0
+ duration = 50000 {
+ freq_offset = 400
+ wander = 1.0
+ jitter = 0.001
+ prop_delay = 0.001
+ proc_delay = 0.001
+ }
+ duration = 6400 {
+ freq_offset = 200
+ wander = 1.0
+ jitter = 0.001
+ prop_delay = 0.001
+ proc_delay = 0.001
+ }
+ }
+
+ # Server 2
+ server = baldwin.udel.edu {
+ server_offset = 0.02
+ duration = 10000 {
+ freq_offset = 400
+ wander = 1.0
+ jitter = 0.001
+ prop_delay = 0.5
+ proc_delay = 0.001
+ }
+ duration = 60000 {
+ freq_offset = 200
+ wander = 1.0
+ jitter = 0.05
+ prop_delay = 0.005
+ proc_delay = 0.001
+ }
+ }
+ }
+ </pre>
+ <hr>
+ <address><a href="mailto:skamboj@udel.edu">Sachin Kamboj</a></address>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
projects / thirdparty / ntp.git / commitdiff
