Question? Leave a message!




A mobility gateway for small-device networks

Design of wireless gateway between on-board vehicle wired networks and mobile devices A TDMA-based MAC between gateway and devices in M2M networks
Dr.ElonHibbs Profile Pic
Dr.ElonHibbs,Malaysia,Researcher
Published Date:09-12-2017
Your Website URL(Optional)
Comment
Abstract 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 configuration by the user, potentially leaving the network vulnerable to attacks. We present an enhancement of the current port forwarding configuration 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 configure 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 unified configuration 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 configuring network gateways. iChapter 1 Introduction 1.1 Background 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 configuring their gateways. 1.2 Goals Simplifying configuration by abstracting common tasks for the end-user aims to relieve customers and technical support staff. Using automatic device identification 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 simplification of usability when configuring port forwarding and evaluate the changes. Many common support issues could be automated by the software running on the customer premises equipment (CPE). By effective communication with the end-user through the user interface, these improvements would also aid first-line support when guiding the customer over phone. In order to even begin configuring 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 1.3 Delimitations 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 operationofthedeviceisuser-friendlier, whentheend-userreceivehelpfulhintsandamoreinteractive workflow in the configuration 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 effects on support costs is out of the scope of this degree project. 1.4 Solutions By building a library of presets for common port forwarding rules and developing a simple selection dialog, the end user can more efficiently set up port their firewall redirection rules and general con- figuration of their gateway. A limited range of settings and automatic portforwarding settings are presented to the user. For the system of service identification, a wrapper around a port scanner is implemented, which performsascanofthenetworknodesandreturnsalistofavailableservices. Thisinformationisinturn used to match against the known presets and protocols, and offers 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 definitions, each with their specific 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 figuring 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. 2Chapter 2 Current situation 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, specifically network gateways.3 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 Intenos webpage.2 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 verifications 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. 3Chapter 3 Research End users of Inteno CPE have expressed concern about the relative difficulty of port forwarding and configuration 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 specific device or unit, and entering these on the web page forms. These set of rules sometimes involve several ports and over different protocols, increasing the possibility for misstep and faulty configuration 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 configuring 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 configurations, 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 specific IP address on the local network. Examples of locally run port scanners include PFConfig, which functions in a similar way to the proposed system but requires a separate download and installation.8 3.4 Programming languages 3.4.1 Lua Lua is a programming language that is intended to be embeddable and extensible, it is implemented in C and enables the developer to employ different 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 first-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 beneficial to implement as much of the application in the programming language and contained in a Lua Configuration Interface module. See section 3.5.4 for details on Lua Configuration Interface, or LuCI. 3.4.2 Almquist shell 1 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 primitive shells. 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 buffer 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. 1 Also called sh, A shell or ash 63.5. SOFTWARE SUITE 3.4.3 JavaScript JavaScript is a common interpreted programming language mostly used in client-side web develop- 2 ment. For the LuCI web interface in OpenWrt, the view can be extended using JavaScript to include 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 difficulty of writing interaction logic sticking to the LuCI CBI models. For an exam- ple on how to perform an XMLHttpRequest, sending data from JavaScript to the Lua backend and receiving an answer, please refer to figure 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. 3.5.1 OpenWrt OpenWrt is a free and open-source GNU/Linux distribution, targeting embedded devices, specifically network routers, but can run on almost any set of hardware. It intends to be a meta distribution and offers developers a framework on which to base their firmware 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 Makefiles 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 menuconfig, which before building lets users select which features of the distribution they want to compile or link from a menu of choices, menuconfig is often used when building the Linux kernel. OpenWrt offers 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 Unified Configuration Interface, or UCI, is used in OpenWrt as a uniform format for commonly used configuration files. UCI has a Lua bindings as well as a command line interface, to read and modify the configuration files. One example is the rules for port forwarding, which are defined in the UCI compatible configuration file in /etc/config/firewall. A port forwarding rule which forwards external HTTP traffic over port 80 to the internal IP 192.168.1.214, is shown in figure A.1 in appendix A, in our example the line config redirect defines the start of a section, a section can contain several values and the UCI configuration file can consist of several such sections. 3.5.2 OPKG The package management system used in OpenWrt is Open PacKaGe Management, or OPKG. It is based off 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. 2 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 offers 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 3 leads to good compatibility with Inteno hardware and protection from breakage because of upstream code changes. 3.5.4 Lua Configuration Interface Lua Configuration 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 configuration files. 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 configuration files. The view provides a visual representation of the model. When sticking to CBI models, most of the code and design effort can be put into the Lua module, allowing LuCI to automatically handle GUI elements, form validation, and writing UCI files. 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. 3.5.5 Dnsmasq 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 file 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. 3 Code released and maintained by the official project 8Chapter 4 Implementation The overall design of the system consists of two parts, the service identification and port forwarding 1 presets. These parts are connected by the LuCI dispatcher and the model. Communication between the different parts of the port forwarding process is outlined in figure 4.1. The user initiates the iden- tification procedure and the identification 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 identification are returned the list of presets is sorted. Based on the results from the identification, the user can review their options before finally applying the new settings. User model:devices.lua package:detect config:preset config:firewall start wizard start return services show services select forwarding lookup ports and protocols show forwarding apply forwarding update firewall 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 configuration files. The 2 port forwarding wizard works with the standard OpenWrt configuration files and uses nmap as its backend for discovering and identifying services on the local network. Visible in the sequential diagram of figure 4.1 are the two UCI configuration files, config:firewall (/etc/config/firewall) and config:presets (/etc/config/preset), located on the router filesystem. The service detection wrapper returns the newly discovered services, these can then be matched 1 Not shown in diagram 2 OpenWrt can be configured using Unified Configuration System, or UCI. It also provides a command-line utility and provides an API for programming languages such as C and Lua 9 1CHAPTER 4. IMPLEMENTATION against the presets of forwarding rules. The final redirection settings are applied to the firewall configuration file, based on the preset library, the network service scan and user choice. 4.1 Usability There are a few issues with the current firewall 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 configuration. Another issue that has been identified are the tedious steps involved in applying the rules through the web interface. 4.1.1 Current firewall 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 figure 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 firewall tab In the projects improved port forwarding dialog, the user is confronted with fewer mental steps. In figure 4.3, we see a conceptual flowchart 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 configuration of the port forwarding. The mental steps and actions within the gray area of figure 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 Foraportforwardinginterfacepage, theuserispresentedwithdetectednodesandtheircorresponding network services, as shown in figure 4.4. Listed presets are sorted by the output from the service identification 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 no Host Look Wizard page it up known? no Host yes Scan host known? Ports and protocol Select host known? yes Display discovered services. no Preselect the first from Preset yes Look Select host it up yes Enter protocol and port Correct no Select service Preset from Presets selected? More ports and Enter description protocols? Display details. yes no Apply Apply Figure 4.3. Usability flowchart for configuring port forwarding, illustrating differ- 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. 1 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 identification is there to help the users make choices, not decide for them. This way of interacting with the user before writing any files required the more asynchronous approach using XMLHttpRequests from the JavaScript code than what was offered by using LuCI’s CBI model. This method is known as asynchronous JavaScript and XML, or AJAX. An alternative solution would be to write temporary UCI configuration files to disk. This would allow the implementation to rely on LuCI’s CBI models, which are discussed in section 3.5.4, probably 1 making the codebase more consistent with less custom JavaScript. Disadvantages of using CBI models for this use case is that we do not want the configuration files to be used as temporary databases. Since the interactive logic requires an intermediary state of possible forwarding selections and the developers experience in JavaScript, it was decided to implement it with AJAX techniques. 11CHAPTER 4. IMPLEMENTATION Figure 4.5. Screenshots of applying the forwarding rules and viewing the resulting redirection rules on the conventional firewall configuration page. 4.3 Nmap 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, usedtomonitorthenetworkforillicitbehavior. Analternativeapproachisusingpassivefingerprinting of network traffic, one such utility is P0f which uses passive scanning of traffic.7 However, in order to provide low latency, the Inteno routers are configured with cut-through switching, which would render the passive fingerprinting of P0f ineffective. 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. 4.3.1 Wrapper 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 and a quick adaptation was made to to the script to return valid JSON for the JavaScript frontend. When running the basic operating system scan service identification features of Nmap, there is no way for Nmap to positively identify an XBox 360. This failure is due to an inconclusive fingerprint. Using aflagnamed 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 identified 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 3 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 fingerprint, this was decided against because of the wish to use a standard ipkg package of Nmap, which is already in the OpenWrt repository. 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, specifically for address translation reasons. Using the Unified Configuration System, which is included in the OpenWrt distribution, all the basic commands for configuring the firewall rules were prototyped and explored. A set of XBox 360 port forwarding rules from the preset configuration file is shown in figure A.1 in appendix A. The rules were formatted to fit the UCI configuration file format and returned as JSON to the JavaScript 4 frontend in an AJAX call through the Lua dispatcher. For the scope of this project the following services is added to the preset library: • Xbox360 • HTTP traffic • POP3 email • FTP traffic • SSH traffic • 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 which runs a JavaScript function, performing an AJAX call to the Lua backend, issuing the UCI calls. See section 3.4.3 for examples of how JavaScript is used in the LuCI module. 4.5 Internal DNS The implementation of the internal IP address translation is a small and simple improvement of the userexperience. Inorderfortheendusertoreachthewebinterfacetheyneedtofindoutandenterthe 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 file keeps a localized record of address translations. On most Unix-like operating systems the hosts file is assessable from /etc/hosts, and consist of a text file 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 file, updating the IP 3 The XBox 360 is labeled xbox360 in the configuration presets 4 The dispatcher is the Controller in the MVC framework 13