[Help]: bind to a single host interface

[CyberbreinAirw0lf]

Controller Version

v5.15.24.19

Describe Your Issue or Question

I'm running the controller in a Docker container via the host network. And would like to know if there is a way to bind the container to one specific interface (i.e. the management interface)? Ideally similar to what can be done via a bridge network?

Expected Behavior

Services are only listening on the management interface - not the wildcard 0.0.0.0 - see also the output of ss -tulpn.

Steps to Reproduce

See the docker CLI command and the output of ss -tulpn.

How You're Launching the Container

docker run -d \
  --name omada-controller \
  --network host \
  --stop-timeout 60 \
  -v /opt/docker/omada/data:/opt/tplink/EAPController/data \
  -v /opt/docker/omada/logs:/opt/tplink/EAPController/logs \
  -e PORTAL_HTTP_PORT=8888 \
  -e TZ=Europe/Amsterdam \
  --restart unless-stopped \
  mbentley/omada-controller

Container Logs

n.a. - I have no technical issues.

MongoDB Logs

No response

Additional Context

Output of ss -tulpn:

Netid State  Recv-Q Send-Q        Local Address:Port  Peer Address:PortProcess                                                                         
udp   UNCONN 0      0                   0.0.0.0:19810      0.0.0.0:*    users:(("java",pid=495,fd=617))                                                
udp   UNCONN 0      0                   0.0.0.0:58653      0.0.0.0:*    users:(("java",pid=495,fd=730))                                                
udp   UNCONN 0      0                   0.0.0.0:27001      0.0.0.0:*    users:(("java",pid=495,fd=591))                                                
udp   UNCONN 0      0                   0.0.0.0:29810      0.0.0.0:*    users:(("java",pid=495,fd=604))                                                
tcp   LISTEN 0      4096                0.0.0.0:9098       0.0.0.0:*    users:(("java",pid=495,fd=571))                                                
tcp   LISTEN 0      100                 0.0.0.0:8888       0.0.0.0:*    users:(("java",pid=495,fd=558))                                                
tcp   LISTEN 0      100                 0.0.0.0:8843       0.0.0.0:*    users:(("java",pid=495,fd=554))                                                
tcp   LISTEN 0      100                 0.0.0.0:8043       0.0.0.0:*    users:(("java",pid=495,fd=550))                                                
tcp   LISTEN 0      100                 0.0.0.0:8088       0.0.0.0:*    users:(("java",pid=495,fd=546))                                                
tcp   LISTEN 0      1024                0.0.0.0:29816      0.0.0.0:*    users:(("java",pid=495,fd=713))                                                
tcp   LISTEN 0      1024                0.0.0.0:29814      0.0.0.0:*    users:(("java",pid=495,fd=681))                                                
tcp   LISTEN 0      1024                0.0.0.0:29815      0.0.0.0:*    users:(("java",pid=495,fd=697))                                                
tcp   LISTEN 0      1024                0.0.0.0:29812      0.0.0.0:*    users:(("java",pid=495,fd=633))                                                
tcp   LISTEN 0      1024                0.0.0.0:29813      0.0.0.0:*    users:(("java",pid=495,fd=665))                                                
tcp   LISTEN 0      1024                0.0.0.0:29811      0.0.0.0:*    users:(("java",pid=495,fd=649))                                                
tcp   LISTEN 0      4096              127.0.0.1:27217      0.0.0.0:*    users:(("mongod",pid=997,fd=11))                                               

[mbentley]

I am not aware of any settings exposed that control which host IP address the services bind to - there isn't anything I can see in the omada.properties which is where most of the exposed configuration is available unless there is a setting that isn't used/documented. A community forum post I saw (https://community.tp-link.com/en/business/forum/topic/253322) asked the same question but the person who replied apparently didn't understand what they were asking and there was no further resolution from anyone else. A quick search online didn't turn up any other results that seemed relevant, unfortunately.