GnuCash Personal Finance Manager

Linux, X.25, Frame Relay and Related Info

This page contains tidbits relating to X.25 and Frame Relay for Linux. Caveat Emptor: This page is sporadically maintained and incomplete; the last major revision was made in 1997, with only minor changes since then!


CCITT (ITU) X.25 Packet Layer support is now a part of the Version 2.1 Linux Development kernel. (News from 1997)

Overview & Background Material

The Sangoma Technologies, Inc. web server offers excellent introductory articles on Frame Relay, X.25, HDLC and LAPB, SDLC, and Synchronous and Asynchronous Protocols in general.

The folks at Emerging Technologies, Inc. offer an FAQ for Frame Relay.

Solutions Primer

There are a large variety of X.25 and Frame Relay Solutions one could contemplate. I over-simplify the options below.
X.25 over ordinary serial port and 14.4/28.8 modem
This is the slowest, most basic implementation of X.25. Some work for Linux has been started, is in alpha stage? Note that X.25 transactions (a write followed by a read) could take 0.6 seconds on such an implementation.

X.25 over special serial port and 14.4/28.8 modem
Several vendors provide cards (PCI and ISA) that run X.25 in firmware/microcode, and have Linux drivers. These are listed below.

X.25 over special serial port and 56K,ISDN, T1 and T3
High speed serial ports go under a variety of names, such as V.35 and RS422. A variety of vendors provide ISA and PCI cards for this, including the linux drivers. By hooking a CSU/DSU to the serial port, you can connect to the net. Some of the cards have built-in CSU/DSU's.

Don't confuse PPP/CHAP over ISDN with X.25 or Frame Relay. Most small office/home office and Internet providers provide Internet connections by running PPP/CHAP over ISDN. PPP is a way of encapsulating IP over a "serial line" such as ISDN or an ordinary modem. It has nothing to do with X.25 or Frame Relay. Of course, it is possible to run IP over X.25 and Frame Relay; many European Internet connections are via X.25.

X.25 or frame relay router or bridge or FRAD.
These are external boxes that have nothing to do with Linux. A variety of vendors sell these: Cisco, Ascend, among many others. Basically, you buy one of these boxes, and cable them to your linux box with Ethernet.

An interesting alternative to buying a router is making your linux box into a router. One does this by buying one of the above-mentioned serial cards, a CSU/DSU, and an ethernet card, and configuring the linux kernel appropriately. The folks at Emerging Technologies, Inc. make some strong, elegant arguments as to why this is an excellent technical solution.

X.25 over TCP/IP
In order to connect older X.25 devices over long distances, it is no longer economical to rent point-to-point leased lines from telecommunications vendors. Nevertheless, a number of older devices that speak only X.25 are deployed around the world; it is equally not economic to replace all of these devices (they tend to be built like tanks, they tend to keep working and have a very low failure rate). To enable long-dstance communications, X.25 and the protocols layered on top of it can be tunneled through TCP/IP. This is not an uncommon usage of X.25 on Linux; indeed, the majority of Linux X.25 deployments may be as X.25 to TCP/IP gateways/bridges. Not clear to me if the Linux version is compatible woth the Cisco XOT protocol or not.

Frame Relay over special serial port and 56K,ISDN, T1 and T3
Frame Relay traces its roots to X.25 and other network protocols, but is much more efficient, and therefore faster. The Frame Relay Forum offers introductory papers that explain Frame Relay, how it works, and its advantages.

As above, the options are similar: buy an FRAD ... which has nothing to do with Linux, or buy a high-speed serial card that supports Frame Relay in firmware/microcode, plug it into your linux box, and add the appropriate CSU/DSU.

PCI card Hardware Vendors

Since stand-alone Frame Relay Access Devices (FRAD's) are commonly available, and will work with any operating system, these are NOT reviewed here. The below reviews PCI cards supporting X.25 communications. These card fall into two classes: PCI cards which have native X.25 connections on them, and PCI cards with serial-port output, which require a CSU/DSU to complete he connection to an X.25 circuit. In either case, the actual X.25 protocols are handled on the PCI card. Because these are PCI cards, they require native Linux device drivers to operate.

A list of serial board and X.25 vendors for Linux:

Offers the WANPIPE which is a different name for S502E, 503, and S508 ?? These are high-speed serial cards that support X.25 and Frame Relay among other things. A CSU/DSU is needed to connect to the public net (phone company).

Sangoma drivers are now part of the 2.1.x series of kernels, and can also be found on the Sangoma FTP site. Sangoma holds a special place in the Linux heirarchy and in the hearts and minds of the developers, as having been an early and engaged participant in Linux. They help get a lot of the initial infrastructure up and debugged.

Farsite's principal business seems to be a vendor of X.25 PCI cards. The FarSync X.25 T-Series is a 4-port PCI card. Device drivers for Linux are available from the Farsite website under a GPL license.

Emerging Technologies, Inc.
Offer the ET5025 Series, ranging from a cheap, low end board, to a dual processor version that can handle multiple T1 lines.

SDL Communications
Offers cards for 56/64, T1 and T3 connections, some with internal CSU's/DSU's. These are the RISCom/N2dds for 56K, RISCom/Pri for T1/Pri, among others.

Programming Interfaces

The standard programming interfaces for x.25 comminucations on Linux make use of the standard BSD socket interfaces. Type 'man x25' on most modern Linux distros to pull up the man page for X.25 programming. In short, an X.25 socket is opened by calling

#include <sys/socket.h> #include ≤linux/x25.h> int x25_fd = socket(PF_X25, SOCK_SEQPACKET, 0);

From this point on, one uses the standard Unix bind(), listen(), connect(), accept(), read(), write() and close() I/O calls to communicate on the X.25 connection. Almost the only way in which this differs from ordinary socket programming is the addressing. The X.25 sockets use ITU_T X.121 recommended network addresses:

struct sockaddr_x25 { sa_family_t sx25_family; /* must be AF_X25 */ x25_address sx25_addr; /* X.121 Address */ };
Some additonal control can be gotten via setsockopt() with the parameter X25_QBITINC. See the x25(7) man page for details.

SysV Streams

In most cases, X.25 applications do not send raw data ovr raw X.25 interfaces, but use the higher-level OSI Session layer protocol (ISO-SP aka ISO 8327 aka ITU X.225 aka CCITT X.225). Other implementations might use the ISO-TP OSI Transport Layer Protocols (TP0, TP1, TP2, TP3, TP4, ISO 8073). I am not aware of any Free or Open Source implementations of these higher protocols. (Note however, the Farsite T-Series X.25 card seems to come with a development kit that includes ISO 8073 interfaces).

See the ISO 8327 and ISO 8326 spec pages. ISO is charging several hundred dollars to get access to *each* of these specifications. Forget free and open source, we can't even get free and open documentation! This is an apallingly bad attitude and gross misconduct by an organization purporting to represent international interests! Are these people stupid, corrupt, or both? OK, both ... Surely anyone with a few decades experience in the computing industry can't help but notice that ISO standards are consistent failures, eventually becomming completely irrelelvant, whereas the IETF RFC's are consistent successes that become a part of the core backbone of the Internet and of the world economy. In my not-so-humble opinion, may I suggest that at least part of the problem with ISO is this absurd need to charge money for specifications?

See the ITU X.225 page for the specifications. ITU is charging a nominal fee for a copy of the specification. Makes me want to grab the ITU by the lapels and shake them: WAKE UP! How can an interantional standards body charge money for specifications, and expect to be anything other than a failure? Oh, that's right, they are a failure ... no wonder the X.whatever specs are deader-n-a-doornail. Sigh. Oh well. The future belongs to a younger generation.

Prorietary/in-house implementations are frequently built on top of the SysV Streams interfaces, that is, require TLI or XTI support in the operating system. There are a few implementations of TLI for Linux:

Other protocols and API's

Last updated April 2005 by Linas Vepstas (
Copyright (c) 1996, 1997, 2005 Linas Vepstas. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found at
Go Back to the Enterprise Linux Page
Go Back to Linas' Home Page