Confirmed on mipsbe too, and it follows the BUILD DATE, not the version number. Long-term 7.23.x is affected as well.
Device: wAP ac (RBwAPG-5HacT2HnD, mipsbe). netinstall-cli on Debian 12 (kernel 6.1), on the same L2 segment as the device, through a CRS109 bridge. No other BOOTP/DHCP server answering (the router's DHCP has bootp-support=none, and this was
verified with tcpdump).
Symptom (bad builds): the same thing the OP describes, an endless
Received a BOOTP request from xx:xx:xx:xx:xx:xx (mips)
Assigned 192.168.x.127 to xx:xx:xx:xx:xx:xx
and the device never fetches the boot image (no TFTP at all).
What the packet capture shows: the device sends a new BOOTP request with a fresh xid every 200 ms. The bad netinstall-cli builds do answer, but each reply carries the xid of an older request, and the lag grows over time (1, then 2, … then 5+ requests behind). So RouterBOOT discards every reply and keeps asking. The first reply also only appeared ~4 s after the requests started. The replies themselves are well-formed: correct yiaddr/siaddr/chaddr, file "linux.mips". I checked that the
replies leave the switch port toward the device (/tool sniffer on the switch), so nothing in the path drops them.
Versions I ran on the same host, same device, same day:
| netinstall-cli |
embedded build date |
result |
| 7.23.5 |
2026-09-04 06:02 |
works, full install completed |
| 7.23.7 |
2026-09-16 12:49 |
BOOTP loop |
| 7.23.8 |
2026-10-08 10:16 |
BOOTP loop |
| 7.24.5 |
2026-09-29 14:51 |
BOOTP loop |
| 6.49.23 |
2026-10-07 16:05 |
boots the device fine |
(The OP's results: 7.24.2 works, 7.24.4 loops.)
Why the date matters more than the version. I extracted the build timestamp embedded in every netinstall-cli binary (the string printed as Version: x.y.z(date)) from the official tarballs. The long-term and stable branches are built in pairs
on the same days:
| build date |
long-term |
stable / testing |
status |
| 2026-09-02 |
|
7.25beta3 |
untested |
| 2026-09-03 |
7.23.4 |
7.24.2 |
7.24.2 works (OP) |
| 2026-09-04 |
7.23.5 |
|
works (me) |
| 2026-09-14 |
7.23.6 |
7.24.3 |
untested |
| 2026-09-16 |
7.23.7 |
7.24.4 |
broken (me + OP) |
| 2026-09-29 |
|
7.24.5 |
broken (me) |
| 2026-10-01 |
|
7.25rc1 |
untested |
| 2026-10-08 |
7.23.8 |
|
broken (me) |
So the regression entered the shared netinstall code between 2026-09-04 and 2026-09-16 (the 09-14 builds 7.23.6/7.24.3 are the open question). Every build since then is affected, on both branches. That also means "use an older version" is
misleading advice. 7.23.7 has a lower version number than 7.24.2 but is broken, because it was built two weeks later. Workaround: pick a netinstall-cli built on or before 2026-09-04 (e.g. 7.23.5 or 7.24.2). An older netinstall-cli installs
newer .npk files fine. I used 7.23.5 to install 7.23.7 packages.
One more observation, possibly related: on the same LAN, the working 7.23.5 build logged
Could not determine architecture for BOOTP request from <another non-MikroTik device>
and carried on. Something else on this network sends BOOTP requests. The broken builds didn't print that line in the output I captured. Maybe the new code handles a foreign BOOTP request badly, and that slows down or desynchronises the reply path?
That would explain why it works for some people and not others. This is a guess. I haven't tested a broken build with that device removed.
Separate issue, for anyone else on Realtek: with an RTL8168h (r8169 driver) the transfer later stalled at "Sending package…" right after the first ~1 KB UDP chunk. ethtool -K <if> tx off (disable TX checksum offload) fixed that.
