The Problem

Network engineers juggle a dozen single-purpose tools—separate SSH clients, ping utilities, port scanners, and DNS lookup apps. Ducky consolidates these into one PySide6 desktop application, so a user can run diagnostics and manage sessions without switching contexts.

What This Does

Ducky is a tabbed desktop app with a multi-protocol terminal (SSH, Telnet, Serial), network diagnostics (ping, traceroute, port scan, subnet calculator, Wake-on-LAN), DNS/email tools (lookup, MX, propagation, whois, SMTP test), and IP utilities (geolocation, MAC vendor lookup, ARP/route table). The UI lives in src/ducky_app/ui/ with widgets, dialogs, themes, and a main window; core logic sits in src/ducky_app/core/ for config, sessions, and background workers. Configuration persists through config_manager.py, sessions through session_manager.py.

How It Is Wired

Execution starts at run in src/ducky_app/main.py:23, which reaches 12 functions and builds the MainWindow. The heaviest file is src/ducky_app/ui/widgets.py—118 functions, 24 classes—handling terminal widgets, network tools, and crypto operations (likely SSH key generation). src/ducky_app/core/workers.py (42 functions, 16 classes) runs external commands and makes outbound network calls via ConnectionReaderThread.

The internal call graph shows _merge_format called from 7 places and disconnect_from_target from 5—these carry the widest blast radius. A traced path from entry to process exit: run -> _run_ping which invokes subprocess.Popen. The module graph shows no import edges between internal modules, meaning the codebase is flat and decoupled; changes to one file won't cascade through imports, but the oversized files concentrate risk.

File-by-file map:

  • widgets.py — terminal and tool UI, the main hub
  • workers.py — background threads, subprocesses, network calls
  • main_window.py — window assembly, toolbar, file I/O
  • config_manager.py — config load/save, settings access
  • dialogs.py — connection and settings dialogs
  • session_manager.py — session folder creation, log save/load
  • main.py — entry point, admin elevation
  • icons.py, helpers.py — icon lookup, dependency checks

How To Use It

Setup (from pyproject.toml):

pip install -e .

Configuration: No environment variables required. Settings persist via config_manager.py; sessions save to directories created by session_manager.py.

Running it:

python -m src.ducky_app.main

The repo includes build_installer.ps1, ducky.spec, and installer.iss for packaging, but lacks a Dockerfile or lockfile.

Real-World Use

A network admin troubleshooting a remote device: open Ducky, SSH into the device via the terminal tab, run a ping to a target IP from the diagnostics tab, then use the port scanner to check open ports. Sessions save automatically, so the admin can close and reopen the app without re-entering credentials.

Code Health & Issues

Static analysis (deterministic, not opinion) found 11 findings across 3 kinds:

  • High – Deep nesting – src/ducky_app/core/workers.py, src/ducky_app/ui/main_window.py, src/ducky_app/ui/widgets.py – max indentation depth 9; fix with early returns and extracted blocks.
  • High – Oversized files – widgets.py (1359 lines), workers.py, themes.py – split by responsibility.
  • Medium – Broad exception handling – config_manager.py, workers.py, main.py – bare except swallows errors; catch specific exceptions.

SDLC gaps: no CI/CD pipeline, no lockfile, no test suite (despite a tests/ directory existing), no Dependabot/Renovate config. The repo has a license and no committed secrets.

The Bottom Line

Ducky is a functional, feature-rich networking tool with a clean separation between UI and core logic—the zero import edges between modules make it easy to reason about. The risk is concentrated in oversized, deeply nested files that will be painful to modify. Use it if you need a single desktop app for network diagnostics; contribute only if you're willing to refactor widgets.py first.