Two EAP245 (v1 + v3), Omada controller, different behavior
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Hello,
I have two EAP245 APs, one old model v1 (firmware 1.4.0 Build 20180323 Rel. 32551) and one recently bought v3 (2.4.0 Build 20200117 Rel. 39932). Configured using Omada controller 3.2.10. I have two VLANs (and two SSIDs) configured with the ids of 1 and 7.
I have Netgear GS108PEv3 managed switch. I have installed that swich when I added the new AP (v3 one). The switch is also running the latest firmware.
Shortly after configuring everything I have noticed that I could no longer access the Web UI of the switch from my laptop. Odd. I have restarted the switch while moving around with the latop and it's got working again, for a while. This did lead me on the wrong path in my investigation. Long story short, I have finally found that it is not the switch - it depends on which of these two APs I am connected to!
Turned out that if I am connected to the old v1, everything works smoothly, I can access the switch Web UI. Once my laptop jumps to v3, I lose access. Cannot ping the switch, cannot browse it. However, everything else is working fine at the same time, I can connect any device in the network or outside. Any but the switch itself!
Finally I got some time and did the ultimate test. Plugged only v1 AP in the switch, confirmed that I can access the UI and ping the switch. Unplugged v1 AP, plugged v3 one in the SAME port. No access. Again, everything else works, can access any device on the net but that switch. So, I am convinced that it is not the switch, not its configuration. It also cannot be the AP configuration since I manage both via Omada Controller. Also the network is rather simple. Oh, I have also tried to plug my laptop directly in the switch with the cable - I can access the UI of the swich without any issues.
The same behavior is demonstrated by all wireless devices, so it is clearly not the client problem either.
Just to add some details to it. The APs are configured with two SSIDs and two VLANs, 1 and 7. 1 is the main VLAN.
APs receive the IP addresses via DHCP. One is 192.168.8.103, another one is 192.168.8.105. The switch is 192.168.8.104.
Netgear switch port configuration (concentrating on one port - all my last tests were done using that particular port):
- 802.1Q mode is used (not port-based)
- APs are connected to port #1
- port #1 has VLANs 1 and 7 enabled
- on port #1 VLANs 1 and 7 both use tagged mode
- PVID 1 is configured for all ports by default
I am really confused. Given the kind of test I have done, I have eliminated all possibilities except somehing being different in the traffic from EAP245 v3. And thinking about what can be different, the only word that comes to my mind is VLAN. But what is it that can be different by the traffic sent by ONE OF THESE TWO APs that makes it impossible to connect to the UI (so, essentially, IP stack of the switch)?
The only test I have left before I start plugging things into the computer and doing some network dumping is trying the 3rd AP. I have just received E225-outdoor and my plan was to plug it in the same switch and have 3 APs.
unfortunately you did not describe to which VLAN/SSID you connect to when doing the test and what frame types this VLAN uses.
I guess the different behavior comes from a bug in older firmwares, which leaked tagged frames to a SSID not assigned to a VLAN. There were several reports claiming that after this bug was fixed their VLAN network no longer worked as it used to work before the update.
In other words: if your VLAN setup depends on leaking frames from a VLAN to a SSID not assigned to this VLAN, then it won't work with the latest firmwares which did fix this leakage starting with version 2.3.0 of 2019-07-31 for EAP245 V3. From the release notes:
Since EAP245 V1 is not supported anymore, its firmware has not been fixed.
It's just a guess (since your posts lacks important information about the tagging of VLANs and SSID-mapping), but at least you now know a difference in behavior of the two hardware versions.
The above bug fix affects all networks which use untagged and tagged frames on the trunk to the EAP and utilize the »Default VLAN 1« for the purpose to process untagged frames. It does not affect networks which use only tagged frames on a trunk, so a work-around is possible even for EAP245 V1.
if you use a common broadcast domain over more than one VLAN, you probably use an asymmetric VLAN setup.
There is nothing wrong with asymmetric VLAN setups, except that asymmetric VLANs can't work with VLAN-mapped Multi-SSIDs.
The bug in older firmwares was a VLAN leak, which magically made asymmetric VLANs work with VLAN-mapped Multi-SSIDs by accident, but which did screw up VLAN isolation in real (symmetric) VLAN setups with separate broadcast domains. Thus, it had to be fixed to make VLAN isolation work again.
I suggest to either post a network diagram with enough information to be able to help (IPs, switch port VLAN memberships, PVID settings, SSID to VLAN mappings, see diagram below) or to compare your VLAN setup with the setup required for Multi-SSIDs as shown in this diagram of a typical VLAN-mapped Multi-SSID network:
Notes:
- You can use VLAN 1 instead of VLAN 200 for mgmt.
- You can even use untagged ports for the mgmt VLAN, but not for VLAN-mapped SSIDs.
- If you use untagged ports for the mgmt VLAN and want to reach this VLAN from an SSID, the SSID must not be assigned to a VLAN.
- You can use VLAN 10 for mgmt to access it through SSID »Private«, but switch ports 1/0/3-1/0/4 need to be tagged members of VLAN 10.
- You can not use an asymmetric VLAN setup with VLAN-mapped SSIDs.
Just for the record: Laptops running a modern OS can indeed process tagged frames nowadays.
