replace vis with alfred about gluon HOT 12 CLOSED

Uptime?

from gluon.

• fastd pubkey?
• contact info (at least e-mail)?

I'd like to completely decentralize the information needed to operate the network.
Pubkeys in alfred would mean that pushing the key to one VPN server (and connecting to this one) is enough for every other server to get the key via alfred.
Publishing contact information on the other hand may be considered problematic privacy-wise (as is publishing location along with a maybe identifying name) and thus must be optional. But having contact information of a router's operator is important if something breaks or needs upgrade, and having a central list means another means of communication, someone has to maintain it etc.

from gluon.

@neoraider: uptime sounds useful. maybe add load avergage and memory usage, too/

@jplitza: I don't think fastd pubkeys and (optionally) contact info published via alfred is important for the first gluon release and will require more dicussion.

from gluon.

Hmm, I'm not sure what the usecase for the keys would be. And I'm not sure if we should encourage publishing contact info through the mesh...

In Lübeck, we save contact information together with the fastd keys, but we keep that repository private.

from gluon.

• RX/TX stats? I think bat0 would be the most meaningful interface.

from gluon.

RX/TX as increasing counter, since last push or normalized to bytes/second?

Also, bat0 is the most meaningful for "client traffic", but maybe "forwarded mesh traffic" is a remarkable figure as well? Indicates how essential the node is for the current network usage. (no idea which interface that would be though. :D Sum of all batman-adv interfaces?)

from gluon.

I think batman-adv has internal statistics for forwarded mesh traffic, available through ethtool.

from gluon.

• MAC address of bat0

All MAC addresses except br-client and bat0 are real clients, so we can finally fix the map to show only those.

from gluon.

Why can't we generate the bat0 MAC address from the other(s)? Every router has multiple MAC addresses generated from the radio MAC addresses, and we could generate one more for bat0.

from gluon.

The map code currently has a few hacks that try to recognize "similar" MAC addresses, but that's just stupid.

We now have a way to get the information to the map server, so we shouldn't require the MAC adresses to be similar for the map to work correctly, but just announce all relevant MAC addresses.

from gluon.

I think the fuzzing is still needed. The way it works now (not sure what exactly that is), my router has three MAC adresses which are identified by fuzzing: mesh-vpn, br-client and wlan0-1 (don't know why not wlan1-1).

from gluon.

mesh-vpn is a interface "inside" bat0, as is wlan0-1. Those will never be reported as TT entries by batman-adv, but as secondaries.

We get all addresses reachable through br-client as TT entries though. The way Linux bridges work, we should only ever see the address of br-client, as the other interfaces like wlan0 should never send or receive packets themselves. bat0 is special as batman-adv maintains an internal TT entry for it even when it is part of the bridge.

Your comment made me think though if we shouldn't just give bat0 the same address as br-client (as it's a bridge, so everything should be fine)

from gluon.