Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[AxelG]

Erstmal danke, dass ihr alle so schnell reagiert :-)

@thomas-braun

das hatte ich schon das ein oder andere mal gemacht. Ich habe auch Deinen Werkzeugkasten entdeckt und dies hier als output:

iob@iobroker:~ $ type -P nodejs && nodejs -v && type -P node && node -v && type -P npm && npm -v && type -P npx && npx -v && apt policy nodejs 
/usr/bin/nodejs
v18.17.1
/usr/bin/node
v18.17.1
/usr/bin/npm
9.6.7
/usr/bin/npx
9.6.7
nodejs:
  Installed: 18.17.1-deb-1nodesource1
  Candidate: 18.17.1-deb-1nodesource1
  Version table:
 *** 18.17.1-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_18.x bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     12.22.12~dfsg-1~deb11u4 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages

Dennoch habe ich das nochmal durchgeführt und "iob nodejs-update" liefert nun:

ioBroker nodejs fixer 2023-10-13

Recommended nodejs-version is: 18.18.2
Checking your installation now. Please be patient!

Your current setup is:
/usr/bin/nodejs         v18.17.1
/usr/bin/node           v18.17.1
/usr/bin/npm            9.6.7
/usr/bin/npx            9.6.7
/usr/bin/corepack       0.18.0

We found these nodejs versions available for installation:

nodejs:
  Installed: 18.17.1-deb-1nodesource1
  Candidate: 18.17.1-deb-1nodesource1
  Version table:
 *** 18.17.1-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_18.x bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     12.22.12~dfsg-1~deb11u4 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages



Nothing to do - Your installation is using the correct paths.

You are running nodejs v18.17.1. Do you want to install recommended version 18.18.2? 

Press <y> to continue or any other key to quit
Trying to update your installation now. Please be patient.
Waiting for ioBroker to shut down - Give me a minute...
############################################################

*** These repos are active on your system:
Hit:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
Hit:2 https://packages.grafana.com/oss/deb stable InRelease                                                                                  
Hit:3 https://repos.influxdata.com/debian bullseye InRelease                                                                                 
Hit:4 http://archive.raspberrypi.org/debian bullseye InRelease  
Reading package lists... Done             

*** Installing ca-certificates, curl and gnupg, just in case they are missing.

*** Creating new /etc/apt/sources.list.d/nodesource.list and pinning source

deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_18.x nodistro main
Package: nodejs
Pin: origin deb.nodesource.com
Pin-Priority: 1001

*** These repos are active after the adjustments:
Hit:1 http://archive.raspberrypi.org/debian bullseye InRelease
Get:2 https://deb.nodesource.com/node_18.x nodistro InRelease [12.1 kB]                                                                      
Hit:3 http://raspbian.raspberrypi.org/raspbian bullseye InRelease                                                                            
Hit:4 https://repos.influxdata.com/debian bullseye InRelease                                                                    
Hit:5 https://packages.grafana.com/oss/deb stable InRelease                  
Get:6 https://deb.nodesource.com/node_18.x nodistro/main armhf Packages [6155 B]
Fetched 18.3 kB in 1s (18.2 kB/s)
Reading package lists... Done

Installing the recommended nodejs version now!

Installing the recommended nodejs version!
(Reading database ... 66518 files and directories currently installed.)
Preparing to unpack .../nodejs_18.18.2-1nodesource1_armhf.deb ...
Detected old npm client, removing...
Unpacking nodejs (18.18.2-1nodesource1) over (18.17.1-deb-1nodesource1) ...
Setting up nodejs (18.18.2-1nodesource1) ...
Processing triggers for man-db (2.9.4-2) ...

We tried our best to fix your nodejs. Please run iob diag again to verify.

*** RESTARTING ioBroker NOW! *** 
 Please refresh or restart your browser in a few moments.

martian sources gibt es leider immer noch :-/ :)

[Thomas Braun]

@axelg sagte in "martian source" flutet dmesg und log files auf meinem PC:

martian sources gibt es leider immer noch

Ja, natürlich. Das hat ja auch nix mit dem ioBroker sondern mit deinem Netzwerkaufbau zu tun. Aber da hab ich nicht viel Ahnung von.

[AxelG]

@homoran

Auch Dir ein Dankeschön, für die irre schnelle Reaktion!!!

iob diag läuft und nun lerne ich, dass ich das wohl besser in eine Datei umgeleitet hätte :-) Give me a sec, ich mache das gleich nochmal und dann zip und scp zurück auf meinen PC....

[AxelG]

@homoran
erstmal das Summary:

======================= SUMMARY =======================
                        v.2023-10-10


   Static hostname: iobroker
         Icon name: computer
  Operating System: Raspbian GNU/Linux 11 (bullseye)
            Kernel: Linux 6.1.21-v8+
      Architecture: arm64

Installation:           native
Kernel:                 aarch64
Userland:               armhf
Timezone:               Europe/Berlin (CET, +0100)
User-ID:                1000
X-Server:               false
Boot Target:            multi-user.target

Pending OS-Updates:     0
Pending iob updates:    0

Nodejs-Installation:    /usr/bin/nodejs         v18.18.2
                        /usr/bin/node           v18.18.2
                        /usr/bin/npm            9.8.1
                        /usr/bin/npx            9.8.1
                        /usr/bin/corepack       0.19.0

Recommended versions are nodejs 18.18.2 and npm 9.8.1
Your nodejs installation is correct

MEMORY: 
               total        used        free      shared  buff/cache   available
Mem:            7.8G        1.6G        5.1G        1.0M        1.1G        6.2G
Swap:             0B          0B          0B
Total:          7.8G        1.6G        5.1G

Active iob-Instances:   34
Active repo(s): stable

ioBroker Core:          js-controller           5.0.16
                        admin                   6.12.0

ioBroker Status:        iobroker is running on this host.


Objects type: jsonl
States  type: jsonl

Status admin and web instance:
+ system.adapter.admin.0                  : admin                 : iobroker                                 -  enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin
+ system.adapter.web.0                    : web                   : iobroker                                 -  enabled, port: 8082, bind: 0.0.0.0, run as: admin

Objects:                8223
States:                 6947

Size of iob-Database:

25M     /opt/iobroker/iobroker-data/objects.jsonl
5.8M    /opt/iobroker/iobroker-data/states.jsonl



=================== END OF SUMMARY ====================

[Thomas Braun]

@axelg sagte in "martian source" flutet dmesg und log files auf meinem PC:

dass ich das wohl besser in eine Datei umgeleitet hätte

Passiert automatisch. Liegt im home vom iobroker herum.

[AxelG]

@thomas-braun

Verstehe... nur habe ich da am 23.10 nichts geändert. Allerdings habe ich die Erfahrung schon von Gentoo, dass ein System irgendwann seine Toleranz abwirft. Sprich man hatte immer schon was falsch und an dem Tag an dem die Toleranz wegbricht hat man eigentlich nichts geändert und kommt deswegen nicht auf den eigentlichen Fehler....

Am Ende ist es oft ein 30cm Problem, das kann ich mir schon denken...

[AxelG]

@thomas-braun
ich gehe auf die Suche

[AxelG]

@thomas-braun leider nein. Redirected-run läuft

[Thomas Braun]

@axelg

echad@chet:~ $ ls -la /home/iobroker/iob_diag.log
-rw-r--r-- 1 iobroker iobroker 24220 Nov 20 17:14 /home/iobroker/iob_diag.log
echad@chet:~ $

Das Log muss da liegen. Liegt es immer...

[Thomas Braun]

@axelg

https://de.m.wikipedia.org/wiki/Martian_Packet

Ist eine Fehlkonfiguration im Netzwerk, würde ich behaupten.

[AxelG]

@thomas-braun

sorry, dass das etwas gedauert hat:

gemein..., es gibt ein /home/iob und ein /home/iobroker. In letzterem fand ich nun das File, genau wie Du sagst....

iob_diag.log

[AxelG]

@thomas-braun

Ja, sowas in der Art habe ich auch schon gefunden. Nur weiß grad nicht, was ich ändern müsste, denn es ist nach meiner Wahrnehmung nicht so gänzlich falsch und ich habe da unlängst nichts dran geändert und witzigerweise bekomme ich die selbe Message nicht auf dem NIC "C)" welches an dem selben Switch hängt (der eben noch kein V-Lan konfiguriert hat)

[Thomas Braun]

@axelg

Wie gesagt: muss sich ein Netzwerker anschauen, ich hab da keine Ahnung von.

[AxelG]

Die DAIKIN Geräte (tatsächlich gibt es auch noch ein Daikin.0 ---klar) zicken auch erst seit einiger Zeit... Früher waren die immer sauber online. Ob das "related" ist, weiß ich nicht, kann es aber auch nicht ausschließen.

[Marc Berg]

@axelg sagte in "martian source" flutet dmesg und log files auf meinem PC:

aber erst seit 23.10.2023 habe ich das Problem, dass ich "martian sources" auf "B)" empfange und dies mein dmesg und /var/log/messages bis zur Unkenntlichkeit zumüllt.

Das ist eigentlich ein normales Verhalten, wenn man mehrere Netze in eine Broadcast Domain klatscht. Das beantwortet natürlich nicht, warum es seit dem 23.10. so geballt auftritt. Sind die Adressen 192.168.178.72, .73, .76 noch im DNS verfügbar und ggf. auf dem Raspi als Name oder IP-Adresse in Scripten oder Adaptern hinterlegt? Was sind/waren das für Geräte?

[AxelG]

@marc-berg said in "martian source" flutet dmesg und log files auf meinem PC:

wenn man mehrere Netze in eine Broadcast Domain klatscht.

Sorry, dass ich erst jetzt wieder "auftauche". Was ist damit gemeint "in eine Domain klatscht"???? Mir ist keine unsaubere Konfig bewusst

Meine Erfahrung mit Gentoo ist, dass Fehlkonfigurationen eine Zeit tolleriert wurden und irgendwann wird eine Software strenger und plötzlich geht was nicht mehr. Dann steht man vor einem Problem, obwohl man doch gar nichts geändert hat im fraglichen Zeitraum... Sowas könnte auch hier im Oktober passiert sein und so zu der Häufung geführt haben.

.72 bis .75 sind meine Daikin Geräte. Da habe ich tatsächlich auch ein Problem, das ich nicht beheben kann. Siehe https://github.com/Apollon77/ioBroker.daikin/issues/18#issuecomment-1828697627

.76.... keine Ahnung, leider...

Ich habe heute mit Wireshark weiter geschaut und sehe da eben die ARP-requests (Who has....?) in unnatürlicher Menge

Dann habe ich versucht herauszufinden, welcher Service so "rumbrüllt" :-)

while ! ss -p state syn-sent | grep 192.168.178.76; do sleep .1; done

tcp   0      1      192.168.178.119:60454 192.168.178.76:9090

Mit "iobroker stop" fahren die ARP requests fort

Wenn ich jedoch den Service mit "systemctl stop iobroker.service" beende, dann enden auch die ARP-requests.

Also denke ich heute doch wieder, dass dies ein Bug ist und wünschte mir, dass dieser Thread wieder nach Error/Bug verschoben wird. @Homoran was denkst Du dazu?

Für heute muss ich leider ins Bett, denn dummerweise muss ich, wie die meisten wohl, meine Brötchen morgen wieder verdienen :-)

Any Help highly appreciated

[OliverIO]

@axelg

ich bin da weißgott kein netzwerk spezialist.
aber wenn ich martian source sehe und du beschreibst, das du diverse sub netze konfiguriert hast, dann geistern in subnetzen pakete herum, die da nicht hingehören.
irgend etwas stimmt dann beim routing und damit der konfiguration des netzes oder zumindest der subnetze nicht.
ich gehe mal davon aus, das du die definition davon kennst
https://de.wikipedia.org/wiki/Martian_Packet

das mit der anfänglichen fehlertoleranz wäre mir neu. mag sein das es das in manchen ecken gibt, aber bei linux kern elementen glaub ich das eher nicht. wenn falsch konfiguriert, dann gleich falsch, wie soll man den sonst in komplexen systemen die ursache finden

was ist das für eine ip, die gesucht wird? kennst du diese? weißt du zu welchem subnet die gehört? und warum das netzwerk die nicht erreichen kann? ansonsten müsste der zuständige gateway sich ja melden

kannst du noch deinen grund nennen, warum du die verschiedenen geräte in verschiedene subnetze gepackt hast?
sinn ist ja eher voneinander zu kapseln, als das die geräte sich weiterhin miteinander unterhalten sollen und wenn dann durch konkrete routings wo einzelne geräte dann doch im anderen netzt sichtbar gemacht werden. ein anwendungsfall wäre bspw alle sensoren in ein eigenes subnetz packen ohne internetzugriff, sensoren dürfen nur mit iobroker sprechen. so kann das nach hause telefonieren verhindert werden (sofern sie dann noch weiter funktionieren)

ein fehler ist es sicherlich, aber meines erachtens keiner den iobroker zu verantworten hat. ansonsten müssten hier noch mehr solche anfragen vorliegen und das ist die erste dieser art den ich sehe.

[Marc Berg]

@axelg sagte in "martian source" flutet dmesg und log files auf meinem PC:

Was ist damit gemeint "in eine Domain klatscht"???? Mir ist keine unsaubere Konfig bewusst

Du hast ja selbst gesagt, dass du vorhast, VLANs zu bilden. Wenn dann jedes Subnetz im eigenen VLAN eingesperrt ist, solltest du auch keine "Pakete vom Mars" mehr erhalten. Damit sagt ja das Betriebssystem nur, dass es über ein Interface Pakete aus einem Subnetz erhält, für das kein Routing bekannt ist.

.72 bis .75 sind meine Daikin Geräte. Da habe ich tatsächlich auch ein Problem, das ich nicht beheben kann.

Und diese Geräte sind per Ping vom Raspi erreichbar?

.76.... keine Ahnung, leider...

Das muss aber irgendwo in einem Adapter/Script/Bashscript/Config verwurstet sein, der Raspi denkt sich die Adressen ja nicht aus. :-)

Ich habe heute mit Wireshark weiter geschaut und sehe da eben die ARP-requests (Who has....?) in unnatürlicher Menge

Die "unnatürliche Menge" kommt ja scheinbar nur deshalb zustande, weil der Raspi auf seine ARP-Anfragen (gib mir bitte die Hardware-Adresse zur IP-Adresse x.y.z) keine Antworten von den DAIKINs erhält. Sobald die Anfrage 1x erfolgreich beantwortet wurde, liegen die Adressen im ARP-Cache und werden daraus genommen. Das ist reine Netz-/Betriebssystem-Ebene ohne direkten Einfluss des Adapters.

Mit "iobroker stop" fahren die ARP requests fort
Wenn ich jedoch den Service mit "systemctl stop iobroker.service" beende, dann enden auch die ARP-requests.

Ich könnte mir vorstellen, dass das Betriebssystem noch eine Zeit lang unbeantwortete ARP-Requests raussendet, bevor es aufgibt. Das Stoppen des Service wird bewirken, dass die Queue dann gelöscht wird.

[AxelG]

Danke, dass ihr Euch alle soviel Mühe gebt, Euch in mein Problem einzudenken. Ich sitze davor, aber Ihr müsst Eure Vorstellungskraft nutzen...

@oliverio said in "martian source" flutet dmesg und log files auf meinem PC:

aber wenn ich martian source sehe und du beschreibst, das du diverse sub netze konfiguriert hast, dann geistern in subnetzen pakete herum, die da nicht hingehören.
irgend etwas stimmt dann beim routing und damit der konfiguration des netzes oder zumindest der subnetze nicht.

Verstehe ich. Nur die heutige Konfig habe ich schon seit 2021 so und erst jetzt kommt es zu dem Phänomen

@oliverio said in "martian source" flutet dmesg und log files auf meinem PC:

ich gehe mal davon aus, das du die definition davon kennst

ja

Martian_Sources sehe ich ja nur auf dem PC. Auf dem Raspi wiederrum sehe ich (vom PC aus mit wireshark suchend) die schiere Menge an ARP requests

@oliverio said in "martian source" flutet dmesg und log files auf meinem PC:

das mit der anfänglichen fehlertoleranz wäre mir neu

Dies war ein Erfahrungsbericht von Gentoo, nicht auf Netzwerktechnik bezogen. Bei Gentoo hatte ich schon mindestens zwei mal den Effekt, dass ich ein Auftreten an Tag X hatte und an dem Tag und rund herum keine relevante Änderung vorlag. Aber als das Problem dann behoben war, stellte ich fest, dass die Situation schon immer so war, nur das entsprechende Packet früher fehlertolerant war und das dann zwecks Korrektheit eliminiert wurde.

@oliverio said in "martian source" flutet dmesg und log files auf meinem PC:

was ist das für eine ip, die gesucht wird? kennst du diese?

Das weiß ich nicht. Ich erinnere mich nicht, .76 konfiguriert zu haben und das ist nur ein Beispiel. Es werden mehrere IP's gesucht, die ich mir nicht erklären kann und ich wüsste eben gerne genau, "wer konkret" das von meinem Raspi aus wissen will. Aber dazu finde ich leider nichts.

@oliverio said in "martian source" flutet dmesg und log files auf meinem PC:

weißt du zu welchem subnet die gehört?

Na klar, steht ja in dem Wireshark-screenshot mit drin. Es ist das Subnetz in dem der Raspi unterwegs ist. Sie Detailierung weiter unten :)

@oliverio said in "martian source" flutet dmesg und log files auf meinem PC:

kannst du noch deinen grund nennen, warum du die verschiedenen geräte in verschiedene subnetze gepackt hast?

• Fritz!Box = 192.168.178.0/24 mit wifi. In dem Subnetz hängt mein iobroker (.119) und auch ein raspberrymatic (.103) beide per LAN
• PC und früher weitere andere PCs und Drucker 192.168.5.0/24 mit Firewall auf dem ersten/haupt PC
• weiteres Subnetz für Backup-server

Dieses Setup besteht so schon seit sehr vielen Jahren (mehr als 10Jahre, tatsächlich)

Früher hatte ich lediglich einen Switch am PC, an dem dann alle Geräte aus 192.168.5.0/24 hingen

2021 sind wir in dieses Haus gezogen mit umfangreicher LAN-Verkabelung und Patchfeld im Keller.
Dort hängt nun ein managed switch, auf dem die ersten beiden Netze gemeinsam drauf laufen (und zwar seit 2021 ohne Probleme). Das dritte Subnetz hat akt. nur ein NAS und das hängt direkt am Patchpannel und von dort unmittelbar in den PC (das erklärt warum ich auf dem dritten Subnetz keine Martian sources sehe)

Am Anfang meiner "Netzwerk-karriere" gab es noch nicht soo viel W-lan (2 Handies und fertig). Dann kam, wie bei uns allen, vermute ich: iPad, laptop, homeoffice-laptop etc, etc. etc. Das führte zu dem Wunsch, von Wifi aus drucken zu können. Also wanderte der Drucker in das Subnetz der Fritzbox. Dann kam Smarthome und die meisten Geräte funktionieren eben nur mit Zugriff auf entweder wifi oder Internet oder es muss alles im selben Subnet sein, somit ist das gesamte Smarthome im subnetz der Fritzbox (ich hätte es lieber hinter meiner Firewall, aber der PC läuft ja nicht immer)

@oliverio said in "martian source" flutet dmesg und log files auf meinem PC:

ein fehler ist es sicherlich, aber meines erachtens keiner den iobroker zu verantworten hat. ansonsten müssten hier

Hmmmm. Nichts lieber als das, dass ich herausfinde, dass nur ich irgend einen der Adapter falsch konfiguriert habe (ich glaube (noch) nicht, dass grundsätzlich der raspi falsch konfiguriert ist, denn systemctl stop iobroker.service beendet ja den Spuk)

@marc-berg said in "martian source" flutet dmesg und log files auf meinem PC:

Du hast ja selbst gesagt, dass du vorhast, VLANs zu bilden. Wenn dann jedes Subnetz im eigenen VLAN eingesperrt ist, solltest du auch keine "Pakete vom Mars" mehr erhalten. Damit sagt ja das Betriebssystem nur, dass es über ein Interface Pakete aus einem Subnetz erhält, für das kein Routing bekannt ist.

Ist mir im Prinzip klar, dass dieser Schritt überfällig ist und das dann auf dem PC die Martians aufhören, aber auf dem Raspi sind deswegen die unzähligen ARP requests ja noch nicht weg...
...und warum war das vor dem 23. Oktober nicht. (ich erinnere mich nicht, dass ich am 23.10. irgendwas großes geändert hätte außer ggf. ein update.)
...dmesg nutze ich auf meinem PC schon öfter mal, daher weiß ich, dass ich bislang keine Probleme hatte

[
aktuell habe ich mir so geholfen, dass ich vorübergehend!!! das martian-logging in der firewall ausgeschaltet habe, 0 statt 1 bei:

# Log impossible addresses
echo "0" >/proc/sys/net/ipv4/conf/all/log_martians

]

@marc-berg said in "martian source" flutet dmesg und log files auf meinem PC:

.72 bis .75 sind meine Daikin Geräte. Da habe ich tatsächlich auch ein Problem, das ich nicht beheben kann.

Und diese Geräte sind per Ping vom Raspi erreichbar?

Leider nein. Das ist ja (siehe github) noch ein weiteres Problem, dass die Plötzlich nicht mehr gehen (sie gingen aber definitiv, ich schalte die Klima in einem empfindlichen Raum gemäß Temp über den iobroker ein). Sicherung raus und wieder rein hat nicht geholfen. Es gab ein APP update, aber das sollte die Daikin's nicht stören. Diesem Thema werde ich aber auch nochmal dediziert nachtauchen. Leider habe ich abends immer nur sehr begrenzt Zeit, mich darum zu kümmern.

[EDIT1: habe gerade in der APP gesehen, dass Daikins, trotz sperre, neue IPs erhalten haben, aber wie gesagt, es trifft ja nicht nur die Daikin IPs. Anyway, ich werde das als nächstes im IO-Broker korrigieren]

@marc-berg said in "martian source" flutet dmesg und log files auf meinem PC:

.76.... keine Ahnung, leider...

Das muss aber irgendwo in einem Adapter/Script/Bashscript/Config verwurstet sein, der Raspi denkt sich die Adressen ja nicht aus. :-)

hihihi ja. Wie gesagt, .76 ist nur eine von mehreren IPs die da gesucht werden und ich kann mir das alles kaum erklären. Die eine oder andere finde ich (Daikin eben) aber nicht alle anderen. und sooooo viele Adapter mit IP-Geräten habe ich nicht konfiguriert (ein paar Shelly noch, aber sonst...)
Es wäre wirklich hilfreich, wenn ich herausbekommen könnte, welcher Service im Raspi den ARP-request triggert, aber genau da komme ich nicht weiter. Aber ja, ich werde eben Adapter für Adapter nachsehen, welche IPs da eingestellt sind und hoffe, es noch irgendwo zu finden ein grep im /etc des raspi werde ich auch noch starten.

@marc-berg said in "martian source" flutet dmesg und log files auf meinem PC:

Ich habe heute mit Wireshark weiter geschaut und sehe da eben die ARP-requests (Who has....?) in unnatürlicher Menge

Die "unnatürliche Menge" kommt ja scheinbar nur deshalb zustande, weil der Raspi auf seine ARP-Anfragen (gib mir bitte die Hardware-Adresse zur IP-Adresse x.y.z) keine Antworten von den DAIKINs erhält. Sobald die Anfrage 1x erfolgreich beantwortet wurde, liegen die Adressen im ARP-Cache und werden daraus genommen. Das ist reine Netz-/Betriebssystem-Ebene ohne direkten Einfluss des Adapters.

Verstehe ich im Prinzip. Es sind ja nicht nur die Daikin-Geräte, nach deren IPs gesucht wird. In Summe sind es ca. 6-8 weitere

@marc-berg said in "martian source" flutet dmesg und log files auf meinem PC:

Mit "iobroker stop" fahren die ARP requests fort
Wenn ich jedoch den Service mit "systemctl stop iobroker.service" beende, dann enden auch die ARP-requests.

Ich könnte mir vorstellen, dass das Betriebssystem noch eine Zeit lang unbeantwortete ARP-Requests raussendet, bevor es aufgibt. Das Stoppen des Service wird bewirken, dass die Queue dann gelöscht wird.

Macht Sinn. Ich hatte in meinem Github-issue ja auch geschrieben, dass iob stop schon reicht, den Spuk zu beenden. Das war dann ggf. zufällig mal so, denn diese Aussage stellte sich später als unwahr heraus.

BTW: routing-Tabelle auf dem raspi und auf dem PC sieht korrekt aus... (außer dass der rapsi kein loopback auf localhost hat, aber das ist auch schon immer so)

[AxelG]

@axelg
Ich habe .76 gefunden
Es ist mein NUC-PC der mit libreelec/Kodi auf dessen port 9090 arbeitet. Das Gerät ist natürlich oft aus und wird dann nicht gefunden.

Aber den gibt es auch schon länger als 23. Oktober 2023 :-)