L009 Arm64 working perfectly.
(ehm... Work or not?)
At this point it could be the name of some interface that influences the result,
maybe some character outside of ascii-7 or some unicode character that ruins everything...
EDIT: not
Why are you doing this?
It never even occurred to me to question what you wrote.
Unless I misunderstood what you meant, and I apologize in advance.
Because you wondered about whether some interface names might be the cause, so I reset a CHR to default configuration so that the interfaces names are only ether1-4 and lo 
Sorry, I really need a bit of a vacation, but here I am in tourist places,
in winter there is no dog,
in summer they overwhelm you as soon as you leave the office...
Apple devices work fine for me with FT enabled on the ax3
You need to be more precise... did you also enable FT over DS?
Because the issue with Apple devices is precisely with FT and DS.
Whit this:
https://download.mikrotik.com/routeros/7.24/chr-7.24.vmdk.zip
I obtain this:
Is on WinBox 3.43... work as expected...
and also on vmware termial..
Subject: DHCP Snooping regression in RouterOS 7.24 with Wi-Fi repeater
Hello,
After upgrading RB5009UG+S+ from RouterOS 7.23.x to 7.24 stable, DHCP Snooping causes a TP-Link Archer C5 v4 working in Repeater Mode to fail DHCP lease acquisition/renewal.
With
dhcp-snooping=yes, the DHCP server receives the request and assigns192.168.31.5, but the repeater does not receive/process the DHCP ACK and retries every ~20 seconds:
assigned → deassigned → assigned → deassignedThe client has different DHCP and Ethernet source MAC addresses:
DHCP MAC / Client-ID: AC:84:C6:64:F7:4C
src-mac-address: AE:84:C6:64:F7:4ESetting DHCP Server
use-src-mac=yesdoes not fix the issue.With
dhcp-snooping=no, DHCP immediately works correctly, the repeater receives the ACK, obtains192.168.31.5/23, and stops retrying. The problem also reappears during DHCP lease renewal when snooping is enabled.This setup worked before upgrading to RouterOS 7.24.
Router: RB5009UG+S+
RouterOS: 7.24 stable
DHCP lease time: 15m
Bridge VLAN filtering: enabled
DHCP Snooping: enabled
Affected port: untrustedPlease check for a DHCP Snooping regression in RouterOS 7.24, possibly related to DHCP
chaddrdiffering from the Ethernet source MAC.===
ADD:
Item: bridge – fixed stability issue when using DHCPv4 snooping.It breaks the proper operation of the repeater/relay and blocks the access point from functioning correctly.
If I disable DHCP snooping on the bridge in version 7.24, or roll back to version 7.23.3 (even with DHCP snooping enabled), the problem goes away and everything works correctly.
Вы отправили это или просто перевели?
Maybe they notice it here, but better send an email to support@mikrotik.com
Отправил в техподдержку
I did more tests and it does depend on the package installed! For the following tests, every time a package has been added / removed, a full Reset Configuration with No Default Configuration is performed:
Back to only base package -> BUG GONE!
Note: This screenshot also has the VM details. It's running under Hyper-V.
My RB5009 has these packages, can you try enabling container on yours?
I just updated RB5009, everything works correctly, including Vlan, no problems observed
I'm out of the office now, but I'm glad my insistence on list installed or not installed packages finally paid off...
Thank you @CGGXANNX!!!
If is needed, I test it tomorrow.
Issue on hap be lite:
- I see unexpected device reboots due to kernel error.
- Wlan throughput seems to have decreased compared to 7.24rc3 and rc4: significantly less throughput with iperf3 on local network - about 400-500mbit/s, compared to ~800mbit/s in the rc versions. No config changes have been done.
Everything went fine on my hap ax2.
FT enabled works, FToverDS doesnt with apple devices.
And folks complain AI makes up stuff...
On D53G-5HacD2HnD (arm) with routeros,container,netinstall the issue is not reproducible. Is this an isolated arm64 container package issue?