Inner Workings of WANPIPE
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.
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.
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.
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
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.
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—ftp.linuxjournal.com/pub/lj/listings/issue82).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide