Inner Workings of WANPIPE

by Nenad Corbic



Intelligent Adapters





WANPIPE Device Drivers



  • Each link can have a maximum of 255 logical channels

  • Control and configure each link separately

  • Control and configure each logical channel separately


  • Easily expandable (future protocols)

  • Support for both Routing and API applications simultaneously


  • Local and remote debugging support

  • SNMP Support

  • Fast Tx and Rx paths

  • Proc file system support: statistics and debugging

  • Driver Message/Event Logging

  • Easy updates and upgrades

The following design rules were adopted in developing the driver:







  • Monitoring cellular switch information using X.25.


  • Controlling military hardware using HDLC LAPB.







WANPIPE and the Linux Kernel

Figure 1 shows how the WANPIPE device driver fits into the Linux kernel architecture. Linux is divided into two operating regions, the user space and the kernel space. All applications, dæmons and utilities execute in the user-space, while kernel and device drivers execute in the kernel space. Communications between user space applications and the kernel are facilitated through system calls such as ioctl.

Device drivers, an integral part of the Linux kernel, interface hardware components to the operating system. Drivers are usually compiled into the kernel or provided as independent, separate modules that can be dynamically loaded or unloaded at run time.

Sangoma used modular drivers in WANPIPE because modules can easily be updated and reloaded while the kernel is running, eliminating the need for costly system reboots.

WANPIPE, being a network device driver, uses network interfaces to bind to the Linux kernel stack. The network interfaces contains Level 3 protocol information (IP) as well as driver entry points, enabling the Linux kernel stack, via the network interface, to control driver operation: interface shutdown, startup, statistics and data communications.

WANPIPE Configuration

The WANPIPE configuration process starts with creating a detailed configuration file that outlines the hardware, protocol and IP options as well as location of the adapter firmware. Once completed, WANPIPE driver modules are loaded into the kernel. The initial module load allocates necessary resources, initializes and sets up the proc file system directories and enables the ioctl system calls. Since loaded modules do not have enough information to completely configure the card, ioctl system calls are used to pass the contents of the configuration file to the driver. The final step in WANPIPE configuration is to configure and start up network interfaces using the ifconfig() command. The sequence is shown in Table 1.

Table 1. Configuring and Starting up Network Interfaces

WANPIPE and Routing

The kernel IP layer provides a packet transfer service; that is, given a packet complete with addressing information, it will take care of the transfer. In conjunction with the IP layer, the routing table (see Table 2) determines the forwarding order of all incoming packets.

Table 2. Kernel IP Routing Table

Once the WANPIPE network interface (wp1_fr16) is up and running, the kernel routing table is updated with the interface's IP information. The wp1_fr16 interface has two entries. The first one specifies the destination network and the second indicates a default route, meaning that all IP addresses not specified in the above routing table will be forwarded to wp1_fr16 interface.

Upon successful driver configuration, network interfaces and routing tables can be viewed and modified from the user space using the standard Linux commands:

  • ifconfig—display or modify network interfaces

  • route—display or modify the routing table

WANPIPE and the APIs

An API is used to send and receive custom RAW, non-IP packets to and from the card. Since data is not communicated in IP format, the network interface is configured without the IP address. This effectively removes the kernel routing table entry and unhooks the IP routing stack from the WANPIPE driver. Non-IP communication is achieved using the RAW socket calls to the driver. As the name implies, packets are transferred without any modification.

To ensure that packets that had been acknowledged at the card level were never lost, a secure socket solution was developed: a custom WANPIPE socket that guarantees delivery in both upstream and downstream directions. The WANPIPE socket is based on the Linux RAW socket, developed by Alan Cox and others.

Developing with the WANPIPE Secure Socket: X.25API

We provide the following as an example of working with the WANPIPE API set. We have chosen X.25 as a line protocol because it is probably the most complicated, involving call set up and tear-down, logical channel management and exception condition handling. X.25 is a packet-switched WAN protocol that (generally) uses a public packet-switched network to route packets to different end points. In operation, it appears to be similar to TCP/IP, although the underlying mechanisms are quite different. Line speeds are almost always below 256KBps, usually below 64KBps. Its operation is analogous to a telephone. A call must be initiated, and once the call is accepted, data can be transmitted. When data transmission is over, the call is cleared. Using the WANPIPE secure socket, X.25API programming is very similar to TCP/IP programming.

To continue our example, we assume that the WANPIPE drivers are configured and successfully started, and that the X25 link is up and running (see Listings 1 and 2 at our FTP site—

WANPIPE Debugging



The xPipemon Programs




Table 3. Monitors and Typical Commands


Proc File System


Log Messages




Load Disqus comments