@EricPerl 

Did you set the DHCP server on the subnet and set option 138 to the ip of the controller (normally in hex : format)

@farmer1 

My understanding of option 138 is that it is populated with the IP of the controller so that Omada SDN aware devices know where to send the messages bootstrapping adoption.

It's especially useful when such device is not in the same subnet as the controller because broadcasting (the alternative to option 138) won't work.

In the state where I'm testing the Discovery Utility now, all Omada SDN aware devices (ER605, 2x SG2008, EAP245) are in the same subnet as the OC200 controller so broadcasting worked and I have not needed to use option 138. All devices are currently adopted.

It's also my understanding that the Discovery Utility is entirely relying on broadcast messages.

The next lines in the utility log are in fact about opening the ports mentioned in discovery related articles (29810–29813).

I can't paste them here without triggering some external link detection...

Many articles about fixing adoption mention using the utility OR using option 138.

They seem to achieve the same goal differently.

I also don't want to specify that option now because the IP of the controller will change when I enable the management VLAN and that would make the switch more difficult.

This said, as I looked for more material about option 138, I stumbled on this: 

Introduction of eap adoption (tp-link.com)

It's implied but reinforces my guess that adopted devices are no longer sending discovery messages but instead sending keep-alive messages.

That could explain why no devices show up in my current state (all adopted).

Hi  @EricPerl 

You are right, no need to use DHCP 138 option.

But there is a thing you may need to concern, the controller uses port 29810–29814. (not 29810–29813 you mentioned)

You don't have to adopt the devices in one subnet. You can setup VLANs first and put the OC200 into correct VLAN, then on EAP standalone mode->Controller Settings, put in OC200 IP to make it work. (EAP standalone has built-in "discovery utility now)

@Somnus,

I must have copy/pasted that port range from an outdated article.

Per a previous reply (of yours: EAP245 and 225 stuck at "ADOPTING" after power cycle on SDN v5 - Business Community (tp-link.com)), the range has been recently extended to include 29814. The utility log indeed opens that port (and not 29813). Anyway, that's not the problem for me because it's not the FW that's getting in the way since I'm getting the same results even without a firewall.

I was mostly trying to follow the steps from How to configure Management VLAN in Omada SDN Controller (4.4.4 or above)? | TP-Link

Since that FAQ is using the discovery utility, I thought I'd test it prior to moving my devices into the VLAN.

I'm still in that state for now and discovery is not yielding anything.

But again, that could be a misguided attempt if currently adopted devices no longer send the discovery messages (which is kinda implied in the last article of my previous reply).