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