status-page: preparing for babel

[lemoer]

Current working branch: https://github.com/lemoer/gluon/tree/rebase_statuspage

TODOs

gluon-mesh-babel:

• adapt a stub makefile out of the babel pr
• create a respondd module
• respondd-module: provide nodeinfo.network.mac
• respondd-module: provide nodeinfo.network.mesh
• respondd-module: provide nodeinfo.network.addresses (adresses on br-client, see question 4)
• create an issue to extend the respondd module for gluon-mesh-babel (see notice 1)

status-page-api:

• add "protocol" field to /cgi-bin/dyn/neighbours-batadv
• provide information about babel neighbours in /cgi-bin/dyn/routing-metrics
• rename to /cgi-bin/dyn/routing-metrics
• legacy symlink to /cgi-bin/dyn/neighbours-batadv
• port /cgi-bin/dyn/{stations,neighbours-nodeinfo} to lua (adapt work done in reduce batman dependency in status page #745)
• use generic function to get mesh ifaces in /cgi-bin/interfaces (see question 2)
• use generic function to get mesh ifaces in /cgi-bin/dyn/stations?iface (see question 2)
• use generic function to get mesh ifaces in /cgi-bin/dyn/neighbours-nodeinfo?iface (see question 2)

status-page:

• rename /cgi-bin/dyn/neighbours-batadv to /cgi-bin/dyn/routing-metrics (see here)
• differentiate between batman and babel metrics and show them differently (see here)

general:

• test in babel
• test in batman-adv
• docs: add documentation about gluon-status-page (see here)

Notices:

1. these resources remain unimplemented in the gluon-mesh-babel respondd provider:
   • nodeinfo.software.babeld
   • statistics.clients
   • statistics.traffic
   • statistics.gateway
   • statistics.gateway_nexthop
   • neighbours.*

Questions:

1. Why do we have providers/neighbours-batadv instead of using respondd neighbours?
2. How do we get the mesh ifaces?
3. Do we need the statistics api part of gluon-mesh-batman-core/respondd?
4. Is the br-client iface still existing in babel?
5. Can we write the needed respondd provider as general provider for both mesh protocols?

[christf]

2. can be answered with: https://github.com/freifunk-ffm/gluon/blob/n_babel-work/package/gluon-mesh-babel/files/lib/gluon/upgrade/980-gluon-mesh-babel-firewall#L9

[lemoer]

@rotanid Could you assign me on these issue?

[lemoer]

The status-page depends on the respondd facts nodeinfo.network.mesh.*.interfaces[] = $mac to find out which wifi/mesh neighbour has $mac:

{ "nodeinfo": { "network": { "mesh": {

    "bat0": {
        "interfaces": {
            "tunnel": [
                "66:6a:b3:de:dd:58"
            ],
            "wireless": [
                "66:6b:b5:de:dd:58",
                "66:6b:b4:de:dd:58"
            ],
            "other": [
                "66:67:b4:de:dd:58"
            ]
        }
    }

} } }

As bat0 is the interface name, we have a problem in babel to hold the convention here. We do not have an equivalent to such an interface in babel. How should we name this section in babel?

An unbeautiful solution would be using nodeinfo.network.mesh.babel.interfaces[]...

[christf]

actually since in theory there could be more than one mesh protocol on one node, using nodeinfo.network.mesh.babel.interfaces[] does not seem so ugly to me. this would also allow for leaving bat0 as it is even though it seems sensible to call it batman instead of bat0.

[christf]

4. br-client is for the moment still existing in babel however there seems to be some pull to remove it. at a later stage.
5. this is probably possible but I do not think this is a good idea - what if more than one mesh protocol is used on one node in the future? Shouldn't each report its own metrics?

[christf]

#745 is an early work which will likely be superseeded by the results of the work going into this issue.

[lemoer]

Back to the question how we get the mesh ifaces: (Q2)

• How do we solve this in shell?
  • Not at all. We will switch to lua and use the work done in reduce batman dependency in status page #745.
• Is there a lua function which is exported and can be used?
  • No and Yes. We could consider outsourcing find_meshes() to an includable path.
  • Or maybe we should consider using this:
    • ubus call network.interface dump | jsonfilter -e "@.interface[@.proto='gluon_mesh' && @.up=true].device
    • (converted to lua)
    • I think @NeoRaider preferred this version, but I'm not sure.
  • How should we name this function and where should it be placed?

[lemoer]

What is the current status of the br-client interface? (Q4)

[christf]

br-client will remain in gluon for quite some time. The gluon-client-bridge-babel has been obsoleted by the change in gluon-client-bridge. This was taken from an irc discussion from last week.

I feel find_meshes() is the way to go in lua-context. However I do not know where this function should be placed. If you provide the place @NeoRaider, I will put it there as part of PR #934.

EDIT It should be considered that find_meshes currently does a different thing than the above ubus call as it does not consider if an interface is currently up.

Edit2: actually find_meshes() in the firewall will be obsoleted by #938 hence the babel PR itself would not use this function any more after #938 has been merged.
That means this PR could

• implement a version of find_meshes that includes checking for link status without having the function available in a central place
• embed the above ubus call
• a third option arises by add zones having proto = gluon_mesh to firewall mesh-zone #938 because the statuspage could read all interfaces that are in the mesh network zone from uci as well.

[christf]

as discussed on irc with @neoraider he liked the ubus version that must be converted to lua and should be placed in gluon.util. I took the liberty of implementing this in PR #990

[christf]

as discussed with lemoer, I have just pulled the rebase_statuspage branch into the babel-PR and will continue the integration there.

[christf]

closing because nothing is left to do for this issue.