If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/HMBSbige/NatTypeTester shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2d ago
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 59% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live HMBSbige/NatTypeTester repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/HMBSbige/NatTypeTester.

What it runs against: a local clone of HMBSbige/NatTypeTester — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in HMBSbige/NatTypeTester | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of HMBSbige/NatTypeTester. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/HMBSbige/NatTypeTester.git
#   cd NatTypeTester
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of HMBSbige/NatTypeTester and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "HMBSbige/NatTypeTester(\\.git)?\\b" \\
  && ok "origin remote is HMBSbige/NatTypeTester" \\
  || miss "origin remote is not HMBSbige/NatTypeTester (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/HMBSbige/NatTypeTester"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

NatTypeTester is a C# multi-platform (Android, Console) STUN client that detects and classifies NAT types on a network using RFC 3489, RFC 5780, and RFC 8489 protocols. It tests network connectivity characteristics (mapping behavior, filtering behavior, binding detection) by exchanging packets with STUN servers and publishes its core logic as the Stun.Net NuGet package. Multi-target project structure: src/NatTypeTester.Application.Contracts defines service interfaces (IRfc3489AppService, IRfc5780AppService, IStunServerListAppService); src/NatTypeTester.Application implements them; src/NatTypeTester.Configuration handles config via JSON serialization; src/NatTypeTester.Console and src/NatTypeTester.Android are platform-specific entry points. Architecture follows ABP (ASP.NET Boilerplate) module pattern with dependency injection.

Network engineers and developers building peer-to-peer applications, VoIP systems, or game backends who need to detect NAT behavior to optimize connection routing. Also useful for users wanting a simple Android app to diagnose their network's NAT type.

Actively maintained with CI/CD pipelines (.github/workflows/CI.yaml), organized modular architecture using ABP framework conventions, and published as a production NuGet package. The codebase shows professional structure with configuration management (AppConfigManager.cs), contracts-based design, and multi-protocol support (UDP, TCP, TLS, DTLS), indicating production-ready status.

Single maintainer (HMBSbige) is a potential risk for long-term maintenance. Dependency management is centralized via Directory.Packages.props and NuGet.Config, which is good practice but means breaking upstream changes could affect all projects simultaneously. No visible test directories in the provided file list suggests test coverage may be incomplete or located elsewhere.

Active Renovate bot integration (.github/renovate.json) indicates automated dependency updates. No specific recent commits or PRs visible from file list alone, but CI workflows are in place and the project has released versions to NuGet, suggesting ongoing maintenance and potential incremental improvements.

git clone https://github.com/HMBSbige/NatTypeTester.git
cd NatTypeTester
dotnet restore
dotnet build

To run the Console variant: dotnet run --project src/NatTypeTester.Console. For Android, open NatTypeTester.Android.csproj in Visual Studio and deploy to an emulator or device.

Daily commands: Console: dotnet run --project src/NatTypeTester.Console -- [STUN_SERVER] [OPTIONS]. Android: Load src/NatTypeTester.Android/NatTypeTester.Android.csproj in Visual Studio, set Android SDK path, and deploy. No traditional dev server; this is a client-side diagnostic tool.

• src/NatTypeTester.Application.Contracts/IRfc5780AppService.cs: Defines the core RFC 5780 STUN test service interface that implements NAT detection logic.
• src/NatTypeTester.Application/Rfc5780AppService.cs: Implements the RFC 5780 STUN protocol state machine for binding, mapping, and filtering behavior detection.
• src/NatTypeTester.Application/StunServerListAppService.cs: Manages the pool of STUN servers used for testing; critical for test reliability and failover.
• src/NatTypeTester.Configuration/AppConfigManager.cs: Handles loading and managing application configuration (STUN server URLs, timeout values, protocol settings).
• src/NatTypeTester.Console/Program.cs: Entry point for the CLI; orchestrates the test flow and output formatting for users.
• src/NatTypeTester.Android/MainActivity.cs: Android UI entry point; binds application logic to platform-specific lifecycle and UI controls.

To add new STUN tests, extend src/NatTypeTester.Application.Contracts/IRfc5780AppService.cs interface and implement in src/NatTypeTester.Application/Rfc5780AppService.cs. To add STUN server sources, modify src/NatTypeTester.Application/StunServerListAppService.cs. For Android UI changes, edit src/NatTypeTester.Android/MainActivity.cs. Configuration defaults live in src/NatTypeTester.Configuration/AppConfigManager.cs.

Configuration file location and format must match AppConfigJsonContext schema—misconfigured JSON will silently fail to load. STUN server list is fetched via HTTP (AppHttpClientFactory)—network connectivity is required at runtime or tests will fail. RFC 3489 vs RFC 5780 implementations use different state machines; mixing them in a single test run can produce incorrect NAT classification. TLS/DTLS support requires platform-specific certificate handling not visible in the file list—verify certificate pinning or validation logic is implemented before using in production.

• STUN (Session Traversal Utilities for NAT) — STUN is the core protocol that NatTypeTester implements; understanding the request/response message format and state machine is essential to extend or debug the tool.
• NAT Behavior Classification (Mapping & Filtering) — RFC 5780 distinguishes four NAT types based on how a NAT maps internal addresses to external addresses and filters inbound traffic; NatTypeTester's entire purpose is automating this classification.
• XOR-MAPPED-ADDRESS (STUN Attribute) — STUN servers return the client's external IP and port via this obfuscated attribute; NatTypeTester parses it to detect address translation changes across test vectors.
• Full Cone, Address Restricted, Port Restricted, Symmetric NAT — These four NAT types represent increasingly restrictive behaviors; NatTypeTester determines which one applies to the client's network through a sequence of STUN binding tests.
• ABP (ASP.NET Boilerplate) Modular Architecture — This project uses ABP's module system, dependency injection, and service contracts pattern; understanding this framework is critical for extending the application layer and adding new STUN protocols.
• Dual-Stack IPv4/IPv6 Testing — NatTypeTester supports both IPv4 and IPv6 protocols; this affects how STUN messages are formatted and how external addresses are interpreted, requiring parallel test execution paths.
• DTLS-over-UDP (Datagram TLS) — NatTypeTester supports encrypted STUN over UDP via DTLS; this requires async socket handling and certificate validation distinct from TCP/TLS paths.

• coturn/coturn — Reference STUN/TURN server implementation; useful for understanding server-side behavior and testing the client against a real server.
• pion/stun — Go-based STUN library with similar RFC 5780 test logic; good for comparing implementation approaches across languages.
• sigip-media/stunclient — Another C# STUN client; reference for alternative implementation patterns and cross-validation of NAT detection algorithms.
• webrtc/samples — WebRTC peer-connection samples that rely on STUN for NAT traversal; demonstrates real-world usage context for NAT type detection.
• pradt2/always-online-stun — Aggregates public STUN servers and provides health checks; complements NatTypeTester's STUN server list management.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for Rfc3489AppService and Rfc5780AppService

The repo implements STUN protocol testing across RFC 3489 and RFC 5780 standards, but there's no visible test project in the file structure. The core application services (src/NatTypeTester.Application/Rfc3489AppService.cs and Rfc5780AppService.cs) lack test coverage, which is critical for a network protocol library. This would improve reliability and help contributors understand the expected behavior.

• [ ] Create a new test project: src/NatTypeTester.Application.Tests/NatTypeTester.Application.Tests.csproj
• [ ] Add unit tests for Rfc3489AppService covering different NAT detection scenarios (Full Cone, Restricted, Port Restricted, Symmetric)
• [ ] Add unit tests for Rfc5780AppService testing RFC 5780 specific binding test flows
• [ ] Add integration tests for StunTestInputResolver to verify correct STUN server selection logic
• [ ] Reference the RFC diagram documentation (docs/img/) to ensure test cases map to the protocol flows

Add GitHub Actions workflow for cross-platform testing (Windows/Linux/macOS)

The repo supports multiple platforms (Console, Desktop, Android) and protocols (IPv4/IPv6, UDP/TCP/TLS/DTLS), but the CI.yaml workflow is not visible in detail. A comprehensive cross-platform test matrix would catch platform-specific networking issues early. This is especially important for STUN protocol implementation which has OS-specific socket behavior.

• [ ] Expand .github/workflows/CI.yaml to include matrix build for ubuntu-latest, windows-latest, and macos-latest
• [ ] Add separate test step for IPv4 and IPv6 protocol validation on each platform
• [ ] Add test step for multiple transport protocols (UDP, TCP, TLS, DTLS) execution
• [ ] Configure test step to validate both NatTypeTester.Console and NatTypeTester.Desktop projects
• [ ] Add coverage reporting for src/NatTypeTester.Application/ and src/NatTypeTester.Domain/ projects

Document STUN server configuration and add tests for StunServerListAppService

The codebase includes src/NatTypeTester.Application.Contracts/IStunServerListAppService.cs and LoadStunServerListInput.cs, but no visible test coverage or configuration documentation. Contributors and users need guidance on how STUN server lists are loaded, validated, and cached. This affects the reliability of NAT type testing.

• [ ] Create unit tests for StunServerListAppService (src/NatTypeTester.Application.Tests/) covering list loading, validation, and filtering logic
• [ ] Add documentation to docs/ explaining STUN server configuration format and LoadStunServerListInput parameters
• [ ] Add test cases for network resilience (timeout handling, server unavailability fallback) in StunServerListAppService
• [ ] Document the server list schema and add example configuration file to docs/
• [ ] Add tests verifying IPv4/IPv6 server filtering based on StunTestInput parameters

• Add comprehensive unit tests for Rfc3489AppService.cs under a new src/NatTypeTester.Tests directory, covering all NAT type classification branches (Full Cone, Restricted, Port Restricted, Symmetric).
• Implement retry logic with exponential backoff in StunServerListAppService.cs when a STUN server is unreachable, and document fallback behavior in README.md.
• Create a configuration validation utility in AppConfigManager.cs that detects invalid STUN server URLs, protocol mismatches, or timeout values before tests run, and emit clear error messages to the Android UI.

The NatTypeTester codebase demonstrates a reasonable security posture with a modular architecture and clear separation of concerns. However, several medium and low-severity vulnerabilities exist primarily around network communication security, dynamic configuration loading, and input validation. The main concerns are: (1) ensuring HTTPS is properly enforced for all remote communications, (2) validating dynamically loaded STUN server configurations, (3) protecting sensitive network diagnostic information in logs, and (4) comprehensive input validation across all network parameters. The application does not appear to contain hardcoded secrets or obvious injection vulnerabilities based on the file structure. Addressing the medium-severity issues around HTTP communication and server configuration validation should be prioritized.

• Medium · Potential Insecure HTTP Communication — src/NatTypeTester.Application/AppHttpClientFactory.cs, src/NatTypeTester.Application/UpdateAppService.cs. The application implements STUN protocol testing which may involve HTTP/HTTPS communication for server lists and updates. Without explicit code review of AppHttpClientFactory.cs and UpdateAppService.cs, there's a risk of insecure HTTP usage, SSL/TLS validation bypass, or certificate pinning absence. Fix: Ensure all HTTP communications use HTTPS with proper TLS validation. Implement certificate pinning for critical endpoints. Review HttpClient configuration for secure defaults.
• Medium · Dynamic STUN Server Configuration — src/NatTypeTester.Application/StunServerListAppService.cs, src/NatTypeTester.Application.Contracts/IStunServerListAppService.cs. The application loads STUN server lists dynamically via StunServerListAppService.cs and LoadStunServerListInput.cs. If server lists are fetched from untrusted sources or without proper validation, this could enable man-in-the-middle attacks or redirection to malicious servers. Fix: Implement integrity validation for loaded STUN server lists (e.g., cryptographic signatures). Use trusted sources for server configuration. Validate server addresses before use. Consider allowlisting known good servers.
• Low · Potential Information Disclosure via Logging — src/NatTypeTester.Application/Rfc3489AppService.cs, src/NatTypeTester.Application/Rfc5780AppService.cs. Network diagnostic applications often log detailed information about network configurations, IP addresses, and NAT behavior. If logs are not properly secured or contain sensitive network information, they may leak privacy-sensitive data. Fix: Implement secure logging practices. Avoid logging IP addresses, detailed network topology, or other PII. Ensure logs are stored securely with appropriate access controls. Consider implementing log rotation and encryption.
• Low · Missing Input Validation Documentation — src/NatTypeTester.Application.Contracts/StunTestInput.cs, src/NatTypeTester.Application.Contracts/LoadStunServerListInput.cs. The StunTestInput.cs and LoadStunServerListInput.cs contracts lack visible input validation. STUN testing involves network parameters that should be validated to prevent malformed requests or resource exhaustion. Fix: Implement comprehensive input validation for all user-provided parameters. Validate port ranges, server addresses format, timeout values, and retry counts. Use data annotations and custom validators.
• Low · Platform-Specific Security Considerations — src/NatTypeTester.Android/MainActivity.cs, src/NatTypeTester.Android/Properties/AndroidManifest.xml. The application supports multiple platforms (Android, Desktop, Console) with different security models. Android implementation in MainActivity.cs and manifest may have permission issues or insecure configurations. Fix: Review Android manifest for least privilege principle. Ensure only necessary permissions are requested (INTERNET, ACCESS_NETWORK_STATE). Implement proper runtime permission handling for Android 6.0+. Validate all network operations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.