SVDRP Peering mit Docker Aufnahme Server

m.list · May 7, 2020 at 7:38 PM

Hallo,

ich versuche gerade mein Glück beim einrichten von SVDRP Peering mit einen Aufnahme Server der in einem Docker Container lauft.

Wenn der Container in Host Netzwerk Modus (Docker Container Netzwerk = Host Netzwerk) lauft dann funktioniert alles bestens aber wenn ich den Aufnahme Server im Docker Netzwerk laufen lass dann bekomme ich immer den Fehler:

Code

ERROR: Error while accessing remote timer 0@keller!

Was ich auch bei meinem vielen Fehlversuche festgestellt habe ist das ich den SVDRP TCP Port umstellen kann aber nicht den UDP Port

Code

SVDRP server handler thread started (pid=17823, tid=17843, prio=low)
SVDRP mld opening port 64019/tcp
SVDRP mld listening on port 64019/tcp
SVDRP client handler thread started (pid=17823, tid=17844, prio=low)
SVDRP mld opening port 6419/udp
SVDRP mld listening on port 6419/udp
SVDRP mld > 255.255.255.255:6419 send dgram 'SVDRP:discover name:mld port:64019 vdrversion:20401 apiversion:20401 timeout:300 host:keller'

Konfiguration Client

Code

MLD> vdr --version
vdr (2.4.1/2.4.1) - The Video Disk Recorder
rpihddevice (1.0.4) - HD output device for Raspberry Pi
satip (2.4.1-GIT-v219) - SAT>IP Devices
suspendoutput (2.1.0) - Suspend output
svdrpservice (1.0.0) - SVDRP client

MLD> grep SVDRP /etc/vdr/setup.conf
SVDRPDefaultHost = keller
SVDRPHostName = mld
SVDRPPeering = 2
SVDRPTimeout = 300

Display More

Konfiguration Server

Code

root@keller:/# vdr --version
vdr (2.4.1/2.4.1) - The Video Disk Recorder
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu

epgsearch (2.4.0) - search the EPG for repeats and more
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
quickepgsearch (0.0.1) - Quick search for broadcasts
satip (2.4.0) - SAT>IP Devices

root@keller:/# grep SVDRP /var/lib/vdr/setup.conf
SVDRPDefaultHost =
SVDRPHostName = keller
SVDRPPeering = 1
SVDRPTimeout = 300

Display More

Konfiguration docker-compose yml

Code

version: '3.5'

networks:
    vdr:

services:
    vdr:
        image: vdr
        container_name: vdr
        hostname: keller
        ports:
            - 64004:2004
            - 4010-4020:4010-4020/udp
            - 64019:6419/tcp
            - 64019:6419/udp
            - 6419:6419/udp
        networks:
            - vdr
        restart: always
        volumes:
            - /srv/docker/vdr/cache:/var/cache/vdr
            - /srv/docker/vdr/lib:/var/lib/vdr
            - /srv/docker/vdr/video:/var/lib/video

Display More

Ich denke mir fehlt ein Port Mapping aber welches?

Danke für euer Hilfe wäre ich dankbar

m.list

rfu · June 16, 2020 at 11:05 AM

Hi,

jetzt erst Dein Post gesehen...

Bei mir ist das einfach im docker-compose.yml direkt gemappt:

Code

ports:
      - "2004:2004"   # streamdev
      - "3000:3000"   # streamdev
      - "4444:4444"
      - "6419:6419"   # svdrp
      - "6420:6420"   # vdrmanager
      - "8002:8002"   # restfulapi
      - "8008:8008"   # live
      - "34890:34890" # vnsiserver

also auf Port 6419, und zumindest remoteosd funktioniert problemlos...

In Deinem obigen Mapping scheint mir zumindest

Code

- 64019:6419/tcp
- 64019:6419/udp
- 6419:6419/udp

widersprüchlich, da Du versuchst den selben Port mehrfach unterschiedlich zu mappen. Gibt es einen Grund warum Du auf 64019 möchtest?

Was sagt denn docker ps über das mapping zur Laufzeit?

rfu

m.list · July 25, 2020 at 1:35 AM

Hallo rfu,

danke für die Antwort.

ich habe zwei VDRs am laufen, einen Produktiven und einen für test Zwecke, deshalb muss der test VDR auf andere Ports ausweichen. In diesem Fall habe ich 64019 gewählt.

Warum ist deiner Meinung nach das Mapping widersprüchlich? Es werden jeweils der 64019 TCP und der 64019 UDP Port von Server auf den 6419 TCP und 6419 UDP Port von Container gemappt.

Das Problem ist nicht mit remoteosd, das funktioniert einwandfrei.

Das Problem ist mit der neuen SVDRP Peering Funktionalität. Ich vermute das es entweder daran liegt das ich den UDP Port nicht ändern kann oder es werden irgendwelche Random (UDP?) Ports noch zusätzlich aufgemachen.

m.list

rfu · July 27, 2020 at 2:06 PM

Hi,

mit meinen bescheidenen Docker Kenntnissen würde ich sagen unter

Code

- 64019:6419/tcp
- 64019:6419/udp
- 6419:6419/udp

mappst Du den Container-port 6419/udp sowohl auf host port 64019 (zweite Zeile) als auch 6419 (dritte Zeile), ich weiß nicht ob Docker das unterstützt...

Aber möglicherweise leite ich Dich da auch völlig in die Irre weil ich Dein Setup nicht komplett verstanden habe...

Du hast den Server VDR auf svdrp port 6419, der im docker auf 64019 gemappt wird. Wenn Du jetzt vom client aus auf 64019 zugreifst bekommst Du einen Timeout? Wenn Du sagst Du kannst den UDP Port nicht ändern... auf dem Server oder auf dem Client?

rfu

m.list · July 27, 2020 at 10:53 PM

Hallo rfu,

so weit ich das verstanden habe sind das NAT Mappings in der Form HOST:CONTAINER und NAT Mappings greifen nur für eingehende Verbindungen. Ausgehende Verbindungen sind ja in der Format IP:Port und die Regeln haben keine Möglichkeit den IP zur berücksichtigen deshalb können die Regel nicht für ausgehende Verbindungen greifen. Also ist das kein Problem und außerdem funktioniert es auch nicht wenn ich Zeile 3 weg lasse.

Wenn sich der Client, mit Port 64019, mit dem Server vebindet mapped Docker das auf dem Container Port 6419. Einfaches SVDRP funktioniert weil ich zum Beispiel auf dem Menü von VDR im Container zugriff habe.

Was nicht funktioniert ist das SVDRP Peering beziehungsweise SVDRP Peering der Timer

Code

Peering

If there is more than one VDR in the local network, they can now form a peer-to-peer network, so that timers can be moved freely between them. The following changes have been made to implement this:

VDR now sends out a broadcast to port 6419/udp, which was assigned to 'svdrp-disc' by the IANA. VDRs listening on that port will automatically initiate an SVDRP connection to the broadcasting VDR, and in turn send out a broadcast to make other VDRs connect to them. That way all VDRs within the local network will have permanent "peer-to-peer" SVDRP connections between each other. The configuration in the svdrphosts.conf file is taken into account when considering whether or not to respond to an SVDRP discover broadcast.

The new SVDRP command PING is used by automatically established peer-to-peer connections to keep them alive.
[snip]

m.list

rfu · July 31, 2020 at 12:54 PM

Hi m.list,

ich habe dazu UDP Broadcast not working in docker bridge network #637 gefunden, falls das weiterhilft... selbst nutze ich das SVDRP Peering nicht...

Robert

m.list · July 31, 2020 at 7:18 PM

Hallo rfu,

vielen danke für den hinwies, ich werde es mal ausprobieren

m.list

m.list · August 2, 2020 at 8:30 PM

Hallo rfu,

ich wollte den Vorschlag ausprobieren aber bin auf ein anderes Problem gestoßen - der Test VDR (SVDRP Port 65019) verbindet sich mit den Produktions VDR (SVDR Port 64019) und holt sich die Timers.

Ich denke ein Grund liegendes Problem ist das man den UDP Port nicht ändern kann "SVDRP yavdr opening port 6419/udp" was dazu führt das ein Broadcast an alle VDRs geht.

Code

yavdr    | 2020-08-02T20:07:44.543766+02:00 yavdr vdr: [213] SVDRP server handler thread started (pid=185, tid=213, prio=low)
yavdr    | 2020-08-02T20:07:44.544096+02:00 yavdr vdr: [213] SVDRP yavdr opening port 65019/tcp
yavdr    | 2020-08-02T20:07:44.544656+02:00 yavdr vdr: [213] SVDRP yavdr listening on port 65019/tcp
yavdr    | 2020-08-02T20:07:44.553835+02:00 yavdr vdr: [214] SVDRP client handler thread started (pid=185, tid=214, prio=low)
yavdr    | 2020-08-02T20:07:44.553948+02:00 yavdr vdr: [214] SVDRP yavdr opening port 6419/udp
yavdr    | 2020-08-02T20:07:44.554230+02:00 yavdr vdr: [214] SVDRP yavdr listening on port 6419/udp
yavdr    | 2020-08-02T20:07:44.554866+02:00 yavdr vdr: [214] SVDRP yavdr > 255.255.255.255:6419 send dgram 'SVDRP:discover name:yavdr port:65019 vdrversion:20401 apiversion:20401 timeout:300'

Ein zweites Problem ist das ein neues (Random) Port, 44204,eröffnet wird das nicht gemappt ist und auch nicht gemappt werden kann weil es nicht bekannt ist

Code

yavdr    | 2020-08-02T20:07:44.555444+02:00 yavdr vdr: [213] SVDRP yavdr < 172.19.0.1:44204 client connection accepted
yavdr    | 2020-08-02T20:07:44.556567+02:00 yavdr vdr: [185] OSD size changed to 720x480 @ 1
yavdr    | 2020-08-02T20:07:44.557513+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:44204 server created
yavdr    | 2020-08-02T20:07:44.558369+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:64019 server connection established
yavdr    | 2020-08-02T20:07:44.558867+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:64019 client created for 'keller'

Bis es ein Lösung für die zwei Probleme gibt wird das nichts.

m.list

SVDRP Peering mit Docker Aufnahme Server

Participate now!

Tags