 |
» |
|
|
|
|  | |
The X.25 subsystem generates many different types of X.25
unsolicited status messages. Some of the status messages provide
X.25 link specific information, that is, some of the status codes
are only generated by the X.25 link and will never be generated
by a Virtual Circuit ZLU. Other codes pertain to various VC related
protocol errors. Typically these are only delivered to the zx25d X.25 protocol driver. Finally,
a third set of status codes are returned which pertain explicitly
to the various states and protocol packets received by a Virtual
Circuit ZLU. In addition, the VC status codes may also return a
data buffer containing additional data about the event. Note that
status messages 64 through 84 and 88 through 109 are delivered by
default to the X.25 link ZLU receivers. The format of the status messages listed below is the symbolic
name (define) for the specific status code following by the numeric
value of the status code in parenthesis and then a description of
the meaning of the status code. X.25 Link Status | |
These status messages all pertain solely to X.25 link ZLUs.
None of these status messages provide an additional data buffer.
For status codes 64 through 74, bit 7 of the mrqstat field
in the ZCOM message header is used to indicate whether the HDLC/LAP-B
protocol is up. This is, if the X.25 link at level 2 has been established.
If the bit is set, than level 2 is down. Otherwise, if clear, then
the HDLC/LAP-B handshaking has been completed and level 2 is up.
Note that although the level 2 protocol is up, you may not use the
link until the X.25 packet layer (level 3) restart processing has
been completed (indicated by status code 85). These unsolicited
status messages may be received by an application program, if requested
through a call to zx25l2stat_rcvr().
Status codes 64 through 84 are also delivered to all applications
that have set themselves up as receivers on the X.25 link ZLU. - ST25ENBL (64)
X.25 Link status after ENABLE. This status is used
to indicate whether the HDLC/LAP-B (X.25 level 2) link has
been established following an enable of the X.25 link ZLU. If bit
7 of the mrqstat field is set,
the link is down indicating that the MUX card was unable to establish
the HDLC/LAP-B link (X.25 level 2) following an enable of the X.25
link ZLU. Most likely the remote end of the link is not responding
to the HDLC/LAP-B protocol packets sent by the ACC.
If
bit 7 = 0, then the link is up (at level 2). - ST25DSBL (65)
The X.25 link has been disconnected due to a disable request
on the X.25 link ZLU. - ST25XDCD (66)
X.25 Link disconnected or restarted due to loss
of DCD. Bit 7 of the mrqstat field
will indicate the current up/down state of the link. - ST25XCTS (67)
X.25 Link disconnected or restarted due to loss
of CTS. Bit 7 of the mrqstat field
will indicate the current up/down state of the link. - ST25RTRY (68)
X.25 Link disconnected or restarted due to retransmission
counter N2 being exceeded. Bit 7 of the mrqstat field
will indicate the current up/down state of the link. - ST25TXFR (69)
X.25 Link disconnected or restarted due to a transmitted
FRMR (Frame Reject). Bit 7 of the mrqstat field
will indicate the current up/down state of the link. - ST25RXFR (70)
X.25 Link disconnected or restarted due to a received FRMR
frame. Bit 7 of the mrqstat field
will indicate the current up/down state of the link. - ST25RXDM (71)
X.25 Link disconnected or restarted due to a received DM
(Disconnect Mode) frame. Bit 7 of the mrqstat field will
indicate the current up/down state of the link. - ST25RXSA (72)
X.25 Link disconnected or restarted due to a received SABM
(Set Asynchronous Balanced Mode) frame. Bit 7 of the mrqstat field will indicate the current
up/down state of the link. - ST25RXDI (73)
X.25 Link disconnected due to a received DISC (Disconnect)
frame. Bit 7 of the mrqstat field
will indicate the current up/down state of the link. For this particular
status code, bit 7 should always be set to 1 indicating the link
is down. - ST25RXUA (74)
X.25 Link disconnected or restarted due to a received UA
(Unnumbered Acknowledgment) frame. Bit 7 of the mrqstat field will indicate the current
up/down state of the link. - ST25RUFR (75)
X.25 Link disconnected or restarted due to a received unsolicited
final response frame. Bit 7 of the mrqstat field
will indicate the current up/down state of the link. - ST25ENF (77)
X.25 Link ZLU enable failed due to an invalid configuration.
Check the various configuration parameters, particularly the poll
and select words for this X.25 link ZLU. - ST25ENB (78)
X.25 Link ZLU has been enabled. - ST25TPA (79)
X.25 Link ZLU has been activated. This link can
now accept inbound I-frames. - ST25TPD (80)
X.25 Link ZLU has been deactivated. Note that a deactivated
link will not accept inbound data. The ACC MUX will automatically
respond with a level 2 RNR when the remote side of the link attempts
to send an HDLC/LAP-B I-frame to a deactivated link. - ST25DSBRQ (81)
A DISABLE request has been issued to this X.25 link
ZLU. This status normally begins the link shutdown process. When
the shutdown processing is complete, a link disabled status (82)
is received. - ST25DSB (82)
X.25 link ZLU has been disabled. The X.25 link is
now fully shutdown and will not respond to any HDLC/LAP-B protocol
packets. - ST25LNCTO (83)
An X.25 link control timeout has occurred. This indicates
that the remote end of the link has not responded to a protocol
packet within the appropriate amount of time. For example, when
a Restart Request packet is sent, the remote end must respond within timer
T20 seconds. This status message is sent when the timer expires
without having seen a response from the remote end of the link. - ST25LNNBF (84)
X.25 link buffer shortage has occurred. This indicates
that the MUX firmware was unable to find a free outbound buffer
for sending a low-level protocol packet (e.g. RR or RNR). This can
be caused by applications sending large contiguous messages and/or using
a TTGEN configuration file with a Port-Limit parameter
that is too large. Try reducing the port limit and insure that no
applications are sending large contiguous messages. If an application
is sending a large contiguous message, it is recommended that the message
be broken up and sent in 4,096 byte blocks using the M-bit where
appropriate. - ST25RSTRT (85)
X.25 link Restart processing complete. The X.25 packet
layer (level 3) is now up. Note that SVC and PVC ZLUs can not be
used until the packet layer is up.
Miscellaneous and Protocol Error Status Messages | |
The following unsolicited status messages are delivered only
to those applications (and the X.25 protocol driver) which have
set themselves up as receivers on the X.25 link ZLU. Note that status
codes 90 through 106 pertain to specific Virtual Circuits and always
have a single data byte associated with them. This data byte contains
the MUX terminal number of the associated virtual circuit. This
terminal number corresponds to the ptterm and ltterm fields in the Physical and
Logical Terminal Tables, respectively. - ST25L2STAT (88)
Level-2 statistics upload. The data buffer contains the
data structure x25l2stat_type (defined
in zcomx25.h). Note that the values in this structure are not absolute
values, but the number of occurrences of each type of condition
since the last time the statistics were uploaded. - ST25REVCD (89)
X.25 and HDLC/LAP-B firmware implementation revision
codes upload. - ST25LCENF (90)
Virtual Circuit ZLU ENABLE failed. Check the configuration
for the VC ZLU. Pay particular attention to the poll, select, and
device type fields. - ST25LCERQ (91)
VC ZLU enable requested. This indicates a zcntl() request to enable the Virtual
Circuit ZLU has been issued. - ST25LCDRQ (92)
VC ZLU disable requested. This indicates a zcntl() request to disable the Virtual
Circuit ZLU has been issued. - ST25BADPS (93)
Bad P(S) in received packet. This indicates that
a data packet received on a VC contained an invalid sequence number
in the P(S) field. This will cause the VC to be reset. - ST25BADPR (94)
Bad P(R) in received packet. This indicates that
a data packet received on a VC contained an invalid sequence number
in the P(R) field. This will cause the VC to be reset. - ST25RXREJ (95)
The VC received a REJECT packet. This will cause the
VC to be reset. - ST25LCCTO (96)
A Virtual Circuit control timeout has occurred.
This indicates that the remote end of the link has not responded
to a protocol packet within the appropriate amount of time. For
example, when a Clear Request packet is sent, the remote end must
respond within timer T23 seconds with a Clear Confirm. This status message
is sent when the timer expires without having seen a response from
the remote end of the link. Typically, this will cause the VC to
be reset or cleared depending on the particular protocol packet
that timed out. - ST25DATTO (97)
VC data acknowledgment timeout has occurred. That
is, the remote end of the link has not RR'd a sent data
packet within the required T25 time. Note that if the T25 timer
is disabled, this status message will not be generated. This will
cause the VC to be reset. - ST25RNRTO (98)
A VC RNR timeout has occurred. This indicates that the
remote end of the link sent an level 3 RNR which halted the outbound
data traffic to the associated VC. If this condition is not cleared
within 180 seconds, this status message is generated. This will
cause the VC to be reset. - ST25LCNBF (99)
A buffer shortage has occurred for the associated Virtual
Circuit. - ST25BADIC (100)
Bad Interrupt Confirm packet received on the Virtual
Circuit. This indicates that an Interrupt Confirm packet was received
without having sent an interrupt data packet. This will cause the
VC to be reset. - ST25INTTO (101)
Interrupt packet timeout has occurred. This indicates
that the remote end of the link has not confirmed our sent interrupt
packet within timer T26 seconds. This will cause the VC to be reset. - ST25PKLNG (102)
VC interrupt or data packet too long. The remote end
of the link sent a data packet which exceeded the X.25 level 3 packet
size or an interrupt packet larger than 32 bytes for 1984 X.25 or
larger than 1 byte for 1980 X.25. This will cause the VC to be reset. - ST25BADQB (103)
Inconsistent Q-bit usage detected in VC data packets.
This indicates the inbound data packets of a complete packet sequence
did not ALL contain the same Q-bit value. This will cause the VC
to be reset. - ST25NVGFI (104)
An invalid GFI was received on the Virtual Circuit. Most
likely the modulo 128 bit was set (bit 6). The ACC does not support
modulo 128 sequence numbering. This will cause the VC to be reset
or cleared as appropriate. - ST25ILLDB (105)
Illegal use of D-bit detected in packets for the
VC. This indicates a data packet was received with the D-bit set
when D-bit use has not been negotiated in the call setup (non-1980
X.25). This will cause the VC to be reset. - ST25SHMPK (106)
Invalid short data packet received on Virtual Circuit.
This indicates a data packet was received with the M-bit set whose
length was less than the X.25 level 3 packet size for this VC. This
will cause the VC to be reset. - ST25RNRFL (107)
X.25 link port break has been issued. This is used for
internal purposes. - ST25PKSHT (108)
Packet too short. This will cause the VC to be reset. - ST25ILINT (109)
Illegal interrupt packet. The remote system sent
an interrupt packet while there was an unconfirmed incoming interrupt
packet pending. This will cause the VC to be reset.
Virtual Circuit Status Messages | |
Finally, the following X.25 specific unsolicited statuses
may be received directly from a Virtual Circuit ZLU by application
programs which have set themselves up as the receiver for that VC
ZLU. Status codes 110 through 117 are always delivered to the appropriate
applications. Status codes 118 through 127 are only delivered to
an application if the CNT bit is
set in the VC ZLU's option word. - ST26INTPT (110)
The VC has received an Interrupt Packet. The data buffer
contains up to 32 bytes worth of interrupt data. - ST26ICONF (111)
Interrupt Confirmation packet received for this Virtual
Circuit. The remote DTE has confirmed the Interrupt packet which
was sent. - ST26LCENB (112)
VC ZLU has been enabled. This indicates that the VC
ZLU is now in the enabled state. At this point, the ZLU is available
to place a call (SVC) or for transferring data (PVC). - ST26LCTPA (113)
VC ZLU has been activated. If the virtual circuit was
in a flow control state (RNR sent), then an RR has been sent and
inbound data will now be accepted by this virtual circuit. - ST26LCUP (114)
The Virtual Circuit is now in the UP state. That is, it is available
for data transfer operations. For SVCs this status message indicates
that the call setup processing is complete. You should not attempt
to send data until this status message is received. This status
message also contains 16 bits of data containing the Logical Channel
Number (LCN) used for this Virtual Circuit. - ST26LCDN (115)
The Virtual Circuit is now in the DOWN state. This status message usually
indicates the completion of the Call Clear processing for an SVC.
Note that if you have issued a Clear Request, you should not attempt
to place a call on this VC until you receive this status message. This
status message also contains two bytes of data: Byte 1 = Cause code
Byte 2 = Diagnostic code - ST26LCTPD (116)
The VC ZLU has been deactivated. This status indicates
that the VC has been placed into an inbound flow control mode. That
is, an inbound data packet on this VC will result in a level 3 RNR
being transmitted. - ST26LCDSB (117)
The VC ZLU has been disabled. A disabled VC ZLU may
not be used to accept or place calls (SVC) or to transfer data (PVC).
Any call that was established has been cleared. - ST26LCRST (118)
VC Reset Request confirmation received. This indicates
that the Reset request processing is complete. Either a reset collision
has occurred or the remote end of the link has confirmed the reset
request. - ** ST26CLRCV (119)
Inbound Call Request received on the SVC ZLU. This
status is only received when the ACK bit
is set to 0 in the VC ZLU's option word. The ACC X.25 subsystem
will automatically attempt to send a Call Accept packet. Note that
this status message is accompanied by a data buffer containing the
contents of the Call packet. - ** ST26CLRCF (120)
Inbound Call Request received on the SVC ZLU requiring
application acknowledgment. This status is only received when the ACK bit is set to 1 in the VC ZLU's
option word. If the application does not acknowledge the inbound
call (using zx25callacc or zx25callrej) within 60 seconds, the
call will be automatically cleared by the ACC X.25 subsystem. Note
that this status message is accompanied by a data buffer containing
the contents of the Call packet. - ** ST26LCRSR (121)
Reset Indication received on VC. If the RSET bit is set to 1 in the VC ZLU's
option word, then the application is required to confirm the reset
within 60 seconds by calling zx25reset_conf().
If the RSET bit is set to 0,
then the ACC X.25 subsystem will automatically issue a Reset Confirmation
packet on the VC. This status is also accompanied by data structure containing
the reset cause and diagnostic codes. - ** ST26LCCLR (122)
Clear Request packet received on VC. This indicates
that the Call Clear processing has begun. The application will receive
a VC DOWN (115) status message when the clear processing is complete.
This status message also has an associated data buffer containing
the Clear packet data. - ** ST26LCCLC (123)
Call Accepted packet received on VC. This indicates
that an outbound call has been accepted by the destination. This
status does not indicate the
call is now established. The application should wait for the VC
UP status message. Status 123 also has an associated data buffer
which contains the Call Accept packet information. - ** ST26LCRSS (124)
Local VC Reset initiated due to protocol exception
condition. This indicates that the ACC X.25 subsystem has sent a
Reset Request as the result of an exception condition. For example,
if an Interrupt packet that was sent is not confirmed within T26 seconds. - ZxRESET_TO(125)
VC Reset Request has timed out. That is, the remote
end of the link has not replied with a Reset Confirmation packet
within the allowed amount of time (T22 timer). - **ZxCLR_CONF(126)
Clear Confirmation packet received on VC. The status
message data buffer contains the clear confirmation packet data.
The status code symbolic names are available to C application
programs by including the file /opt/acc/include/zcom/zx25status.h. The statuses marked "**" are received by
the application with the packet data. These statuses are only received
if the "notify application" option is enabled
for the virtual circuit terminal. The packet data layout is described
in /opt/acc/include/zcom/zcomx25.h for
C as described in the following diagrams. The routine X25STAT may be called to convert any X.25 status
codes to a description. This is call compatible and may be used
as a direct replacement for the ZCOM Status call which is documented
in the Multiprotocol ACC Programmer's Reference
Guide. The C structure for the packet data layout is as follows: #define X25PKDATALEN 512 /* Max len of facility + user data */
typedef struct {
uint16 x25pkdbit; /* Deliv. confm bit: ZX25_TRUE, ZX25_FALSE */
uint16 x25pkcaus; /* Cause code */
uint16 x25pkdiag; /* Diagnostic code */
uint16 x25pkdflg; /* Use call addr: ZX25_TRUE, ZX25_FALSE */
uint8 x25pkcald[8]; /* Called X.121 address */
uint16 x25pkgflg; /* Use calling addr: ZX25_TRUE, ZX25_FALSE */
uint8 x25pkclng[8]; /* Calling X.121 address */
uint16 x25pkflen; /* Facility data byte length */
uint16 x25pkulen; /* User data byte length */
char x25pkdata[X25PKDATALEN]; /* Facility and user data */
} x25pkform_type
|
Printable version
