Hi @CISTORop,

EAPs support multicast to unicast, please keep your all devices' firmware are the latest.

Hi @CISTORop 

Thanks for posting in our business forum.

CISTORop wrote

If there is another support channel, I should go for, please, say so. Learning how to deal with feature requests but also bug reports from the ‘field’, reported by users, could be the unique selling point for Omada series. As of today, I am still not sure whether my other thread was transformed into a bug report internally at all. If it was, which status does that have now, and which Omada models are consider to be fixed. I went for the latest Omada SDN controller 5.13.30.8, reset my devices to factory and re-adopted them, did not help. Such re-tests take time, making Omada more expensive than it should be. Then, I re-visited the thread about early-access firmware. For the EAP650, EAP655, and EAP670, it states, ‘Fixed abnormal IPv6 address acquisition for clients when enables Dynamic VLAN’. Again, I am just guessing, but that might relate to my bug report. Therefore, I went for a (not mentioned) EAP653. Not sure, why that model was not mentioned. And I am not sure why this bug fix was not found in the official release notes. Again failures, failures. But indeed, without fiddling around with the Multicast/Broadcast settings in the controller, the behavior of the EAP653 was different; IPv6 RAs from my router do not leak across VLANs. But in my last thread, IPv6 was just one example!

 

mDNS still leaks. Furthermore, I tested more than one Wi-Fi client connected to the same access point: All multicast/broadcast messages from one Wi-Fi client, although in a different VLANs, are sent to all other Wi-Fi clients. Again, I monitored via Wireshark: The client sends broadcast messages via PMK, and the access point re-sends them via GTK. Consequently, Omada does not isolate the different VLANs. The latter could be worked around with Client Isolation or, as TP-Link called it, ‘SSID isolation,’ enabled on each access point. However, that is just a workaround because then members of the same VLAN cannot talk to each other either. Furthermore, TP-Link enhanced that feature into Guest Network, blocking Wi-Fi clients from private IP addresses, too. But I do not need/want that.

 

Long story short, RADIUS dynamic VLAN is still broken in the world of Omada. For example, a bad Wi-Fi client in a guest network is able to send IPv6 RAs himself, tearing down IPv6 connectivity for all Wi-Fi clients, even those in different VLANs. Consequently, the team who added Dynamic VLAN did neither implement nor test correctly. Consequently, the one who tackled my bug report just focused on the example and did not understand the broader picture. I am not sure, whether giving that team this bug report again would be a good idea. Again, the solution is quite easy as you just have to monitor Wi-Fi on the air layer with the help of the PMK, and then copy the behavior of Cisco, UniFi, or MikroTik.

Since my associate left, I have taken over this temporarily and I am new to this issue. There was an email forwarded to me about your issue.

As instructed, here's the download link I need to share with you and you can take a look.

EAP245_v3.0_5.1.90_build20240305_rel60554

Let me know if this resolves your issue or not.

Hi @CISTORop 

Thanks for posting in our business forum.

CISTORop wrote

With the new firmware 5.1.90, behaves like EAP653 now: IPv6 does not leak. Multicast/Broadcast originating at the Wi-Fi client like mDNS and DHCP leak.

mDNS and DHCP are expected. The firmware has fixed the reported issue and the other aspects you proposed do not compose an issue.

mDNS packets will influence the Apple Bonjour Service, as a result, someone using Airprint ® or screen sharing would not be able to use them after we stop the mDNS transition in different VLANs.

Hi @CISTORop

CISTORop wrote

I don't know what I shall say. How do you come to that conclusion? Again, DHCP is just an example. The whole concept of how to deal with multicast/broadcast (from client devices and from the router) in case of dynamically assigned VLANs is broken. GTK is misused currently. Each VLAN must be isolated. The current situation creates the wildest issues, explained in the source cited in my previous thread, years ago. Therefore, I invite @MikeSchnagli @StevieDuk @Nitin-Lohchab @pokhui @TomasAAA @Christian2705 @bky @Oliv2831 @MatthiasL22 @Holl595 @Yttra @sonaric @MR.S @mtl_squirrel because they reported to use Dynamic VLAN Assignment. @4uba @Eguliker @Ofloo @mobb @NickyV @0llli @mtpi @maresu @bolhaskutya @Kamal9 intended to use Dynamic VLAN Assignment. Hopefully, you are still with Omada, using Dynamic VLAN, and noticed my reported issue. Perhaps you can explain/convince TP-Link, which I cannot.

 

@BrnM

• EAP653 V1 1.0.12 Build 20240131
• EAP620 V1 1.1.0 Build 20230303
• EAP245 V3 5.1.90 Build 20240305

Do you have a newer release on your EAP653?

Your last reply about mDNS and DHCP was read by the dev and it is not something useful and fruitful.

If you want to continue this conversation with me, please show the test method, topology of your test environment and Wireshark result.

I will check if is expected or not and if it is logical and will get the dev to read through your test methodology as well.

So far, you just say mDNS does not make sense. DHCP is leaking, how do you test it out? DHCP's first query is broadcasting. Do you think the broadcast is leaking? I don't think this will be a dialectic and logical way to discuss.

I only take concrete evidence and a dialectic way to illustrate an issue. Please, please reply with some other concrete information as we go further into this conversation.