Design of wireless gateway between on-board vehicle wired networks and mobile devices A TDMA-based MAC between gateway and devices in M2M networks
To set up port forwarding rules on network gateways, certain technical skills are required
from end-users. These assumptions in the gateway software stack, can lead to an increase
in support calls to network operators and resellers of customer premises equipment. The
user interface itself is also an important part of the product and a complicated interface
will contribute to a lessened user experience. Other issues with an overwhelming user
interface include the risk of faulty conﬁguration by the user, potentially leaving the network
vulnerable to attacks.
We present an enhancement of the current port forwarding conﬁguration in the gateway
software, with an extensible library of presets along with usability improvements. To help
users with detecting available services, a wrapper for a network scanner is implemented, for
detecting devices and services on the local network. These parts combined relieves end-users
of looking up forwarding rules for ports and protocols to conﬁgure their gateway, basing
their decisions on data collected by the network scanner or by using an applications name
instead of looking up its ports. Another usability improvement is an internal DNS service,
which enables access to the gateway interface through a human-memorable domain name,
instead of using the LAN IP address.
Using the Nmap utility for identifying services on the network, could be considered
harmful activity by network admins and intrusion detection systems. The preset library
is extensible and generic enough to be included in the default software suite shipping with
the network equipment. Working within the uniﬁed conﬁguration system of OpenWrt, the
preset design will add value and allow resellers to easily customize it to their services. This
proposal could reduce support costs for the service operators and improve user experience
in conﬁguring network gateways.
There are simple ways in which to improve the user experience, add value to the product and put less
stress on the end-users. We want to prototype a port forwarding wizard that is designed for being
usable and safe. Developers of network gateway software often implement a set of presets of port
forwarding rules for common applications, there is no reason to stop there.
Working from the theory that a good user experience lies in the details, iterative improvements
of the system is the way to address this. This project contributes to the ongoing work of improving
details of user experience, strengthening the product and saving costs for support departments. The
project aspires to contribute to the continuous development of the OpenWrt ecosystem and aid users
in conﬁguring their gateways.
Simplifying conﬁguration by abstracting common tasks for the end-user aims to relieve customers and
technical support staﬀ. Using automatic device identiﬁcation and automating common tasks such as
port forwarding, will result in savings in support along with a better user experience. This project will
investigate the simpliﬁcation of usability when conﬁguring port forwarding and evaluate the changes.
Many common support issues could be automated by the software running on the customer premises
equipment (CPE). By eﬀective communication with the end-user through the user interface, these
improvements would also aid ﬁrst-line support when guiding the customer over phone. In order to
even begin conﬁguring the device, the correct IP address to the CPE has to be typed in the web
browsers address bar. A wrapper script which helps with automatic DNS translation from a domain
name to its LAN IP address will be developed. The project goals can be summarized as:
• Preset library of port forwarding rules
• Automatic detection of services on the local network devices
• Evaluate usability
• Internal DNS translation of the gateway IP address
1CHAPTER 1. INTRODUCTION
The main purpose of this degree project is to achieve a more user friendly operation by adding
automatic service discovery on the local network within the OpenWrt system. It is assumed that
workﬂow in the conﬁguration process. The internal DNS translation for reaching the front-end of the
CPE through an internal domain name, does not account for various browser implementations of the
address bar, which could sometimes interpret a domain address as a search query. The internal DNS
translation system will operate independently from the rest of the project, it will not be dependant
on either the preset library or the service detection.
Evaluation of usability is meant to be of a more qualitative type and focuses on reason rather than
test groups. Measuring actual eﬀects on support costs is out of the scope of this degree project.
By building a library of presets for common port forwarding rules and developing a simple selection
dialog, the end user can more eﬃciently set up port their ﬁrewall redirection rules and general con-
ﬁguration of their gateway. A limited range of settings and automatic portforwarding settings are
presented to the user.
For the system of service identiﬁcation, a wrapper around a port scanner is implemented, which
used to match against the known presets and protocols, and oﬀers the user a choice of applying the
preset rules for the newly detected network device. The preset system is extensible, allowing retailers
to add their own devices and services as preset deﬁnitions, each with their speciﬁc forwarding rules.
DNS translation of the gateway IP address, allows easy access through the web browser by simply
entering a domain name in the address bar, which should be easier for users than remembering or
ﬁguring out its IP. This works by translating the gateways internal IP address to a domain name and
keeping it up to date whenever the IP is changed.
These parts will be developed in an iterative process with support and suggestions from the
company throughout the project.
Inteno Broadband Technology is a company that supplies customer premises equipment for internet
service providers. Their headquarters and research and development center is located in Stockholm,
Sweden. Inteno Open Systems Platform, or iopsys, is a Linux-based open source platform running
on their CPE. It is based on the OpenWrt distribution which targets embedded devices, speciﬁcally
The research and development department at Inteno works on improving the platform, adding
value to the end users, the operators and the larger OpenWrt software ecosystem. By the nature
of OpenWrt’s free software licence4, the code is publicly released and available for download from
The resellers of Inteno gateways are mainly internet service providers, who then deploy the CPE
among end users. Connectivity of the XBox 360 gaming console has been chosen as the reference unit
to do tests and veriﬁcations against. Based on previous information from technical support of service
providers, one of the most commonly reported issues of end users, is setting up port forwarding for
connecting their XBox 360 to the XBox Live network.
End users of Inteno CPE have expressed concern about the relative diﬃculty of port forwarding and
conﬁguration of their network gateway. The default settings page for port forwarding is currently
located under the Firewall tab in the OpenWrt front end, the forwarding procedure involves looking
up ports for the speciﬁc device or unit, and entering these on the web page forms.
These set of rules sometimes involve several ports and over diﬀerent protocols, increasing the
possibility for misstep and faulty conﬁguration by the end user. If these complexities could be reduces
and presented in a way that is easily understandable, then user satisfaction would increase. Such
tasks could be well suited for automation by software, especially for applications and devices which
require several port forwarding rules, automating some of these steps will save time and bring overall
value to the user experience.
Currently the interaction with the web interface requires the user to enter the gateways IP address
in the web browsers address bar. This potential barrier to access the web interface could be lowered
by using DNS address-to-name mapping, locally on the internal network, just like how DNS works on
the global internet.
3.1 Design and layout
The user interface of a product, including graphical and ergonomic design, is an important part of the
brand and ease of use of products. Inaccessible interfaces to electronic devices and its software, can
cause irritations with the product and leave the user with a sense of hopelessness and self-blame.12 It
is important to communicate a clear usage that is as unambiguous as possible to the user, the project
aims to focus on this idea of clarity when implementing the improvements. This is the main goal
of the user experience, removing the possibility of misstep by communicating clearly. Citing Krug’s
second law of usability, “It doesn’t matter how many times I have to click, as long as each click is a
mindless, unambiguous choice”.10
3.2 Measuring improvements
For evaluating usability a more qualitative approach is chosen as opposed to testing on humans.
The main reason for the more analytical approach is inexperience with putting together test groups
and evaluating the results. This allowed for a more sequential approach in delivering the module
and provided time to familiarize with the OpenWrt ecosystem before starting work on implementing
the user interface. At the request of Inteno, the basic usability scenario chosen for evaluation was
conﬁguring port forwarding of the XBox 360.
Disadvantages of not using usability tests with actual people, includes developers missing out
on valuable feedback from the people they are designing it for. The iterative process of producing
a prototype, having users test is and improving the design based on own observations and their
5CHAPTER 3. RESEARCH
direct feedback is lost. The main purpose of the usability improvements presented in this project, is
presenting a more guiding and interactive approach, resulting in fewer mental steps.
We feel the method chosen works for its intentions and is suitable for a project of this scope,
although continuous testing would have been employed had we done it again
3.3 Alternative using a locally run application
To test the newly applied conﬁgurations, web-based or locally run port scanners can be used, as
opposed to a gateway-centric port forwarding solution presented by this report. Web-based port
scanners will scan the users external IP address for open ports and present which are open, however
this does not guarantee that the packets are routed to the correct internal address.
Alternative solutions to simplifying port forwarding include using standalone applications which
run on a PC, connected to the local network. These applications also use internal lists of port
forwarding rules for common applications and devices, which is then applied for a speciﬁc IP address
on the local network. Examples of locally run port scanners include PFConﬁg, which functions in a
similar way to the proposed system but requires a separate download and installation.8
3.4 Programming languages
Lua is a programming language that is intended to be embeddable and extensible, it is implemented
in C and enables the developer to employ diﬀerent programming techniques with its multi-paradigm
approach. The programming language is distributed with a permissive free software licence5, while
being open source allowing use within proprietary software. The language is dynamically typed,
which means that the underlying variable type is determined at runtime and supports features such
as memory management, closures and ﬁrst-class functions.
Implementation-wise the language is small in size yet expressive, which makes it suitable for higher
level programming in embedded systems such as network gateways. Since the web user interface of
OpenWrt uses Lua, it was beneﬁcial to implement as much of the application in the programming
language and contained in a Lua Conﬁguration Interface module. See section 3.5.4 for details on Lua
Conﬁguration Interface, or LuCI.
3.4.2 Almquist shell
Adhering to the POSIX standards, Almquist shell on OpenWrt it is the default operating system
command-line interface, scripting language and command processor. It has less features than bash and
sometimes requires a strict and sometimes more verbose scripting style, without the permissiveness of
bash idioms, such practices are referred to as bashism and are often incompatible with ash and such
Shell scripting allows the developer to aggregate the power of a range of UNIX programs, using
redirection to route the output of one program as the input of another, and with the shell prompt
as an interactive development environment it allows for rapid prototyping. The permissiveness and
features of bash, has brought along handy constructs such as process substitution, which is unavailable
in ash. Instead the port scanning wrapper of section 4.3.1 solves this by using named pipes, in which
the script manually creates a temporary buﬀer in which the processes can exchange data. An example
of explicitly redirecting the output from a command into a named pipe and then processing the output
of that command is available in appendix B.1.
Also called sh, A shell or ash
63.5. SOFTWARE SUITE
custom graphical elements and interaction logic to the Model-View Controller framework. LuCI can
perform much of the heavy lifting when it comes to interactive pages, but it supplies support routines
for AJAX operations through their xhr.js library. AJAX calls are used extensively in the module,
because of the diﬃculty of writing interaction logic sticking to the LuCI CBI models. For an exam-
receiving an answer, please refer to ﬁgure B.2 in appendix B.
3.5 Software suite
The newer Inteno devices ship with the OpenWrt distribution, which is a small GNU/Linux operating
system. It provides the developer with the basic UNIX debugging tools and a POSIX compatible
command-line interface shell. As common with free software, the OpenWrt exists in an ecosystem of
applications and tools, in this section a few of these parts are discussed.
OpenWrt is a free and open-source GNU/Linux distribution, targeting embedded devices, speciﬁcally
network routers, but can run on almost any set of hardware. It intends to be a meta distribution and
oﬀers developers a framework on which to base their ﬁrmware on, it is regarded as the Bazaar model
from Eric S. Raymond’s The Cathedral and the Bazaar.13
Cross-compilation is enabled by OpenWrt Buildroot, which compiles the C code using uClibc, a
lightweight C library focusing on embedded Linux systems. OpenWrt is then compiled and linked
using gcc and binutils, with the help of Makeﬁles and patches for the various gcc versions and target
platforms. The GNU Autotools handles dependencies, linking and cross-compiling, provides build
automation for end users and developers. OpenWrt Buildroot supports menuconﬁg, which before
building lets users select which features of the distribution they want to compile or link from a menu
of choices, menuconﬁg is often used when building the Linux kernel.
OpenWrt oﬀers the BusyBox set of stripped-down UNIX tools, enabling advanced users to fully
interact with their Linux system and providing developers with a familiar platform for debugging and
testing their product.6
Uniﬁed Conﬁguration Interface, or UCI, is used in OpenWrt as a uniform format for commonly
used conﬁguration ﬁles. UCI has a Lua bindings as well as a command line interface, to read and
modify the conﬁguration ﬁles. One example is the rules for port forwarding, which are deﬁned in the
UCI compatible conﬁguration ﬁle in /etc/config/firewall. A port forwarding rule which forwards
external HTTP traﬃc over port 80 to the internal IP 192.168.1.214, is shown in ﬁgure A.1 in appendix
A, in our example the line conﬁg redirect deﬁnes the start of a section, a section can contain several
values and the UCI conﬁguration ﬁle can consist of several such sections.
The package management system used in OpenWrt is Open PacKaGe Management, or OPKG. It is
based oﬀ the discontinued ipkg and operates similar to APT and dpkg of Debian-based distributions.
It targets GNU/Linux based operating systems for embedded devices and there are currently over
2000 OPKG packages available for OpenWrt.
Just like in ordinary web design
7CHAPTER 3. RESEARCH
The OpenWrt system and its packages are built using GNU Autoconf, which automates tasks
associated with compiling larger software suites. This includes pulling in parts of the system from
remote software repositories and automatically resolving dependencies on programs and libraries.
3.5.3 Inteno Open Platform System
For Customer Premises Equipment like wireless gateways, Inteno Open Platform System oﬀers an
open-source Linux distribution based on OpenWrt. It uses the OpenWrt’s build system including
cross-compilation toolchain to ensure compatibility with the ecosystem and upstream.
Inteno maintains and hosts a repository, which contains a frozen release of OpenWrt and compat-
ible packages and patches. Freezing an ever changing open source codebase means forking an existing
version, submitting more conservative patches to the system and focusing on smaller changes. This
leads to good compatibility with Inteno hardware and protection from breakage because of upstream
3.5.4 Lua Conﬁguration Interface
Lua Conﬁguration Interface, or LuCI, is a suite of programs and libraries for extending OpenWrt using
the Lua programming language and providing a web interface built with the Model-View Controller
architecture. It originated in the OpenWrt project, but is now an independent project on its own.
Developing LuCI pages that interact with the settings of the OpenWrt deployment is usually done
with CBI models, which map the Lua module to OpenWrt and its conﬁguration ﬁles.
LuCI relies on the Model-View Controller software architecture pattern and separates data and
its visual representation. It is divided in three parts with the model representing the data and storing
it in UCI conﬁguration ﬁles. The view provides a visual representation of the model. When sticking
to CBI models, most of the code and design eﬀort can be put into the Lua module, allowing LuCI to
automatically handle GUI elements, form validation, and writing UCI ﬁles.
The controller part of the LuCI MVC framework is the dispatching tree. It associates input
events with logic in the model, and contains a tree of dispatching actions which is most apparent in
the display of the dropdown menus of the web site.
In order for the user to have access to the web interface by a domain name instead of an IP address,
we use DNS. Dnsmasq is a lightweight DNS server, using the /etc/hosts ﬁle to translate IP addresses
on the local network to domain names.1 The simple operation of Dnsmasq is suitable for serving
address translations on smaller networks, such as LAN.
Code released and maintained by the oﬃcial project
The overall design of the system consists of two parts, the service identiﬁcation and port forwarding
presets. These parts are connected by the LuCI dispatcher and the model. Communication between
the diﬀerent parts of the port forwarding process is outlined in ﬁgure 4.1. The user initiates the iden-
tiﬁcation procedure and the identiﬁcation process starts. Nmap and its wrapper script is represented
by the package : detect process in the digram, it receives a call from the dispatcher that originates
in an AJAX call from the view. A scan is then performed in the background by Nmap, which tries
to “guess” the services available behind the IP address on the network. When the results from the
identiﬁcation are returned the list of presets is sorted. Based on the results from the identiﬁcation,
the user can review their options before ﬁnally applying the new settings.
User model:devices.lua package:detect conﬁg:preset conﬁg:ﬁrewall
lookup ports and protocols
update ﬁrewall rules
Figure 4.1. Sequential diagram of applying port forwarding rules, the User box
represents the view or the user interaction part of the implementation.
By selecting the name of the service, the correct forwarding rules are loaded and presented to the
user, who can then chose to apply them, after which they are written to the conﬁguration ﬁles. The
port forwarding wizard works with the standard OpenWrt conﬁguration ﬁles and uses nmap as its
backend for discovering and identifying services on the local network.
Visible in the sequential diagram of ﬁgure 4.1 are the two UCI conﬁguration ﬁles, conﬁg:ﬁrewall
(/etc/config/firewall) and conﬁg:presets (/etc/config/preset), located on the router ﬁlesystem.
The service detection wrapper returns the newly discovered services, these can then be matched
Not shown in diagram
OpenWrt can be conﬁgured using Uniﬁed Conﬁguration System, or UCI. It also provides a command-line utility
and provides an API for programming languages such as C and Lua
1CHAPTER 4. IMPLEMENTATION
against the presets of forwarding rules. The ﬁnal redirection settings are applied to the ﬁrewall
conﬁguration ﬁle, based on the preset library, the network service scan and user choice.
There are a few issues with the current ﬁrewall tab for novice users. It requires the user to acquire
all the ports necessary for the network service, this increases the chance of missteps and faulty
conﬁguration. Another issue that has been identiﬁed are the tedious steps involved in applying
the rules through the web interface.
4.1.1 Current ﬁrewall tab
For the device or network service to function properly, the user has to add a forwarding rule for each
required port. A screenshot of the port forwarding form in the web interface is shown in ﬁgure 4.2.
For our reference unit, the XBox 360 which requires ports 88 (UDP), 3074 (UDP), 3074 (TCP) and
80 (TCP), this requires four such steps.
Figure 4.2. Current port forwarding dialog, the user is burdened with identifying
and applying rules for every port of the service.
4.1.2 Guided ﬁrewall tab
In the projects improved port forwarding dialog, the user is confronted with fewer mental steps. In
ﬁgure 4.3, we see a conceptual ﬂowchart of the all the steps in the current user interaction when port
forwarding. The two parts called “Look it up” requires a switch of context which can delay the
conﬁguration of the port forwarding.
The mental steps and actions within the gray area of ﬁgure 4.3 (left), will form a loop every time
the service has several protocols and ports. The general idea is reducing as many of these harder
choices or replacing them with simpler ones. In addition to the “Look it up”-steps, in the example
of the XBox 360 – which has four ports – the user have to perform seven additional actions for the
three remaining ports:
• Select host
• Enter protocol and port
• Enter description
The intention is to turn hard choices into easier ones, while automating as many tasks as possible.
4.2 User interface
network services, as shown in ﬁgure 4.4. Listed presets are sorted by the output from the service
identiﬁcation process, presenting the user with the most likely services at the top of the list. To apply
the port forwarding rule set, the user selects a node in the network and the service from the sorted
list, then applies it.
104.2. USER INTERFACE
Port forward page
Display discovered services.
Preselect the ﬁrst from Preset
Figure 4.3. Usability ﬂowchart for conﬁguring port forwarding, illustrating diﬀer-
ences in user interaction with the conventional port forwarding tab (left), to the one
presented in this paper (right).
Figure 4.4. Screenshots of scanning the local network for available services.
Instead of performing all the steps automatically like in the current implementation, the user is
interacting with the system and approving the suggested changes before they are set. The service
identiﬁcation is there to help the users make choices, not decide for them.
This way of interacting with the user before writing any ﬁles required the more asynchronous
An alternative solution would be to write temporary UCI conﬁguration ﬁles to disk. This would
allow the implementation to rely on LuCI’s CBI models, which are discussed in section 3.5.4, probably
for this use case is that we do not want the conﬁguration ﬁles to be used as temporary databases.
Since the interactive logic requires an intermediary state of possible forwarding selections and the
11CHAPTER 4. IMPLEMENTATION
Figure 4.5. Screenshots of applying the forwarding rules and viewing the resulting
redirection rules on the conventional ﬁrewall conﬁguration page.
The program Nmap is a popular network discovery program, and was chosen as the engine for the
service scanner implementation. The XBox 360 gaming console was chosen at Inteno’s suggestion,
with the motivation that it is one of the devices that end users have had the most issues with, in
regards to port forwarding. Nmap is capable of detecting several operating systems, embedded devices
and network services.
Using Nmap is quite intrusive and could be detected as an attack by intrusion detection software,
of network traﬃc, one such utility is P0f which uses passive scanning of traﬃc.7 However, in order
to provide low latency, the Inteno routers are conﬁgured with cut-through switching, which would
render the passive ﬁngerprinting of P0f ineﬀective. Cut-through switching, as opposed to store and
forward, starts forwarding the packets before it has been fully received, this hides hides the packet
information from software processing and analyzing techniques. These disadvantages of P0f along
with Nmap being a common, well tested-tool in analysis of network topology and nodes, it was chosen
as the backend.
Executing the Nmap scanning utility and returning results, is implemented as a shell script. In the
development process of the wrapper, a shell script was written to test the functionality and extract
data about the detected services. The original intent was to replace this with a Lua script, for a more
consistent codebase in regards to the rest of the system. Due to lack of time, the rewrite was cancelled
When running the basic operating system scan service identiﬁcation features of Nmap, there is no
way for Nmap to positively identify an XBox 360. This failure is due to an inconclusive ﬁngerprint.
Using aﬂagnamed version scan – run with arguments -sV – Nmapinterrogates ports morethoroughly
and returns more information than a regular operating system scan. The extra scan using the Nmap
version scan, was successfully used to identify the XBox 360. Whenever the service is identiﬁed as
LSA-or-nterm, the TCP ports 1026 and 1027, were scanned, either of these are in use by the XBox
360.11 A more thorough version scan is issued for the device and then matched for XBox 360 UPnP,
124.4. PRESET LIBRARY
which the wrapper is set to interpret as a positive match and returns its service name .
An alternative solution would be constructing an Nmap-compatible ﬁngerprint, this was decided
against because of the wish to use a standard ipkg package of Nmap, which is already in the OpenWrt
4.4 Preset library
The preset library consists of common services and port data, that the user would want to set up
forwarding rules for. Details of these ports and protocols are provided by the application developers,
speciﬁcally for address translation reasons.
Using the Uniﬁed Conﬁguration System, which is included in the OpenWrt distribution, all the
basic commands for conﬁguring the ﬁrewall rules were prototyped and explored. A set of XBox 360
port forwarding rules from the preset conﬁguration ﬁle is shown in ﬁgure A.1 in appendix A. The
frontend in an AJAX call through the Lua dispatcher.
For the scope of this project the following services is added to the preset library:
• HTTP traﬃc
• POP3 email
• FTP traﬃc
• SSH traﬃc
• IMAP email
• IMAP3 email
• IMAPS email
• POP3S email
Applying the rules requires the user to select the desired service from a list, and pressing a button
4.5 Internal DNS
The implementation of the internal IP address translation is a small and simple improvement of the
IP address of the gateway. DNS works by translating hard to remember IP addresses to memorable
domain names. By using the lightweight DNS forwarder Dnsmasq we can make the web interface
easier to access. Being a standard part of most operating systems, the hosts ﬁle keeps a localized
record of address translations. On most Unix-like operating systems the hosts ﬁle is assessable from
/etc/hosts, and consist of a text ﬁle that list IP addresses and their corresponding domain name.
This small usability improvement consists of a shell script that keeps the routers current IP
up to date with the domain name login.lan. The script gets its current IP address from the UCI
command-line interface, it then proceeds to iterate through the lines of the hosts ﬁle, updating the IP
The XBox 360 is labeled xbox360 in the conﬁguration presets
The dispatcher is the Controller in the MVC framework