Design & Prototype Log

Engineering Scratchpad.

This website helps track the evolution of features, bugs, and decisions. It keeps a clear trace of historical changes, captures real feedback from testing, and creates informal reports for deeper insight. 

Subject: Initial concept.

Version: 0.0.0 / 0.0.1  (First Draft)

Date: 12/07/2025

Goal: Create a database using the most convenient technology to manage inventory of network devices. 

Integrate the database with the application to ensure that network devices are tracked and that information about the network inventory can be stored.

Method: I selected the SQLite database scheme as the most effective technology for the application. SQLite databases are based on the SQL syntax. 

Result: SQLite database works were tested as a single file on a disc without a required server database connection. No setup or administration settings were required. Database was tested on Windows and Linux systems. It is expected that the file will be relatively small, under 1MB during production time. 

Decision/Status: Create a schema of the database based on SQLite, a lightweight, serverless, self-contained database engine. The decision was made to use SQLite technology due to its fast integration with PyQT5, simplicity, and lack of necessity for deploying the server database process.

Future Work (Inventory Module):

There is a planned small expansion of the inventory module, but the core feature of the application is mapping network devices. Planned potential expansion of an inventory module:

•  add/edit users (a user/administrator can add new users to the database)

•  add device manually (user/administrator can add device manually without needed direct or remote connection to the device)

• basic statistics (devices information in statistical format: descriptive statistics, to be added to Inventory module in the future)

Figure 1 shows the Inventory Tab with a pre-built table of devices placed in the main window of the application. The table is connected to the SQL database, parsing the device information. The information from the inventory database is parsed automatically every time the application is opened by a user. Therefore the table is up to date after the user opens the application. Also, the table is refreshed after any changes to the database made by the user or during the application process.

The user is able to simply edit each device, changing information like the operating system, location, asset number, planned maintenance date, and more. The user can select a device for the edition using its unique ID number. In the example shown, the device with ID number 1 was selected for an edition. 

User can save any changes by clicking on the "Save" button. An application automatically updates information to an SQL database file. After saving, a pop-up window is enabled to confirm the changes made. 

Above has been attached a GIF snapshot showing the inventory module with the edit function. User is able to edit the inventory device and update information inside the database. This module will be expanded with new features like adding users, adding devices, adding statistics to existing devices and more. 

Subject: First draft with trial connection in lab environment.

Version:  0.0.2

Date: 12/07/2025

Goal: Establish connection with network device (router / switch). Map basic information and save to database file. Utilise the Netmiko library to handle and connect with physical devices.

Method: Test the Netmiko library using basic commands, such as "netmiko.send_command('show version')" for the Cisco router. Create a show_run_config_output.py file to parse information from the connected device. 

Result: The run_config_output.py file was created with functions to withdraw data using the Cisco router/switch command (show version) to obtain more detailed device information. 

Decision/Status: Developing and standardising the router switch to pursue information. 

Future Work (Connection Module): 

Modular architecture:

Application will be restructured into modular classes under the NetSafe Auditor framework. Each module will represent a specific audit function type, for example, PortScanner, ACLCompliance, ProtocolCheck, QoSMonitor, etc.

SSH as a standard protocol in a production environment:

The Telnet protocol has been used only for the purpose of quick connection during tests in the lab. In future work SSH protocol is considered as the standard connection between and among network devices. 

  Distinguished switch and router connection:

In experiments, identifying a device by its fundamental features has shown advantages. For example, a router with the command "Show version" gives a slightly different outcome compared to the switch. Classifying devices for switch, router, and firewall brings practical benefits with code reusability and maintainability. Additionally, logical separation makes code easier to understand and work with in the future. 

Potential modules in the future build:

Potential modular development plan will be presented in the separated chapter.

Action log:

Remote connection to the router was established from the laptop on the local network 192.168.1.1/24. Connection was successfully obtained, and packets were translated with an average speed of 4.0 ms. 

Next, remote access to the router was successfully obtained from the same laptop. Admin was able to log in to confirm that the telnet protocol correctly works on both devices, the router and the laptop, prior to the first connection from the application.

Unsecure telnet protocol has been used only for the test purpose in the lab environment! 

Interfaces were checked to ensure that the port, which was connected to the local network, worked to the required standard. 

Below is a screenshot from the user interface during the first connection to the router. The user is required to enter details about the device before connecting: an IP address, a telnet password, and an enable password if available. 

In the centre of the window, there was a design panel called "Connection Status." This part of the interface shows the current status for the selected modules (interface, configuration file, vlan, stp ). 

At this time, when the application was tested during the first run, only two modules were available: device information and interfaces, which showed a green colour after successful mapping. The next modules will be introduced successfully during the project time. 

All focus during the first test was on collecting basic information from the router, as shown in the tab called "Information."Snapshot in figure 9 shows how data was populated after the user connected to the router.

This GIF demonstrates how the program implements the feature for capturing device configuration snapshots within the main loop. The snippet highlights how NetAuditor establishes a connection to a Cisco IOS device using Netmiko, executes the show command, and then captures the raw configuration output.

The purpose of this demonstration is to visualise the core logic path and provide a quick reference for how device sessions were handled in early builds. This experiment informed later decisions about creating a dedicated parser module, rather than embedding JSON conversion logic directly inside main.py.

Subject: Device interfaces in PyQt5 tabular form.

Version: 0.0.3

Date: 12/07/2025

Goal: Enhance clarity and readability of output of data from device interfaces by implementing a user-friendly table view. The user-friendly table view will allow for easier interpretation and analysis of the data.

Method: Use the PyQt5 Table View object to present withdrawn data from the device by netmiko module.

Result: The NetSafeAuditor application offers several clear and valuable benefits to users, especially network engineers and IT professionals who work with Cisco devices. Below is a breakdown of the key advantages. The CLI can be dense and hard to scan quickly. The PyQt5 table view organises data into structured rows and columns, making it easier to identify key parameters like bandwidth, input/output errors, duplex mode, etc. Therefore, users can quickly scan the table to find what they need instead of scrolling through long CLI outputs. This feature will be especially helpful when monitoring multiple interfaces and comparing values across them. 

The most value comes from the ability to have all data in one click instead of manually logging into each device and running a standalone command for each interface. Users can quickly scan all tables, which makes for faster data interpretation.

Decision/Status: Interfaces TAB will be extended to present device information in tabular form. This enhancement will greatly improve efficiency and streamline data analysis processes. Further work will be performed to integrate with multi-device connections for more comprehensive data analysis.

Future Work (Connection Module): An export data feature will be added to the table view, enabling users to generate reports or share findings with teams. This will streamline the process and improve the efficiency of work for the network engineer/administrator. 

User interaction with the program is depicted in the snapshot below (figure 11). By using its ID number, the user can establish a connection with the router. Some basic details about the interfaces are included in the quick reference to the interface table, and the device connection status tab is updated. To view interface status data, the user then selects the Interfaces tab. To update details about the chosen interface, the user can choose it by selecting a port number from the combo list.

Additional modification was applied to the window size of the program. As seen in figures 11 and 12, a program window size has been reduced to optimise space on the user's screen. After a few trials and interactive tests, it has been observed that the data-driven table form of design of the application is more efficient, giving the user a better experience. 

This explains why a user might prefer to work with the app while keeping a few windows open, including the CLI interpreter.

In the right-down corner of the main window (figure 13), simple interface information in table form has been added during project development. The main benefit from these modifications is to give the user quick access to the diagnostics of connections. It allows users quick reference to which interface is active, inactive or misconfigured. 

In figure 14, the equivalent brief information of interfaces was presented in the CLI terminal after entering the "show ip int brief" command line. With the potential for quicker data interpretation, it demonstrates that the same information displayed in the table (figure 13) is easier to read. 

Almost the same data are shown in both figures, 15 and 16. The table view (figure 15) reveals data in a structured format with columns and rows, making it easier to recognise the key parameters.