Automatic Program Startup for Incoming X.25 Calls

An application written to handle an incoming call may be started on the command line and "listen" for a call (X25listen), sleeping until it arrives. Alternatively, x25daemon may execute your application at the time the new call request arrives at your system.

How Applications are Invoked by the x25daemon

An application that uses the API to interact with a remote device using a switched virtual circuit must have a device name (/dev directory entry) to use before it can do anything. The easiest way to do this is for x25daemon to provide the name when it invokes the program, as in the following example.

ANY:PASS:YES:/etc/padd -d $dev -v $index

The $dev field is replaced by the packet layer device. In this example, padd is started with the arguments: -d /dev/x25pkt -v NN where NN is the call index. The call index is unique for every incoming call and existing virtual circuit, and is used by the X.25 drivers to identify incoming calls that are later accepted by applications such as padd.

x25daemon will also replace the $netid field with the network identifier as defined in /etc/packetnets that corresponds to the physical link on which the incoming call arrived.

When a program uses the PASS disposition, it has the option of using _X25getcallinfo to obtain the information associated with the incoming call packet before accepting it. The following is an example.

     ct = X25open(netid);
     _X25getcallinfo(X25_fd(ct), call index, &cps);

A PASS disposition program may also pass the incoming call on to another process, or clear it (with X25clear), rather than accepting it. If a program chooses to pass the call on elsewhere, it must be disposed of before the internal timer runs out, since Netcom II will clear calls that appear to be hung by the application (not cleared or accepted).

Starting padd from /etc/x25daemon

padd is a special purpose daemon provided by TSG. It builds an X.25 pseudo-tty suitable for use by getty/login. Normally, padd will invoke(3I) the login scheme defined by your operating system. For a discussion of invoke(3I) and login schemes, refer to the operating system manuals.

padd logs to /usr/spool/x25/paddlog each invocation and any errors that occur. The name of the log file may be changed with the -l option.

By default, the X.25 pseudo-tty will manipulate remote PAD parameters by sending Qualified data packets. In some cases, this is undesirable. The Parity parameter (21) is not consistently interpreted and implemented in PADs, so it is often best to leave it untouched by using the override options. There may be other local reasons for using the override options. The override options override the pseudo-tty manipulations of remote parameters.

The -x option can be used to set the remote PAD parameter par to a specific value. Used in conjunction with the -o (override) option, it is used to set a pad parameter once, or to set pad parameters that are not ever manipulated by the pseudo-tty. For example, national or pad-specific PAD parameters.

The -s option is used to negotiate packet size down to a smaller value. This is rarely used, but is available if, for instance, bandwidth or economic reasons dictate that some calls should receive smaller packets. This option is also useful if an upper layer protocol requires smaller packet sizes.

The -c option is used to start a program other than the operating system login scheme. This option should be used with care as programs executed this way are running as root with all its privileges. This option bypasses the normal user ID and password authentication to run a tty-based program directly.

For a more information about padd options, see the padd man page.

Revision 6.1.0 (February 2003)