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)