btest-rs/KNOWN_ISSUES.md

Known Issues

This document tracks known limitations, bugs, and platform-specific issues in btest-rs. If you encounter an issue not listed here, please report it at: https://git.manko.yoga/manawenuz/btest-rs/issues

IPv6 UDP on macOS (Server Mode)

Severity: High Affects: macOS only (server mode, UDP, IPv6) Status: Open

When running as a server on macOS and a MikroTik client connects over IPv6 UDP, the server's UDP transmit hits ENOBUFS (error 55 — "No buffer space available") repeatedly. This causes:

• Direction "receive" (server TX): intermittent packet bursts with gaps, MikroTik shows unstable or low speed
• Direction "send" (server RX): works, but speed drops over time due to MikroTik's speed adaptation receiving irregular status feedback
• Direction "both": TX side severely degraded

Root cause: macOS kernel returns ENOBUFS on IPv6 send_to() much more aggressively than IPv4 due to smaller interface output queues and per-packet NDP overhead. Connected sockets (send()) perform better than unconnected (send_to()), but still hit limits under high throughput.

Workaround: Use IPv4 for UDP tests on macOS, or deploy the server on Linux where IPv6 UDP works correctly.

Not affected:

• IPv4 UDP (all directions, all platforms)
• IPv6 TCP (all directions, all platforms)
• Client mode over IPv6 (connecting TO a MikroTik server works fine at 600+ Mbps)

IPv6 UDP — Not Tested on Linux

Severity: Unknown Affects: Linux server, IPv6, UDP Status: Untested

IPv6 UDP in server mode has not been thoroughly tested on Linux. The macOS ENOBUFS issue is kernel-specific and likely does not exist on Linux (which has much better IPv6 UDP buffer management). Testing and reports welcome.

macOS UDP Send Buffer Saturation

Severity: Medium Affects: macOS (client and server, IPv4 and IPv6, UDP) Status: Mitigated

On macOS, when sending UDP at unlimited speed, the kernel buffer fills quickly and returns ENOBUFS. The adaptive backoff mechanism (200μs → 10ms) mitigates this, but the first few seconds of a test may show:

• Interval 1: high burst (40-300 Mbps depending on conditions)
• Interval 2: 0 bps (buffer full, backoff in effect)
• Interval 3+: gradually recovers to steady state

This causes the first 2-3 seconds of UDP tests to be unreliable on macOS. On Linux, this issue does not occur.

Workaround: Ignore the first few seconds of results, or use TCP mode which does not have this issue.

Windows Binaries Not Tested

Severity: Unknown Affects: Windows x86_64 Status: Untested

Windows binaries are cross-compiled from Linux using gcc-mingw-w64 in CI. They have never been tested on actual Windows systems. Issues may include:

• Socket behavior differences (Winsock vs BSD sockets)
• IPv6 dual-stack handling
• Path separator issues in CSV output
• Console output encoding

Help wanted: If you test on Windows, please report your findings.

EC-SRP5 Server Authentication — Occasional Failure

Severity: Low Affects: Server mode with --ecsrp5 Status: Mostly fixed

EC-SRP5 server authentication occasionally fails with "client proof mismatch". This was largely fixed by storing the correct gamma parity from key derivation, but edge cases may still exist with certain salt/password combinations due to the Curve25519 Weierstrass arithmetic.

Workaround: Retry the connection. If it fails consistently, restart the server (which regenerates the salt).

MikroTik Speed Adaptation Staircase (Server RX, UDP)

Severity: Low Affects: Server mode, UDP, direction "send" (MikroTik sends to us) Status: MikroTik client behavior

When MikroTik connects as a client and sends data (direction "send"), the speed may gradually decrease in a staircase pattern over 30-60 seconds. This is caused by MikroTik's client-side speed adaptation algorithm, not by our server.

The original C btest-opensource server exhibits the same behavior. Single-connection mode (connection-count=1) provides the best results.

TCP Multi-Connection Bandwidth Reporting

Severity: Low Affects: Server mode, TCP, connection-count > 1 Status: Open

With TCP multi-connection, the server correctly handles all connections and data flows, but bandwidth is only measured on the primary connection's status loop. MikroTik may show lower-than-actual speeds because status messages are not distributed across all connections.

Bandwidth Limit (-b) Not Fully Effective

Severity: Low Affects: Client mode, -b flag Status: Open

The -b bandwidth limit flag does not reliably cap speed. The calc_send_interval function computes the inter-packet delay correctly, but tokio's timer resolution and task scheduling can cause actual throughput to exceed the specified limit, especially for high bandwidth values.

---

Reporting Issues

Found a bug or unexpected behavior? Please report it:

• Issue tracker: https://git.manko.yoga/manawenuz/btest-rs/issues
• Include: OS/platform, btest-rs version (btest --version), MikroTik RouterOS version, protocol (TCP/UDP), direction, connection count, and the full command line used.
• Packet captures: If possible, attach a tcpdump/pcap capture. Use: sudo tcpdump -i <interface> -w capture.pcap -s 200 'host <mikrotik_ip> and (port 2000 or portrange 2001-2356)'
• Debug logs: Run with -vv to get hex-level status exchange dumps.

Platform Test Matrix

Platform	TCP4	UDP4	TCP6	UDP6	Notes
macOS (ARM64)	Pass	Pass*	Pass	Fail**	*UDP send buffer saturation on first seconds
macOS (x86_64)	Untested	Untested	Untested	Untested
Linux (x86_64)	Pass	Pass	Pass	Untested	Deployed on Ubuntu 24.04
Linux (aarch64)	Untested	Untested	Untested	Untested	RPi builds available
Linux (armv7)	Untested	Untested	Untested	Untested	RPi builds available
Windows (x86_64)	Untested	Untested	Untested	Untested	Cross-compiled, never tested

Pass = verified against MikroTik RouterOS 7.x Fail = known issue documented above Untested = builds available but not verified