@Fae Hi Fae, thanks for replying :-)

Components;

1 x OC200 1.0, 1.9.1 Build 20210721 Rel.39263

1 x TL-SG2428P v1.0, 1.1.2 Build 20210806 Rel.55686

2 x TL-SG2008P v1.0, 1.0.2 Build 20210806 Rel.55686

3 x EAP225(EU) v3.0, 5.0.5 Build 20210604 Rel. 51118

1 x EAP225-Outdoor(EU) v1.0, 5.0.5 Build 20210604 Rel. 51118

5 x TP-LINK AV1000 PowerLine Adapters

No other kit for the network infra (so no Non-Omada kit)

Tried turning everything off, then bringing up the OC200 first, then the main TL-SG2428P which the three EAP225(EU) are connected to, then one of the TL-SG2008P switches. At this point, everything is labeled correctly on the topology diagram.

So, the last TL-SG2008P is connected to the TL-SG2428P switch via TP-LINK PowerLine Adapters, and the EAP225-Outdoor(EU) is also connected to this TL-SG2008P switch. When this is turned on, the link between the switches is misidentified as a uplink on the TL-SG2008P and a downlink on the TL-SG2428P, this should be the other way around. Also the EAP225-Outdoor(EU) shows as not being connected to anything, whereas it should be listed as an uplink connection to the TL-SG2008P switch. (I'm assuming this is also related to the link between the two switches being incorrectly labeled because the switch can have multiple downlink connections, but only one uplink connection ?)

So, the topology diagram looks like this:

Previously, the topoligy diagram was correct, and changed to this incorrect representation when I moved the OC200 controller to a different subnet (using DNS option 138 for discovery). Origionally the OC200 was on the same subnet as all the switches and AP's, hanging off the main TL-SG2428P. The issue with this was when the TL-SG2428P was rebooted for any reason (eg. Firmware upgrade) this would take out the OC200 controller at the same time, so I moved it to a different subnet in order to maintain connectivity when performing upgrades etc.

So it should look something like this:

@Fae Hi Fae, its been two weeks now and I still have had no contact from support on this issue..., any chance you could chase this up ?

Thanks.

Hi there , for me the problem is the same. Can one set manually which port is the uplink?

This has now been investigated by the engineers and traced to a bug/issue that has been fixed in v5.0.15 of the controller.

Looks like this has already been released for PC based controllers, so I'm now just waiting for the OC200 firmware version to confirm.

(and no, you cannot set the uplink/downlink manually)

@Fae Just updated to the Beta for the OC200 OC200v1_un_1.14.1_20211213_rel61873_up and the mapping issue is different, but still not fixed, SW1 and SW3 are still the wrong way around. The uplink/downlink link between SW1 and SW3 should be reversed, i.e. Labeled as an uplink on SW3.

Additionally, clients connected to SW1 via Powerline adapters still do not appear in the client list (and they did previously when the OC200 was on the same subnet as the switches)

I understand this is a BETA release, but wanted to provide some feedback, as it looks like the 'mislabeling of links' bug is still there.

@Fae 

After all the comms with the support team, thet have still failed to correct this issue. The last email I had from them said:

"If the gateway of the network is not Omada Gateway, Omada Controller can not judge which port of which switch is the uplink port, so it will randomly choose a switch as the root switch, which causes this issue. It is difficult to determine from packets only what port is connected to the router, and Omada does not yet support this feature. If the gateway is Omada Gateway, Controller will get correct topology with the help of the information from the gateway."

So, it basically ransomly chooses a switch to be the master !

What is so annoying about this is the second part of the message. It is trivial to work out which port the router is connected to.  Each switch is assigned an IP over DHCP which contains the gateway IP address, in my case 192.168.10.1. This 'client' is connected to SW1 Port 1. The routing tables in SW2 & SW3 will forward all traffic for this gateway to SW1, so SW1 must be the root switch. Whats DIFFICULT about that.

I've had no response back from support for two weeks, very poor.