@TP-Link at least I have issues with the beta firmware using my TLWA1201v2 in the MultiSSID mode. I have tried the following setup using Multi SSID:

Router <-> TP Link Switch <-> TLWA1201 <-> SSID1(VLAN1) + SSID2(VLAN3).

VLAN Trunk is configured between router-switch and switch-TLWA1201. (I have tried to use both tagged and untagged VLAN1 in trunk links, nothing changed, VLAN3 is of course tagged).

Both SSIDs do work better than with the previous firmware, however every hour or so my main connection (SSID1 on VLAN1) drops for an unknown reason and I cannot connect to the AP, unless I reboot it. Additional SSID2 on VLAN3 seems to be stable all the time. Unstable connection with my main wifi (SSID1) prevents me from being able to use the Multi SSID mode therefore I had to switch back to the AP mode, using AP mode my main SSID1 works without issues, but the Multi SSID support was almost the main reason I bought the TLWA1201 and seems to me it is not functional..

Any help? Thanks.

@TP-Link I can confirm applying this beta firmware fixed the issue for me as well.

I'm using a TL-WA1201 v2.0 .

On firmware "TL-WA1201(US)_V2_200709" the SSID using the PVID (native VLAN in Cisco terminology) works without issue.

All other SSIDs with a tagged VLAN intermittantly drop packets when routing to an external subnet.

Pings withing the same subnet did not have any dropped packets.

Regards,

Nato V

@Solla-topee 

Compared to 20200709, something got broken in 210104 beta. The very short version: It's duplicating packets.

I have two SSIDs on 2.4GHz on vlan 1, and one on 5GHz on vlan 1. Nothing else is configured. No special vlan configuration. I am pinging a wifi client from a wired machine.

With 20200709, regardless of which SSID the client is connected to, I see one request go from the wired machine, and one response coming back:

23:10:40.486360 IP 10.5.5.26 > 10.5.5.38: ICMP echo request, id 14, seq 132, length 64
23:10:40.526408 IP 10.5.5.38 > 10.5.5.26: ICMP echo reply, id 14, seq 132, length 64
23:10:41.486703 IP 10.5.5.26 > 10.5.5.38: ICMP echo request, id 14, seq 133, length 64
23:10:41.559674 IP 10.5.5.38 > 10.5.5.26: ICMP echo reply, id 14, seq 133, length 64

With the 210104 beta, when the wifi client is connected to the 5GHz ssid, the result is as above (good). However, if the client is connected to one of the 2.4GHz ssids, there is a duplicate reply:

23:10:48.496491 IP 10.5.5.26 > 10.5.5.38: ICMP echo request, id 14, seq 140, length 64
23:10:48.577083 IP 10.5.5.38 > 10.5.5.26: ICMP echo reply, id 14, seq 140, length 64
23:10:48.577139 IP 10.5.5.38 > 10.5.5.26: ICMP echo reply, id 14, seq 140, length 64
23:10:49.497694 IP 10.5.5.26 > 10.5.5.38: ICMP echo request, id 14, seq 141, length 64
23:10:49.608716 IP 10.5.5.38 > 10.5.5.26: ICMP echo reply, id 14, seq 141, length 64
23:10:49.608770 IP 10.5.5.38 > 10.5.5.26: ICMP echo reply, id 14, seq 141, length 64

If I disable one of the 2.4GHz ssids, the other one works without duplicated packets. If I reenable that other ssid, the duplicate packets resume.

This only happens with the beta.

/Kasper Pedersen

@Solla-topee 

The packet captures were not done by the access point's logging mechanism. The packet captures were done by running tcpdump on the wired machine.

With the access point in the state where it duplicates packets, upload performance is about half (this makes sense, as double upstream ISP bandwidth is consumed). Connections to some things are either extremely slow, intermittent, or do not work. This is what caused me to investigate.

I have now been running

https://static.tp-link.com/beta/2021/202106/20210628/TL-WA1201v2_eu-up-ver1-0-1-P1[20210628-rel55053].zip

for a couple weeks. It still looks good.

(The post with firmware above was updated after the comments below it - this is the first comment on this firmware version)

I have it set up with multiple vlans, and multiple ssids on the same vlan on the same radio.

- Performance in the single-ssid case is back up, and about identical to the current official firmware.

- multiple vlans work and not losing packets.

- the bug in the previous two betas which caused it to duplicate packets with two ssid on the same vlan is gone.

- the AP UI no longer becomes totally unresponsive during load (also a bug in the previous two betas).

I thought it might have a bug with IPv6 ND, but as it turns out, this is a Microsoft Bug(TM). Repeatably, when a windows pc joins work's domain, the ICMPv6 firewall rule that allows the router to query the machine's address gets lost, and though we have been poking at group policy, we have not found the fix yet. The ND packet arrives correctly, Windows at some point just stops answering the router.

@Solla-topee 

Hi,

the newest firmware breaks accessibility of the web gui via the VLANs. Build 20210104 did allow it. Build 20210628 doesn't.

Is that intended and if so what do you suggest so that I gain access to the web gui again?

A little bit of info about our network: We have two different VLANs, one for employees and one for customers. The APs are connected to TL-SG108E switches that have both VLANs tagged on the ports going to the APs. The IPs of the APs are in the network range of the employee network and so far we could access them from the employee network to monitor or change settings. Now not even pinging works.

Best regards.

Edit: So i succumbed to it and added a VLAN 1. The APs with the newest beta firmware will only respond to that. And then I tried upgrading the rest of the APs to the newest firmware and guess what? It tells me that I can't do that from the management network! So I had to walk to every damn AP, connect to one of its SSIDs with my laptop and upgrade the firmware that way.

Something is very broken in the though-process of the engineer who thought it would be a good idea that you can access the AP and do everything with it from one of the SSIDs but if you access the AP from VLAN 1 then you're not allowed to do everything.