macOS returns ENOBUFS on IPv6 send_to() until NDP neighbor resolution
completes. Send a 1-byte probe packet and wait 200ms for NDP to resolve
before starting the data blast.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The into_std/from_std conversion lost the buffer settings. Now create
the raw socket with socket2 first, set SO_SNDBUF/SO_RCVBUF to 4MB,
then wrap with tokio. Also logs actual buffer sizes for debugging.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
macOS IPv6 UDP sockets have tiny default send buffers, causing
immediate ENOBUFS on every send_to(). Set SO_SNDBUF and SO_RCVBUF
to 4MB using socket2, matching what works for high-throughput IPv4.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Same fix as server side — format!("{}:{}", ipv6, port) fails.
Use SocketAddr::new() for IPv6 and bind to [::] instead of 0.0.0.0.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
IPv6 UDP sends hit ENOBUFS much faster than IPv4 (smaller kernel
buffers, NDP overhead). Fixed:
- Adaptive backoff: 200us→10ms as errors accumulate, resets on success
- Higher error threshold: 50k instead of 1k before stopping
- Yield with sleep when errors have been seen recently
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
macOS connected IPv6 UDP sockets don't receive properly.
Use unconnected socket (send_to/recv_from) for IPv6 peers,
same as multi-connection mode.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
format!("{}:{}", ipv6_addr, port) produces invalid socket address.
Use SocketAddr::new() instead. Also bind UDP to [::] for IPv6 peers
and 0.0.0.0 for IPv4 peers.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Server now binds on both IPv4 (0.0.0.0) and IPv6 (::) by default.
Uses tokio::select! to accept from whichever listener has a connection.
New flags:
--listen <addr> IPv4 listen address (default: 0.0.0.0, "none" to disable)
--listen6 <addr> IPv6 listen address (default: ::, "none" to disable)
Examples:
btest -s # listen on both v4 and v6
btest -s --listen6 none # IPv4 only
btest -s --listen none # IPv6 only
btest -s --listen 192.168.1.1 # specific IPv4 address
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New features:
- --syslog <address:port> sends structured events to remote syslog (RFC 5424 UDP)
Events: AUTH_SUCCESS, AUTH_FAILURE, TEST_START, TEST_END, TEST_RESULT
- EC-SRP5 authentication for both client and server modes
- TCP multi-connection support (session tokens, all 3 directions)
Bug fixes since v0.2.0:
- EC-SRP5 server: fixed gamma parity (was 50% auth failure rate)
- EC-SRP5 server: use lift_x not redp1 for verification
- TCP send direction: server sends 12-byte status messages to client
- TCP both direction: TX loop injects status between data packets
- TCP data: send all zeros (no 0x07 header that MikroTik rejected)
- TCP disconnect detection: running flag set on EOF
- UDP multi-connection: unconnected socket accepts all source ports
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
In BOTH direction, the TX loop now injects 12-byte status messages
every 1 second between data packets, reporting rx_bytes to the client.
Multi-connection mode also updated with same logic for all 3 cases:
- TX only: pure data
- RX only: status sender on writer
- BOTH: TX data + interleaved status messages
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The status sender and status_report_loop were BOTH calling swap(0)
on rx_bytes, racing each other. Now the status sender owns the swap
and prints stats itself. The report loop is skipped in RX-only TCP mode.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Was sending cumulative rx_bytes total which zigzagged because
MikroTik interprets the value as per-interval bandwidth.
Now tracks last_rx and sends (current - last) delta each second.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pcap of MikroTik-as-server showed it sends periodic 12-byte status
messages back to the client even in RX-only mode. The client needs
these to display speed. Added tcp_status_sender that writes status
messages containing rx_bytes on the TCP write half every 1 second.
Reverted the "always bidirectional" change — TCP direction is
conditional, but RX mode now uses the writer for status instead
of keeping it idle.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MITM capture of MikroTik-to-MikroTik showed both sides always send
zero-filled TCP streams, regardless of the direction setting. Direction
only controls what gets measured. Our server wasn't starting a TX thread
when direction=RX, so MikroTik saw no data and reported 0 speed.
Now TCP always starts both TX and RX on every connection.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MITM capture showed MikroTik sends all-zero TCP data streams.
Our server was setting packet[0]=0x07 (STATUS_MSG_TYPE), which
MikroTik rejected. TCP mode has no status headers — just raw
zero-filled data streams in both directions.
Fixed in both server and client TCP TX loops.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When a TCP connection closes (EOF or write error), the loop now sets
the shared running flag to false, which stops the status report loop
and all other tasks. Adds "test ended" log messages.
The TCP multi-conn "MikroTik shows 0 on send" is a separate issue
requiring TCP-level status exchange (MikroTik sends 12-byte status
messages on TCP connections, not just a data stream).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The gamma point's y-parity depends on the random salt. Using hardcoded
parity=true caused ~50% of auth attempts to fail (whenever the actual
parity was 0). Now stored from key derivation and used correctly.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pcap analysis showed MikroTik sends/receives data across all 20 TCP
connections, but we only used the primary. Now all streams get their
own TX and RX tasks, distributing bandwidth across all connections.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Server-side shared secret used redp1(x_gamma) which is the hash-to-curve
blinding function, but verification needs lift_x(x_gamma) — the raw
validator public key point. Also fixed prime_mod_sqrt for p ≡ 5 (mod 8)
using Atkin's algorithm instead of Tonelli-Shanks.
Removed unused password parameter from server_authenticate.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Secondary connections send [TOKEN_HI, TOKEN_LO, 0x02, 0x00, ...]
as their command — they don't do auth. Server verifies the session
token matches a pending session from the same IP, sends OK with
token, and lets them join. No auth challenge/response needed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Secondary connections were rejected at recv_command with "Invalid command"
because they don't send a standard 16-byte command. Now we read raw bytes
first, check if there's a pending session from the same IP, and handle
secondary connections before validating the command format.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When tcp_conn_count > 0, the auth OK response includes a session
token in bytes 1-2: [01, HI, LO, 00] instead of [01, 00, 00, 00].
MikroTik checks these bytes to determine multi-connection support.
Primary connection: full handshake, receives session token
Secondary connections: auth with same token, join the session
Server waits up to 10s for all connections to join before starting.
This fixes MikroTik showing "test unsupported" for TCP multi-conn.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause found via pcap analysis: MikroTik with connection-count=N
sends UDP from N different source ports (2257, 2258, 2259, ...) all
to our single server port 2001. A connect()'d UDP socket only accepts
packets from the one connected address, silently dropping ~75% of
traffic with conn_count=4.
Fix: when tcp_conn_count > 0, leave the UDP socket unconnected and
use send_to()/recv_from() instead of send()/recv(). This accepts
packets from all MikroTik source ports.
This bug also exists in the original C btest-opensource.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Dockerfile.static: takes pre-built binary, no compilation
- push-docker.sh: downloads x86_64 from CI release, builds arm64
natively, creates multi-arch manifest and pushes both
- docker pull works on both Intel and Apple Silicon / RPi
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Multi-connection mode is not supported and causes near-zero throughput.
Updated README, user guide, MikroTik CLI examples, and troubleshooting.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
crane can't pull scratch in CI. Docker images are built locally
on Mac where Docker is available, then pushed to Gitea registry.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
crane append doesn't support --set-entrypoint. Use crane mutate
as a separate step to set entrypoint and cmd on the pushed image.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Uses crane (no Docker daemon needed) to build a minimal scratch-based
OCI image from the static musl binary and push it to the Gitea
container registry. Tags both vX.Y.Z and latest.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Uses gcc-mingw-w64 to cross-compile btest.exe from Linux.
Release now includes 4 targets: Linux x86_64/aarch64/armv7 + Windows x86_64.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The act runner has no Node.js in container jobs. Replace
actions/upload-artifact and actions/download-artifact with
direct Gitea API uploads from a single job that builds all
three architectures sequentially.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The act runner already mounts the repo at the workspace path.
Removed manual git clone and working_directory overrides.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The act runner executes actions/checkout inside the job container,
but that action is a Node.js script and rust:1.86-slim has no node.
Use plain git clone instead.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- .gitea/workflows/ci.yml: run tests on every push/PR
- .gitea/workflows/release.yml: build Linux binaries on tag push
- x86_64 (musl static)
- aarch64 / RPi 64-bit (musl static)
- armv7 / RPi 32-bit (musl static)
- Auto-creates Gitea release with all artifacts
- scripts/build-macos-release.sh: build macOS binary locally and
upload to an existing Gitea release
Release flow:
git tag v0.1.0 && git push origin v0.1.0
# CI builds Linux + RPi, creates release
# Then on Mac: ./scripts/build-macos-release.sh --upload v0.1.0
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Rename package to btest-rs (Rust convention for reimplementations)
- MIT license matching the original btest-opensource license
- LICENSE explicitly credits Alex Samorukov's original work
- Comprehensive README with usage, performance numbers, and credits
- CLI --help references the original project
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Dockerfile.cross: builds static x86_64 musl binary from macOS via Docker
- scripts/build-linux.sh: one-command cross-compilation
- scripts/install-service.sh: systemd service with security hardening
- Bump Rust Docker images to 1.86 for edition2024 support
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Full reimplementation of the MikroTik Bandwidth Test protocol:
- Server mode: accepts connections from MikroTik devices on port 2000
- Client mode: connects to MikroTik btest servers
- TCP and UDP protocols with bidirectional support
- MD5 challenge-response authentication
- Dynamic speed adjustment (1.5x algorithm)
- Status exchange matching original C pselect() behavior
- Docker support with multi-stage build
Tested against MikroTik RouterOS achieving:
- 1.05 Gbps server RX (single connection)
- 530 Mbps client TCP download
- 840 Mbps client TCP upload
- 433 Mbps client UDP download
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
