X.25 Virtual Circuits as Serial Ports

Incoming Calls as login Ports

Remote terminal users can use an X.3/X.28/X.29 PAD to make an X.25 call to a UNIX system. When the incoming call arrives, the driver accepts the call, engages in a control packet conversation with the remote PAD, and passes the call on to getty for further processing.

Often the system administrator wants to allow incoming calls to be connected to a login port. For example, when the user community is connecting to the host from remote async terminals that call, or are connected to, a Packet Assembler Disassembler (PAD). In this case, the administrator should configure incoming calls to be directed towards the incoming pad daemon /etc/padd.

On System V Release 4, the Netcom II utility x25daemon spawns padd to open particular X.25 devices for login. padd in turn executes getty after accepting the call and pushing the x29 module to act as a host pad.

/etc/padd accepts the incoming call, and builds a streams pseudo-tty on top of the X.25 connection. It then opens the pseudo-ttys as stdin/stdout/stderr and invokes (invoke(3I)) the login scheme. /etc/padd can also execute an administrator-defined application on the pseudo-tty instead of the default "login" scheme.

/etc/padd has options to negotiate the X.25 packet size, and control the X.3 parameters in the remote PAD. The underlying pseudo-tty will also control the X.3 parameters in the remote PAD. (See Interaction with a Remote PAD which describes the relationship between termio(7) settings and X.3 parameters.) The pseudo-ttys manipulation of remote X.3 parameters may be overridden by padd. That is, padd may instruct the pseudo-tty to never modify some X.3 parameters.

To start padd for incoming calls the following entry is needed in the /etc/x25incalls file.

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

Of course, ANY may be tailored by the administrator for specific call identifiers (see x25incalls File Description).

The -d $dev and -v $index options are required. Optional arguments are described in the following table.

Option

Argument

Description

-l

logfile

By default, padd writes to /usr/spool/x25/paddlog. This can be changed with the -l option.

-s

pktsize

Negotiate X.25 packet size down to pktsize if possible.

-c

Do not invoke(3I) the login scheme.

Execute the command given instead. If found, the $tty variable in the command string is replaced with the pseudo-tty device name. In all cases, the pseudo-tty will already be open as stdin/stdout/stderr. For example:

 
/etc/padd -d $dev -v $vc -c application_name $tty

After accepting the call and building the pseudo-tty, the tty is opened as stdin/stdout/stderr and padd will exec(3) the program:

 
/usr/bin/application

The program will have one argument: the tty name as /dev/xpt/NN, where NN is a number.

-x

par:val

This option instructs padd to set the remote pad parameter par to the value val before executing the application specified or invoking the login scheme. -x options may be repeated. This option works well in conjunction with -o to set parameters once to a known state. For example:

 
/etc/padd -d $dev -v $vc -o 21 -x 21:0

will instruct the pseudo-tty to never change parameter 21 then set parameter 21 to 0.

About Pseudo-ttys

STREAMS based X.25 pseudo-ttys are implemented in the xpt driver. By default there are a maximum of 64 pseudo-ttys. The number is controlled by the parameter XPT_CNT defined in /etc/conf/pack.d/xpt/Space.c. It is also limited by the number of pseudo-tty nodes built. The nodes are defined in /etc/conf/node.d/xpt. There is one line for each node:

 
xpt xpt/NN c NN

To create more nodes, you must increase XPT_CNT and add more entries to /etc/conf/node.d/xpt, then rebuild the kernel.

Pseudo-tty nodes may NOT be used directly by applications unless they are invoked by /etc/padd for incoming calls. /etc/padd builds the pseudo-tty stack. This involves, opening the X.25 packet level, accepting the X.25 call, pushing the X.29 module on the stack, then linking /dev/xpt to the result. Finally, the kernel line disciplines ldterm must be pushed.

Therefore, there is no way to use the pseudo-tty directly, such as by uucp for outgoing connections. X.25 pseudo-ttys only exist in the context of an incoming call.

During normal processing of an incoming call, padd accepts the call and makes the /etc/utmp entries appropriate for starting a login process. It forks, and the parent waits for the switched circuit connection to terminate; the child executes the process specified, or invokes the login scheme. Each incoming call is logged to the logfile as follows:

 
"padd started on Vc NN"

NN is the call index number. This number increases by one for every incoming call, to a maximum of 65,535. It has no meaning in X.25 terms; it is merely an index to allow the internal interfaces to track incoming calls and the applications associated with them.

When the switched circuit terminates, or the login application exits, the parent process cleans up the /etc/utmp entry and ensures both the switched circuit is cleared and the application it executed is terminated. Then the parent exits.

If X.25 devices are not available for login because all devices already have users connected, the incoming call is cleared. The diagnostic code associated with this clear is "0xA3".

Adding More login Ports

All modem control devices in the system are available to be opened by the spawned getty. More devices can be created by following the instructions in


Interaction with a Remote PAD

When the virtual circuit is treated as a tty device, it is assumed that the remote device is connected to the packet network with a CCITT-compatible (X.3/X.28/X.29) Packet Assembler / Disassembler (PAD). X.29 command packets are used to determine PAD capabilities, then control the PAD parameters according to the tty-specific ioctl() calls that the application makes. An overview of X.29 and X.3 is provided in the Programmer's Guide.

As remote X.3 parameter manipulation is also an operations issue, this is also shown here. You may tell Netcom II not to manipulate an X.3 parameter with the padd -x option (par:val).

In the example below, ICANON is normally set for line-entry programs like csh, and not set for programs that do their own echoing like vi.

Parameter

Description

Control

1

Escape to Command Mode

The driver sets this parameter to 1 if ICANON is set; otherwise it is set to 0.

2

Echo

The driver sets to 1 if ECHO is set; otherwise, it sets to 0.

3

Forwarding

Set to 126 if ICANON is set (All characters less than SPACE (0x20) and DEL are forwarding characters); otherwise, set to 0.

4

Idle timer forwarding

Set to 0 if ICANON is set.

If ICANON is not set and VMIN is 1, then set to 1.

If ICANON is not set and VMIN is not 1, if VTIME is 1, then set to 1.

If ICANON is not set, VMIN is not 1, and VTIME is not 1, set this parameter to twice VTIME.

5

Ancillary Device Control

Set to 1 if IXOFF is set; otherwise, set to 0.

12

PAD flow control

Set to 1 if IXON is set; otherwise set to 0.

13

Line Feed Insertion

Set to 4 if ICRNL and ONLCR are set; otherwise, set to 0.

15

Line Editing

Set to 1 if ICANON is set; otherwise, set to 0.

16

Back Space Character

Set to ERASE character.

17

Line Kill Character

Set to KILL character.

19

Editing Service Signals

Set to 2 if ECHOE is set; otherwise, set to 8.

21

PAD parity

Set to 0 if IGNPAR is set; otherwise, if PARENB is set, then set to 1.

If neither IGNPAR, nor PARENB are set, then this parameter is controlled by PARODD.

If PARODD is set, this parameter is set to 3; otherwise set to 2.


Revision 6.1.0 (February 2003)

Copyright © 1997-2003 The Software Group Limited. All Rights Reserved.
® Netcom is a registered trademark of The Software Group Limited.