Using Radius-assigned VLAN in Radius-powered PPSK setup, I also observed the same phenomenom when a WiFi client tries to connect to VLAN1 when this VLAN is also the mangement VLAN:

- DHCP DISCOVER is sent by client in appropriate VLAN (ie VLAN1)

- DHCP OFFER is replied  within VLAN1

- no DHCP REQUEST ever comes in as if either OFFER or REQUEST was discarded by AP.

It seems using default VLAN1 "collides" with Radius-assigned VLAN either with 802.1X or PPSK.

In my case, VLAN 1 was not tagged and I faced exactly the same symptom. I changed my switch to tag everything, even the port VLAN, on the port towards the Omada EAP. Now it works. Does that help in your case as well? I think this is a bug in the Dynamic VLAN handling of Omada EAPs because I never experienced that with any other brand. However, I am not aware of any IETF RFC which mandates this. Anyone?

  @CISTORop 

In my testings, VLAN1 was also untagged.

I also never met any other vendor device requiring VLAN1 to be explicitely tagged.

  @Oliv2831 were you able to test my workaround as well already. If that worked, we are talking about the same issue for sure and the issue is confirmed because two people face it. Consequently, TP-Link could create a bug report internally.

  @CISTORop 

I'll do my best to test anew within the next couple of days, this issue.