Context

aws s3 sync was running at 60 KB/s on a link that should reach around 80 Mbps. The issue was not one bug but several: DFS channel pauses, Apple roaming behavior, LTE bufferbloat, and smaller configuration problems. This article walks through the complete fixes on RouterOS v7.

Symptoms

Three things were happening at once:

  1. s3 sync would stall for seconds, then resume, then stall again.
  2. Speed tests showed 80 Mbps down, but interactive use felt sluggish.
  3. The Mac would occasionally drop off Wi-Fi and reconnect seconds later.

The tools: networkQuality on macOS for latency and throughput measurement, and the MikroTik CLI for radio and queue diagnostics.

Layer 1: DFS radar on the 5 GHz radio

5 GHz Wi-Fi in Europe overlaps with weather radar spectrum. Channels in the DFS (Dynamic Frequency Selection) range require the router to listen for radar pulses. When it detects one, it must go silent for 60 seconds and switch channels.

My router was on channel 100 (5500 MHz), right in the DFS zone:

/interface wifi monitor [find name=mrt6]

# channel: 5500/ax/Ceee/D (DFS)

The logs showed frequent "radar detected" events. Each one meant a full minute of radio silence.

The fix: move to channel 36 (5180 MHz), which is outside the DFS range. No radar checks, no forced channel switches.

/interface wifi set [find name=mrt6] channel.frequency=5180

Layer 2: 802.11r roaming and Apple devices

With the radio stable, the Mac still had micro-stutters. The Wi-Fi logs showed a pattern: disconnect at -92 dBm, reconnect at -52 dBm. The Mac was roaming aggressively, even with only one access point in range.

The issue was 802.11r Fast Transition, specifically the "over-the-DS" (Distribution System) variant. This negotiates roaming through the wired backbone. Apple devices prefer "over-the-air" roaming and stall during the DS handshake.

Disabling FT-over-DS and enforcing Protected Management Frames (required for WPA3) resolved the disconnects:

/interface wifi set [find name=mrt6] security.ft-over-ds=no security.pmf=required

Layer 3: LTE bufferbloat

The Wi-Fi was now solid. No drops, no radar pauses. But networkQuality showed:

Responsiveness: Low (727 milliseconds)

Idle Latency: 440 milliseconds

700 ms of latency on a connection with 28 ms idle round-trip time. This is bufferbloat.

The ISP (LTE) has large buffers on the tower side. During an upload like s3 sync, the router sends packets faster than the tower can drain them. The tower queues them. Eventually every new packet, including DNS lookups and TCP ACKs, waits behind hundreds of queued data packets.

The fix is Smart Queue Management using the CAKE algorithm. CAKE shapes traffic on the router side, keeping the outbound rate just below the link capacity so the ISP's buffer never fills.

/queue simple add name="queue-lte" target="bridge" \

    max-limit=45M/80M queue=cake-default/cake-default

The limits (45 Mbps up, 80 Mbps down) are set to 90-95% of measured capacity. Setting them at 100% defeats the purpose since the ISP's buffer would still fill.

Layer 4: Transmit power

Wi-Fi is bidirectional. The router might transmit at 23 dBm, but a laptop radio typically maxes out around 15-17 dBm. If the router's power is too high, it can hear the client but the client struggles to send frames back. This asymmetry causes retransmissions.

Reducing transmit power to 17-20 dBm brought it closer to the client's capability:

/interface wifi set [find name=mrt6] channel.tx-power=17

Layer 5: Channel width

Wider channels (80 MHz, 160 MHz) offer higher throughput but collect more noise. In a residential environment with neighboring access points, a 40 MHz channel is often more reliable than an 80 MHz one. The throughput ceiling drops, but the error rate drops further.

/interface wifi set [find name=mrt6] channel.width=20/40mhz

Layer 6: macOS AWDL

Apple Wireless Direct Link (awdl0) is the interface macOS uses for AirDrop and AirPlay discovery. It periodically forces the Wi-Fi radio to hop to a social channel for peer discovery, causing latency spikes of 50-200 ms even when AirDrop is not in active use.

Disabling it removes the spikes:

sudo ifconfig awdl0 down

This disables AirDrop. It re-enables on reboot.

Layer 7: LTE MTU and MSS clamping

LTE links often have a lower MTU than the standard 1500 bytes due to GTP tunneling overhead. When a TCP segment exceeds the path MTU, it gets fragmented or dropped. If the Don't Fragment bit is set (common with modern TCP), the packet is dropped and the sender must retransmit at a smaller size after receiving an ICMP "Fragmentation Needed" message. Some networks filter ICMP, breaking this discovery process entirely.

MSS clamping rewrites the TCP Maximum Segment Size during the handshake so segments are sized correctly from the start:

/ip firewall mangle add chain=forward action=change-mss \

    new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn

Summary

After all seven layers:

Responsiveness: High (420 RPM)

Idle Latency: 28 ms
Layer Problem Fix
1. Physical DFS radar pauses Channel 36 (non-DFS)
2. Protocol Apple FT-over-DS stalls Disable FT-over-DS, enforce PMF
3. Traffic LTE bufferbloat (700 ms) CAKE queue at 90-95% capacity
4. Power Tx/Rx asymmetry Reduce to 17-20 dBm
5. Width Noise on wide channels 40 MHz instead of 80/160
6. macOS AWDL channel hopping Disable awdl0
7. WAN MTU/fragmentation MSS clamping

The first three layers had the largest impact. Layers 4-7 were incremental improvements that reduced tail latency and retransmissions. The total debugging took an afternoon; most of it was spent on layer 3, understanding why a fast connection felt slow.