Preliminary development of an inexpensive and portable network monitoring probe using an internet embedded microprocessor - PDF

Please download to get full document.

View again

of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Nature & Wildlife

Published:

Views: 2 | Pages: 8

Extension: PDF | Download: 0

Share
Related documents
Description
University of Wollongong Research Online Faculty of Informatics - Papers (Archive) Faculty of Engineering and Information Sciences 2009 Preliminary development of an inexpensive and portable network monitoring
Transcript
University of Wollongong Research Online Faculty of Informatics - Papers (Archive) Faculty of Engineering and Information Sciences 2009 Preliminary development of an inexpensive and portable network monitoring probe using an internet embedded microprocessor Karthic Rajaram Montse Ros University of Wollongong, Peter James Vial University of Wollongong, Publication Details Hoang Nguyen, G., Phung, S. & Bouzerdoum, A. (2009). Reduced training of convolutional neural networks for pedestrian detection. In H. Huynh, D. Tien & G. Shi (Eds.), The 6th International Conference on Information Technology and Applications (ICITA 2009) (pp ). Hanoi, Vietnam: ICITA. Research Online is the open access institutional repository for the University of Wollongong. For further information contact the UOW Library: Preliminary development of an inexpensive and portable network monitoring probe using an internet embedded microprocessor Abstract Management of a telecommunication network involves the requirement to monitor and manage devices on local and wide area networks (for optical, wired and wireless). Devices used to perform this function are referred to as Remote Monitoring devices or network probes. This paper investigates the prototyping of a network probe which uses an embedded internet microprocessor to collect and send data to a network monitor. The device uses the TINI Internet Interface developed by Dallas Semiconductor. This device was chosen as the ethernet driver has a promiscuous mode which potentially allows the capture of all packets sent on the ethernet connection of the embedded internet microprocessor. A prototype system of the Remote Network Monitoring System is developed which utilises Java based software for server and client on a personal computer and some preliminary results are presented. The client software was not implemented on the TINI due to problems associated with memory limitations of the chosen embedded internet processor, with the TINI only having simple functionality of packet capture demonstrated. Further hardware design requirements for the TINI board are needed to provide sufficient resources on the embedded processor to allow for effective packet capture and storage. Keywords network, monitoring, probe, internet, embedded, microprocessor, development, preliminary, inexpensive, portable Disciplines Physical Sciences and Mathematics Publication Details Hoang Nguyen, G., Phung, S. & Bouzerdoum, A. (2009). Reduced training of convolutional neural networks for pedestrian detection. In H. Huynh, D. Tien & G. Shi (Eds.), The 6th International Conference on Information Technology and Applications (ICITA 2009) (pp ). Hanoi, Vietnam: ICITA. This conference paper is available at Research Online: Preliminary Development of an Inexpensive and Portable Network Monitoring probe using an Internet Embedded Microprocessor Karthic Rajaram, Montse Ros, Peter James Vial University of Wollongong Abstract Management of a telecommunication network involves the requirement to monitor and manage devices on local and wide area networks (for optical, wired and wireless). Devices used to perform this function are referred to as Remote Monitoring devices or network probes. This paper investigates the prototyping of a network probe which uses an embedded internet microprocessor to collect and send data to a network monitor. The device uses the TINI Internet Interface developed by Dallas Semiconductor. This device was chosen as the ethernet driver has a promiscuous mode which potentially allows the capture of all packets sent on the ethernet connection of the embedded internet microprocessor. A prototype system of the Remote Network Monitoring System is developed which utilises Java based software for server and client on a personal computer and some preliminary results are presented. The client software was not implemented on the TINI due to problems associated with memory limitations of the chosen embedded internet processor, with the TINI only having simple functionality of packet capture demonstrated. Further hardware design requirements for the TINI board are needed to provide sufficient resources on the embedded processor to allow for effective packet capture and storage. information that will not change frequently, such as the number of ports on a router. The second category is Dynamic information, which is constantly changing, such as transmission of packets on a network. The final classification is Statistical information which is derived from dynamic information such as packets transmitted by a node to another node in the network. The collection of static information can be made available to the network monitor via a software agent installed in the monitored element. Alternatively it can also be obtained from a proxy agent. Dynamic and statistical information is also collected and stored in a similar manner to static information. Index Terms RMON probe, TINI, network monitoring, embedded internet device N I. INTRODUCTION ETWORK Monitoring is the cornerstone of automated network management. The objective of network monitoring is to collect information concerning the status and performance of nodes which are part of a managed network. The International Organisation for Standardisation (ISO) defines the key functions of network management as fault management, accounting management, configuration and name management, performance management and security management. Network monitoring is essentially the backbone which supports the five functional areas of the network monitoring framework. According to Stallings [1], the information that should be obtained from network monitoring systems can be grouped into three main categories. The first category is Static Manuscript received August 1, Figure 1: Achitecture of a Network Management System [2] The architecture of a NMS (Network Management System) can be demonstrated from a functional perspective [2]. This model represents the monitoring system as four functional blocks and is shown in Figure 1. These are the monitoring application, manager function, agent function, and managed objects. The prototype system used a TINIs400 evaluation board provided by Dallas Semiconductor and integrated available packet capturing libraries such as WinPcap [3] and Jpcap [4] to illustrate how such a system could be potentially deployed in a switched network. Section II includes an examination of the TINI microprocessor used. Section III considers the software used in the PC (Personal Computer) to provide a Remote Network Management System (RNMS). Section IV describes the developed TINI ethernet driver which was able to capture packets, however due to memory limitations it was not able to do this in promiscuous mode and possible solutions to this problem are suggested. Section V describes the software developed for the PC prototyping of the RNMS and provides measured results at different link utilizations. Section VI concludes the paper and provides future areas of development and research. II. THE TINY INTERNET INTERFACE A. TINIs400, TINIm400, DS80C400 Figure 2 shows the components of the TINIs400 socket and TINIm400 module which was deployed as a portable internet probe in this prototype. The microprocessor used is the DS80C400 designed and manufactured by Dallas Semiconductor to be used in internet embedded applications. It is an 8051 device and has a maximum clock speed of 75MHz. It uses a 24 bit addressing scheme to allow access to up to 16MB of contiguous memory, though the evaluation board only comes with 1MB of SRAM and 1MB of flash RAM. The TINI Operating System is located in the ROM of the DS80C400 microprocessor and this includes the functionality of the IPv4/6 network stack. The network stack provides for a maximum of thirty two concurrent TCP connections with a transfer rate of up to 5Mbps through the Ethernet MAC [5]. Figure 2: Components of the TINIs400 evaluation board [5] B. Packet Capture Role of TINI The role of the TINIs400 is to capture the ethernet data packets and send this to the monitoring application which is to be run on a PC via an Ethernet link. The PC would have the analysing modules, the configuration modules and possibly an RMON MIB implemented. As highlighted in Figure 3, the combination of the TINIs400 and the PC (with installed RMON probe software) provides a possible implementation of an inexpensive and highly portable RMON probe. Figure 3: Basic concept of using the TINI and a PC to capture and process packets at the MAC layer The DS80C400 also has a built-in Ethernet media-access controller (MAC) with an standard media independent interface (MII), the MII defines I/O lines that allow the DS80C400 to communicate with the physical layer interface or network interface card (NIC). The MII contains two basic blocks. The two blocks are the MII I/O Block and the MII Management block. The function of the MII I/O Block is to deliver and receive Ethernet frames to and from an external NIC. Through the MII I/O the DS80C400 is able to support all of the transmit and receive data transactions between the DS80C400 MAC and the external NIC. The DSTINIm400 is built with the DS80C400 processor and this microcontroller was originally designed with Ethernet networking as its primary objective or application area [6]. With the support of the MII, the DS80C400 allows for the integration of the Ethernet MAC and as a result allows for the capability to access the network stack. Assembly language was used to implement an Ethernet interrupt handler which would be operated in promiscous mode so that all passing packets could be captured by the TINI and resent to the PC. Assembly code was also used to send and receive Ethernet packets to the PC with the monitoring application. The TINI has a native layer which represents the collection of native methods that support Java s API and provides access to the infrastructure of the TINI Operating System. Between this native method implementations and the interpreted Java code is a very thin layer referred to as the Native Layer Interface. This native method interface is a boundary that must be crossed to switch execution between code being executed by the JVM and a native method. As the TINI RMON project requires native methods, a native library needed to be loaded into the system. Although some support is provided by Dallas semiconductors, the bulk of the library needed to be reprogrammed in order to successfully capture the Ethernet packets. Figure 4 shows the relationship between the various layers in the TINI software runtime environment. The DS80C400 has the ability to capture the MAC layer packets via a special function register (SFR) called the buffer control unit (BCU). The BCU serves as the central controller of all DS80C400 Ethernet activity and is responsible for coordinating and reporting status for all data-packet transactions between the Ethernet MAC and the 8kB dual port buffer memory [7]. The BCU also regulates CPU read/write activity to the Ethernet controller blocks through a series of SFRs. These SFRs allows the CPU to issue commands to the BCU, exchange packet size/location information with the BCU, configure the on-chip Ethernet MAC, and communicate with external NICs through the MII serial-management bus. Figure 4: TINI runtime environment [6] To achieve optimal performance an Interrupt Service Routine (ISR) for handling Ethernet activities should be utilized. The Ethernet ISR can be triggered when the BCU reports the status of either transmit or receive packets [8]. When the ISR is enabled the DS80C400 will be able to capture and send Ethernet packets. The implementation of this ISR is implemented in Assembly and the skeleton for the ISR is provided by Dallas Semiconductors. III. THE REMOTE NETWORK MONITORING SYSTEM We first consider existing network protocol analysers and Remote network monitors in the available research literature and online sources. The objective of this was to assess the functionalities of existing systems to assess the feasibility of incorporating such functionalities in the Remote Network Monitoring System (RNMS). Table I shows the four products which were considered. A. Ethereal Ethereal [9] is an open-source, free packet capture tool/packet analyser. Years of considerable development as a protocol analyser have resulted in a feature-rich product with some excellent analysis options. It uses a library known as libpcap to perform the actual packet capture. Libpcap is a systemindependent interface for user-level packet capture and provides a portable framework for low-level network monitoring [9]. Libpcap is a free library for developers wanting to write applications for packet capture. The majority of packet capture software interfaces with this library. B. TCPDump and WinDump TCPDump is an open-source, command line packet capture tool [3]. It is installed on most Linux systems and is often used by system administrators for a quick overview of network activity. Though a simple application, it has many command line switches which are used to customize its functionality. It again uses libpcap to obtain packets, and though traditionally a Linux application, has been ported to run under Windows and other platforms. WinDump is the Windows version of Tcpdump, WinDump is fully compatible with TCPDump and can be used to watch, diagnose and save to disk network traffic according to various complex rules. WinDump captures using the WinPcap library to capture packets [3]. Product Name TCPDump [3] WinDump [3] Ethereal [9] Platform Capture Method Interface All libpcap Command line Windows WinPcap (based on libpcap) Command line Functions RMON- Grabber [10] Windows /Linux Proprietar y Table 1: Existing systems for Network Monitoring Exports Captured Packets to a file Exports Captured Packets to a file All libpcap Graphical Protocol analysis tolls, graphing, statistics Graphical Follows SNMP and RMON 1 standards C. RMONGrabber RMONGrabber is a proprietary closed-source applications marketed at network administrators. Information regarding system design was not available [10]. However the product specifications for this application seem to be similar to that of Ethereal with the exception that the RMONGrabber software follows the SNMP and RMON 1 standards to interact with remote probes[10]. D. Design considerations of RNMS It became clear that libpcap is the most common method for capturing packets. All but two of the researched products of Table I used this library. The decision was made to use WinPcap which is a windows version of libpcap to capture packets for the portable probe due to the fact it was open source and due to the abundance of support for the module. All of the reviewed products had some method of exporting captured data to a file. The feature of being able to save the captured packets in a common format is essential for the RNMS as it allows the captured data to be analyzed for future use and be used in conjunction with other analysis software. Due to its popularity, libpcap was used as the format for stored capture packets. A feature missing from any of the products which had basic remote capture support was the ability to command more than one capture agent from the client software. Particularly on a larger managed networks where it would be desirable to have agents deployed at strategic points, having to manually keep a list of agent locations would be rather time consuming. One of the major design objectives for the portable TINI probe and management PC was that the developed software should support the ability to control multiple agents concurently from a single management console. Another design consideration was to develop a graphical client with an intuitive and appealing interface, paying particular attention to Human Computer Interface (HCI) principles to ensure an enjoyable user experience. The broad design goals of the RNMS were that the software needed to interface with WinPcap library using the Java Native Interface. It also needed to establish a means of finding the packet capturing agents in the given network. This was implemented by sending a UDP Broadcast. It also needs to establish a connection between the remote packet capturing agent which is capturing the Ethernet packets and the client which is in essence is the GUI showing the retrieved packet. This was achieved using Java sockets. It also needed the development of a GUI which allows the user to connect to a particular agent, start/stop capturing packets, show the retrieve packets and save the retrieved packets in a pcap formatted file. The design of the Software architecture is provided in Figure 5. The agent module, shown in Figure 5, should ideally be executed on the TINI board but during development the agent module was executed on a PC. Once the agent is initialized, it creates a Java socket and waits for a client to connect to this socket. When the client wants to find and start retrieving the packets from the agent the client sends a UDP broadcast across the network. The agent replies to this broadcast and hence the agent is identified. Once the agent is identified the client has the option to start retrieving packets from the agent. This is initiated when the client prompts the agent to start capturing packets. The captured packets are sent from the agent to the client via the socket which was established when the agent module was executed. The client GUI is populated by the packets received from the agent in a tabular manner showing the source and destination MAC address of the received packet and the packet type. The client has the option of terminating the packet capture, and saving the retrieved packets into a file for further analysis. Figure 6: Ethernet controller for TINI [6] For the purpose of capturing packets it is required that the Ethernet driver has functions to write and read from the specified registers which store the raw Ethernet packets. It is also important to set the MII to operate in promiscuous mode so that all Ethernet packets which pass across the TINIs ethernet interface are captured rather than simply those which are addressed to it (as is normally the functionality of an RMON probe). From the DS80C400 s data sheet, the Command/Status Register (CSR) called MAC control register governs the operation characteristics of the DS80C400 in promiscuous mode. Hence using the write function from the Ethernet driver it was possible to write the 18 th bit value in the MAC control register to 1; this then forces the DS80400 to operate in promiscuous mode. The design goals of the Ethernet Driver are to set the MAC control register to operate in promiscuous mode; be able to successfully write to the CSRs; be able to successfully read from CSRs; be able to send a Ethernet packet which is placed in the send buffer and finally be able to unload a received packet received from the Ethernet controller. The Java application which runs on the TINI invokes a native call to the assembly library to set the TINI on promiscuous mode and then start to receive Ethernet packets. These received packets are then sent to the RNMS. In essence the Ethernet driver for the TINI is transparent to the agent module of the Remote Packet Capturing System, however instead of utilizing the WinPcap/Jpcap libraries which was designed for Windows/Linux a library written in assembly is used to capture and send the Ethernet packets. During the design phase of the TINI Ethernet driver it was uncertain as to whether such an implementation was possible on the TINI due to memory and processing limitations. These limitations were discovered during the development phase and are noted next. Figure 5: Proposed architecture of RNMS IV. THE TINI ETHERNET DRIVER The design of the TINI Ethernet driver is based on the Application note DS80C400 Ethernet drivers, which were provided by Dallas Semiconductors [11] which provides design considerations f
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks