Ankündigung

Einklappen
Keine Ankündigung bisher.

KNXD: F00000105: [ 9:B.ipt] Link down, terminating

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    KNXD: F00000105: [ 9:B.ipt] Link down, terminating

    Hallo,

    ich bin leider am verzweifeln. Ich hatte ein seit 3 Jahren einwandfrei laufendes System mit Docker Containern für knxd, Smartvisu und SmarthomeNG. Dann habe ich ein Update des Host-Systems auf die neueste LTS Version Ubuntu 22.04.1 LTS gemacht. Smartvisu und SmarthomeNG liefen nach kleineren Anpassungen prima. Nur knxd bekomme ich partout nicht mehr zum laufen.

    Ich bin hier absolut ratlos - unten meine Versuche der Diagnose - kann mir irgendwer vielleicht weiterhelfen?

    Ich bekomme anscheinend keine Verbindung zum Gateway.
    Der KNX/IP-Router (Gira) ist/war korrekt eingerichtet und sowohl über ETS (Test erfolgreich) als auch per ping aus dem knxd Docker Container erreichbar.

    Aber knxd bricht wegen connection timeout ab.

    Leider habe ich keine Ahnung, wie ich die Erreichbarkeit des Ports 3671 prüfen kann, bzw. was ich tun kann, wenn er nicht erreichbar ist.
    ich habe bereits einen KNX Bus-reset gemacht und den Router mehrfach neu programmiert. Am Ende war er immer aus der ETS erreichbar. Starte ich den knxd daemon zegt er auch in ETS, daß das Gerät durch eine andere Verbindung geblockt ist. Stoppe ich den daemon, ist sie über ETS wieder erreichbar. Doch der daemon startet nach der Fehlermeldung alle paar Sekunden neu.

    Ich habe aus dem knxd docker container heraus telnet versucht (8080 funktionerte übrigens - 3671 nicht):
    Code:
    root@537da0cae23d:/# telnet 192.168.2.150 3671
    Trying 192.168.2.150...
    telnet: Unable to connect to remote host: Connection refused
    root@537da0cae23d:/#​
    Außerdem nmap (zeigt nur den http port 8080 an - ich weiß nicht, ob hier 3671 ebenfalls erscheinen sollte):
    Code:
    root@537da0cae23d:/# nmap -F 192.168.2.150
    Starting Nmap 7.70 ( https://nmap.org ) at 2022-12-10 16:59 UTC
    Nmap scan report for 192.168.2.150
    Host is up (0.00023s latency).
    Not shown: 99 closed ports
    PORT     STATE SERVICE
    8080/tcp open  http-proxy
    
    Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds
    root@537da0cae23d:/#​
    Und da 8080 ja offen ist, spasseshalber mal curl:
    Code:
    root@537da0cae23d:/# curl http://192.168.2.150:8080
    curl: (52) Empty reply from server
    root@537da0cae23d:/#​
    Die komplette knxd Ausgaben bis zum Abbruch/Neustart:
    Code:
    Starting knxd ... done
    Attaching to knxd
    knxd    | I00000131: [ 1:main] 0.14.30: knxd /etc/knxd.ini
    knxd    | I00000129: [ 1:main] Connected: cfg:B.ipt.
    knxd    | I00000129: [ 1:main] Connected: cfg:D.cache.
    knxd    | I00000129: [ 1:main] Connected: cfg:A.tcp.
    knxd    | W00000126: [ 1:main] knxd should not run as root
    knxd    | Layer 4 [ 1:main        0.000] initialized
    knxd    | Layer 4 [ 1:main        0.000] setting up
    knxd    | Layer 4 [ 5:D.cache/G      0.000] GroupCacheInit
    knxd    | Layer 3 [ 4:D.cache/Conn   0.000] registerLink: 4:D.cache
    knxd    | Layer 3 [ 6:A.tcp/inet     0.000] registerLink: 6:A.tcp
    knxd    | Layer 3 [ 9:B.ipt/Conn      0.000] registerLink: 9:B.ipt
    knxd    | Layer 4 [ 1:main            0.000] setup OK
    knxd    | Layer 4 [ 1:main            0.000] trigger going up
    knxd    | Layer 3 [ 9:B.ipt/Conn      0.000] Start: cfg:B.ipt
    knxd    | Layer 5 [ 9:B.ipt/Conn      0.000] down => >up
    knxd    | Layer 5 [ 9:B.ipt/Conn      0.000] Starting
    knxd    | Layer 2 [10:B.ipt/ipt       0.000] Open
    knxd    | Layer 2 [10:B.ipt/ipt       0.001] Opened
    knxd    | Layer 4 [ 9:B.ipt/Conn      0.001] >up
    knxd    | Layer 3 [ 4:D.cache/Conn    0.001] Start: cfg:D.cache
    knxd    | Layer 5 [ 4:D.cache/Conn    0.001] down => >up
    knxd    | Layer 5 [ 4:D.cache/Conn    0.001] Starting
    knxd    | Layer 5 [ 4:D.cache/Conn    0.001] >up => up
    knxd    | Layer 4 [ 4:D.cache/Conn    0.001] up
    knxd    | Layer 5 [ 4:D.cache/Conn    0.001] Started
    knxd    | Layer 4 [ 4:D.cache/Conn    0.001] up
    knxd    | Layer 3 [ 6:A.tcp/inet      0.001] Start: cfg:A.tcp
    knxd    | Layer 5 [ 6:A.tcp/inet      0.001] down => >up
    knxd    | Layer 5 [ 6:A.tcp/inet      0.001] >up => up
    knxd    | Layer 4 [ 6:A.tcp/inet      0.001] up
    knxd    | Layer 5 [ 6:A.tcp/inet      0.001] Started
    knxd    | Layer 4 [ 6:A.tcp/inet      0.001] up
    knxd    | Layer 4 [ 1:main            0.001] going up triggered
    knxd    | Layer 4 [ 1:main            0.001] check start
    knxd    | Layer 4 [ 9:B.ipt/Conn      0.001] is >up
    knxd    | Layer 4 [ 1:main            0.001] check end: want_up 1 some 1>1 all 0>0, going 1 up 2 down 0
    knxd    | F00000105: [ 9:B.ipt] Link down, terminating
    knxd    | Layer 5 [ 9:B.ipt/Conn      10.009] >up => down/error
    knxd    | Layer 4 [ 9:B.ipt/Conn      10.009] up/error
    knxd    | Layer 4 [ 1:main            10.009] check start
    knxd    | Layer 5 [ 9:B.ipt/Conn      10.009] Stopping
    knxd    | Layer 5 [ 9:B.ipt/Conn      10.009] up/error => down
    knxd    | Layer 4 [ 9:B.ipt/Conn      10.009] down/error
    knxd    | Layer 4 [ 9:B.ipt/Conn      10.009] is down
    knxd    | Layer 4 [ 1:main            10.009] check end: want_up 1 some 1>1 all 0>0, going 0 up 2 down 1
    knxd    | Layer 4 [ 1:main            10.009] trigger Going down
    knxd    | Layer 4 [ 9:B.ipt/Conn      10.009] Stopping
    knxd    | Layer 5 [ 9:B.ipt/Conn      10.009] down/error => >down
    knxd    | Layer 4 [ 9:B.ipt/Conn      10.009] down/error
    knxd    | Layer 4 [ 4:D.cache/Conn    10.009] Stopping
    knxd    | Layer 5 [ 4:D.cache/Conn    10.009] up => >down
    knxd    | Layer 5 [ 4:D.cache/Conn    10.009] Stopping
    knxd    | Layer 5 [ 4:D.cache/Conn    10.009] >down => down
    knxd    | Layer 4 [ 4:D.cache/Conn    10.009] down
    knxd    | Layer 4 [ 4:D.cache/Conn    10.009] down
    knxd    | Layer 4 [ 6:A.tcp/inet      10.009] Stopping
    knxd    | Layer 5 [ 6:A.tcp/inet      10.009] up => >down
    knxd    | Layer 5 [ 6:A.tcp/inet      10.009] >down => down
    knxd    | Layer 4 [ 6:A.tcp/inet      10.009] down
    knxd    | Layer 4 [ 6:A.tcp/inet      10.009] down
    knxd    | Layer 4 [ 1:main            10.009] check start
    knxd    | Layer 4 [ 9:B.ipt/Conn      10.009] is down
    knxd    | Layer 4 [ 4:D.cache/Conn    10.009] is down
    knxd    | Layer 4 [ 6:A.tcp/inet      10.009] is down
    knxd    | Layer 4 [ 1:main            10.009] check end: want_up 0 some 1>0 all 0>0, going 0 up 0 down 3
    knxd    | Layer 4 [ 1:main            10.009] down
    knxd    | Layer 4 [ 1:main            10.009] deleting
    knxd    | Layer 2 [10:B.ipt/ipt       10.010] Close
    knxd    | Layer 4 [ 5:D.cache/G       10.010] GroupCacheDestroy
    knxd    | N00000128: [ 1:main] Shutting down.
    knxd    | Layer 4 [ 5:D.cache/G       10.010] GroupCacheClear
    knxd    | Layer 4 [ 1:main            10.010] deleted.​
    Meine knxd.ini:
    Code:
    [A.tcp]
    server = knxd_tcp
    port = 6720
    
    [B.ipt]
    driver = ipt
    #filters = C.pace
    ip-address = 192.168.2.150
    #ip-address = localhost
    
    [C.pace]
    delay = 50
    filter = pace
    
    [D.cache]
    max-size = 200
    
    [E.debug]
    error-level = 0x9
    trace-mask = 0xfc
    
    [main]
    addr = 0.0.1
    debug = E.debug
    client-addrs=0.0.2:8
    cache = D.cache
    connections = A.tcp,B.ipt
    background = false
    #background = true​
    Der Vollständigkeit halber auch noch das Dockerfile und die docker compose:
    Code:
    #
    # knxd
    #
    
    FROM debian:buster
    
    LABEL maintainer "Andreas Leinen"
    LABEL description "knxd docker image"
    
    ENV LANG=de_DE.UTF-8
    
    RUN apt-get update \
        && apt-get install -y knxd knxd-tools iputils-ping
    
    COPY knxd.ini /etc/
    COPY knxd.conf /etc/
    CMD ["knxd", "/etc/knxd.ini"]
    ... und die docker-compose (ich habe schon einige images ausprobiert 😉, bevor ich dann mein eigenes gebaut habe)
    Code:
    version: '2'
    services:
        knxd:
            build:
              context: ./docker
            #image: tekn0ir/knxd:latest
            #image: renehezser/knxd
            container_name: knxd
        
            #image: renehezser/knxd
            #image: foxi352/knxd
            #image: tekn0ir/knxd
            #image: henfri/knxd:v0.12.6
            #
            volumes:
            - /home/andreas/docker/knxd/tmp:/tmp
            - /home/andreas/docker/knxd/etc:/etc
            # renehezser/knxd
            #- /home/andreas/docker/knxd/etc/knxd.ini:/config.ini
            ports:
            - "192.168.2.124:6720:6720"
            #- "192.168.2.124:3671:3671"
            # knxd erreichbar für SmarthomeNG (smarthome) über den Hostnamen knxd - dieser muss in der plugin.conf
            # unter smarthomeNGconfig/etc für das knx-Plugin entsprechend mit host = knxd eingetragen sein
            #network_mode: "host"
            command: "knxd /etc/knxd.ini"
            #entrypoint: "/entrypoint.sh"
            #command: "knxd -e 0.0.3 -E 15.15.249:8 -DTRS -c -i --send-delay=30 -B single -b iptn:192.168.2.150"
            #command: "/config/knxd.ini"
            restart: always
    Wäre Super, wenn mir jemand auf die Sprünge helfen könnte,
    Andreas

    #2
    Ganz ehrlich: Ich kenne absolut keinen Grund, wieso man den knxd nicht nativ auf der Kiste laufen lassen sollte – und sich damit das Gebastel mit Docker und Konsorten schlicht und einfach erspart. Weniger Ressourcen verbrät er dadurch außerdem.

    Bitte baue die aktuelle Version nativ, nicht die 0.14.30. Wie das geht steht im README. (Debian-Zweig.)

    PS, Port 3671 ist UDP. da wirst du mit Telnet eher wenig Chancen haben.

    DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

    Kommentar


      #3
      Net=Host war bei mir immer nötig.

      Kommentar


        #4
        Weniger Ressourcen verbrät er dadurch außerdem.
        Nicht wirklich

        https://stackoverflow.com/questions/...cker-container
        Ansonsten stimme ich dir zu.
        Bei Debian gibt es ja mittlerweile auch fertige Pakete. Und mittlerweile ist es auch nicht schwieriger, den knxd nativ zu bauen, als ein Dicker image

        Kommentar


          #5
          Uih, uih. uih. Ich äussere mich dazu ja so gut wie nicht mehr aber es ist so ein Parade-Beispiel dafür warum ich schon vor vielen Jahren nichts von solchen Konstruktionen wie Docker gehalten habe
          Es ist, wenn man darin nicht absoluter Profi mit täglichem Betrieb ist m.E. eben nahezu unbetreibbar. Zumindest nach dem ersten Update des Hosts..

          Dein Problem kann ich dir leider so direkt nicht lösen, aber evtl. ein paar Anregungen geben.
          - 3671/UDP KNXnet/IP wirste per Telnet nicht viel erreichen, mal ganz generell! Es gibt ein NMAP-Dings-Templates von mir von anno schnuff um den eibd/knxd damals auf "Vollgasfestigkeit" und Funktion (zur möglichen Zertifizierung) zu testen, aber die helfen dir vermutlich auch nix Weil bis auf den eibd/knxd wo dann die Bugs ausgeräumt wurden(!) und den Enertex hat das Script kein Gerät am Markt ohne reboot überlebt (ok, das war teils provoziert weil ich es halt "Vollgasfest" wollte)

          Die anderen Ports haben Kollegen schon erklärt.

          Also, Tipps vom Küken: wie mach ich das seit einigen Jahren:
          - Nix Docker! nix Raspi-bastelwastel sondern physikalische x86 Hardware(sei es nun ALIX,APU,NUC,..)
          Wenns nicht deine Entwicklungsumgebung am Schreitisch ist, lass sowas weg.. VirtualBox oder VMWare mit Netzwerk-Bridge geht auch grad noch ganz gut zum testen aber danach wird das Eis halt sehr dünn. Erfahrung.
          Und Sinn macht es auch nicht unbedingt immer, da ist so ein "Stapel" an x86 Rechnern manchmal sogar erheblich stromsparender und vor allem leichter und unabhängiger(!) in der Pflege/Updates etc.
          Das WG1 braucht weniger Strom als fast alle KNXnet/IP-Router die ich kenne im Betrieb, so what.. Hab ich halt 2-3 davon im EFH, fällt eins aus (1x passiert in 15J!!) geht halt die X10 Fernbedienung für 24h nicht mehr aber die Heizung läuft
          Das WireGate1 mit nem alten eibd läuft seit 2007 durch , einmal die CF-Karte getauscht (nicht die, die wir ausgeliefert haben! sondern eine stinkenormale MLC aus meiner Kamera damals - ich wollte wissen wann sie stirbt)
          Tägliches Backup per simplem Cron-Job und dd auf NAS, keine "fancy" Tools, kein garnix..
          TimeToRecover mit einem 80€ Alix-Board und einer 15€ CF (die ausgelieferten SLC kosteten glaube ich schon 50-80€ im EK) im heimischen Ersatzteilschrank, ein Kartenleser: 1-2h.. Fertig.

          Nur so eine Anregung für den Threadersteller: KISS Keep it simple stupid, bevor ich mich heute ewig mit Docker, fremden Images, disfunktionalitäts-Gefahr bei jedem Update rumschlage...

          just meine 5ct, Makki


          P.S.: was ich da aus rund 15J Livebetrieb eines Smarthome gelernt habe adaptiere ich umsomehr auch aufs Schiff: KISS, Funktionstrennung, Ersatzteile aber keine anfälligen Redundanzen (die im Notfall kollektiv versagen wenn alles auf einer Kiste mit Docker etc. läuft)
          EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
          -> Bitte KEINE PNs!

          Kommentar


            #6
            Sorry henfri der Nachschlag muss sein:

            ​Das ist quatsch, jedwedes für was auch immer zusammengefuddeltes (VM, "Container", docker,...) wird jemals denselben schlanken Fussabdruck (Resourcennutzung) wie eine native C(++) Anwendung erreichen. Es mag nur bequemer sein..

            Bei Debian gibt es ja mittlerweile auch fertige Pakete. Und mittlerweile ist es auch nicht schwieriger, den knxd nativ zu bauen, als ein Dicker image
            Dicker war gut trifft es auf den Punkt Wer die Debian-Packerl erstellt und Upstream gebracht hat, lass mich mal kurz überlegen..

            Makki
            EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
            -> Bitte KEINE PNs!

            Kommentar


              #7
              Hallo Makki,
              schön, von dir zu hören.

              Zumindest nach dem ersten Update des Hosts..
              Das verstehe ich nicht. Das ist doch das schöne an Docker: Dass man sehr unabhängig vom Host ist.
              Ich bin kein Experte. Aber bei mir war ein Update vom host kein Problem.
              Das war bei selbst kompilierter SW oder noch schlimmer bei Paketen aus fremden Quellen/ppas oft anders.

              Kommentar


                #8
                Code:
                wie eine native C(++) Anwendung erreichen
                Eine Docker Anwendung läuft nativ auf dem Kernel. Quasi in einem chroot.
                Es ist eine native Anwendung.
                Sicher kann es dennoch einen Overhead geben.
                Aus dem o.g. Link
                Docker is nearly identical to native performance
                Screenshot_20221210-235349.png
                Das ist aus einem wissenschaftlichen Paper und kein Marketing.
                Der mögliche Overhead ist also in der Praxis nicht relevant. Auch wenn das Einigen nicht passt.
                Zuletzt geändert von henfri; 10.12.2022, 23:54.

                Kommentar


                  #9
                  Und bevor man auf doofe Gedanken kommt, ich hab auch schon ne ESXi Infrastruktur (12 Hosts und 20 davor, getrennte VS Umgebungen) projektiert, mitentworfen und umgesetzt (umgesetzt heisst nicht nur die HW bestellt sondern auch die selbst die Kisten in die Racks geschraubt..)
                  Alles fein mit der Virtualisierung, nur halte ich das im Smarthome-Keller halt nicht für die beste Idee ohne 24x7 RZ/NOC, 1J Projektplanung etc. - daher mein Tipp an den TE: KISS, lieber 5 kisterl mit 5W Watt mehr..

                  Makki
                  EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                  -> Bitte KEINE PNs!

                  Kommentar


                    #10
                    Zitat von henfri Beitrag anzeigen
                    Code:
                    wie eine native C(++) Anwendung erreichen
                    Eine Docker Anwendung läuft nativ auf dem Kernel. Quasi in einem chroot.
                    Es ist eine native Anwendung.
                    Sicher kann es dennoch einen Overhead geben.
                    Aus dem o.g. Link
                    Screenshot_20221210-235349.png
                    Das ist aus einem wissenschaftlichen Paper und kein Marketing.
                    Der mögliche Overhead ist also in der Praxis nicht relevant. Auch wenn das Einigen nicht passt.
                    Glaube nur der Statistik, die du selbst gefälscht hast (Winston Churchill)

                    Da läuft genau garnix "nativ" weder unter Linux, Windows, Docker noch unter VMWare, VBox.. Ne?
                    "Nativ" ist ein ASM-Code auf einem uC, selbst durch den Compiler/Interpreter ist der schon wieder "Fake"
                    Ich hatte mir mal den Spass gemacht für einen 1-Wire Sensor ein bisschen Beispielcode von Atmel für einen AtMega644 auf einen Attiny84 mit sleep usw auf 1/5 der Grösse und 1/100 (!!) des Stromverbauchs "einzudampfen" - es reichte dann ein kleiner Kondensator zur parasitären Stromversorgung über 1Wire - kam so leider nie auf den Markt. Nur ein Beispiel.

                    Der Overhead bzw. Schlamperei bei der Sorgfalt in der Entwicklung ist sehr wohl relevant! Interessiert halt nur (fast) keinen, aber das Strom teuer, Gas, Öl, Kernkraft eh böse usw. das ist da dann egal.

                    Provokante Frage: oder warum brauche ich heute mind einen Core i3 am PC um BubbleBobble oder Tetris am Gameboy zu spielen.. Inhalt und Grafik, Anforderung an die Rechenleistung haben sich nicht geändert..

                    P.S.: ich hab irgendwann in der Schule mal als "Projektaufgabe" in der 8/9. Klasse (Informatik war damals Wahlfach - sollte Pflichtfach sein! vor allem für zukünftige BWL-Studenten..) einen Zinseszins-Rechner in Pascal geschrieben.
                    Verstanden hat es keiner, auch nicht der Lehrer, warum ich irre Stolz drauf war das es auf dem Schul-PC (irgendein 286er glaube ich) genauso schnell lief wie auf meinem 386DX40 zuhause und der Code auch auf dem Atari520ST funktionierte..

                    Was ich damit sagen will: es wäre manchmal evtl. sinnvoll darüber nachzudenken, was es bedeutet wenn man ohne jegliche Rücksicht auf Verluste, Rechenleistung, (Energie)Effizienz das "einfach mal so macht, weil man es ja kann"

                    Und damit meine ich z.B. Docker, Virtualisierung Ok aus meiner Sicht aber das ist m.E. total unnötige und zumeist ineffiziente Bloatware

                    Makki
                    EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                    -> Bitte KEINE PNs!

                    Kommentar


                      #11
                      Zitat von henfri Beitrag anzeigen
                      Der mögliche Overhead ist also in der Praxis nicht relevant. Auch wenn das Einigen nicht passt.
                      Und damit entlarst du dich eigentlich selbst, wenn man nur die Grafiken anguckt ist sonnenklar worum es dabei ging (irgendsowas wie kauft SAP, schickt die OSS-Spinner mit MySQL in die Wüste, keine Ahnung)
                      Das kann ich dir sogar raten, obwohl die Zahlen augenscheinlich erstmal was anderes sagen (Aufmerksamkeitsspanne von BWL-Absolventen zwischen den Meetings ist halt drastisch verringert, das nutzt man eben aus.
                      Ich kann ja für diese "Präsentation" ( eigentlich würde ich gefälschte/friesierte Lügenfolien von Unternehmensberatern und IT-Laien Laien dazu sagen) mehrere Motive vermuten:
                      Sie wollten irgendwas "verkaufen", ich weiss ja nicht was - aber selbst das können sie da nicht komplett kaschieren: Betreibe deinen DB-Server halt selbst, nativ ohne Kühe und Docker
                      Bei Datenbank-Transaktionen, sei es nun Netflow-Export, Syslog oder Finanzmarkt mit Millionen darf die Verlustschwelle bei exakt 0,0000% liegen, sonst isses kaputt

                      Makki
                      EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                      -> Bitte KEINE PNs!

                      Kommentar


                        #12
                        Die Grafiken sind echt niedlich, blenden aber zB Speicherverbrauch und evtl Cache-Overhead durch die doppelt und dreifach geladene libc konsequent aus. Das stört natürlich nicht, wenn man auf der Möhre zum Testen nur den mysql betreibt und sonst gar nix, aber sobald die Kiste noch was Anderes zu tun hat kann das ganz anders aussehen.

                        Wie dem auch sei, das ist hier nicht das Thema. Fakt ist, Docker hat noch andere Nachteile: eine Sicherheitslücke im Host ist mit dem nächsten "apt upgrade" weg, aber das Dockerding schleppt sie noch mit sich rum bis man das auch geupdatet hat. Und man muss zusätzlich zum knxd-Wissen auch rudimentäre Kenntniss über Docker mitbringen und leidlich aktuell halten.

                        Dazu gehört auch die Tatsache, dass das Tier ohne net=host (oder, wenn man wirklich ein brauchbar isoliertes Image haben will, net=ipvlan oder macvlan! aber dann wird die Konfiguration des Tiers definitiv nichttrivial) mit UDP nur leidlich und mit Multicasts gar nicht klarkommt. Und der knxd nutzt halt Beides …

                        Allein die magische "net=host" Formel wusste ich auch mal, hab sie nur wieder vergessen – und werde sie, weil ich Docker und Konsorten nicht nutze (und weil mit net=host die halbe Isolation, die Docker eigentlich bringen soll, futsch ist), auch gleich wieder vergessen.

                        Und deshalb gibt's hier im Zweifelsfall keinen Support für knxd-auf-Docker. Jedenfalls nicht von mir.
                        Zuletzt geändert von Smurf; 11.12.2022, 10:22.
                        DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

                        Kommentar


                          #13
                          Zitat von makki Beitrag anzeigen
                          Glaube nur der Statistik, die du selbst gefälscht hast (Winston Churchill)
                          Sorry, aber auf dem Level möchte ich nicht diskutieren.
                          Ich nenne eine Quelle, deren Ergebnis passt Dir nicht und dann implizierst du, dass die Ergebnisse gefälscht seien.

                          @smurf: Ich kann nachvollziehen, dass der RAM Bedarf höher ist. apt upgrade funktioniert so lange gut, wie man nur SW der Distri nutzt. Wie oft war ich schon in der Versions-Konflikt-Hölle. SW A brauch libX-1.0.0 oder niedriger, SW B braucht libX-1.5.4, oder höher.

                          Beim KNXd -da stimme ich dir zu- gibt es aber unter Debian und Ubuntu keinen Grund mehr für Docker.

                          Gruß,
                          Hendrik
                          Zuletzt geändert von henfri; 11.12.2022, 11:35.

                          Kommentar


                            #14
                            ALEI
                            Du hast `network_mode: "host"` in deinem Docker-compose auskommentiert. Ohne gibts auf jeden Fall kein Multicast. Und ob knxd überhaupt ohne auskommt weiß ich ned.

                            Wenn du ports für UDP in compose weiterleiten willst müsstest du das jedenfalls explizit angeben. Siehe https://stackoverflow.com/questions/...-it-tcp-or-udp Aber wäre ja bei host network eh nicht nötig.

                            Kommentar


                              #15
                              Hallo,

                              Zitat von Smurf Beitrag anzeigen
                              Bitte baue die aktuelle Version nativ, nicht die 0.14.30. Wie das geht steht im README. (Debian-Zweig.)
                              als Laie habe ich es nach 2 Stunden hinbekommen ein eigenes Build zu erstellen. 😅

                              Leider hat das noch keinen Effekt gebracht - gleicher Fehler wir vorher.

                              Das neue Dockerfile
                              Code:
                              #
                              # knxd
                              #
                              
                              FROM debian:buster
                              
                              LABEL maintainer "Andreas Leinen"
                              LABEL description "knxd docker image"
                              
                              ENV LANG C.UTF-8
                              
                              RUN apt-get update \
                                  && apt-get install -y git-core sudo
                              
                              # get the source code
                              RUN git clone -b debian https://github.com/knxd/knxd.git
                              
                              # now build+install knxd
                              RUN cd knxd \
                                  && sudo apt-get install --yes --no-install-recommends build-essential devscripts equivs \
                                  && sudo mk-build-deps --install --tool='apt-get --no-install-recommends --yes --allow-unauthenticated' debian/control \
                                  && rm -f knxd-build-deps_*.deb \
                                  && dpkg-buildpackage -b -uc \
                                  && cd .. \
                                  && sudo dpkg -i knxd_*.deb knxd-tools_*.deb \
                                  && sudo apt remove --yes --autoremove knxd-build-deps
                              
                              #RUN adduser knxd --disabled-password
                              
                              USER knxd
                              WORKDIR /home/knxd
                              
                              COPY knxd.ini /etc/
                              COPY knxd.conf /etc/
                              CMD ["knxd", "/etc/knxd.ini"]
                              Zitat von Smurf Beitrag anzeigen
                              PS, Port 3671 ist UDP. da wirst du mit Telnet eher wenig Chancen haben.

                              Also ein Versuch mit netcap... (zumindest scheint ein Dienst zu existieren)
                              Code:
                              root@652e3daba6a8:/# nc -vz 192.168.2.150 8080
                              192.168.2.150: inverse host lookup failed: Unknown host
                              (UNKNOWN) [192.168.2.150] 8080 (?) open
                              root@652e3daba6a8:/# nc -vz -u 192.168.2.150 3671
                              192.168.2.150: inverse host lookup failed: Unknown host
                              (UNKNOWN) [192.168.2.150] 3671 (?) open
                              root@652e3daba6a8:/#
                              Zitat von henfri Beitrag anzeigen
                              Net=Host war bei mir immer nötig.
                              Zitat von meti Beitrag anzeigen
                              Du hast `network_mode: "host"` in deinem Docker-compose auskommentiert. Ohne gibts auf jeden Fall kein Multicast. Und ob knxd überhaupt ohne auskommt weiß ich ned.
                              Ich habe nun sowohl mal mit network_mode: "host" gearbeitet als auch dem Port 3671 freigeschaltet - beides hat nichts gebracht. Warum ich den Port 3671 weiterleiten soll habe ich ehrlich nicht verstanden. Mein KDX Router (Gira) unter 192.168.2.150 muß doch auf dem Port lauschen - warum soll ich den Port auch auf dem kndx server freischalten?

                              Zitat von Smurf Beitrag anzeigen
                              Und deshalb gibt's hier im Zweifelsfall keinen Support für knxd-auf-Docker. Jedenfalls nicht von mir.

                              Da ich ohnehin nicht weiter weiß, habe ich nun das Build für kndx direkt auf dem Host unter Ubuntu 22.04.1 LTS laufen lassen.

                              bis hierhin ging es gut:
                              Code:
                              ...
                              ...
                              + : 4 Install knxd. Have fun.
                              + sudo dpkg -i knxd_0.14.56.2_amd64.deb knxd-tools_0.14.56.2_amd64.deb
                              Selecting previously unselected package knxd.
                              (Reading database ... 107516 files and directories currently installed.)
                              Preparing to unpack knxd_0.14.56.2_amd64.deb ...
                              Unpacking knxd (0.14.56.2) ...
                              Selecting previously unselected package knxd-tools.
                              Preparing to unpack knxd-tools_0.14.56.2_amd64.deb ...
                              Unpacking knxd-tools (0.14.56.2) ...
                              Setting up knxd (0.14.56.2) ...
                              addgroup: The group `knxd' already exists as a system group. Exiting.
                              Warning: The home dir /var/lib/knxd you specified already exists.
                              The system user `knxd' already exists. Exiting.
                              Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 142.
                              A dependency job for knxd.service failed. See 'journalctl -xe' for details.
                              invoke-rc.d: initscript knxd, action "start" failed.
                              ○ knxd.service - KNX Daemon
                                   Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
                                   Active: inactive (dead)
                              TriggeredBy: × knxd.socket
                              
                              Dec 11 12:10:01 home.server systemd[1]: Dependency failed for KNX Daemon.
                              Dec 11 12:10:01 home.server systemd[1]: knxd.service: Job knxd.service/start failed with result 'dependency'.
                              Dec 11 12:10:02 home.server systemd[1]: Dependency failed for KNX Daemon.
                              Dec 11 12:10:02 home.server systemd[1]: knxd.service: Job knxd.service/start failed with result 'dependency'.
                              Dec 11 12:18:13 home.server systemd[1]: Dependency failed for KNX Daemon.
                              Dec 11 12:18:13 home.server systemd[1]: knxd.service: Job knxd.service/start failed with result 'dependency'.
                              Dec 11 12:18:14 home.server systemd[1]: Dependency failed for KNX Daemon.
                              Dec 11 12:18:14 home.server systemd[1]: knxd.service: Job knxd.service/start failed with result 'dependency'.
                              dpkg: error processing package knxd (--install):
                               installed knxd package post-installation script subprocess returned error exit status 1
                              Setting up knxd-tools (0.14.56.2) ...
                              Processing triggers for ureadahead (0.100.0-21) ...
                              Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
                              Errors were encountered while processing:
                               knxd
                              Ok, also manueller Start...
                              Code:
                              andreas@home:~/docker/knxd/build$ knxd ../etc/knxd.ini
                              Layer 4 [ 1:main        0.000] initialized
                              I00000131: [ 1:main] 0.14.56.2: knxd ../etc/knxd.ini
                              Layer 4 [ 1:main        0.000] setting up
                              Layer 4 [ 5:D.cache/G      0.000] GroupCacheInit
                              Layer 3 [ 4:D.cache/Conn   0.000] registerLink: 4:D.cache
                              Layer 3 [ 6:A.tcp/inet        0.000] registerLink: 6:A.tcp
                              Layer 3 [10:B.ipt/Conn        0.000] registerLink: 10:B.ipt
                              I00000129: [ 1:main] Connected: cfg:B.ipt.
                              I00000129: [ 1:main] Connected: cfg:A.tcp.
                              I00000129: [ 1:main] Connected: cfg:D.cache.
                              Layer 4 [ 1:main              0.000] setup OK
                              Layer 4 [ 1:main              0.000] trigger going up
                              Layer 3 [10:B.ipt/Conn        0.000] Start: cfg:B.ipt
                              Layer 5 [10:B.ipt/Conn        0.000] down => >up
                              Layer 5 [10:B.ipt/Conn        0.000] Starting
                              Layer 2 [11:B.ipt/ipt         0.000] Open
                              Layer 2 [11:B.ipt/ipt         0.000] Opened
                              Layer 4 [10:B.ipt/Conn        0.000] link state changed: >up
                              Layer 3 [ 6:A.tcp/inet        0.000] Start: cfg:A.tcp
                              Layer 5 [ 6:A.tcp/inet        0.000] down => >up
                              E00000013: [ 6:A.tcp] OpenInetSocket 6720: bind: Address already in use
                              Layer 5 [ 6:A.tcp/inet        0.000] >up => error
                              Layer 4 [ 6:A.tcp/inet        0.000] link state changed: error
                              Layer 4 [ 6:A.tcp/inet        0.000] link state changed: error
                              Layer 3 [ 4:D.cache/Conn      0.000] Start: cfg:D.cache
                              Layer 5 [ 4:D.cache/Conn      0.000] down => >up
                              Layer 5 [ 4:D.cache/Conn      0.000] Starting
                              Layer 5 [ 4:D.cache/Conn      0.000] >up => up
                              Layer 4 [ 4:D.cache/Conn      0.000] link state changed: up
                              Layer 5 [ 4:D.cache/Conn      0.000] Started
                              Layer 4 [ 4:D.cache/Conn      0.000] link state changed: up
                              Layer 4 [ 1:main              0.000] going up triggered
                              Layer 4 [ 1:main              0.000] check start
                              Layer 4 [10:B.ipt/Conn        0.000] state is >up
                              Layer 4 [ 1:main              0.000] check end: want_up 1 some 1>1 all 0>0, going 1 up 1 down 1
                              F00000105: [ 6:A.tcp] Link down, terminating
                              Layer 4 [ 1:main              0.000] trigger Going down
                              Layer 4 [10:B.ipt/Conn        0.000] R Stopping
                              Layer 5 [10:B.ipt/Conn        0.000] >up => >down
                              Layer 5 [10:B.ipt/Conn        0.000] L Stopping
                              Layer 5 [10:B.ipt/Conn        0.000] >down => down
                              Layer 4 [10:B.ipt/Conn        0.000] link state changed: down
                              Layer 4 [10:B.ipt/Conn        0.000] link state changed: down
                              Layer 4 [ 6:A.tcp/inet        0.000] R Stopping
                              Layer 5 [ 6:A.tcp/inet        0.000] error => >down
                              Layer 4 [ 6:A.tcp/inet        0.000] link state changed: error
                              Layer 4 [ 4:D.cache/Conn      0.000] R Stopping
                              Layer 5 [ 4:D.cache/Conn      0.000] up => >down
                              Layer 5 [ 4:D.cache/Conn      0.000] L Stopping
                              Layer 5 [ 4:D.cache/Conn      0.000] >down => down
                              Layer 4 [ 4:D.cache/Conn      0.000] link state changed: down
                              Layer 4 [ 4:D.cache/Conn      0.000] link state changed: down
                              Layer 4 [ 1:main              0.000] check start
                              Layer 4 [10:B.ipt/Conn        0.000] is down
                              Layer 4 [ 4:D.cache/Conn      0.000] is down
                              Layer 4 [ 1:main              0.000] check end: want_up 0 some 1>0 all 0>0, going 0 up 0 down 3
                              Layer 4 [ 1:main              0.000] down
                              N00000128: [ 1:main] Shutting down.
                              Layer 4 [ 1:main              0.000] deleting
                              Layer 2 [11:B.ipt/ipt         0.000] Close A
                              Layer 4 [ 5:D.cache/G         0.000] GroupCacheDestroy
                              Layer 4 [ 5:D.cache/G         0.000] GroupCacheClear
                              Layer 4 [ 1:main              0.000] deleted.
                              andreas@home:~/docker/knxd/build$
                              also, leider auch keine Verbindung direkt auf dem Host.

                              Hat vielleicht noch jemand eine Idee, wie man hier weiter analysieren könnte?

                              Kommentar

                              Lädt...
                              X