@TheKaban 

 

Sorry, I could have included more detail. 

 

When i was setting up my EAP225, I was setting up 1 VLAN, but it wouldn't get an IP address from the DHCP server. 

 

Here's what they said: 

 

"Now I know that in your network, the EAP is connected to port 9 of the switch, and the router is connected t port 15 of the switch. You have created VLAN1 and VLAN 100 on your switch. But when you try to enable VLAN200 on the SSID, you find the clients cannot get the IP address.
I have known your network topology from the old emails. For your issue, here are some suggestions for you.
Please make sure that the firmware of your EAP is Build 20190404 because we change the mechanism of the VLAN in later firmware.
Then we recommend you to set the port 9 (which is connected to the EAP) as untagged. After that, when you enable wireless VLAN on the EAP, the client devices should be able to work normally." 

 

So a few things jump out at me. This firmware is a few versions old. Why doesn't the newer firmware work right? 

And second, in this case, port 9 should have been tagged, not untagged, since it was carrying the VLANs. 

 

Regardless, it didn't solve my problem. Using the newest firmware and having the port tagged did. 

Just trying to learn. 

 

CoKro wrote

So a few things jump out at me. This firmware is a few versions old. Why doesn't the newer firmware work right? 

And second, in this case, port 9 should have been tagged, not untagged, since it was carrying the VLANs. 

 

Regardless, it didn't solve my problem. Using the newest firmware and having the port tagged did. 

 

Hello CoKro,

 

I can not speak for the support of TP-Link, but I can tell you that I would also recommend to roll back to an older version of EAP firmware if you did set up a VLAN which is incompatible with Multi-SSID VLANs and can't change the setup for any reason.

 

First, there is no such thing as a »wrong VLAN setup«, so please don't get me wrong here. You can do anything you like with VLANs, it's just an universal mechanism.

 

But there are VLAN setups which can not work with VLAN-tagged Multi-SSID setups. Multi-SSIDs are nothing exceptionally here; the same VLAN setups can't even work with VLAN-aware servers where software services are listening to one VLAN only. So it's not related to SSIDs. It's related to software VLANs.

 

Software VLANs such as used in APs behave not like switch ports do. A switch port can be assigned membership of several VLANs at the same time and it can be tagged or untagged member, while a single software VLAN interface such as used for a VLAN SSID can be only a member of exactly one VLAN (then its frames are tagged) or be no VLAN member at all (then frames are untagged).

 

The EAP itself can also be a member of exactly one VLAN (then its frames are tagged) or it can belong to no VLAN at all (then its frames are untagged).

 

You even can use any combination thereof:

• EAP itself in VLAN x & SSID in VLAN y
• or: EAP no VLAN & SSID VLAN y
• or: EAP VLAN x & SSID no VLAN
• or: EAP no VLAN & SSID no VLAN.

 

Next, you should understand that inside a VLAN network there is no untagged traffic at all. Every untagged frame from any device such as a laptop, a PC, a server and even a router will get tagged on entry into a VLAN network and becomes untagged on exit.

 

On ingress into a VLAN this tagging is done either by software (e.g. for VLAN-aware routers and servers) according to the interface used for sending data or by the switch (e.g. for VLAN-unaware devices such as laptops, PCs) according to the Port VLAN ID (PVID) of the switch's port used for receiving data.

 

On egress from a VLAN the tag will be removed again either by the switch (for VLAN-unaware devices) when sending data or by the software handling the interface of the device itself (for VLAN-aware devices) when receiving data.

 

Thus, the VLAN will start somewhere and it will be terminated somewhere. Inside the whole VLAN network, untagged frames just do not exist.

 

The only question is: where starts the VLAN and where ends it?

 

Let's assume you have an EAP, a switch and a non-VLAN-aware router with one network only and one DHCP server assigning IP addresses:

 

• You connect the router to port 9 of your switch and set its PVID=1. Port 9 is untagged member of VLANs 1 and 100.
   
• You connect an EAP to port 15, PVID=1, which is untagged member of VLAN 1 and tagged member of VLAN 100.
   
• A single SSID on this EAP is assigned a tagged member of VLAN 100.

 

This setup causes:
 

• VLAN 1 spanning only switch ports 9 to 15 of the switch. It starts at port 9 and is terminated at port 15 of the switch.
  
  Traffic from the router is untagged, enters the VLAN, gets tagged VID 1, forwarded to port 15, VLAN terminated, tag removed and finally reaches the EAP itself (not the SSID!). Answers from the EAP itself take the same path in reverse order.
   
• VLAN 100 spanning switch port 9 over port 15 up to the EAP's SSID. It starts at port 9 as well, but now is terminated in the SSID (to be precise: in the virtual Ethernet interface bridged with the virtual radio interface for this SSID).
  
  Traffic from a wireless client using the SSID is untagged, enters the VLAN when received by the EAP, gets tagged VID 100, sent to switch port 15, forwarded to port 9, VLAN terminated, tag removed and finally reaches the router. So far, so good.
  
  But now the answer from the router is untagged, enters the VLAN, gets tagged VID 1, forwarded to port 15, VLAN terminated, tag removed and finally reaches the EAP itself instead of the SSID. Bummer!

 

The behavior that an EAP gets an IP assigned by DHCP, but clients don't get one is the consequence of using an asymmetric VLAN (VLAN 100 for traffic from the SSID to the router, VLAN 1 for traffic from the router to the SSID) – this can't work with VLAN-tagged Multi-SSIDs!

 

Now, why did it work before firmware 2.6.0?

 

The bug in older firmware versions was that traffic from VLAN 1 (in the above setup) did leak into SSID VLAN 100, thus reaching wireless clients connected to this SSID. This behavior is wrong and it has been fixed in V2.6.0.

 

While this bug allowed use of asymmetric VLANs accidently, it nevertheless interferes with regular VLAN usage for isolating wireless clients from the rest of the network as it exposes parts of the network which should be isolated.

 

I hope this helps to understand what happened in old firmware versions.