DOCSLIB.ORG

Design of an Ethernet Monitor and Protocol Analyzer Gwenna S

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design of an Ethernet Monitor and Protocol Analyzer Gwenna S Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1990 Design of an Ethernet monitor and protocol analyzer Gwenna S. Jacobson Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Hardware Systems Commons Recommended Citation Jacobson, Gwenna S., "Design of an Ethernet monitor and protocol analyzer" (1990). Retrospective Theses and Dissertations. 16878. https://lib.dr.iastate.edu/rtd/16878 This Thesis is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Design of an Ethernet monitor and protocol analyzer by Gwenna S. Jacobson A Thesis Submitted to the Graduate Faculty in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE Department: Electrical Engineering and Computer Engineering Major: Computer Engineering Signatures have been redacted for privacy Iowa State University Ames, Iowa 1990 11 TABLE OF CONTENTS ACKNOWLEDGEMENTS VIll 1. INTRODUCTION ... 1 2. MONITORING TECHNIQUES 3 2.1 C en t ralized ~Ioni tor 3 2.1.1 Probe Monitor 3 2.1.2 Spy Monitor. 3 2.2 Distributed Monitor 4 2.3 Hybrid l\Ionitor ... 4 3. NETWORK PROTOCOLS .5 3.1 OSlo 5 3.1.1 Physical Layer. 6 3.1.2 Data Link Layer 6 3.1.3 Network Layer 8 3.1.4 Transport Layer. 11 3.1.5 Session Layer . 13 3.1.6 Presentation Layer 1.5 3.1.7 Application Layer. 17 3.2 TCP/IP ......... 18 III 3.2.1 IP 20 3.2.2 TCP 21 3.2.3 FOP 23 :3.2.-! IC\IP 24 ·V 3.2 ..5 ARp!RARP. ~.) .)- 3.2.6 RIP _I 3.2.7 Telnet 28 3.2.8 FTP 28 3.2.9 S~ITP 28 3.3 Ethernet 29 4. NETWORK MONITOR DESIGN 37 4.1 Hardware 37 4.2 Software 37 4.2.1 F ser Interface 38 4.2.2 Filters 39 4.2.3 Data Capture 39 4.2.4 Data Display Windows 39 4.2 ..5 File I/O 44 4.2.6 Statistics. 44 4.2.7 Driver Software 44 5. CONCLUSIONS 47 6. BIBLIOGRAPHY 49 IV 7. APPENDIX A: ACRONYMS . .. .')1 8. APPENDIX B: SOURCE CODE. .')3 v LIST OF FIGURES Figure 3.1: OSI Layers. .. ... 7 Figure 3.2: ISO IP packet data unit formats 9 Figure 3.3: ISO transport protocol fixed header formats 12 Figure 3.4: ISO session protocol data unit 14 Figure 3.5: ISO presentation protocol data unit 16 Figure 3.6: Comparison of DPA protocols to OSI layers. 19 Figure 3.7: Internet protocol format 20 Figure .3.8: TCP protocol data unit . 22 Figure 3.9: UDP protocol data unit. 23 Figure 3.10: ICMP protocol data unit 25 Figure 3.11: ARP jRARP protocol data unit 26 Figure 3.12: RIP protocol data unit 27 Figure 3.13: Ethernet frame .... 29 Figure 4.1: Block diagram of the User Interface 38 Figure 4.2: Filtering Setup Menus. 40 Figure 4.3: Data Capture Screen 41 Figure 4.4: Data Display Windows 42 Figure 4.5: Summary Display \Vindow 43 VI Figure 4.6: Detail Display Window . 43 Figure 4.7: Hexadecimal Display \Vindow 44 Figure 4.8: Store/Restore Menu ..... 4.5 Vll LIST OF TABLES Table 3.1: Ethernet Address Assignments for Vendors 31 Table 3.2: Ethernet Type Field Assignments . 34 Table 7.1: Acronyms ............ .52 VIll ACKNOWLEDGEMENTS I would like to thank Professor Terry Smay, my major professor, for his help on the project and helping me meet the deadlines. I would also like to thank Professor Dick Horton and Professor Dale Grosvenor for serving on my committee. I want to thank Lynn Christiansen who worked with me on this project. She encouraged me when I needed encouragement and worked with me although my schedule was difficult to work around. I also need to thank Pam Myers, the graduate secretary, because I am sure without her constant reminders of deadlines I would have missed a few of them. I am grateful to my parents for never imposing limitations on me and always encouraging me to test my abilities. I especially want to thank my husband, Doug, for knowing this was something I wanted to finish and helping me to do it. He answered my many questions on various aspects of this project: He also spent many evenings taking care of things at home, enabling me to complete my degree. 1 1. INTRODUCTION As local area networks have proliferated over the last decade, it is necessary to be able to monitor and analyze activity on these networks. This is even more necessary when LANs are internetworked together and all the computer systems on the network are not under one person's control or even one department's control. A network monitor and protocol analyzer allows you to capt ure, decode, exam­ ine and analyze frames on the network and to isolate and identify problems on the network. A protocol analyzer would be a valuable tool in computer networking classes. Students could use the protocol analyzer to see the packets decoded. Several network protocol analyzers are commercially available, however they are expensive. An ad­ vantage of a protocol analyzer that is especially developed for the classroom instead of the commercial marketplace is that it would allow students to examine source code and write code modules for other protocols, thus giving them experience in network programrrung. The network monitor and protocol analyzer discussed in this thesis was developed for the Ethernet protocol. The hardware used was an off-the-shelf 386 personal computer installed with a 3eom Ethernet board [1]. The Ethernet board used was a 3C505 intelligent Ethernet adapter board and came with driver software. The 2 board has an 80188 microprocessor, 512 Kbytes of memory and a DMA interface. It captures, decodes and analyzes Ethernet protocols, TCP lIP protocols and OSI protocols. The user interface was standardized to that of an FDDI monitor currently be­ ing developed by Lynn Christiansen. It was developed with a windowing library of routines called C \Vindows Toolkit [2]. 3 2. MONITORING TECHNIQUES There are three commonly used monitoring techniques. They are centralized, distributed, and hybrid [3] [4]. 2.1 Centralized Monitor A centralized monitor is a monitor in which a dedicated station on the net­ work collects and analyzes data on that station. There are two types of centralized monitoring techniques. They are the probe monitor and the spy monitor. 2.1.1 Probe Monitor The probe monitor injects packets onto the network and can be used to analyze how the network will perform under varying loads. 2.1.2 Spy Monitor The spy monitor is a special node dedicated to monitoring the network passively. It listens to already existing traffic on the network and does not introduce any ar­ tificial traffic onto the network. The monitor designed in this research was a spy monitor. 4 2.2 Distributed Monitor A distributed monitor is a monitor where each station collects and analyzes data and then sends this information to a central location for further analysis. 2.3 Hybrid Monitor A hybrid monitor is a monitor where data are collected and analyzed at both a central location and distributed locations. .5 3. NETWORK PROTOCOLS A network protocol is a set of rules that govern the exchange of data between two communicating entities. There are two major protocol standards for the higher protocol layers, the OSI reference model and TCP /IP. At the two lower protocol layers the standards for local area networks (LANs) are the IEEE 802 series of standards. There are three major types of LANs defined in IEEE 802, CSMA/CD bus, token ring and token bus. CSMA/CD is also known as Ethernet and is the type of LAN used in this research. The OSI reference model, Tep /IP and Ethernet are discussed in further detail in the following sections. The part of the protocol that is examined by the network monitor is the actual protocol data units (PDUs) associated with each layer. 3.1 OSI In 19ii the International Organization for Standardization (ISO) established a subcommittee to define a communications architecture. The result was the Open Systems Interconnection (051) reference model adopted in 1983. The OSI reference model uses the structuring technique of layering, where each layer in the network performs a certain subset of functions and passes the information on to the next lower layer where the next layer performs more primitive functions and conceals the 6 details of those functions [,5] [6] [i]. Each layer also provides serVIces to the next higher layer [8]. The OSI model has seven layers listed below and shown in Figure 3.1. • the physical layer • the data link layer • the network layer • the transport layer • the session layer • the presentation layer • the application layer. 3.1.1 Physical Layer The Physical Layer is concerned with the transmission of data over the physical medium. It deals with the mechanical, electrical, functional and procedural char­ acteristics to access the physical medium. The physical layer protocol used in this proje,ct is Ethernet and will be discussed in another section. 3.1.2 Data Link Layer The data link layer provides for the reliable transfer of information across the physical link. It sends blocks of data (frames or packets) with the necessary synchro­ nization, error control, and flow control.
Load more

Recommended publications
  • Getting Started Computing at the Al Lab by Christopher C. Stacy Abstract
    MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICIAL INTELLI..IGENCE LABORATORY WORKING PAPER 235 7 September 1982 Getting Started Computing at the Al Lab by Christopher C. Stacy Abstract This document describes the computing facilities at the M.I.T. Artificial Intelligence Laboratory, and explains how to get started using them. It is intended as an orientation document for newcomers to the lab, and will be updated by the author from time to time. A.I. Laboratory Working Papers are produced for internal circulation. and may contain information that is, for example, too preliminary or too detailed for formal publication. It is not intended that they should be considered papers to which reference can be made in the literature. a MASACHUSETS INSTITUTE OF TECHNOLOGY 1982 Getting Started Table of Contents Page i Table of Contents 1. Introduction 1 1.1. Lisp Machines 2 1.2. Timesharing 3 1.3. Other Computers 3 1.3.1. Field Engineering 3 1.3.2. Vision and Robotics 3 1.3.3. Music 4 1,3.4. Altos 4 1.4. Output Peripherals 4 1.5. Other Machines 5 1.6. Terminals 5 2. Networks 7 2.1. The ARPAnet 7 2.2. The Chaosnet 7 2.3. Services 8 2.3.1. TELNET/SUPDUP 8 2.3.2. FTP 8 2.4. Mail 9 2.4.1. Processing Mail 9 2.4.2. Ettiquette 9 2.5. Mailing Lists 10 2.5.1. BBoards 11 2.6. Finger/Inquire 11 2.7. TIPs and TACs 12 2.7.1. ARPAnet TAC 12 2.7.2. Chaosnet TIP 13 3.
    [Show full text]
  • Edition with Romkey, April 16, 1986 (PDF)
    PC/IP User's Guide MASSACHUSETTS INSTITUTE OF TECHNOLOGY Laboratory For Computer Science Network programs based on the DoD Internet Protocol for the mM Personal Computer PC/~ release or March, 1986; document updated Aprill4, 1986 by: Jerome H. Saltzer John L. Romkey .• Copyright 1984, 1985, 1986 by the Massachusetts Institute or Technology Permission to use, copy, modlt'y, and distribute these programs and their documentation ror any purpose and without ree ls hereby granted, provided that this copyright and permission notice appear on all copies and supporting documentation, the name or M.I.T. not be used in advertising or publlclty pertalnlng to dlstrlbutlon or the programs without written prior permission, and notice be glven in supporting documentation that copying and distribution ls by permlsslon or M.I.T. M.I.T. makes no representations about the suitablllty or this software for any purpose. It is provided "as ls" without express or Implied warranty. - ii - CREDITS The PC/IP packages are bullt on the work of many people in the TCP/IP community, both at M.I.T. and elsewhere. Following are some of the people who directly helped in the creation of the packages. Network environment-John L. Romkey Terminal emulator and customizer-David A. Bridgham Inltlal TFTP-Kari D. Wright Inltlal telnet-Louls J. Konopelskl Teinet model-David D. Clark Tasking package-Larry W. Allen Development system-Christopher J. Terman Development environment-Wayne C. Gramlich Administrative Assistant-Muriel Webber October 3, 1985. This document is in cover .mss - iii- - iv Table of Contents 1. Overview of PC/IP network programs 1 1.1.
    [Show full text]
  • Latest Result of DNSSEC Validation
    BIND 9 Administrator Reference Manual Internet Systems Consortium Sep 23, 2021 CONTENTS 1 Introduction 1 1.1 Scope of Document ............................................ 1 1.2 Organization of This Document ..................................... 1 1.3 Conventions Used in This Document ................................... 1 1.4 The Domain Name System (DNS) .................................... 2 2 BIND Resource Requirements 7 2.1 Hardware Requirements ......................................... 7 2.2 CPU Requirements ............................................ 7 2.3 Memory Requirements .......................................... 7 2.4 Name Server-Intensive Environment Issues ............................... 7 2.5 Supported Operating Systems ...................................... 8 3 Name Server Configuration 9 3.1 Sample Configurations .......................................... 9 3.2 Load Balancing .............................................. 10 3.3 Name Server Operations ......................................... 11 3.4 Plugins .................................................. 13 4 BIND 9 Configuration Reference 15 4.1 Configuration File Elements ....................................... 15 4.2 Configuration File Grammar ....................................... 18 4.3 Zone File ................................................. 105 4.4 BIND 9 Statistics ............................................. 110 5 Advanced DNS Features 117 5.1 Notify ................................................... 117 5.2 Dynamic Update ............................................
    [Show full text]
  • M0 -N6z L-Ol Fui
    COMPUTER NETWORKING Af STANFORD Dept.oi Spe ; - ,|| '"i YMO Title . suries m0 -n6Z l-ol Fui. Tit 3 :;3i "\\ Computer Networking at Stanford Current Status and Future Plans for Ethernet at Stanford University Ralph E. Gorin Computer ScienceDepartment Stanford University January 1981 In the near future all major computing resources on the Stanford campus will be connected by the Xerox Corporation's Ethernet communications network. This network will provide an unprecedented level of system integration of immense value to the growing community of computer users. Many new uses of computer systems, hitherto thought too inconvenient or too expensive, will become practicable. Our current efforts are aimed at connecting existing systems to Ethernet; these systems include various configurations from several vendors, among which arc Xerox Corporation Alto personal computers, a file server and a printing server; IBM 3033 and Series 1; Digital Equipment Corporation PDP-11, VAX-11/780, and DECsystcms-10 and -20; and systems from Hewlett Packard, Data General, and other vendors. In addition to die progress being made connecting existing systems, we are designing Ethernet-based stations to support clusters of graphical or conventional terminals. These terminal systems will allow users to communicate with any host computer on the Stanford University Network (SUN). Portions of this document, particularly sections 3 and 4.3, are based on an unpublished proposal, The SUN Workstation, [Baskett, Bechtolsheim]. * 2 1. Introduction The future of computing at Stanford will be characterized by growth in demand for the services presendy offered, and growing demand for services from personal-sized systems. Neither large mainframes nor personal computers will dominate the environment; rather, both will flourish.
    [Show full text]
  • BIND 9 Administrator Reference Manual
    BIND 9 Administrator Reference Manual BIND 9 Administrator Reference Manual Copyright © 2000, 2001 by Internet Software Consortium Table of Contents 1. Introduction............................................................................................................................................9 1.1. Scope of Document.....................................................................................................................9 1.2. Organization of This Document..................................................................................................9 1.3. Conventions Used in This Document..........................................................................................9 1.4. The Domain Name System (DNS)............................................................................................10 1.4.1. DNS Fundamentals.......................................................................................................10 1.4.2. Domains and Domain Names.......................................................................................10 1.4.3. Zones ............................................................................................................................11 1.4.4. Authoritative Name Servers .........................................................................................11 1.4.4.1. The Primary Master .........................................................................................12 1.4.4.2. Slave Servers....................................................................................................12
    [Show full text]
  • An Introduction to Computer Networks (Week 4) Stanford Univ CS144 Fall 2012
    An Introduction to Computer Networks (week 4) Stanford Univ CS144 Fall 2012 PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Thu, 11 Oct 2012 19:28:39 UTC Contents Articles Names and addresses 1 Address Resolution Protocol 1 Dynamic Host Configuration Protocol 6 Domain Name System 18 IPv4 31 IPv6 41 Network address translation 54 Ebooks Dedicated to Richard Beckett 64 References Article Sources and Contributors 65 Image Sources, Licenses and Contributors 67 Article Licenses License 68 1 Names and addresses Address Resolution Protocol Address Resolution Protocol (ARP) is a telecommunications protocol used for resolution of network layer addresses into link layer addresses, a critical function in multiple-access networks. ARP was defined by RFC 826 in 1982.[1] It is Internet Standard STD 37. It is also the name of the program for manipulating these addresses in most operating systems. ARP has been implemented in many combinations of network and overlaying internetwork technologies, such as IPv4, Chaosnet, DECnet and Xerox PARC Universal Packet (PUP) using IEEE 802 standards, FDDI, X.25, Frame Relay and Asynchronous Transfer Mode (ATM), IPv4 over IEEE 802.3 and IEEE 802.11 being the most common cases. In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the Neighbor Discovery Protocol (NDP). Operating scope The Address Resolution Protocol is a request and reply protocol that runs encapsulated by the line protocol. It is communicated within the boundaries of a single network, never routed across internetwork nodes. This property places ARP into the Link Layer of the Internet Protocol Suite, while in the Open Systems Interconnection (OSI) model, it is often described as residing between Layers 2 and 3, being encapsulated by Layer 2 protocols.
    [Show full text]
  • Network Working Group D
    Network Working Group Jeffrey Mogul Request for Comments: 919 Computer Science Department Stanford University October 1984 BROADCASTING INTERNET DATAGRAMS Status of this Memo We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Acknowledgement This proposal is the result of discussion with several other people, especially J. Noel Chiappa and Christopher A. Kent, both of whom both pointed me at important references. 1. Introduction The use of broadcasts, especially on high-speed local area networks, is a good base for many applications. Since broadcasting is not covered in the basic IP specification [13], there is no agreed-upon way to do it, and so protocol designers have not made use of it. (The issue has been touched upon before, e.g. [6], but has not been the subject of a standard.) We consider here only the case of unreliable, unsequenced, possibly duplicated datagram broadcasts (for a discussion of TCP broadcasting, see [11].) Even though unreliable and limited in length, datagram broadcasts are quite useful [1]. We assume that the data link layer of the local network supports efficient broadcasting. Most common local area networks do support broadcast; for example, Ethernet [7, 5], ChaosNet [10], token ring networks [2], etc. We do not assume, however, that broadcasts are reliably delivered. (One might consider providing a reliable broadcast protocol as a layer above IP.) It is quite expensive to guarantee delivery of broadcasts; instead, what we assume is that a host will receive most of the broadcasts that are sent.
    [Show full text]
  • Address Resolution Protocol 1 Address Resolution Protocol
    Address Resolution Protocol 1 Address Resolution Protocol Address Resolution Protocol (ARP) is a telecommunications protocol used for resolution of network layer addresses into link layer addresses, a critical function in multiple-access networks. ARP was defined by RFC 826 in 1982.[1] It is Internet Standard STD 37. It is also the name of the program for manipulating these addresses in most operating systems. ARP has been implemented in many combinations of network and overlaying internetwork technologies, such as IPv4, Chaosnet, DECnet and Xerox PARC Universal Packet (PUP) using IEEE 802 standards, FDDI, X.25, Frame Relay and Asynchronous Transfer Mode (ATM), IPv4 over IEEE 802.3 and IEEE 802.11 being the most common cases. In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the Neighbor Discovery Protocol (NDP). Operating scope The Address Resolution Protocol is a request and reply protocol that runs encapsulated by the line protocol. It is communicated within the boundaries of a single network, never routed across internetwork nodes. This property places ARP into the Link Layer of the Internet Protocol Suite, while in the Open Systems Interconnect (OSI) model, it is often described as residing between Layers 2 and 3, being encapsulated by Layer 2 protocols. However, ARP was not developed in the OSI framework. Packet structure The Address Resolution Protocol uses a simple message format that contains one address resolution request or response. The size of the ARP message depends on the upper layer and lower layer address sizes, which are given by the type of networking protocol (usually IPv4) in use and the type of hardware or virtual link layer that the upper layer protocol is running on.
    [Show full text]
  • CABLEPORT Through CYCLESERV2
    CABLEPORT through CYCLESERV2 • CABLEPORT-AX, page 4 • CAB-PROTOCOL, page 5 • CADLOCK, page 6 • CAILIC, page 7 • CALL-OF-DUTY, page 8 • CAPWAP-CONTROL, page 9 • CAPWAP-DATA, page 10 • CBT, page 11 • CDC, page 12 • CDDBP-ALT, page 13 • CFDPTKT, page 14 • CFTP, page 16 • CHAOS, page 17 • CHARGEN, page 18 • CHECKPOINT-CPMI, page 19 • CHSHELL, page 20 • CIFS, page 21 • CIMPLEX, page 22 • CISCO-FNA, page 23 • CISCO-IP-CAMERA, page 24 • CISCO-JABBER-AUDIO, page 25 • CISCO-JABBER-CONTROL, page 26 • CISCO-JABBER-IM, page 27 • CISCO-JABBER-VIDEO, page 28 NBAR2 Protocol Pack 12.0.0 1 CABLEPORT through CYCLESERV2 • CISCO-NAC, page 29 • CISCO-PHONE, page 30 • CISCO-SYS, page 31 • CISCO-TDP, page 32 • CISCO-TNA, page 33 • CITRIX-STATIC, page 34 • CITRIX, page 36 • CLEARCASE, page 38 • CLOANTO-NET-1, page 39 • CMIP-AGENT, page 40 • CMIP-MAN, page 42 • COAUTHOR, page 44 • CODAAUTH2, page 45 • COLLABORATOR, page 46 • COMMERCE, page 47 • COMPAQ-PEER, page 48 • COMPRESSNET, page 49 • COMSCM, page 50 • CON, page 51 • CONFERENCE, page 52 • CONNENDP, page 53 • CONSUMER-CLOUD-STORAGE, page 54 • CONTENTSERVER, page 56 • COOLTALK, page 57 • CORBA-IIOP, page 58 • CORBA-IIOP-SSL, page 60 • CORERJD, page 61 • COURIER, page 62 • COVIA, page 63 • CPHB, page 64 • CPNX, page 65 • CPQ-WBEM, page 66 • CREATIVEPARTNR, page 67 NBAR2 Protocol Pack 12.0.0 2 CABLEPORT through CYCLESERV2 • CREATIVESERVER, page 68 • CRS, page 69 • CRTP, page 70 • CRUDP, page 71 • CRYPTOADMIN, page 72 • CSI-SGWP, page 73 • CSNET-NS, page 74 • CTF, page 75 • CUSEEME, page 76 • CUSTIX, page 77 •
    [Show full text]
  • Eth, Ip and TCP Packet Structure
    ETHERNET Structure - 6 bytes Destination Ethernet Address (All 1 if broadcast, …) - 6 bytes Source Ethernet Address - 2 bytes Length or Type Field - if IEEE 802.3 number of bytes <= 1500(05DC) - if ethernet I or II is the packet type > 1500(05DC) - 46 bytes until 1500 are data! Short packets filled until 46 bytes - 4 bytes (Frame Check sequence: directly evaluated and managed by the hardware. Not accessible via software.) 1 SAP CODES Null LSAP 0x00 Individual LLC Sublayer Management Function 0x02 Group LLC Sublayer Management Function 0x03 IBM SNA Path Control (individual) 0x04 IBM SNA Path Control (group) 0x05 ARPANET Internet Protocol (IP) 0x06 SNA 0x08 SNA 0x0C PROWAY (IEC955) Network Management & Initialization 0x0E Texas Instruments 0x18 IEEE 802.1 Bridge Spanning Tree Protocol 0x42 EIA RS-511 Manufacturing Message Service 0x4E ISO 8208 (X.25 over IEEE 802.2 Type 2 LLC) 0x7E Xerox Network Systems (XNS) 0x80 Nestar 0x86 PROWAY (IEC 955) Active Station List Maintenance 0x8E ARPANET Address Resolution Protocol (ARP) 0x98 Banyan VINES 0xBC SubNetwork Access Protocol (SNAP) 0xAA Novell NetWare 0xE0 IBM NetBIOS 0xF0 IBM LAN Management (individual) 0xF4 IBM LAN Management (group) 0xF5 IBM Remote Program Load (RPL) 0xF8 Ungermann-Bass 0xFA ISO Network Layer Protocol 0xFE Global LSAP 0xFF Ethernet types 0x0000 0x05DC IEEE 802.3 Length Fields 0x0600 0x0600 Xerox XNS IDP 0x0800 0x0800 DOD IP 0x0801 0x0801 X.75 Internet 0x0802 0x0802 NBS Internet 0x0803 0x0803 ECMA Internet 0x0804 0x0804 CHAOSnet 0x0805 0x0805 X.25 Level 3 0x0806 0x0806 ARP (for IP and CHAOS) 0x0807 0x0807 Xerox XNS Compatibility 0x081C 0x081C Symbolics Private 0x0888 0x088A Xyplex 0x0900 0x0900 Ungermann-Bass network debugger 0x0A00 0x0A00 Xerox 802.3 PUP 0x0A01 0x0A01 Xerox 802.3 PUP Address Translation 0x0A02 0x0A02 Xerox PUP CAL Protocol (unused) 0x0BAD 0x0BAD Banyan Systems, Inc.
    [Show full text]
  • ILINK SOHO Reference Manual
    IOLINK-SOHO Ethernet Bridge/Router Reference Manual Issue 2 All Software Versions © Copyright 1999 by Chase Research 6/99 Part # 168-28807 1 Introduction The IOLINK SOHO Ethernet Remote Bridge/Router The IOLINK SOHO Ethernet remote bridge/router provides IP and IPX routing combined with a protocol transparent bridge. This bridge/router combination is often the best solution to linking remotely located LANs where most of the traffic is IP or IPX with smaller amounts of traffic from other protocols such as NetBIOS or DEC LAT. The IOLINK SOHO Ethernet bridge/router supports the widely implemented Routing Information Protocol, otherwise known as RIP. RIP support allows the IOLINK SOHO Ethernet to interoperate with other vendors’ routers. The IOLINK SOHO Ethernet remote bridge/router will operate as delivered, providing increased LAN performance directly out of the box without the need for complex pre-configuration. However, in those situations where specific customization is required, an easy-to-use “hotkey” menuing Bridge/Router Manager console provides access to LAN and Link statistical information, and control of the network configuration. With increased LAN and Link management capability, you will be able to detect LAN and Link problems, determine utilization patterns, and plan for future expansion that will optimize your existing data-communication resources. The IOLINK SOHO Ethernet bridge/router can be thought of as a group of discrete functions combined in a single box. The first functional module is the LAN interface, which receives all LAN traffic and then decides where individual frames should be sent: to the IP router, to the IPX router, to the bridge, to the management system, or discarded altogether.
    [Show full text]
  • Characterizing Network Infrastructure Using the Domain Name System
    CHARACTERIZING NETWORK INFRASTRUCTURE USING THE DOMAIN NAME SYSTEM A Dissertation Presented to The Academic Faculty By Panagiotis Kintis In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the School of School of Computer Science Georgia Institute of Technology December 2020 Copyright c Panagiotis Kintis 2020 CHARACTERIZING NETWORK INFRASTRUCTURE USING THE DOMAIN NAME SYSTEM Approved by: Dr. Emmanouil Antonakakis School of Electrical and Computer Engineering Dr. Mustaque Ahamad Georgia Institute of Technology School of Computer Science Georgia Institute of Technology Dr. Douglas Blough School of Electrical and Computer Dr. Jonathan M. Smith Engineering Department of Computer and Infor- Georgia Institute of Technology mation Science University of Pennsylvania Dr. Angelos Keromytis School of Electrical and Computer Date Approved: October 1, 2020 Engineering Georgia Institute of Technology Reason is immortal, all else mortal. Pythagoras of Samos To my family and friends, for being there. ACKNOWLEDGEMENTS Several people have made the last few years very exciting and productive. I owe a great debt of gratitude to exceptional researchers and devoted friends, who have played a significant role in my personal and professional life, and helped me in many different ways to complete this thesis. I would like to thank my advisor, Manos Antonakakis, who has been there throughout this journey to guide and assist. He pushed me to achieve my full potential, helped me navigate the research world, and provided me with the intellectual capital to complete this thesis and become a better researcher. Several years ago, he gave me a chance, accepting me in the PhD program, and taught me everything I needed to succeed.
    [Show full text]