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 (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.1 / 002

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: Proposed future expansion.

Version: 0.0.3

Date: 12/07/2025

Goal: 

Method: 

Result: 

Decision/Status: 

Future Work (Connection Module): 

To be continued.