Sonoff-Adapter - ungültige Zeichen in Logmessages

mcm1957

@MartinP sagte:

Nachtrag - ein Gedanke. Wenn bei der Entgegennahme der Log-Message auf "Bad control characters" geprüft und ggfs. entschärft würde, könnte nicht jeder Adapter beim Logging gepflegten Unsinn treiben ....

Bin ich im Prinzip bei dir. Mach bitte ein Issue beim js-controller auf und beschreib dein Problem.

OliverIO

@MartinP sagte:

Wenn man Shit bemerkt, reicht man ihn nicht weiter ... nicht einmal an einen Logger -> https://www.trendmicro.com/de_de/what-is/apache-log4j-vulnerability.html

ist der erwähnte logger irgendwo da im einsatz?
ist ja eher ein logger im java umfeld.
das problem da war, das ein feature defaultmäßig nicht beschränkt war und dadurch über logeinträge, die ein angreifer mit entsprechendem wissen evtl provozieren konnte, externer code nachgeladen werden konnte (sofern die firewalls das zugelassen haben)

MartinP

Es ist sicherlich keine gute Idee, sich da sicher zu fühlen. Exotische ungeprüfte Eingabedaten ist der Angriffsvektor vieler Schadsoftware ...

mcm1957

@MartinP sagte:

Nachtrag - ein Gedanke. Wenn bei der Entgegennahme der Log-Message auf "Bad control characters" geprüft und ggfs. entschärft würde, könnte nicht jeder Adapter beim Logging gepflegten Unsinn treiben ....

Bin ich im Prinzip bei dir. Mach bitte ein Issue beim js-controller auf und beschreib dein Problem.

Es macht null Sinn in zig Adaptern explizite Filter zu implementieren bzw. eigene Hüllen um log.* zu schreiben.

Andreas67 0

Es macht wenig Sinn, jeden Adapter einzeln anzupassen. Die Bereinigung sollte zentral im Logger des js-controller stattfinden, kurz bevor der String in die Datei geschrieben wird.Ein schlanker regulärer Ausdruck (Regex) kann alle schädlichen Steuerzeichen (C0- und C1-Kontrollzeichen) entfernen, ohne nennenswerten CPU-Overhead zu erzeugen. Wichtig dabei ist, dass die ANSI-Escape-Zeichen für die farbige Log-Ausgabe im Terminal erhalten bleiben.Hier ist ein konkreter JavaScript-Entwurf für die zentrale Logging-Schnittstelle:javascriptfunction sanitizeLogMessage(message) {
if (typeof message !== 'string') return message;

// Entfernt schädliche Steuerzeichen (C0 und C1),
// erlaubt aber Zeilenumbrüche (\n, \r), Tabs (\t) und das ANSI-Escape-Zeichen (\x1b) für die Farben
return message.replace(/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F-\x9F]/g, '');

}
Verwende Code mit Vorsicht.Die VorteileZentral: Keine Anpassungen an den einzelnen Adaptern notwendig.Integrität: Logfiles bleiben für grep und andere Text-Tools immer vollständig durchsuchbar.Abwärtskompatibel: Die Farb-Formatierungen im Terminal funktionieren weiterhin einwandfrei, da das Escape-Zeichen (\x1b) geschützt wird.Ich würde mich über eine kurze Rückmeldung freuen, ob dieser Ansatz für euch infrage kommt, oder ob ich dazu ein offizielles GitHub-Issue eröffnen soll. Viele Grüße,Andreas

MartinP

Die Lösung gefällt mir.

Verstehe ich das richtig, Du machst direkt einen Pull-Request?

MartinP

Noch ein Nachtrag: Die Farbgebung des Log-Levels finde ich eher hinderlich. Das Suchen nach einem Pattern "error: 0.<adaptername> wird dadurch z. B. kompliziert

MartinP

Ich habe mir sowohl das Repository des js-controllers, als auch des Sonoff-Adapters angeschaut. Die Änderungen würden meine Fähigkeiten deutlich übersteigen.

@andreas67-0 hast Du Dir die Änderung im js-controller auf die To-Do Liste gesetzt, oder soll ich einen Issue schreiben?

MartinP

Habe mal einen Issue erstellt, und Gegenwind bekommen ;-)

https://github.com/ioBroker/ioBroker.js-controller/issues/3397

Ein kleiner Ersatz sind vielleicht folgende beiden Skripte - die habe ich aber mal eben aus den Ärmeln geschüttelt, nicht besonders flexible:

my_grep.sh (usage my_grep.sh <pattern> <file>)

#!/bin/bash
#
# usage my_grep.sh <pattern> <file>
#
# prototype line zcat iobroker.current.log |sed  's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F\x7F-\x9F]//g' |grep button

patt=$1
shift
while [ "$#" -gt 0 ]; do
    cat "$1" |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"
    shift
done

my_zgrep.sh (usage my_zgrep.sh <pattern> <file>)

#!/bin/bash
#
# usage my_zgrep.sh <pattern> <file>
#
# prototype line zcat iobroker.current.log |sed  's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F\x7F-\x9F]//g' |grep button
patt=$1
#echo "pattern =" $patt
shift
while [ "$#" -gt 0 ]; do
    zcat "$1" |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"
    shift
done

#echo "searchpattern =" $patt

Dann noch eins, um in allen Logs zu suchen:

#!/bin/bash
patt=$1
zcat *.log.gz |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"
cat *.log |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"

Wenn man will, dass der eingeloggte User sie aus allen Verzeichnissen aufrufen kann, muss man noch an das File ~/.profile eine Zeile anhängen mit dem Pfad, in dem die Shellscripte liegen

PATH="$HOME/gitea/iobroker_shellscripte:$PATH"

EDIT Scripte angepasst, nun funktionieren auch Suchtexte aus mehreren Wörtern (Gänsefüße)

martin@iobroker-test-sicher:~/gitea/iobroker_shellscripte$ my_zgrep.sh "unexpected response" *.gz
2026-07-02 01:55:30.964  - error: tradfri.0 (633) Error: unexpected response (4.00) to observeDevice(65545): [object Object]
2026-07-02 01:55:33.534  - error: tradfri.0 (633) Error: unexpected response (4.00) to observeDevice(65545): [object Object]

MartinP

Habe eine einfachere Lösung gefunden:

das Tool "ansifilter" ist anscheinend auch im normalen regulären debian repository...

martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$ apt install ansifilter
[sudo] Passwort für martin:       
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden NEUEN Pakete werden installiert:
  ansifilter
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 68,3 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 200 kB Plattenplatz zusätzlich benutzt.

Zur Erinnerung der nicht hilfreiche Output von grep:

martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$ grep "Bad control" iobroker.2026-06-23.log
grep: iobroker.2026-06-23.log: Übereinstimmungen in Binärdatei

Aber....

martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$ ansifilter -i iobroker.2026-06-23.log |grep "Bad control"
2026-06-23 11:38:24.659  - warn: sonoff.0 (213567) Client [Bewaesserung] cannot parse data"SENSOR": _{"Time":"2026-06-23T10:36:54","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":514.532,"Yesterday":0.643,"To0�tele/tasmota_17AB7E/STATE{"Time":"2026-06-23T10:37:14","Uptime":"55T00:44:43","UptimeSec":4754683,"Heap":16,"Sle_ - SyntaxError: Bad control character in string literal in JSON at position 118 (line 1 column 119)
martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$

Aufgrund des "Strippens" der Farbcodierung kann man auch in einem Schritt nach Warnungen des sonoff-Adapters suchen.

martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$ ansifilter -i iobroker.2026-06-23.log |grep "warn: sonoff"
2026-06-23 11:38:24.659  - warn: sonoff.0 (213567) Client [Bewaesserung] cannot parse data"SENSOR": _{"Time":"2026-06-23T10:36:54","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":514.532,"Yesterday":0.643,"To0�tele/tasmota_17AB7E/STATE{"Time":"2026-06-23T10:37:14","Uptime":"55T00:44:43","UptimeSec":4754683,"Heap":16,"Sle_ - SyntaxError: Bad control character in string literal in JSON at position 118 (line 1 column 119)
2026-06-23 11:38:24.661  - warn: sonoff.0 (213567) Client [Bewaesserung] received pubrel on Bewaesserung for unknown messageId 19823
....

Alles verfügbare Logging nach einem Text durchsuchen geht so:

#!/bin/bash
patt=$1
zcat *.log.gz |ansifilter |grep "$patt"
cat *.log |ansifilter |grep "$patt"

Beispiel

martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$ bash my_logsearch.sh "warn: sonoff"
2026-06-23 11:38:24.659  - warn: sonoff.0 (213567) Client [Bewaesserung] cannot parse data"SENSOR": _{"Time":"2026-06-23T10:36:54","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":514.532,"Yesterday":0.643,"To0�tele/tasmota_17AB7E/STATE{"Time":"2026-06-23T10:37:14","Uptime":"55T00:44:43","UptimeSec":4754683,"Heap":16,"Sle_ - SyntaxError: Bad control character in string literal in JSON at position 118 (line 1 column 119)
2026-06-23 11:38:24.661  - warn: sonoff.0 (213567) Client [Bewaesserung] received pubrel on Bewaesserung for unknown messageId 19823
2026-06-23 11:38:24.662  - warn: sonoff.0 (213567) Client [Bewaesserung] received pubrel on Bewaesserung for unknown messageId 28257
2026-06-23 12:18:34.304  - warn: sonoff.0 (213567) Old client Bewaesserung with secret 1782209331543_5611 sends publish. Ignore! Actual se
....

Nachtrag: ansifilter scheint langsamer zu sein, als sed

Ausführungszeit ein paar Sekunden für das Durchsuchen der vergangenen Woche ist aber nicht so gravierend...

Trotzdem mal interessehalber gemessen

Hier der alte Code mit sed

#!/bin/bash
starttime=$(date +'%s%3N')
patt=$1
zcat *.log.gz |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"
cat *.log |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"
#zcat *.log.gz |ansifilter |grep "$patt"
#cat *.log |ansifilter |grep "$patt"
echo Laufzeit $(($(date +'%s%3N') - $starttime)) ms

ca 185 ms....

martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$ bash my_logsearch.sh "Bad control"
2026-06-23 11:38:24.659  - warn: sonoff.0 (213567) Client [Bewaesserung] cannot parse data"SENSOR": _{"Time":"2026-06-23T10:36:54","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":514.532,"Yesterday":0.643,"To0�tele/tasmota_17AB7E/STATE{"Time":"2026-06-23T10:37:14","Uptime":"55T00:44:43","UptimeSec":4754683,"Heap":16,"Sle_ - SyntaxError: Bad control character in string literal in JSON at position 118 (line 1 column 119)
2026-06-23 11:38:24.659  - warn: sonoff.0 (213567) Client [Bewaesserung] cannot parse data"SENSOR": _{"Time":"2026-06-23T10:36:54","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":514.532,"Yesterday":0.643,"To0�tele/tasmota_17AB7E/STATE{"Time":"2026-06-23T10:37:14","Uptime":"55T00:44:43","UptimeSec":4754683,"Heap":16,"Sle_ - SyntaxError: Bad control character in string literal in JSON at position 118 (line 1 column 119)
Laufzeit 185 ms

Mit ansifilter statt sed vergeht fast die zehnfache Zeit....

martin@martin-D2836-S1:~/gitea/iobroker_shellscripte$ bash my_logsearch.sh "Bad control"
2026-06-23 11:38:24.659  - warn: sonoff.0 (213567) Client [Bewaesserung] cannot parse data"SENSOR": _{"Time":"2026-06-23T10:36:54","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":514.532,"Yesterday":0.643,"To0�tele/tasmota_17AB7E/STATE{"Time":"2026-06-23T10:37:14","Uptime":"55T00:44:43","UptimeSec":4754683,"Heap":16,"Sle_ - SyntaxError: Bad control character in string literal in JSON at position 118 (line 1 column 119)
2026-06-23 11:38:24.659  - warn: sonoff.0 (213567) Client [Bewaesserung] cannot parse data"SENSOR": _{"Time":"2026-06-23T10:36:54","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":514.532,"Yesterday":0.643,"To0�tele/tasmota_17AB7E/STATE{"Time":"2026-06-23T10:37:14","Uptime":"55T00:44:43","UptimeSec":4754683,"Heap":16,"Sle_ - SyntaxError: Bad control character in string literal in JSON at position 118 (line 1 column 119)
Laufzeit 1603 ms

Andreas67 0

@martinp Sehr gute Lösung

MartinP

Hier noch eine Erweiterung.
Durch Angabe des absoluten Pfades auf die Log-Files muss man das Script nicht mehr im Verzeichnis /opt/iobroker/log/ ausführen.

#!/bin/bash
starttime=$(date +'%s%3N')
patt=$1
#zcat *.log.gz |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"
#cat /opt/iobroker/log/iobroker.current.log |sed 's/[\x00-\x08\x0B\x0C\x0E-\x1A\x1C-\x1F]//g' |grep "$patt"
zcat /opt/iobroker/log/*.log.gz |ansifilter |grep "$patt"
cat /opt/iobroker/log/iobroker.current.log |ansifilter |grep "$patt"
echo Laufzeit $(($(date +'%s%3N') - $starttime)) ms

Daneben heißt das script nun logsearch - die Umbenennung von "my_logsearch.sh" beschleunigt den Aufruf durch weniger tipparbeit ;-)
Es gibt bei mir nun auch logsearchf (f=fast) mit der sed-Version des filterns ...

Community Forum

NEWS

Sonoff-Adapter - ungültige Zeichen in Logmessages

Support us

404

33.0k

83.4k

1.3m