06_default_svdrp_port_0.patch ist problematisch

  • Bei den von mir genutzten Quellen (e-Tobi und seahawks vdr 2.3.8 ppa) ist mir aufgefallen, dass der Patch 06_default_svdrp_port_0.patch der den VDR-Standardport auf 0 ändert, problematisch ist. Damit wird das im VDR 2.3.x eingebaute Remotetimers Feature dauerhaft ausgeschaltet und lässt sich per Kommandozeilenoption auch nicht mehr aktivieren. Der Grund ist, dass zum TCP-Port auch noch ein UDP-Port, dazugekommen ist, die beide die gleiche Portnummer (6419) verwenden.


    HP

  • Interessant, dann stellt sich die Frage, warum der VDR nicht das Startargument für den Port auch für den UDP-Port berücksichtigt.


    Eine Möglichkeit wäre die Ports anzugleichen:

    Oder man führt ein extra Startargument für den UDP-Port ein.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich denke mal, dass es sinnvoll wäre, tatsächlich das Startargument zu nutzen, da UDP-Port ohne TCP-Port keinen Sinn macht. Für einen wertemässigen Unterschied bei TCP und UDP sehe ich kein wirklich sinnvolles Anwendungsszenario.


    HP

  • Für einen wertemässigen Unterschied bei TCP und UDP sehe ich kein wirklich sinnvolles Anwendungsszenario.

    Man hat vermutlich so oder so ein Problem, wenn man zwei VDR-Instanzen auf dem gleichen Rechner starten lassen will. Ohne den Patch kommen die sich beim UDP-Port in die Quere und mit Patch können sie erst recht nicht miteinander reden...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Für das Peering ist es in der Tat ungünstig, dass alle vdr den gleichen Port haben müssen.


    Aber gibt es denn ein sinnvolles Szenario, warum zwei vdr auf einem Host per Peering miteinander reden können müssen?


    Lars.

  • Aber gibt es denn ein sinnvolles Szenario, warum zwei vdr auf einem Host per Peering miteinander reden können müssen?

    Eventuell beim yavdr-addon-pip - wenn zwei VDRs in Zukunft ihre Kanallisten selbstständig abgleichen können (wie es Klaus mal angedacht hatte), wäre das schon ein nettes Feature. Das ist aber natürlich eher ein kann als ein muss :)


    Ich habe den Patch für das VDR-Paket in ppa:yavdr/experimental-vdr (für bionic) mal wie oben gezeigt angepasst.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Den Patch 06_default_svdrp_port_0.patch halte ich für unnötig. Die standardmäßig mitgelieferte svdrphosts.conf sorgt dafür, dass SVDRP-Verbindungen nur vom localhost angenommen werden. Wenn man selbst das nicht will, sollte man besser die svdrphosts.conf patchen als den DEFAULTSVDRPPORT.


    Klaus

  • Für das Peering *müssen* alle VDRs auf dem gleichen UDP-Port "lauschen". Wie sollen sie sonst den Broadcast mitbekommen, über den sie sich "suchen"? Der TCP-Port kann ruhig unterschiedlich sein (wenn man das denn unbedingt braucht), denn den teilen sie sich dann gegenseitig mit.


    Klaus

  • Mit der standardmäßig mitgelieferten svdrphosts.conf müsste es eigentlich sogar so sein, dass der Port nur auf localhost überhaupt offen ist. Clients im LAN sehen den offenen Port garnicht. Die Änderung kam vor einiger Zeit mal von mir, weil ich ein für alle mal mit dem Thema "SVDRP und Sicherheit" reinen Tisch machen wollte. Es gibt jetzt eigentlich keinen Grund mehr SVDRP tot zu schalten. Als lokales Kommunikationsprotokoll mit dem VDR (Interprozess-Kommunikation) kann SVDRP immer aktiv bleiben.

  • Das älteste Debian VDR-Paket mit dem Patch, das ich gefunden habe, ist für den VDR 1.2.6 ( https://anonscm.debian.org/cgi…p_port_0.dpatch?h=1.2.6-8 ) - anscheinend hat sich dann niemand mehr für die Änderung im VDR 1.7.12 vom M-Reimer interessiert.


    Ich habe das mit dem VDR 2.3.8 und dem Öffnen von Ports in Abhängigkeit von der svdrphosts.conf und den Peering-Einstellungen gerade mal nachgestellt und denke auch, dass das in der Voreinstellung unkritisch ist (der UDP-Port wird auch nur geöffnet, wenn man das Peering explizit aktiviert). Damit sollte man eigentlich auf den Patch verzichten können.

    Das heißt, mit einer leeren svdrphost.conf kann man svdrp abschalten?

    Vorgesehen ist SVDRP mit dem Start-Argument -p 0 abzuschalten, das steht auch so in der Manpage (dadurch wird auch die Nutzung des UDP-Port deaktiviert, wenn das Peering in der setup.conf angeschaltet ist):

    Code: man 1 vdr
    -p port, --port=port
    Use port for SVDRP. A value of 0 turns off SVDRP. The default SVDRP port is 6419. You need to edit the file svdrphosts.conf in order to enable access to the SVDRP port.

    Wenn die svdrphosts.conf leer ist, öffnet der VDR zwar die Ports auf localhost, aber akzeptiert keine Verbindungen:

    Code
    $ sudo netstat -tulpen | grep 6419
    tcp        0      0 127.0.0.1:6419          0.0.0.0:*               LISTEN      666        19129      626/vdr             
    udp        0      0 127.0.0.1:6419          0.0.0.0:*                           666        20778      626/vdr             
    $ svdrpsend help
    Access denied!

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ok. Es wäre dann sicherlich sinnvoll, gar nicht erst den Port zu belegen, wenn sowieso keine Verbindung akzeptiert wird.


    Wenn man sich eine Maschine mit mehreren Usern teilt, kann es durchaus auch wichtig sein, Verbindungen von localhost unterbinden zu können.


    Lars

  • Wenn man sich eine Maschine mit mehreren Usern teilt, kann es durchaus auch wichtig sein, Verbindungen von localhost unterbinden zu können.

    In dem Fall reicht es ja, den VDR mit -p 0 zu starten, dann öffnet er keine Ports für SVDRP (weder TCP noch UDP).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hatte das neulich schon kurz mit Klaus besprochen und daraufhin den Patch vorerst aus dem Debian-Paket rausgeschmissen.

    Mit -p 0 und deaktiviertem Peering sollte der VDR weder TCP noch UDP-Port öffnen.


    In den Debian-Paketen wurde in der Default-Config sowieso -p 6419 übergeben. Wer mehrer VDR-Instanzen auf der selben Maschine betreibt muss halt aufpassen -p 0 bzw. unterschiedliche Ports zu verwenden.


    Wäre vom Bauchgefühl her IMHO trotzdem schön, wenn man den UDP-Port via define und CLI-Option konfigurieren könnte. Vielleicht um zwei getrennte VDR-Peer-Netze (wozu auch immer..) zu bauen? Oder weil vielleicht doch irgendeine andere Anwendung ausgerechnet schon Port 6419 belegt?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!