owm: replacing owm

[PolynomialDivision]

OWM is just not maintained anymore. I suggest a combination of

• respondd
• Yanic

Currently, respondd typically works with multicast groups (does not work in our mesh), but also with direct queries from a server.

TODO: Add more Infos

[SvenRoederer]

A monitoring and map as @Freifunk-Potsdam is using as also an alternative, which is a dropin-solution (a1afeea#diff-e51cef7f0a92ae0b41f56758c13f303c).
Running it on my node from some time.

[sarumpaet]

I like the simple POST approach owm.lua takes, and it is maintained as in, it works and will continue to work, and "replacing" it on the routers will not solve anything but add legacy since we'll have to support owm.lua anyways for years to come (unless we're fine with a map that just lists a tiny fraction of our nodes).

Pro: owm.lua just works and provides quite some flexibility and has some privacy advantages - e.g., back when we decided not to publish MAC addresses, we were able to quickly hide those in the maps, which wouldn't be possible with daemons flooding the mesh with that info. Also, tiny ROM footprint.
Con: owm.lua isn't very fancy (who cares?). No "offline"/mesh connectivity only map (which I believe is a slightly different topic as such a map will always miss separated mesh islands, and we want at least one complete map somewhere).

Please, when listing alternatives, don't just drop names but give characteristics and pros and cons.

[SvenRoederer]

A monitoring and map as @Freifunk-Potsdam is using as also an alternative, which is a dropin-solution (a1afeea#diff-e51cef7f0a92ae0b41f56758c13f303c).

Pro:

• just a simple Shell script, so easy to extend.
• It feeds the data to a Grafana-based monitoring (https://monitor.freifunk-potsdam.de/grafana/d/000000008/node-overview?orgId=2&var-hostname=Ahof-frieden03&refresh=5m) and provides a map (https://monitor.freifunk-potsdam.de/ff/apmap)
• it's a ready solution, we just can copy

Con:

• just a simple Shell script, so always hackisch

[SvenRoederer]

e.g., back when we decided not to publish MAC addresses, we were able to quickly hide those in the maps

@sarumpaet do you referencing #585 ? currently we only anonymize the MAC-addresses to some extend, but still pushing them out - unencrypted.

[Akira25]

The solution of Freifunk Potsdam does not convince me. It took me more than seven clicks, to get the wifi-data in their Grafana setup. As I think, that data on signal strength and SNR are essential for mobile ad-hoc meshing, this is definitely to much.

In addition i'd prefer our recent solution, hopglass, way over the Potsdam map. Its not for technical reasons: both maps do pretty much the same thing and share very similar features. But hopglass visualises node-data in a more comprehensive way (box on the left). In addition, we have there some superior statistics-features: i.e. selecting nodes by their firmware-version, etc.

I'm in favour of abiding by the current owm.lua app, as downward compatibility is a strong demand in this case: Only around 250 of 800 Routers currently run hedy-1.0.6 and 1.0.4. If we move on to a incompatible solution, we must assume, that only those 250 Routers would be updated in a reasonable amount of time. The rest would be completely gone. And we might not be able to look after them for updates, as we won't be able to locate them any more.

[Akira25]

e.g., back when we decided not to publish MAC addresses, we were able to quickly hide those in the maps

@sarumpaet do you referencing #585 ? currently we only anonymize the MAC-addresses to some extend, but still pushing them out - unencrypted.

No one questioned that. As @sarumpaet mentioned: They are hidden in the map. As no one worked on that issue for nearly two years, it might not have been that urgend to implement a complete suppression of MAC-Addresses in owm.lua. Thus I'm quite astonished, why that should now serve as argument against owm.lua .?

[SvenRoederer]

I just wanted to mention this setup. As I remember that the current monitor suffers old software (endless loading time of the mainpage) and @booo once tried to setup a grafana-monitoring also. IMHO it's very great, what data these little scripts on the node provide in contrast to our setup of owm-script for status and collectd for monitoring.
The term "we just can copy" was more directed towards "copying the infrastructure setup" and customize to our needs than copying all and use it in exact the same way.

hopglass: I'm quite sure a bit of server-side scripting can also be used to generate the required json data from the Potdam-solution script.

Please don't argument with "staying in the past". Old and unmaintained nodes are still the reason why we are stuck ad adhoc and OLSRv1.

---

regarding the "They are hidden in the map": when we hide something on the map, it's a weak argument for the flexibility of owm.lua, which wasn't involved in this at all :-)

[sarumpaet]

By "flexibility" I meant the whole approach (POSTing data) as opposed to the things mentioned in the first posting (e.g., respondd implements UDP based mesh information distribution, which is great for certain use cases, but horrible in terms of flexibility and debug-ability).

While I thought this ticket is mainly about the map, I like the idea of merging the client side of monitor and map. collectd isn't quite that great (uses up quite a lot of resources both in terms of RAM and ROM, and is quite arcane in general); I'd be happy to get rid of it.

Perhaps we can adapt the Potsdam script to our needs? I.e., create something that replaces owm.lua on the client side but still POSTs to util.berlin.freifunk.net, AND that sends monitoring data additionally to the map data.

[SvenRoederer]

Right, comparing the amount of client-side code that we currently need monitoring and map, in comparison to the Potsdam-solution, we have a very bad ratio.

Another argument for reimplementing this features is, that we can design it more flexible in terms of link reporting. This will help in gathering link data (#778, #779), which currently relies on olsrd only.

[booo]

As far as I get the situation everybody is in favour of a simple and maintainable script that pushes metrics about the router to a database.

I suggest someone makes a concrete proposal for a script and creates a first package. We can discuss the script and changes to the script once we have a prototype.

I don't want to maintain multiple scripts but for a limited time we can have both scripts in our repositories and running in the wild. Once everything is ready we can discuss a transition/migration to this new script/infrastructure.

[SvenRoederer]

So we should at first think of some kind of API, the server will provide / accept.

[SvenRoederer]

A monitoring and map as @Freifunk-Potsdam is using as also an alternative, which is a dropin-solution (a1afeea#diff-e51cef7f0a92ae0b41f56758c13f303c).
Running it on my node from some time.

Btw: my 4/32MB node is back on monitoring: https://monitor.freifunk-potsdam.de/grafana/d/000000008/node-overview?orgId=2&var-hostname=Ahof-frieden01&refresh=5m

[SvenRoederer]

Regarding a new API there is some discussion going on at freifunk-berlin/falter-packages#159