Discovery Utility not discovering any devices

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Discovery Utility not discovering any devices

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Discovery Utility not discovering any devices
Discovery Utility not discovering any devices
2022-06-17 23:12:55 - last edited 2022-06-17 23:15:53
Model: ER605 (TL-R605)  
Hardware Version: V1
Firmware Version: 1.2.0 Build 20220114

My first attempt at following FAQ 2814 (Management VLAN) was a failure.

I locked my self out with an ACL and I had to reset everything.

Since I didn't have a backup, it was a bit painful.

I'd like to try this again but this time I'm proceeding carefully...

 

Since one of the steps require the use of the discovery utility, I thought I'd give it a shot PRIOR to moving devices into the MGMT VLAN.

The utility starts fine but I have yet to see it discover anything...

 

The log shows the following:

2022-06-17 15:41:45.053  INFO 8036 --- [main] c.t.u.d.DiscoveryUtilityApplication      : Starting DiscoveryUtilityApplication using Java 1.8.0_333 on <MYMACHINE> with PID 8036 (C:\Omada\Discovery\omada-discovery-utility-5.0.8.jar started by <ME> in C:\Omada\Discovery)
2022-06-17 15:41:45.070  INFO 8036 --- [main] c.t.u.d.DiscoveryUtilityApplication      : No active profile set, falling back to default profiles: default
2022-06-17 15:41:46.831  INFO 8036 --- [main] com.tplink.smb.ecsp.server.context.c     : start schedule remove expire device... period = 10
2022-06-17 15:41:47.237  INFO 8036 --- [main] c.t.u.d.DiscoveryUtilityApplication      : Started DiscoveryUtilityApplication in 2.876 seconds (JVM running for 3.596)
2022-06-17 15:41:47.250  WARN 8036 --- [main] c.t.utility.common.omadac.OmadacType     : Failed to load omada.properties

It's only a warning so maybe that's no big deal.

I've let the utility run for a while. Nothing.

I've let Java through the FW, and even disabled the FW for another attempt. Nothing.

 

The machine I'm running the utility on is a Windows 10 21H2 machine connected directly to the router.

It belongs to the same subnet as all the tp-link devices (OC200, couple 2008 switches, EAP245).

   Connection-specific DNS Suffix  . : lan.home
   Link-local IPv6 Address . . . . . : fe80::f04d:b21b:efa3:51d4%10
   IPv4 Address. . . . . . . . . . . : 10.1.1.123
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.1.1.1

All of my other clients are in separate VLANs.

 

Unless adopted devices are no longer "discoverable" (which I'm not aware of), I'm at a loss...

  0      
  0      
#1
Options
4 Reply
Re:Discovery Utility not discovering any devices
2022-06-18 09:14:59

  @EricPerl 

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

  0  
  0  
#2
Options
Re:Discovery Utility not discovering any devices
2022-06-18 17:53:07

@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).

  0  
  0  
#3
Options
Re:Discovery Utility not discovering any devices
2022-06-20 11:00:50

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)

  0  
  0  
#4
Options
Re:Discovery Utility not discovering any devices
2022-06-20 22:02:55

@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).

  0  
  0  
#5
Options