Zumindest mir sagt die Mac nichts, nicht aus meinem lokal katalogisierten Bestand.
Warum wird von obigem Meshy die Uptime nicht angezeigt?
Ausserdem vermisse ich bei allen
a) die Load
b) die werte für TX/RX bytes (ins br-client)
Wäre toll, das wieder zu bekommen.
Weshalb die Uptime nicht angezeigt wird kann ich dir nicht sagen, evtl fehtl auch hier der Datensatz wieder?
Die Map wird gar nicht mehr von uns gepatcht um die Eigenentwicklungen zu verhindern wie es bei der FFMap der Fall war. Dort gab es gefühlt 10 verschiedene Backends und Frontends.
Daher werden neue Features nur noch installiert wenn diese als „offizielle“ Meshviewer Version released werden.
Nee, die war schon im letzten Datensatz vorhanden wo die node_id noch fehlte:
Aber gern aktualisiert:
"ea:09:f6:4f:b2:c2": {
"owner": {
"contact": "adorfer@nadeshda.org"
},
"hardware": {
"model": "Intel(R) Celeron(R) CPU G1610 @ 2.60GHz"
},
"location": {
"longitude": 6.8106383085251,
"latitude": 51.212493452929
},
"network": {
"mesh_interfaces": [
"ea:09:f6:4f:b2:c2",
"e4:00:27:ef:5d:0c"
],
"addresses": [
"fe80:0:0:0:e809:f6ff:fe4f:b2c2",
"2a03:2260:40:0:e809:f6ff:fe4f:b2c2",
"fda0:747e:ab29:cafe:e809:f6ff:fe4f:b2c2"
]
},
"system": [],
"node_id": "ea09f64fb2c2",
"hostname": "nadeshda-org-meshy",
"software": {
"fastd": {
"version": "v17",
"enabled": true
},
"firmware": {
"base": "gluon-v2014.4-66-g3056e8b",
"release": "2014.4-rel3_exp20150129-ad"
},
"batman-adv": {
"version": "2013.4.0",
"compat": 14
},
"autoupdater": {
"enabled": true,
"branch": "experimental"
}
},
"uptime": 234603.52,
"rootfs_usage": 0.30234866027125,
"memory": {
"free": 490348,
"cached": 7360,
"total": 513908,
"buffers": 872
},
"clients": {
"wifi": 0,
"total": 0
},
"idletime": 225589.37,
"processes": {
"total": 52,
"running": 1
},
"gateway": "04:be:ef:ca:fe:04",
"traffic": {
"tx": {
"packets": 45480,
"bytes": 9052606,
"dropped": 4
},
"mgmt_tx": {
"bytes": 1204088106,
"packets": 5404484
},
"rx": {
"bytes": 705287597,
"packets": 8510586
},
"mgmt_rx": {
"bytes": 5650638244,
"packets": 35499759
},
"forward": {
"bytes": 26856459086,
"packets": 33014374
}
},
"loadavg": 0.05
},
Hmm das ist seltsam, es werden aber auch andere Dinge nicht angezeigt wie z.b. die primäre Mac Adresse.
Ich frage mich woran das liegen mag da ja alle Daten augenscheinlich vorhanden sind.
Ach das mit der primären MAC geht schon in Ordnung, da ist wirklich ein Feld leer.
Aber fehlende Load und kein Sort nach Uptime, kein TX-Byte und kein Geochecker, das nervt schon. Dazu noch die faktisch unsichtbaren VPN - Links
Ganz ehrlich: Ich hätte gern die alte Karte zurück, selbst wenn die ziemlich lahm war.
wir haben genau diesen fehler bei uns in Nord auch jetzt seit ein paar tagen, weisst du noch , wie ihr das gelöst habt ?
ausgelöst wird der fehler durch
alfred-json -s /var/run/alfred.bat-ffnord.sock -r 159 -z
Und das liegt wohl daran, wenn auf den kleinen routern respondd abschmiert, dann liefert alfred kaputte daten (die alfred von respondd erhält)
kann man wahrscheinlich nichts machen, ausser die netzgröße klein halten, damit die kleinen 4mb routern nicht immmer respondd abschiessen.
Oder vom alfred zu respondd wechseln.
Wobei das die Datensätze natürlich nicht heilt, der kommt schlicht nur geringfügig besser damit zurecht.
Wir nutzen inzwischen Hopglass und haben dafür einen eigenen Alfred Receiver gebaut:
Da werden die Einträge dann auch ignoriert. Dies hat nichts zwingend mit respondd zu tun.
Prinzipiell sind (die mir bekannten) Map-Anzeige-Konzepte durch geringe Robstness gekennzeichnet.
Sei es wie hier beschrieben, dass unvollständige Datagramme zu Problemen nicht nur in der Anzeige, sondern auch in anderen Knoten führen.
Sei es, dass einzelne Knoten, die syntaktisch falschen Content übermitteln, die Kartendarstellung ins Straucheln bringen.
Oder eben auch, dass semantischer Unfug einen bislang kaum genutzten Erlebnisraum für jugendliche Eskapaden bieten.
Wenn Knoten Daten senden, dann wird die Plausibilität derzeit kaum validiert.
Will sagen: Bislang hatten wir noch viel Glück, dass da so vergleichsweise wenig in Richtung „Defacement“ passiert ist.
Prinzipiell wäre es also durchaus wünschenswert, wenn die Aggregatoren (ich will sie gar nicht alle aufzählen), Integritäts- und zumindest grundlegende Plausibilitätschecks durchführen würden.
(wobei soetwas natürlich auch eine „Rüstungsspirale“ in Gang setzen könnte)
das ist ja auch keine Verbesserung, bei uns werden die ja auch ignoriert, und sind dann offline im meshviewer. Ich bin ja nur bei der suche nach dem Fehler, warum die knoten alle offline sind auf diese fhelermeldungen beim generieren der nodes.json gestossen und anscheinend kann man da nichts machen, die knoten liefern halt keine daten, oder?
Wenn ich die daten als string statt json ausgebe mit
alfred-json -s /var/run/alfred.bat-ffnord.sock -r 159 -z -f string
kommt da
Warning: invalid UTF-8 string from k51P�
Warning: invalid UTF-8 string from ��R+_D�
Warning: invalid UTF-8 string from `�'�!��
Warning: invalid UTF-8 string from `�'����
Warning: invalid UTF-8 string from �+�ets\":1991,\"bytes\":284762},\"mgmt_rx\":{\"packets\":2412283,\"bytes\":825189258},\"mgmt_tx\":{\"packets\":5718192,\"bytes\":2399072532}},\"gateway\":...