Recently I was troubleshooting a hotspot client who had issues accessing the internet because he had to many devices already hotspot active.

The client assured me that this could not be true since he doesn't own more devices than the Shared Users limit allows. After looking into it in detail I found that his Windows machine, which could not access the internet, was already hotspot active, but with the Microsoft fallback IP address 169.254.x.x which is invalid. Funny enough the Windows machine had a DHCP lease already with a valid address and only after I deleted the invalid hotspot active entry it was able to access the internet.

I went through all out logs and found that there are a few dozen hosts which face this issue every day.

Did anyone face this issue before?
Is there any explanation how the hotspot learns this address since I don't see how a host can talk with the firewall without a valid IP address in the first place?

We use MAC Cookies as authentication method.

Not an answer, just nit-picking: these addresses are not "Microsoft Fallback Addresses", they are RFC 3927 link-local addresses, also known as "automatic private IP addressing (APIPA)".

But yes, it serms they're best known from windows machines without proper IP addresses.

Not an answer, just nit-picking: these addresses are not "Microsoft Fallback Addresses", they are RFC 3927 link-local addresses, also known as "automatic private IP addressing (APIPA)".

But yes, it serms they're best known from windows machines without proper IP addresses.

I believe that the issue could be due to Windows doing some broadcast/multicast with the 169.254.x.x before obtaining a dhcp address. MikroTik receives the packet and because of MAC Cookie activates the client. Any thoughts?

I believe that the issue could be due to Windows doing some broadcast/multicast with the 169.254.x.x before obtaining a dhcp address. MikroTik receives the packet and because of MAC Cookie activates the client. Any thoughts?

I've found that lowering the idle timeout helps mitigate the issue since the invalid IPs are flushed from the table quickly.
Otherwise there would need to be a way to drop these packets before they are processed by hotspot.
I've seen that there is HOTSPOT-IN at prerouting (Packet Flow diagram), however no drop action.