Erreichbarkeit von Plugin-URLs nach Rückstellung des Loxberry auf Port 80

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • mysterymind
    Azubi
    • 11.02.2022
    • 5

    #1

    Erreichbarkeit von Plugin-URLs nach Rückstellung des Loxberry auf Port 80

    Hallo community,

    ich betreibe auf den Loxberry neben den Plugins auch NoteRed und darunter eine Node zur Kommunikation mit Amazon Alexa. Diese benötigt zwingend Port 80 um eine Verbindung mit dem
    Amazon Echo herzustellen. Daher habe ich den Port des Loxberry von 80 auf 81 geändert.

    Nach langer Recherche musste ich jedoch feststellen, dass der Miniserver bei einem virtuellen HTTP-Eingang nur den geänderten Port 81 verwendet, wenn nach der Portangabe keine
    weiteren Argumente stehen. Geht der String nach :81 noch weiter wird automatisch der Port 80 verwendet.

    Nach dieser Erkenntnis habe ich die Alexa-Node auf eine andere NodeRed-Instanz (anderer Server) umgezogen und den Loxberry wieder von Port 81 auf Port 80 zurückgestellt. Dies hat
    leider nur teilweise funktioniert. Nach einem Neustart ist der Loxberry wieder unter Port 80 erreichbar. Jedoch gilt dies nur für die "normalen" Konfigurations-URLs. Die URLs der Plugins
    (hier u.a. Sonos und ebusd) laufen ins Leere (sind somit nicht unter Port 80 aber auch nicht mehr unter Port 81 erreichbar).

    Beispiel:

    http://user:passwort@loxberry/admin/...uit=ehp&update[]=HwcTemp&update[]=HeatPumpStatus&update[]=HcPress&update[]=SourcePress&update[]=OutsideTemp&update[]=currenterror

    Ist dieses Verhalten bekannt. Besteht hier die Möglichkeit per SSH Konfigurationsänderungen durchzuführen, damit die Kommunikation wieder funktioniert.

    Vielen lieben Dank vorab für ein paar Tipps!




  • svethi
    Lebende Foren Legende
    • 25.08.2015
    • 6318

    #2
    Irgendwie kann ich Deinen ganzen Ausführungen nicht folgen. Die Sache mit den HTTP Eingängen, die nicht zu Port 80 verbinden sollen, sollen nicht funktionieren? Da habe ich noch nichts davon gehört. Vielleicht ein Problem einer bestimmt Config-Version?
    Das Problem mit den Plugins kann ich noch viel weniger nachvollziehen. Wenn der Loxberry unter einem bestimmten Port erreichbar ist, dann sind es auch die Plugins. Es handelt sich um EINEN Webserver und wenn dieser erreichbar ist, ist er erreichbar. Mit Deinen Plugins ist natürlich klar, dass Du diese alle auf den Servern oder im Miniserver oder von wo auch immer Du diese aufrufst, musst Du DORT natürlich Deine Konfiguration ändern und auch DORT den richtigen Port eintragen. Im Falle von Port 80, kannst Du die Portangabe natürlich auch weglassen.
    Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)

    Kommentar

    • mysterymind
      Azubi
      • 11.02.2022
      • 5

      #3
      Hallo svethi,

      danke für die schnelle Antwort.

      Zitat von svethi
      Irgendwie kann ich Deinen ganzen Ausführungen nicht folgen. Die Sache mit den HTTP Eingängen, die nicht zu Port 80 verbinden sollen, sollen nicht funktionieren? Da habe ich noch nichts davon gehört. Vielleicht ein Problem einer bestimmt Config-Version?
      Ich hatte das gleiche Phänomen wie in diesem Beitrag:

      I have set up the ebusd plugin on my LoxBerry. It works well as long as the port set for my LoxBerry is port 80, but when I try to change it to port 81 (under LoxBerry services), the http connector on my Loxone does not work anymore, although I have specified the port 81 in the URL address (http://loxberry:Password@192.168.1.5..


      Bzgl. der Ports und des Webservers bin ich etwas weitergekommen. Es scheint mit DNS / IP-Konfiguration zu tun zu haben. Der Loxberry steht auf DHCP. Die Adressen vergibt eine Fritz!Box.

      Warum auch immer ist das System (ESXi VM) unter zwei IPv4-Adressen sowie einer IPv6-Adresse erreichbar. Rufe ich im Browser die ebusd-Pluginseite mit Hostnamen auf funktioniert es inzwischen. Der Miniserver (V2) kann die gleiche Adresse nicht erreichen (ggf. weil der Browser eine Verbindung über IPv6 aufbaut).

      Die beiden IPv4-Adressen kann ich über den Browser beide nicht erreichen (ERR_CONNECTION_REFUSED). Per Ping ist das System (IPv4) erreichbar. Sehr seltsam.

      Kommentar

      • Christian Fenzl
        Lebende Foren Legende
        • 31.08.2015
        • 11237

        #4
        Mir fällt spontan ein:
        User oder Passwort (genau das, was wir nie sehen) hat Zeichen anders als a-z/0-9. Kann schon sein, dass es den Miniserver damit „wirft“, wenn er die URL falsch parst.

        IP-Verhalten in einer VM: Keine Ahnung, haben wir nichts damit am Hut. Du kannst dir ja mal ansehen, was deine VM für IPs hat.
        Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine

        Kommentar

        • mysterymind
          Azubi
          • 11.02.2022
          • 5

          #5
          Danke Dir, Christian. Sonderzeichen im Passwort habe ich schonmal entfernt :-) Sicher ist sicher.

          Durch das Löschen des Geräts in der Fritz!Box und anschließendem Reboot des Loxberrys hat dieser nun nur noch eine IPv4- sowie eine IPv6-Adresse. Damit sollte eine weitere Fehlerquelle beseitigt sein. Leider kann ich über den Browser den Loxberry nach wie vor nur per Hostname erreichen (wahrscheinlich dann über IPv6). Die direkte Eingabe der IPv4-Adresse führt zu einer Zurückweisung. Kann dies ggf. an der Apache-Config liegen (das nur ein Adapter zugelassen wird)?

          Kommentar

          • Christian Fenzl
            Lebende Foren Legende
            • 31.08.2015
            • 11237

            #6
            In der Apache Config gibt’s keine IP, da gibt’s nur den Port.
            Wie gesagt, schau einfach mal, welche IP(s) dein LB hat.
            Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine

            Kommentar

            • mysterymind
              Azubi
              • 11.02.2022
              • 5

              #7
              Hab es mit Änderung der Netzwerkkartenkonfiguration im ESX (E1000 durch VMXNET ersetzt) hinbekommen. Manchmal liegen die Fehler eben doch ganz wo anders ...

              Vielen lieben Dank für Eure Bemühungen!

              Kommentar

              Lädt...