Vincent-TP wrote

  @relvy 

To understand the issue better, please give us the following info:

1.  A screenshot of the Device page of your controller so we would know the models, versions of the Omada devices you are using;

2. the screenshots of the config page mentioned in the FAQ;

3. What IP address will the wireless clients get?

4. Are you using an external Radius server?

5. the topology of the network.

 

You may have a look on the following guide to configure it with the controller built-in Radius server:

How to Configure Dynamic VLAN with the Built-in RADIUS Server of Omada SDN Controller via User Auth?

Screenshot of my devices:

2. Screenshot of radius config page:

3. DHCP Address depending on the VLAN assigned to them.

4. Yes, Freeradius configured to do EAP-TTLS+PAP.

5. Topology

Vincent-TP wrote

Hi  @relvy 

 

Thanks for the reply.

 

3. DHCP Address depending on the VLAN assigned to them.

>>> Since the devices are receiving IP addresses from the correct VLAN, when you mention the wireless clients "aren’t working," do you specifically mean: They cannot access the internet?

 

 

Please have a look on the note for Enable VLAN Assignment for Wireless Network:

 

 

1. Your controller OC300 is working with a firmware from 2023, which is really old. Please update the controller to the latest one;

2. Do you configure Portal with RADIUS for the wireless network?

 

  @Vincent-TP 

3. DHCP Address depending on the VLAN assigned to them.

>>> Since the devices are receiving IP addresses from the correct VLAN, when you mention the wireless clients "aren’t working," do you specifically mean: They cannot access the internet?

The wired clients do get DHCP address from the correct VLAN after successful dot1x authentication.
The wireless clients do not get assigned to a VLAN. I see no DHCP traffic.

I see the EAP does receive the Access-Accept packet with all attributes for dynamic VLAN assignment.

1. Your controller OC300 is working with a firmware from 2023, which is really old. Please update the controller to the latest one;

The button "Check for Upgrade" gives


So I will do manual update.
For EU latest english firmware
https://static.tp-link.com/upload/firmware/2025/202504/20250401/OC300(UN)_v1_1.29.5%20Build%2020250325.zip

should be good?

2. Do you configure Portal with RADIUS for the wireless network?

No, I don't.
 

  @Vincent-TP 

OC300 manual update successful:

Now the "Check for Upgrade" works, too.

Unfortunately, the OC300 update does not have any effect on the dynamic VLAN settings on EAP.
The problem remains.

  @Vincent-TP 

> What's the profile of the LAG port on the switch configured, is it the default profile ALL? 

That LAG is on port 3 and port 4. It has the default profile ALL.

The ALL profile has the system vlan 1 as native untagged network.
All other VLAN networks are tagged.

> Did you create corresponding VLAN SSIDs for the EAP?? 

I created one SSID with WPA-Enterprise and radius for all VLANs.

The mobile client is supposed to land in the corresponding VLAN as told by radius access-accept packet.

From mobile client perspective the EAP behaves as it would get an access-reject and never tells the client.
In reality the EAP receives an access-accept packet and it appears to throw the packet away.
 

> Did the config work correctly before? or never worked?

It never worked before. It is a complete new setup.
 

For the wired clients I also use the default ALL profile with 802.1x enabled ports.
After successful authentication the switch assigns the correct VLAN as native untagged network on that port.

For wired clients I increased the radius timeout value from 5 to 9 and retransmit value from 2 to 3 via device CLI.
With this I get this behaviour:

switch -> radius: access-request id 53
switch -> radius: access-request id 53
radius -> switch: access-accept id 53
The switch puts the port into state authorized with correct VLAN.

Without this I had this behaviour:

switch -> radius: access-request id 53
switch -> radius: access-request id 54
radius -> switch: access-reject id 53
radius -> switch: access-accept id 54

The switch rejected the client and ignored the access-accept.

I had to do that with device CLI because I could not do that elsewhere. It would be nice to be able to do that in the radius profile settings.
I cannot do this for the EAP directly (no CLI support) but it appears the EAP works together with the switch to get the same result with EAP.
 

  @GRL 

> Port Based will lock a switch port to the vlan of the first authenticated client and set the vlan as untagged on that port, regardless of what else is downstream of that port.  I think you need MAC based.

The ports where the wired clients get connected to have 802.1x enabled.

The ports where the EAP and Servers are connected to do not have 802.1x enabled.