Hallo zusammen,
wir haben hier ein Problem, dass über VLANs hinweg die Darstellung einer Kamera erst mit einigen Sekunden Verzögerung im Browser dargestellt wird. Aus dem Netz mit dem Browser in das IOT-Netz mit der Kamera und dem HomeAssistant ist alles erlaubt.
Der Browser loggt dann immer mehrfach:
QuoteWebRTC: ICE failed, add a TURN server and see about:webrtc for more details
ICE(PC:{973c38db-ee0c-4f1c-ac4c-d01413ea27ec} 1772974974282538 (id=15032385544 url=http://172.17.1.1:8123/dashboard-katzen-02/0)): peer (PC:{973c38db-ee0c-4f1c-ac4c-d01413ea27ec} 1772974974282538 (id=15032385544 url=http://172.17.1.1:8123/dashboard-katzen-02/0):default) has no stream matching stream PC:{973c38db-ee0c-4f1c-ac4c-d01413ea27ec} 1772974974282538 (id=15032385544 url=http://172.17.1.1:8123/dashboard-katzen-02/0) transport-id=transport_25 - 4e6f7817:ebccdf6e1b287c38cbe5dc2acf1d0cac
ICE-STREAM(PC:{0d4da293-42f9-42a1-992b-f87dcf9c99e3} 1772975955781375 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0) transport-id=transport_0 - e5f39160:e1eabf4c8037a85881857af3fc6320da): Skipping STUN server because of address type mis-match
/builds/worker/checkouts/gecko/dom/media/webrtc/transport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:175 function nr_socket_multi_tcp_create_stun_server_socket skipping UDP STUN server(addr:IP4:0.0.0.0:3478/UDP)
ICE-STREAM(PC:{ff924bcc-af30-41fe-97ee-193c9f384121} 1772975955782750 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0) transport-id=transport_1 - a0e45dab:d0f7132aa6be03897c42948c1b35af84): failed to create passive TCP host candidate: 3
ICE(PC:{ff924bcc-af30-41fe-97ee-193c9f384121} 1772975955782750 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0)): All candidates initialized
ICE(PC:{0d4da293-42f9-42a1-992b-f87dcf9c99e3} 1772975955781375 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0)): peer (PC:{0d4da293-42f9-42a1-992b-f87dcf9c99e3} 1772975955781375 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0):default) starting grace period timer for 5000 ms
ICE(PC:{0d4da293-42f9-42a1-992b-f87dcf9c99e3} 1772975955781375 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0)): peer (PC:{0d4da293-42f9-42a1-992b-f87dcf9c99e3} 1772975955781375 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0):default) no streams with non-empty check lists
ICE(PC:{0d4da293-42f9-42a1-992b-f87dcf9c99e3} 1772975955781375 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0)): peer (PC:{0d4da293-42f9-42a1-992b-f87dcf9c99e3} 1772975955781375 (id=15032385545 url=http://172.17.1.1:8123/dashboard-katzen-02/0):default) no streams with pre-answer requests
Ich hab nun tatsächlich keinen Plan, was ich mit dem os-turnserver Plugin anfangen soll, aber das wäre doch das, was man dann braucht, oder?
Die "grace period timer for 5000 ms" Meldung sieht doch Verdächtig aus.
Wobei laut Paket-Trace der Browser nur mit dem HomeAssistant kommuniziert und nicht mit der Kamera direkt.
Wir haben testhalber mal "allow all" auf dem IOT-Netz angelegt - damit ist die Kamera-Darstellung dann "fluffig". Mit den Standard-Regeln "IOT darf ins Internet aber nicht ins LAN" haben wir immer diese 5 Sekunden Gedenkpause drin. Wobei die Verbindung natürlich aus dem LAN aufgebaut wird.
Danke und liebe Grüße
Patrick
TURN wäre doch nur nötig, damit die OPNSense als Proxy zwischen den Geräten fungiert, wenn keine direkte Verbindung möglich ist. Das brauchst du hier doch gar nicht.
Was sagt denn das Live-Log? Werden irgendwelche UDP-Pakete gedroppt, wenn du das Kamerabild im Browser aufrufst?
Keine zu sehen, nur diese Meldungen im Browser. Ich guck morgen nochmal.
TURN ist eigentlich ein NAT Bohrer, das solltest du intern nicht brauchen.
Was die Konfiguration angeht, da gibt es normal keine, aber die Ports müssen halt offen sein.