feature/wgcf/custom-mtu-generation

[michaelik1]

Motivation

Currently, wgcf always generates WireGuard profiles with a fixed MTU of 1280. While this is a safe default, some network setups may benefit from a different MTU or from letting WireGuard determine it automatically.

This change allows users to customize or omit the MTU without manually editing the generated profile, while preserving the existing behavior by default.

Description

Adds support for custom MTU values when generating WireGuard profiles.

Usage:

wgcf generate --mtu 1420    # sets a custom MTU
wgcf generate --no-mtu      # omits the MTU setting

The --mtu and --no-mtu flags are mutually exclusive and cannot be used together.

The default remains MTU = 1280 for backward compatibility.

Added tests for flag parsing and generated profile output.

---

I also considered validating MTU values against system-specific limits, but decided that this falls outside wgcf's responsibility, especially since valid MTU ranges may vary across systems. For now, only zero and negative values are rejected, leaving further validation to the user and the system.

Side note

Tried to keep this one consistent with the project's existing code style and structure, just like last time.

@ViRb3

[michaelik1]

I've been thinking about this for a while: do we really need to preserve wgcf's existing MTU behavior for backward compatibility?

I'm personally torn between keeping the --no-mtu flag I implemented to preserve the default behavior of previous versions and using this as an opportunity to make a small breaking change in favor of a cleaner, more explicit CLI.

Ideally, the MTU setting would only be included when explicitly requested with --mtu, and omitted otherwise. This would make the behavior more predictable, without relying on implicit defaults or requiring a separate --no-mtu flag.

A similar approach was taken in the PR #637 for --keepalive, where the flag now requires an explicit value instead of relying on implicit behavior. I think this is a nice improvement in terms of CLI consistency and predictability.

I'd like to hear your thoughts on this before making a final decision. I'm happy to implement whichever approach we agree on.