Development Implementation - paulmac57/Network_Analyzer GitHub Wiki

The methodology details the various tools and equipment that will be employed. To have a comfortable working environment the use of a Windows computer to develop and test the software will be used. Milestone iterations will be downloaded to the Raspberry PI and further tests carried out. As proposed in the methodology, IDLE will be the development environment and Python will be programming language employed. Programming started before the equipment arrived beginning with the development of a simple GUI frontend interface and a backend program ensuring the ability to communicate with Cisco switches and routers. (see Figure 15/16)

Serial Port Configuration

Figure 15 Setting the Serial Interface Parameters.

Figure 16 Testing Communications with Cisco Devices using a simple dumb terminal Emulator. The initial test was to ensure the device could login to a network device and receive replies and this was the first iteration of the software as shown in Appendix F: Test Log iteration 1 test 1. In order for serial communications to work on the Raspberry PI it was found that the device name needed to be changed from COM3 to /dev/ttyUSB0 (See Appendix F: Test Log iteration 1 Test 2). However, this can be easily changed in the serial.ini file or in the Serial Config GUI. (see Figure 17). Once the device name was changed the connection was established.

Figure 17

The video at https://youtu.be/XKVd5638T_8 provides an informative instruction on the build of the device.

Figure 18 With the device built, further development of the interface saw it gradually taking shape. The interface development took by far the longest time. The interface was based on something akin to a chess board where Routers and switches could be moved around the board rather than Pawns and Bishops.

Figure 19

The Interface design went through various iterations. When the application was trialled on the Raspberry PI it was found that the icons were too small for use with fingers when tested and were therefore increased in size as shown below.

Figure 20   The main interface was firstly designed as a Top-level window with no windows manager to ensure it could not be resized or moved, however when the application was transferred to the device it was found that all other windows opened underneath this window and were therefore useless as they could not be seen. Yet on the windows PC they opened above the top-level window. No way around this problem could be found so in the end I had to make the window movable and resizable.

Figure 21

On the Raspberry PI, contrary to the windows computer, the Main Application Window always opened above child windows which made the child windows useless.

  The device login window gradually displayed more information and as a result became larger.

Figure 22 Once the IP address was configured Telnet became the communication method of choice; Serial Coms can be selected for initial configuration of the Cisco Router/Switch; SSH will be left for future development. This required the development of an “establish_connection” method using the Python Telnet libraries to check for login and password replies and send the relevant information.

Figure 23 The “Show Version” command was the first command needed to be implemented in order to bring back much of the Cisco device information. Obviously initial commands must be sent to the device before the “Show version” command can be sent, these are: - • login with a username • send a password, if required • send the “enable” command • send an “enable” password, if required. The test failed initially but this was due to an incorrect password being entered after being corrected the test worked without a problem and the connection was now ready to accept commands. (See Appendix F: Test Log iteration 2 Test 1) Initially the “Show Version” command failed and only returned half of the information, this was due to the device providing a More> pagebreak. In order to ensure all text was returned the “terminal length 0” command had to be sent to ensure the text wasn’t stopped at the end of a page with the MORE> enquiry. . (See Appendix F: Test Log iteration 3 Test 1) With the remote connection now open various commands can now be sent. The following listing shows the methods written to send various commands to the devices. Figure 24 At this point the “Show version” command is sent and the following information is returned:- Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-I-M), Version 12.3(5), RELEASE SOFTWARE (fc1) Copyright (c) 1986-2003 by cisco Systems, Inc. Compiled Tue 28-Oct-03 05:07 by kellythw Image text-base: 0x80008098, data-base: 0x80CA4288

ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)

Preston uptime is 23 minutes System returned to ROM by power-on System image file is "flash:c2600-i-mz.123-5.bin"

cisco 2610 (MPC860) processor (revision 0x203) with 45056K/4096K bytes of memory. Processor board ID JAD05060SLY (1836265265) M860 processor: part number 0, mask 49 Bridging software. X.25 software, Version 3.0.0. 1 Ethernet/IEEE 802.3 interface(s) 1 Serial network interface(s) 32K bytes of non-volatile configuration memory. 16384K bytes of processor board System flash (Read/Write)

Configuration register is 0x2102

This text is put through a Show_Version_Parser module where the relevant parts are placed into variables and then these variables are displayed on screen as shown below. (also see Appendix F: Test Log iteration 5 Test 1/2/3)

Figure 25

This effectively proves the ability of the device to be able to read and display information from Routers and switches. The next task is to prove the ability to make changes to the device settings. The “hostname” command was chosen to provide this proof and a method was therefore written as shown below.

Figure 26 Before the hostname command can be sent the “ENABLE” command and the “CONFIGURE TERMINAL” commands must be sent and the method was written to take account of this.   A new Configure window was created where the old hostname is displayed and a new hostname can be entered as shown below. The ability to change hostnames or any other paramaeter for that matter was successful as can be seen at Appendix F: Test Log iteration 7 Test 1)

Figure 27 Eventually from this screen many other parameters can be changed as can be seen from the various additional buttons on display. Each new command simply needs a new method creating in the telnet_connection module. If new commands must be parsed before displaying such as a command to show all interfaces on a device it is a simple matter of creating a parser module for that command. The “Show CDP Neigbors” command button has been created and tested (See Appendix F: Test Log iteration 8 Test 1/2) and eventually it is hoped that by putting the text reply through a parser an entire network infrastructure will be displayed.

Figure 28 The “CDP Neighbors” button currently returns the following text:- gp1= Blackpool gp2= Ser gp3= 0/0

show cdp entry Blackpool -------------------------Device ID: BlackpoolEntry address(es): IP address: 192.168.20. 2Platform: cisco 2610, Capabilities : Router Interface: Serial0/0, Port ID (outgoing port): Serial0/0Holdtime : 164 sec Version :Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-I-M), Version 12.3(5), RELEASE SOFTWARE (fc1)Copyright (c) 1986-2003 by cisco Systems, Inc.Compiled Tue 28-Oct-03 05:07 by kellythwadvertisement version: 2Preston >

gp1= unknown gp2= Eth gp3= 0/0

show cdp entry unknown -------------------------Device ID: unknownEntry address(es): IP address: 192.168.0. 153Platform: cisco WS-C2950-24, Capabilities : Switch IGMP Interface: Ethernet0/0, Port ID (outgoing port): FastEthernet0/1Holdtime : 145 sec Version :Cisco Internetwork Operating System Software IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(14)EA1a, RELEASE SOFTWARE (fc1)Copyright (c) 1986-2003 by cisco Systems, Inc.Compiled Tue 02-Sep-03 03:33 by antoninoadvertisement version: 2 Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF010231FF000000000000000ED742FA00FF0000 VTP Management Domain: 'Marton' Duplex: half

  To display the CDP information The Main Comms module first calls the Show CDP neighbors method within the Telnet_connection module and this sends the command to the local device. The returned text is then written to a text file. This file is then read and parsed using the show CDP neighbours parser and information such as hostname, port type and interface number are placed into variables ready to be displayed on screen.

Figure 29

  Proof of this working can be seen in the output below and also in the test logs. (See Appendix F: Test Log iteration 8 Test 1/2). As can be seen the variables gp1, gp2, gp3 have each been assigned the hostname, port type and port number. Additionally, the command has found that on the Preston Serial 0/0 port a remote host is connected named Blackpool and a switch has been found connected to Ethernet 0/0. These devices could be displayed as objects on the screen and furthermore could then be investigated by utilising the “Show CDP neighbours Detail” command (See Appendix F: Test Log iteration 9 Test 1). to see what is connected to their ports. From this an entire picture of the infrastructure could be drawn.

Figure 30