[Help]: Omada Conrtoller docker in bridge mode possible missing port mapping

[pixielark]

Controller Version

v5.15.20.16

Describe Your Issue or Question

few days ago after upgrade to the latest controller version v5.15.20.16, my old Omada switch T1500G-10MPS v2.0 wont adopt correctly, I thought the switch turns bad or Omada dropped the support on it since its at EOL for a long time, so I purchased a new TL-SX3008F and then realized that the new switch wont be adopted as well, so I started to dig on my docker container

current container running with these ENV and port mapped correctly

      - MANAGE_HTTP_PORT=8088
      - MANAGE_HTTPS_PORT=8043
      - PORTAL_HTTP_PORT=8088
      - PORTAL_HTTPS_PORT=8843
      - PORT_APP_DISCOVERY=27001
      - PORT_ADOPT_V1=29812
      - PORT_UPGRADE_V1=29813
      - PORT_MANAGER_V1=29811
      - PORT_MANAGER_V2=29814
      - PORT_DISCOVERY=29810
      - PORT_TRANSFER_V2=29815
      - PORT_RTTY=29816

log shows

03-25-2025 17:26:10.732 INFO [main] [] c.t.s.o.d.g.a(): discovery Port is 29810.

03-25-2025 17:26:10.732 INFO [main] [] c.t.s.o.d.g.a(): manage    port v1 is 29811.

03-25-2025 17:26:10.732 INFO [main] [] c.t.s.o.d.g.a(): manage    port v2 is 29814.

03-25-2025 17:26:10.732 INFO [main] [] c.t.s.o.d.g.a(): adopt     port v1 is 29812.

03-25-2025 17:26:10.732 INFO [main] [] c.t.s.o.d.g.a(): upgrade   port is 29813.

03-25-2025 17:26:10.732 INFO [main] [] c.t.s.o.d.g.a(): transfer  port is 29815.

03-25-2025 17:26:10.732 INFO [main] [] c.t.s.o.d.g.a(): rtty port is 29816.

but adopt failed after 3 retries

03-25-2025 17:27:43.116 INFO [discovery-work-group-1] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:29:04.227 INFO [discovery-work-group-0] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:30:25.347 INFO [discovery-work-group-1] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:31:46.465 INFO [discovery-work-group-0] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:33:07.575 INFO [discovery-work-group-1] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

until then I switched my docker to use host mode instead of bridge, both switch can now be adopted correctly

03-25-2025 17:35:03.423 INFO [adopt-work-group-0] [] c.t.s.o.m.d.d.m.d.d.s(): Switch OmadacId(437e095bad7338f554b440ab7308705a) SiteId(678f59562b474b7d0df331a0) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) adopt[auto=false] ok

03-25-2025 17:35:03.435 INFO [adopt-work-group-0] [] c.t.s.o.m.d.d.m.d.d.s(): Init Osw DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) with omadac OmadacId(437e095bad7338f554b440ab7308705a) on site SiteId(678f59562b474b7d0df331a0).

03-25-2025 17:35:03.436 INFO [manage-work-group-14] [] c.t.s.o.m.d.a.u.f.b.c(): receive adopt success event for TargetFirmwareOnDeviceAdoptSuccessSubscriber: TargetFirmwareEvent(super=AbstractDomainEvent(id=43a7d8991225440da6248cf80c4632c5, createTime=Tue Mar 25 17:35:03 PDT 2025, type=null), omadacId=OmadacId(437e095bad7338f554b440ab7308705a), siteId=SiteId(678f59562b474b7d0df331a0), deviceMac=DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=), compoundModel=T1500G-10MPS v2.0, version=2.0.6, timeStamp=1742949303436)

wonder if anyone run into similar issue and knows what additional port that omada requires now?

Expected Behavior

adoption should work

Steps to Reproduce

as written

How You're Launching the Container

docker run -d \
  --name omada-controller \
  --stop-timeout 60 \
  --restart unless-stopped \
  --ulimit nofile=4096:8192 \
  -p 8088:8088 \
  -p 8043:8043 \
  -p 8843:8843 \
  -p 27001:27001/udp \
  -p 29810:29810/udp \
  -p 29811-29816:29811-29816 \
  -e MANAGE_HTTP_PORT=8088 \
  -e MANAGE_HTTPS_PORT=8043 \
  -e PGID="508" \
  -e PORTAL_HTTP_PORT=8088 \
  -e PORTAL_HTTPS_PORT=8843 \
  -e PORT_ADOPT_V1=29812 \
  -e PORT_APP_DISCOVERY=27001 \
  -e PORT_DISCOVERY=29810 \
  -e PORT_MANAGER_V1=29811 \
  -e PORT_MANAGER_V2=29814 \
  -e PORT_TRANSFER_V2=29815 \
  -e PORT_RTTY=29816 \
  -e PORT_UPGRADE_V1=29813 \
  -e PUID="508" \
  -e SHOW_SERVER_LOGS=true \
  -e SHOW_MONGODB_LOGS=false \
  -e SSL_CERT_NAME="tls.crt" \
  -e SSL_KEY_NAME="tls.key" \
  -e TZ=Etc/UTC \
  -v omada-data:/opt/tplink/EAPController/data \
  -v omada-logs:/opt/tplink/EAPController/logs \
  mbentley/omada-controller:5.15

Container Logs

03-25-2025 17:27:43.116 INFO [discovery-work-group-1] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:29:04.227 INFO [discovery-work-group-0] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:30:25.347 INFO [discovery-work-group-1] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:31:46.465 INFO [discovery-work-group-0] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

03-25-2025 17:33:07.575 INFO [discovery-work-group-1] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

MongoDB Logs

No response

Additional Context

No response

[mbentley]

Hmm, I don't see any additional ports mentioned in either the changelog or the FAQ.

A clean install in a container shows the following:

# netstat -ltnpu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:27217         0.0.0.0:*               LISTEN      -
tcp6       0      0 :::29816                :::*                    LISTEN      -
tcp6       0      0 :::29814                :::*                    LISTEN      -
tcp6       0      0 :::29815                :::*                    LISTEN      -
tcp6       0      0 :::29812                :::*                    LISTEN      -
tcp6       0      0 :::29813                :::*                    LISTEN      -
tcp6       0      0 :::29811                :::*                    LISTEN      -
tcp6       0      0 :::8088                 :::*                    LISTEN      -
tcp6       0      0 :::8043                 :::*                    LISTEN      -
tcp6       0      0 :::9098                 :::*                    LISTEN      -
tcp6       0      0 :::8843                 :::*                    LISTEN      -
udp6       0      0 :::19810                :::*                                -
udp6       0      0 :::27001                :::*                                -
udp6       0      0 :::29810                :::*                                -

If I get rid of all of the known ports, I see it's also listening on these:

# netstat -ltnpu | grep -vE '8088|8043|8843|27001|29810|29811|29812|29813|29814|29815|29816|27217'
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp6       0      0 :::9098                 :::*                    LISTEN      -
udp6       0      0 :::19810                :::*                                -

Checking the startup logs, I see:

03-26-2025 13:06:52.727 INFO [main] [] n.d.b.g.s.s.GrpcServerLifecycle(): gRPC Server started, listening on address: *, port: 9098                                                                                               (1 results) 09:06:57 [33/4575]
03-26-2025 13:07:07.174 INFO [main] [] c.t.s.e.t.a.t.AbstractServer(): Start NettyUdpServer bind /0.0.0.0:19810, export localhost/127.0.0.1:19810

On port 19810, I see a forum post about it: https://community.tp-link.com/en/business/forum/topic/672596. I do not see anything related to 9098 on a quick google. Could you try to add these ports (one at a time to figure out which one it might be):

  -p 9098:9098 \
  -p 19810:19810/udp \

I imagine it might be 19810 on UDP so that might be the first I would try. If it works, I will update the README and examples to address this. Thanks!

[pixielark]

Thanks mbentley

I did try to add UDP 19810 and TCP 9098 but still cannot adopt the switch (my 4 EAP225v3 all adopt just fine though, even prior the port change)

on my bridge docker container when I search for TYxtRIetscfiHMMGkMKhdToEjSHHM= which is encrypted switch MAC address all I get is 1 line of

03-26-2025 15:35:56.609 INFO [discovery-work-group-0] [] c.t.s.o.m.d.d.m.d.a(): OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) receive discovery when adopting, times[3] reach limit, set adopt fail

and thats it

on my host docker I got a bunch of message

03-26-2025 15:43:47.602 INFO [adopt-work-group-0] [] c.t.s.o.m.d.d.m.d.d.s(): Init Osw DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=) with omadac OmadacId(437e095bad7338f554b440ab7308705a) on site SiteId(678f59562b474b7d0df331a0).

03-26-2025 15:43:47.604 INFO [manage-work-group-7] [] c.t.s.o.m.d.a.u.f.b.c(): receive adopt success event for TargetFirmwareOnDeviceAdoptSuccessSubscriber: TargetFirmwareEvent(super=AbstractDomainEvent(id=01628ba699554c91b9bfae1d6a8ffd8c, createTime=Wed Mar 26 15:43:47 PDT 2025, type=null), omadacId=OmadacId(437e095bad7338f554b440ab7308705a), siteId=SiteId(678f59562b474b7d0df331a0), deviceMac=DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=), compoundModel=T1500G-10MPS v2.0, version=2.0.6, timeStamp=1743029027603)

03-26-2025 15:43:47.607 INFO [adopt-work-group-0] [] c.t.s.o.m.d.d.m.a.e(): send empty setting to OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=)

03-26-2025 15:43:57.398 INFO [manage-work-group-0] [] c.t.s.o.m.d.p.t.b(): Device oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM= OmadacId(437e095bad7338f554b440ab7308705a) changed to status CONNECTED, which don't need to handle.

03-26-2025 15:44:02.524 INFO [gateway-dev-inform-pool-8] [] c.t.s.o.m.d.d.m.i.a(): got first inform of OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=)

03-26-2025 15:44:02.540 INFO [manage-work-group-3] [] c.t.s.o.m.d.d.m.i.g(): first inform no need send full config to OmadacId(437e095bad7338f554b440ab7308705a) DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=)

03-26-2025 15:44:07.018 WARN [scheduled-pool-6] [] c.t.s.o.m.d.d.m.s.c.a(): failed to query device sn OmadacDeviceId(omadacId=OmadacId(437e095bad7338f554b440ab7308705a), deviceMac=DeviceMac(oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM=)) result DeviceSnInfoDTO(sn=null, mac=AC84C6BFF0FC, errorCode=-20530)

03-26-2025 15:44:44.878 INFO [client-inform-work-group-13] [] c.t.s.o.c.p.e.d(): Switch:oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM= informed client:{"mac":"K+dmEzvmjyZACCtR7FydXAun8s4TxxIZDARHvw39u+A=","name":"","vendor":"","ip":"e397411241f40745b998be4ab9e5193a114a962dee4f3c775e92f40dab1b0669","time":0,"tx":0,"rx":0,"txP":0,"rxP":0,"vid":0,"port":0,"txT":0,"dot1x":0,"dVid":0} with invalid port:0, portIndex: null

03-26-2025 15:45:15.216 INFO [client-inform-work-group-3] [] c.t.s.o.c.p.e.d(): Switch:oj5XujXV0upjH/TYxtRIetscfiHMMGkMKhdToEjSHHM= informed client:{"mac":"K+dmEzvmjyZACCtR7FydXAun8s4TxxIZDARHvw39u+A=","name":"","vendor":"","ip":"e397411241f40745b998be4ab9e5193a114a962dee4f3c775e92f40dab1b0669","time":0,"tx":0,"rx":0,"txP":0,"rxP":0,"vid":0,"port":0,"txT":0,"dot1x":0,"dVid":0} with invalid port:0, portIndex: null

still very confused about whats going on here...

[pixielark]

my only theory right now is controller is probably doing some MAC level (layer 2) communication when adopting Omada switches, I do see logs that controller does

list local interface macs: ...

which docker won't suppor in bridge mode, anyone here has Omada switch running into similar issue?

[pixielark]

so I think I stand correctly, I have now changed my omada docker to use macvlan and now my switch can be adopted correctly, it has nothing to do with the port afaik (I specifically tested with the 2 port 9098/19810 removed from network mapping)

mbentley maybe you can update the README and let people know about this weird quirks about adopting Omada switches in particular and see if people run into this issue or not

[mbentley]

I’ll have to search around to see if I can find any FAQs or details related to any specific devices like switches and their adoption process. I personally also use macvlan for my controller.

[mbentley]

OK, so looking at this article: https://www.tp-link.com/us/support/faq/3087/ this is essentially the mode in which you're dealing with when the controller is in bridged mode. The device(s) need to have the Controller Inform URL set either using the discovery utility, through the web interface or using DHCP option 138. I will be updating the README and known issues to address this.

[mbentley]

Hmm, someone reported something similar in #562. Any chance that just restarting when in bridge mode allows it to work again? The person over in that discussion restarted the controller and it started working again.

[pixielark]

Hmm, someone reported something similar in #562. Any chance that just restarting when in bridge mode allows it to work again? The person over in that discussion restarted the controller and it started working again.

no unfortunately, for me I have restarted my entire PVE node and my switch still won't be adopted, but other than that, my 4 EAP works fine for a week without dropping back to the adoption mode as described in #562

I do see in #562 he has switch as well, but looks like he also has a bunch of other MACs showing up in the log (I assume normal person won't have like 10 switches in his topology) so it might be different issue

[mbentley]

Ah well, thanks for validating that it isn't the same behavior, just the same log message.