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!
News
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:
- Sangoma
 - 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
 - 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:
- LiS - Linux STREAMS 
    from Gcom, Inc. appears to be a stable, 
    commerically supported, well-debugged package. Last version dates to 
    October 2004.
 - strxnet from
    OpenSS7 Corporation is an
    X/Open XTI/TLI library for Linux.  Recent versions are dated at June 2004.
 - TIRPC 
    is an implementation of SunOS-5 tirpc and the TLI library. Includes
    assorted utilities.  Last version dates from 1998.
 
Other protocols and API's
- Gcom, Inc. 
    offers SNA, X.25, Frame Relay,
    and many other types of protocol support on Linux.
 
Last updated April 2005 by Linas Vepstas
(linas@linas.org)
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
http://www.gnu.org/copyleft/fdl.html.
Go Back to the Enterprise Linux Page
Go Back to Linas' Home Page