[Bug Report] - Mikrotik ATL 5G R16 - Router 5G

RouterOS General
1

Hi everyone,

I'd like to report what I believe is a firmware bug in the MikroTik Chateau ATL 5G (R16) when operating in Passthrough mode. The antenna refuses to assign an IP (or forward internet traffic) to a new device with a different MAC address after switching the Ethernet cable, even though the previous device has been physically disconnected.

Equipment

  • Antenna: ATL 5G R16 (Passthrough)

  • Router: ASUS GT-AX6000

  • PC: Windows 11, ASIX USB Gigabit Ethernet adapter

  • ISP: Fastweb (Italy), 5G FWA

  • WAN IP: 10.2… — Gateway: 10.2...

  • DHCP Lease Time: 60 seconds (confirmed from router syslog: dhcp client: bound 10..../255.255.255.248 via 10.2.... for 60 seconds)

Problem Description

When Passthrough mode is enabled, the antenna forwards the WAN IP to a single downstream device. The problem is: when I physically disconnect the Ethernet cable from device A and connect it to device B (different MAC), device B cannot get internet — even after the 60-second lease should have expired. The antenna does not release the DHCP binding upon detecting link-down on the Ethernet port.

A full reboot of the antenna immediately resolves the issue, confirming the problem is in the antenna's internal state, not on the ISP side.

Reproducible Test Cases

Test Case 1: Router → PC → Router

  1. ASUS router connected to antenna via Ethernet — internet working for 1 week

  2. Disconnect cable from router, connect to PC — PC gets internet :white_check_mark: (lease had expired)

  3. After 1 minute, disconnect cable from PC, reconnect to router — Router does NOT get internet :cross_mark:

Test Case 2: Router → Router → PC

  1. ASUS router connected to antenna — internet working

  2. Disconnect cable, reconnect to same router after 1 minute — Router works :white_check_mark: (same MAC, lease renewed)

  3. After 1 minute, disconnect cable from router, connect to PC — PC does NOT get internet :cross_mark:

  4. After 1 minute, disconnect cable from PC, reconnect to router — Router works :white_check_mark:

Pattern

The first different MAC that connects after a long pause (expired lease) works fine. But any subsequent MAC change within the lease window is blocked. Reconnecting the same MAC always works. This clearly points to the DHCP binding being locked to a specific MAC address.

Diagnostic Tests Performed

To isolate the exact cause, I performed the following diagnostic tests:

Test A: Wireshark capture during blocked state

Setup: Router was connected and working. Cable moved to PC. Wireshark running on PC in promiscuous mode.

Result: Packets from the internet were arriving on the cable, but ALL were addressed to the router's MAC (bc:f....), not the PC's MAC.

Conclusion: The antenna was still forwarding traffic to the old MAC. However, packets were physically arriving (not blocked at port level), which rules out 802.1x port security or MAC filtering.

Test B: Static IP test (the decisive test)

Objective: Determine whether the block is at the DHCP level or the ARP/forwarding level.

Setup:

  1. Router connected to antenna, internet working

  2. Disconnect cable from router

  3. Configure PC with static IP before connecting cable:

    • IP: 10.2...

    • Subnet: 255.255.255.248

    • Gateway: 10.2..

    • DNS: 8.8.8.8

  4. Connect cable to PC

  5. Run: ping 10.2...

Result:

Reply from 10.24....: bytes=32 time=2ms TTL=64
Reply from 10.24....: bytes=32 time=1ms TTL=64
Reply from 10.24....: bytes=32 time=1ms TTL=64
Reply from 10.24....: bytes=32 time=1ms TTL=64

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Ping to the gateway works perfectly — the antenna accepts the new MAC at layer 2/3 and responds to ARP/ICMP.

However, internet browsing does NOT work. The antenna pings back locally but does not forward/NAT traffic to the internet for the new MAC.

Conclusion: The ARP cache updates correctly when a new device connects. The block is specifically in the DHCP-to-NAT binding: the antenna only forwards internet traffic for the MAC address that holds the active DHCP lease. A device with the correct IP but a different MAC is allowed local communication but denied internet forwarding.

Summary of Findings

Hypothesis Result Evidence
Port Security / MAC blocking :cross_mark: Ruled out Wireshark shows packets arriving at PC; ping works with static IP
ARP Cache :cross_mark: Ruled out Ping to gateway works immediately with static IP from new MAC
DHCP Lease binding blocks NAT :white_check_mark: Confirmed Static IP allows local ping but NOT internet; antenna only forwards internet for the MAC in the active DHCP binding

Expected Behavior

When the antenna detects a link-down event on the Ethernet port (which it does — confirmed from router syslog showing eth0 Link DOWN), the DHCP binding should be released immediately, allowing a new device to:

  1. Obtain a new DHCP lease

  2. Have its traffic forwarded to the internet

This is standard behavior for bridge/passthrough devices. The current behavior forces users to either:

  • Reboot the antenna every time they switch devices

  • Use MAC cloning as a workaround

  • Wait for an unpredictable amount of time (the 60s lease timeout does not seem to be respected consistently)

Feature Request

Please consider implementing one of the following in a future firmware update:

  1. Auto-release DHCP binding on link-down — When the Ethernet port goes down, flush the DHCP lease and NAT binding for that port, so a new device can connect immediately.

  2. Gratuitous ARP trigger — When a new MAC is detected on the Ethernet port (via Gratuitous ARP), automatically update the DHCP/NAT binding to the new MAC without requiring a new DHCP handshake.

  3. Configurable behavior — Add an option in the Passthrough settings: "Release binding on link-down: yes/no" so users can choose.

Thank you for your attention.

2

That's very detailed test you performed here. Can you open the ticket at Mikrotik support? Because they may or may not see this post. Also you can send them the supout file before and after but.