SunLink X.25 9.0 Programming Guide - Oracle...SunLink® X.25 9.0 Programming Guide A Sun Microsystems, Inc. Business 2550 Garcia Avenue Mountain View, CA 94043 U.S.A Part No.: 802-3313-10

SunLink® X.25 9.0Programming Guide

A Sun Microsystems, Inc. Business

2550 Garcia AvenueMountain View, CA 94043U.S.A

Part No.: 802-3313-10Revision A, September 1995

PleaseRecycle

1995 Sun Microsystems, Inc. All rights reserved.2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A.

This product and related documentation are protected by copyright and distributed under licenses restricting its use, copying,distribution, and decompilation. No part of this product or related documentation may be reproduced in any form by anymeans without prior written authorization of Sun and its licensors, if any.

Portions of this product may be derived from the UNIX® and Berkeley 4.3 BSD systems, licensed from UNIX SystemLaboratories, Inc., a wholly owned subsidiary of Novell, Inc., and the University of California, respectively. Third-party fontsoftware in this product is protected by copyright and licensed from Sun’s font suppliers.

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the United States Government is subject to the restrictionsset forth in DFARS 252.227-7013 (c)(1)(ii) and FAR 52.227-19.

The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications.

TRADEMARKSSun, the Sun logo, Sun Microsystems, Solaris, are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S.and certain other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensedthrough X/Open Company, Ltd. OPEN LOOK is a registered trademark of Novell, Inc. PostScript and Display PostScript aretrademarks of Adobe Systems, Inc. All other product names mentioned herein are the trademarks of their respective owners.

All SPARC trademarks, including the SCD Compliant Logo, are trademarks or registered trademarks of SPARC International,Inc. SPARCstation, SPARCserver, SPARCengine, SPARCstorage, SPARCware, SPARCcenter, SPARCclassic, SPARCcluster,SPARCdesign, SPARC811, SPARCprinter, UltraSPARC, microSPARC, SPARCworks, and SPARCompiler are licensedexclusively to Sun Microsystems, Inc. Products bearing SPARC trademarks are based upon an architecture developed by SunMicrosystems, Inc.

The OPEN LOOK® and Sun™ Graphical User Interfaces were developed by Sun Microsystems, Inc. for its users and licensees.Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical userinterfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface,which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written licenseagreements.

X Window System is a trademark of the X Consortium.

THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR APARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES AREPERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEWEDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES INTHE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.

iii

Contents

1. STREAMS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Part 1 —Network Layer Interface (NLI)

2. About NLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1 NLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

2.2 NLI ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

2.3 Support Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

2.4 Support for OSI Connection-Mode Network Service (OSICONS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

2.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

2.6 Facilities and QOS Parameters . . . . . . . . . . . . . . . . . . . . . . . . 2-6

2.7 Upgrading from SunLink X.25 8.x . . . . . . . . . . . . . . . . . . . . . 2-7

3. Making and Receiving Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.1 Making a Single Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.2 Receiving Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

3.3 Additional Call Information . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

3.3.1 Opening connections for OSI CONS Calls . . . . . . . . . 3-9

iv SunLink X.25 Programming Guide—September 1995

3.3.2 Receiving Expedited Data . . . . . . . . . . . . . . . . . . . . . . . 3-10

3.3.3 Dealing with Resets and Interrupts . . . . . . . . . . . . . . . 3-12

4. Listening for Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1 Listening for a Single Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.2 Listening for Multiple Incoming Calls . . . . . . . . . . . . . . . . . 4-8

5. Getting Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

6. NLI Commands and Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.1 x25_primitives C Union . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

6.2 Generic Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

6.2.1 xaddrf —define addressing . . . . . . . . . . . . . . . . . . . . . 6-6

6.2.2 lsapformat —define an LSAP . . . . . . . . . . . . . . . . . . 6-8

6.2.3 extraformat —define standard X.25 facilities. . . . . 6-9

6.2.4 qosformat —define OSI CONS QOS parameters . . 6-14

6.3 NLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18

6.3.1 N_Abort —Abort Indication. . . . . . . . . . . . . . . . . . . . . 6-18

6.3.2 N_CC—Call Response/Confirmation . . . . . . . . . . . . . 6-19

6.3.3 N_CI—Call Request/Indication. . . . . . . . . . . . . . . . . . 6-21

6.3.4 N_DAck—Data Ack Request/Indication. . . . . . . . . . . 6-23

6.3.5 N_Data —Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

6.3.6 N_DC—Clear Confirm . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27

6.3.7 N_DI—Clear Request/Indication . . . . . . . . . . . . . . . . 6-29

6.3.8 N_EAck—Expedited Data Acknowledgement . . . . . 6-32

6.3.9 N_EData —Expedited Data. . . . . . . . . . . . . . . . . . . . . . 6-33

6.3.10 N_PVC_ATTACH—PVC Attach . . . . . . . . . . . . . . . . . . . 6-35

Contents v

6.3.11 N_PVC_DETACH—PVC Detach. . . . . . . . . . . . . . . . . . . 6-37

6.3.12 N_RC—Reset Response/Confirm. . . . . . . . . . . . . . . . . 6-39

6.3.13 N_RI—Reset Request/Indication . . . . . . . . . . . . . . . . 6-40

6.3.14 N_Xcanlis —Listen Cancel Command/Response . 6-42

6.3.15 N_Xlisten —Listen Command/Response . . . . . . . . 6-44

7. Network Layer ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.1 N_getlinkstats —retrieve per-link statistics. . . . . . . . . . 7-4

7.2 N_getoneVCstats —retrieve per virtual-circuit statistics 7-6

7.3 N_getpvcmap —get PVC default packet/window sizes . . 7-8

7.4 N_getstats —get X.25 multiplexor statistics. . . . . . . . . . . 7-9

7.5 N_getVCstats —get per virtual-circuit statistics . . . . . . . 7-12

7.6 N_getVCstatus —get per virtual-circuit statistics . . . . . . 7-17

7.7 N_linkconfig —configure the wlcfg database . . . . . . . . 7-21

7.8 N_linkent —configure a newly linked driver . . . . . . . . . . 7-36

7.9 N_linkmode —alter the characteristics of a link. . . . . . . . . 7-37

7.10 N_linkread —read the wlcfg database . . . . . . . . . . . . . . 7-38

7.11 N_nuidel —delete specified NUI mapping . . . . . . . . . . . . 7-39

7.12 N_nuiget —read the mapping for a specified NUI . . . . . . 7-40

7.13 N_nuimget —read all existing NUI mappings . . . . . . . . . . 7-41

7.14 N_nuiput —store a set of NUIs . . . . . . . . . . . . . . . . . . . . . . . 7-42

7.15 N_nuireset —delete all existing NUI mappings . . . . . . . 7-46

7.16 N_putpvcmap —change PVC packet and window sizes . . 7-47

7.17 N_traceoff ioctl—cancel N_traceon . . . . . . . . . . . . . . . . 7-48

7.18 N_traceon —turn on packet level tracing . . . . . . . . . . . . . 7-49

vi SunLink X.25 Programming Guide—September 1995

7.19 N_X25_ADD_ROUTE—set fields of X25_ROUTE structure . 7-51

7.20 N_X25_FLUSH_ROUTE—flushes all routes . . . . . . . . . . . . . 7-53

7.21 N_X25_GET_ROUTE—obtains routing information . . . . . . 7-55

7.22 N_X25_GET_NEXT_ROUTE—get next routing entry . . . . . 7-57

7.23 N_X25_RM_ROUTE—remove route from X25_ROUTE. . . . 7-59

7.24 N_zerostats —reset X.25 multiplexor statistics count . . 7-61

8. Support Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

8.1 The padent Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

8.2 The hostent Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5

8.3 endpadent —closes the PAD Hosts Database. . . . . . . . . . . 8-6

8.4 endxhostent —closes the xhosts file . . . . . . . . . . . . . . . . 8-7

8.5 equalx25 —compares two X.25 addresses . . . . . . . . . . . 8-8

8.6 getnettype —get type of network for a link . . . . . . . . . . . 8-9

8.7 getpadbyaddr —get PAD database entry for address . . . 8-10

8.8 getpadent —get next line in PAD Hosts Database . . . . . . 8-11

8.9 getxhostbyaddr —get X.25 host name by address . . . . . 8-12

8.10 getxhostbyname —get X.25 address by name . . . . . . . . . 8-13

8.11 getxhostent —reads next line of xhosts file . . . . . . . . . 8-14

8.12 linkidtox25 —convert link identifier to numeric form . 8-15

8.13 padtos —convert PAD database structure into string . . . . 8-16

8.14 setpadent —open and rewind the PAD Hosts Database. 8-18

8.15 setxhostent —open and rewind the xhosts file . . . . . . 8-19

8.16 stox25 —convert X.25 address to xaddrf structure. . . . 8-20

Contents vii

8.17 x25_find_link_parameters —finds link configuration filesand builds a linked list of links . . . . . . . . . . . . . . . . . . . . . . . 8-21

8.18 x25_read_config_parameters —reads a configuration fileinto a data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22

8.19 x25_read_config_parameters_file —reads aconfiguration file into a data structure . . . . . . . . . . . . . . . . . 8-24

8.20 x25_save_link_parameters —update config files. . . . 8-26

8.21 x25_set_parse_error_function —install a function asdefault error handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27

8.22 x25_write_config_parameters —writes a data structureinto a configuration file identified by a link number . . . . . 8-28

8.23 x25_write_config_parameters_file —writes a datastructure into a configuration file identified by a filename 8-30

8.24 x25tolinkid —convert numeric link identifier to string. 8-32

8.25 x25tos —convert xaddrf structure to X.25 address. . . . . 8-33

9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Part 2 —Data Link Protocol Interface (DLPI)

10. About DLPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

10.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

11. DLPI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

11.1 Address Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

11.1.1 LLC2 Address Structure . . . . . . . . . . . . . . . . . . . . . . . . 11-5

11.1.2 LAPB Address Structure . . . . . . . . . . . . . . . . . . . . . . . . 11-5

11.2 Message Primitive Sequence Summary . . . . . . . . . . . . . . . . 11-7

11.3 DL_ATTACH_REQ—identifies physical link to use . . . . . . . . 11-8

11.4 DL_BIND_ACK—acknowledges request . . . . . . . . . . . . . . . . 11-9

viii SunLink X.25 Programming Guide—September 1995

11.5 DL_BIND_REQ—specifies CNLS or CONS service . . . . . . . 11-10

11.6 DL_CONNECT_CON—acknowledge DL_CONNECT_REQ. . . 11-12

11.7 DL_CONNECT_IND—indicate incoming connection . . . . . . 11-13

11.8 DL_CONNECT_REQ—establish a connection . . . . . . . . . . . . 11-15

11.9 DL_CONNECT_RES—accept a connect request . . . . . . . . . . 11-17

11.10 DL_DETACH_REQ—undoes a previous DL_ATTACH_REQ. 11-19

11.11 DL_DISABMULTI_REQ—disable a multicast address . . . . 11-20

11.12 DL_DISCONNECT_IND—indicates connection disconnect 11-22

11.13 DL_DISCONNECT_REQ—disconnects a connection . . . . . . 11-24

11.14 DL_ENABMULTI_REQ—Enable a multicast address . . . . . . 11-26

11.15 DL_ERROR_ACK—negative acknowledgment . . . . . . . . . . . 11-28

11.16 DL_INFO_ACK—convey info summary . . . . . . . . . . . . . . . . 11-29

11.17 DL_INFO_REQ—request info summary . . . . . . . . . . . . . . . . 11-31

11.18 DL_OK_ACK—acknowledge previous primitive . . . . . . . . . 11-32

11.19 DL_RESET_CON—acknowledges DL_RESET_REQ. . . . . . . 11-33

11.20 DL_RESET_IND—indicates remote reset . . . . . . . . . . . . . . . 11-34

11.21 DL_RESET_REQ—request connection reset . . . . . . . . . . . . . 11-35

11.22 DL_RESET_RES—respond to reset request . . . . . . . . . . . . . 11-36

11.23 DL_TOKEN_ACK—acknowledges DL_TOKEN_REQ. . . . . . . 11-37

11.24 DL_TOKEN_REQ—assigns token to stream. . . . . . . . . . . . . . 11-38

11.25 DL_UNBIND_REQ—summary. . . . . . . . . . . . . . . . . . . . . . . . . 11-39

11.26 L_GETPPA—returns the PPA associated with a stream . . . 11-40

11.27 L_GETGSTATS—reads global layer 2 statistics . . . . . . . . . . 11-41

11.28 L_GETSTATS—retrieves per link statistics. . . . . . . . . . . . . . 11-43

Contents ix

11.29 L_SETTUNE—sets tunable parameters for a PPA . . . . . . . . 11-48

11.30 L_SETPPA—associates a PPA with a physical device . . . . 11-51

11.31 L_ZEROSTATS—clears the per-link statistics count . . . . . . 11-53

Part 3 —Sockets Example

12. Compatibility with 7.0—Sockets-based Packet Level Interface . . . . . . . . . . . . . . . . . . . . . . 12-1

12.1 Introduction — The AF_X25 Domain . . . . . . . . . . . . . . . . . . 12-1

12.2 AF_X25 Domain Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

12.3 Creating Switched Virtual Circuits . . . . . . . . . . . . . . . . . . . . 12-3

12.3.1 Calling Side — Outgoing Call Setup . . . . . . . . . . . . . . 12-3

12.3.2 Calling Side — Setting the Local Address . . . . . . . . . 12-5

12.3.3 Called Side — Incoming Call Acceptance. . . . . . . . . . 12-6

12.3.4 Address Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

12.3.5 Binding by PID/CUDF . . . . . . . . . . . . . . . . . . . . . . . . . 12-8

12.3.6 Masking Incoming Protocol Ids at Bit Level. . . . . . . . 12-10

12.3.7 AEF Matching Considerations . . . . . . . . . . . . . . . . . . . 12-10

12.3.8 Explicit Link Selection—Calling Side . . . . . . . . . . . . . 12-11

12.3.9 Explicit Link Selection—Called Side . . . . . . . . . . . . . . 12-13

12.3.10 Accessing the Local and Remote Addresses. . . . . . . . 12-14

12.3.11 Finding the Link Used for a Virtual Circuit . . . . . . . . 12-15

12.3.12 Determining the LCN for a Connection . . . . . . . . . . . 12-16

12.4 Sending Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16

12.4.1 Control of the M-, D-, and Q-bits . . . . . . . . . . . . . . . . . 12-17

12.4.2 Sending Interrupt and Reset Packets. . . . . . . . . . . . . . 12-19

x SunLink X.25 Programming Guide—September 1995

12.5 Receiving Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20

12.5.1 In-Band Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20

12.5.2 Reading the M-, D-, and Q-bits. . . . . . . . . . . . . . . . . . . 12-21

12.5.3 Receiving X.25 Messages in Records . . . . . . . . . . . . . . 12-22

12.5.4 Out-of-Band Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23

12.6 Clearing a Virtual Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-25

12.7 Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-26

12.7.1 Facility Specification and Negotiation. . . . . . . . . . . . . 12-26

12.7.2 X25_SET_FACILITY /X25_GET_FACILITY ioctls . 12-26

12.7.2.1 Reverse Charge . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-28

12.7.2.2 Fast Select. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-29

12.7.2.3 Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-30

12.7.2.4 Window Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31

12.7.2.5 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32

12.7.2.6 Minimum Throughput Class . . . . . . . . . . . . . . . 12-32

12.7.2.7 Closed User Group . . . . . . . . . . . . . . . . . . . . . . . . 12-33

12.7.2.8 RPOA Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-34

12.7.2.9 Network Transit Delay. . . . . . . . . . . . . . . . . . . . . 12-34

12.7.2.10 End-to-End Transit Delay . . . . . . . . . . . . . . . . . . 12-35

12.7.2.11 Network User Identification . . . . . . . . . . . . . . . . 12-35

12.7.2.12 Charging Information Request . . . . . . . . . . . . . . 12-36

12.7.2.13 Charging Information . . . . . . . . . . . . . . . . . . . . . 12-36

12.7.2.14 Called Line Address Modified Notification . . . 12-37

12.7.2.15 Call Redirection Notification. . . . . . . . . . . . . . . . 12-37

Contents xi

12.7.2.16 Expedited Data Negotiation . . . . . . . . . . . . . . . . 12-38

12.7.2.17 Called/Calling AEF . . . . . . . . . . . . . . . . . . . . . . . 12-38

12.7.2.18 Non-X.25 Facilities . . . . . . . . . . . . . . . . . . . . . . . . 12-39

12.7.2.19 Determining Which Facilities are Present . . . . . 12-40

12.7.3 Fast Select User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-41

12.7.3.1 Calling Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-42

12.7.3.2 Called Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-43

12.7.4 Permanent Virtual Circuits . . . . . . . . . . . . . . . . . . . . . . 12-45

12.7.5 Call Acceptance by User . . . . . . . . . . . . . . . . . . . . . . . . 12-45

12.7.6 Accessing the Link (X.25) Address. . . . . . . . . . . . . . . . 12-47

12.7.7 Accessing High Water Marks of Socket. . . . . . . . . . . . 12-47

12.7.8 Accessing the Diagnostic Code . . . . . . . . . . . . . . . . . . 12-49

12.8 Routing ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-52

12.9 Miscellaneous ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-53

12.9.1 Obtaining Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-54

12.9.1.1 Obtaining Version Number . . . . . . . . . . . . . . . . . 12-59

13. Sockets Programming Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

13.1 Include Files for User Programs. . . . . . . . . . . . . . . . . . . . . . . 13-1

13.2 Compilation Instructions and Sample Programs . . . . . . . . 13-2

13.3 Structures Used by the X25_SET_FACILITY andX25_GET_FACILITY ioctl Commands . . . . . . . . . . . . . . . . 13-2

xii SunLink X.25 Programming Guide—September 1995

xiii

Figures

Figure 1-1 STREAMS Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Figure 2-1 NLI and STREAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Figure 2-2 NLI Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Figure 10-1 DLPI Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

xiv SunLink X.25 Programming Guide—September 1995

xv

Tables

Table 2-1 NLI Commands and Structures. . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Table 2-2 PVC and Listening Commands and Structures . . . . . . . . . . . . 2-5

Table 6-1 NLI Commands and Structures. . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Table 6-2 PVC and Listening Commands and Structures . . . . . . . . . . . . 6-2

Table 6-3 Generic Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

Table 6-4 xaddrf Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

Table 6-5 Members of xaddrf Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7

Table 6-6 lsapformat Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8

Table 6-7 Members of lsapformat Structure. . . . . . . . . . . . . . . . . . . . . . 6-8

Table 6-8 extraformat Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9

Table 6-9 Members of extraformat Structure . . . . . . . . . . . . . . . . . . . . 6-10

Table 6-10 QOS Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15

Table 6-11 Call Response/Confirmation Message. . . . . . . . . . . . . . . . . . . . 6-20

Table 6-12 Call Request/Indication Message . . . . . . . . . . . . . . . . . . . . . . . . 6-22

Table 6-13 Data Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26

Table 6-14 Clear Confirm Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28

xvi SunLink X.25 Programming Guide—September 1995

Table 6-15 Clear Request/Indication Parameters . . . . . . . . . . . . . . . . . . . . 6-30

Table 6-16 PVC Attach Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36

Table 6-17 Listen Cancel Command/Response Parameters . . . . . . . . . . . 6-38

Table 6-18 Listen Cancel Command/Response Parameters . . . . . . . . . . . 6-43

Table 6-19 Variables for CUD matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45

Table 6-20 Variables for address matching . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46

Table 6-21 Listen Command/Response Parameters . . . . . . . . . . . . . . . . . . 6-47

Table 7-1 NUI mapping icotls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Table 7-2 Multiplexor ioctls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Table 7-3 Virtual circuit ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Table 7-4 Packet level tracing ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Table 7-5 Routing ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

Table 7-6 perlinkstats fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Table 7-7 nliformat fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Table 7-8 vcinfo structure fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

Table 7-9 getpvcmap fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Table 7-10 N_getstats structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

Table 7-11 vcstatsf fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Table 7-12 xstate summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14

Table 7-13 perVC_stats summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15

Table 7-14 vcstatusf fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17

Table 7-15 xstate summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18

Table 7-16 perVC_stats summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19

Table 7-17 NET_MODE values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21

Table 7-18 bit map summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28

Tables xvii

Table 7-19 SUB_MODES summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29

Table 7-20 PSDN Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30

Table 7-21 Intl_addr_recogn summary . . . . . . . . . . . . . . . . . . . . . . . . . 7-31

Table 7-22 prty_encode_control values . . . . . . . . . . . . . . . . . . . . . . . . 7-32

Table 7-23 src_addr_control values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33

Table 7-24 thclass_type values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34

Table 7-25 xll_ref fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36

Table 7-26 linkoptformat fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37

Table 7-27 nui_del fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-39

Table 7-28 nui_get fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-40

Table 7-29 Members of the nui_mget structure . . . . . . . . . . . . . . . . . . . . . 7-41

Table 7-30 nui_put fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-42

Table 7-31 nuiformat fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43

Table 7-32 facformat fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-44

Table 7-33 nui_reset fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-46

Table 7-34 pvcconf fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-47

Table 7-35 trc_regioc fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-49

Table 7-36 trc_ctrl fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-50

Table 8-1 PAD related functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Table 8-2 xhosts functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Table 8-3 X.25 addressing functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Table 8-4 Configuration file functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Table 8-5 Link functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

Table 8-6 Members of padent structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

Table 8-7 Members of hostent structure . . . . . . . . . . . . . . . . . . . . . . . . . 8-5

xviii SunLink X.25 Programming Guide—September 1995

Table 8-8 Members of xaddrf structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8

Table 8-9 getnettype parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

Table 8-10 Network Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

Table 8-11 getpadbyaddr parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10

Table 8-12 getxhostbyaddr parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12

Table 8-13 getxhostbyname parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13

Table 8-14 linkidtox25 parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15

Table 8-15 padtos parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16

Table 8-16 strp character string values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17

Table 8-17 setpadent parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18

Table 8-18 setxhostent parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19

Table 8-19 stox25 parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20

Table 8-20 Members of link_data structure . . . . . . . . . . . . . . . . . . . . . . . 8-21

Table 8-21 read_confing_parameters parameters . . . . . . . . . . . . . . . 8-22

Table 8-22 x25_read_config_parameters_file parameters. . . . . . 8-24

Table 8-23 x25_save_link_parameters parameters . . . . . . . . . . . . . . 8-26

Table 8-24 x25_set_parse_error_function parameters . . . . . . . . . 8-27

Table 8-25 x25_write_config_parameters parameters . . . . . . . . . . 8-28

Table 8-26 write_link_config_parameters_file parameters . . . 8-31

Table 8-27 x25tolinkid parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32

Table 8-28 x25tos parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33

Table 9-1 Reason when Originator is NS Provider . . . . . . . . . . . . . . . . . . 9-1

Table 9-2 Reason when Originator is NS User . . . . . . . . . . . . . . . . . . . . . . 9-2

Table 11-1 Local Management Service Message Primitives . . . . . . . . . . . . 11-1

Table 11-2 Connection Mode Service Message Primitives . . . . . . . . . . . . . 11-2

Tables xix

Table 11-3 Data Transfer Message Primitives. . . . . . . . . . . . . . . . . . . . . . . . 11-2

Table 11-4 Statistics Ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

Table 11-5 Stream Configuration Ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

Table 11-6 Tracing Ioctls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

Table 11-7 Connectionless Mode Service Message Primitives. . . . . . . . . . 11-4

Table 11-8 Members of llc_dladdr structure . . . . . . . . . . . . . . . . . . . . . . 11-5

Table 11-9 Members of pstnformat structure . . . . . . . . . . . . . . . . . . . . . . 11-6

Table 11-10 Members of the dl_attach_req_t structure. . . . . . . . . . . . . 11-8

Table 11-11 DL_ATTACH_REQ errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8

Table 11-12 Members of the dl_bind_ack_t structure . . . . . . . . . . . . . . . 11-9

Table 11-13 Members of the dl_bin_req_t structure . . . . . . . . . . . . . . . . 11-10

Table 11-14 DL_BIND_REQ errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11

Table 11-15 Members of the dl_connect_con_t structure . . . . . . . . . . . 11-12

Table 11-16 Members of the dl_connect_ind_t structure . . . . . . . . . . . 11-13

Table 11-17 Members of the dl_connect_req_t structure . . . . . . . . . . . 11-15

Table 11-18 DL_ONNECT_REQ errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16

Table 11-19 Members of the dl_connect_res_t structure . . . . . . . . . . . 11-17

Table 11-20 DL_CONNECT_RES errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18

Table 11-21 Members of the dl_detach_req_t structure. . . . . . . . . . . . . 11-19

Table 11-22 DL_DETACH_REQ errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19

Table 11-23 Members of the dl_disabmulti_req_t structure. . . . . . . . 11-20

Table 11-24 DL_DISABMULTI_REQ errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21

Table 11-25 Members of dl_disconnect_ind structure . . . . . . . . . . . . . 11-22

Table 11-26 Members of the dl_disconnect_req_t structure. . . . . . . . 11-24

Table 11-27 DL_DISCONNECT_REQ errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25

xx SunLink X.25 Programming Guide—September 1995

Table 11-28 dl_enabmulti_req_t structure . . . . . . . . . . . . . . . . . . . . . . . 11-26

Table 11-29 dl_enabmulti_req_t errors . . . . . . . . . . . . . . . . . . . . . . . . . . 11-27

Table 11-30 Members of the dl_error_ack_t structure. . . . . . . . . . . . . . 11-28

Table 11-31 members of the dl_info_ack_t structure . . . . . . . . . . . . . . . 11-30

Table 11-32 Members of the dl_info_req_t structure . . . . . . . . . . . . . . . 11-31

Table 11-33 Members of the dl_ok_ack_t structure . . . . . . . . . . . . . . . . . 11-32

Table 11-34 Members of the dl_reset_con_t structure. . . . . . . . . . . . . . 11-33

Table 11-35 Members of the dl_reset_ind_structure . . . . . . . . . . . . . 11-34

Table 11-36 Members of the dl_reset_req_t structure. . . . . . . . . . . . . . 11-35

Table 11-37 DL_RESET_REQ errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-35

Table 11-38 Members of the dl_reset_res_t structure. . . . . . . . . . . . . . 11-36

Table 11-39 DL_RESET_RES errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-36

Table 11-40 Members of the dl_token_ack_t structure. . . . . . . . . . . . . . 11-37

Table 11-41 Members of the dl_token_req_t structure. . . . . . . . . . . . . . 11-38

Table 11-42 Members of the dl_unbind_req_t structure. . . . . . . . . . . . . 11-39

Table 11-43 Members of the ll_snioc structure . . . . . . . . . . . . . . . . . . . . . 11-40

Table 11-44 Members of the llc2_gstioc structure . . . . . . . . . . . . . . . . . 11-41

Table 11-45 Members of the lapb_gstioc structure . . . . . . . . . . . . . . . . . 11-42

Table 11-46 llc2stats_t structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-43

Table 11-47 lapbstats_t structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-45

Table 11-48 Members of the llc2_tnoic structure. . . . . . . . . . . . . . . . . . . 11-49

Table 11-49 Members of the llc2_tnoic structure. . . . . . . . . . . . . . . . . . . 11-50

Table 11-50 Members of the ll_snioc structure . . . . . . . . . . . . . . . . . . . . . 11-51

xxi

Preface

This guide describes the programming interfaces provided as part of theSunLink X.25 9.0 product. It does not cover the installation or configuration ofthe product. For this, refer to Installing and Licensing SunLink X.25 9.0 andManaging SunLink X.25 9.0.

How This Book Is OrganizedThis book contains the following parts and chapters:

Part 1, “Network Layer Interface (NLI),” covers the network layer interface.

Chapter 1, “STREAMS Overview,” provides a brief overview of STREAMSprogramming.

Chapter 2, “About NLI,” provides some background information on the NLIprogramming interface.

Chapter 3, “Making and Receiving Calls,” contains example programs formaking and receiving calls.

Chapter 4, “Listening for Calls,” contains example programs for listening forincoming calls.

Chapter 5, “Getting Statistics,” contains an example program for collectingstatistics.

Chapter 6, “NLI Commands and Structures,” provides reference material onNLI commands and structures.

xxii SunLink X.25 Programming Guide—September 1995

Chapter 7, “Network Layer ioctls,” provides reference material on network layerioctls.

Chapter 8, “Support Functions,” provides reference material on the availablelibrary routines.

Chapter 9, “Error Codes,” provides information on NLI error codes.

Part 2, “Data Link Protocol Interface (DLPI),” covers the DLPI programminginterface.

Chapter 10, “About DLPI,” provides background information on DLPI.

Chapter 11, “DLPI Reference,” provides reference information on DLPI.

Part 3, “Sockets Interface,” covers the Sockets programming interface.

Chapter 12, “Compatibility with 7.0— Sockets-based Packet Level Interface,”provides reference material on sockets programming.

Chapter 13, “Sockets Programming Example,” contains a sockets programmingexample.

What Typographic Changes MeanThe following table describes the typographic changes used in this book.

Table P-1 Typographic Conventions

Typeface orSymbol Meaning Example

AaBbCc123 The names of commands,files, and directories;on-screen computer output

Edit your .login file.Use ls -a to list all files.machine_name% You have mail.

Preface xxiii

Shell Prompts in Command ExamplesThe following table shows the default system prompt and superuser prompt forthe C shell, Bourne shell, and Korn shell.

AaBbCc123 What you type, contrastedwith on-screen computeroutput

machine_name% suPassword:

AaBbCc123 Command-line placeholder:replace with a real name orvalue

To delete a file, type rm filename.

AaBbCc123 Book titles, new words orterms, or words to beemphasized

Read Chapter 6 in User’s Guide. Theseare called class options.You must be root to do this.

Table P-2 Shell Prompts

Shell Prompt

C shell prompt machine_name%

C shell superuser prompt machine_name#

Bourne shell and Korn shellprompt

$

Bourne shell and Korn shellsuperuser prompt

#

Table P-1 Typographic Conventions

Typeface orSymbol Meaning Example

xxiv SunLink X.25 Programming Guide—September 1995

1-1

STREAMS Overview 1

STREAMS defines a standard interface for character I/O within the kernel, andbetween the kernel and the rest of the system. STREAMS creates, uses anddismantles streams. A stream is a full-duplex processing and data transfer pathbetween a driver in kernel space and a process in user space.

A stream is made up of three parts—a stream head, optionally one or moremodules, and a driver. The stream structure is summarized in Figure 1-1 onpage 2. The stream head provides the interface between the stream and the userprocesses. The module processes data travelling between the stream head andthe driver. The driver can be a device driver, which has associated hardware, ora software driver.

1-2 SunLink X.25 Programming Guide—September 1995

1

STREAMS facilities are available using a series of system calls, which interactwith the driver.

Figure 1-1 STREAMS Format

For detailed information on STREAMS, refer to the STREAMS ProgrammingGuide.

User Space

Kernel Space

User Process

Stream

Head

Module

Driver

ExternalInterface

(optional)

Part 1 — Network Layer Interface (NLI)

2-1

About NLI 2

The SunLink X.25 Network Layer Interface provides access to the X.25 PacketLayer Protocol (PLP). The NLI defines the format that STREAMS messages musttake when interfacing to the network layer. This allows for the easy constructionof user level library software, and means that applications map convenientlyonto the STREAMS format.

NLI Commands page 2-3

NLI ioctls page 2-5

Support Functions page 2-5

Support for OSI Connection-Mode Network Service (OSI CONS) page 2-6

Addressing page 2-6

Facilities and QOS Parameters page 2-6


2

SunLink X.25 applications use the putmsg and getmsg system calls to interactwith the PLP driver.

Figure 2-1 NLI and STREAMS

Messages passed using NLI have both a control and a data part. Primitives andassociated parameters are passed to the X.25 driver using the control part of themessage. Data, if there is any, is contained in the data part of the message.

Figure 2-2 NLI Message Format

User Space

Kernel Space

X.25 Application

X.25 PLPmodule

LAPBdriver

ExternalInterface

Stream Head

putmsg getmsg

Control partcontains primitivesand parameters

Data partcontains data

About NLI 2-3

2

SunLink X.25 NLI provides the following:

• NLI messagesThese determine the format of the control parts of putmsg and getmsg , andare used to communicated with the network.

• A series of ioctlsThese communicate with the SunLink X.25 code, rather than with thenetwork.

• A series of library functionsThese are not part of the NLI, but can be used along with it.

2.1 NLI CommandsSunLink X.25 NLI provides a series of NLI commands contained within Cstructures. These determine the format of the control parts of putmsg andgetmsg . The NLI commands correspond to X.25 packet types, and are used tocommunicate with the network. For example, when an application passes downthe NLI command N_CI to a stream using putmsg , this is translated into an X.25Call Connect by the PLP module. When the PLP module receives a ConnectIndication, it translates it into an N_CI command which is passed up to theapplication using a getmsg system call.


2

Table 2-1 summarizes the structures and their corresponding Packet Types andNLI Commands. Refer to the sections indicated for detailed information.

Table 2-1 NLI Commands and Structures

NLICommand X.25 Packet NLI Structure See section

N_Abort Abort Indication xabortf “N_Abort—AbortIndication” on page 6-18

N_CC Call Response/Confirmation

xccnff “N_CC—CallResponse/Confirmation”on page 6-19

N_CI Call Request/ Indication xcallf “N_CI—CallRequest/Indication” onpage 6-21

N_DAck Data AcknowledgmentRequest/Indication

xdatacf “N_DAck—Data AckRequest/Indication” onpage 6-23

N_Data Data xdataf “N_Data—Data” onpage 6-25

N_DC Clear Confirm xdcnff “N_DC—Clear Confirm”on page 6-27

N_DI Clear Request/Indication xdiscf “N_DI—ClearRequest/Indication” onpage 6-29“N_RI—ResetRequest/Indication” onpage 6-40

N_EAck Expedited DataAcknowledgment

xedatacf “N_EAck—ExpeditedData Acknowledgement”on page 6-32

N_EData Expedited Data xedataf “N_EData—ExpeditedData” on page 6-33

N_RC Reset Response/Confirm xrscf “N_RC—ResetResponse/Confirm” onpage 6-39

N_RI Reset Request/Indication xrstf “N_RI—ResetRequest/Indication” onpage 6-40

About NLI 2-5

2

The following commands and structures are also provided. They do notcorrespond to X.25 packet types:

2.2 NLI ioctlsSunLink X.25 NLI provides a series of ioctls. These are used to communicatewith the SunLink X.25 code itself, rather than with the network. For example,ioctls are used to gather statistics about a link, or to set the parameters to be usedon a link. This distinguishes them from the NLI Commands given in Table 2-1.To use them together, you might use an ioctl to set the parameters to be used ona link and then use an NLI command to initiate a call over the link. The NLIioctls can be used for the following purposes:

• Operating on the Network User Identifiers mapping table• Reading and resetting statistics• Getting status information• Operating on the X.25 Routing Table• Overriding settings made using x25tool

2.3 Support FunctionsSunLink X.25 also includes a library of Sun-specific support functions that youcan use when writing applications. These are not part of the NLI, but can beused in NLI applications.

Table 2-2 PVC and Listening Commands and Structures

NLI Command NLI Structure Description See section

N_PVC_ATTACH pvcattf Specify X.25 service to use with PVC “N_PVC_ATTACH—PVC Attach” onpage 6-35

N_PVC_DETACH pvcdetf Specify X.25 service to stop usingwith PVC

“N_PVC_DETACH—PVC Detach”on page 6-37

N_Xcanlis xcanlisf Cancel listening “N_Xcanlis—Listen CancelCommand/Response” on page 6-42

N_Xlisten xlistenf Listen for incoming calls “N_Xlisten—ListenCommand/Response” on page 6-44


2

2.4 Support for OSI Connection-Mode Network Service (OSI CONS)The SunLink X.25 NLI can support applications which use the OSI Connection-Mode Network Service, as defined in X.223 and ISO 8878. To be consistent withthese documents, this service is referred to as OSI CONS in this guide. Thisservice provides the mapping between the OSI CONS primitives and theelements of the X.25 Packet Layer Protocol.

2.5 AddressingWhen making straightforward X.25 calls, you need to work with DTE and LSAPaddresses. When making OSI CONS calls, you use NSAP and LSAP addresses.

2.6 Facilities and QOS ParametersThe X.25 Recommendations allow service providers to offer a number ofoptional facilities, that affect the way that calls are made and handled.

• 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.

The following Quality of Service (QOS) parameters are available when writingOSI CONS applications:

• Throughput Class• Minimum Throughput Class

About NLI 2-7

2

• Target Transit Delay• Maximum Acceptable Transit Delay• Use of Expedited Data• Protection• Priority• Receipt Acknowledgment

2.7 Upgrading from SunLink X.25 8.xIf you are upgrading from a previous version of SunLink X.25, and you havemade use of the library functions, you need to relink your applications againstthe new library, which is contained in /opt/SUNWconn/lib .


2

3-1

Making and Receiving Calls 3

This chapter contains examples of how to make and receive calls. All of theexamples involve the application opening a stream to the X.25 PLP Driver. Oncethe stream has been opened, it can be used for initiating, listening for, oraccepting a connection. There is a one-to-one mapping between X.25 virtualcircuits and PLP driver streams. Once a connection has been established on astream, the stream cannot be used other than for passing data and protocolmessages for that connection.

Sample code for making OSI CONS calls, dealing with Expedited Data andResets and receiving a remote disconnect is given at the end of this section.

Note – There are copies of the code samples referred to in this chapter in the/opt/SUNWconn/x25/samples.nli directory.

3.1 Making a Single CallThis section shows the process for making a single, straightforward call. The callbeing made is a standard X.25 call. It does not have to deal with Expedited Dataor Resets. The disconnect is initiated locally. The steps for making a standardX.25 call are:


3

1. Open a stream on the /dev/x25 device:

2. Open a connection to the open stream.

a. Allocate a Connect Request structure.

b. Supply any quality of service and facilities parameters that are required.

c. Set the called (and optionally calling) addresses.

d. Pass the Connect Request down to the X.25 Driver.

if ((x25_fd = open("/dev/x25", O_RDWR)) < 0) {perror("Opening Stream");exit(1);}

Making and Receiving Calls 3-3

3

e. Wait for the connect confirmation or rejection.

In the example, the entire QOS field is zeroed, allowing for future additions tothe structure. Setting the calling address to null, as shown, leaves the networkto fill in this value. For more information on QOS and Facilities, seeSection 2.6, “Facilities and QOS Parameters,” on page 6.

#define FALSE 0#define TRUE 1#define CUDFLEN 4#define DBUFSIZ 128#include #include struct xaddrf called = { 0, 0, { 14, { 0x23, 0x42, 0x31, 0x56,0x56, 0x56, 0x56 }}, 0 }; /* no flags * DTE = "23423156565656", null NSAP */struct xcallf conreq;struct strbuf ctlblk, datblk;struct xdataf data;

main (){ . . . /* Convert link to internal format */ called.link_id = 0; conreq.xl_type = XL_CTL; conreq.xl_command = N_CI; conreq.CONS_call = FALSE; /* This is 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)); . . .}


3

3. Send the message on the stream using the putmsg system call, passing anycall user data in the data part of the message:

4. Transfer the data.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 OSI CONS.Normal and Q-bit data is sent and received using the N_Data message andmay be acknowledged using the N_DAck message. Expedited data uses theN_EData message, and is acknowledged using an N_EAck message.

Once a connection has been successfully opened on a stream, sending a datapacket is straightforward:

char cudf[CUDFLEN] = { 1, 0, 0, 0 };ctlblk.len = sizeof(struct xcallf);ctlblk.buf = (char *) &conreq;datblk.len = CUDFLEN;datblk.buf = cudf;if (putmsg(x25_fd, &ctlblk, &datblk, 0) < 0 ) {

perror("Call putmsg");exit(1);}

char datbuf[DBUFSIZ];/* Copy data into datbuf[] here*/data.xl_type = XL_DAT;data.xl_command = N_Data;data.More = data.setQbit = data.setDbit = FALSE;ctlblk.len = sizeof(struct xdataf);ctlblk.buf = (char *) &data;datblk.len = DBUFSIZ;datblk.buf = datbuf;retval = putmsg(x25_fd, &ctlblk, &datblk, 0);


3

Normally, the call to putmsg blocks if there are flow control conditions in theconnection which lead to either a full queue at the stream head, or a lack ofstreams resources. To avoid blocking due to a full queue, open the streamwith the option O_NDELAY flagged. In this case, putmsg returns immediately,and the failure is signalled by a return value (retval ) of EAGAIN.

This procedure allows the application to carry out other processing (forexample, receiving data) before trying again. The best method to use dependson the nature of the application.

5. Close the connection.In this example, closure is initiated locally. The application sends a DisconnectRequest (N_DI ) message on the stream. Unless this is being used to reject anincoming call the X.25 driver signals that it has observed the message. It doesthis by sending a Disconnect Confirm upstream when it receives the ClearConfirm. In this way, the upper components can be certain that no messageswill follow the Disconnect.

In the case of rejection, the connection identifier supplied on the ConnectIndication must be returned in the disconnect message. The disconnect (reject)is not acknowledged in this case.

As in the case of a remote disconnection, once the response has been receivedthe stream becomes idle, and remains in this state until the application sendsout another control message. This may be to close the stream, or to initiate anew Listen or Connect request on it. The application should, however, notsend any of these messages until it receives the Disconnect Response.


3

As described in Section 6.3.7, “N_DI—Clear Request/Indication,” on page 29,a disconnect collision may occur. If this happens, no Clear Confirm is sent.

/* Coded and 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 */

}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 */

}} /* end if (xqos) */

} /* end if (hdrptr->xl_type==XL_CTL) */


3

3.2 Receiving DataIn the same way as sending data, data reception is straightforward. When data isreceived with the D-bit set, action may be required by the application. When theinitial Call Request is sent, it may request that data confirmation be at theapplication-to-application level. If application-to-application confirmation isagreed upon, then on receiving a packet with the D-bit set, an application mustsend a Data Acknowledgment (N_DAck) message.

This example prints out incoming data as a string, if the Q-bit is not set:

S_X25_HDR *hdrptr;struct xdataf *dat_msg;struct xdatacf *dack;for(;;) {

if (getmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) {perror(“Getmsg 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;isetDbit) {


3

3.3 Additional Call InformationThe example in Section 3.1, “Making a Single Call,” is of a relativelystraightforward call. Procedures for making a call using OSI CONS, for receivingexpedited data, for dealing with resets and for receiving remotely initiateddisconnects are given in the following sections. These can be integrated into theexample above, as required.

dack = (struct xdatacf *)malloc(sizeof(struct xdatacf));memset((char *)dack 0, 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;putmsg(x25_fd, &ctlblk, &datblk, &getflags);}

} /* end else */break;

case N_EData:printf(“***Expedited data received \n”);

/* Must deal with it */break;

case N_DAck:printf(“***Data Acknowledgement received \n”);break;

default:break;

} /* end switch */} /* end if */

} /* end for */


3

3.3.1 Opening connections for OSI CONS Calls

The following example opens a connection for an OSI CONS call:

#define FALSE0#define TRUE1#define CUDFLEN 4#define EXPLEN 4#include #include 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;struct strbuf, ctlblk, datblk;struct xedataf exp;

main (){ . . . called.link_id = 0; /* * 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; /* Negotiate requested */ memset(&conreq.qos, 0, sizeof (struct qosformat)); conreq.qos.reqexpedited = TRUE; /* Expedited requested */ conreq.qos.xtras.locpacket = 8; /* 256 bytes */ conreq.qos.xtras.rempacket = 8; /* 256 bytes */ memcpy(&conreq.calledaddr, &called, sizeof(struct xaddrf)); memset(&conreq.callingaddr, 0, sizeof(struct xaddrf)); . . .}


3

Note – When negotiate_qos is true (non-zero), setting the QOS fields to zeromeans that the connection uses defaults for QOS and Facilities. If required, thesecan be set to different values but it is recommended that the entire QOS structurebe zeroed first as shown. This is preferable to setting each field individually, as itallows for any future additions to this structure. Setting the calling address tonull leaves the network to fill this value in.

The message is sent on the stream using the putmsg system call, with any calluser data being passed in the data part of the message:

At this stage, the application should wait for a response to the Call Request. Theresponse may be either a Connect Confirmation or a Disconnect (rejection)message.

3.3.2 Receiving Expedited Data

The preceding example allows for the possibility of receiving expedited datamessages, which are carried in X.25 interrupt packets. These must be dealt withappropriately. Since only one expedited data packet can be outstanding in theconnection at any time, its sender is prevented from sending any further suchmessages until the receiver has acknowledged it. The receiver does this bysending an Expedited Acknowledgment (EAck) message. The EAck is sent in thesame way as an ordinary data packet, but with no data part.

If an application does not need to use the expedited data capability, then itresponds to receiving an EData by resetting or closing the connection.

When sending expedited data, the application must wait for an acknowledgmentbefore requesting further expedited transmissions.

char cudf[CUDFLEN] = { 1, 0, 0, 0 };ctlblk.len = sizeof(struct xcallf);ctlblk.buf = (char *) &conreq;datblk.len = CUDFLEN;datblk.buf = cudf;if (putmsg(x25_fd, &ctlblk, &datblk, 0) < 0 ) {

perror("Call putmsg");exit(1);}


3

char expdata[]= {1, 2, 3, 4};exp.xl_type= XL_CTL;exp.xl_command= N_Edata;ctlblk.len= sizeof (struct xedataf);ctlblk.buf= (char *) &exp;datblk.len= EXPLEN;datblk.buf= expdata;if (putmsg(x25_fd, &ctlblk, &datblk, 0) < 0) {

error("Exp putmsg");exit(1);}

for (;;) {if (getmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) {perror("Getmsg 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) {

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;

}}


3

3.3.3 Dealing with Resets and Interrupts

Resets and Interrupts are dealt with in a similar way, except that there is no datapassed with a Reset Request. When a Reset Request or Interrupt is issued, theapplication must wait for the acknowledgment, as for an expedited request.However, until this is received, the only action that can be taken is to issue aDisconnect Request.

The diagnostic field in a Reset Request or Interrupt contains the reason forissuing the reset. Standard values for this are defined in the include file , although the application can set any value. SeeChapter 9, “Error Codes” for more details.

When a Reset Indication is received, there are only two valid actions that may betaken:

• send a Reset Confirmation message to acknowledge the reset• send a Disconnect Request

In either case, pending data is flushed from the queue.


3

Reset Indications can be dealt with as part of the general processing of incomingmessages, as shown in the following disconnect handling example.

Control messages, like resets and interrupts, take higher priority than normaldata messages, both internally in the PLP driver, and across the network.Receiving a Remote Disconnect

If the remote end initiates a Disconnect, then a Disconnect Indication (N_DI )message (or possibly an N_Abort message, see Section 6.3.1, “N_Abort—AbortIndication,” on page 18) is received at the NLI. The application need not

#includestruct xrstf rst;S_X25_HDR *hdrptr;rst.xl_type= XL_CTL;rst.xl_command= N_RI;rst.cause= 0;rst.diag= NU_RESYNC;ctlblk.len= sizeof (struct rstf);ctlblk.buf= (char *) &rst;if (putmsg(x25_fd, &ctlblk, 0, 0) < 0) {

perror(" putnmsg");exit(1);}for (;;) {

if (getmsg(x25_fd, &ctlblk, &datblk, &getflags) < 0) {perror("Getmsg fail");exit(1);}

hdrptr = (S_X25_HDR *) ctlbuf;if (hdrptr->xl_type == XL_CTL) {

continue;}

switch (hdrptr->xl_command) {case N_RC: /* Reset complete */

/* Enter data transfer */break;

default:break;

} /* end switch */} /* end for */


3

acknowledge this message since, after sending a Disconnect, the X.25 driversilently 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 isavailable in the getmsg call to receive all parameters and, when present, up to128 bytes of Clear User Data. Handling such a Disconnect event would normallybe part of the general processing of incoming messages.

The following example could be combined with the code from the data transferexample in the previous section.

Note – It is guaranteed that no X.25 interface messages are sent to the applicationonce a disconnect message has been passed up to it, wherever the message camefrom.

Although at this stage the stream is idle, it is in an open state and remains sountil some user action. This could be to close the stream, or to initiate a newListen or Connect request on it.

struct xdiscf *dis_msg;if (hdrptr->xl_type == XL_CTL) {

switch (hdrptr->xl_command) {/* Other events/indications dealt with * here - 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;

}}

4-1

Listening for Calls 4

This chapter contains examples of listening for incoming calls.

4.1 Listening for a Single CallThe steps for listening for a single incoming call are:

1. Send an N_Xlisten message to the X.25 driver.This should carry the called address list in which the application is interested.

2. Wait for the response to the Listen Request.The l_result flag will indicate success or failure. If the l_result flagindicates failure, the application can decide either to close the stream or to tryagain later.

3. Wait for Connect Indication messages from the X.25 driver.

4. Decide whether to accept on this or a different stream.

5. Negotiate facilities and QOS, if required.A Connect Confirmation message carrying the appropriate connectionidentifier is then passed down on the stream on which the connection is beingaccepted.


4

6. Construct the listen message.The listen message has two parts. Construct the control part of the messagelike this:

In this example, lmax has the value of 1, indicating that only one ConnectIndication is to be handled at a time.

The data part of the message contains the sequence of bytes that specify theCall User Data string and address(es) which are to be listened for. Thesimplest case for this would be to set “Don’t Care” values for both the CUDand address:

Alternatively, to set the CUD to match exactly the (X.29) value defined in thearray cudf[] (0x01000000), and the NSAP to match any sequence starting0x80 , 0x00 , the following would be used:

struct xlistenf lisreq;lisreq.xl_type = XL_CTL;lisreq.xl_command = N_XListen;lisreq.lmax = 1;

int lislen;char lisbuf[MAXLIS];lisbuf[0] = X25_DONTCARE; /* l_cumode*/lisbuf[1] = X25_DONTCARE; /* l_mode*/lislen = 2;

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;

Listening for Calls 4-3

4

Or, to accept any CUD Field, with a DTE of 2342315656565:

Note – The l_add field uses packed hexadecimal digits and the l_lengthvalue is actually the number of semi-octets, whereas the l_culength fieldspecifies the length of the l_cubytes field in octets.

7. Send the Listen Request down the open stream:

#define MY_DTE_LEN 13#define MY_DTE_OCTETS 7char 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 */lislen += MY_DTE_OCTETS;

ctlblk.len = sizeof(struct xlistenf);ctlblk.buf = (char *) &lisreq;datblk.len = lislen;datblk.buf = lisbuf;if (putmsg(x25_fd, &ctlblk, &datblk, 0) < 0) {

perror("Listen putmsg failure");return -1;}


4

8. Wait for the listen response; the result flag indicates success or failure:

Cancelling a Listen Request is done in the same way, except that no data ispassed with the request. It cancels all successful Listens that have been madeon that stream.

#define DBUFSIZ 128#define CBUFSIZ MAX( sizeof(struct xccnff), sizeof(structxdiscf) )struct xlistenf *lis_msg;ctlblk.maxlen = CBUFSIZ; /* See 4.1 above for declarations */ctlblk.buf = ctlbuf;datblk.maxlen = DBUFSIZ;datblk.buf = datbuf;for(;;) {

if (getmsg (x25_fd, &ctlblk, &datblk, &getflags) < 0) {perror("Listen getmsg 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) {

printf("Listen command failed \n");return -1;}

else {printf("Listen command succeeded \n");return 0;}

}


4

9. Once the listening application has received a Listen Response indicatingsuccess, it should wait for incoming Connect Indications.When an N_CI message arrives, the application should inspect itsparameters— address, call user data, facilities, quality of service, and soon—then decide whether to accept or reject the connection.

A listening application can accept a call either on the stream the indicationarrived on, or on some other stream. This other stream can be one which isalready open and free, or the application can open it.

Whatever method is used for the accept, the identifier conn_id in theConnect Indication message must be copied into the accept message formatching by the X.25 driver. If this identifier in the accept message does notmatch, a Disconnect is sent to the accepting application. This causes theresource to hang on the stream on which the incoming call was sent, since theconnection is never accepted.

A listening application can reject the call by sending a N_Disc message downthe stream on which the Connect Indication arrived. A Connect Indicationcannot be rejected on a different stream. The connection identifier must bequoted in the message for matching, since there may be several ConnectIndications passed to the listening application. If there is no match for therejection, the message is silently discarded.

The rejecting listener can request one of two actions in response to thedisconnect:

• Request immediate disconnect. The application sets the reason field toNU_PERMANENT (0xF5).

• Search for further matching listeners. The application set the reason field toany value except 0xF5.


4

The following code example shows how to reject an incoming call:

Note – The application must not accept a connection on a listening stream that iscapable of handling more than one Connect Indication at one time if there couldsubsequently be other Connect Indications to be handled on that stream. Forexample, the application issues a Listen Request to handle three ConnectIndications at one time. A Connect Indication is received and sent to theapplication on the listen stream. The application must not accept this connectionon the listen stream because there could be two more Connect Indications thatcan be sent subsequently.

10. Negotiate any facilities or OSI CONS QOS parameters required.To do this, set the negotiate_qos flag in the Connect Response message.The values received should then be copied into the response, and thosefacilities and/or parameters (and any related flags) for which a different valueis desired should then be altered (see Section 2.6, “Facilities and QOSParameters,” on page 2-6). Copy the entire QOS structure from the indicationto the response. This allows for future additions to this structure.

struct xcallf *conind;struct xdiscf disc_msg;/* Use getmsg 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.conind = conind->conind;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 putmsg */


4

An example of negotiation is shown below. Here all the values are copied asindicated, except the packet size, which is negotiated down to 256 if it isflagged as negotiable, and is greater than 256:

Alternatively, the application may decide to accept (agree with) the indicatedvalues, in which case the negotiate_qos flag is set to zero.

If a connection is never established on a listening stream (using a matchingaccept) then that stream remains listening on the address list supplied. On theother hand, once an established connection has been disconnected, the streamdoes not return to a listening state. Instead, it remains open in an idle state. If theapplication needs to listen again, then the listen message must be re-sent.Rejection does not alter the listening state of the stream.

struct xcallf *conind;struct xccnff conresp;/* Do a getmsg etc to receive the Connect Indication, * assign conind to point to it. */conresp.xl_type = XL_CTL;conresp.xl_command = N_CC;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 = 2v’-.2’8v’+.2’

*/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 a putmsg. */


4

4.2 Listening for Multiple Incoming CallsThe sample code shown in this section shows a listener that can handle severalincoming PAD calls simultaneously. Listeners to handle other types of incomingcalls are similar. The steps are:

1. Define the values you need.You need to specify the X.25 device /dev/x25 , the maximum allowed size ofcall user data and the maximum number of simultaneous calls you want toallow. Set the maximum number of simultaneous calls depending on theprocessor power available to you and the number of calls you expect to needto handle.

2. Open the X.25 device and set up the signal handling.The open_stream() function does this. It requests notification from thekernel when there is incoming data on the stream.

3. Listen for incoming data.The do_listen() function specifies the information used to decide what todo with an incoming call. The example shows two ways of doing this, onesimple, the other more complex. In the simple example, the program listensfor any call user data beginning with the four BCD digits 01000000 . Allstandard PAD calls start with these BCD digits. In the more complex example,the program listens for particular call user data and for an address ending in11. Note that whereas the CUD can be given as bytes, in this case 6, theaddress must be given as BCD digits, in this case 3. As the example deals witha PAD call, the triple X module is pushed next. Finally do_listen() sendsthe listen request to the X.25 driver and makes sure it has been acted uponsuccessfully.

4. Check the validity of the incoming data.The do_connect() function determines what happens with data once it hasbeen accepted. This checks which stream data arrives on and then uses thevalid_connect() function to make sure the connect message is valid.At this point, you could choose to do some more sophisticated checking. Theexample program includes a function called try_next() that tells the driverto see if the connect message is destined for another application, and afunction called reject_call() that rejects the call.


4

5. Accept the incoming data.Assuming the data is valid, the do_accept() function is used to accept it.Note that when accepting incoming data, the application must copy the callindication identifier into the connect confirm sent to the kernel.

6. Handle the incoming data as appropriate.In the example, the doit() function handles the incoming call by pushingthe line discipline module, pushing a BSD translation module, converting thecalling address to a string using the x25_to_str() function, adding theNSAP using the dehex() function and printing a message.

7. Exit the program when finished.

Note – There is a copy of this code sample is in the/opt/SUNWconn/x25/samples.nli directory.

/* *********************************************************************** * * Copyright 12 Apr 1995 Sun Microsystems, Inc. All Rights Reserved * * Use cc -o listen listen.c to compile this program. * * Usage: listen * * This program is a simple example of a listener which can handle many * calls simultaneously. It demonstrates how to set up the listening * streams, and then performs a very basic action each time a call is` * received. * * See the ‘do_listen()’ routine for some alternative sets of * listen data. **/

#include #include #include #include #include


4

#include #include #include #include #include

#include #include #include

#include #include #include #include #include #include

#define X25_DEVICE“/dev/x25”

#define MAX_CALLUSERDATA 128

/* Maximum number of listener Streams */#define LISTEN_MAX4int listen_failed = 0;

structpollfdpollfds[LISTEN_MAX];

int endp=0;

/* * Prototypes for functions used in the program*/void do_connect(int sig);int valid_connect (int fd, struct xcallf *ci);int do_accept (int fd, struct xcallf *ci);int reject_call (int fd, struct xcallf *ci);int try_next(int fd, struct xcallf *ci);int do_listen(int devd);int open_stream (char *device);void doit(int f, struct xcallf *ci);static char *dehex(char *cp, unsigned char *addr, unsigned char len);static int x25_to_str(char *str, struct xaddrf *xad);


4

/******************************************************************/main(int argc, char **argv)/******************************************************************/{

int i;pid_t pid;int status;

/* * When a call is received, the x25 kernel driver will attempt * to match it with a listener, i.e. a stream on which an * N_Xlisten request has been made. If a match is found, a * call indication is sent up that stream to the application. * If no match is found the call will be rejected with a * diagnostic of 0xF5 (not available - permanent) * * When the call indication has been sent, the stream is then * busy, and will remain so until the call is cleared, or accepted * on another stream. * * During that time, any other call requests which arrive cannot * be processed by that stream, and if no other suitable streams * available, the call will be rejected with a diagnostic of 0xF4 * (not available - transient). * * To avoid this situation, this program opens multiple identical * listen streams, so that there is always at least one available * to handle an incoming call.*/

for (i = 0; i < LISTEN_MAX; i++){/* * open_stream() opens the X.25 device and sets up the signal handling*/ if ((pollfds[i].fd = open_stream(X25_DEVICE)) < 0) {

/* * Fail if this is the first attempt. */if (i == 0){ fprintf(stderr,”Listen Request failed\n”);


4

exit(1);}break;

} ++endp; pollfds[i].events = POLLIN; pollfds[i].revents = 0; if (pollfds[i].fd == OPEN_MAX)

break;}

/* * now setup the ‘do_connect’ routine to be called when a * POLL signal arrives (that will indicate that there is data to * be read on the stream)*/(void) sigset(SIGPOLL, do_connect);

/* * loop forever waiting for something to happen and * and handling it when it does*/status = 0;for (;;){/* * The connect routine forks a child process to handle the * call. Wait here until one of the children dies, so we * can cleanup*/ while ((pid = wait(&status)) == -1) {

if (errno == EINTR){/* continue if we were woken by a signal */ continue;}else if (errno == ECHILD){/* no children, so wait for a POLL */ sigpause(SIGPOLL);}else{


4

/* some other unexpected error, die */ fprintf(stderr, “Unexpected error %d from wait()\n”, errno); exit(2);}

} /* * Get here if one of the children exited due to an error. * Check the global flag set in the ‘do_connect’ routine */ if (listen_failed) {

listen_failed = 0;/* Find a free slot in pollfds[] for a replacement listener */for (i = 0; i < endp; i++){ if (pollfds[i].fd == -1) { /* * Requeue a listen request to keep the total * at LISTEN_MAX */

pollfds[i].fd = open_stream(X25_DEVICE); }}

}}

}

/******************************************************************/void do_connect(int sig)/******************************************************************/{/* * This is called when something happens on the listening stream * The possibilities here are endless, we just do a simple * and fairly basic action to illustrate the possibilities*/

int p, status;struct xcallf ci;

/* Find out why we were signalled */while (poll(pollfds, (unsigned long) endp, -1) < 0){


4

if (errno == EINTR)continue;

perror(“Poll failed”); exit(1);}

/* check all the streams, find the one responsible */for (p = 0; p < endp; p++){ int ev = pollfds[p].revents; int s = pollfds[p].fd;

/* Was there a POLLIN event on this stream? */ if (ev & POLLIN) { /* yes, so verify that it is a valid connect message */

connect:status = valid_connect(s, &ci);if (status > 0){/* no, try next one */ continue;}else if (status < 0){/* * something went wrong, ignore it if just a signal, * otherwise discard the stream & start again.*/ if (errno == EINTR)

goto connect;

close(s); pollfds[p].fd = open_stream(X25_DEVICE); continue;}else{/* status == 0, so it worked. Reply by accepting the call */

accept: if (do_accept(s, &ci)) {

if (errno == EINTR) goto accept;


4

close(s);pollfds[p].fd = open_stream(X25_DEVICE);continue;

}

/* * Now fork a child process to deal with the call * independently*/ switch (fork()) {

case 0: /* success, this is the child */

signal(SIGCLD, SIG_IGN);

/* do something useful... */doit(s, &ci);exit(2);

case -1:/* Fork failure, so complain */perror(“FORK”);

/* * re-open a stream for a listener.*/close(s);pollfds[p].fd = open_stream(X25_DEVICE);break;

default: /* * success, this is the parent. clean up, and * re-open a stream for a listener. */

close(s);pollfds[p].fd = open_stream(X25_DEVICE);break;

}}

/* If only a POLLIN, nothing more to do */if (!(ev &= ~POLLIN)) continue;


4

/* * Stream was hungup, usually due to remote end clearing the * call. This is normal, we just tidy up.*/if (ev & POLLHUP){/* * Retrieve the message, to be tidy*/ int fl = 0; struct strbuf ctlptr; shortctlbuf[10];

ctlptr.len = 0; ctlptr.maxlen = sizeof(ctlbuf); ctlptr.buf = (char *)ctlbuf;

if (getmsg(s, &ctlptr, (struct strbuf *) 0, &fl) < 0 ) {

perror(“HANGUP getmsg”); }

close(s);

/* * And re-open the stream, again to stay at LISTEN_MAX * streams in total */ pollfds[p].fd = open_stream(X25_DEVICE); continue; /* dont care if POLLERR as well */}

/* * Other problems, just ignore them, there is * nothing we can do*/if (ev & POLLERR || ev & POLLNVAL){ close(s); /* * And again re-open the stream, to stay at LISTEN_MAX * streams in total */


4

pollfds[p].fd = open_stream(X25_DEVICE); continue;}

}}

}

/**********************************************************************//* returns 0 for success, -1 for error, optionally +1 for ‘try again’ */int valid_connect (int fd, struct xcallf *ci)/**********************************************************************/{

struct strbuf ctlbuf, datbuf; char rbuf[MAX_CALLUSERDATA];

int fl=0;

memset (&ctlbuf, 0, sizeof(struct strbuf));memset (&datbuf, 0, sizeof(struct strbuf));

ctlbuf.len = 0;ctlbuf.maxlen = sizeof(struct xcallf);ctlbuf.buf = (char *)ci;

datbuf.len = 0;datbuf.maxlen = MAX_CALLUSERDATA;datbuf.buf = (char *)rbuf;

if (getmsg(fd, &ctlbuf, &datbuf, &fl) < 0){

return(-1);}

if (ci->xl_type != XL_CTL || ci->xl_command != N_CI){

return(-1);}

/* * At this point the routine could be greatly expanded to do much * more detailed analysis of called and calling addresses, * user data, time of day etc. If the match fails then the routine * try_next() can be called, to pass it on to any further listeners * who might match the call data but have different criteria:


4

* * try_next(fd, ci); * * Alternatively, if it is necessary to permanently reject this * call, and not allow other listening applications the chance * to try and handle it (perhaps a security breach has been * identified) it can be rejected with: * * reject_call(fd, ci);*/

return(0);}

/******************************************************************/int do_accept (int fd, struct xcallf *ci)/******************************************************************/{/* * routine to send a ‘call accept’ message*/

struct strbuf ctlbuf, datbuf;struct xccnff cc;char rbuf[MAX_CALLUSERDATA];

memset (&ctlbuf, 0, sizeof(struct strbuf));memset (&datbuf, 0, sizeof(struct strbuf));memset (&cc, 0, sizeof(struct xccnff));

cc.xl_type = XL_CTL;cc.xl_command = N_CC;

cc.CONS_call = 0;/* don’t use CONS */

cc.negotiate_qos = 0;/* don’t support QOS negotiation */memset(&(cc.rqos), 0, sizeof(struct qosformat));

/* NOTE. This is ESSENTIAL */cc.conn_id = ci->conn_id;

memcpy(&(cc.responder), &(ci->calledaddr), sizeof(struct xaddrf));

ctlbuf.len = sizeof(struct xccnff);ctlbuf.maxlen = 0;


4

ctlbuf.buf = (char *)&cc;

datbuf.len = 0;datbuf.maxlen = MAX_CALLUSERDATA;datbuf.buf = (char *)rbuf;

if (putmsg(fd, &ctlbuf, &datbuf, 0) < 0){

return(-1);}return(0);

}

/******************************************************************/int reject_call (int fd, struct xcallf *ci)/******************************************************************/{

struct strbuf ctlbuf;struct xdiscf dr;

memset (&ctlbuf, 0, sizeof(struct strbuf));memset (&dr, 0, sizeof(struct xdiscf));

/* Disconnect message */dr.xl_type = XL_CTL;dr.xl_command = N_DI;

/* no other aplications to be allowed a chance */dr.originator = 0;dr.reason = NU_PERMANENT;dr.cause = 0;dr.diag = NU_TRANSIENT;

/* NOTE. This is ESSENTIAL */dr.conn_id = ci->conn_id;memcpy(&(dr.responder), &(ci->calledaddr), sizeof(struct xaddrf));

ctlbuf.len = sizeof(struct xdiscf);ctlbuf.maxlen = 0;ctlbuf.buf = (char *)&dr;

if (putmsg(fd, &ctlbuf, (struct strbuf *)0, 0) < 0){


4

return(-1);}return(0);

}/******************************************************************/int try_next(int fd, struct xcallf *ci)/******************************************************************/{

struct strbuf ctlbuf;struct xdiscf dr;

memset (&ctlbuf, 0, sizeof(struct strbuf));memset (&dr, 0, sizeof(struct xdiscf));

/* Disconnect message */dr.xl_type = XL_CTL;dr.xl_command = N_DI;

/*

SunLink X.25 9.0 Programming Guide - Oracle...SunLink® X.25 9.0 Programming Guide A Sun Microsystems, Inc. Business 2550 Garcia Avenue Mountain View, CA 94043 U.S.A Part No.: 802-3313-10

Documents