Inner Workings of WANPIPE

Corbic and Mandelstam discuss the structure and user interfaces to the WANPIPE drivers as they have evolved and currently exist.

WANPIPE Debugging

WANs, by their nature, are quite complicated. There are
usually several players, including one or more Telcos, often a
public network provider and often a separate ISP that adds to the
confusion. The inevitable line teething problems and ongoing line
debugging can often denigrate into futile finger-pointing
exercises.

For this reason, a major part of the WANPIPE development has
been devoted to debugging. Sangoma's philosophy is to provide
customers with enough debugging information so that the customers
can solve most problems by themselves. Furthermore, if support is
necessary, Sangoma tech support must have enough information to
solve the problem remotely.

The xPipemon Programs

Each WAN protocol has its own debugging utility that is used
to determine the status of the driver and physical line, obtain
protocol state and statistics, as well as raw and interpreted line
traces. The data transfer involved in the monitors is UDP-based.
Remote systems can be debugged via the Internet, without logging
into the user system, while system security can be tightly managed.
UDP calls are OS-independent, meaning that a remote Linux machine
can debug a WANPIPE card running in a FreeBSD or Windows
machine.

Since system security is an important issue, the UDP
debugging commands can be turned off by setting the UDPPORT to 0,
or better yet, by setting the TTL (time to live) value to a small
one. By setting the TTL value to one, for example, only users that
are logged into the machine or located in front of the first router
will be able to operate the debugger. The TTL and UDPPORT values
are configurable in the WANPIPE configuration file.

A current list of monitors and typical commands is given in
Table 3. Under Windows, X and other graphic environments, the
complicated command lines are replaced by simple GUI
applications.

The driver receives management requests via the UDP/IP stack.
All received requests are then forwarded into a low priority queue.
A low priority thread handles requests and sends the results back
up the stack, to the originating IP address. UDP debug requests can
also come from the network where the request is sent back through
the line. Management connections through the network interface are
treated differently from traffic from “above”. Only statistics
are available through the network, while access from above allows
the user to also reconfigure, test and set up the CSU/DSU and run
line traces.

Proc File System

The proc file system is a memory mapped virtual directory
structure that is used to provide driver and kernel information.
Management systems, such as SNMP, use the proc file systems to
obtain kernel/driver statistics and states. The WANPIPE driver
binds into the proc file system by setting up /proc/net/wanrouter
directory. This directory contains virtual files for each WANPIPE
device. WANPIPE configuration and statistics can be obtained by
reading/opening supported /proc files. To display tx, rx and error
statistics for, say, the wanpipe1 device, use this command:
cat /proc/net/wanrouter/wanpipe1

Log Messages

All WANPIPE events are logged via the syslog dæmon, in
the /var/log/messages file. Note, syslog can be reconfigured to
forward messages to a different location. To view the messages log
continuously, execute: tail -f
/var/log/messages.

Nenad Corbic,
senior data communications specialist—Heading the Linux
development team at Sangoma, Nenad works with senior management to
ensure Sangoma's Linux customers are provided with innovative wide
area network (WAN) communications technology. Nenad is responsible
for WANPIPE device driver design and development, WANPIPE quality
assurance, new product development and third-level
customer/developer support. He also has interests in the Linux
routing project and embedded Linux development. Nenad holds a BEng
in Computer Engineering from Ryerson Polytechnic University in Toronto.

David Mandelstam,
chief technology officer—Spearheading
Sangoma's growth since inception, David remains committed to
developing and improving technology for wide area network (WAN)
communications. As chief technology officer and founder of Sangoma,
David directs the technology strategy and corporate research
activities, managing development of new product technologies and
overseeing the entire manufacturing cycle. David holds a BSc in
Mechanical Engineering from the University of Witwatersrand in
South Africa, an MSc in Aerodynamics from the Cranfield Institute
of Technology in the United Kingdom and a BComm from the University
of South Africa.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.