x25 Protocol Manual

X.
25 Protocol
Users Guide
205 Indigo Creek Drive
Rochester, NY 14626
Phone +1.585.256.0200
support@pt.com
w w w. p t . c o m
Document Revision History Part Number

112p0996.10 112p0996.20 112p0996.30 112p0996.31 112p0996.40 112p0996.41 112p0996.42 112p0996.43 112p0996.44 112p0996.45 112p0996.46 112p0996.47 112p0996.48 112p0996.49 112p0996.50
Date
10/21/98 03/19/99 11/12/01 08/29/02 02/28/03 07/23/03 11/17/03 10/11/04 03/14/05 08/04/05 01/15/07 5/28/07 6/16/08 07/09/10 01/18/11
Explanation of Changes
Initial Release Added Section 5: QMC Configuration Reformatting Conversion and Reformatting. Removed QMC Configuration Section. Various modifications to content in Chapter 4. Modifications to the Wantemplate in Chapter 4. Modifications to Extended Mode Listen definitions in Chapter 3. Modifications to the X.25 template in Chapter 4. Modifications to dnetd network daemon information in Chapter 4. Administration modifications in Chapter 4. Modifications to the X.25 template (added value 4 to option 75) in Chapter 4. Minor corrections to OS and path. Reformatting. Other minor edits. Rebranded and reformatted. Removed Appendix D, Writing an X.25 Link Monitor Application." Modified function descriptions in the topic Network Control Functions on page 75.
Copyright Notice Copyright 2011 by Performance Technologies, Inc. All Rights Reserved. The PT logo is a registered trademark of Performance Technologies, Inc. All other product and brand names may be trademarks or registered trademarks of their respective owners. This document is the sole property of Performance Technologies, Inc. Notice This document presents information for users of PTs X.25 protocol. The information contained in this document is considered accurate and characteristic of the subject product at the time of writing. Performance Technologies, Inc., reserves the right to make changes to this document and any products described herein to improve reliability, function, or design. Performance Technologies, Inc., does not assume any liability arising out of the application or use of any product or circuit described herein. Although diligent efforts are made to provide accurate technical information to the user, occasionally errors and omissions occur in manuals of this type. Refer to the Performance Technologies, Inc. web site to obtain manual revisions or current customer information: http://www.pt.com. Performance Technologies, Inc., reserves its right to change product specifications without notice.
Contents
Chapter 1: About This Guide
11
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Symbol Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Customer Support and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Customer Support Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Other Web Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Return Merchandise Authorization (RMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Product Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Chapter 2: Getting Started
15
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Running the Test Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Switched Virtual Circuit Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 X25SVCSND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 X25SVCRCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Running the Switched Virtual Circuit Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Permanent Virtual Circuit Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 X25PVCSND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 X25PVCRCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Running the Permanent Virtual Circuit Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Chapter 3: X.25 Programmer's Guide
27
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Contents
The Network Layer Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Quality of Service and X.25 Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Listens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Listening for Incoming Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Standard Mode Listen Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Extended Mode Listen Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 NLI Message Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Connect Request/Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Connect Response/Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Data Acknowledgement Request/Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Expedited Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Expedited Data Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Reset Request/Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Reset Response/Confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Disconnect Request/Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Disconnect Confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Abort Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Listen Command/Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Listen Cancel Command/Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 PVC Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 PVC Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Programming Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Opening a Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Closing a Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Listening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 PVC Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Contents
Chapter 4: X.25 Network Managers Guide
75
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Network Control Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 DNETD and NETD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Network Control Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 nc_alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 nc_close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 nc_delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 nc_fdval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 nc_initialise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 nc_link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 nc_muxval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 nc_open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 nc_pop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 nc_push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 nc_rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 nc_shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 nc_shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 nc_strioc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 nc_terminate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 nc_unlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 nc_version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Re-configuring Network Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Running the DNETD Example Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 V.25bis Compliant Modem Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Modem Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Providing a Telephone Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 V.25bis Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 Network Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 dnetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Contents
lltune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 mknetconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 netd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 nuimap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 pvcmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 wanmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 wantune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 x25llmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 x25stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 x25tune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Network Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 equalx25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 getnettype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 getsubnetent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 getxhostent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 snidtox25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 stox25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 x25tos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 x25tosnid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Network Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 lapbtemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 netconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 nuimapconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 pvcmapconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 subnetworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 wanmapconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 wantemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 x25conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 x25template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 xaddrf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 xhosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Contents
X.25 Address Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140 Special Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 lapb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 x25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Appendix A: Product Safety Information
143
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Product Safety Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Safety Precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 AC or DC Power Safety Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 DC Power Safety Warning (DC Powered Units) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 Rack Mount Enclosure Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 General Safety Precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Appendix B: NLI Events Appendix C: Error Codes
147 149
Contents
Tables
Table 2-1: Network and Country Listing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Table 2-2: SVC Test Programs Options, Defaults, and Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . 19 Table 2-3: X25SVCSND Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 2-4: X25SVCRCV Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 2-5: PVC Test Programs Options, Defaults, and Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . 23 Table 2-6: X25PVCSND Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Table 2-7: X25PVCRCV Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Table B-1: Downstream Messages and Associated Outgoing X.25 Packets. . . . . . . . . . . . . . . . . . 147 Table B-2: Upstream Messages and Associated Incoming X.25 Packets . . . . . . . . . . . . . . . . . . . . 147
Tables
10
Chapter 1
About This Guide
Overview
This guide is intended to be used by programmers writing applications that interface to PTs X.25 Protocol. It describes the Network Layer Interface (NLI), which the programmer can use to access the X.25 Packet Layer Protocol Driver. The guide includes the following chapters: Chapter 1, About This Guide, on page 11, this chapter, provides information about related documents, text and symbol convention, and a history of previous revision in this guide. Chapter 2, Getting Started, on page 15 - Provides a description of the installation and operation of the networking software. It provides a brief overview of the Network Layer Interface and a guide to running the sample applications. Chapter 3, X.25 Programmer's Guide, on page 27 - Provides a list of the include files which a programmer needs. Details the function and use of the data structures used across the NLI for addressing, Quality of Service and facility negotiation. Shows how to set up an application to listen for incoming calls. Describes the interface message formats and parameters which the X.25 driver supports. Provides programming examples using the NLI. Chapter 4, X.25 Network Managers Guide, on page 75 - Provides manual pages which describe all the programs, application utilities, and configuration files available to the Network Manager, programmers, and users. Appendix A, Product Safety Information, on page 143 - Provides information relevant to preventing injury and preventing harm to equipment and data. Appendix B, NLI Events, on page 147 - Provides information about NLI events. Appendix C, Error Codes, on page 149 - Provides information about error codes.
Related Documents
This guide should be used in conjunction with your UNIX or Windows system's Streams Primer, Streams Programmer's Guide, and Programmer's Reference Manual. It is assumed that the programmer is familiar with ISO 8208, X.25 Packet Level Protocol for Data Terminal Equipment. Documentation to support the additional components that you purchased from PT is available on the documentation CD. The most current documentation is available at www.pt.com under the product you are inquiring about.
11
Text Conventions
This guide uses the following text conventions. Convention
Monospace font Bold font
What it is Used For

Monospace font is used to represent sample code. Bold font is used to represent: pathnames filenames UNIX commands user input
Italic font
Italic font is used to represent: notes that supply useful advice general information referenced documents
<> All Capitals
Angle brackets are used to represent variables such as file names, passwords, and so on. All capitals are used for the ENTER and TAB keys and the SPACEBAR on your keyboard.
12
Symbol Conventions
Symbol Conventions
The following symbols appear in this document. Caution: There is risk of equipment damage. Follow the instructions. Warning: Hazardous voltages are present. To reduce the risk of electrical shock and danger to personal health, follow the instructions. Additional safety information is available throughout this guide and in Appendix A, Product Safety Information.
Customer Support and Services

PT offers a variety of standard and custom support packages to ensure customers have access to the critical resources that they need to protect and maximize hardware and software investments throughout the development, integration, and deployment phases of the product life cycle. If you encounter difficulty in using this PT product, you may contact our support personnel by:
1. EMAIL (Preferred Method) Email us at the addresses listed below or use our online email support form. Outline your problem in detail. Please include your return email address and a telephone number. 2. TELEPHONE Contact us via telephone at the number listed below, and request Technical Support. Our offices are open Monday to Friday, 8:00 a.m. to 8:00 p.m. (Eastern Time).
PT Support Contact Information Embedded Systems and Software (Includes Platforms, Blades, and Servers) Email Phone
support@pt.com +1 (585) 256-0248 (Monday to Friday, 8 a.m. to 8 p.m. Eastern Time)
SS7 Systems (Includes SEGway)

ss7support@pt.com +1 (585) 256-0248 (Monday to Friday, 8 a.m. to 8 p.m. Eastern Time)
If you are located outside North America, we encourage you to contact the local PT distributor or agent for support. Many of our distributors or agents maintain technical support staffs.
Customer Support Packages

Our configurable development and integration support packages help customers maximize engineering results and achieve time-to-market goals. To find out more about our Customer Support packages, visit http://www.pt.com/page/support/.
13
Other Web Support

Support for existing products including manuals, release notes, and drivers can be found on specific product pages at http://www.pt.com. Use the product search to locate the information you need.
Return Merchandise Authorization (RMA)

To submit a return merchandise authorization (RMA) request, complete the online RMA form available at http://pt.com/assets/lib/files/rma-request-form.doc and follow the instructions on the form. You will be notified with an RMA number once your return request is approved. Shipping information for returning the unit to PT will be provided once the RMA is issued.
Product Warranty
Performance Technologies, Incorporated, warrants that its products sold hereunder will at the time of shipment be free from defects in material and workmanship and will conform to Performance Technologies applicable specifications or, if appropriate, to Buyers specifications accepted by Performance Technologies in writing. If products sold hereunder are not as warranted, Performance Technologies shall, at its option, refund the purchase price, repair, or replace the product provided proof of purchase and written notice of nonconformance are received by Performance Technologies within 12 months of shipment, or in the case of software and integrated circuits within ninety (90) days of shipment and provided said nonconforming products are returned F.O.B. to Performance Technologiess facility no later than thirty days after the warranty period expires. Products returned under warranty claims must be accompanied by an approved Return Material Authorization number issued by Performance Technologies and a statement of the reason for the return. Please contact Performance Technologies, or its agent, with the product serial number to obtain an RMA number. If Performance Technologies determines that the products are not defective, Buyer shall pay Performance Technologies all costs of handling and transportation. This warranty shall not apply to any products Performance Technologies determines to have been subject to testing for other than specified electrical characteristics or to operating and/or environmental conditions in excess of the maximum values established in applicable specifications, or have been subject to mishandling, misuse, static discharge, neglect, improper testing, repair, alteration, parts removal, damage, assembly or processing that alters the physical or electrical properties. This warranty excludes all cost of shipping, customs clearance and related charges outside the United States. Products containing batteries are warranted as above excluding batteries. THIS WARRANTY IS IN LIEU OF ALL OTHER WARRANTIES WHETHER EXPRESS, IMPLIED OR STATUTORY INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS. IN NO EVENT SHALL PERFORMANCE TECHNOLOGIES BE LIABLE FOR ANY INCIDENTAL OR CONSEQUENTIAL DAMAGES DUE TO BREACH OF THIS WARRANTY OR ANY OTHER OBLIGATION UNDER THIS ORDER OR CONTRACT.
14
Chapter 2
Getting Started
Overview
This chapter provides an overview of the X.25 Protocol software package. It contains what you need to do to get started with the X.25 Protocol and where to look in other chapters for more information. Key topics in this chapter include:
Installation, on page 16 Configuration, on page 17 Running the Test Applications, on page 18 Switched Virtual Circuit Test Programs, on page 19 Permanent Virtual Circuit Test Programs, on page 23
To perform the software installation and X.25 configuration, you should be familiar with UNIX or Windows system administration and the X.25 Protocol. PTs X.25 Protocol is a port of SpiderX.25, which is a STREAMS implementation of the X.25 Protocol suite. The PT implementation of SpiderX.25 runs under xSTRa, the PT real-time executive for STREAMS applications. The product meets the approval requirements for the European Telecommunication Standard NET2 for connecting a DTE to an X.25(84) PSDN, and the joint U.S. standard FIPS 100 / Federal Standard 1041 [22] for the DTE/DCE interface. SpiderX.25 contains comprehensive configuration mechanisms which allow the software to be tailored for operation on many worldwide Public Data Networks (PDN). The list of PDNs which are currently supported is shown in Table 2-1, Network and Country Listing Table. Note that the PT implementation of SpiderX.25 is not certified on all of these networks. Table 2-1: Network and Country Listing Table Network
PSS DATAPAC TELENET TYMNET DDX-P ACCUNET DATAPAK DCS DATAPAC PACNET
Country
UK Canada USA USA Japan USA Sweden Belgium Finland New Zealand
Network
AUSTPAC DDN TRANSPAC DATTEX-P VENUS-P ITAPAC DATANET TELEPAC FINPAC LUXPAC
Country
Australia USA France Germany Japan Italy Holland Switzerland Finland Luxembourg
15
Installation
Before you can use the X.25 Protocol software, you must first install the hardware and software.
Embedded Controller Installation

For Installation of a communication controller, refer to the Users Guide you received from PT.
LAN-based Server Installation

For installation of a LAN-based server, refer to your Software & Hardware Installation Guide.
Software Installation
To install the X.25 Protocol Software package, read the instructions in the Software & Hardware Installation Guide. Note: This change applies to all docs.
16
Configuration
Configuration
There are two techniques available to prepare the server to support applications. For the first case, the initialization and configuration of an X.25 Protocol network is accomplished by means of four configuration utilities and five configuration files. The top-level netd utility uses information in the file netconf to set up and initialize the software modules as required by your hardware configuration. After initializing the modules, netd runs the other three utilities to configure each level of the server network software according to your specific site requirements. Each of these utilities has a corresponding configuration file. The fifth configuration file, called x25conf, is currently used only by the x25stat utility, which displays network statistics. The second technique is provided for users that require control of the link (lapb) layer of the network. This technique uses the dnetd utility and requires software to be written that builds the streams from the server modules. This software accesses the dnetd utility using interprocess communication procedures. Like netd, this software invokes the utilities to read the configuration files and configure the three levels of the server network software. With this approach, there is no netconf file; all information is developed from user developed software. The rest of this chapter describes the first technique. The second technique is discussed in Chapter 4, X.25 Network Managers Guide, on page 75. The configuration utilities are described in Chapter 4, X.25 Network Managers Guide, on page 75. These utilities are copied to the directory UNIX /etc during the software installation procedures, or to the %PTI%\bin directory for Windows systems. The configuration files are described in Chapter 4, X.25 Network Managers Guide, on page 75. The install script copies netconf and x25conf to the UNIX etc directory (/etc), and the remainder of the sample configuration files to the UNIX templates directory (/usr/lib/snet/ template). For a Windows system, the install program copies netconf and x25conf to the etc directory (%PTI%\etc), and the remainder of the sample configuration files to the templates directory (%PTI%\lib-\snet\template). The x25tune utility reads X.25 configuration parameters from a file in the format specified by x25template. Two sample x25template files, def.dce84.x25 and def.dte84.x25, are provided with this release. The lltune utility reads a file in the format specified by lapbtemplate to obtain link layer configuration parameters. A sample lapbtemplate file called def.lapb is included with the release. Configuration of the wide-area network is performed by wantune according to parameters specified in a wantemplate configuration file. The sample wantemplate file is called def.wan. If your configuration includes an ITU-T V.25bis compliant modem on a dial-up line and the server is to provide telephone numbers to the modem, the wanmap utility can be used to provide telephone numbers to the server software. See Chapter 4, X.25 Network Managers Guide, on page 75 for information about using the V.25bis calling procedures provided by the server.
17
Important Information
1. Read the descriptions of wantune on page 100 and wantemplate on page 124. Modify the file def.wan in the templates directory according to your site requirements. For multiple subnetworks (links) with different configuration requirements, you will need more than one wantemplate file. You can name the file(s) anything you like; the filename for each subnetwork is specified in netconf. 2. Read the descriptions of lltune on page 91 and lapbtemplate on page 116. Modify the def.lapb file in the templates directory according to your site requirements. As described above for wantune, you may need different lapbtemplate files for different subnetworks. 3. Read the descriptions for x25tune on page 106 and x25template on page 127. Modify one or both of the sample x25template files in the templates directory according to your site requirements. One of the sample files configures a subnetwork as DTE and the other configures it as DCE. If you plan to test your installation by connecting two links with a loopback cable, you must configure one as DTE and the other as DCE. 4. Read the descriptions for netd on page 94 and netconf on page 118. Modify the netconf file in the /etc directory to use the x25stat utility, read the description for x25conf on page 126 and modify the x25conf file in the /etc directory as well. The netconf and x25conf files contain similar information, which must be consistent across the two files. 5. If you have a controller installed in a host backplane. The commload utility is used to download the communication controller(s). Refer to the MPS Software & Hardware Install Manual for a description of the commload utility usage procedures 6. If you have a LAN-based server, power on the server and verify that it loads successfully. Refer to Appendix A of the MPS Software & Hardware Install Manual for a description of the network load procedures. 7. Login as root and execute the command netd found in the /etc directory on UNIX systems and in %pti%\bin on Windows systems. When netd begins execution, it prints the message Start. When it completes successfully, it prints the UNIX message forking, or the Windows message Iconify this window..., meaning that it has created a background daemon process to control the X.25 environment. If netd or any of the three tune utilities encounters an error, it prints a description of the error and netd exits without displaying the forking message. Errors are generally caused by an invalid parameter or format error in one of the configuration files.
Running the Test Applications

After you have completed the X.25 Protocol configuration, you can verify your installation by running some of the test programs included with the release. The files needed to run these test programs are in the UNIX directory /usr/pti/x25/tests/x25tests or the Windows directory %PTI%\x25\tests\x25tests. Note: If you want to reset the controller or server, first kill the netd daemon process, then reload, and finally start netd again.
18
Switched Virtual Circuit Test Programs

The Switched Virtual Circuit (SVC) test programs, x25svcsnd and x25svcrcv, provide examples of how the X.25 Protocol Network Layer Interface data structures are used to establish a call, listen for a call, accept a call, and exchange data. These test programs are designed to operate together over two serial links connected with a loopback (null modem) cable. You need two terminals (or windows) to run the test, one for x25svcsnd and one for x25svcrcv. The test programs are invoked as follows: x25svcsnd x25svcrcv [-p pktsize] [-t] [-o controller][-s server] [-v service] [-c subnetid] [-t] [-o controller][-s server] [-v service] [-x x25address]
Table 2-2: SVC Test Programs Options, Defaults, and Descriptions Command-line Option
-c subnetid
Default Value
A (x25svcrcv only)
Description
The subnet id option directs the x25svcrcv program to send the call request to the specified subnetwork, i.e., to the link associated with the subnetwork. For example, -c A would request that the call go out on the link associated with subnetwork A. The association between subnetworks and links is defined in the netconf configuration file found in the /etc directory. The netconf file provided with the release associates subnetwork A with link zero. The controller option specifies the embedded board controller number. The packet size parameter is used when reading the file, and writing data to the link. The file read is issued indicating that the buffer size is packet size. The server parameter identifies the target server and is stored in the data structure for the MPSopen command. The default assumes the embedded board case, and is /dev/ucsclone in UNIX systems and \\.\PTIXpqcc for Windows systems. By convention, this is the path name to the embedded boards drivers cloneable special file. For a LAN-based server, server is the server's host name as specified in the hosts database in the /etc directory. The trace option causes the operation of the program to be displayed on the standard output device. For LAN-based servers, this identifies the service name to be accessed, as specified in the clients services database in the /etc directory. For embedded-board servers, servers installed in a backplane, this parameter is not used. The address option allows a called X.25 address to be specified.
-o controller -p pktsize
0 128 bytes
-s server
/dev/ucsclone
-t
trace
trace disabled mps (LAN server only)
-v service
-x x25address
no address
19
X25SVCSND
The x25svcsnd program begins by opening a connection to the specified server. Then it displays the following menu: Table 2-3: X25SVCSND Menu
L A D S Send Listen Send Call Accept Send Disconnect Display Statistics C T Q Read Incoming Call Send File Quit Program
Option ? The usual sequence is: L C A T D Q Send a listen to the server. The server validates the message and returns a message indicating whether or not it accepted the listen. Read the incoming call. x25svcsnd waits for a call from the link. At this point, x25svcrcv should send a call. Send a call accept message. Send a file. x25svcsnd prompts for the name of a file. It opens the file, reads its contents and writes it to the server. Send disconnect. The file has been written across the link. Disconnect the call. Close connection and exit.
X25SVCRCV
The x25svcrcv program begins by opening a connection to the specified server. Then it displays the following menu: Table 2-4: X25SVCRCV Menu
C D Q Send Call Send Disconnect Quit Program T B Receive File Send Clear Confirm
Option ? The usual sequence is: C T Send a call. x25svcrcv sends a call on the link and waits for a reply. The call has been accepted, prompt user for a file name. Open the file, read the link and write the data to the file. When x25svcrcv reads a disconnect, it closes the file and displays the menu. Close connection and exit.
20
Running the Switched Virtual Circuit Test Programs

Before running the SVC Test programs, the following items must be performed:
The server must be loaded with the X.25 software. The netd command must complete successfully.
Running the Switched Virtual Circuit Test Programs

1. Connect a loopback cable between two serial ports.
2. Start x25svcsnd. If you have an embedded board, the default parameters sufficient. An example of this is: x25svcsnd -t Note: If you have a LAN-based server, you must specify the name of the server. In this example, diamond is the server name. The command is: x25svcsnd -s diamond -t When x25svcsnd has opened a connection to the server, it displays a menu and waits for your input. An example of this menu is displayed in Table 2-3, X25SVCSND Menu, on page 20. Option ?
1. Select an option from the list. Select L to register a listen with the server. The server accepts the listen and writes a message back to x25svcsnd. Select C to listen for an incoming call.
2. Execute x25svcrcv. If you have an embedded board, the default parameters suffice if subnet id A is configured and is associated with one of the links being used in the test. The command is: x25svcrcv -t
Note: If you have a LAN-based server, you must specify the name of the server. This is the same name of the server as it appears in the hosts database in the /etc directory. In this example, diamond is the server name. The command is: x25svcsnd -s diamond -t When x25svcrcv has opened a connection to the server, it displays its menu and waits for your input. An example of this menu is displayed in Table 2-4, X25SVCRCV Menu, on page 20.
21
Option ?
1. Select an option from the list. Select C to send a call. The call goes to the link associated with the specified subnet id. The default subnet id is A. If you use the distributed netconf configuration file in the /etc directory, the call goes out on port 0, since it is associated with subnet id A. The call is read by x25svcsnd. It displays its menu. 2. Select A to accept the call. When control is returned to x25svcsnd, it displays its menu. The call acceptance is read by x25svcrcv, and it displays its menu. 3. Select T at the x25svcrcv menu to receive a file. After you enter T, x25svcrcv prompts you for the name of the file for the received data. Provide it with a file name in a directory x25svcrcv can write to. Then at x25svcsnds menu select T to transmit a file. After you enter T, x25svcsnd prompts you for a file name. Enter the name of a file x25svcsnd can read. Once x25svcsnd has opened the file, it begins reading the file and transmitting the data. After each data write, it prints a dot. As x25svcrcv reads the data, it writes it to the receive file and prints a count of the number of data messages received. 4. x25svcsnd displays a menu after it finishes sending the file. Select D to send a disconnect. The disconnect is read by x25svcrcv, causing it to close the receive file and display its menu. 5. Select Q from both menus to close all connections and exit.
To file transmitted may then be compared to the file received to ensure proper data transmission and reception. There should be no differences.
22
Permanent Virtual Circuit Test Programs

The Permanent Virtual Circuit (PVC) test programs, x25pvcsnd and x25pvcrcv, are included with the release. They provide examples of how the X.25 Protocol Network Layer Interface data structures are used to exchange data by attaching to one or more permanent virtual circuits. These test programs are designed to operate together over two serial links connected with a loopback (null modem) cable. You need two terminals (or windows) to run the test, one for x25pvcsnd and one for x25pvcrcv. The test programs are invoked as follows: x25pvcsnd x25pvcrcv [-c subnetid] [-l starting lci] [-n number of PVCs] [-p pktsize] [-t] [-o controller] [-s server] [-v service] [-c subnetid] [-l starting lci] [-n number of PVCs] [-t] [-o controller] [-s server] [-v service]
Table 2-5: PVC Test Programs Options, Defaults, and Descriptions Command-line Option
-c subnetwork
Default Value
For x25pvcsnd, A. For x25pvcrcv, B.
Description
The subnetid option directs the programs to attach to the specified subnetwork, i.e., to the link associated with the subnetwork. For example, running x25pvcsnd with -c A requests that x25pvcsnd attach the link associated with subnetwork A. The association between subnetworks and links is defined in the netconf configuration file. The netconf file in the /etc directory provided with the release associates subnetwork A with link zero, and subnetwork B with link one. The test programs must be executed specifying unique subnetworks. The logical channel indication (lci) option directs the program to attach to a channel starting at this lci. The range of logical channels or permanent virtual circuits is configured in the dce and dte x25template files at lines 4 and 5. The test programs may be executed specifying the same lci. The number of PVCs option directs the program to perform all the functions (attach, detach, transmit, receive, reset) on each of this specified number of PVCs, starting at the lci specified in the lci option. The controller option specifies the embedded board controller number. The packet size parameter is used when reading the file being transferred, and writing data to the link. The file read is issued indicating that the buffer size is packet size.
-l
starting lci
-n number of PVCs
-o -p packet size
0 128 (x25pvcsnd only)
23
Table 2-5: PVC Test Programs Options, Defaults, and Descriptions (Continued) Command-line Option
-s server
Default Value
/dev/ucsclone
Description
The server parameter identifies the target server and is stored in the data structure for the MPSopen command. The default assumes the embedded board case and for a UNIX system is /dev/ucsclone, and for a Windows system is \\.\PTIXpqcc. By convention, this is the pathname to the embedded boards drivers cloneable special file. For a LAN-based server, server is the server's host name as specified in the hosts database in the /etc directory. The trace option causes the operation of the program to be displayed on the standard output device. For LAN-based servers, this parameter identifies the service name to be accessed, as specified in the clients services database in the /etc directory. For embedded-board servers, servers installed in a backplane, this parameter is not used.
-t trace -v service
(trace disabled) mps (LAN server only)
X25PVCSND
The x25pvcsnd program begins by opening a connection to the specified server. Then it displays the following menu: Table 2-6: X25PVCSND Menu
A T Q Attach to PVC(s) Send File Quit Program R D Send Reset Request Detach From PVC(s)
Option ? The usual sequence is: A R T D Q Attach to the PVC(s). Send a reset request. (The program will reset each PVC.) Send a file. x25pvcsnd prompts for the name of a file. It opens the file, reads its contents and writes it to each PVC attached to the server. Detach from the PVC(s). The file has been written across the link. Close connection and exit.
24
X25PVCRCV
The x25pvcrcv program begins by opening a connection to the specified server. Then it displays the following menu: Table 2-7: X25PVCRCV Menu
A T Q Attach to PVC(s) Receive File Quit Program R D Send Reset Request Detach From PVC(s)
Option ? The usual sequence is: A R T Attach to the PVC(s). Send a reset request. (The program will reset each PVC.) Receive a file. x25pvcrcv prompts for the name of a file. It opens the file, reads the link and writes the data to the file for the first PVC specified. When x25pvcsnd detaches from the circuit, x25pvcrcv reads a reset indication. At this point, x25pvcrcv closes the receive data file, and displays its menu. Close connection and exit.
Running the Permanent Virtual Circuit Test Programs

Before running the test programs, the configuration process discussed above must be completed, the server must be loaded with the X.25 software, and the netd command must complete successfully. Each test program attaches to a subnetwork. These subnetworks must be distinct. The defaults are subnetwork A for x25pvcsnd and subworknet B for x25pvcrcv. The loopback (null modem) cable must connect the links associated with the subnetworks selected, and the subnetworks selected must be included in the configuration file netconf in the /etc directory. The dte and dce x25template files in the distribution define no permanent virtual circuits since most applications employ switched virtual circuits. So, before the pvc test programs can be executed, both dte and dce x25template files in the templates directory (def.dce84.x25 and def.dte84.x25) must be modified at lines 4 and 5. If both lines in both files are set to 001, the test programs run successfully with the run time defaults. To run the test programs, connect a loopback cable between two configured serial ports. Start x25pvcsnd first. If you have an embedded board, the default parameters suffice if you are using links that are associated subnetworks A and B, and both subnetworks are configured and connected with loopback (null modem) cables. For this case the command is: x25pvcsnd -t
If you have a LAN-based server, you must specify the name of the server. Suppose the servers name is diamond. For this case the command is:
25
x25pvcsnd
-s diamond
-t
When x25pvcsnd has opened a connection to the server, it displays its menu and waits for your input. An example of this menu is displayed in Table 2-6, X25PVCSND Menu, on page 24. Option ? At this point, execute x25pvcrcv. If you have an embedded board, the default parameters should suffice. For this case the command is: x25pvcrcv -t
If you have a LAN-based server, you must specify the name of the server. Suppose the servers name is diamond. For this case the command is: x25pvcrcv -s diamond -t
When x25pvcrcv has opened a connection to the server, it displays its menu and waits for your input. An example of this menu is displayed in Table 2-7, X25PVCRCV Menu, on page 25. Option ? Select A at both menus to attach to the pvc. Then select R at both menus to reset the circuit. At the x25pvcrcv menu, select T to receive a file. x25pvcrcv prompts you for the name of the file for the received data. Provide it with a file name in a directory x25pvcrcv can write to. Then at x25pvcsnds menu select T to transmit a file. x25pvcsnd prompts you for a file. Provide it with the name of a file it can read. Once x25pvcsnd opens the file, it begins reading the file and transmitting the data. After each data write, it prints a dot. As x25pvcrcv reads the data, it writes it to the receive file and prints a dot for each packet read. When x25pvcsnd finishes sending the file, it displays its menu. Select D to detach from the circuit. The detach is read by x25pvcrcv, causing it to close the receive file and display its menu. At this point, both test programs to display their menus. For both programs, select Q to exit. The file transmitted may then be compared to the file received to ensure proper data transmission and reception. There should be no differences. When running with more than one PVC, the program only writes the first PVCs file to disk; otherwise, many large files could be created when transmitting large files on a large number of PVCs.
26
Chapter 3
X.25 Programmer's Guide
Overview
This chapter is intended to be used by programmers writing applications that interface to the X.25 Protocol. It describes the Network Layer Interface (NLI), which the programmer can use to access the X.25 Packet Layer Protocol Driver. This guide should be used in conjunction with your UNIX system's Streams Primer, Streams Programmer's Guide, and Programmer's Reference Manual. It is assumed that the programmer is familiar with ISO 8208, X.25 Packet Level Protocol for Data Terminal Equipment. Key topics in this chapter include:
Data Structures, on page 28 details the function and use of the data structures used across the NLI for addressing, Quality of Service, and facility negotiation. Listens, on page 36 shows how to set up an application to listen for incoming calls. NLI Message Primitives, on page 41 describes the interface message formats and parameters supported by the X.25 driver Programming Examples, on page 51 provides programming examples using the NLI.
The Network Layer Interface

The X.25 Protocol supports a Network Layer Interface (NLI) to the X.25 Packet Layer Protocol (PLP) for use by applications. This NLI is Spider Systems' proprietary Application Programming Interface. This interface uses the PT Application Programming Interface (API) with standard STREAMS message formatting. In this way, application programs in user space interact with the PLP Driver running on the PTI communication controller or server by exchanging STREAMS messages, using the MPSgetmsg and MPSputmsg API calls. Messages passed in this way have both a control part and a data part. Primitives and associated parameters are passed to the X.25 driver by using the control part of messages. If data is to be passed with a primitive, it is contained in the data part of the message. This means that the application must always provide a control part in messages when using the API calls MPSgetmsg and MPSputmsg, whether data is present in the message or not. Using this message type, the packet structure and parameters necessary for a general X.25 driver can be mapped into the STREAMS environment very easily. Refer to the document MPSapi Application Programming Interface Users Manual for more information about the API.
27
Include Files
On the PTI communication controllers and servers, the X.25 Protocol runs under xSTRa, the PTI executive for STREAMS applications. Client applications using the X.25 Protocol NLI need to include several xSTRa system header files:
xstopts.h and xstopen.h define the message structures used in xSTRa API calls. sys/snet/uint.h defines types used by the data structures passed across the NLI. sys/snet/x25_proto.h defines the data structures which must be included.
Data Structures
This section describes the data structures used by NLI primitives to specify X.25 addresses and facilities. These data structures are defined in the file <sys/snet/x25_proto.h>.
Addresses
In call requests and responses, it is usually necessary to specify the X.25 addresses associated with the connection - the called, calling and responding addresses. A common structure is used for these addresses. The addressing format used by this structure provides the following information:
the subnetwork on which outgoing Call Requests are to be sent and on which Connect Indications arrive; NSAPs and SNPAs (or DTE addresses and LSAPs); options in encoding of addresses (NSAPs).
The addressing format is:
#define NSAPMAXSIZE20 struct xaddrf { unsigned long unsigned char struct lsapformat unsigned char unsigned char } The fields in this structure are: sn_id
sn_id; aflags; DTE_MAC; nsap_len; NSAP[NSAPMAXSIZE];
sn_id is the subnetwork identifier, selected by the system administrator. This identifies the subnetwork required for a Connect Request, or on which a Connect Indication arrived. The sn_id field holds a representation of the one to four byte string subnetwork identifier as an unsigned long. The X.25 library routine snidtox25 can be used to convert the character representation of the subnetwork identifier to an unsigned long. aflags specifies the options required (or used) by the subnetwork to encode and interpret addresses. It takes one of three values:
aflags
28
Data Structures
0 1 2 DTE_MAC
NSAP field contains an OSI encoded NSAP address NSAP field contains a non-OSI encoded extended address the DTE_MAC field contains the LCI of a Permanent Virtual Circuit (PVC).
holds the DTE address, the MAC+SAP address or the Logical Channel Identifier (LCI). This is binary. The format of the lsapformat structure is described below. indicates the length of the NSAP, if any (and where appropriate), in semioctets. carries the NSAP or address extension (See field aflags above) when present as indicated by nsap_len. This is binary.
nsap_len NSAP
The format of the lsapformat structure is as follows: #define LSAPMAXSIZE9 struct lsapformat { unsigned charlsap_len; unsigned charlsap_add[LSAP MAXSIZE]; }; The fields in this structure are defined as follows: lsap_len gives the length of the DTE address, the MAC+SAP address or the LCI in semi-octets. The SAP always follows the MAC address. The DTE can be up to 15 decimal digits unless X.25(88) and TOA/NPI addressing is being used when it can be up to 17 decimal digits. For an LCI the length is 3. holds the DTE, MAC+SAP or LCI, when present, as indicated by lsap_len. This is binary.
lsap_add
Quality of Service and X.25 Facilities

Negotiable X.25 facilities are supported by the PLP driver. This section is concerned with the request and negotiation of these facilities, and describes the data structures used by the NLI primitives. Refer to the X.25 Network Managers Guide, on page 75 for details on the options selected for a particular subnetwork. The facility set can be broken down into two main groups - those required for CONS support and those for non-OSI procedures (X.29, for instance). Note: CONS may also use the non-OSI procedures.
CONS Quality of Service Parameters

The CONS quality of service (QOS) parameters supported are the following:
Throughput Class Minimum Throughput Class
29
Target Transit Delay Maximum Acceptable Transit Delay Use of Expedited Data Protection Priority Receipt Acknowledgement.
CONS-related quality of service parameters are defined in the following structure: #define MAX_PROT 32 struct qosformat { unsigned char reqtclass; unsigned char locthroughput, remthroughput; unsigned char reqminthruput; unsigned char locminthru, remminthru; unsigned char reqtransitdelay; unsigned short transitdelay; unsigned char reqmaxtransitdelay; unsigned short acceptable; unsigned char reqpriority; unsigned char reqprtygain; unsigned char reqprtykeep; unsigned char prtydata; unsigned char prtygain; unsigned char prtykeep; unsigned char reqlowprtydata; unsigned char reqlowprtygain; unsigned char reqlowprtykeep; unsigned char lowprtydata; unsigned char lowprtygain; unsigned char lowprtykeep; unsigned char protection_type; unsigned char prot_len; unsigned char lowprot_len; unsigned char protection[MAX_PROT]; unsigned char lowprotection[MAX_PROT]; unsigned char reqexpedited; unsigned char reqackservice; struct extraformat xtras; }; The fields in this structure are defined as follows:
Throughput Class
reqtclass is non-zero if the throughput negotiation parameter is selected, in which case the fields locthroughput and remthroughput contain, respectively, the four-bit throughput encoding for the directions local-to-remote and remote-to-local.
30
Data Structures
Minimum Throughput Class

reqminthruput is non-zero if the minimum throughput negotiation parameter is selected, in which case the fields locminthru and remminthru contain, respectively, the four-bit throughput encoding for the directions local-to-remote and remote-to-local.
Target Transit Delay

reqtransitdelay is non-zero if the transit delay parameter is selected, in which case transitdelay contains the 16-bit value - this applies to both Connect Requests and Indications. In a Connect Confirm, the value of the selected transit delay will be placed in the transitdelay field and will be non-zero.
Maximum Acceptable Transit Delay

If the calling NLI application specifies a maximum acceptable value for the transit delay parameter, (Lowest Quality Acceptable), then the field reqmaxtransitdelay is non-zero and acceptable contains the 16-bit value of the maximum acceptable. The transit delay selection relates only to Connect Requests and there is no transit delay QOS parameter in a Connect Response primitive. The correct response when the indicated QOS is unattainable is to make a Disconnect Request. Also, in a Connect Confirm, the value of the selected transit delay will be placed in the transitdelay field when such negotiation takes place.
Priority
The reqpriority field is used to request/indicate priority on a connection. The mandatory field prtydata contains the 8-bit value for the priority of data on the connection. The reqprtygain and reqprtykeep fields can be optionally set to indicate that the fields prtygain and prtykeep contain, respectively, the 8-bit value for the priority to gain a connection; and priority to keep a connection. On N-CONNECT requests the calling NS_user may also specify a lowest acceptable value for priority. The fields reqlowprtydata, reqlowprtygain, reqlowprtykeep, may be set to indicate that the fields lowprtydata, lowprtygain, and lowprtykeep contain, respectively, the 8-bit value for the lowest acceptable; priority of data on connection; priority to gain a connection.
Protection
If the protection negotiation parameter is selected, then protection_type is non-zero and indicates the type of protection required, in which case the mandatory fields prot_len and protection contain, respectively, the length and value for the target protection. On NCONNECT requests the calling NS_user may optionally specify a lowest acceptable protection, in which case the fields lowprot_len and lowprotection contain, respectively, the length and value for the lowest acceptable protection. Values for protection_type are: PRT_SRC PRT_DST PRT_GLB Source address specific Destination address specific Globally unique
31
Use of Expedited Data

If expedited data is required/selected, then the field reqexpedited is non-zero. For Connect Indications, a value of 1 implies that the expedited data negotiation facility was present in the INCOMING CALL packet, and that its use was requested. Note: Negotiation is a CONS procedure. When the facility is present and indicates non-use, use cannot be negotiated by Connect responses. See Connect Request/Indication, on page 41 for a description of the use of the CONS_call field in Connect Requests and Connect Responses. For incoming or outgoing non-CONS calls (denoted by the CONS_call flag set to 0), Expedited Data Negotiation is not required - interrupt data is always available in X.25. This means that this field is ignored on Connect Requests and Responses for non-CONS calls.
Receipt Acknowledgement Service

If the receipt acknowledgement service is to be used, the field reqackservice is non-zero. Setting reqackservice to 1 signifies receipt confirmation by the remote DTE. Setting reqackservice to 2 signifies receipt confirmation by the remote application. In the case of receipt confirmation by the remote DTE, no acknowledgements are expected or given over the X.25 interface. In the case of receipt confirmation by the remote application, there is a one to one correspondence between D-bit data and acknowledgements with one data acknowledgement being received/sent for each D-bit data packet sent/received over the X.25 interface.
Non-OSI Facilities
Note: The non-OSI facilities are also negotiable by CONS. For those NLI applications which require them, the non-OSI facilities supported are as follows:
Non-OSI extended addressing X.25 fast select request/indication with no restriction on response X.25 fast select request/indication with restriction on response X.25 reverse charging X.25 packet size negotiation X.25 window size negotiation X.25 network user identification X.25 Recognized Private Operating Agency selection X.25 Closed User Groups X.25 programmable facilities X.25 call deflection.
Facilities and QOS parameters are defined in the following structure: #define #define #define #define MAX_NUI_LEN MAX_RPOA_LEN MAX_CUG_LEN MAX_FAC_LEN 64 8 2 32
32
Data Structures
#define MAX_TARIFFS 4 #define MAX_CD_LEN MAX_TARIFFS * 4 #define MAX_SC_LEN MAX_TARIFFS * 8 #define MAX_MU_LEN 16 struct extraformat { unsigned char fastselreq; unsigned char restrictresponse, reversecharges; unsigned char pwoptions; unsigned char locpacket, rempacket; unsigned char locwsize, remwsize; int nsdulimit; unsigned char nui_len; unsigned char nui_field [MAX_NUI_LEN]; unsigned char rpoa_len; unsigned char rpoa_field[MAX_RPOA_LEN]; unsigned char cug_type; unsigned char cug_field[MAX_CUG_LEN]; unsigned char reqcharging; unsigned char chg_cd_len; unsigned char chg_cd_field[MAX_CD_LEN]; unsigned char chg_sc_len; unsigned char chg_sc_field MAX_SC_LEN]; unsigned char chg_mu_len; unsigned char chg_mu_field [MAX_MU_LEN]; unsigned char called_add_mod; unsigned char call_redirect; struct lsapformat called; unsigned char call_deflect; unsigned char x_fac_len; unsigned char cg_fac_len; unsigned char cd_fac_len; unsigned char fac_field [MAX_FAC_LEN]; }; The fields in this structure are: CCITT DTE-Facilities Marker
Fast Select
For non-OSI services like X.29, if the X.25 facility fast select is to be requested/indicated the field fastselreq is non-zero. Note: For CONS, the use of fast select need not be requested.
Fast Select with Restricted Response

If the response to a Connect Indication or Request is to be a Disconnect, then the field restrictresponse is non-zero.
33
Reverse Charging
If reverse charging is requested or indicated for a connection, then the field reversecharges is non-zero. Note: The configuration mode bit SUB_REVCHARGE has an impact on whether reverse charging will be indicated since it is possible to select a "per subnetwork status" for receipt of reverse charging.
Packet Concatenation, Packet and Window Size Negotiation

The pwoptions field is used to indicate per circuit options. The field is a bit map with the following interpretation: bit 0: 0 - Packet size negotiation NOT permitted. 1 - Packet size negotiation permitted. bit 1: 0 - Window size negotiation NOT permitted. 1 - Window size negotiation permitted. bit 2: 0 - No concatenation limit asserted. 1 - Assert concatenation limit. This is defined as follows: #define NEGOT_PKT 1 /* packet size negotiable */ #define NEGOT_WIN 2 /* window size negotiable */ #define ASSERT_HWM 4 /* assert concatn limit */ This field is used for two reasons:
The X.25 software will always indicate the values of the window and packet sizes operating on the virtual circuit. However, the field pwoptions for an Incoming call indicates whether these values are negotiable or not. In Connect Requests and Connect Responses the NLI user can set a limit value, nsdulimit, for packet concatenation by the X.25 level which differs from the limit in the subnetwork configuration database. It is not a negotiable option, so that whatever the user has requested is used.
Packet Size Negotiation

If the fields locpacket and rempacket are non-zero, then they contain indicated or negotiated encoded packet sizes, for the directions local-to-remote and remote-to-local, respectively. Note: Actual packet size is 2 to the power of the value employed. #define DEF_X25_PKT 7/* default X.25 packet size */
Window Size Negotiation

If the fields locwsize and remwsize are non-zero, then they contain indicated or negotiated window sizes, for the directions local-to-remote and remote-to-local, respectively. #define DEF_X25_WIN 2 /* default X.25 window size */
34
Data Structures
Packet Concatenation
If the field nsdulimit is non-zero, and the appropriate bit is set in the pwoptions field described above, then the nsdulimit specified is used as the concatenation limit.
Network User Identification

The Network User Identification (NUI) is used in Connect Requests and Responses. It is not available on X.25(80) networks. If the field nui_len is non-zero, then the Network User Identification is supplied in nui_field of length nui_len octets.
RPOA Selection
Recognized Private Operating Agency, used in Connect Requests only. If the field rpoa_len is non-zero, then the RPOA DNIC information is supplied in rpoa_field and is of length rpoa_len semi-octets. For an X.25(80) network this is restricted to one RPOA of length 4 semi-octets. The basic format encoding is used for the RPOA selected. For an X.25(84) or X.25(88) network one or more RPOAs may be selected. The extended format encoding is used only if the number of RPOAs selected is greater than 1. The maximum number of RPOAs which may be selected is restricted to 4. Valid values for rpoa_len are 0, 4, 8, 12 and 16.
Closed User Groups

This field is used in Connect Requests and Indications only. If the field cug_type is non-zero, then the CUG information is supplied right-justified in cug_field. Values for cug_type are: CUG BCUG Closed User Group, up to 4 semi-octets Bilateral CUG (two members only), 4 semi-octets
Note: Incoming Closed User Group facilities are assumed to have been validated by the network. No further checking is performed.
Charging Information
If the field reqcharging is non-zero in a Connect Request or Connect Accept, call charging is requested. In a Disconnect Indication or Disconnect Confirm, the following three fields give the lengths of the charging information: chg_cd_len gives length of chg_cd_field - call duration chg_sc_len gives length of chg_sc_field - segment count chg_mu_len gives length of chg_mu_field - monetary unit A zero length field means no charging information is supplied for the relevant charging category.
35
Called Address Modification

A non-zero called_add_mod field holds the reason for any address modification. Call Redirection A non-zero call_redirect field holds the reason for the call redirection. The field called supplies the originally-called DTE address.
Call Deflection
A non-zero call_deflection field holds the reason for the call deflection. The deflected field in the Disconnect Request contains the DTE address, and if required, the NSAP address that the call is to be deflected to.
Programmable X.25 Facilities

This field is used in Connect Requests and Connect Accepts only. Provision is made for the passing of explicit facility encoded strings for X.25 facilities, and nonX.25 facilities for calling and called networks. The fields x_fac_len, cg_fac_len, and cd_fac_len denote the lengths of the facilities in the field fac_field relating to, respectively, X.25 facilities, non-X.25 facilities for the calling network and non-X.25 facilities for the called network. If a length field is zero this denotes that no facilities are supplied for the corresponding facility category. Note: The contents of this field, if supplied, are not validated or acted upon by the code. The X.25 facilities are inserted at the end of any other X.25 facilities which are passed in the Connect Request/Accept (for example, packet/window sizes). If any non-X.25 facilities are supplied the appropriate marker will be inserted before the supplied facilities.
Listens
The major features of listening are the following:
Any number of processes can listen simultaneously, subject to resource constraints imposed by the system administrator. Moreover, any number of these processes can listen at the same (set of) called addresses. Note that there is no means of listening for a particular calling address. An application can elect to listen and handle one or more Connect Indications at a time. The most likely use of this feature is when the application wants to make use of the following facility: An incoming connection may be accepted on a stream other than the one which received the Connect Indication (the listening stream).
36
Listens
Listening for Incoming Calls

When an application wishes to listen for incoming calls, it can do so in one of two ways: using the standard mode or using the extended mode. As there is the facility for multiple listeners, only one type of listening mode (standard or extended) is allowed at any one time. For the standard mode, the application must specify the (called) address(es) and CUD field values for which it is prepared to accept calls. For the extended mode the called subnetwork ID (SNID) must also be specified. The structure which does this is passed in the data part of a listen request. In the standard mode of operation, the control part of the listen request message is accompanied by a data part containing the addresses to be registered for incoming calls. The data portion is treated as a byte stream of CUD and address(es) conforming to the following definition: unsigned char l_cumode; unsigned char l_culength; unsigned char l_cubytes [l_culength]; unsigned char l_mode; unsigned char l_type; unsigned char l_length; unsigned char l_add[(l_length+1)>>1]; In the extended mode of operation, the data portion is treated as a byte stream of CUD, SNID and address(es) conforming to the following definition: unsigned char l_cumode; unsigned char l_culength; unsigned char l_cubytes [l_culength]; unsigned char l_snmode; unsigned char l_snlen; unsigned char l_snid [l_snlen]; unsigned char l_mode; unsigned char l_type; unsigned char l_length; unsigned char l_add[l_length]; Note: It is important to note that, depending on both the value of the "mode" bytes and the lengths, not all fields need to be present. Refer to the individual field descriptions below for more details.
Standard Mode Listen Request

This section contains the field descriptions for a standard mode listen request
Call User Data Matching

The fields l_cumode, l_culength and l_cubytes are used to match the CUD field of the incoming call, if any, against that specified in the Listen request. l_cumode This field defines the type of matching. Three cases are possible:
37
X25_DONTCARE The listener ignores the CUD - l_culength and l_cubytes are omitted. X25_IDENTITY The listener match is only made if all bytes of the CUD field are the same as the supplied l_cubytes. X25_STARTSWITH The listener match is only made if the leading bytes of the CUD Field are the same as the supplied l_cubytes. The last two are intended to distinguish X.29, say, from other higher level protocols. l_culength This is the length of the CUD in octets for an X25_IDENTITY or X25_STARTSWITH CUD Field match. If l_culength is zero, the l_cubytes are omitted. Currently, the range for l_culength is zero to 16 inclusive. The application still has to check the full CUD Field. This is the string of bytes sought in the call user data field when l_cumode is X25_IDENTITY or X25_STARTSWITH.
l_cubytes
Address Matching
The fields l_mode, l_type, l_length and l_add are used to match the address field(s) of the incoming call against that specified in the Listen request. l_mode X25_DONTCARE The listen ignores the address - l_type, l_length and l_add are omitted. X25_IDENTITY The listener match is only made if all semi-octets of the address are the same as the supplied l_add. X25_STARTSWITH The listener match is only made if the leading semi-octets of the address are the same as the supplied l_add. l_type This is the type of the address entry and can have two values - X25_DTE or X25_NSAP. It denotes the important addressing quantity. For X.25(84) and X.25(88), for example, NSAPs (or extended addresses) are the important addresses while for X.25(80), where there is no NSAP, the DTE is the important quantity. Various applications can be distinguished by X.25 DTE sub-address where necessary. On many X.25(84) and X.25(88) networks, it is possible to listen on either X25_DTE or X25_NSAP addresses. l_length This is the length of the address l_add in semi-octets - the common format for X.25 DTE addresses and NSAPs. If l_length is zero, then l_add is omitted. The maximum values for l_length are 15 for X25_DTE and 40 for X25_NSAP. This contains the address. l_add is omitted when l_length is zero. This field defines the type of matching to be done. Three cases are possible:
l_add
38
Listens
Extended Mode Listen Request

This section contains the field descriptions for an extended mode listen request
Extended Call User Data Matching

The fields l_cumode, l_culength and l_cubytes are used to match the CUD field of the incoming call, if any, against that specified in the Extended Listen request. l_cumode X25_DONTCARE The listener ignores the CUD - l_culength and l_cubytes are omitted. X25_MATCH This indicates that the wildcard characters (* and ?) can be used to match unknown characters in the CUD field. The * matches on any number of characters, including none. The ? matches on any one character. At least one character must be present. The listener match is only made if all bytes of the CUD field are the same as the supplied l_cubytes. This is intended to distinguish X.29, say, from other higher level protocols. This is the length of the CUD in octets for an X25_MATCH Field match. If l_culength is zero, the l_cubytes are omitted. Currently, the range for l_culength is zero to 32 inclusive. The application still has to check the full CUD Field. This is the string of bytes sought in the call user data field when l_cumode is X25_MATCH. This field defines the type of matching. Two cases are possible:
l_culength
l_cubytes
SNID Data Matching

The fields l_snmode, l_snlen and l_snid are used to match the SNID field of the incoming call, if any, against that specified in the Extended Listen request. l_snmode X25_DONTCARE The listen ignores the SNID - l_snlen and l_snbytes are omitted. X25_MATCH This indicates that the wildcards (* and ?) can be used to match unknown characters in the SNID field. The * matches any number of characters, including none. The ? matches on any one character. At least one character must be present.The listener match is only made if all other bytes of the SNID field are the same as the supplied SNID. This is the length of the SNID in octets for an X25_MATCH Field match. If l_snlen is zero, the l_snid is omitted. Currently, the range for l_snlen is zero to four inclusive. The application still has to check the full SNID field. This is the string of bytes sought in the SNID field when l_snmode is X25_MATCH. This field defines the type of matching to be done. Two cases are possible:
l_snlen
l_snid
39
Extended Address Matching

The fields l_mode, l_type, l_length and l_add are used to match the address field(s) of the incoming call against that specified in the Listen request. l_mode X25_DONTCARE The listen ignores the address - l_type, l_length and l_add are omitted. X25_MATCH This indicates that the wildcard characters (* and ?) can be used to match unknown characters in the address field. The * matches any number of characters, including none. The ? matches on any one character. At least one character must be present. The listener match is only made if all the other bytes of the address field are the same as the supplied l_add. This is the type of the address entry and can have two values - X25_DTE or X25_NSAP. It denotes the important addressing quantity. For X.25(84) and X.25(88), for example, NSAPs (or extended addresses) are the important addresses while for X.25(80), where there is no NSAP, the DTE is the important quantity. Various applications can be distinguished by X.25 DTE sub-address where necessary. On many X.25(84) and X.25(88) networks, it is possible to listen on either X25_DTE or X25_NSAP addresses. l_length This is the length of the address l_add in octets - the common format for X.25 DTE addresses and NSAPs. If l_length is zero, then l_add is omitted. The maximum values for l_length are 15 for X25_DTE and 40 for X25_NSAP. This contains the address. l_add is omitted when l_length is zero. This field defines the type of matching to be done. Two cases are possible:
l_type
l_add
Priority
The listen request queue is ordered in terms of the amount of listen data supplied. The more a listen request asks for, the higher its place in the queue. Connect Indications are sent to the listener whose listening criteria are best matched. Privileged users can ask for a request to be placed at the front of the queue, regardless of the amount of listen data supplied. To do this, the listen request should be sent as a M_PCPROTO message. This is achieved by setting the RS_HIPRI flag in MPSputmsg. Such requests are searched in the order in which they arrive. The system administrator controls whether or not listening for incoming calls is a privileged operation. If listening is privileged, incoming calls will only be sent on listen streams opened by a user with superuser privilege. This prevents other users accepting calls which may contain private information, passwords and so on. In systems where privileged and non-privileged listens are allowed:
privileged listens have priority a matching but busy privileged listen prevents a search of any non-privileged listens
40
NLI Message Primitives

The control part of the messages passed across the NLI has a format defined by structures in the following C union. union X25_primitives { struct struct struct struct struct struct struct struct struct struct struct struct struct struct struct xcallf xccnff xdataf xdatacf xedataf xedatacf xrstf xrscf xdiscf xdcnff xabortf xlistenf xcanlisf pvcattf pvcdetf xcall; xccnf; xdata; xdatac; xedata; xedatac; xrst; xrscf; xdisc; xdcnf; abort; xlisten; xcanlis; pvcatt; pvcdet; /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* Connect Request Indication Connect Confirm Response Normal,Q-bit,or D-bit data Data ack Expedited data Expedited data ack Reset Request Indication Reset Confirm Response Disconnect Request Ind Disconnect Confirm Abort Indication Listen Command Response Cancel Command Response PVC Attach PVC Detach */ */ */ */ */ */ */ */ */ */ */ */ */ */ */
}; The above messages have common fields which can be accessed by the following type: typedef struct xhdrf { unsigned char xl_type; /* XL_CTL/XL_DAT */ unsigned char xl_command; /* Command */ } S_X25_HDR; The messages to and from the application are classified into control and data, depending on the value of xl_type which is either XL_CTL (control) or XL_DAT (data). Within each classification, the exact message identity is determined by the xl_command qualifier, and it is important to ensure that the combination of xl_type and xl_command is consistent. Each of these cases is described below.
Connect Request/Indication
The control part of a Connect Request or Indication message has a format defined in the following structure: struct xcallf { unsigned char unsigned char int conn_id; unsigned char unsigned char
xl_type; /* Always XL_CTL xl_command;/* Always N_CI /* Connection id CONS_call; /* CONS call indicator negotiate_qos;/* negotiate qos if
*/ */ */ */ */
41
struct struct struct };
xaddrf calledaddr; xaddrf callingaddr; qosformat qos;
/* /* /* /* /*
set else use defaults The called and calling addresses Facilities & CONS qos if negotiate_qos set
*/ */ */ */ */
This structure is used when calls are requested or indicated across the X.25 interface. The data part of the message contains the call user data (if any). Other components are: conn_id For incoming calls, an attempt is made to match the called address and call user data with that of one of the listening applications. If a match is found, then the indication is passed to that application with a conn_id identifier, which must be returned in the Connect Response or Disconnect Request to accept or reject the connection. For requests, this field, when set, indicates that CONS procedures should be used for the call.
CONS_call
negotiate_qos A non-zero value shows that facilities and quality of service (QOS) are being negotiated. A zero value for the flag means the initiator is requesting all default values. qos calledaddr This structure holds the facilities requested/indicated. See Opening a Connection, on page 51, for more information about QoS negotiation. holds the called address.
callingaddr holds the calling address.
Connect Response/Confirmation
The control part of a Connect Response or Confirmation message is defined in the following structure: struct xccnff { unsigned char unsigned char int unsigned char unsigned char
xl_type; /* xl_command; /* conn_id; /* CONS_call; /* negotiate_qos; /* struct xaddrf responder; /* struct qosformat rqos; /* /*
Always XL_CTL */ Always N_CC */ connection id */ CONS call indicator */ /* negotiate facilities */ else use values */ Responding address */ Facilities &CONS qos */ if negotiate_qos set */
}; This structure is used when calls are being accepted. The data part of the message contains the called user data, if any. The components of the structure are:
42
conn_id
is the connection identifier. conn_id must be returned in the Connect Response so that the procedures described under Listening on page 66 can be guaranteed to operate properly. For responses, this field, when set, indicates that CONS procedures should be used for the call.
CONS_call
negotiate_qos A non-zero value shows that facilities and quality of service (QOS) are being negotiated. A zero value for the flag means the initiator is requesting all default values. responder qos holds the responding address. holds selected facilities and CONS QOS parameters to be passed to the initiator.
Data
The control part of a data message is defined in the following structure: struct xdataf { unsigned char unsigned char unsigned char
xl_type; xl_command; More, setDbit, setQbit;
/* /* /* /* /* /* /* /*
Always XL_DAT Always N_Data Set when more data is required to complete nsdu Set when data carries X.25 D-bit Set when data carries X.25 Q-bit
*/ */ */ */ */ */ */ */
}; This structure is used when data crosses the X.25 interface. The components are: More setQbit setDbit shows whether there is more of this network service data unit to be received/ sent. used to request or indicate that the Q-bit is set when user data is transmitted/ received. used to request or indicate that the D-bit is set when user data is transmitted/ received.
The following M_DATA portion contains the user data. Note: No acknowledgement for this data is given to, or expected from, the application unless the D-bit is set and Application to Application Receipt Confirmation is being used.
43
Data Acknowledgement Request/Indication

This following structure is associated with this message:struct xdatacf { unsigned char xl_type; /* Always XL_DAT */ unsigned char xl_command; /* Always N_DAck */ }; This structure is used when an N-DATA-ACK request or an N-DATA-ACK indication crosses the X.25 interface. When receipt confirmation from the remote application is active on a virtual circuit, this structure is used to acknowledge a previous N-DATA request/indication which had the D-bit set. There is a one to one correspondence between D-bit data and acknowledgements, with one Data Acknowledgement being received/sent for each D-bit data packet sent/received. It is always the oldest outstanding D-bit packet which is being acknowledged. For CONS calls, if receipt acknowledgement has been negotiated on the connection then the above procedures should apply for any D-bit data sent or received. However to be compatible with previous releases of the NLI, the value of the reqackservice field in the qos structure can be set to request that the D-bit signifies receipt confirmation by the remote DTE only, thus ensuring no acknowledgement is expected or given. For non CONS calls, only if the reqackservice field in the qos structure has been set to the appropriate value will the above procedures apply for any D-bit data sent or received. Otherwise no acknowledgement is expected or given.
Expedited Data
The control part of an Expedited Data message has a format defined in the following structure: struct xedataf { unsigned char xl_type; unsigned char xl_command; };
/* Always XL_DAT */ /* Always N_EData */
This structure is used when expedited data, carried by an X.25 INTERRUPT packet, crosses the X.25 interface. No parameters are required. The following M_DATA portion of the message contains the user data. The expedited data is a confirmed primitive and must be acknowledged (see below) before another expedited data unit can be requested or indicated.
44
Expedited Data Acknowledgment

The control part of the Expedited Data Acknowledgment message has a format defined in the following structure: struct xedatacf { unsigned char xl_type; unsigned char xl_command; };
/* Always XL_DAT */ /* Always N_EAck */
This structure is used when expedited data needs to be, or is being, acknowledged. No parameters or user data are required.
Reset Request/Indication
The control part of a Reset Request or an Indication message has a format defined in the following structure: struct xrstf { unsigned charxl_type; unsigned charl_command; unsigned charoriginator, reason cause diag; }; This structure is used when a Reset Request/Indication crosses the X.25 interface. Data is never associated with the primitive. The X.25 cause and diagnostic bytes, cause and diag, are presented as well as the CONS originator and reason codes which are mapped from these. For a Reset Request on a non-CONS call, the user can specify a non-zero cause code. This has no effect for a CONS call; the value is set to zero by the system. Note: A Reset primitive is an acknowledged service (see the associated structure xrscf below). A collision between a Reset Indication and a Reset Request is taken to acknowledge the Reset -- no Reset Confirmation is then required.
/* /* /* /* /* /* /*
Always XL_CTL Always N_RI Originator reason mapped from X.25 cause/diag in indicatns X.25 cause byte X.25 diagnostic byte
*/ */ */ */ */ */ */
45
Reset Response/Confirm
The control part of a Reset Response or Confirm message has a format defined in the following structure: struct xrscf { unsigned char xl_type; /* Always XL_CTL */ unsigned char xl_command; /* Always N_RC */ }; This structure is used when a Reset Confirm or Response to a previous Reset crosses the X.25 interface. There are no parameters or data associated with the primitive. The comments above on reset collision also apply here.
Disconnect Request/Indication
The control part of a Disconnect Request or Indication message has a format defined in the following structure: struct xdiscf { unsigned char unsigned char unsigned char
xl_type; xl_command; originator, reason, cause, diag; conn_id; indicated_qos;
int unsigned char
struct xaddrf responder; struct qosformat rqos;
/* /* /* /* /* /* /* /* /* /* /* /* /* /*
Always XL_CTL Always N_DI Originator reason mapped from X.25 cause/diag in indicatns X.25 cause byte X.25 diagnostic byte connection id (used for reject only) When set, facilities */ indicated CONS responder address Facilities & CONS qos if negotiate_qos set
*/ */ */ */ */ */ */ */ */ */ */ */ */
This structure is used when a Disconnect Request/Indication crosses the X.25 interface. The data part of the message contains the Clear User Data, if any. The X.25 cause and diagnostic bytes, cause and diag, are presented, as well as the CONS originator and reason codes mapped from these. For a Disconnect Request on a nonCONS call, the user can specify a non-zero cause code. This has no effect for a CONS call; the value is set to zero by the system. Other parameters are: indicated_qo A non-zero value shows that facilities and QOS are being indicated. responder This field contains the responding address.
46
deflected
This field is used in conjunction with the call_deflect facility in the qos structure, to convey the address of the remote DTE that the call is to be deflected to. contains the facilities indicated. Currently, this is used with the Charging Information facility and the Call Deflection facility.
qos
The Disconnect Request from an application is confirmed unless it is a rejection of a previous Connect Indication. When it is not a rejection, the X.25 driver sends a Disconnect Confirm to the application when the Clear Confirmation is received. This guarantees that, once the Disconnect Confirm is observed by the application, no more messages are sent on this stream. For this reason, after requesting disconnection, the application should read and discard all messages from the stream until the Disconnect Confirm is received. For call rejection, no acknowledgment is sent. However, the application must supply the connection identifier presented in the Connect Indication so that the appropriate circuit is cleared. In the case of a Disconnect Indication, all messages sent downstream except connect messages are discarded silently. Note: A disconnect collision can occur. If it does, the "acknowledgment" can be taken to be complete.
Disconnect Confirm
The control part of a Disconnect Confirm message has a format defined in the following structure: struct xdcnff { unsigned char xl_type; /* Always XL_CTL*/ unsigned char xl_command; /* Always N_DC*/ unsigned char indicated_qos;/* When set,facilities*/ /* indicated*/ struct qosformat rqos; /* Facilities/CONS qos*/ /* if indicated_qos set*/ }; This structure is used when a Disconnect Confirm crosses the X.25 interface. There is no data associated with this primitive. The components of the structure are: indicated_qos A non-zero value shows that facilities and QOS are being indicated. rqos contains the facilities indicated. Currently, this is only used with the Charging Information facility.
47
Abort Indication
The control part of an Abort Indication message has a format defined in the following structure: struct xabortf { unsigned char xl_type; /* Always XL_CTL */ unsigned char xl_command; /* Always N_Abort */ }; This structure is used when the X.25 driver needs to send a Disconnect to the application but there is no resource available in the system to construct a full Disconnect Indication message. For this reason, this message should rarely be received. Note: This message is only used in the upstream direction - never downstream.
Listen Command/Response
The control part of a Listen Command or Response message has a format defined in the following structure: struct xlistenf { unsigned char xl_type; /* unsigned char xl_command;/* int lmax; /* int l_result; /* };
Always XL_CTL N_Xlisten or N_Xelisten Max # CI's at a time Result flag
*/ */ */ */
This structure is used when an NLI application wants to register interest in incoming calls. The components are: xl_command This is type of Call Requests which the listener wishes to honor. Either a Standard Mode Listen N_Xlisten or the Extended Mode Listen N_Xelisten (See also Listens on page 30). This is the maximum number of Connect Indications which the listener is willing to handle at one time. The data part of the message carries the address(es) in which the listener is interested (See also Listens, on page 36).
lmax
Note: Listen requests are cumulative but the lmax value (number of simultaneously handled Connect Indications) is not. This means that several listen requests can be made on a single stream, in which case the lmax value contained in the last listen message specifies the number of simultaneously handled Connect Indications. l_result The result of the listen request is acknowledged upstream with the same message. An error in the parameters or a lack of resources to set up the listen results in this flag being set to a non-zero value.
For more information, see Listens, on page 36.
48
Listen Cancel Command/Response

The control part of a Listen Cancel Command or Response message has a format defined in the following structure: struct xcanlisf { unsigned char xl_type; /* Always XL_CTL */ unsigned char xl_command; /* Always N_Xcanlis */ int c_result; /* Result flag */ }; This structure is used to cancel an interest in incoming calls. Like the listen message described above, this request is confirmed. In this case, a non-zero value of the c_result flag indicates failure of the operation to cancel a c_result Listen. For example, the Listen was not present or some connect event is outstanding. Naturally, the closure of a stream on which there is a Listen also cancels the Listen, but in the case of the cancel command message, the stream remains open. Note: The Cancel Request removes all listen addresses from the stream. There is no way of cancelling a Listen on a particular address; this message is probably used when the use of the stream is about to be changed by the application.
PVC Attach
The control part of a PVC Attach message has a format defined in the following structure: struct pvcattf { unsigned char xl_type; /* Always XL_CTL */ unsigned char xl_command; /* N_PVC_ATTACH */ unsigned short lci; /* Logical channel */ unsigned long sn_id; /* Subnet identifier */ unsigned char reqackservice;/* Receipt Ack */ /* 0 for next parameter implies use of default */ unsigned char reqnsdulimit; int nsdulimit; int result_code; /* Non-zero - error }; This structure is used when a PVC Attach crosses the X.25 interface. This message is used when a user wants to "attach" to a PVC. The components are: lci sn_id contains the logical channel identifier of the required PVC. denotes the particular subnetwork for the PVC.
*/
reqackservice if non-zero, denotes that the receipt acknowledgement service is requested by use of the D-bit. Setting reqackservice to 1 signifies receipt confirmation by the remote DTE. Setting reqackservice to 2 signifies receipt confirmation by the remote application.
49
In the case of receipt confirmation by the remote DTE, no acknowledgements are expected or given over the X.25 interface. In the case of receipt confirmation by the remote application, there is a one to one correspondence between D-bit data and acknowledgements with one data acknowledgement being received/sent for each D-bit data packet sent/received over the X.25 interface. reqnsdulimit If this is non-zero, look at the field nsdulimit. nsdulimit specifies the packet concatenation limit for NSDUs.
result_code In the attach message sent to the user as acknowledgment, this field denotes whether or not the attach was successful.
PVC Detach
The control part of a PVC Detach message has a format defined in the following structure: struct pvcdetf { unsigned char xl_type; unsigned char xl_command; int reason_code; };
/* Always XL_CTL */ /* Always N_PVC_DETACH */ /* Reports why */
This structure is used when a PVC Detach crosses the X.25 interface. This message is used when a user wants to "detach" from the PVC. This allows the use of the stream to be changed. The Detach message is acknowledged to the user by returning a Detach message, in which the field reason_code denotes whether or not the Detach was successful. This message is also used by the X.25 driver to inform the user of some failure of the PVC. These include link down, remote end not responding and so on. When the message is sent by the X.25 driver, the field reason_code gives the reason for the Detach.
50
Programming Examples
To perform any of the operations described in this section, the application must open a connection to the X.25 PLP Driver using the MPSopen API call. Once the connection, or stream, has been opened it can be used for initiating, listening for, or accepting a connection. There is a one-to-one mapping between X.25 Virtual Circuits and PLP driver Streams. Once a connection has been established on a stream, the stream cannot be used other than for passing data and protocol messages for that connection. The API defines an OpenRequest structure, which the application must supply on input to the MPSopen call. An example is shown below: OpenRequest oreq; strcpy(oreq.serverName, "/dev/ucsclone"); strcpy(oreq.serviceName, "LocalHost"); strcpy(oreq.protoName, "x25"); oreq.ctlrNumber = 0; oreq.port = 0; oreq.dev = 0; oreq.flags = CLONEOPEN; x25_fd = MPSopen(&oreq); For more information about the OpenRequest structure and the MPSopen request, refer to the MPSapi Application Programming Interface Users Manual.
Opening a Connection
To establish an X.25 connection on an open stream, an application must do the following:
1. Allocate a Connect Request structure.
2. Supply the Connect Request with the quality of service and facilities parameters. 3. Set the called (and optionally calling) addresses. 4. Pass the Connect Request down to the X.25 Driver. 5. Wait for the connect confirmation or rejection. Note: A Connect Request cannot be issued on a listening stream. The following sections describe the procedures for opening a connection for a CONS call and for a non-CONS call, respectively.
51
CONS Calls
The following example opens a connection for a CONS call: #define FALSE #define TRUE 0 1
#include <memory.h> #include <sys/snet/x25_proto.h> struct xaddrf called = { 0, 0, {14, { 0x23, 0x42, 0x31, 0x56, 0x56, 0x56, 0x56 }}, 0}; /* Subnetwork "A" (filled in later), no flags, * DTE = "23423156565656", null NSAP */ struct xcallf conreq;
/* Convert sn_id to internal format */ called.sn_id = snidtox25("A"); /* snidtox25 only fails if a * NULL string is passed to it */ conreq.xl_type = XL_CTL; conreq.xl_command = N_CI; conreq.CONS_call = TRUE; /* This is a CONS call conreq.negotiate_qos = TRUE; /* memset(&conreq.qos, 0, sizeof(struct conreq.qos.reqexpedited = TRUE; /* conreq.qos.xtras.locpacket = 8; /* conreq.qos.xtras.rempacket = 8; /*
*/
Negotiate requested */ qosformat)); Expedited request */ 256 bytes */ 256 bytes */
memcpy(&conreq.calledaddr, &called, sizeof(struct xaddrf)); memset(&conreq.callingaddr, 0, sizeof(struct xaddrf)); Note: When negotiate_qos is true (non-zero), setting the QOS fields to zero means that the connection uses defaults for QOS and Facilities. If required, these can be set to different values but it is recommended that the whole QOS structure be zeroed first as shown. This is preferable to setting each field individually, as it allows for any future additions to this structure. Setting the calling address to null leaves the network to fill this value in. The message is then sent on the stream using the MPSputmsg API call, with any call user data being passed in the data part of the message: #define CUDFLEN 4 struct xstrbuf ctlblk, datblk;
52
char
cudf[CUDFLEN] = { 1, 0, 0, 0 }; = = = = sizeof(struct xcallf); (char *) &conreq; CUDFLEN; cudf;
ctlblk.len ctlblk.buf datblk.len datblk.buf
if (MPSputmsg(x25_fd, &ctlblk, &datblk, 0) < 0 ) { MPSperror("Call MPSputmsg"); exit(1); } At this stage, the application should wait for a response to the call request. The response may be either a Connect Confirmation or a Disconnect (rejection) message. #define #define DBUFSIZ CBUFSIZ 128 MAX(sizeof(struct xccnff), sizeof(struct xdiscf))
int S_X25_HDR char
getflags = 0; *ind_msg; ctlbuf[CBUFSIZ], datbuf[DBUFSIZ];
struct xccnff *ccnf; struct qosformat qos; ctlblk.maxlen ctlblk.buf datblk.maxlen datblk.buf = = = = CBUFSIZ; ctlbuf; DBUFSIZ; datbuf;
for(;;) { if (MPSgetmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) { MPSperror("MPSgetmsg fail"); exit(1); } ind_msg = (S_X25_HDR *) ctlbuf; if (ind_msg->xl_type != XL_CTL) continue; switch (ind_msg->xl_command) { case N_CC: /* Process the Connect Confirmation */
53
ccnf = ((struct xccnff *) ind_msg; if (ccnf -> negotiate_qos ) { bcopy (&qos, ccuf->qos, sizeof (struct qosformat)); if (qos -> reqexpedited ) printf("Request Expedited set n"); else printf("Request Expedited not set n"); } else { /* } return; case N_DI: MPSperror("Connection rejected"); exit(1); default: continue; } } In the example, MPSgetmsg is used to retrieve the next message from the stream head. This is done in a loop, until either a Connect Confirm message, indicating successful completion, is received, or a Disconnect Indication, showing that the connect attempt was rejected. Note: The facility and QOS values indicated in the Connect Confirmation are those that are used for the duration of the connection. It is possible to abort the connect request before a response is received. The application can do this by sending a Disconnect Request message (see Closing a Connection, on page 63). If this is done, the application should read and discard all messages from the stream until it receives the disconnect acknowledgement (described in Disconnect Request/Indication, on page 46). After a rejection or connect abort the stream remains open, and can be used, for example, to make further connection attempts. indicated values have been accepted */
54
Non-CONS Calls
The following example opens a connection for a non-CONS call: #define FALSE #define TRUE 0 1
#include <memory.h> #include <sys/snet/x25_proto.h> struct xaddrf called = { 0, 0, { 14, { 0x23, 0x42, 0x31, 0x56, 0x56, 0x56, 0x56 }}, 0 }; /* Subnetwork "A" (filled in later), no flags, * DTE = "23423156565656", null NSAP */ struct xcallf conreq;
/* Convert sn_id to internal format */ called.sn_id = snidtox25("A"); conreq.xl_type = XL_CTL; conreq.xl_command = N_CI; conreq.CONS_call = FALSE;/* Not a CONS call */ conreq.negotiate_qos = FALSE;/* Just use default */ memset(&conreq.qos, 0, sizeof(struct qosformat)); memcpy(&conreq.calledaddr, &called, sizeof(struct xaddrf)); memset(&conreq.callingaddr, 0, sizeof(struct xaddrf)); Note: When negotiate_qos is true (non-zero), setting the QOS fields to zero means that the connection uses defaults for QOS and Facilities. If required, these can be set to different values (see Quality of Service and X.25 Facilities, on page 29, and Connect Request/Indication, on page 41 for more details), but it is recommended that the whole QOS structure be zeroed first, as shown. This is preferable to setting each field individually, as it allows for any future additions to this structure. Setting the calling address to null leaves the network to fill this value in.
55
The message is sent on the stream using the MPSputmsg API call, with any call user data being passed in the data part of the message: #define CUDFLEN 4 struct strbuf char ctlblk, datblk; cudf[CUDFLEN] = { 1, 0, 0, 0 };
ctlblk.len = sizeof(struct xcallf); ctlblk.buf = (char *) &conreq; datblk.len = CUDFLEN; datblk.buf = cudf; if (MPSputmsg(x25_fd, &ctlblk, &datblk, 0) < 0 ) { MPSperror("Call MPSputmsg"); exit(1); }
Data Transfer
In the data transfer phase, access is given to:
The Q-bit - to support X.29-like services The M-bit - to signal packet fragmentation The D-bit - to request confirmation of data delivery Expedited data - to support X.29 and CONS.
Normal and Q-bit data is sent and received using the N_Data message and may be acknowledged using the N_DAck message. Expedited data uses the N_EData message, and is acknowledged using an N_EAck message. The following sections show examples of code for data transfer.
56
Sending Data
Once a connection has been successfully opened on a stream, sending a data packet is straightforward: #define DBUFSIZ 128 struct xdataf char int data; datbuf[DBUFSIZ]; retval;
/* Copy data into datbuf[] here */ data.xl_type = XL_DAT; data.xl_command = N_Data; data.More = data.setQbit = data.setDbit = FALSE; ctlblk.len ctlblk.buf datblk.len datblk.buf = = = = sizeof(struct xdataf); (char *) &data; DBUFSIZ; datbuf;
retval = MPSputmsg(x25_fd, &ctlblk, &datblk, 0); Normally, the call to MPSputmsg flow control blocks if there are flow control conditions in the connection which lead to either a full queue at the stream head, or a lack of STREAMS resources. Blocking due to a full queue can be avoided if the stream is opened with the option O_NDELAY flagged. In this case, MPSputmsg returns immediately, and the failure is signalled by a return value (retval) of EAGAIN. This procedure allows the application to carry out other processing (for example, receiving data) before trying again. The best method to use depends on the nature of the application.
57
Receiving Data
In the same way, data reception is straightforward. When data is received with the D-bit set, action may be required by the application. When the initial Call Request is sent, it may request that data confirmation be at the application-to-application level. If application to application confirmation is agreed upon, then on receiving a packet with the D-bit set, it must be acknowledged by sending a Data Acknowledgement (N_DAck) message. This example prints out incoming data as a string, if the Q-bit is not set: S_X25_HDR struct xdataf struct xdatacf *hdrptr; *dat_msg; *dack;
for(;;) { if (MPSgetmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) { MPSperror("MPSgetmsg fail"); exit(1); } hdrptr = (S_X25_HDR *) ctlbuf; if (hdrptr->xl_type == XL_CTL) { /* Deal with protocol message as required see below */ } if (hdrptr->xl_type == XL_DAT) { dat_msg = (struct xdataf *) ctlbuf; switch (dat_msg->xl_command) { case N_Data: if (dat_msg->More) printf("M-bit set n"); if (dat_msg->setQbit) printf("Q-bit set n"); else { if (dat_msg->setDbit) printf("D-bit set n"); for (i = 1;i<datblk.len; i++) printf("%c", datbuf[i]); /*
58
* If application to application * Dbit confirmation was negotiated * at call setup time, * send an N_DAck */ if (app_to_app && dat_msg->setDbit) { dack = (struct xdatacf *) malloc(sizeof(struct xdatacf)); bzero((char *)dack, sizeof(struct xdatacf)); dack->xl_command = N_DAck; dack->xl_type = XL_DAT; ctlblk->len = sizeof(struct xdatacf); ctlblk->buf = (char *)dack;
datblk->len = 0; datblk->buf = (char *)0; MPSputmsg(x25_fd, &ctlblk, &datblk, &getflags); } } break; case N_EData: printf("***Expedited data received n"); /* Must deal with */ break; case N_DAck: printf("***Data Acknowledgement received n"); break; default: break; } } }
59
Expedited Data
The above example allows for the possibility of receiving expedited data messages (which are carried in X.25 interrupt packets). These must be dealt with appropriately. Since only one expedited data packet can be outstanding in the connection at any time, its sender is prevented from sending any further such messages until the receiver has acknowledged it. It does this by sending an Expedited Acknowledgement (Eack) message. This is sent in much the same way as an ordinary data packet, but with no data part. If the application does not need to use the expedited data capability, then other appropriate responses to receiving an EData message are to reset or close the connection (See Resets, on page 62, and Closing a Connection, on page 63). When sending expedited data, the application must wait for an acknowledgement before requesting further expedited transmissions. #include #define <sys/net/x25_proto.h> EXPLEN 4
struct xedataf exp; char expdata[]= {1, 2, 3, 4}; exp.xl_type = XL_DAT; exp.xl_command = N_EData; ctlblk.len = sizeof (struct xedataf); ctlblk.buf = (char *) &exp; datblk.len = EXPLEN; datblk.buf = expdata; if (MPSputmsg(x25_fd, &ctlblk, &datblk, 0) < 0) { error("Exp MPSputmsg"); exit(1); } for (;;) { if (MPSgetmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) { MPSperror("MPSgetmsg fail"); exit(1); } hdrptr = (S_X25_HDR *) ctlbuf; if (hdrptr->xl_type == XL_CTL) { /* Deal with protocol message as required } if (hdrptr->xl_type == XL_DAT) {
*/
60
dat_msg = (struct xdataf *) ctlbuf; switch (dat_msg->xl_command) { case N_Data: /* process more data break; case N_EData: printf("***Expedited data received n"); /* Must deal with */ .... send N_EAck.... break; case N_EAck: /* Expedited data received */ /* Further N_Edata can now be sent */ break; default: break; } }
*/
61
Resets
These can be dealt with in a similar way to interrupts, except that there is no data passed with a Reset Request. When a Reset Request is issued, the application must wait for the acknowledgement, as for an expedited request. However, until this is received, the only action which can be taken is to issue a Disconnect Request. The diagnostic field in a Reset Request should be filled in with the reason for issuing the reset. Standard values for this are defined in the include file <sys/snet/x25_proto.h>, although the application can set any value. When a Reset Indication is received, there are only two valid actions that may be taken:
Send a Reset Confirmation message to acknowledge the reset. Send a Disconnect Request. In this situation, pending data is flushed from the queue.
Reset Indications can be dealt with as part of the general processing of incoming messages, see the Disconnect handling example below. #include struct xrstf S_X25_HDR rst.xl_type rst.xl_command rst.cause rst.diag ctlblk.len ctlblk.buf <sys/snet/x25_proto.h> rst; *hdrptr; = = = = XL_CTL; N_RI; 0; NU_RESYNC;
= sizeof (struct rstf); = (char *) &rst;
if (MPSputmsg(x25_fd, &ctlblk, 0, 0) < 0) { MPSperror(" putnmsg"); exit(1); } for (;;) { if (MPSgetmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) { MPSperror("MPSgetmsg fail"); exit(1); } hdrptr = (S_X25_HDR *) ctlbuf; if (hdrptr->xl_type == XL_CTL) { continue; }
62
switch (hdrptr->xl_command) { case N_RC: /* /* Reset complete */ Enter data transfer
*/
break; default: break; } } Control messages like resets and interrupts take higher priority than normal data messages, both internally in the PLP driver, and across the network. However, it is important to note that the NLI does not use the mechanism for priority processing of STREAMS messages (by setting the RS_HIPRI flag in MPSputmsg). There are two reasons for this:
The stream head can only hold one incoming priority message (the first). This is inappropriate in certain situations where several of these messages may follow each other in quick succession. For example, a Reset may be followed immediately by a Disconnect. An outgoing priority message would overtake any data which is queued waiting to be sent. It is possible that data could then be sent after the priority message (for example, a reset), which would lead to an NLI protocol violation.
Closing a Connection
This section covers remote and local disconnects.
Remote Disconnect
If, during a connection, the remote end initiates a Disconnect, then a Disconnect Indication (N_DI) message (or possibly an N_Abort message - see Abort Indication on page 48) is received at the NLI. The application need not acknowledge this message since, after sending a Disconnect, the X.25 driver silently discards all messages received except for connect and accept messages. These are the only meaningful X.25 messages on the stream after disconnection. The receiver of a Disconnect Indication should ensure that enough room is available in the MPSgetmsg call to receive all parameters and, when present, up to 128 bytes of Clear User Data. Handling such a Disconnect event would normally be part of the general processing of incoming messages. The example which follows could be combined with the code from the data transfer example shown above. struct xdiscf *dis_msg;
63
if (hdrptr->xl_type == XL_CTL) { switch (hdrptr->xl_command) { /* Other events/indications dealt withhere * - e.g. Reset Indication (N_RI) */ case N_DI: dis_msg = (struct xdiscf *) hdrptr; printf("Remote disconnect, cause = %x," "diagnostic = %x n", dis_msg->cause, dis_msg->diag); /* Any other processing needed here * - e.g. change connection state */ return; case N_Abort: printf("***Connection Aborted n"); /* etc. */ return; default: break; } } Note: It is guaranteed that no X.25 interface messages are sent to the application once a disconnect message has been passed up to it, wherever the message came from (that is, it can be a Disconnect Indication or the 'response' described in Local Disconnect, on page 64). Although at this stage the stream is idle, it is in an open state and remains so until some user action. This could be to close the stream, or to initiate a new Listen or Connect request on it.
Local Disconnect
To initiate a Disconnect on a connection, the application should send a Disconnect Request (N_DI) message on the stream. Unless this is being used to reject an incoming call (See Handling the Connect Indication, on page 69), the X.25 driver signals that it has observed the message. It does this by sending a Disconnect Confirm upstream when it receives the Clear Confirm. In this way, the upper components can be certain that no messages will follow the Disconnect. In the case of rejection, the connection identifier supplied on the Connect Indication must be returned in the disconnect message. The disconnect (reject) is not acknowledged in this case.
64
As in the case of a remote disconnection, once the response has been received the stream becomes idle, and remains in this state until the application sends out another control message. This may be to close the stream, or to initiate a new Listen or Connect request on it. The application should, however, not send any of these messages until it receives the Disconnect Response. As described in Disconnect Request/Indication, on page 46, a disconnect collision may occur. If this happens, no Disconnect Confirm is sent. /* Coded ans sent disconnect request, process response */ struct xdiscf *dis_ind; struct xdcnff *dis_cnf; struct extraformat *xqos = (struct extraformat *)0; if ( hdrptr->xl_type == XL_CTL ) { switch( hdrptr->xl_command ) { /* Disconnect Collision */ case N_DI: dis_ind = (struct xdiscf*)hdrptr; xqos = &dis_ind->indicatedqos.xtras; break; /* Disconnect Confirmation */ case N_DC: dis_cnf = (struct xdcnff*)hdrptr; xqos = &dis_cnf->indicatedqos.xtras; break; default: return; } if ( xqos ) { /* * Print any charging information returned */ if ( xqos->chg_cd_len ) { /* Print out Call Duration from chg_cd_field */ }
65
if ( xqos->chg_mu_len ) { /* Print out Monetary Unit from chg_mu_field */ } if ( xqos->chg_sc_len ) { /* Print out Segment Count from chg_sc_field */ } } }
Listening
For more information about listening, see Listens, on page 36.
Listening for Incoming Connections

Before an incoming call can be received from the X.25 driver, there must be (at least) one listener. Moreover, as mentioned in Priority, on page 40, listening for incoming connections may be a privileged operation - that is, the stream must have been opened by a process with superuser privilege. To listen for and open an incoming connection, the application should do the following:
1. Send an N_Xlisten message carrying the called address list in which the application is interested to the X.25 driver (see Listens, on page 36). After this, wait for the response to the Listen Request.
2. When the listen response is received (and the l_result flag indicates success), wait for Connect Indication messages from the X.25 driver. If the l_result flag indicates failure, the application can decide either to close the stream or to try again later. 3. When a Connect Indication is passed up, the application can decide whether to accept on this or a different stream. 4. At this point, the facilities and QOS are negotiated if required. A Connect Confirmation message carrying the appropriate connection identifier is then passed down on the stream on which the connection is being accepted.
Constructing the Listen Message

As described in Listens, on page 36, the listen message has two parts. The construction of the control part of the message is straightforward: struct xlistenf lisreq;
lisreq.xl_type = XL_CTL; lisreq.xl_command = N_Xlisten; lisreq.lmax = 1;
66
In this example, lmax has the value of 1, indicating that only one Connect Indication is to be handled at a time. The data part of the message should be filled with the sequence of bytes which specifies the Call User Data string and address(es) which are to be listened for. The simplest case for this would be to set DONTCARE values for both the CUD and address: int lislen; char lisbuf[MAXLIS]; /* l_cumode /* l_mode */ */
lisbuf[0] = X25_DONTCARE; lisbuf[1] = X25_DONTCARE; lislen = 2;
Alternatively, to set the CUD to match exactly the (X.29) value defined in the array cudf [ ] earlier (0x01000000), and the NSAP to match any sequence starting 0x80, 0x00, the following would be used: lislen = 0; lisbuf[lislen++] = X25_IDENTITY; /* l_cumode lisbuf[lislen++] = CUDFLEN; /* l_culength memcpy(&(lisbuf[lislen]), cudf, CUDFLEN); /* l_cubytes lislen += CUDFLEN; */ */ */
lisbuf[lislen++] = X25_STARTSWITH; /* l_mode */ lisbuf[lislen++] = X25_NSAP; /* l_type */ lisbuf[lislen++] = 4; /* l_length */ lisbuf[lislen++] = 0x80; /* l_add */ lisbuf[lislen++] = 0x00; Or, to accept any CUD Field, with a DTE of "2342315656565": #define MY_DTE_LEN 13 #define MY_DTE_OCTETS 7 char my_dte[MY_DTE_OCTETS] = {0x23, 0x42, 0x31, 0x56, 0x56, 0x56, 0x50}; lislen = 0; lisbuf[lislen++] = X25_DONTCARE; /* l_cumode */ lisbuf[lislen++] = X25_IDENTITY; /* l_mode */ lisbuf[lislen++] = X25_DTE; /* l_type */ lisbuf[lislen++] = MY_DTE_LEN; /* l_length */ memcpy(&(lisbuf[lislen]), my_dte, MY_DTE_OCTETS); /* l_add */
67
lislen += MY_DTE_OCTETS; Note: The l_add field uses packed hexadecimal digits and the l_length value is actually the number of semi-octets whereas the l_culength field specifies the length of the l_cubytes field in octets. Next, send the Listen Request down the open stream: ctlblk.len = sizeof(struct xlistenf); ctlblk.buf = (char *) &lisreq; datblk.len = lislen; datblk.buf = lisbuf; if (MPSputmsg(x25_fd, &ctlblk, &datblk, 0) < 0) { MPSperror("Listen MPSputmsg failure"); return -1; } Finally, wait for the listen response - the result flag indicates success or failure: #define DBUFSIZ 128 #define CBUFSIZ MAX(sizeof (struct xccnff), sizeof (struct xdiscf)) struct xlistenf *lis_msg; /* See above for declarations */ ctlblk.maxlen = CBUFSIZ; ctlblk.buf = ctlbuf; datblk.maxlen = DBUFSIZ; datblk.buf = datbuf; for(;;) { if (MPSgetmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) { MPSperror("Listen MPSgetmsg failure"); return -1; } lis_msg = (struct xlistenf *) ctlbuf; if ((lis_msg->xl_type == XL_CTL) && (lis_msg->xl_command == N_Xlisten)) { if (lis_msg->l_result != 0)
68
{ printf("Listen command failed n"); return -1; } else { printf("Listen command succeeded n"); return 0; } } } Cancelling a Listen Request can be done in the same way, except that no data is passed with the request - it simply cancels all successful Listens which have been made on that stream.
Handling the Connect Indication

Once the listening application has received a Listen Response indicating success, it should wait for incoming Connect Indications. When an N_CI message arrives, the application should inspect its parameters - address, call user data, facilities, quality of service and so on, then decide whether to accept or reject the connection:
Acceptance
If accepting, it can do so either on the stream the indication arrived on, or on some other stream. This other stream can be one which is already open and free, or it can be newly opened. Whatever method is used for the accept, the identifier conn_id in the Connect Indication message must be copied into the accept message for matching by the X.25 driver. If this identifier in the accept message does not match, a Disconnect is sent to the accepting application. This causes the resource to hang on the stream on which the incoming call was sent, since the connection is never accepted. Note: The application must not accept a connection on a listening stream which is capable of handling more than one Connect Indication at one time if there could subsequently be other Connect Indications to be handled on that stream. For example, the application issues a Listen Request to handle three Connect Indications at one time. A Connect Indication is received and sent to the application on the listen stream. The application must not accept this connection on the listen stream because there could be two more Connect Indications which can be sent subsequently.
Rejection
The call can be rejected by sending an N_DI message down the stream on which the Connect Indication arrived. A Connect Indication cannot be rejected on a different stream. Again, the connection identifier must be quoted in the message for matching, since there may be several Connect Indications passed to the listening application. If there is no match for the rejection, the message is silently discarded.
69
The rejecting listener can request one of two actions in response to the disconnect:
Request immediate disconnect. Set the reason field to NU_PERMANENT (0xF5). Search for further matching listeners. Set the reason field to any value except 0xF5.
The following code example shows how to reject an incoming call:
struct xcallf struct xdiscf
*conind; disc_msg;
/* Use MPSgetmsg to receive the Connect Indication * use conind to point to it */ disc_msg.xl_type = XL_CTL; disc_msg.xl_command = N_DI; disc_msg.conn_id = conind->conn_id; disc_msg.cause = cause; /* cause to be returned */ disc_msg.diag = diag; /* diagnostic to be returned */ if (disc_immed) /* no more searches disc_msg.reason = NU_PERMANENT; /* 0xF5 /* Send Rejection down stream with MPSputmsg */ */ */
Negotiation
The Connect Indication message passed contains X.25 facility values, and CONS QOS parameters, if appropriate. The application may want to negotiate these values. This is done by setting the negotiate_qos flag in the Connect Response message. The values received should then be copied into the response, and those facilities and/or parameters (and any related flags) for which a different value is desired should then be altered (See Quality of Service and X.25 Facilities, on page 29). It is recommended that the whole QOS structure be copied from the indication to the response. This is preferable to copying each field individually, as it allows for any future additions to this structure. An example of negotiation is shown below. Here all the values are copied as indicated, except the packet size, which is negotiated down to 256 if it is flagged as negotiable, and is greater than 256: struct xcallf struct xccnff *conind; conresp;
/* Do an MPSgetmsg etc to receive the Connect Indication, * assign conind to point to it. */ conresp.xl_type = XL_CTL; conresp.xl_command = N_CC;
70
conresp.conn_id = conind->conn_id; /* Connection identifier */ conresp.CONS_call = TRUE/* This is a CONS call */ memset(&conresp.responder, 0, sizeof(struct xaddrf)); /* Let network fill in responding addr */ conresp.negotiate_qos = TRUE; memcpy(&conresp.rqos, &conind->qos, sizeof(struct qosformat)); if (conind->qos.xtras.pwoptions & NEGOT_PKT) { if (conind->qos.xtras.rempacket > 8) conresp.rqos.xtras.rempacket = 8; /* 256 = 2 8 */ if (conind->qos.xtras.locpacket > 8) conresp.rqos.xtras.locpacket = 8; } /* Set any other values to be negotiated here, * then send the response down with an MPSputmsg. */ Alternatively, the application may decide to accept (agree with) the indicated values, in which case the negotiate_qos flag is set to zero.
Re-Using the Listen Stream

If a connection is never established on a listening stream (using a matching accept) then that stream remains listening on the address list supplied. On the other hand, once an established connection has been disconnected, the stream does not return to a listening state. Instead, it remains open in an idle state. If the application needs to listen again, then the listen message must be re-sent. Rejection does not alter the listening state of the stream.
PVC Operation
The following subsections describe the procedures necessary for an application to operate a PVC on the X.25 PLP Driver.
Attaching a PVC
To attach a PVC on an open stream, an application must:
Allocate a PVC_attach structure. Supply the structure with the appropriate reqackservice and reqnsdulimit parameters. These parameters are used for the duration of the connection. Set the appropriate subnetwork and logical channel identifiers. Pass the attach request down to the X.25 Driver. Wait for the attach accept or rejection.
71
For example: #include <sys/stropts.h> #include <sys/snet/x25_proto.h> struct pvcattf attach = { XL_CTL, N_PVC_ATTACH, 1, 0, 0, 0, 0 }; /* Subnetwork "A" (filled in later), Logical Channel 1 * No request for Receipt Ack or nsdulimit */ struct strbuf ctlblk; /* Convert sn_id to internal format */ attach.sn_id = snidtox25("A"); ctlblk.len = sizeof(struct pvcattf); ctlblk.buf = (char *) &attach; The message is then sent on the stream using the MPSputmsg API call: if (MPSputmsg(x25_fd, &ctlblk, 0, 0) < 0) { MPSperror("Attach MPSputmsg"); exit(1); } At this stage, the application should wait for a response to the attach. The response may indicate either a successful attachment or a rejection. #define #define DBUFSIZ CBUFSIZ 128 sizeof(struct pvcattf)
int struct pvcattf char ctlblk.maxlen ctlblk.buf datblk.maxlen datblk.buf = = = =
getflags; *ind_msg; ctlbuf[CBUFSIZ], datbuf[DBUFSIZ]; CBUFSIZ; ctlbuf; DBUFSIZ; datbuf;
for(;;) { if (MPSgetmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) { MPSperror("MPSgetmsg fail"); exit(1); } ind_msg = (struct pvcattf *) ctlbuf; if (ind_msg->xl_type != XL_CTL)
72
continue; switch (ind_msg->xl_command) { case N_PVC_ATTACH: { switch (ind_msg->result_code) { case PVC_SUCCESS: /* ...... Process the attach */ return(1); case case case case { PVC_NOSUCHSUBNET: PVC_CFGERROR: PVC_PARERROR: PVC_BUSY:
/* ...... Process the reject */ return(0); } default: { printf("Unknown PVC message n"); exit(1); } } } } } In this example, MPSgetmsg is used to retrieve the next message from the stream head. This is done in a loop, until either the attach is confirmed successful or rejected. Although the processing of the attach is not shown here, it is recommended that the application sends a Reset Request (See Reset Request/Indication, on page 45) and waits for the Reset Confirm (See Reset Response/Confirm, on page 46) before proceeding with the data transfer. The example given in Resets, on page 62, shows the code used to send a Reset and handle the acknowledgement. This synchronizes the X.25 PLP drivers at each end of the PVC. The example does not illustrate all possible result_code cases. It is possible to abort the Attach Request before a response is received. The application can do this by sending a Detach Request message (See Detaching a PVC, on page 74 below). If this is done, the application should read and discard all messages from the stream until it receives the detach acknowledgement.
73
After a rejection or an attach abort the stream remains open and can be used, for example, to make further attach attempts.
PVC Data Transfer

The transfer of data over a Permanent Virtual Circuit is exactly the same, to the application, as for Virtual Circuits. Refer to Data Transfer, on page 56, for a description of the procedures involved.
Detaching a PVC
The procedure used to detach a PVC differs for the remote and local cases, so these are described separately here:
Remote Detach
If, during a connection, the remote end initiates a detach, then a Reset Indication (See Reset Request/Indication, on page 45) message is received at the NLI. The application should acknowledge this with a Reset Response (See Reset Response/Confirm, on page 46). Handling such an event would normally be part of the general processing of incoming messages. After sending the Reset Response, the application is still attached to its PVC and remains so until it initiates a local detach.
Local Detach
To initiate a detach on a connection, the application should send a Detach Request (N_PVC_DETACH) message on the stream. The X.25 driver signals that it has observed the message by sending a Detach upstream. In this way, the upper component can be certain that no messages follow the Detach. For example: struct pvcdetf detach = { XL_CTL, N_PVC_DETACH, 0 }; ctlblk.len = sizeof(struct pvcdetf); ctlblk.buf = (char *) &detach; if (MPSputmsg(x25_fd, &ctlblk, 0, 0) < 0) { MPSperror("Detach MPSputmsg"); exit(1); } As is the case for a Remote Detach, once the response has been received the stream becomes idle. It enters an open state, in which it remains until the application commands otherwise. This could be to close the stream, or to initiate a new Attach Request on it. The application should, however, wait until it receives the Detach Response.
74
Chapter 4
X.25 Network Managers Guide
Overview
This chapter is intended to provide information to assist the Network Manager in the configuration of the X.25 network. It is assumed that the network manager is a familiar with ISO 8208, X.25 Packet Level Protocol for Data Terminal Equipment. Key topics in this chapter include:
Network Control Functions, on page 75 discusses the Network Control functions and a sample application
that utilizes the dynamic daemon, dnetd.
V.25bis Compliant Modem Support, on page 88 discusses the support for ITU-T V.25bis compliant
modems.
Network Utilities, on page 91 provides descriptions of the Network Utility programs. Network Libraries, on page 108 provides descriptions of the Network Library functions and their structures. Network Files, on page 116 provides templates of the Network Files including a description of each
configuration parameter.
Miscellaneous, on page 140 contains miscellaneous support files needed to configure the network. Special Files, on page 141 defines the design goals of the lapb and x25 STREAMS network layer
multiplexor-drivers.
Network Control Functions

This section defines a collection of functions called the Network Control functions. In addition, it discusses an application that uses these functions to communicate with the dnetd program in order to control when the link (lapb) layer is established. The application demonstrates how the dnetd program functions as the X.25 network control daemon. The dnetd program is an alternative to the netd program and its netconf configuration file. Most users prefer to use netd and allow the server to control the link layer. If your application does not need to control the link layer, you do not need the information in this section.
DNETD and NETD

To introduce this approach to network control, it is helpful to briefly discuss the netd program. The netd program reads the netconf file and issues ioctls to create the X.25 protocol stack on the server. The stack consists of three layers: the packet layer (X25), the link layer (LAPB), and the WAN layer. In addition, netd configures each layer of each subnetwork by invoking the configuration utilities with the configuration files specified by the netconf file. When netd reads the X25_SET_SNID command in the netconf configuration file, it sends an N_snident ioctl, which causes the server to send a series of messages between the protocol stack layers. One of these messages is a registration message to the WAN layer which causes the WAN layer to examine the WAN_auto_start configuration parameter. This parameter is
75
defined in the WAN configuration file. (The netd program invokes the wantune program which sends the file to the server.) If the parameter is YES, the WAN layer asserts the request to send modem signal. If the WAN sees the clear to send and carrier detect modem signals, it notifies the protocol layers above it. This causes the LAPB layer to try to bring up the link. As a rule, this happens before any packet layer applications are running. The lapb software attempts to maintain communications at the link layer regardless of whether any applications are running or not. Some applications require control over the link layer, that is, they need to control when the link layer is brought up. These applications do not want the server to try to bring up the link layer after the X25_SET_SNID. Both the netd and dnetd programs function as X.25 network daemons, i.e., when they are executed, they do not exit. Unlike the netd program, the dnetd program does not read a configuration file. Instead, it accepts messages from your application which cause it to send the messages to the server which create and configure the X.25 protocol stack on the server. Your application must be linked with the Network Control (NC) software and the Interprocess Communications (IPC) software. The Interprocess Communications method is currently only supported in the System V UNIX environment (including Solaris) and the Windows environment. The X.25 protocol stack is created on the server when your application makes calls to the Network Control functions which make calls to the Interprocess Communications functions which send messages to the dnetd program. This X.25 software distribution includes a program that causes the X.25 protocol stack to be created on the server and causes the defined subnetworks to be configured. In addition, two other programs are provided: one that brings up two specified subnetworks and one that takes down two specified subnetworks. These programs are discussed later. In order for your application to control the link layer, you must set the WAN configuration parameter, WAN_auto_start, to N, i.e. no. When your application calls the Network Control software to have an N_snident ioctl issued, the server does not try to bring up the link. Instead, it waits for a W_ENABLE ioctl. When the server sees the W_ENABLE it asserts the request to send modem signal and waits for the clear to send and carrier detect modem signals to be asserted by the modem. When these modem signals are present, the server tries to bring up the link. When the link is up, the application can set up a call and transfer data across an X.25 virtual circuit. When the data transfer is complete, the application calls the Network Control software to issue a W_DISABLE ioctl. This causes the server to take down the link. These controls are available for each subnetwork. Note: T1/E1 embedded controllers (PCI37xPQ, CPC37xPQ, and PMC37x controllers) have specific configuration parameters that may be modified via the QMC configuration utility discussed in Chapter 4, QMC Configuration Guide, of the MPS Software and Hardware Installation Manual. If you are satisfied with the default values for these parameters, you will not need to run the QMC configuration utility, and may proceed to run netd or dnetd. However, if you need to modify the defaults for these parameters, you must run the QMC configuration utility prior to running netd or dnetd.
76

The Network Control (NC) software is a collection of functions which provide a means by which an application can communicate with the dnetd X.25 network control daemon. Any application wishing to use this interface must link in the NC and Interprocess Communication (IPC) software. The dnetd network daemon does not support access to it by any means other than the NC software. Below is the list of functions which make up the NC software along with a description of the ASCII text string which is passed across the IPC mechanism. The dnetd and application processes are assumed to run on the same processor architecture hence structures which are passed across the interface are portable using this method. When designing an application which uses the NC software, the developer should be aware that as there is one IPC channel, the structure which supports it is statically allocated. This means that after an application has called any nc_() function, any data which the application wishes to keep from the IPC buffer should be copied to memory allocated locally.
nc_alias
Name
nc_alias - create an alias
Synopsis
int nc_alias (struct nc *nc, char *label, char *alias);
Description
Create an alias for an existing label. Returns one if successful. --> ALIAS <label> <alias> <-- OK | ERR ...
77
nc_close
Name
nc_close - close a stream
Synopsis
int nc_close (struct nc *nc, char *stream);
Description
Close a STREAM in the server. The argument, stream is a label returned by the nc_open function. Returns one if successful. --> CLOSE <stream> <-- OK | ERR ... Example: if ( ! nc_close(nc, x25)) { printf(Error cannot close x25); return 0; }
nc_delete
Name
nc_delete - delete a label
Synopsis
int nc_delete(struct nc *nc, char *label);
Description
Remove an existing label. Returns one if successful. --> DELETE <label> <-- OK | ERR ...
78
nc_fdval
Name
nc_fdval - retrieve value of label
Synopsis
int nc_fdval(struct nc *nc, char *label);
Description
Retrieve value of FD label. Return -1 if error. -->VALUE <label> FD <-- OK <value> | ERR ...
nc_initialise
Name
nc_initialise - initialize a connection to dnetd, the X.25 network control daemon
Synopsis
struct nc *nc_initialise (char *nc);
Description
Initialize the IPC connection to dnetd, the network control daemon. Returns zero on error.
nc_link
Name
nc_link - link a stream under another stream
Synopsis
char *nc_link(struct nc *nc, char *upper, char *lower, char *label);
Description
Link one STREAM under another. Returns zero if error. --> LINK <upper> <lower> <label> <-- OK <label> | ERR ... Example:
79
char *ret_stat; if (ret_stat = nc_link(nc, XXX0, LLL0, l31) == NULL) { printf(Error cannot link lapb under x25); return 0; } In the example above the labels XXX0 and LLL0 would be returned from calls to nc_open(). The STREAM should be referred to as l31 by the Network Client for further operations.
nc_muxval
Name
nc_muxval - get value of label
Synopsis
int nc_muxval(struct nc *nc, char *label);
Description
Retrieve value of MUX label. Return -1 if error. -->VALUE <label> MUX <-- OK <value> | ERR ...
nc_open
Name
nc_open - open server
Synopsis
char *nc_open (struct nc *nc, char *server, char *service, char *controller, char *protocol, char *device, char *label);
Description
Open a STREAMS device in the server. The arguments provided to nc_open are sent to dnetd where they are used in a call to the PT application programming interface function, MPSopen. Returns zero if error. --> OPEN <server> <service> <controller> <protocol> <device> <label> <-- OK <label> | ERR ...
80
Example: char *dev_lbl; if (dev_lbl = nc_open(nc, /dev/ucsclone, mps, 0, x25 0, XXX0) == NULL) { printf(Error cannot open x25); return 0; }
nc_pop
Name
nc_pop - pop the module at the head of the stream
Synopsis
int nc_pop(struct nc *nc, char *stream);
Description
Pop the module at the head of the specified stream. Returns one if successful. --> POP <stream> <-- OK | ERR ... Example: if ( ! nc_pop(nc, LLL0)) { printf(Error: cannot pop from LLL0); return 0; }
nc_push
Name
nc_push - push a module on the stream
Synopsis
int nc_push(struct nc *nc, char *stream, char *module);
81
Description
Push a STREAMs module on the specified stream. Returns one if successful. --> PUSH <stream> <module> <-- OK | ERR ... Example: if ( ! nc_push(nc, LLL0, llswap)) { printf(Error: cannot nc_push) return 0; }
nc_rename
Name
nc_rename - rename label
Synopsis
int nc_rename(struct nc *nc, char *old, char *new);
Description
Rename an existing label. Returns one if successful. -->REName <old> <new> <-- OK | ERR ...
nc_shell
Name
nc_shell - execute command string
Synopsis
int nc_shell(struct nc *nc, char *cmd);
Description
Pass a command string to be executed by system(). Returns -1 on error. --> SHELL <command> <-- OK | ERR ...
82
nc_shutdown
Name
nc_shutdown - request dnetd, the X.25 network daemon, to exit
Synopsis
int nc_shutdown (struct nc *nc);
Description
Request the network control daemon to terminate. Returns one if successful. --> SHUTDOWN <-- OK | ERR ...
nc_strioc
Name
nc_strioc - issue ioctl to server
Synopsis
int nc_strioc(struct nc *nc, char *stream, int cmd, long tmout, char *dp, int len);
Description
Send an ioctl down a stream. Returns -1 on error. --> STRIOC <stream> <ioctl> <timeout> <length> --> <data> --> END | ABORT ... <-- OK <length> | ERR ... <-- <data> <-- END | ABORT Example: struct xll_reg xlreg; xlreg.snid = snidtox25(A); xlreg.dl_sap = 0; xlreg.lmuxid = mux; xlreg.dl_max_conind = 1; if (nc_strioc(nc, l31, N_snident, 10, (unsigned char *)&xlreg, sizeof(xlreg)) == -1) { printf(Error N_snident ioctl failed); exit(1); }
83
In the above example the mux value would be the muxid. This would be retrieved from the network daemon using the library function nc_muxval() with the label specified.
nc_terminate
Name
nc_terminate - end connection to X.25 network daemon
Synopsis
void nc_terminate(struct nc *nc);
Description
Terminate specified connection.
nc_unlink
Name
nc_unlink - unlink stream
Synopsis
int nc_unlink(struct nc *nc, char *driver, char *mux);
Description
Unlink a previously linked stream. Returns one if successful. --> UNLINK <stream> (<mux>|ALL) <-- OK | ERR ... Example: if ( ! nc_unlink(nc, x25, l31)) { printf(Error unlink failed on l31); exit(1); }
84
nc_version
Name
nc_version - NOT AVAILABLE
Synopsis
int nc_version (struct nc *nc);
Description
Assign the protocol version to be used by the server. The server is the network clients handle to the NC protocol. Returns one if successful. --> VERSION <-- OK <version>
Re-configuring Network Parameters

When a network configuration has been started it may be desirable to change some of the parameters within the running configuration. This has been possible in the past but only certain parameters could be changed using the relevant tuning utility. It is now possible to change any parameter using the relevant tuning utility by following the steps specified below. Re-configuring Network Parameters
1. Send a W_DISABLE ioctl to the appropriate WAN device. This will clear all virtual circuits (VCs) open across that WAN subnetwork. 2. Issue the appropriate tuning command. 3. Send a W_ENABLE ioctl to the appropriate WAN device. After the W_ENABLE ioctl has
been acknowledged successfully the network is in a suitable state to setup VCs as requested with the new parameters being operational. The dnetd demonstration programs in the tests/dnetd_demo directory include examples of the W_DISABLE and W_ENABLE ioctls.
Running the DNETD Example Programs

Included with the distribution are three dnetd demonstration programs: conf_control, conf_enable and conf_disable. These programs are located in the dnetd_demo directory under tests. The conf_control program builds and configures the X.25 protocol on the server. The conf_enable program enables subnetworks A-D. conf_disable program disables subnetworks A-D. In order for the example to execute properly, it is essential that the WAN configuration file parameter, WAN_auto_enable is set to N, i.e., no.
85
This test procedure includes running the switched virtual circuit or permanent virtual circuit test programs discussed in Section 2 Getting Started. These programs are designed to operate together over two serial links connected with a loopback (null modem) cable. At this point, download the X.25 software to your server. See Chapter 2, Getting Started, on page 15 for instructions. Now make sure that the first two ports on your server are connected with the provided loopback cable. Also, be sure that the WAN_baud parameter is set to a value other than -1 (e.g. 9600). This indicates that internal clocking is required. To perform the test, bring up four windows. In the first window, run the dnetd X.25 daemon. Before running dnetd in the UNIX environment, make sure the dnetd process isnt already running and that there are no message queues from earlier executions of the example. This is accomplished by running the utilities ps and ipcs. If dnetd is running, it can be terminated by sending it signal 9. For example, $ ps -ef | grep netd 121 0:01 inetd 5498 0:00 dnetd $ kill -9 5498 You may have to be super user to execute the ps command. If there are old message queues, remove them by using the Solaris utility, ipcrm. For example, $ipcs Message Queues: T ID KEY MODE OWN q 400 0x000003fc $ ipcrm -q 400
GROUP -Rrw-rw-rw-rw-
rjp
engineer
In the Windows environment, make sure the dnetd command line program is not already running. If it is, use ctlr-c to terminate it. Run the dnetd X.25 network daemon which is located in /etc for UNIX, and $(PTI)\bin for Windows. $ dnetd Note: T1/E1 embedded controllers (PCI37xPQ, CPC37xPQ, and PMC37x controllers) have specific configuration parameters that may be modified via the QMC configuration utility discussed in Chapter 4, QMC Configuration Guide, of the MPS Software and Hardware Installation Manual. If you are satisfied with the default values for these parameters, you will not need to run the QMC configuration utility, and may proceed to run dnetd. However, if you need to modify the defaults for these parameters, you must run the QMC configuration utility prior to running dnetd. In a second window, run the conf_control program. This program makes calls on the Network Control (NC) functions to configure the protocol software. For example, $ conf_control -s /dev/ucsclone -o 0 -v mps
86
When the conf_control program exits, the server software is configured, but, since you have set the WAN_auto_enable set to N, i.e., no, the server does not bring up the link layer. If you have a protocol analyzer monitoring the serial links, you will not see any message traffic. Now run the conf_enable program. This program makes calls on the NC functions that cause a W_ENABLE to be sent to the WAN server software for subnetworks A-D. $ conf_enable -s /dev/ucsclone -o 0
Subnet A enabled Subnet B enabled Subnet C enabled Subnet D enabled When the conf_enable program exits, the server is bringing up the link layer. If you have a protocol analyzer monitoring the serial links, you will see the message exchange typical of establishing lapb communication. In the third and fourth windows, run the x25svcsnd and x25svcrcv test programs. The programs are at tests/x25tests. For instructions on using these test programs, please see Chapter 2, Getting Started, on page 15. When the x25svcsnd and x25svcrcv programs exit, run conf_disable in the second window. The conf_disable program makes calls on the NC functions to send a W_DISABLE to the server WAN software for subnetworks A-D. For example, $ conf_disable -s /dev/ucsclone -o 0
Subnet A disabled Subnet B disabled Subnet C disabled Subnet D disabled You can repeat the demonstration by running conf_enable again followed by the switched virtual or permanent virtual circuit test programs and conf_disable. If it is desired to run more than one instance of the dnetd network daemon on the same Host system (one per X.25 controller), a unique key name must be provided so each dnetd can have a separate IPC channels associated with it. This can be accomplished by either specifying the -N keyName switch when starting the dnetd daemon, and when starting each of the demonstration programs: conf_control, conf_enable, and conf_disable, or by having the environment variable NETD defined to the desired keyName when starting these programs. The specific keyName will be used as a way for the conf programs to access each dnetd. The number of dnetd's that a Host system will support is limited to the maximum number of message queue identifiers the Host operating system will allow. Note that the actual IPC channel key generated from the input keyName is based on the first four characters. The hash function for the key generation might provide duplicate keys when many queues are needed. Try different character combinations as the input keyName if the error EEXIST is returned.
87
V.25bis Compliant Modem Support

Introduction
The server software can provide a telephone number to V.25bis compatible modems. The modem dials the number and establishes a call with a remote modem. After establishing the call, the modem asserts the RS232 modem signals, data carrier detect and data set ready. Since the server has asserted request to send, the modem also asserts clear to send. At this point, the server attempts to establish the link layer connection with the remote software. When the link layer is established, application programs can move data on either a switched or permanent virtual circuit. The link layer code assumes various states as it brings up the link. These states can be read by the application by requesting statistics (L_GETSTATS) from the link layer. When the state assumes the value NORMAL the link is up. The dnetd_v25_demo directory includes test programs that demonstrate the V.25bis support provided by the server. This section discusses the required configuration and how telephone numbers are provided to the server. In addition, a discussion on how the demonstration programs are used is included.
Server Configuration
The wan configuration file, wantemplate, includes the parameter, WAN_connect_proc. The default value for this parameter is zero, i.e. no calling procedures. Setting the parameter to two, causes the server to use V.25bis calling procedures.
Modem Configuration
The server support for V.25bis compatible modems was tested using a Motorola 3260 modem. The modem as configured at the factory is not suitable for supporting the placing of calls to a remote site using bit synchronous communications. Before using this modem, it is necessary to configure the modem to use Option Set 3, synchronous calls to a remote site. With this one change, the modem is ready to use. If a protocol analyzer is to be placed between the modem and the server, the DTE Rate parameter of the TERMINAL OPTS menu must be set to the baud rate used when configuring the protocol analyzer. For example, if the analyzer is set to 9600 baud, then the DTE Rate parameter must be set to 9600 as well. The factory setting for DTE Rate is 14400. The key configuration considerations are that V.25bis calling procedures are used, bit synchronous communications are used and transmit clocking is to be provided by the modem.
88
V.25bis Compliant Modem Support
Providing a Telephone Number

There are two ways to provide the server with a telephone number: invoke the utility wanmap or include the telephone number with the W_ENABLE ioctl. If you are using the netd daemon, you can provide a wanmapconf file and invoke the wanmap utility in your netd script file. If you are using the dnetd daemon, you can include the telephone number in the W_ENABLE ioctl. If you are using the netd daemon, your script file (netconf) includes a line linking the wan module under the lapb module. This line generally includes a series of control actions, which invoke the wantune and lltune utilities. These control actions can be extended by invoking the wanmap utility. For example, lapb wan0 LL_SET_SNID={A, LC_LAPBDCE} \ SHELL=wantune -P -d 0 -s A -c 0 def.wan \ SHELL=lltune -P -p lapb -s A -d 0 -c 0 def.lapb\ SHELL=wanmap -P -s A -d 0 -c 0 wanmapconf.A The wanmap utility reads the wanmapconf file specified on the command line, parses it and sends the content to the wan code in the server. The content is expected to relate to the specified subnet. In the example above, the subnet is A. When the wan code begins to bring up the link, it tests the WAN_connect_proc parameter. If the value of the parameter is two, the wan reads the telephone number provided by wanmap and sends it to the modem. With this approach, the first telephone number in the wanmapconf is always used to place the call. If you are using the dnetd daemon, your wantemplate configuration file specifies a value of N for the WAN_auto_start parameter. Thus, the wan code does not try to bring up the link until it receives a W_ENABLE ioctl. This ioctl can include a telephone number. When the wan code begins to bring up the link, it tests the WAN_connect_proc parameter. If the value of the parameter is two, the wan reads the telephone number provided by the W_ENABLE ioctl and sends it to the modem. With the dnetd approach, the telephone number can be provided either directly or indirectly. The ioctl includes a structure with two areas: a remote address area and an interface area. If the remote address is non-null, the address is used as the telephone number. If the remote address is null, the interface area is used to search the list of interface addresses provided by wanmap. When a match is found, the corresponding remote address is used as the telephone number. This allows the application writer to create a collection of remote address/interface address couplets when the wan is configured and then use the W_ENABLE ioctl to select an interface at link establishment time. See wanmapconf for a definition of the format of the file.
89
V.25bis Demonstration
A demonstration is performed at PT using two MPS600 servers. One server, named diamond, is connected to a V.25bis compatible modem, the other, named stone, is connected to an answer-only modem. Server stone is configured using netd and the configuration files, netconfStone, def.dce84.x25, def.lapb and def.wan. Server diamond is configured using file def.dte84.x25, def.lapb and def.wan.v25. The modems are connected to the local telephone system. Four windows are used in the test. After booting both servers, stone is configured from the first window: $ cd /etc $ netd -t netconfStone Next, the dnetd daemon is readied for communications: $ cd /etc $ dnetd In the third window, the link layer monitor program is started: $ cd /usr/pti/x25/cmd/net/bin/util $ x25llmon -n A -s diamond In the fourth window, diamond is configured: $ cd /usr/pti/x25/tests/dnetd_v25_demo $ conf_control -s diamond Next diamond is instructed to enable the link. The conf_enable program defaults to the telephone number connected to stone. You must change this telephone number to call your server. $ conf_enable -s diamond -n A If your answering modem is at telephone number (619)444-5555, conf_enable would be invoked as follows: $ conf_enable -s diamond -n A -r 16194445555 At this point, the telephone number is dialed by the V.25bis modem, the answering modem goes off-hook and a transmission rate is established between the two modems. Then the modems assert the RS232 signals, data carrier detect, data set ready and clear to send to their respective wan layers. The link layer software brings up the link by exchanging LAPB messages. Typically, the x25llmon program displays that a DISC message is sent, a DM is received, a SABM is sent, a UA is received, an I frame is sent, an I frame is received, an RR is sent, an RR is received. At this point, the link layer is up and ready to support packet layer traffic. The conf_state program indicates the state of the link is NORMAL. $ conf_state -s diamond
90
Network Utilities
Network Utilities
dnetd
Name
dnetd - dynamic network daemon
Synopsis
dnetd
Description
dnetd configures a STREAMS network from commands which are passed to it via an interprocess communications mechanism. Access to dnetd is via the supplied Network Control (NC) functions, i.e., the users application makes calls to the NC functions which cause messages to be sent to dnetd. (See the discussion of the Network Control Functions, on page 75 and dnetd at the beginning of this section.) The dnetd process is an alternative to netd. The purpose of dnetd is to support control of the link layer from user code.
See Also
netd, netconf
lltune
Name
lltune - sends/receives lapb tuning parameters to/from lapb
Synopsis
lltune -s subnet_id -p protocol -P [-d device] [-t target] [-v service] [-c controller] [filename] lltune -s subnet_id -p protocol [-G] [-d device] [-t target] [-v service] [-c controller]
Description
lltune is a utility which either puts a set of lapb parameters to the lapb driver or gets a set of lapb parameters from the lapb driver. By default, a get operation is performed. These parameters are on a per-subnetwork basis and thus, the subnetwork identifier must be specified.
91
The options used in lltune are the following: -s subnet_id subnet_id is the subnetwork to be referenced. -p protocol specifies the protocol being used as protocol. This is a required parameter and must have the value lapb. -G get parameters from the lapb driver. These are written to the standard output. The -G (get) option is used as default and therefore is optional when a 'get' is required. -P -d device -t target put parameters to the lapb driver, giving subnetwork subnet_id these values. specify the device to be device. The device for lapb is always 0. specify the target device or server name to be target. This is a required parameter. For a LAN-based server, target is the logical host name as specified in the client's hosts database. For a controller installed in a backplane, target is the pathname of the driver's cloneable special file. specify the service name from the /etc/services database. Used only for LANbased servers. If this option is not included, the service name defaults to mps.
-v service
-c controller specify the controller number to be controller. The default controller number is 0. The filename, as used in the 'send' option, specifies the file of parameters to be sent (put) to LAPB. The values are read from the standard input but this can be overridden by specifying a file of parameters (see lapbtemplate(4)). If the UNIX filename begins with a '/', then it is assumed to be the full path-name of the file. Otherwise, the file is assumed to be in the directory /usr/lib/snet/template. If filename is not found in the template directory, then it is returned as invalid. For Windows the file is assumed to be in the directory %PTI%\lib\snet\template. If filename is not found in the template directory, then it is returned as invalid.
See Also
lapbtemplate(4)
92
Network Utilities
mknetconf
Name
mknetconf - configuration file generator
Synopsis
mknetconf [-f file_suffix]
Description
The mknetconf utility prompts the user for various configuration parameters in order to automatically build the netconf and x25conf configuration files. The -f option may be used to supply a suffix to the configuration files it creates. Typically the argument is the logical name of the controller or server the configuration is generated for. The mknetconf utility creates netconf.file_suffix and x25conf.file_suffix in the directory the utility is executed in. You may then copy these files to the /etc directory (or execute this utility in /etc). A sample session would proceed like this: mknetconf ucmps Server Name [/dev/ucsclone]: Controller Number [0]: 1 Number of Links [4]: 6 Number of DCEs [3]: First DCE [0]: Second DCE [1]: 2 Number of DTEs [3]: First DTE [1]: Second DTE [3]: Gather File Information: Wantune Filename [def.wan]: lltune Filename [def.lapb]: DCE Filename [def.dce84.x25]: def.dce88.x25 DTE Filename [def.dte84.x25]: def.dte88.x25 %ls *.ucmps netconf.ucmps
x25conf.ucmps
93
netd
Name
netd - network daemon
Synopsis
netd [-nt] [config_file | -]
Description
netd configures a STREAMS network from a specification given in a configuration file whose format is described in netconf(4). By default the configuration is taken from the file netconf in the etc directory. The mknetconf utility can be used to automate the configuration of this file. An alternative file may be specified as a command line parameter (config_file). The special filename '-' is taken to mean the standard input. The -t option may be used to debug a configuration file. It produces trace information indicating the sequence of opens, links, etc. performed by netd to create the STREAMS architecture defined by the configuration. The -n option, which also implies -t, inhibits the actual building of the STREAMS network. A typical configuration file might contain the following: lapb wan0 wan1 x25 %% lapb wan0 LL_SET_SNID={A, LC_LAPBDCE} \ SHELL="wantune -P -d 0 -s A -t server \ -c 0 def.wan" \ SHELL="lltune -P -p lapb -s A -d 0 -t server \ -c 0 def.lapb" x25 lapb SHELL="x25tune -P -s A -d 0 -t server \ -c 0 def.dce84.x25" \ X25_SET_SNID={A,,1} lapb wan1 LL_SET_SNID={B, LC_LAPBDTE} \ SHELL="wantune -P -d 1 -s B -t server \ -c 0 def.wan" \ SHELL="lltune -P -p lapb -s B -d 0 -t server \ -c 0 def.lapb" dc d d dc 0 0 1 0 server server server server 0 0 0 0 mps mps mps mps lapb wan wan x25
94
Network Utilities
x25 lapb SHELL="x25tune -P -s B -d 0 -t server \ -c 0 def.dte84.x25"\ X25_SET_SNID={ B,,1 } The following control actions (as described in netconf(4)) are currently defined: LL_SET_SNID = {subnet-id, LL-class} This registers the subnetwork identifier (subnet-id) to be associated with this link. The subnetwork identifier provides a unique name for an outlet to a board and its associated higher level streams. It is between 1 and 4 alphanumeric characters and is a mandatory parameter. The LL-class can be one of the following: LC_LAPBDTE LC_LAPBXDTE LC_LAPBDCE LC_LAPBXCDE LC_LAPDTE LC_LAPDCE LAPB - DTE, LAPB - DTE, extended addressing, LAPB - DCE, LAPB - DCE, extended addressing. LAP - DTE, LAP - DCE,
X25_SET_SNID ={subnet-id, SAP, max-conid} This registers the subnetwork identifier to be associated with this link, the SAP to be associated with this subnetwork and the maximum number of connect indications that can be outstanding on this stream. Streams setup with a max-conid are listen streams. The subnet-id parameter is mandatory. The SAP is not used but requires the comma as a place holder. SHELL =command-string This allows calls to the shell. Utilities may then be called at an intermediate stage in the building of the STREAMS network. For example: SHELL=lltune -P -p lapb -s B -d 0 -t server -c 0 def.lapb This particular call to the lltune utility sets the tuning parameters for lapb, as described in lltune(1M).
See Also
netcreate(1M), pvcmap(1M), hosts(4), lapbtemplate(4), netconf(4), mknetconf(4), pvcmapconf(4), wantemplate(4)
95
nuimap
Name
nuimap - set up Network User Identifier (NUI)/associated facilities mapping
Synopsis
nuimap [-DG] -n network_user_identifier [-s server] [-v service] [-c controller] nuimap [-MZ] [-s server] [-v service] [-c controller] nuimap -P [-f file] [-s server] [-v service] [-c controller]
Description
The nuimap utility reads in a file of Network User Identifiers and associated facilities mappings and stores them within an X.25 internal table. You may call this utility at any time, allowing dynamic alteration of the mappings. The options have the following meaning: -n network_user_identifier specify a particular mapping. This parameter must be present for the -D and -G options. -s server specify the server's host name from the hosts database in the etc directory, or the clone device name for the host driver. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX and \\.\PTIXpqcc for Windows. specify the service name from the /etc/services database. Used only for LANbased servers. If this option is not included, the service name defaults to mps.
-v service
-c controller specify the controller number to be controller. The default controller number is 0. -f file specify a file for the mappings to be read from. The default file is nuimapconf(4) in the etc directory, but another may be specified using this option. The full directory path is required. delete the mapping for the specified NUI from the X.25 internal table. Used to delete known entries. fetch the mapping for the specified NUI from the X.25 internal table. If the mapping exists, it will be echoed to stdout. Mostly used to find which facilities are associated with a known NUI. Output is of the form: NUI firstnui Associated Facilities p7/7,w4/4g
-D -G
96
Network Utilities
-M
pick up all existing mappings from the X.25 internal table and echo them to stdout. Output is of the form: NUI firstnui andasecond thirdone fourthinline Associated Facilities e,p7/7,w4/4g ox t7/7w120/120, bg,p4/4
See nuimapconf(4) for an explanation of each token. -P -Z load the mappings in the specified file to the X.25 internal NUI/facilities table. zero the X.25 internal NUI/facilities table.
See Also
nuimapconf(4), x25(7)
pvcmap
Name
pvcmap - set up packet/window sizes for Permanent Virtual Circuits
Synopsis
pvcmap [-G] [-s server] [-v service] [-c controller] pvcmap -P [-f file] [-s server] [-v service] [-c controller]
Description
The pvcmap command allows packet and window sizes for specified PVCs to be altered from the defaults for the subnet the PVC is active on. The command reads in a file of PVC logical channel identifiers and associated packet and window sizes and stores them in the internal X25 virtual circuit table (see x25(7)). It is important that non-default packet/window sizes are configured before any user attaches to the PVC; hence this command should be run at network startup time. By default, a get operation is performed. The options have the following meaning: -s server specify the server's host name from the hosts database in the etc directory, or the clone device name for the host driver. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX and \\.\PTIXpqcc for Windows specify the service name from the services database in the etc directory. Used only for LAN-based servers. If this option is not specified, the service name defaults to mps.
-v service
97
-c controller specify the controller number to be controller. The default controller number is 0. -f file specify a file for the mappings to be read from. The default file is pvcmapconf in the etc directory but another may be specified using this option. The full directory path is required. fetch all existing packet/window sizes for configured PVCs from the internal X.25 vc table and echo them to stdout.
-G
Output is of the form: Subnet

A A B
LCI
1 2 1
Locpkt
128 512 256
Rempkt
128 512 128
Lwin
2 4 7
Rwin
2 4 4
See pvcmapconf(4) for an explanation of each token. -P load the packet/window sizes in the specified file to the internal X25 vc table.
See Also
pvcmapconf(4)
wanmap
Name
wanmap - set up remote address/interface address mapping
Synopsis
wanmap [-G] [-s server] [-v service] [-c controller] -n subnetwork_id wanmap -Z [-s server] [-v service] [-c controller] -n subnetwork_id wanmap -P [-s server] [-v service] [-c controller] -n subnetwork_id file-name
98
Network Utilities
Description
The wanmap utility reads in a file of X.121destination addresses and interface address mappings and stores them in the WAN internal table. You may call this utility at any time, allowing dynamic alteration of the mappings. The options have the following meaning: -s server specify the server's host name from the hosts database in the etc directory, or the clone device name for the host driver. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX and \\.\PTIXpqcc for Windows. specify the service name from the services database in the etc directory. Used only for LAN-based servers. If this option is not specified, the service name defaults to mps.
-v service
-c controller specify the controller number to be controller. The default controller number is 0. -n subnetwork_id specify a subnetwork identifier for the entries to be sent to. file-name specify a file for the mappings to be read from. The file must be in wanmapconf(4) format. The full directory path is only required if file-name is not in /usr/lib/snet/interfacemap for UNIX, or %PTI%\lib\snet\interfacemap for Windows. extract all existing mappings from the WAN internal table and echo them to stdout. This is the default option. Output is of the form: Rem Address 12345678901234 uk.co.host 12342342432 -P -Z Interface Address 0101444568765 2323,1223233,2233442332323 uk.ac.host
-G
load the mappings in the specified file into the WAN internal table. zero the WAN internal table.
See Also
netconf(4), wanmapconf(4)
99
wantune
Name
wantune - sends/receives WAN tuning parameters to/from WAN
Synopsis
wantune -P [-d device] -s subnet_id [-t target] [-v service] [-c controller] [filename] wantune [-G] [-d device] -s subnet_id [-t target] [-v service] [-c controller]
Description
wantune is a utility which either puts a set of WAN parameters to the WAN module, or gets a set of WAN parameters from the WAN module. By default, a get operation is performed. These parameters are on a per-subnetwork basis and thus, the subnetwork identifier must be specified. The options used in wantune have the following meaning: -s subnet_id subnet_id is the subnetwork to be referenced. -G get parameters from the WAN module. These are written to the standard output. The -G (get) option is used as default and therefore is optional when a get is required. -P -d device -t target send parameters to the WAN module, giving subnetwork subnet_id these values. specify the device (link number) to be device. The default device is 0. specify the target device or server name to be target. This is a required parameter. For a LAN-based server, target is the logical host name as specified in the client's hosts database in the etc directory. For a controller installed in a backplane, target is the pathname of the driver's cloneable special file. specify the service name from the /etc/services database. Used only for LANbased servers. If this option is not included, the service name defaults to mps.
-v service
-c controller specify the controller number to be controller. The default controller number is 0.
100
Network Utilities
The filename, as used in the 'send' option, specifies the file of parameters to be sent (put) to WAN. The values are read from the standard input but this can be overridden by specifying a file of parameters (see wantemplate(4)). If the UNIX filename begins with a '/', then it is assumed to be the full path-name of the file. Otherwise, the file is assumed to be in the directory /usr/lib/snet/template. If filename is not found in the template directory, then it is returned as invalid. For Windows the file is assumed to be in the directory %PTI%\lib\snet\template. If filename is not found in the template directory, then it is returned as invalid.
See Also
wantemplate(4)
x25llmon
Name
x25llmon - monitor subnetwork traffic
Synopsis
x25llmon[-n subnet] [-s server] [-v service] [-c controller] [-R Raw data mode] [-d debug]
Description
The x25llmon link monitor utility displays HDLC LAPB frames as they are transmitted and received on a specified subnetwork. The following options are recognized: -n subnet -s server This parameter identifies the subnetwork to be monitored. If not specified, subnet defaults to A. This parameter identifies the target server. For a LAN-based server, this is the logical host name as specified in the client's hosts database in the etc directory. For a controller installed in a backplane, server is the pathname of the driver's cloneable special file. If this option is not specified, the server name defaults to /dev/ucsclone for UNIX and \\.\PTIXpqcc for Windows. For LAN-based servers this parameter identifies the service name to be accessed, as specified in the client's services database in the etc directory. For a controller installed in a backplane, this parameter is not used. If this option is not included, the service name defaults to mps.
-v service
-c controller This parameter specifies the controller number. If not specified, controller defaults to 0.
101
-d debug
This parameter causes x25llmon to display detailed information as it sends and receives packets to and from the protocol during processing of the request.
-R Raw data mode This parameter causes x25llmon to collect data from the HDLC LAPB frame and pass it to the application without evaluating the contents. When used with the debug option the data is displayed on the screen. When executed, x25llmon opens a connection directly to the LAPB protocol and requests the protocol module to begin monitoring data traffic on the specified subnetwork. As frames are transmitted and received on the subnet, LAPB records the information and forwards it to the monitor program. x25llmon formats the information and displays it as described below. Note: The link monitor is intended as a diagnostic aid only and is not to be used during normal runtime operation of your X.25 network. Operation of the link monitor requires significant system resources on the server or controller and can noticeably degrade the operation of X.25.
Display Format
When used without the Raw data mode option, each line displayed by the monitor program describes a single HDLC LAPB frame, and is composed of a number of fields. Some fields are always present, and others apply only to certain frame types. The basic fields, which are always present, are defined below in order as they appear within the display line: When used with the Raw data mode and debug options, each line displayed by the monitory program describes a single HDLC LAPB frame. For example, for a connection monitoring subnet A on server sinjin, the following lines represent an initial connection sequence of DISC; SABM; AU; Restart Request; Restart Confirm: x25llmon -n A -s sinjin -R -d Attempting to open lapb. Sending DL_MON_RAW_ATTACH for subnet A Awaiting reply to DL_MON_RAW_ATTACH Response received to DL_MON_RAW_ATTACH LS_SUCCESS received: monitor attached Monitoring... Control-c to exit x25llmon.c-492: 2 bytes of Raw Monitor Data received. 03 43 x25llmon.c-492: 2 bytes of Raw Monitor Data received. 03 0f x25llmon.c-492: 2 bytes of Raw Monitor Data received. 01 3f x25llmon.c-492: 2 bytes of Raw Monitor Data received. 01 73 x25llmon.c-492: 2 bytes of Raw Monitor Data received. 03 00 01 00 fb 00 00 x25llmon.c-492: 5bytes of Raw Monitor Data received. 01 20 10 00 ff
102
Network Utilities
x25llmon.c-492: 2 bytes of Raw Monitor Data received. ASCII Field Name Representation Description direction Rx Received or transmitted frame Tx (separator)(space) subnet ncSubnetwork ID, where c is a single alphabetic character (separator)(space) address0xnnAddress, where nn is an eight-digit hexadecimal value (separator)typeI Type of frame UI RR RNR REJ SREJ DISC DM SABM SABME FRMR UA ?? pf * Asterisk indicates Poll/Final bit was set (space) (terminator)(linefeed)(null) Newline/null terminator (zero) For example, for a connection monitoring subnet B, the following line represents a received DISC with address 3 and with the Poll/Final bit set: Rx nB 0x00000003-DISC* Frame types RR, RNR, REJ and SREJ include an additional field following pf and preceding the terminator. This field consists of the characters n(r)=nn, where nn is a decimal value representing N(r). For example, the following string represents a transmitted RR: Tx nB 0x00000022-RR n(r)=3 FRMR frames also have an additional field following pf, but consisting of six hexadecimal digits. These digits represent the three diagnostic octets (reason code) included in the frame. For example: Tx nA 0x00000003-FRMR 013E9D Information frames include several additional fields following pf: ASCII Field Name Representation Description rcvseq n(r)=nn N(r), where nn is one to three decimal digits
103
sndseq n(s)=nn N(s), where nn is one to three decimal digits (separator)(space) size <nn> size of the information Field (number of data bytes), where nn is one to four decimal digits For example, the following line represents a received information frame with N(r) equal to 3, N(s) equal to 5, and containing 103 bytes of data in the information field: Rx nB 0x00000001-I*n(r)=3 n(s)=5 <103>
x25stat
Name
x25stat - show status of X.25 network
Synopsis
x25stat[-zawLN] [-p proto] [-n subnet] [-s server] [-v service] [-c controller] [-l lcn] ... [interval]
Description
The x25stat command symbolically displays the contents of various per-protocol statistics, which are held by various modules in the X.25 network. By default, X.25 packet-level protocol (PLP) statistics are shown as combined values for all subnetworks on controller zero: GLOBAL STATISTICS FOR X25 ----------------------------------------------------------Packet type TX RX ----------------------------------Call 2 2 Call accept 1 1 Restart 2 2 Restart Confirm 0 0 RNR 0 0 RR 56 56 Resets 0 0 Reset confirms 0 0 Diagnostic 0 0 Interrupts 0 0 Registration 0 0 Reg confirm 0 0
104
Network Utilities
Packets (total)116116 Bytes (total)43884388 -----------------------------------Running totals -----------------------------------Tot no of VCs established 2 Connections refused 0 Connections currently open 0 Max connections open 0
GLOBAL STATISTICS FOR LAPB --------------------------Statistic TX RX ------------------------------------Frames 217 216 Bytes4971 0 SABM 1 0 The options in x25stat have the following meaning: -a Display abbreviated statistics for all active virtual circuits. If this option is selected, and the protocol is set to x25 (default), only X.25 statistics are displayed. If this option is selected, and the protocol is set to lapb, both LAPB and X.25 are displayed. Display statistics on a per-subnetwork basis. subnet can be an actual subnetwork identifier, or the name of the subnetwork, as specified in the subnetworks file in the etc directory. Display statistics for all subnetworks. Display statistics for the specified logical channel number. The channel number must be specified as a hexadecimal number. Display statistics for all logical channels. show statistics for a specified protocol proto; proto may be either 'lapb' or 'x25'.
-n subnet
-N -l lcn -L -p proto
It should be noted that if this option is used in conjunction with the -n option, then the subnetwork's underlying protocol must be the same as the one specified. For 'x25', statistics are displayed in the same format as the default case shown above. With the -n option, packet-level statistics are displayed only for the specified subnetwork. Unless the -c option is used to specify a particular controller, statistics are displayed for controller 0 only. -w Display statistics relating to the WAN. The format of the output is of the form: STATISTICS FOR WAN Subnetwork : A 14 good frames transmitted 14 good frames received
105
0 transmit underruns 0 receive overruns 0 received frames too long 0 CRC/frame errors received 0 received aborts The WAN statistics can be reset using the -z option with the -p option with wan specified as the protocol. -z zero -s server resets the statistics on a per-protocol basis. Thus, it must be used with the -p option. specifies the name of the communication controller's clone device, or the server's host name as specified in the hosts database in the etc directory. If this option is not specified, the server name defaults /dev/ucsclone for UNIX and \\.\PTIXpqcc for Windows. for LAN-based servers, specifies the server's TCP service name, as specified in the services database in the etc directory. Not used for communication controllers installed in a host backplane. If this option is not included, the service name defaults to mps.
-v service
-c controller specifies the controller number. If this option is not included, packet level statistics are shown for controller zero. If an interval is specified, x25stat will continuously re-display the appropriate information or reset the statistics, pausing interval seconds between each action.
See Also
subnetworks(4), x25conf(4)
x25tune
Name
x25tune - sends/receives X.25 tuning parameters to/from X.25
Synopsis
x25tune-s subnet_id -P [-a local_address] [-d device] [-t target] [-v service][-c controller] [filename] x25tune -s subnet_id [-G] [-d device] [-t target] [-v service] [-c controller]
106
Network Utilities
Description
x25tune is a utility which either puts a set of X.25 parameters to the X.25 driver or gets a set of X.25 parameters from the X.25 driver. By default, a get operation is performed. These parameters are on a per-subnetwork basis and thus, the subnetwork identifier must be specified. The options used in x25tune are the following: -s subnet_id subnet_id is the subnetwork to be referenced. -G get parameters from X.25 subnetwork. These are written to the standard output. The -G (get) option is used as default and therefore is optional when a 'get' is required. -P -a address -d device -t target send parameters to the X.25 driver, giving subnetwork subnet_id these values. sets the X.25 address of the specified subnetwork to be address. This address is either a DTE or an LSAP. This is only valid with the -P option. specify the device to be device. The device for X.25 is always 0. specify the target device or server name to be target. This is a required parameter. For a LAN-based server, target is the logical host name as specified in the client's hosts database in the etc directory. For a controller installed in a backplane, target is the pathname of the driver's cloneable special file. specify the service name from the /etc/services database. Used only for LANbased servers. If this option is not included, the service name defaults to mps.
-v service
-c controller specify the controller number to be controller. The default controller number is 0. The filename, as used in the 'send' option, specifies the file of parameters to be sent (put) to X.25. The values are read from the standard input but this can be overridden by specifying a file of parameters (see x25template(4)). If the UNIX filename begins with a '/', then it is assumed to be the full path-name of the file. Otherwise, the file is assumed to be in the directory /usr/lib/snet/template. If filename is not found in the template directory, then it is returned as invalid. For Windows the file is assumed to be in the directory %PTI%\lib\snet\template. If filename is not found in the template directory, then it is returned as invalid.
See Also
x25template(4), x25addr(5)
107
Network Libraries
equalx25
Name
equalx25 - tests if two X.25 address structures are identical
Synopsis
#include <sys/snet/x25_proto.h> #include <x25db.h> int equalx25 (x1, x2)
struct xaddrf *x1, *x2;
Description
The equalx25 routine checks to see if two X.25 xaddrf (see xaddrf(4)) structures contain X.25 addresses that are equivalent.
See Also
xaddrf(4)
Diagnostics
The equalx25 routine returns 1 if the two structures are equal, and 0 otherwise.
getnettype
Name
getnettype - get network type
Synopsis
#include <sys/snet/x25_proto.h> #include <xnetdb.h> int getnettype (snid)
unsigned char *snid;
108
Network Libraries
Description
The getnettype routine reads from the file x25conf, defined in xnetdb.h, to determine what type of network the subnetwork identifier, snid, refers to. The following values are returned: W80 W84 W88 Wide Area Network conforming to 1980 X.25. Wide Area Network conforming to 1984 X.25. Wide Area Network conforming to 1988 X.25.
Files
x25conf in the etc directory
Diagnostics
A negative value is returned if the given subnetwork identifier is invalid.
getsubnetent
Name
getsubnetent, getsubnetbyid, getsubnetbyname, getaddrbyid, setsubnetent, endsubnetent - get subnetwork entry
Synopsis
#include <sys/snet/x25_proto.h> #include <xnetdb.h> struct subnetent *getsubnetent( ) struct subnetent *getsubnetbyname(name) char *name; struct subnetent *getsubnetbyid(snid) unsigned long snid; struct xaddrf *getaddrbyid(snid) unsigned long snid; setsubnetent(stayopen) int stayopen; endsubnetent()
109
Description
The getsubnetent, getsubnetbyname, and getsubnetbyid subroutines each return a pointer to an object with the following structure containing the broken-out fields of a line in the subnetworks database, subnetworks in the etc directory. { struct xaddrf xaddr; char char ; *alias; *descrip; /* /* /* /* X.25 Calling Address (includes subnetwork) Subnetwork Alias Subnetwork Description */ */ */ */
The members of this structure are: xaddr alias descrip This is a Calling Address for a particular subnetwork. A name for the subnetwork. The name can contain 2 or more alphanumeric characters. An optional description field describing the function of the subnetwork.
The getsubnetent subroutine reads the next line of the network subnetworks database, opening the file if necessary. The setsubnetent subroutine opens and rewinds the file. If the stayopen flag is non-zero, the subnetworks database will not be closed after each call to getsubnetent (neither directly, nor indirectly through one of the other 'getsubnet' calls). The endsubnetent subroutine closes the file. The getsubnetbyname and getsubnetbyid subroutines sequentially search from the beginning of the /etc/subnetworks file until a matching subnetwork name or subnetwork identifier is found, or until EOF. Both routines return a pointer to a subnetent structure. The getaddrbyid subroutine functions identically to getsubnetbyid except that it returns a pointer to an xaddrf structure (see xaddrf(4) as opposed to a subnetent structure.)
Restrictions
All information is contained in a static area, so it must be copied if it is to be saved.
Files
subnetworks in the etc directory
See Also
subnetworks(4), xaddrf(4)
110
Network Libraries
Diagnostics
Null pointer (0) returned on EOF or error by getsubnetent, getsubnetbyname, getsubnetbyid or getaddrbyid.
getxhostent
Name
getxhostent, getxhostbyname, getxhostbyaddr, setxhostent, endxhostent - get network xhost entry
Synopsis
#include <sys/snet/x25_proto.h> #include <xnetdb.h> struct xhostent *getxhostent( ) struct xhostent *getxhostbyname(name) char *name; struct xhostent *getxhostbyaddr(addr, len, type) char *addr; register int len, type; setxhostent(stayopen) int stayopen; endxhostent( )
Description
The getxhostent and getxhostbyname subroutines each return a pointer to the following structure containing the broken-out fields of a line in the network xhost database, xhosts in the etc directory. struct hostent { char h_name; char **h_aliases; int h_addrtype; int h_length; char *h_addr; };
111
The members of this structure are: h_name h_aliases h_addrtype h_length h_addr The official name of the X.25 host. A zero terminated array of alternative names for the X.25 host. The type of address being returned; currently always CCITT_X25. The length, in bytes, of the address h_addr. A pointer to the network address for the X.25 host. Host addresses are returned as a character pointer to an xaddrf structure (see xaddrf(4)).
The getxhostent subroutine reads the next line of the network xhost database, opening the file if necessary. The setxhostent subroutine opens and rewinds the file. If the stayopen flag is non-zero, the xhost database will not be closed after each call to getxhostent (neither directly, nor indirectly through one of the other 'getxhost' calls). The endxhostent subroutine closes the file. The getxhostbyname subroutine sequentially searches from the beginning of the xhosts file in the etc directory until a matching xhost name is found, or until EOF. Host names are supplied as a character string which refers to an X.25 host name or an alias of the X.25 host name. The getxhostbyaddr subroutine sequentially searches from the beginning of the xhosts file in the etc directory until a matching xhost address is found, or until EOF. A pointer to a hostent structure is returned. The xhost address is supplied as a character pointer to an X.25 address in xaddrf format (see xaddrf(4)). The len field must be the length, in bytes, of the address, addr. The type field is the address type required, currently always CCITT_X25.
Restrictions
All information is contained in a static area, so it must be copied if it is to be saved.
Files
xhosts in the etc directory
See Also
xaddrf(4), xhosts(4), x25addr(5)
Diagnostics
Null pointer (0) returned on EOF or error by getxhostent, getxhostbyname or getxhostbyaddr.
112
Network Libraries
snidtox25
Name
snidtox25 - convert a character string subnetwork identifier to an X.25 subnetwork identifier
Synopsis
#include <sys/snet/x25_proto.h> #include <xnetdb.h> unsigned long snidtox25 (snid) unsigned char *str_snid;
Description
The snidtox25 routine converts a character string snid of up to four characters in length to a subnetwork identifier represented as a unsigned long. On a successful return, the routine returns the new subnetwork identifier.
See Also
x25tosnid(3N)
Diagnostics
On failure, it returns 0, an invalid value for the subnetwork identifier.
stox25
Name
stox25 - convert an X.25 dot format address to an X.25 structure
Synopsis
#include <sys/snet/x25_proto.h> #include <x25db.h> int stox25 (cp, xad, lookup)
unsigned char *cp;/* X.25 dot format address */
struct xaddrf *xad;/* The returned structure */ int lookup;
113
Description
The stox25 routine converts an address, cp, in the X.25 address dot format (see x25addr(5)) to an xaddrf structure, xad (see xaddrf(4)). This routine can be also used as a validity check for X.25 addresses. The parameter lookup defines the level of address checking to be performed. A non-zero value implies that the given X.25 address will be rigorously checked, using the file x25conf in the etc directory, to see if its format is valid for the type of network to which it refers. This involves a reference to a file which holds the associations between subnetwork identifiers and their types (for example WAN80, WAN84 or WAN88). A zero value means that this file will not be referenced and thus a faster X.25 address conversion/check can be made. In this case the address may be invalid for the type of network specified by the subnetwork identifier.
Restrictions
All information is held in a static area so it must be copied if it is to be saved.
See Also
x25tos(3N), xaddrf(4), x25addr(5)
Diagnostics
A negative value is returned from stox25 if the given X.25 address is invalid. This means that the returned structure is NOT a valid one. Zero is returned if the routine is successful.
x25tos
Name
x25tos - convert an X.25 structure to a X.25 dot format address
Synopsis
#include <sys/snet/x25_proto.h> #include <x25db.h> int x25tos (xad, cp, lookup) struct xaddrf *xad; /* The X.25 structure unsigned char *cp; /* int lookup; The returned string */ */
114
Network Libraries
Description
The x25tos routine converts an X.25 xaddrf structure, xad (see xaddrf(4)) to an X.25 dot format string, cp (see x25addr(5)). The validity of the given structure is checked. The character string cp should be at least MAXXADDRSIZE characters. The parameter lookup defines the level of address checking to be performed. A non-zero value implies that the given X.25 structure will be checked, using the file x25conf in the etc directory, to see if its constituent parts are valid for the type of network to which it refers. This is done by referencing to a file which holds the associations between subnetwork identifiers and their types (for example, WAN80, WAN84 or WAN88). A zero value means that this file will not be referenced and in this way a faster structure to address conversion can be made.
See Also
stox25(3N), xaddrf(4), x25addr(5)
Diagnostics
A negative value is returned from x25tos if the given X.25 structure is invalid. This means that the returned address is not a valid one. If the routine is successful, it returns 0.
x25tosnid
Name
x25tosnid - convert an X.25 subnetwork identifier to character string subnetwork identifier
Synopsis
#include <sys/snet/x25_proto.h> #include <xnetdb.h> int x25tosnid (snid, str_snid)
unsigned long snid; unsigned char *str_snid;
Description
The x25tosnid routine converts a subnetwork identifier, snid, represented as an unsigned long to a character string, str_snid. The character string str_snid should be at least 5 characters long. On a successful return, str_snid contains a string representation of the subnetwork identifier.
See Also
snidtox25(3N)
115
Diagnostics
If the routine is successful, it returns 0. On failure, it returns -1.
Network Files
lapbtemplate
Name
lapbtemplate - description of LAPB configuration file
Description
A LAPB configuration file contains 16 lines of various parameters. Configuration of the lapb driver is performed by lltune using files with this format. These parameters are detailed below: N2_VAL Maximum number of times that a Protocol Data Unit is sent following the expiration of the Acknowledgement Timer, the P-bit timer, or the Reject Timer. It also limits the number of times an RR with the P-bit set is sent when remote busy is true and the Busy timer expires. The standard value for this parameter is 10; the permitted range is 1 - 255. The time during which the LAPB expects to receive an acknowledgement to an outstanding I Protocol Data Unit(PDU) or an expected response to a sent unnumbered PDU. The value is specified in 0.1 second units. The standard value for this parameter is 10; the permitted range is 1 - 3000. At slower line speeds, the T1 timer must be increased for proper operation, especially with large packet sizes. Some recommendations for the value of T1_VAL at 9600 bps are listed below. Packet Size 0-896 897-1536 1537-2048 above 2048 TPF_VAL T1 (seconds) 3 6 9 14 T1_VAL 30 60 90 140
T1_VAL
The time during which the LAPB expects to receive a PDU with the F-bit set to 1 in response to a command with the P-bit set to 1. Value is in 0.1 second units and should be less than the value specified for the Acknowledgement Timer. The standard value is 7; the permitted range is 1 - 3000. The time interval during which the LAPB expects to receive a reply to a sent REJ TPDU. Value is in 0.1 second units. The standard value is 25; the permitted range is 1 - 10000. The time interval during which the LAPB waits for an indication of the clearance of a busy condition at the other LAPB. Value is in 0.1 second units. The standard value is 100; the permitted range is 1 - 30000.
TREJ_VAL
TBUSY_VAL
116
Network Files
IDLE_VAL
The time during which the LAPB expects to receive a PDU from the other LAPB. If it expires then the P/F cycle is initiated which may result in link disconnection. Value is in 0.1 second units. The standard value is 250; the permitted range is 0 - 32000. A value of zero will disable this function. The maximum delay in 0.1 second units before transmitting a delayed RR. This must be considerably less than the Acknowledgement Timer value. The standard value is 4; the permitted range is 0 - 3000. The maximum number of unacknowledged received I PDUs before the RR acknowledging them all must be sent. The standard value is 3; the permitted range is 0 - 127.
ACK_DELAY
NOTACK_MAX
TX_WINDOW
The number of unacknowledged I PDUs which may be sent. In normal mode, when Modulo 8 sequence numbering is used: the standard value is 7; the permitted range is 1 - 7. In extended mode, when Modulo 128 sequence numbering is used: the standard value is 7; the permitted range is 1 - 127.
TX_PROBE
The position before the window is closed at which an I PDU is sent with the Pbit set to solicit an acknowledgement from the receiver. In normal mode, when Modulo 8 sequence numbering is used: the standard value is 0; the permitted range is 0 - 7. In extended mode, when Modulo 128 sequence numbering is used: the standard value is 0; the permitted range is 0 - 127.
MAX_I_LEN
Maximum size of LAPB I frame. LAPB requires all incoming I frames above a certain size to be rejected by a FRMR. This parameter specifies the maximum size. It is constructed as (maximum X.25 data size + X.25 protocol length + LAPB protocol length). The standard value for this parameter is 261. Permitted values are: 261 - 263, 517 - 519, 1029 - 1031, 2053 - 2055, and 4101 - 4103. When the connection is in ERROR state, ignore any UA frames received. Enter 'Y' if yes, 'N' if no.
IGN_UA_ERROR
FRMR_FRMR_ERROR When the connection is in ERROR state, re-transmit a frame reject if a frame reject is received. Enter 'Y' if yes, 'N' if no. FRMR_INVRSP_ERROR When the connection is in ERROR state, transmit a frame reject if an invalid frame response is received. Enter 'Y' if yes, 'N' if no. SFRAME_PBIT Send a frame reject if an S-Frame is received without the P-bit set. Enter 'Y' if yes, 'N' if no. NO_DM_ADM Send a DM on entry to ADM state after an N2 count expiration. Enter 'Y' if yes, 'N' if no.
117
SABM_IN_X32 This parameter determines whether the link registration procedure is abandoned if a SABM(E) is received during registration. Enter 'Y' if yes, 'N' if no.
See Also
lltune(1M)
netconf
Name
netconf - network configuration file
Description
The netconf file describes the configuration of the STREAMS network constructed by netd(1M). The mknetconf utility automatically configures a netconf file after asking configuration questions from the user. The netconf file it makes can then be copied to the /etc directory. This utility is helpful when changes must be made to the netconf file. The file is in two sections, separated by a line consisting of the character sequence '%%'. Blank lines may be used freely throughout the file, and a token (see below) beginning with an unquoted '#' (hash) denotes a comment which lasts till the end of the line. In addition, a backslash ( \ ) immediately preceding the end of a line results in the newline being treated as whitespace (except at the end of comment lines). Tokens can be any of the following:
single occurrence of the special characters { =, {, ,, } }
Note: = is not a special character within the brace-enclosed argument list of a control message; , is only a special character in this position.
strings of arbitrary characters enclosed in single or double quotes (''' or '"'), but not containing a newline - each quoting character quotes the other, for example, foo 'bar' or '"foo bar' Newlines occurring within quoted strings will silently terminate the string.) Sequences of non-whitespace characters not including any of the special characters or quotes All strings are case-sensitive, and are silently truncated to 200 characters.
The modules section describes the individual modules and drivers from which the STREAMS network configuration will be built. x25 lapb wan0 wan1 dc dc d d 0 0 0 1 /dev/ucsclone /dev/ucsclone /dev/ucsclone /dev/ucsclone 0 0 0 0 mps mps mps mps x25 lapb wan wan
118
Network Files
Each line (such as the examples above) consists of seven tokens (separated by whitespace) as follows. The module identifier is the name by which the module or driver will be known in the streams section (see below). The module type is a sequence of character flags describing the module or driver. The flag 'd' describes a STREAMS driver, whereas 'm' describes a module. The 'c' flag specifies a driver to be cloneable. (See the UNIX STREAMS Programmer's Guide for a detailed description of modules and drivers.) The device number is the value passed to the module or driver in the dev parameter of the open request. For x25 and lapb, it should always be 0. For wan, it specifies the serial link number. The next field contains the device name for a local installation (in a host backplane), or the server name from the hosts database in the etc directory for a LAN installation. The controller number specifies a board in the backplane or in the LAN server. For a local installation, the service name should always be mps. For a LAN server, specify the TCP service name for the PT server from the services database in the etc directory. The module name is the protocol name for a driver, or the pushable module name for a module. The streams section describes the architecture of the network in terms of how the previously defined modules and drivers are to be combined (by means of the appropriate PUSHes and LINKs) into streams. Multiplexing and cloning are handled automatically by the netd(1M) utility. x25 lapb0 SHELL="x25tune -P -s A -d 0 -t server \ -c 0 def.dte.x25 \ X25_SET_SNID={A, LC_LAPBDTE, , } Lines in this section (such as the above example) are of the following form. The first two tokens on a line are names (module identifiers as defined in the previous section) of drivers or modules which are to form the upstream and downstream components respectively of a STREAMS link. Each link performed between token 1 and token 2 generates a mux_id identifier) which is associated with that link. (multiplexing
These names may be qualified by a suffix consisting of a colon (:) and a number (for example arp:1 to signify a particular instantiation of a module. (An uninstantiated name is an abbreviation for name:0.) Each instantiation of a module can be thought of as a separate block in a STREAMS Architecture diagram. Separate instantiations would be appropriate for, say, a module pushed above more than one driver, but not for a cloneable multiplexed driver. Instantiations are used in the 'streams' section only, to instantiate modules defined in the 'modules' section. The remainder of each line consists of a (possibly null) sequence of control actions to be performed on completion of the link in the order specified.
119
Each control action is of the form function = argument-list, where the argument-list is either a single string argument or a comma-separated list enclosed in braces ({ and }). Control actions requiring no arguments may consist simply of the function component. Arguments containing whitespace or any of the special characters listed above must be quoted. The following three control actions are currently defined:
1. LL_SET_SNID={subnet_id, LL_class} The LL_SET_SNID control function registers the subnetwork identifier, subnet_id, with the link defined in this text line. The subnetwork identifier provides a unique name for a port on the server and its associated higher level streams. Subnetwork identifiers are from one to four characters in length and are a mandatory parameter. The LL_class can be one of the following;
LC_LAPBDTE LC_LAPBXDTE LC_LAPBDCE LC_LAPBXDCE
LAPB LAPB LAPB LAPB
DTE DTE and extended (modulo 128) operation DCE DCE and extended (modulo 128) operation
See the netconf files provided with your software for examples. 2. X25_SET_SNID={subnet_id, SAP, max_conid} The X25_SET_SNID control function registers the subnetwork identifier, subnetid, with the link defined in this text line, the SAP to be associated with this subnetwork, and that maximum number of DL_CONNECT_IND primitives that can be accepted on a listen stream. For X.25 running over LAPB (our case), there is exactly one stream per subnetwork, so the value for max_conid is always one. See the netconf files provided with your software for examples. 3. SHELL=command string The SHELL control function allows calls to the shell. Utilities may be called at an intermediate stage in the building of the STREAMS network. See the netconf files provided with your software for examples. A special dummy link exists, where no link is formed, but the control action is executed. This occurs when token 2 is a hyphen ( '-' ). For example:
x25
SHELL=pvcmap -P
which is simply a shell call to execute pvcmap.
Files
netconf in the etc directory
See Also
mknetconf(4), netcreate(1M), netd(1M), pvcmap(1M), hosts(4). STREAMS Programmer's Guide.
120
Network Files
nuimapconf
Name
nuimapconf - Network User Identifier and associated facilities data base
Description
The nuimapconf file contains information regarding the mapping between Network User Identifiers and associated facilities. It is loaded into the X.25 driver by nuimap(1M) and is stored in a hash table. When a call is made with NUI override subscribed to (see x25template(4)) and an NUI specified, the facilities associated with that NUI will be taken from this data base (loaded in X.25) and will override the configured default values for the duration of the call. Each line should contain the following:
Network User Identifier Associated Facilities
Example file: firstnui andasecond p7/7,w4/4g,b o,t5/5
Items are separated by any number of spaces and/or tab characters. The Network User Identifier (NUI) is a string of up to 64 alphanumeric characters used to identify a call for the purposes of security or billing. The Associated Facilities field is a string of parameter values and subscription options. Components of the string take the following format: e p M / N w M / N t M / N g o b x Subscribe to extended format packets Local and remote packet size (M,N in range 4 to 12) Local and remote window size (M,N in range 1 to 127) Local and remote window size (M,N in range 0 to 15) Subscribe to Closed User Groups (CUGs) Subscribe to CUGs with outgoing access. Only one of g or o may be selected per NUI Subscribe to CUGs with basic format (that is, this DTE may subscribe to up to 100 CUGs) Subscribe to CUGs with extended format (that is, this DTE may subscribe to up to 10000 CUGs). Only one of b or x may be selected per NUI.
In the example above, firstnui is associated with a default packet size of 7 and a window size of 4 in each direction, and subscription to Closed User Groups with basic format. Each component of the facilities string is either null or comma separated.
121
See Also
nuimap(1M), x25template(4)
pvcmapconf
Name
pvcmapconf - Permanent Virtual Circuit packet and window size database
Description
The pvcmapconf file contains information regarding PVCs whose packet and window sizes are different than the defaults configured for the subnetwork on which the PVC is active. It is loaded into the X.25 driver by pvcmap and is stored in the internal X.25 virtual circuit table. Each line should contain the following:
Subnetwork Identifier Logical Channel Identifier Local Packet Size Remote Packet Size Local Window Size Remote Window Size
Example file: A B 5 1 128 512 128 128 7 7 7 2
Items are separated by any number of spaces and/or tab characters. The Subnetwork Identifier is used to identify the subnetwork that the PVC exists on. It should have a value in the range A-Za-z0-9. The Logical Channel Identifier specifies the logical channel that the PVC is assigned to. It is represented by three hex digits in the range 001-FFF. The local and remote packet size may be one of 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 bytes. The local and remote window size is an integer in the range 1-127.
See Also
pvcmap(1M)
122
Network Files
subnetworks
Name
subnetworks - X.25 subnetwork and alias database
Description
The subnetworks file specifies which calling address to use when making a call on a particular subnetwork. Each calling address contains a unique subnetwork identifier. For each subnetwork, a single line should be present with the following information:
calling address subnetwork name subnetwork description
For example: A.2342 PSS Subnetwork for PSS network Items are separated by any number of blanks and/or tab characters. A '#' indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines which search the file. The calling address should be an X.25 dot format address and only one calling address should be given per subnetwork. The name should be two or more characters. Entries can be taken from the subnetworks file in the etc directory using the routines in getsubnetent (3N).
Files
subnetworks in the etc directory
See Also
getsubnetent(3N), x25addr(5)
123
wanmapconf
Name
wanmapconf - WAN remote address and interface address data base
Description
The wanmapconf file contains information regarding the mapping between the remote addresses of network hosts and underlying interface addresses. It is loaded into the WAN driver by wanmap and is stored in the WAN internal address table. Each line should contain the following: Remote Address Example file: 12345678901234 uk.co.host 12342342432 Interface Address 0101444568765 2323,1223233,2233442332323 uk.ac.host
Items are separated by any number of spaces and/or tab characters. A '#' indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines which search the file. The Remote Address may be either a destination name or X.121 address. The Interface Address follows the format for the corresponding interface.
See Also
wanmap(1M)
wantemplate
Name
wantemplate - description of WAN configuration file
Description
A WAN configuration file contains a set of parameters, each on a separate line, which are used by wantune to configure the WAN driver. The parameters are detailed below: WAN_maxframe Maximum size of WAN frame. The standard value for this parameter is 262. Permitted values are: 262 - 264, 518 - 520, 1030 - 1032, 2054 - 2056, and 4102 - 4104.
124
Network Files
WAN_baud
The baud rate, in units of bits per second, defining the speed of the WAN line. A baud rate of -1 configures the link for external clocking, meaning that the transmit clock must be supplied by an external device (such as a modem). All other baud rates configure the link for internal clocking, meaning that the baud rate generator on the controller or server supplies the transmit clock. In either case, the receive clock signal is configured as an input (supplied by the transmitting device or other external device). Note:This parameter does not apply to T1/E1 controller cards. Refer to Chapter 4 of the MPS Software and Hardware Installation Manual for information about configuration of these types of controllers.
WAN_auto_start When the netd program interprets the X25-SET_SNID control action from the netconf file, the server software examines the WAN_auto_start parameter. If the parameter is Y, the server tries to establish communications at the link layer. If the parameter is N, an explicit W_ENABLE must be sent by application code for each subnetwork to request that the link layer communications be established. The W_ENABLE must be sent after the X25_SET_SNID is completed. The default setting is Y. This parameter is provided for applications that require control over the link layer. WAN_connect_proc This parameter specifies the calling procedures (V21 or V25) to use. This parameter should always be set to '0', indicating no calling parameters used. WAN_v25_callreq A timeout which is used if the network does not support call fail indications. This parameter should always be set to zero. WAN_encoding Specifies the type of HDLC encoding to be used for the serial line, as follows: 0 = NRZ (Standard) 1 = NRZI Quicc-based hardware platforms also support: 2 = FM0 3 = FM1 4 = Manchester 5 = Differential Manchester 6 = NRZ (with embedded clock) 7 = NRZI (with embedded clock)
125
WAN_phylf
This parameter configures the physical interface of a CPC358. It is ignored by all other products. The supported interfaces and their respective values are: 0 = V.11 1 = RS530A 2 = RS530 3 = X.21 4 = V.35 5 = RS449 6 = RS232 7 = HIZ
See Also
wantune(1M)
x25conf
Name
x25conf - X.25 subnetwork description file
Description
The x25conf file contains configured information about all subnetworks directly below the X.25 multiplexor-driver (see x25(7)). The mknetconf utility automatically configures an x25conf file after asking configuration questions from the user. The x25conf file it makes can then be copied to the /etc directory. This utility is helpful when changes must be made to the x25conf file. Each entry in x25conf should contain the following information:
Device Prefix Alias Class Subnetwork Identifier Net Type X.25 Template Mlp Template X.25 Address nsap Description
126
Network Files
Example file: wans line0 - A WAN84 def.dce84.x25 - 100000001wans line1 - B WAN84 def.dte84.x25 - 100000002Tokens are separated by any number of spaces and/or tab characters. The Device Prefix specifies the WAN subnetwork (wans). The Alias specifies a user-friendly name associated with the line. The Class describes the class of the lower X.25 interface to a particular subnetwork (always ). The Subnetwork Identifier is an alphanumeric string (up to 4 characters) providing a logical administrator-selected descriptor for each subnetwork below the X.25 driver. Subnetwork Identifiers must be unique within each node. The Net Type describes the type of the particular subnetwork. It may be one of:
WAN80 - Wide Area Network 1980 WAN84 - Wide Area Network 1984 WAN88 - Wide Area Network 1988
The X.25 Template File refers to an appropriate configuration file for this particular subnetwork. It contains the name of an X.25 configuration file (see x25template(4)). The MLP Template File refers to the name of an appropriate MLP configuration file for this particular subnetwork (always-). The X.25 Address is a DTE address (of between zero and fifteen BCD digits). Any token in an entry may be a question mark ? meaning not configured. If any entry contains such a token, then the entire entry will be ignored by netcreate. A Description is prefaced by the # character. This indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines which search the file.
Files
x25conf in the etc directory
See Also
lapbtemplate(4), wantemplate(4), x25template(4), x25(7), mknetconf(4)
x25template
Name
x25template - description of X.25 configuration file
127
Description
An X.25 configuration file consists of 84 parameters, one per line. Each parameter description (below) has three parts:
A number, which corresponds to the line in the configuration file which holds the parameter, The name which the parameter is known by, The description of the parameter.
Only the value of each parameter (not the line number, parameter name or description) actually appears in the configuration file. The parameters are described below: NET_MODE NET_MODE determines the various characteristics of the network protocol. Valid values are integers, as specified below, which refer to the networks listed: X25_88 X25_80 DATAPAC 2 4 7 X25_84 PSS DDN 5 8 3 AUSTPAC TELENET 11 6 9
TRANSPAC 10 DDX_P ITAPAC DCS FINPAC 13 16 19 22
TYMNET
DATEX_P 12 ACCUNET 15
VENUS_P 14 DATAPAK 17 TELEPAC 20 PACNET 23
DATANET 18 F_DATAPAC 21 LUXPAC 24
X25_VERSION X25 Version determines the version of the X.25 protocol which is being used over the network. '80' - indicates 1980 '84' - indicates 1984 '88' - indicates 1988 L3PLPMODE L3PLPMODE indicates the DTE/DCE nature of the link. 0' - indicates DCE, '1' - indicates DTE, '2' - indicates DXE - resolved using ISO 8208 for DTE-DTE operation. LPC LPC to HPC (below) is the range of Permanent Virtual Circuits (PVCs). LPC is represented by three Hex digits (max is FFF). Setting LPC to zero means there are no PVCs. To define a range of PVCs, LPC must be greater than zero and must consist of three Hex digits.
128
Network Files
HPC LIC
LPC (above) to HPC is the range of Permanent Virtual Circuits (PVCs). HPC is represented by three Hex digits (max is FFF). LIC to HIC (below) is the range of one-way incoming logical channels. LIC is represented by three Hex digits (max is FFF). Setting both LIC and HIC to zero means there are no one-way incoming logical channels. LIC (above) to HIC is the range of one-way incoming logical channels. HIC is represented by three Hex digits (max is FFF). LTC to HTC (below) is the range of two-way incoming logical channels. LTC is represented by three Hex digits (max is FFF). Setting both the LTC and HTC to zero means there are no two-way logical channels. LTC (above) to HTC is the range of two-way logical channels. HTC is represented by three Hex digits (max is FFF). LOC to HOC (below) is the range of one-way outgoing logical channels. LOC is represented by three Hex digits (max is FFF). Setting both the LOC and HOC to zero means there are no one-way outgoing logical channels. LOC (above) to HOC is the range of one-way outgoing logical channels. HOC is represented by three Hex digits (max is FFF). THISGFI Indicates whether Modulo 8 or 128 sequence numbering operates on the network. It takes one of two values: 8 128 Modulo 8 Modulo 128
HIC LTC
HTC LOC
HOC THISGFI
LOCMAXPKTSIZE LOCMAXPKTSIZE is the maximum size of data packets in the direction localto-remote which are acceptable. That is, on any incoming X.25 call, a value for the packet size parameter greater than LOCMAXPKTSIZE will be negotiated down to this value when the call is accepted. The packet size is specified as a power of two, in the range 7 to 12, inclusive. This gives a range for the data packet size of 128 to 4096 octets. Ensure that LOCMAXPKTSIZE is less than your LAPB I frame size (see lapbtemplate(4)). REMMAXPKTSIZE REMMAXPKTSIZE is the maximum size of data packets in the direction remote-to-local which are acceptable. That is, on any incoming X.25 call, a value for the packet size parameter greater than REMMAXPKTSIZE will be negotiated down to this value when the call is accepted. The packet size is specified as a power of two, in the range 7 to 12, inclusive. This gives a range for the data packet size of 128 to 4096 octets. Ensure that REMMAXPKTSIZE is less than your LAPB I frame (see lapbtemplate(4)).
129
LOCDEFPKTSIZE On a particular subnetwork, LOCDEFPKTSIZE specifies the value of the default packet size for the direction local-to-remote, which may be nonstandard, provided the value is agreed between all communicating parties on the LAN or between the DTE and DCE. The packet size is specified as a power of two, in the range 7 to 12, inclusive. This gives a range for the data packet size of 128 to 4096 octets. The usual standard value is 7 implying a default data packet size for each direction of transmission of 128 octets. REMDEFPKTSIZE On a particular subnetwork, REMDEFPKTSIZE specifies the value of the default packet size for the direction remote-to-local, which may be nonstandard, provided the value is agreed between all communicating parties on the LAN or between the DTE and DCE. The packet size is specified as a power of two, in the range 7 to 12, inclusive. This gives a range for the data packet size of 128 to 4096 octets. The usual standard value is 7 implying a default data packet size for each direction of transmission of 128 octets. LOCMAXWSIZE LOCMAXWSIZE selects the maximum size of the X.25 window which is acceptable. That is, on any incoming X.25 call, a value for the window size parameter greater than LOCMAXWSIZE will be negotiated down to this value when the call is accepted. For Modulo 8 networks, LOCMAXWSIZE must be between 2 and 7 while for Modulo 128, the range is 2 to 127. REMMAXWSIZE REMMAXWSIZE selects the maximum size of the X.25 window which is acceptable. That is, on any incoming X.25 call, a value for the window size parameter greater than REMMAXWSIZE will be negotiated down to this value when the call is accepted. For Modulo 8 networks, REMMAXWSIZE must be between 2 and 7 while for Modulo 128, the range is 2 to 127. LOCDEFWSIZE On a particular subnetwork, LOCDEFWSIZE specifies the value of the default window size, which may be nonstandard provided the value is agreed between all communicating parties on the LAN or between the DTE and DCE. The usual standard value is 2. Note:The sequence numbering scheme (THISGFI), Modulo 8 or 128 affects the range of this parameter. For Modulo 8 networks, the range for LOCDEFWSIZE is 1 to 7, while for Modulo 128 the range is 1 to 127. REMDEFWSIZE On a particular subnetwork, REMDEFWSIZE specifies the value of the default window size, which may be nonstandard provided the value is agreed between all communicating parties on the LAN or between the DTE and DCE. The usual standard value is 2.
130
Network Files
Note:The sequence numbering scheme (THISGFI), Modulo 8 or 128 affects the range of this parameter. For Modulo 8 networks, the range for LOCDEFWSIZE is 1 to 7, while for Modulo 128 the range is 1 to 127. MAXNSDULEN MAXNSDULEN specifies a default maximum length beyond which concatenation of data packets with the more data flag (M-bit) set will be stopped and the data currently held will be passed to the NS user. The maximum value for this parameter is 32000. ACKDELAY specifies the maximum number of ticks (0.1 second units) over which a pending acknowledgement is withheld. This specifies, in number of ticks (0.1 second units), the DTE timer parameter T20, the Restart Request Response Timer. When you are configuring a DCE, this parameter is the DCE timer parameter T10. The standard value for this parameter is 1800; the permitted range is 0 - 32000. This specifies, in number of ticks (0.1 second units), the DTE timer parameter T21, the Call Request Response Timer. When you are configuring a DCE, this parameter is the DCE timer parameter T11. The standard value for this parameter is 2000; the permitted range is 0 - 32000. This specifies, in number of ticks (0.1 second units), the DTE timer parameter T22, the Reset Request Response Timer. When you are configuring a DCE, this parameter is the DCE timer parameter T12. The standard value for this parameter is 1800; the permitted range is 0 - 32000. This specifies, in number of ticks (0.1 second units), the DTE timer parameter T23, the Clear Request Response Timer. When you are configuring a DCE, this parameter is the DCE timer parameter T13. The standard value for this parameter is 1800; the permitted range is 0 - 32000. TVALUE is related, but does not correspond exactly, to the DTE Window Status Transmission Timer, T24. It specifies, in number of ticks (0.1 second units), the maximum time during which acknowledgements of data received from the remote transmitter will be withheld. When the timer expires, any withheld acknowledgements will be carried by an X.25 level 3 'Receiver-NotReady' control packet. The standard value for this parameter is 750; the permitted range is 0 - 32000. This specifies, in number of ticks (0.1 second units), the DTE timer parameter T25, the Window Rotation Timer. The standard value for this parameter is 1500; the permitted range is 0 - 32000. This specifies, in number of ticks (0.1 second units), the DTE timer parameter T26, the Interrupt Response Timer. The standard value for this parameter is 1800; the permitted range is 0 - 32000. This specifies, in number of ticks (0.1 second units), the DTE timer parameter T28, the Registration Request Timer. The standard value for this parameter is 1800; the permitted range is 0 - 32000. The Idle Value is the number of ticks (0.1 second units), during which a linklevel connection associated with no connections will be maintained. This parameter should always be set to zero (infinity).
ACKDELAY T20VALUE
T21VALUE
T22VALUE
T23VALUE
TVALUE
T25VALUE
T26VALUE
T28VALUE
IDLEVALUE
131
CONNECTVALUE Connect value specifies the number of ticks (0.1 second units), over which the DTE/DCE resolution phase be complete - implemented in order to prevent the (unlikely) event that the two packet level entities cannot resolve their DTE/ DCE nature. When this expires, the link connection will be disconnected and all pending connections aborted. The standard value for this parameter is 2000; the permitted range is 0 - 32000. R20VALUE R22VALUE R23VALUE R28VALUE LOCALDELAY R20 value specifies the DTE Restart Request Retransmission Count. The standard value for this parameter is 1; the permitted range is 1 - 255. R22 value specifies the DTE Reset Request Retransmission Count. The standard value for this parameter is 1; the permitted range is 1 - 255. R23 value specifies the DTE Clear Request Retransmission Count. The standard value for this parameter is 1; the permitted range is 1 - 255. R28 value specifies the DTE Registration Request Retransmission Count. The standard value for this parameter is 1; the permitted range is 1 - 255. LOCAL DELAY is, in milliseconds, the transit delay attributed to internal processing. The standard value for this parameter is 5; the permitted range is 0 - 32000. ACCESS DELAY is, in milliseconds, the transit delay attributed to the effect of the line transmission rate. The standard value for this parameter is 5; the permitted range is 0 - 32000. LOCMAXTHCLASS LOCMAXTHCLASS is the maximum value of the throughput class Quality Of Service parameter which is supported. According to ISO 8208 this parameter must be between 3 and 12, corresponding to a range of 75 to 48000 bits/ second. REMMAXTHCLASS REMMAXTHCLASS is the maximum value of the throughput class Quality Of Service parameter which is supported. According to ISO 8208 this parameter must be between 3 and 12, corresponding to a range of 75 to 48000 bits/ second. LOCDEFTHCLASS In some networks, for example, TELENET, negotiation of throughput class is constrained to be towards a configured default throughput class. In such cases the flag tcneg_to_default (see below) is non-zero and LOCDEFTHCLASS is the default. In other PSDN's, LOCDEFTHCLASS should be set equal to the value of LOCMAXTHCLASS. Note that LOCMAXTHCLASS is greater than or equal to LOCDEFTHCLASS.
ACCESSDELAY
132
Network Files
REMDEFTHCLASS In some networks, for example, TELENET, negotiation of throughput class is constrained to be towards a configured default throughput class. In such cases the flag tcneg_to_default (see below) is non-zero and REMDEFTHCLASS is the default. In other PSDN's, REMDEFTHCLASS should be set equal to the value of REMMAXTHCLASS. Note that REMMAXTHCLASS is greater than or equal to REMDEFTHCLASS. LOCMINTHCLASS According to ISO 8208, the throughput class parameter is defined in the range of 3 to 12. Some PSDN's may provide a different mapping, in which case LOCMINTHCLASS is the minimum value. Note that LOCMINTHCLASS must be less than or equal to LOCMAXTHCLASS and LOCDEFTHCLASS. REMMINTHCLASS According to ISO 8208, the throughput class parameter is defined in the range of 3 to 12. Some PSDN's may provide a different mapping, in which case REMMINTHCLASS is the minimum value. Note that REMMINTHCLASS must be less than or equal to REMMAXTHCLASS and REMDEFTHCLASS. SUB_CUG SUB_PREF SUB_CUGOA SUB_CUGIA CUG_FORMAT CUG_FORMAT defines the maximum number of Closed User Groups that this DTE subscribes to. This will be one of two ranges: Basic (100 or fewer) or Extended (between 101 and 10000). Enter '0' for Basic or '1' for Extended. BAR_CUG_IN This flag provides the means to force rejection of any incoming calls carrying the Closed User Group optional facility (which is necessary in some networks) for example DDN. When this parameter value is 'Y', such calls will be rejected; otherwise ('N') incoming Closed User Group facilities are ignored. Subscribe to extended call packets (Window and Packet size negotiation is permitted). Enter 'Y' if yes, 'N' if no. Setting this parameter to 'Y' permits the use of extended CALL REQUEST and CALL ACCEPT packets. BAR_EXTENDED Treat window and packet size negotiation in incoming packets as a procedure error. Enter 'Y' if yes, 'N' if no. Setting this parameter to 'N' permits the use of extended INCOMING CALL and CALL CONFIRM packets. SUB_FSELECT Subscribe to fast select with no restriction on response. Enter 'Y' if yes, 'N' if no. This specifies whether or not this DTE subscribes to Closed User Groups with no Outgoing or Incoming Access. This specifies whether or not this DTE subscribes to a Preferential Closed User Group. Enter 'Y' if yes, 'N' if no. This specifies whether or not this DTE subscribes to Closed User Groups with Outgoing Access. Enter 'Y' if yes, 'N' if no. This specifies whether or not this DTE subscribes to Closed User Groups with Incoming Access. Enter 'Y' if yes, 'N' if no.
SUB_EXTENDED
133
SUB_FSRRESP Subscribe to fast select with restriction on response. Enter 'Y' if yes, 'N' if no. SUB_REVCHARGE Allow incoming calls to specify the reverse charging facility. Enter 'Y' if yes, 'N' if no. SUB_LOC_CHG_PREV Subscribe to local charging prevention. Enter 'Y' if yes, 'N' if no. BAR_INCALL BAR_OUTCALL Bar outgoing calls. Enter 'Y' if yes, 'N' if no. SUB_TOA_NPI_FMT subscribe to TOA/NPI Address Format. Enter 'Y' if yes, 'N' if no. BAR_TOA_NPI_FMT Bar incoming call set-up and clearing packets which use the TOA/NPI Address Format. Enter 'Y' if yes, 'N' if no. SUB_NUI_OVERRIDE Subscribe to NUI Override. Enter 'Y' if yes, 'N' if no. BAR_CALL_X32_REG Bar outgoing calls while the X.32 registration is in progress. If this is set to N, then call request packets are transmitted over the network even when the registration process is under wan. Enter 'Y' if yes, 'N' if no. ACC_NODIAG USE_DIAG Allow the omission of the diagnostic byte in incoming RESTART, CLEAR and RESET INDICATION packets. Enter 'Y' if yes, 'N' if no. Use diagnostic packets. Enter 'Y' if yes, 'N' if no. Bar incoming calls. Enter 'Y' if yes, 'N' if no.
CCITT_CLEAR_LEN Restrict the length of a CLEAR INDICATION to 5 bytes and a CLEAR CONFIRM to 3 bytes. (This parameter applies to 1980 networks only.) Enter 'Y' if yes, 'N' if no or not a 1980 network. BAR_DIAG Bar diagnostic packets. Enter 'Y' if yes, 'N' if no.
DISC_NZ_DIAG Discard diagnostic packets on a non-zero LCN. Enter 'Y' if yes, 'N' if no. ACC_HEX_ADD Allow DTE addresses to contain hexadecimal digits. Enter 'Y' if yes, 'N' if no. BAR_NONPRIV_LISTEN Disallow a non-privileged user (i.e., one without superuser privilege) from listening for incoming calls. Enter 'Y' if yes, 'N' if no. INTL_ADDR_RECOGN INTL_ADDR_RECOGN determines whether outgoing international calls are to be accepted. The values and their interpretation are: 0 - International calls are NOT distinguished,
134
Network Files
1 - The DNIC of the called DTE address is examined and compared to that held in the psdn_local members dnic1 and dnic2. A mismatch implies an international call. 2 - International calls are distinguished by having a '1' prefix on the DTE address eg. DATAPAC has this feature. 3 - International calls are distinguished by having a '0' prefix on the DTE address. The main use of this field is in conjunction with the INTL_PRIORITIZED field discussed below. INTL_PRIORITIZE INTL_PRIORITIZED determines whether some prioritization method is to be used for international calls and is used in conjunction with PRTY_ENCODE_CONTOL and PRTY_PKT_FORCED value. It has two values: 'N': implies no priority. 'Y': implies an attempt to prioritize according to PRTY_ENCODE_CONTROL. DNIC This field contains the first four BCD digits of DNIC and is only used when INTL_ADDR_RECOGN has the value one. This field must contain exactly four BCD digits.
PRTY_ENCODE_CONTROL This entry describes how the priority request is to be encoded for this PSDN. The following are currently valid: 0 - No action taken, 1 - Encode the priority request using the DATAPAC priority bit(1976 version). 2 - Encode the priority request using the DATAPAC Traffic Class (1980 version which employs Calling Network facility marker). PRTY_PKT_FORCED_VAL If this entry is non-zero all priority call requests and incoming calls should have the associated packet size parameter forced to this value. (Note that the actual packet size is 2 to the power of this parameter. For example, 7 implies 128-byte packets.) The permitted range is 4 to 12, or zero, implying no special action (the default packet size is to be used). SRC_ADDR_CONTROL SRC_ADDR_CONTROL provides a means to override or set the calling address in outgoing call requests for this PSDN. It takes the following values: 0 - No action. Calling DTEs are encoded as, and if, provided by the network service user. 1 - Force omission of the calling DTE address, even if the user supplied one. 2 - Force the calling DTE address to that contained in LOCAL_ADDRESS. 3 - Force the calling DTE address to that contained in LOCAL_ADDRESS, even if the network service user supplied one.
135
4 - No action. Calling DTEs are encoded with their Responder's Address in the Call Accept packet. DBIT_ACCEPT_IN The DBIT_ACCEPT_IN flag defines the action to take when a Call Accept is received with the D-bit set and there is no local D-bit support. It takes one of the following values: 0 - Leave the D-bit set and pass the packet on, 1 - Zero the D-bit and pass the packet on, 2 - Clear the call. DBIT_ACCEPT_OUT The DBIT_ACCEPT_OUT flag defines the action to take when the remote user sends a Call Accept with the D-bit set when the local user did not request use of the D-bit. It takes one of the following values: 0 - Leave the D-bit set and pass the packet on, 1 - Zero the D-bit and pass the packet on, 2 - Clear the call. DBIT_DATA_IN The DBIT_DATA_IN flag defines the action to take when a data packet is received with the D-bit set and the local user did not request use of the D-bit. It takes one of the following values: 0 - Leave the D-bit set and pass the packet on, 1 - Zero the D-bit and pass the packet on, 2 - Reset the call. DBIT_DATA_OUT The DBIT_DATA_OUT flag defines the action when the local user sends a data packet with the D-bit set, but the remote party has not indicated D-bit support. It takes one of the following values: 0 - Leave the D-bit set and pass the packet on, 1 - Zero the D-bit and pass the packet on, 2 - Reset the call. THCLASS_NEG_TO_DEF This accommodates certain network procedures which dictate that negotiation of throughput class must be towards the default value (e.g., TELENET), the default value being configured into the members LOCDEFTHCLASS and REMDEFTHCLASS. A non-zero value in this field requests use of this option, zero implies non-use.
136
Network Files
THCLASS_TYPE THCLASS_TYPE is a means by which throughput class encodings can be used to assign packet and window sizes (according to THCLASS_PMAP and THCLASS_WMAP). It should be noted that some implementations of X.25 do not use the X.25 packet and window negotiation but instead rely on mapping the throughput class to these parameters (see THCLASS_TYPE 1, 2 and 3). THCLASS_TYPE should be employed on such PSDNs. Note also that the values of LOCMAXTHCLASS and REMMAXTHCLASS may have an effect on what is achieved through the mapping. The values assigned to indicate the mapping are: 0 - No special action is to be taken on throughput class. 1 - Use only the low nibble of the through-put class parameter to map window and packet sizes in both directions. 2 - Use only the high nibble of the throughput class parameter to map window and packet sizes in both directions. 3 - Use both nibbles of the throughput class parameter to map window and packet sizes for the appropriate directions. Values 1, 2 and 3 are intended for use on special X.25 PSDN implementations. THCLASS_WMAP THCLASS_WMAP is the mapping between throughput class and a window parameter. An entry of zero in this table indicates that the currently set or default value is to be used. The value is required to be entered as 10 integers separated by commas or full-stops. Each integer (if not zero) should be in the range 1 to MAXWSIZE (where MAXWSIZE is the lower of LOCMAXWSIZE and REMMAXWSIZE), with the absolute maximum being 127. THCLASS_PMAP THCLASS_PMAP is the mapping between throughput class and a packet parameter. An entry of zero in this table indicates that the currently set or default value is to be used. The value is required to be entered as 10 integers separated by commas or full-stops. Each integer (if not zero) should be in the range 4 to MAXPKTSIZE (where MAXPKTSIZE is the lower of LOCMAXPKTSIZE and REMMAXPKTSIZE), with the absolute maximum being 12. PVCLCNS The PVCLCNS is an array, which will hold up to 36 individual LCN values (not necessarily continuous). A entry of zero in the first position of the array indicates that the function is inactive. LCN entries should be entered in ascending order separated by commas or full-stops. LCNs used with this feature should be within the range specified by the LPC and HPC parameters.
See Also
x25tune(1M), lapbtemplate(4)
137
xaddrf
Name
xaddrf - X.25 address structure
Synopsis
#include <sys/snet/x25_proto.h>
Description
The xaddrf structure has the following format: #define #define LSAPMAXSIZE NSAPMAXSIZE 9 20
struct lsapformat { unsigned char unsigned char };
lsap_len; lsap_add [LSAPMAXSIZE];
struct xaddrf { unsigned long sn_id; unsigned char aflags; struct lsapformat DTE_MAC; unsigned char nsap_len; unsigned char NSAP [NSAPMAXSIZE]; }; The members of the lsapformat structure are: lsap_len lsap_add The length of the MAC+SAP, DTE address (in semi-octets) or LCI as contained in the lsap_add field, and described below. The actual DTE address or PVC LCI as described above. It should be noted that this field can be empty.
The members of the xaddrf structure are: sn_id aflags The subnetwork identifier. This field can have a value of NSAP_ADDR, EXT_ADDR or PVC_LCI. A value of NSAP_ADDR in this field implies that an NSAP (OSI address) is present in the NSAP field. A value of EXT_ADDR implies that the address in the NSAP field should be encoded as an extended (non-OSI) address. A value of PVC_LCI implies that a LCI is contained in the DTE_MAC field.
138
Network Files
DTE_MAC
This field contains the DTE (up to 17 decimal digits if X.25(88) TOA/NPI addressing is used, 15 decimal digits otherwise), LSAP address (fixed length of 14 hexadecimal digits) or LCI (fixed length of 3 hexadecimal digits), as described above. The length (in semi-octets) of the NSAP or extended address. This may be zero if no address is present and must be zero if the DTE_MAC field represents an LCI. The NSAP or extended address as specified by the aflags field.
nsap_len
NSAP
See Also
getxhostent(3N), stox25(3N), x25tos(3N), x25addr(5)
xhosts
Name
xhosts - X.25 host name data base
Description
The xhosts file contains information regarding all known X.25 hosts. For each X.25 host, a single line should be present with the following information: X.25 address official host name aliases For example: 0.A.01234567890123.X.12 realist alias1 alias2 Items are separated by any number of blanks and/or tab characters. A '#' indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines which search the file. X.25 addresses are specified in the X.25 dot format prepended with the controller. An entry can be taken from the xhosts file in the etc directory using the routine getxhostent(3N). Host names may contain any printable character other than a field delimiter, newline, or comment character.
Files
xhosts in the etc directory
See Also
getxhostent(3N), stox25(3N)
139
Miscellaneous
X.25 Address Format
Name
X.25 address format
Description
An X.25 address, when provided as a string, has the following format: subnet_identifier.[ DTE|LCI ].[ NX|P ].[ NSAP|EXT ] The subnet_identifier is a single alphanumeric character which refers to the subnetwork accessed via a single physical link. DTE LCI N X P Data Terminal Equipment identifier, has between 0 and 17 decimal digits. Logical Channel Identifier. This has a fixed format of 3 hexadecimal digits and represents a PVC channel. indicates the fourth field is an NSAP. indicates the fourth field is an EXT. indicates the second field is a PVC logical channel. If the third field is empty this indicates that the fourth field (if present) will be an NSAP. NSAP EXT Network Service Access Point. This has between 0 and 40 hexadecimal digits. Address extension. This has between 0 and 40 hexadecimal digits.
The range of X.25 addresses is limited by the underlying network type. For each network type, possible X.25 addresses are as follows: Wide Area Network (X.25 1984/1988 Mode): subnet_id subnet_id.DTE subnet_id.DTE.N.NSAP subnet_id.DTE.X.EXT subnet_id..N.NSAP subnet_id..X.EXT subnet_id.DTE.NSAP subnet_id.DTE..NSAP subnet_id..NSAP subnet_id...NSAP subnet_id.LCI.P
140
Special Files
Wide Area Network (X.25 1980 Mode): subnet_id subnet_id.DTE subnet_id.LCI.P
See Also
getxhostent(3N), stox25(3N), x25tos(3N), xaddrf(4), xhosts(4)
Special Files
lapb
Name
lapb - STREAMS multiplexor-driver
Description
lapb is the STREAMS multiplexor-driver which provides the logical link control for Wide Area Networks as specified in Recommendation X.25 of the CCITT Yellow, Red and Blue Books. The multiplexor handles all standard LAPB (including Extended Operation) and LAP formats for 1980 and 1984 except those for Multilink operation. Each lower stream can operate either as a DTE or as a DCE. The multiplexor's upper interface is normally linked below X25, the network level multiplexordriver. Each of its lower streams is a link from the driver which supports the interface to one WAN outlet. The driver does not have any accessible user-level interface.
See Also
lltune(1M), lapbtemplate(4)
141
x25
Name
x25 - STREAMS network layer multiplexor-driver
Description
x25 is the STREAMS network layer multiplexor-driver which supports X.25, the connectionoriented protocol, and provides layer 3 of the 7 layer OSI model. The multiplexor's upper interface may be accessed by various STREAMS components providing different functions:
A STREAMS transport service; X.3, X.28, X.29 PAD module.
It also provides a direct interface to user processes for data transmission and reception. Each of its lower streams is a link to a LAPB driver (see lapb(7)) supporting CCITT X.25(80) Yellow Book, CCITT X.25(84) Red Book and CCITT X.25(88) Blue Book. The virtual call service and the permanent virtual circuit service are both supported.
See Also
x25tune(1M), x25conf(4), lapb(7)
142
Appendix A
Product Safety Information
Overview
This chapter provides safety information for the product.

This section provides safety information including:
Safety Precautions, on page 143 AC or DC Power Safety Warning, on page 145 DC Power Safety Warning (DC Powered Units), on page 145 Rack Mount Enclosure Safety, on page 146 General Safety Precautions, on page 146
Safety Precautions
Review the following precautions to avoid injury and prevent damage to this product, or any products to which it is connected. To avoid potential hazards, use the product only as specified. Read all safety information provided in the component product user manuals and understand the precautions associated with safety symbols, written warnings, and cautions before accessing parts or locations within the unit. Save this document for future reference. Caution: To Avoid Electric Overload: To avoid electrical hazards (heat shock and/or fire hazard), do not make connections to terminals outside the range specified for that terminal. See the product user manual for correct connections. Caution: To Avoid the Risk of Electric Shock: When supplying power to the system, always make connections to a grounded main. Always use a power cable with a grounded plug (third grounding pin). Do not operate in wet, damp, or condensing conditions. Caution: System Airflow Requirements: Platform components such as processor boards, Ethernet switches, etc., are designed to operate with external airflow. Components can be destroyed if they are operated without external airflow. Chassis fans normally provide external airflow when components are installed in compatible chassis. Filler panels must be installed over unused chassis slots so that airflow requirements are met. Please refer to the product data sheet for airflow requirements if you are installing components in custom chassis.
143
Caution: Microprocessor Heatsinks May Become Hot During Normal Operation: To avoid burns, do not allow anything to touch processor heatsinks. Caution: Do Not Operate Without Covers: To avoid electric shock or fire hazard, do not operate this product with any removed enclosure covers or panels. Caution: To Avoid the Risk of Electric Shock: Do not operate in wet, damp, or condensing conditions. Caution: Do Not Operate in an Explosive Atmosphere: To avoid injury, fire hazard, or explosion, do not operate this product in an explosive atmosphere. Caution: If Your System Has Multiple Power Supply Sources: Disconnect all external power connections before servicing. Warning: Power Supplies Must Be Replaced by Qualified Service Personnel Only. Caution: Lithium Batteries Are Not Field-Replaceable Units: There is a danger of explosion if a battery is incorrectly replaced or handled. Do not disassemble or recharge the battery. Do not dispose of the battery in fire. When the battery is replaced, the same type or an equivalent type recommended by the manufacturer must be used. Used batteries must be disposed of according to the manufacturers instructions. Return the unit to PT for battery service.
144
AC or DC Power Safety Warning

The AC or DC power cord is your units main AC or DC disconnecting device, and must be easily accessible at all times. Auxiliary AC or DC On/Off switches or circuit breaker switches are for power control functions only (NOT THE MAIN DISCONNECT). For your safety, use only a power cord with a grounded plug. The enclosure is also provided with a separate earth ground connection/stud. The earth ground connection should be installed prior to the application of power or peripheral connections and should never be disconnected while power or peripheral connections exist. To reduce the possibility of electric shock from a telephone or Ethernet system, plug your enclosure into the power source before making these connects. Disconnect these connections before unplugging your enclosure from the power source. Warning: Verify Power Cord and Outlet Compatibility. Check to ensure you are using the appropriate power cords for your power outlet configurations. Visit the following website for additional information: http://kropla.com/electric2.htm. Caution: Hot surface. Avoid contact: Surfaces are hot and may cause personal injury if touched.
DC Power Safety Warning (DC Powered Units)

Caution: This equipment has a connection between the earthed conductor of the DC supply circuit and the earthing conductor.
1. This equipment shall be connected directly to the DC supply system earthing electrode conductor or to a bonding jumper from an earthing terminal bar or bus to which the DC supply system earthing electrode is connected. 2. This equipment shall be located in the same immediate area (such as, adjacent cabinets) as any other equipment that has a connection between the earthed conductor of the same DC supply circuit and the earthing conductor, and also the point of earthing of the DC system. The DC system shall not be earthed elsewhere. 3. The DC supply source is to be located within the same premises as the equipment. 4. Switching or disconnecting devices shall not be in the earthed circuit conductor between the DC source and the point of connection of the earthing electrode conductor.
145
Rack Mount Enclosure Safety

Your enclosure may be intended for stationary rack mounting. Mount in a rack designed to meet the physical strength requirements of NEBS GR-63-CORE and NEBS GR 487. Your system may have multiple power sources. Disconnect all power sources and external connections/cables prior to installing or removing your system from a rack frame. Avoid Electric Overload: To avoid electric shock or fire hazard, only connect your system to an input voltage source as specified in the product user manual.
General Safety Precautions

This section is provided as a summary of the safety recommendations throughout this manual. PT recommends that all safety precautions be followed to prevent harm to yourself or to the equipment. Please follow all warnings marked on the equipment. Caution: To reduce the risk of fire, use only No. 26 AWG or larger telecommunications line cord for your outside cable connection. Belden ABAM No. 22 AWG is a typical selection. Ensure that the voltage and frequency of your power source matches the voltage and frequency inscribed on the equipment's electrical rating label. Never push objects of any kind through the openings in the equipment. Dangerous voltages may be present. Conductive foreign objects could produce a short circuit that could cause fire, electrical shock, or damage the equipment. Electrostatic Discharge Caution: Electronic components on printed circuit boards are extremely sensitive to static electricity. Ordinary amounts of static electricity generated by your clothing or work environment can damage the electronic equipment. It is recommended that anti-static ground straps and antistatic mats are used when installing the board in a system to help prevent damage due to electrostatic discharge.
146
Appendix B
NLI Events
Table B-1, Downstream Messages and Associated Outgoing X.25 Packets, shows information about outgoing Network Layer Interface (NLI) events. Table B-1: Downstream Messages and Associated Outgoing X.25 Packets Downstream Messages
N_CI N_CC N_Data N_DAck N_EData N_EAck N_RI N_RC N_DI
Outgoing X.25 Packets

Call Request Call Accept Data Data Acknowledgement Interrupt Interrupt Confirmation Reset Request Reset Confirmation Clear Request
Table B-2, Upstream Messages and Associated Incoming X.25 Packets, shows information about incoming Network Layer Interface (NLI) events. Table B-2: Upstream Messages and Associated Incoming X.25 Packets Upstream Messages
N_CI N_CC N_Data N_DAck N_EData N_EAck N_RI N_RC N_DI N_DC
Incoming X.25 Packets

Incoming Call Call Connect Data Data Acknowledgement Interrupt Interrupt Confirmation Reset Indication Reset Confirmation Clear Indication Clear Confirmation
Note: The NLI PVC messages PVC_Attach and PVC_Detach do not have corresponding X.25 packets.
147
Appendix B: NLI Events
148
Appendix C
Error Codes
This section lists the OSI codes defined in <sys/snet/x25_proto.h> which may be used by NLI application programmers. To identify the originator in N_RI and N_DI messages: N_USER N_PROVIDER 1 2
To specify the reason when the originator is the Network Service provider in N_DI messages: NS_GENERIC NS_DTRANSIENT NS_DPERMANENT NS_TUNSPECIFIED NS_PUNSPECIFIED NS_QOSNATRANSIENT NS_QOSNAPERMANENT NS_NSAPTUNREACHABLE NS_NSAPPUNREACHABLE NS_NSAPPUNKNOWN 0xE0 0xE1 0xE2 0xE3 0xE4 0xE5 0xE6 0xE7 0xE8 0xEB
To specify the reason when the originator is the Network Service user in N_DI messages: NU_GENERIC NU_DNORMAL NU_DABNORMAL NU_DINCOMPUSERDATA NU_TRANSIENT NU_PERMANENT NU_QOSNATRANSIENT NU_QOSNAPERMANENT NU_INCOMPUSERDATA NU_BADPROTID 0xF0 0xF1 0xF2 0xF3 0xF4 0xF5 0xF6 0xF7 0xF8 0xF9
149
Appendix C: Error Codes
To specify the reason when the originator is the Network Service provider in N_RI messages: NS_RUNSPECIFIED NS_RCONGESTION 0xE9 0xEA
To specify the reason when the originator is the Network Service user in N_RI messages: NU_RESYNC 0xFA
Note: These codes are found in ISO 8208 and are mapped from X.25 cause and diagnostic codes as described in ISO 8878.
150

x25 Protocol Manual

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

x25 Protocol Manual

Caricato da

Copyright:

Formati disponibili

X.

205 Indigo Creek Drive

Document Revision History Part Number

Chapter 1: About This Guide

Chapter 2: Getting Started

Chapter 3: X.25 Programmer's Guide

Chapter 4: X.25 Network Managers Guide

Appendix A: Product Safety Information

Appendix B: NLI Events Appendix C: Error Codes

Chapter 1: About This Guide

What it is Used For

<> All Capitals

Customer Support and Services

SS7 Systems (Includes SEGway)

Customer Support Packages

Chapter 1: About This Guide

Other Web Support

Return Merchandise Authorization (RMA)

Chapter 2: Getting Started

Embedded Controller Installation

LAN-based Server Installation

Chapter 2: Getting Started

Running the Test Applications

Switched Virtual Circuit Test Programs

Switched Virtual Circuit Test Programs

trace disabled mps (LAN server only)

Chapter 2: Getting Started

Switched Virtual Circuit Test Programs

Running the Switched Virtual Circuit Test Programs

Running the Switched Virtual Circuit Test Programs

Chapter 2: Getting Started

Permanent Virtual Circuit Test Programs

Permanent Virtual Circuit Test Programs

0 128 (x25pvcsnd only)

Chapter 2: Getting Started

(trace disabled) mps (LAN server only)

Permanent Virtual Circuit Test Programs

Running the Permanent Virtual Circuit Test Programs

Chapter 2: Getting Started

The Network Layer Interface

Chapter 3: X.25 Programmer's Guide

The addressing format is:

sn_id; aflags; DTE_MAC; nsap_len; NSAP[NSAPMAXSIZE];

Quality of Service and X.25 Facilities

CONS Quality of Service Parameters

Chapter 3: X.25 Programmer's Guide

Minimum Throughput Class

Target Transit Delay

Maximum Acceptable Transit Delay

Chapter 3: X.25 Programmer's Guide

Use of Expedited Data

Receipt Acknowledgement Service

Fast Select with Restricted Response

Chapter 3: X.25 Programmer's Guide

Packet Concatenation, Packet and Window Size Negotiation

Packet Size Negotiation

Window Size Negotiation

Network User Identification

Closed User Groups

Chapter 3: X.25 Programmer's Guide

Called Address Modification

Programmable X.25 Facilities

Listening for Incoming Calls

/* Always XL_DAT / / Always N_EData */

/* Always XL_DAT / / Always N_EAck */

/* Always XL_CTL / / Always N_PVC_DETACH / / Reports why */

Negotiate requested / qosformat)); Expedited request / 256 bytes / 256 bytes /