[Help]: Android App keeps reverting port to 8043

[res80]

Controller Version

v5.15.6.7

Describe Your Issue or Question

I am running Omada as a Docker container on my ubuntu 24.04.1, with https redirect disabled within omada.
Thus, I am using caddy to redirect omada.mydomain.com to server_IP:8088 and this works just great in a browser.
Within the android app I use omada.mydomain.com with port 443 and it works too, but only once.
After restarting the app, it reverts the port settings to 8043, although I am not even using that within omada and the reverse proxy?
Even accessing localhost:8088 on the server does not cause a redirect to 8043, so I don-+t understand why the android app is doing this? Do I need to add some rewrites in caddy? I really would prefer not to use the omada cloud solutionn.
Thanks for any advice how to solve this.
Kind regards,
Ruediger

Expected Behavior

android app should stay with port 443

Steps to Reproduce

1. setup omada within docker
2. disable http to https redirect within omada
3. setup caddy as reverse proxy to server_ip:8088
4. setup the android app, connect once, exit and restart the app

How You're Launching the Container

services:
  omada-controller:
    container_name: omada
    image: mbentley/omada-controller:5.15-openj9-chromium
    restart: unless-stopped
    stop_grace_period: 60s
    network_mode: host

    volumes:
      - /Speicher/Docker/Omada/data:/opt/tplink/EAPController/data
      - /Speicher/Docker/Omada/logs:/opt/tplink/EAPController/logs

Container Logs

01-07-2025 21:02:06.505 INFO [manager-topology-pool-0] [] c.t.s.o.c.u.f.a(): list local interface macs: [B2-5D-64-20-7D-8C, 3A-79-85-1C-4C-C2, DE-1E-71-9B-A7-C0, 5A-F4-52-C4-5B-B9, 82-AC-29-5D-92-93, 86-26-68-EB-6E-06, EE-53-A7-46-54-67, EA-36-D3-1D-84-D5, 6A-3E-91-2C-DA-20, CA-51-9E-E3-6F-F4, 3E-54-59-01-5C-55, 1A-A5-A9-F5-BA-9E, BA-44-FB-E5-E6-34, D2-6D-30-61-41-0A, 1A-FB-91-5B-56-FB, 8A-A5-42-BA-07-44, A2-40-4B-49-91-A2, EA-E1-87-2F-49-B4, 9A-FA-05-94-13-64, DA-27-84-D7-01-1D, 02-2E-86-1A-8B-D4, 2E-8D-4B-BC-58-89, 0A-F6-77-5B-01-75, 36-73-68-AE-A9-7B, 02-42-13-0C-ED-84, 02-42-98-EA-2B-F2, 02-42-93-4D-C1-C0, 1C-1B-0D-62-94-31]
01-07-2025 21:02:06.506 INFO [manager-topology-pool-0] [] c.t.s.o.m.t.p.s.t.TopologyTask(): site=63af6b81b5c189117340a818 topology calculate cost: 1ms
01-07-2025 21:04:00.075 INFO [client-schedule-statistic-task-0] [] c.t.s.o.c.d.s.u(): [STAT] {"wiredClients":13,"statName":"ClientStatInfo","authedClients":0,"wirelessClients":11}
01-07-2025 21:04:06.475 WARN [quartzScheduler_Worker-2] [] c.t.s.c.s.c.TaskExecutorService(): receive scheduled event with identity (log_device_status_push, null) but did not execute because corresponding handler log_device_status_push doesn't exist
01-07-2025 21:04:17.350 INFO [http-nio-8088-exec-39] [] c.t.s.o.i.p.c.b.h(): saveSession. session idle timeout is invalid. idleTimeout: null, tenantId: 63e89d464c03452de2585a87.
01-07-2025 21:04:28.016 INFO [http-nio-8088-exec-41] [] c.t.s.o.m.s.e.b(): retrieve active ap from cache
01-07-2025 21:04:28.079 INFO [http-nio-8088-exec-43] [] c.t.s.o.m.t.d.a.a(): Failed to find lldpPortMap for gateway <28-87-BA-33-4F-C0>, omadacId=774006ea0991d678a36753366670dc53
01-07-2025 21:04:28.474 WARN [http-nio-8088-exec-37] [] c.t.s.o.c.a.j(): Invalid request param : family value : 
01-07-2025 21:04:28.506 WARN [http-nio-8088-exec-43] [] c.t.s.o.c.a.j(): Invalid request param : family value : 
01-07-2025 21:04:36.490 INFO [comm-pool-3] [] c.t.s.o.m.d.a.u.f.c(): Target firmware check task run
01-07-2025 21:04:36.492 INFO [comm-pool-3] [] c.t.s.o.m.d.a.u.f.c(): no omadac need handle target firmware upgrade

MongoDB Logs

No response

Additional Context

No response

[mbentley]

My first suggestion would be to see if there is any way you can test without caddy in the middle. I would expect that is what TP-Link would ask you to do to try to remove that as a possible issue, otherwise I would have to expect it's a bug in the Android app. I do not have any Android devices to test with so I can't help there.

[res80]

Thanks for your advice! Unfortunately, I was unable to solve this, so I am using the omada cloud service again to reach my instance from abroad and gave up the subdomain. Will try it again later this year ;)

[res80]

I finally figured out what was causing the problem!
I had to reverse_proxy directly to port 8043 instead of 8088 (otherwise the container would redirect to 8043 always).
To make sure that Caddy does not complain about the certificate of omada, I had to add this to my Caddyfile:

lan.example.com {
	reverse_proxy :8043 {
		transport http {
            		tls_insecure_skip_verify
                }
	}
}
``