Anscheinend verursacht Trafficontrol in der Node Firmware XML Probleme mit dem Nodewatcher #176

New Issue

ChristianD · 2021-11-15T23:46:44+01:00

ChristianD commented

2021-11-15 23:46:44 +01:00

Sobald Traffic Control aktiviert wird und ein Wert eingegeben wird, landen keine Daten mehr beim Monitoring. Laut Aussage von Adrian kommt es zu folgenden Fehler:

{2021-11-15 20:55:07} - Warning: Unable to parse xml from 84:16:f9:9b:ba:ce: could not convert string to float: '12288\u202c'
__Traceback (most recent call last):
__ File "/usr/local/lib/python3.7/dist-packages/ffmap/routertools.py", line 65, in import_nodewatcher_xml
__ router_update = parse_nodewatcher_xml(xml,statstime)
__ File "/usr/local/lib/python3.7/dist-packages/ffmap/routertools.py", line 684, in parse_nodewatcher_xml
__ "tc_in": evalxpathfloat(tree,"/data/traffic_control/wan/in/text()",None),
__ File "/usr/local/lib/python3.7/dist-packages/ffmap/routertools.py", line 620, in evalxpathfloat
__ tmp = float(tree.xpath(p)[0])
__ValueError: could not convert string to float: '12288\u202c'

12288 ist der Wert, welcher als Download angegeben wurde.

Sobald Traffic Control aktiviert wird und ein Wert eingegeben wird, landen keine Daten mehr beim Monitoring. Laut Aussage von Adrian kommt es zu folgenden Fehler: {2021-11-15 20:55:07} - Warning: Unable to parse xml from 84:16:f9:9b:ba:ce: could not convert string to float: '12288\u202c' __Traceback (most recent call last): __ File "/usr/local/lib/python3.7/dist-packages/ffmap/routertools.py", line 65, in import_nodewatcher_xml __ router_update = parse_nodewatcher_xml(xml,statstime) __ File "/usr/local/lib/python3.7/dist-packages/ffmap/routertools.py", line 684, in parse_nodewatcher_xml __ "tc_in": evalxpathfloat(tree,"/data/traffic_control/wan/in/text()",None), __ File "/usr/local/lib/python3.7/dist-packages/ffmap/routertools.py", line 620, in evalxpathfloat __ tmp = float(tree.xpath(p)[0]) __ValueError: could not convert string to float: '12288\u202c' 12288 ist der Wert, welcher als Download angegeben wurde.

jkimmel commented

2021-11-16 02:52:04 +01:00

Da wuerde ich ja gern mal eine Kopie von der Config haben, ob da nicht vielleicht schon irgendwie ein Zeichen reingerutscht ist, was da nix verloren hat.
Mögliche Erklärung wäre ein zu schlauer Browser oder Editor. Jedenfalls ist es ziemlich schräg \u202c im Log zu sehen.

Da wuerde ich ja gern mal eine Kopie von der Config haben, ob da nicht vielleicht schon irgendwie ein Zeichen reingerutscht ist, was da nix verloren hat. Mögliche Erklärung wäre ein zu schlauer Browser oder Editor. Jedenfalls ist es ziemlich schräg [\u202c](https://codepoints.net/U+202C) im Log zu sehen.

ChristianD commented

2021-11-16 07:35:04 +01:00

in /etc/config/fff
[...]
config fff 'trafficcontrol'
option enabled '1'
option limit_in '12288 '
option limit_out ' 1536'
[...]

ja das Zeichen scheint (falls es sich um dieses Leerzeichen handelt) da drinnen zu sein (bei out ist es auch zu finden), ist beim Firmwareupdate aufgetaucht und war zuvor kein Problem. Ich finde jetzt aber auch keinen Fehler in der Firmware wie das Zeichen da rein rutschen kann. Laut Aussage passiert das aber jedes mal jetzt mit der neuen Firmware und es wurde das trafficcontrol erstmal ausgemacht. Andere Eingabefelder funktionieren.
Ich bin auch etwas ratlos. Interessant wäre, ob es jemand nachstellen kann.

in /etc/config/fff [...] config fff 'trafficcontrol' option enabled '1' option limit_in '12288 ' option limit_out ' 1536' [...] ja das Zeichen scheint (falls es sich um dieses Leerzeichen handelt) da drinnen zu sein (bei out ist es auch zu finden), ist beim Firmwareupdate aufgetaucht und war zuvor kein Problem. Ich finde jetzt aber auch keinen Fehler in der Firmware wie das Zeichen da rein rutschen kann. Laut Aussage passiert das aber jedes mal jetzt mit der neuen Firmware und es wurde das trafficcontrol erstmal ausgemacht. Andere Eingabefelder funktionieren. Ich bin auch etwas ratlos. Interessant wäre, ob es jemand nachstellen kann.

jkimmel commented

2021-11-16 07:58:34 +01:00

Ne, das ist ein normales Leerzeichen und mich würde es auch nicht wundern, wenn das beim hier her kopieren passiert ist. Insofern wäre eine echte Kopie (Datei per scp vom Router kopieren und hier hochladen) oder ein Hexdump von dem Ausschnitt hilfreich (auch scp, dann xxd/hexdump, dann zurechtschneiden).
Für UTF-8 müsste dann übrigens folgendes Pattern auftauchen:

$ printf '\u202C' | xxd
00000000: e280 ac                                  ...

Außerdem wäre es interessant wie du das aktiviert hast. Im Browser oder selbst getippt?

Wenn es allerdings nicht in der Datei steht, muss es ja eigentlich irgendwo im Nodewatcher passieren, denke ich.

Achja: das Markdown hier kann Codeblocks. Beispiel:

```
Code oder Konsolenoutput hier her
	Dann überleben nämlich Tabs und wird nicht *formatiert*
```

Ne, das ist ein normales Leerzeichen und mich würde es auch nicht wundern, wenn das beim hier her kopieren passiert ist. Insofern wäre eine echte Kopie (Datei per scp vom Router kopieren und hier hochladen) oder ein Hexdump von dem Ausschnitt hilfreich (auch scp, dann xxd/hexdump, dann zurechtschneiden). Für `UTF-8` müsste dann übrigens folgendes Pattern auftauchen: ``` $ printf '\u202C' | xxd 00000000: e280 ac ... ``` Außerdem wäre es interessant wie du das aktiviert hast. Im Browser oder selbst getippt? Wenn es allerdings nicht in der Datei steht, muss es ja eigentlich irgendwo im Nodewatcher passieren, denke ich. Achja: das Markdown hier kann [Codeblocks](https://spec.commonmark.org/current/#fenced-code-blocks). Beispiel: ~~~ ``` Code oder Konsolenoutput hier her Dann überleben nämlich Tabs und wird nicht *formatiert* ``` ~~~

ChristianD commented

2021-11-16 08:09:24 +01:00

Ich hab gerade nochmal Rückmeldung bekommen, jetzt scheint es zu funktionieren. Warum... weiß man nicht

Sign in to join this conversation.