Requests a network connection.
This primitive consists of one M_PROTO message block with the following structure:
typedef struct {
ulong PRIM_type;
ulong DEST_length;
ulong DEST_offset;
ulong CONN_flags;
ulong QOS_length
ulong QOS_offset;
} N_conn_req_t;
Note: QOS_length and QOS_offset are not supported and should be set to 0 (zero).
The N_CONN_REQ primitive requests that the network service (NS) provider make a network connection to a specified destination. This will generate an X.25 call request to the remote X.25 host.
The format of the message is one M_PROTO message block followed by one or more M_DATA blocks for the NS user data transfer. Specifying user data is optional. The NS user can send any integral number of octets of data within the range supported by the NS provider. (For more information, see the N_INFO_ACK primitive.)
The following table defines the specific address format to be used for SVCs. The address must be a null-terminated string, and the null character is not counted as part of the length field of M_PROTO message.
| N_CONN_REQ NPI SVC Address Format | |||
| Byte # (from 1) | Represents | Value | Format |
| 1 | line number | 0-255 | Binary |
| 2 | address prefix | 0 for X.121 | ASCII |
| 3 - on | address itself | X.121 address | ASCII |
Note: User data is expected to be an even-length, null-terminated ASCII string. Facilities should be included in the M_DATA, and are expected to be coded as they would appear in a call packet. The sample code gives an example of facilities and CUD.
For PVCs, the N_CONN primitives are not used. The connection is established through the N_BIND_REQ.
The line number can be obtained several ways. The lsx25 command lists the logical port number for each port, which is the line number. Another way is to use the lsattr command as follows:
lsattr -E -l portname -a port_num
The value to use for the line number is the port_num field. A third option is to use the odm_get_obj subroutine. An example of this code can be found in the sample code directory for NPI.
The following acknowledgments are valid for the N_CONN_REQ primitive:
| Successful | The N_CONN_CON primitive indicates the NC has been established. |
| Unsuccessful | The N_DISCON_IND primitive indicates the NC was not established. A connection may be rejected because either the called NS user cannot be reached, or the NS provider and the called NS user did not agree with the specified facilities. |
The applicable non-fatal errors are defined as follows:
| NBADADDR | Indicates the network address was in an incorrect length or of zero length. This error code is not intended to indicate NC errors, such as an unreachable destination. These errors types are indicated with the N_DISCON_IND primitive. |
| NBADDATA | Indicates the amount of user data specified was outside the range supported by the NS provider. |
| NBADOPT | Indicates the options were either in an incorrect format or contained illegal information. |
| NOUTSTATE | Indicates the primitive was issued from an invalid state. |
| NSYSERR | Indicates a system error. The error is indicated in the N_ERROR_ACK primitive. |
| NODDCUD | Indicates an odd-length call user data string. |
The N_CONN_REQ primitive is part of X.25 Licensed Program.