CCU3 Firmware 3.43.15 ist verfügbar

[jmaus]

Das stimmt so nicht. Ob die kernel module geladen sind oder nicht sagt nichts darüber aus ob über bluetooth/wlan gefunkt wird oder nicht.

Nur weil du deine Meinung jetzt hier wiederholst wird deine Aussage nicht richtiger.
Der unnötig produzierte Funkverkehr ist vor dem Entladen der Kernelmodule mit einem SDR messbar. Hinterher nicht mehr.

Das mit der Meinung gilt übrigens auch für deine Aussage! Und ich bezweifle weiterhin das das einen negativen Effekt hat bzw. das das ein praktisches Problem darstellt (bis zum beweis des Gegenteils). Auch solltest du mal den Befehl "rfkill" aufrufen, dann wirst du sehen das die WLAN schnittstelle explizit als deaktiviert markiert ist und somit der kernel es deaktiviert haben sollte. Aber wenn du natürlich gerne die letzten 0.01% Zweifel ausräumen willst steht es dir weiterhin offen die kritischen kernel module mit "rmmod" zu entfernen. Empfehlen würde ich dann auch gleich noch die ganzen auf die soundschnittstelle bezogenen kernel module auch mit zu entfernen - vielleicht hat das ja dann auch einen weiteren positiven homöopathischen Effekt auf das Funkmodul, wer weiss...

[deimos]

Hi,

ich glaube, wir brauchen nicht darüber diskutieren, dass das WLAN vom Raspberry einen negativen Einfluss zumindest mal auf das alte Funkmodul hat, dazu gibt es ja hinreichend Belege und wenn man sich die Position der Antenne anschaut, dann dürfte einem auch sofort klar sein, warum das so ist.

rfkill sorgt definitiv dafür, dass die Software Schnittstelle deaktiviert wird.

Die Frage ist jetzt nur noch, ob die Hardware ebenfalls vollständig deaktiviert wird. Nach einem Überfliegen des Raspberry Kernels würde ich vermuten, dass dies nicht der Fall ist. Die Hardware wird in brcmsmac.brcms_c_down deaktiviert, bei welchem ich beim Überfliegen den Eindruck hatte, dass es nur beim Beenden des Kernelmoduls aufgerufen wird und nicht im Fall von rfkill. Da ich da aber nur überschaubar tief reingeschaut habe, kann ich das nicht mit absoluter Sicherheit sagen.

Ich für meinen Teil würde aber mal mutmaßen, dass die einzig wirklich sichere Möglichkeit zum deaktivieren der WLAN Schnittstelle über die /boot/config.txt geht mit dem Laden des entsprechenden Device Tree Overlays, so dass die entsprechende Kernel Module die Hardware gar nicht erst initialisieren.

Viele Grüße
Alex

[jmaus]

ich glaube, wir brauchen nicht darüber diskutieren, dass das WLAN vom Raspberry einen negativen Einfluss zumindest mal auf das alte Funkmodul hat, dazu gibt es ja hinreichend Belege und wenn man sich die Position der Antenne anschaut, dann dürfte einem auch sofort klar sein, warum das so ist.

Das ein aktives Nutzen der WLAN Schnittstelle negative Effekte auf das alte und ggf. auch das neue Funkmodul haben kann stelle ich überhaupt nicht in Zweifel und das ist klar. Mir geht/ging es hier alleine darum das ich bezweifle das ein reines, via rfkill zumindest softwaretechnisch deaktiviertes WLAN das lediglich idled dazu führt das man ähnliche negative Effekte hat wie z.B. das nicht abschalten der HDMI Schnittstelle vor der 3.43.x version.

Die Frage ist jetzt nur noch, ob die Hardware ebenfalls vollständig deaktiviert wird. Nach einem Überfliegen des Raspberry Kernels würde ich vermuten, dass dies nicht der Fall ist. Die Hardware wird in brcmsmac.brcms_c_down deaktiviert, bei welchem ich beim Überfliegen den Eindruck hatte, dass es nur beim Beenden des Kernelmoduls aufgerufen wird und nicht im Fall von rfkill. Da ich da aber nur überschaubar tief reingeschaut habe, kann ich das nicht mit absoluter Sicherheit sagen.

Das kann natürlich gut sein das hier die Hardware erst mit entfernen des kernel modules komplett deaktiviert wird. Wie schon gesagt, ich bezweifle aber weiterhin das die im idle-modus betriebene WLAN oder bluetooth Hardware auf dem Pi3 ein Problem darstellt.

Ich für meinen Teil würde aber mal mutmaßen, dass die einzig wirklich sichere Möglichkeit zum deaktivieren der WLAN Schnittstelle über die /boot/config.txt geht mit dem Laden des entsprechenden Device Tree Overlays, so dass die entsprechende Kernel Module die Hardware gar nicht erst initialisieren.

Das stimmt natürlich auch, das wäre der absolut sicherste Weg, allerdings IMHO nicht der praktikabelste da man diese Änderungen beim nächsten Firmwareupdate dann wieder mitunter verlieren würde. Deshalb hatte ich mich damals eben dazu entschieden bis zum beweis des Gegenteils davon auszugehen das eine via rfkill abgeschaltete WLAN Hardware keine negativen Effekte hervorrufen sollte.

[deimos]

Hi,

Das kann natürlich gut sein das hier die Hardware erst mit entfernen des kernel modules komplett deaktiviert wird. Wie schon gesagt, ich bezweifle aber weiterhin das die im idle-modus betriebene WLAN oder bluetooth Hardware auf dem Pi3 ein Problem darstellt.

ich weiß, das klingt jetzt polemisch, aber hättest du gedacht, dass ein HDMI Port im idle zu Problemen führt? Ich ehrlich gesagt nicht.

Was man auch noch betrachten sollte: Solange das Kernel Modul aktiviert ist, wird wg. rfkill regelmäßig der Chip angesprochen, um zu schauen, ob ein Hardware Switch den Funk abschaltet (auch wenn der auf dem Pi nicht vorhanden ist), der Chip selbst hat also immer wieder was zu tun. Wenn der Chip oder die SDIO Anbindung gleich schlechte EMV Eigenschaften wie der Rest des Pis hat, dann braucht im Zweifel nicht mal bis zum Funk denken. Mir ist daher nicht klar, was zumindest gegen das Entladen der Kernel Module statt dem rfkill spricht. Ist ja jetzt nicht so, als würde das Tage in Anspruch nehmen.

Viele Grüße
Alex

[deimos]

Hi,

Ich sehe derzeit noch, dass der Duty Cycle etwas höher ist als normal. Irgendetwas scheint da noch zu funken. Ich warte mal ab bis sich das beruhigt hat und im Zweifel reboote ich.

Meine Beobachtung bei piVCCU mit der Firmware 3.43.15 zeigen Ahnliches:
Ich kann jetzt nach ein paar Stunden sagen, der Duty Cycle ist bei mir minimal höher. Im Schnitt 2,89 statt 1,93. Ich habe dazu aber einen Verdacht: in der 3.41 war ja ein Bug drin, welcher verhindert hat, dass SetInterfaceClock korrekt läuft und das ist gefixt (was übrigens nicht im Changelog steht...)
Bei mir sieht man sehr gut, dass der Dutycycle immer im 30 Minuten Takt kurz einbricht und eine Minute später wieder hochzugehen. Und 30 Minuten ist genau das Intervall von SetInterfaceClock.

Viele Grüße
Alex

[blackbasket]

Hallo zusammen,

seit dem Update beobachte ich regelmäßige ICMP-Verbindungen zu 216.58.207.46. Die IP gehört wohl zu Google.

Hat jemand von euch eine Ahnung, warum dorthin gepingt wird?

LG,
Marcel

[jmaus]

Ich habe dazu aber einen Verdacht: in der 3.41 war ja ein Bug drin, welcher verhindert hat, dass SetInterfaceClock korrekt läuft und das ist gefixt (was übrigens nicht im Changelog steht...)
Bei mir sieht man sehr gut, dass der Dutycycle immer im 30 Minuten Takt kurz einbricht und eine Minute später wieder hochzugehen. Und 30 Minuten ist genau das Intervall von SetInterfaceClock.

Dein Verdacht ist richtig. Allerdings hat hier eQ3 leider den crontab Eintrag wieder hart auf alle 30 Minuten gestellt (d.h. "*/30"). Vollkommen ausreichend wäre das nur 1x am Tag zu machen wie das auch bei RaspberryMatic oder einer CCU2 der Fall ist. Oder eben max 2-3x am Tag. Das ist in RaspberryMatic bereits seit mehreren Versionen so der Fall und es gibt damit bis jetzt meines Wissens keine nennenswerten Probleme. Und es hat eben den Charme das der DutyCycle dadurch etwas geringer ausfällt.

[jmaus]

seit dem Update beobachte ich regelmäßige ICMP-Verbindungen zu 216.58.207.46. Die IP gehört wohl zu Google.

Hat jemand von euch eine Ahnung, warum dorthin gepingt wird?

Um zu prüfen ob die Internetverbindung noch funktioniert und ggf. eine Fehlermeldung (im Sinne einer blinkenden LED des RPI-RF-MOD) auszugeben.

[jmaus]

Das kann natürlich gut sein das hier die Hardware erst mit entfernen des kernel modules komplett deaktiviert wird. Wie schon gesagt, ich bezweifle aber weiterhin das die im idle-modus betriebene WLAN oder bluetooth Hardware auf dem Pi3 ein Problem darstellt.

ich weiß, das klingt jetzt polemisch, aber hättest du gedacht, dass ein HDMI Port im idle zu Problemen führt? Ich ehrlich gesagt nicht.

Nun, es ist IMHO zumindest etwas vorstellbarer da selbst bei nicht angestecktem HDMI Kabel er ja eine Standardauflösung einstellt und egal ob ein Kabel dran ist oder nicht ein HDMI Signal raussendet. Beim WLAN verhält es sich hier IMHO etwas anders da hier ja explizit das WLAN abgeschaltet wird via rfkill und das IMHO einen ähnlichen Effekt haben sollte wie das tvservice, d.h. der WLAN chip sollte seine Funktion größtenteils einstellen und aufhören aktiv zu funken.

Mir ist daher nicht klar, was zumindest gegen das Entladen der Kernel Module statt dem rfkill spricht. Ist ja jetzt nicht so, als würde das Tage in Anspruch nehmen.

Da hast du prinzipiell natürlich recht. Ich werde es mir noch einmal durch den Kopf gehen lassen, denke aber weiterhin das keine unmittelbare Gefahr vom momentanen rfkill verhalten ausgehen sollte.

[deimos]

Hi,

Beim WLAN verhält es sich hier IMHO etwas anders da hier ja explizit das WLAN abgeschaltet wird via rfkill und das IMHO einen ähnlichen Effekt haben sollte wie das tvservice, d.h. der WLAN chip sollte seine Funktion größtenteils einstellen und aufhören aktiv zu funken.

Wie ich geschrieben habe: Der Chip wird regelmäßig per SDIO angesprochen, solange das Kernel Modul aktiv ist. Keine Ahnung, welcher genaue SDIO da verwendet wird, aber es gibt da u.A. auch einen Modus mit 205 MHz. Jetzt nehmen wir da die Oberschwingungen und landen bei 820 MHz. Und das ist gar je nach Chip bei der Carrier Prüfung gar nicht mehr soweit von 868MHz entfernet. Jetzt noch an das Listen-Before-Talk von HmIP gedacht und du bist bei Kommunikationsproblemen.
Das ist jetzt alles theoretisch durchgekaut und mangels entsprechender Messgeräte kann ich das nicht beweisen, aber das Potential für Probleme dürfte gut erkennbar sein.

Viele Grüße
Alex