Ubiquiti Unifi Network Application
Inhaltsverzeichnis
Allgemeines
Nachdem ich die Erstinstallation von meinen Ubiquiti-WLAN-Netzwerk (Secure Gateway, 4 APs und 1 Bridge) an einem Windows PC vorgenommen habe, empfinde ich es mittlerweile als laestig jedesmal wenn ich im Netzwerk etwas nachschauen moechte den Windowsrechner anzuschalten und den Unifi Network Server, mittlerweile in der Version 8.0.24, zu starten und mich im Browser einzuloggen.
Jedesmal wenn man den Server stoppt.
Zu Anfang gleich was zur Begriffsverwirrung
Die "Kurzbezeichnung" der Managing Software (Streamlined Network Management) ist Network Server. Die Software wird oftmals als Unifi Controller benannt.
Im DockerHub ist folgender Eintrag zum unifi-controller zu finden.
From 2024-01-01 this image will be deprecated and it will no longer be updated. Please migrate to our Unifi Network Application image instead
Interessanterweise hat dieses (auslaufende) Image immer noch deutlich mehr Downloads als das Unifi Network Application Image. Ich benutze natuerlich hier das unifi-network-application Image.
Das Original findet man unter https://ui.com/download/releases/network-server.
Unifi OS
Ganz aktuell ist es seit Version 8 (20.11.2023 V8.0.7) auch moeglich den Server auf UnifiOS-Maschinen (DreamMachine,...) laufen zu lassen. Das werde ich bei Gelegenheit testen. Noch habe ich keine entsprechende Hardware.
Installation auf meinen SmartHome (FHEM) Linux Server
Man benoetigt zum Betrieb eine MongoDB und die Network Application Software. Die MongoDB wird in den Versionen 3.6 bis 4.4 empfohlen. Abgesehen davon, dass alte Versionen oft bei der Installation zicken, ist sie auch in den Reposotories von openSuSE nicht vorhanden.
Da sowohl die MongoDB als auch der Unifi Network Application Server (UNAS) als DockerImage angeboten werden, habe ich diesen Weg eingeschlagen, um den Anpassungproblemen der MongoDB Version und der Java Umgebung für den UNAS aus dem Weg zu gehen.
Da ich bisher noch nicht ernsthaft mit docker gearbeitet hatte, nutze ich gleich die Gelegenheit hier nuetzliche Erfahrungen zu sammeln.
Zu Beginn sind erst einmal nur Downloads zu machen. Zusaetzlich habe ich aber trotz des MongoDB-Docker-Image auch noch die MongoDB native auf dem Server installiert. https://www.mongodb.com/docs/v4.4/tutorial/install-mongodb-on-suse/
Die MongoDB Downloads von mongodb.org waren irgendwie unvollstaendig.
Download
Die MongoDb steht nicht im Linuxserver.io-Fleet (https://fleet.linuxserver.io/) wird aber per pull vom DockerHub geliefert.
docker pull linuxserver/unifi-network-application
docker pull mongo:4.4
Da der UNAS nicht ohne eine funktionierende MongoDB-Installation starten will, kommt sie zuerst dran.
Hier die Doku.
Erste Schritte
Docker Images
Mit
docker images
kann man sich ueber die vorhanden Images ein Bild machen. Dabei koennen ruhig mehrere Images mit gleichem Name, aber unterschiedlichen Versionen (TAG) vorliegen. Die ImageID macht sie eindeutig.
docker image ls
hat die gleiche Wirkung. Mit
docker image help
lassen sich alle Kommandos sehen. Dabei sind erst einmal 2 von besonderem Nutzen.
docker image rm <Image Name>
und
docker image prune
Aus den Images lassen sich jetzt Container erstellen.
Docker Container
MongoDB
Mit
docker run ...
kann man nun aus einem vorhandenen Image einen "laufenden" Container erzeugen, Wenn man will auch mehrere parallel. Neben den vielen Optionen die 'docker run' anbietet, empfehle ich '--name -it'.
Man kann zwar den (eigenen) Namen auch weglassen, dann wird er von docker automatisch per Zufall vergeben, wie z.B. flamboyant_rosalind ;-)
Die beiden Optionen
-i --interactive Keep STDIN open even if not attached -t --tty Allocate a pseudo-TTY
erlauben es aehnlich wie per ssh auf die bash-console des laufenden Containers zu verbinden. Das kann nuetzlich sein, um ein wenig umherzustoebern. Aenderungen an der Installation werden dardurch zwar moeglich aber mangels oft nicht installierter Editoren erschwert und zudem wird eine derartige Anpassung auch nicht empfohlen.
Mit
docker run (-itd) (--name MeineMongoDB) mongo:4.4
kann man nun der Container beim ersten mal starten, da er run auch gleichzeitig erzeugt wird. Der Container laesst sich dann spaeter, nach der Erzeugung, mit
docker container start/stop/restart/stats/.... <name>
bedienen.
Wenn der MongoContainer gestartet wurde, sollte standardmaessig auf Port 27017 eine Kontaktaufnahme gelingen.
Nachdem ich den UnifiDB auf Mongo laufen hatte war dadurch der Standard-Port 27017 belegt. Weitere Test ohne den Port anzupassen waren damit bei laufendem UNAS nicht (mehr) moeglich. Also brauchte wenigstens eine weitere Option naemlich -p:
-p=[] : Publish a container's port or a range of ports to the host
format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
Both hostPort and containerPort can be specified as a
range of ports. When specifying ranges for both, the
number of container ports in the range must match the
number of host ports in the range, for example:
-p 1234-1236:1234-1236/tcp
When specifying a range for hostPort only, the
containerPort must not be a range. In this case the
container port is published somewhere within the
specified hostPort range. (e.g., `-p 1234-1236:1234/tcp`)
(use 'docker port' to see the actual mapping)
Da ich noch keine Moeglichkeit gefunden habe, wie ich nachtraeglich (nach docker run) das Portmapping veraendern kann, loesche ich kurzerhand den Container und erzeuge ihn neu.
docker run -itd -p 27018:27017 --name mongotestdb mongo:4.4
Nun kommt mongo (MongoDB shell version v4.4.26) auf dem Hostsystem zum Einsatz. Mit
mongo IP:PORT/DBNAME
kann man jetzt die Kontaktaufnahme testen. Vorher brauche ich aber noch die IP des Containers.
docker container inspect mongotestdb
Unter dem Abschnitt "NetworkSettings" finde folgendes.
"NetworkSettings": {
"Bridge": "",
"SandboxID": "9687d7931fab057018a021244845ece6888ba95341a8daba6fcc361af644bb8f",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {
"27017/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "27018"
},
{
"HostIp": "::",
"HostPort": "27018"
}
]
},
"SandboxKey": "/var/run/docker/netns/9687d7931fab",
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "5f95ee4da8a744a6c4228d97d6daec11675f6a8a3c653ff23200c6f5980e7d75",
"Gateway": "172.17.0.1",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "172.17.0.4",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"MacAddress": "02:42:ac:11:00:04",
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"NetworkID": "fcd1687abcf1e061b8f56fc14c63d103cc76f5dbd4c8584e6d8f1ff50582ac5a",
"EndpointID": "5f95ee4da8a744a6c4228d97d6daec11675f6a8a3c653ff23200c6f5980e7d75",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.4",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:ac:11:00:04",
"DriverOpts": null
}
}
}
Also probiere ich
mongo 172.17.0.4:27018
und scheitere. Obwohl ich den internen Port (Container) auf den externen Port (Host) umgelenkt habe klappt die Kontaktaufnahme nicht. Erst mit
mongo 172.17.0.4:27017
klappt es. Komisch. Die Portumlenkung scheint sich nur auf den Host zu beziehen, nicht auf die Bridge.
MongoDB shell version v4.4.26 connecting to: mongodb://172.17.0.4:27017/test?compressors=disabled&gssapiServiceName=mongodb Implicit session: session { "id" : UUID("ab1224d3-543b-46bc-a7d1-8824bc288512") } MongoDB server version: 4.4.26 --- The server generated these startup warnings when booting:
2023-12-25T08:56:12.469+00:00: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine. See http://dochub.mongodb.org/core/prodnotes-filesystem 2023-12-25T08:56:14.368+00:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted 2023-12-25T08:56:14.368+00:00: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. We suggest setting it to 'never'
--- > show dbs admin 0.000GB config 0.000GB local 0.000GB > db.getSiblingDB("MONGO_DBNAME").createUser({user: "MONGO_USER", pwd: "MONGO_PASS", roles: [{role: "dbOwner", db: "MONGO_DBNAME"}]}); Successfully added user: {
"user" : "MONGO_USER",
"roles" : [
{
"role" : "dbOwner",
"db" : "MONGO_DBNAME"
}
]
}
Noch den zweiten Befehl hinterher.
db.getSiblingDB("MONGO_DBNAME_stat").createUser({user: "MONGO_USER", pwd: "MONGO_PASS", roles: [{role: "dbOwner", db: "MONGO_DBNAME_stat"}]});
und schon sind die Vorbereitungen der MongoDB abgeschlossen.
Der Weg ueber mongosh und docker exec waere wohl auch gegangen. [1]
Unifi Network Application
Der Befehl startet den Container.
docker run -d --name=unifi-network-application -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -e MONGO_USER=unifimongouser -e MONGO_PASS=XXXXXXX -e MONGO_HOST=172.17.0.3 -e MONGO_PORT=27017 -e MONGO_DBNAME=unifiDB -e MEM_LIMIT=1024 -e MEM_STARTUP=1024 -e MONGO_TLS= -e MONGO_AUTHSOURCE= -p 8443:8443 -p 3478:3478/udp -p 10001:10001/udp -p 8080:8080 -p 1900:1900/udp -p 8843:8843 -p 8880:8880 -p 6789:6789 -p 5514:5514/udp -v /path/to/data:/config --restart unless-stopped linuxserver/unifi-network-application:latest
Jetzt etwas Geduld. Ich war zu schnell und habe im Log nichts sehen koennen. Aber die UNA benoetigt ein wenig Zeit die MongoDB zu initialisieren. Dann hat auch der Zugriff ueber hhtps://HOSTIP:8443 geklappt.
Beim Einspielen des Backups hat es allerdings ewig gedauert, bis ich mich entschlossen habe den Vorgang abzubrechen.
fhem:/opt # docker logs -f unifi-network-application
[migrations] started
[migrations] no migrations found
───────────────────────────────────────
██╗ ███████╗██╗ ██████╗
██║ ██╔════╝██║██╔═══██╗
██║ ███████╗██║██║ ██║
██║ ╚════██║██║██║ ██║
███████╗███████║██║╚██████╔╝
╚══════╝╚══════╝╚═╝ ╚═════╝
Brought to you by linuxserver.io
───────────────────────────────────────
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID: 1000
User GID: 1000
───────────────────────────────────────
*** Waiting for MONGO_HOST 172.17.0.3 to be reachable. ***
Generating 4,096 bit RSA key pair and self-signed certificate (SHA384withRSA) with a validity of 3,650 days
for: CN=unifi
[custom-init] No custom files found, skipping...
[ls.io-init] done.
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
Exception in thread "Thread-9" java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
at org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:168)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1172)
at com.ubnt.service.Object.return(Unknown Source)
at com.ubnt.ace.Launcher.Ö00000(Unknown Source)
at java.base/java.lang.Thread.run(Thread.java:840)
Exception na toll:-((
SoftwareNutzung
Das Backup einspielen hat soweit funktioniert. Meine Netzwerke, WLANs und Devices waren sichtbar, aber das ganze Traffic-Reporting funktioniert nicht. Ich vermute ein Netzzugriffsproblem aus dem Container heraus. Mal schauen:-((
Einen hab ich noch
Das Aufnehmen eines neuen Devices geht mit mit eingeschalteter Firewall (noch) nicht. Auch die MobilApp findet die "Console" (!) nicht und da docker mit nftables nicht klar kommt, kann das ja heiter werden.
Mit iptables-save -f docker_unifi_iptables.dump habe ich mir die Regeln von docker gesichert und jedesmal, wenn mir die Firewall die Regeln killt, hole ich sie mit iptables-restore docker_unifi_iptables.dump wieder zurueck.
Das muss auch besser gehen. Grrrrrrrr!
Nachrag 2024-02-01
Eigentlich war der Ausloeser, dass ich einen UAP-AC-M ins Netzwerk aufnehmen wollte, da war es so etwa 18:00 Uhr. Aber weit und breit kein Device in meinem Controller zu sehen. (Anmerkung: Die Unifi-Mobile-App hat ihn sofort gefunden, aber dazu spaeter mehr. Also war es kein Netzanschlussproblem.)
Ich hatte die Firewall im Verdacht. Also die Firewall ausgeschaltet.
systemctl stop firewalld
und dann wie schon in einem anderen Beitrag beschrieben, waren alle "Docker-NATs" weg.
Nach einem Reboot des Rechners mit den 2 Docker Containern (unifi-network-application und mongodb) an Board sind zwar die Container gestartet, aber der Unifi Controller quittierte einen Aufruf ueber den Webbrowser mit einem 404 Error.
Ursachenforschung:
docker container ls docker logs -f unifi-mongo docker logs -f unifi-network-application
Ausgeloest durch die Firewall-Problematik bin ich aber dann auf ein ganz anderes Problem gestoszen. Nach langem Suchen, mittlerweile war es 21:21 Uhr, habe ich die Ursache gefunden. Durch den Neustart hat der Mongo-Container eine andere IP (172.17.0.2 anstatt vorher 172.17.0.3) erhalten und damit war natuerlich auch die Kontaktaufnahme aus dem UNA-Container nicht mehr moeglich.
docker exec -it unifi-network-application bash
root@2f2a54dc0c1e:/usr/lib/unifi# ll
total 36
drwxr-xr-x 1 root root 4096 Feb 3 19:58 ./
drwxr-xr-x 1 root root 4096 Dec 13 17:57 ../
drwxr-xr-x 2 root root 4096 Dec 13 17:58 bin/
lrwxrwxrwx 1 root root 12 Feb 3 19:58 data -> /config/data/
drwxr-xr-x 3 root root 4096 Dec 13 17:57 dl/
drwxr-xr-x 3 root root 12288 Dec 13 17:58 lib/
lrwxrwxrwx 1 root root 12 Feb 3 19:58 logs -> /config/logs/
lrwxrwxrwx 1 root root 14 Dec 13 17:58 run -> /var/run/unifi/
drwxr-xr-x 3 root root 4096 Dec 13 17:57 webapps/
root@2f2a54dc0c1e:/usr/lib/unifi# ll /config/logs
total 21744
drwxr-xr-x 3 abc abc 4096 Feb 4 06:22 ./
drwxr-xr-x 4 abc abc 4096 Dec 24 17:14 ../
-rw-r--r-- 1 abc abc 7019853 Feb 4 07:20 access.log
-rw-r--r-- 1 abc abc 10485799 Jan 31 19:08 access.log.1
-rw-r--r-- 1 abc abc 0 Dec 24 17:41 hotspot.log
-rw-r--r-- 1 abc abc 33093 Dec 25 14:49 migration.log
drwxr-xr-x 2 abc abc 4096 Feb 3 21:38 remote/
-rw-r--r-- 1 abc abc 3763796 Feb 4 07:20 server.log
-rw-r--r-- 1 abc abc 403602 Feb 4 07:20 tasks.log
-rw-r--r-- 1 abc abc 512409 Feb 4 06:22 tasks.log.1
root@2f2a54dc0c1e:/usr/lib/unifi# ll /config/data/
total 64
drwxr-xr-x 5 abc abc 4096 Feb 3 20:34 ./
drwxr-xr-x 4 abc abc 4096 Dec 24 17:14 ../
drwxr-xr-x 3 abc abc 4096 Dec 25 09:15 backup/
drwxr-xr-x 2 abc abc 4096 Dec 25 09:16 db/
-rw-r--r-- 1 abc abc 24464 Feb 3 20:35 firmware.json
-rw-r--r-- 1 abc abc 4230 Dec 24 17:41 keystore
-rw-r--r-- 1 abc abc 1424 Feb 3 20:34 model_lifecycles.json
drwxr-xr-x 3 abc abc 4096 Dec 25 15:10 sites/
-rw-r--r-- 1 abc abc 1623 Feb 3 20:34 system.properties
-rw-r--r-- 1 abc abc 1623 Feb 3 20:34 system.properties.bk
root@2f2a54dc0c1e:/usr/lib/unifi#
Die Logs durchzuschauen brachte zwar keinen Loesungsansatz, aber die neue Erkenntnis wo man ggf. suchen kann. Die Kontaktdaten der MongoDB stehen in der Datei system.properties.
root@2f2a54dc0c1e:/usr/lib/unifi# cat /config/data/system.properties
## system.properties
#
# each unifi instance requires a set of ports:
#
## device inform
# unifi.http.port=8080
## controller UI / API
# unifi.https.port=8443
## portal redirect port for HTTP
# portal.http.port=8880
## portal redirect port for HTTPs
# portal.https.port=8843
## local-bound port for DB server
# unifi.db.port=27117
## UDP port used for STUN
# unifi.stun.port=3478
#
## the IP devices should be talking to for inform
# system_ip=a.b.c.d
## disable mongodb journaling
# unifi.db.nojournal=false
## extra mongod args
# unifi.db.extraargs
#
## HTTPS options
# unifi.https.ciphers=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
# unifi.https.sslEnabledProtocols=TLSv1,SSLv2Hello
# unifi.https.hsts=false
# unifi.https.hsts.max_age=31536000
# unifi.https.hsts.preload=false
# unifi.https.hsts.subdomain=false
#
# Ports reserved for device redirector. There is no need to open
# firewall for these ports on controller, however do NOT set
# controller to use these ports.
#
# portal.redirector.port=8881
# portal.redirector.port.wired=8882
#
# Port used for throughput measurement.
# unifi.throughput.port=6789
#
#Sat Feb 03 20:34:34 UTC 2024
reporter-uuid=eca45030-60a6-45d9-942d-d1078690eb88
is_setup_completed=true
debug.mgmt=warn
db.mongo.local=false
debug.setting_preference=auto
is_default=false
uuid=69b6c3d5-7503-4cc3-89e1-89f6c6c07b58
db.mongo.uri=mongodb\://<USER>\:<PW>@172.17.0.3\:27017/unifiDB?tls\=false
statdb.mongo.uri=mongodb\://<USER>\:<PW>@172.17.0.3\:27017/unifiDB_stat?tls\=false
unifi.db.name=unifiDB
debug.device=warn
debug.system=warn
debug.sdn=warn
root@2f2a54dc0c1e:/usr/lib/unifi#
Und hier sieht man das Uebel 172.17.0.3 anstatt wie nach dem Restart 172.17.0.2. Da mein UNA-Container kein nano,vi, ... an Board hat und uebrigens auch kein ping (Grrrrrr!) sah ich nur den Weg ueber den Host.
docker cp unifi-network-application:/usr/lib/unifi/data/system.properties .
Abaender der IP und wieder zureuck.
docker cp system.properties unifi-network-application:/usr/lib/unifi/data/system.properties
Den Container neu gestartet und es ging.
docker container restart unifi-network-application
Bleibt aber immer noch das Firewall-Problem und die nicht funktionierende Einbindung meines neuen UAP-AC-M.
Das sind die Docker-Portmaps. Logischerweise sollten diese Ports auch von "auszen" nutzbar sein.
0.0.0.0:1900->1900/udp
- 1900->1900/udp
0.0.0.0:3478->3478/udp
- 3478->3478/udp
0.0.0.0:6789->6789/tcp
- 6789->6789/tcp
0.0.0.0:8080->8080/tcp
- 8080->8080/tcp
0.0.0.0:8443->8443/tcp
- 8443->8443/tcp
0.0.0.0:8843->8843/tcp
- 8843->8843/tcp
0.0.0.0:5514->5514/udp
- 5514->5514/udp
0.0.0.0:10001->10001/udp
- 10001->10001/udp
0.0.0.0:8880->8880/tcp
- 8880->8880/tcp
8443 Unifi web admin port
3478/udp Unifi STUN port
10001/udp Required for AP discovery
8080 Required for device communication
1900/udp Required for Make controller discoverable on L2 network option
8843 Unifi guest portal HTTPS redirect port
8880 Unifi guest portal HTTP redirect port
6789 For mobile throughput test
5514/udp Remote syslog port
Anmerkung: Session Traversal Utilities for NAT (STUN, englisch für „Werkzeuge zum Durchkreuzen von NATs“) ist ein einfaches Netzwerkprotokoll, um das Vorhandensein und die Art von Firewalls und NAT-Routern zu erkennen und direkte Verbindungen zwischen Geräten, welche sich hinter einer NAT-Firewall befinden, aufzubauen. Damit ist es Geräten, welche hinter bestimmten Typen von NAT-Firewalls betrieben werden, möglich direkte bidirektionale Verbindungen zwischen den Endknoten aufzubauen. Beispiele für die Anwendung von STUN sind SIP-Telefone und Computer-Programme in Heimnetzwerken.
Also dann mal alle notwendigen Ports in der Firewall oeffnen. Interessanterweise waren alle TCP-Ports bis auf 6789 schon offen.
sudo firewall-cmd --zone=public --add-port=6789/tcp --permanent sudo firewall-cmd --zone=public --add-port=3478/udp --permanent sudo firewall-cmd --zone=public --add-port=10001/udp --permanent sudo firewall-cmd --zone=public --add-port=1900/udp --permanent sudo firewall-cmd --zone=public --add-port=5514/udp --permanent
Siehe auch [2].
Nicht vergessen
sudo firewall-cmd --reload
Also UAP-AC-M wieder eingesteckt, weiszes Blinken und dann weiszes Dauerlicht.
fhem:~ # iptables -n -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-1 all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 172.17.0.3 udp dpt:10001
ACCEPT tcp -- 0.0.0.0/0 172.17.0.3 tcp dpt:8880
ACCEPT tcp -- 0.0.0.0/0 172.17.0.3 tcp dpt:8843
ACCEPT tcp -- 0.0.0.0/0 172.17.0.3 tcp dpt:8443
ACCEPT tcp -- 0.0.0.0/0 172.17.0.3 tcp dpt:8080
ACCEPT tcp -- 0.0.0.0/0 172.17.0.3 tcp dpt:6789
ACCEPT udp -- 0.0.0.0/0 172.17.0.3 udp dpt:5514
ACCEPT udp -- 0.0.0.0/0 172.17.0.3 udp dpt:3478
ACCEPT udp -- 0.0.0.0/0 172.17.0.3 udp dpt:1900
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Fuer den Docker-Container sind alle relevanten Ports offen, aber halt in der Firewall nicht.
Nachdem die Firewall-Regeln ergaenzt waren, hat die UNA den einsteckten UAP-AC-M sofort bemerkt und adoptiert;-) weisz/blaues Blinken und dann ein Update ausgfuehrt.
Ich werde berichten.
