Each PAD configuration file contains a set of stanzas of the following form:
key1: attribute1 = value1 attribute2 = value2 attribute3 = value3 ... key2: ...
Each new key begins after a blank line. The key field and some attribute values may contain pattern-matching characters that are defined as follows:
|*||Matches zero or more characters.|
|?||Matches any single character.|
|[ ]||Matches any single character in the enclosed set of characters; ranges of characters can be defined using the '-' separator, for example, "[0-9a-f]".|
||||Separates values in a list of values.|
The following is an example of attribute values:
12* Matches any value beginning with "12".
12? Matches any value beginning with "12" followed by any single character.
[1-3]* Matches any value beginning with "1", "2", or "3".
12*|23* Matches any value beginning with either "12" or "23".
The configuration file is searched sequentially, and the first key value that matches the search key is used. To avoid redundant attribute definitions, it is possible to use the special default attribute to specify another stanza that supplies attribute values not explicitly defined in the matching stanza. If the attribute definition is still not found after searching any specified default stanzas, the stanza with the special default key is checked. For example:
default: attribute1 = value1 attribute2 = value2 attribute3 = value3 key1: attribute1 = value1 key2: default = key1 attribute2 = value2 key3: default = key2 attribute3 = value3
In this case, the value for key2 's attribute1 comes from key1 , since it is not defined in key2 's stanza; and key1 is key2 's default stanza. Since an arbitrary number of default links can be followed, key3 's attribute1 value also comes from key1 , as the default links are followed from key3 to key2 and key2 to key1 . Finally, the value for key2 's attribute3 comes from the default stanza, since neither key2 nor key2 's default stanza, key1 , defines a value for it.
Call packets can be received without a calling address specified. In these cases, the NULL key value can be used in the address file to match a nonexistent calling address.
The default x29d mode can run as an outgoing PAD call validation daemon and an X.29 listener daemon (a single process with dual functionality).
If started using the -n flag, the x29d runs as an outgoing PAD call. If started in the default mode using no flags, x29d runs as an incoming X.29 call server daemon.
You can start x29d as follows:
x29d [-a] [-p user] | [-n]
|-p user||Sets the initial TTY and X.3 attributes of an X.29 session, where user indicates the AIX login ID. This flag cannot be used with the -n flag and requires that x29d is already running as the X.29 listener daemon.|
|-a||Outputs the calling X.25 address of the system initiating the X.29 session to stdout. x29d runs and obtains the X.25 address, but an AIX login is not needed since this flag is not related to X.3 or TTY attributes. This flag cannot be used with the -n flag and requires that x29d is running as the X.29 listener daemon.|
|-n||Starts x29d as a outgoing call validation daemon. The -a and -p flags cannot be used with this flag.|