[{"content":" Configuration Guide # DiagNet is designed to work out-of-the-box with zero configuration for most users. However, you can customize its behavior using environment variables.\nThese variables can be set in your compose.yaml file or passed directly to the container.\nCore Configuration # Variable Description Default DIAGNET_DATA_PATH Recommended. The base directory for all persistent data (database, secrets). /data (in container) BASE_DIR (local dev) DIAGNET_ALLOWED_HOSTS Comma-separated list of hostnames/IPs that can access the application. localhost,127.0.0.1 DIAGNET_CSRF_TRUSTED_ORIGINS Comma-separated list of trusted origins for CSRF checks. Required when running behind a reverse proxy. (unset) DIAGNET_DEBUG Enables Django debug mode. Never set this to True in production. False Data \u0026amp; Storage # Variable Description Default DIAGNET_DB_PATH Full path to the SQLite database file. Useful if you want the DB in a different location than DIAGNET_DATA_PATH. $DIAGNET_DATA_PATH/db.sqlite3 DIAGNET_STATIC_ROOT Directory where static files (CSS/JS) are collected. Managed automatically by the container. /nix/store/.../static Security (Advanced) # These keys are automatically generated and persisted to DIAGNET_DATA_PATH/secrets.env on the first run. You typically do not need to set these manually unless you are rotating keys or integrating with an external secrets manager.\nVariable Description Requirement DIAGNET_SECRET_KEY The secret key used for cryptographic signing (session cookies, CSRF tokens). Random string DIAGNET_DEVICE_ENCRYPTION_KEY The key used to encrypt/decrypt sensitive device passwords in the database. 32-byte base64-encoded string Custom Test Templates # Variable Description Default DIAGNET_ENABLE_CUSTOM_TESTCASES Set to True to enable the dynamic loading of custom test cases. False DIAGNET_CUSTOM_TESTCASES_PATH The directory where the system scans for .py custom test files. $DIAGNET_DATA_PATH/testcases Example compose.yaml # services: diagnet: image: ghcr.io/diagnet/diagnet:latest restart: unless-stopped ports: - \u0026#34;8000:8000\u0026#34; volumes: - ./data:/data:Z environment: - DIAGNET_DATA_PATH=/data - DIAGNET_ALLOWED_HOSTS=diagnet.local,192.168.1.50 Behind a Reverse Proxy # When DiagNet runs behind a reverse proxy (e.g. nginx, Caddy, Traefik), the browser sends requests to the proxy\u0026rsquo;s origin, not directly to DiagNet. Django\u0026rsquo;s CSRF protection checks that the Origin/Referer header matches a trusted origin, so you must tell DiagNet what origin(s) to trust.\nSet DIAGNET_CSRF_TRUSTED_ORIGINS to a comma-separated list of the scheme + host (and optional port) that users access DiagNet through:\nenvironment: - DIAGNET_ALLOWED_HOSTS=diagnet.example.com - DIAGNET_CSRF_TRUSTED_ORIGINS=https://diagnet.example.com If your proxy exposes DiagNet on a non-standard port, include it:\nDIAGNET_CSRF_TRUSTED_ORIGINS=https://diagnet.example.com:8443 Without this setting, all form submissions and HTMX requests will be rejected with a 403 Forbidden (CSRF verification failed) error when accessed through the proxy.\n","date":"8 September 2025","externalUrl":null,"permalink":"/docs/configuration/","section":"Docs","summary":"","title":"Configuration","type":"docs"},{"content":" Frequently Asked Questions (FAQ) # SSH Configuration # How can I use custom or \u0026ldquo;insecure\u0026rdquo; SSH settings for older devices? # If you need to connect to older network devices that require legacy cryptographic algorithms (e.g., diffie-hellman-group1-sha1 or ssh-rsa), you can provide a custom SSH configuration file to the DiagNet container.\nCreate a file named ssh_config on your host system with the necessary settings:\nHost * # Example: Enable legacy algorithms KexAlgorithms +diffie-hellman-group1-sha1 HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa # Disable strict host key checking if needed StrictHostKeyChecking no UserKnownHostsFile /dev/null Mount this file into the container in your docker-compose.yml:\nservices: diagnet: # ... volumes: - ./data:/data:Z - ./ssh_config:/etc/ssh/ssh_config Networking # How can I allow DiagNet to access services on the host\u0026rsquo;s localhost? # By default, containers are isolated from the host\u0026rsquo;s network. If you want DiagNet to be able to reach services running directly on your host\u0026rsquo;s localhost (127.0.0.1), the easiest way is to use \u0026ldquo;host networking\u0026rdquo;.\nUpdate your docker-compose.yml to include network_mode: host:\nservices: diagnet: # ... network_mode: host # Note: When using host mode, port mapping (ports:) is ignored # as the container binds directly to the host\u0026#39;s ports. When using network_mode: host, localhost or 127.0.0.1 inside DiagNet will refer directly to the host machine.\n","date":"8 September 2025","externalUrl":null,"permalink":"/docs/faq/","section":"Docs","summary":"","title":"FAQ","type":"docs"},{"content":" Get started About # DiagNet is a web-based network testing and validation platform built as a diploma project at HTL Rennweg in partnership with CANCOM Austria AG.\nInstead of running tests manually through a terminal, DiagNet gives teams a single web interface to manage devices, define tests, execute them in batches, and track results over time. No command line needed.\nWhat It Does # Device Inventory Add your routers and switches once. Credentials are stored with Fernet encryption. DiagNet handles the connections so your tests don't have to. 37\u0026#43; Built-in Test Templates Ping, BGP, OSPF, EIGRP, HSRP, IPSec, NAT, port security, AAA audits, and more. All ready to use out of the box. Group tests together and run them in one go. Result History \u0026amp; Comparison Every test run is stored. Compare results across attempts to catch network drift, spot regressions, and prove stability over time. Multi-user Access Control Role-based permissions let you control who can run tests, manage devices, or administer the system. ","date":"16 September 2025","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":" Medieninhaber und Herausgeber # DiagNet Rennweg 89b, 1030 Wien Österreich\nKontaktdaten # E-Mail: team@diagnet.dev Tel: +43 1 242 15-10\nVerantwortlich für den Inhalt # Karun Singh Sandhu\n","date":"16 September 2025","externalUrl":null,"permalink":"/impressum/","section":"","summary":"","title":"Impressum","type":"page"},{"content":"DiagNet (DGNT) is developed by HTL Rennweg students. The goal is simple: make network testing easier, centralized, and more transparent.\nInstead of running every test manually, DiagNet provides a web application with a clear interface and a flexible backend. Tests can be started quickly, planned ahead, stored, and repeated whenever needed.\nThe system is aimed at network administrators and IT professionals — both in training and in production environments. Results are collected, compared, and make changes in the network visible over time.\nIn short: DiagNet turns network testing from a manual chore into a centralized, automated, and analyzable process.\nSponsored by CANCOM Austria AG ","date":"8 September 2025","externalUrl":null,"permalink":"/about/","section":"","summary":"","title":"About","type":"page"},{"content":"","date":"8 September 2025","externalUrl":null,"permalink":"/docs/","section":"Docs","summary":"","title":"Docs","type":"docs"},{"content":" Hey all! 👋 # Meet the people who make DiagNet happen. Our team combines technical expertise, creativity, and collaboration to bring you the best network testing experience.\nFrom left to right: Danijel, Benedikt, Luka, Karun Team Members # Karun – Project Lead # I’m the one steering the ship. I set the technical direction and wear a lot of hats. Sometimes even all at once. What I spend most of my time on:\nCrafting the front‑end experience: building the UI and interactions Designing clean, maintainable code: writing readable, reusable logic Setting up CI/CD pipelines: automating builds, tests, and releases Packaging \u0026amp; deploying: bundling and delivering the final product Curious about me? Take a look at my homepage.\nLuka – Scrum Master # My work happens mostly on the backend, where reliability and efficiency matter most.\nI focus on making the system scalable and well-documented, so it can keep up as the project grows.\nThat means optimizing the backend, designing APIs, and structuring the database.\nI also take care of the practical parts — configuring routers, keeping data flowing, and running the test pipeline to make sure new features don’t break what’s already working.\nBenedikt – Developer # I\u0026rsquo;m one of the driving forces when it comes to the development and design of our Product. A few of my most important tasks are:\nCreating an efficient and well structured backend Organizing and setting up Soft- and Hardware for testing our Product Implementing a seamless interface between our software and the devices it tests Feel free to contact me by writing an email.\nDanijel – Developer # I focus on network testing and visualization within the project. My main responsibilities include:\nConfiguring the network topology, especially the switches Maintaining test cases for switching Implementing the graphical listing and visualization of test results Running tests and analyzing their results Additionally, I contribute to security hardening and manage our social media presence This way, I make sure the technical foundation is solid and the results are presented in an accessible way.\n","date":"8 September 2025","externalUrl":null,"permalink":"/team/","section":"","summary":"","title":"Team","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]