SVDRP Peering mit Docker Aufnahme Server

    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
    1. 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
    1. SVDRP server handler thread started (pid=17823, tid=17843, prio=low)
    2. SVDRP mld opening port 64019/tcp
    3. SVDRP mld listening on port 64019/tcp
    4. SVDRP client handler thread started (pid=17823, tid=17844, prio=low)
    5. SVDRP mld opening port 6419/udp
    6. SVDRP mld listening on port 6419/udp
    7. 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

    Konfiguration Server

    Konfiguration docker-compose yml


    Ich denke mir fehlt ein Port Mapping aber welches?


    Danke für euer Hilfe wäre ich dankbar

    m.list

    Hi,


    jetzt erst Dein Post gesehen...

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

    Code
    1. ports:
    2. - "2004:2004" # streamdev
    3. - "3000:3000" # streamdev
    4. - "4444:4444"
    5. - "6419:6419" # svdrp
    6. - "6420:6420" # vdrmanager
    7. - "8002:8002" # restfulapi
    8. - "8008:8008" # live
    9. - "34890:34890" # vnsiserver

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

    In Deinem obigen Mapping scheint mir zumindest

    Code
    1. - 64019:6419/tcp
    2. - 64019:6419/udp
    3. - 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

    :vdr2 Server: vdr 2.4.6 (yavdr) im Ubuntu 20.04 docker, Client: vdr 2.2.0 auf RPi (raspbian)

    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

    Hi,


    mit meinen bescheidenen Docker Kenntnissen würde ich sagen unter

    Code
    1. - 64019:6419/tcp
    2. - 64019:6419/udp
    3. - 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

    :vdr2 Server: vdr 2.4.6 (yavdr) im Ubuntu 20.04 docker, Client: vdr 2.2.0 auf RPi (raspbian)

    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
    1. Peering
    3. 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:
    5. 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.
    7. The new SVDRP command PING is used by automatically established peer-to-peer connections to keep them alive.
    8. [snip]


    m.list

    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
    1. yavdr | 2020-08-02T20:07:44.543766+02:00 yavdr vdr: [213] SVDRP server handler thread started (pid=185, tid=213, prio=low)
    2. yavdr | 2020-08-02T20:07:44.544096+02:00 yavdr vdr: [213] SVDRP yavdr opening port 65019/tcp
    3. yavdr | 2020-08-02T20:07:44.544656+02:00 yavdr vdr: [213] SVDRP yavdr listening on port 65019/tcp
    4. yavdr | 2020-08-02T20:07:44.553835+02:00 yavdr vdr: [214] SVDRP client handler thread started (pid=185, tid=214, prio=low)
    5. yavdr | 2020-08-02T20:07:44.553948+02:00 yavdr vdr: [214] SVDRP yavdr opening port 6419/udp
    6. yavdr | 2020-08-02T20:07:44.554230+02:00 yavdr vdr: [214] SVDRP yavdr listening on port 6419/udp
    7. 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
    1. yavdr | 2020-08-02T20:07:44.555444+02:00 yavdr vdr: [213] SVDRP yavdr < 172.19.0.1:44204 client connection accepted
    2. yavdr | 2020-08-02T20:07:44.556567+02:00 yavdr vdr: [185] OSD size changed to 720x480 @ 1
    3. yavdr | 2020-08-02T20:07:44.557513+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:44204 server created
    4. yavdr | 2020-08-02T20:07:44.558369+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:64019 server connection established
    5. 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