Respondd information for active channels/txpower, batman nexthop and airtime about packages HOT 11 CLOSED

I haven't had a deeper look at it yet, but I'd like to have such a package in Gluon. I'm not sure if the packages repo or the main repo is the best place for it. The packages repo is for packages which don't depend on Gluon and are supposed to be upstreamed to OpenWrt/LEDE eventually. At a glance, it doesn't seem like anything of this package depends on Gluon, so either might be an option.

Other comments:

• The "nexthop" provider is not only extremely misleading (in the batman-adv context, "nexthop" usually refers to the next node of a forwarding path, which is specific for each destination, and not to the gateway), it is also redundant, gluon-mesh-batman-adv-core/src/respondd.c already provides this field as "gateway"
• All Lua and "legacy" respondd parts should be removed from the package, the submitted package should just contain a single respondd provider (I don't have a strong opinion on splitting off the core functionality into another .so, but if you don't have a concrete usecase for reusing this code, it would make sense to merge everything into the respondd provider)

I haven't looked at the layout yet.

from packages.

@NeoRaider

• Should I open another issue in gluon?
• The nexthop is the other macaddress field from the gateway line in the batman debug file, it is not the same thing.
• Could we keepthe lua part and just not install it?
• Merging could be done by just linking it statically.

from packages.

The nexthop provider is an addition to the gateway information. Its is indeed next node of the forwarding path to the gateway.

from packages.

• A Gluon issue is not needed, one issue is enough
• Ah, indeed. Then that functionality should just be merged into gluon-mesh-batman-adv-core/src/respondd.c, and it should be made clear in the structure that this is the nexthop to the gateway.
• The package should only contain the parts that are required. What do you use the Lua parts for? If they are generally useful, they could become another package.

from packages.

• Nice
• Also nice, the code came from there anyways. I'll open a PR. (Could you give an example for the structure? gateway_nexthop, or can we modify the existing gateway field)
• It would make it easier to integrate it into luci. But TBH its mostly boiler plate anyways. I'll remove it.

from packages.

@t-8ch are you still planning to do a PR for channels/txpower/airtime?

from packages.

Maybe this one is PR ready https://github.com/FreifunkBremen/ffhb-packages/tree/breminale2016/ffhb/gluon-respondd-wifisettings
(It works for me and i have no time for a disscussion about the layout ... so if some own need it, copy it and make a PR)

there is no airtime in this package

from packages.

for reference, part of it (nexthop) got included in freifunk-gluon/gluon#795
the other part is being discussed/worked on in freifunk-gluon/gluon#826

from packages.

Das klingt ja höchst interressant, kann vielleicht jemand auf deutsch kurz erklären, was ein nexthop hier sein soll?

Ich verstehe nicht ganz, was anders ist, zu den schon vorhandenen einstelungen für die sendeleistung im config mode, ist das nicht "TX Power"?

Was passiert mit der airtime in diesem Paket?
Also was genau will man mit diesem Paket erreichen?

from packages.

es geht darum, diese Informationen via respondd im mesh zu verbreiten.
bei der airtime geht es darum, die Information wie stark die airtime eben ausgenutzt ist zu erfassen und zu verbreiten.
Aber für solche Erklärungen, v.a. auf Deutsch, vielleicht besser in den IRC-Channel kommen ;-)

from packages.

this was fixed by merging #156

from packages.