gluon-mesh-batman-adv: Only use local TT to count non-wifi clients

[ecsv]

The amount of local wifi clients is currently counted by two different ways:

• asking the kernel wifi layer for the number of of clients on 2.4GHz and 5GHz band
• asking batman-adv for the number of non-timed out entries in the local translation table with WiFi flag

The number of wifi24+wifi5 and the number of TT wifi client counts are reported via respondd to various consumers. The ffrgb meshviewer is displaying these values as:

• 2,4 GHz: wifi24
• 5 GHz: wifi5
• other: (TT local wifi+non-wifi clients) - (wifi24 + wifi5)

But the local translation table is holding entries much longer than the wifi layer. It can therefore easily happen that a wifi client disappears in the kernel wifi layer and batman-adv still has the entry stored in the local TT.

The ffrgb meshviewer would then show this count in the category "other". This often results in confusions because "other" is usually for ethernet clients. And nodes with a frequently disappearing larger group of clients (near bus stations or larger intersections) often show most clients under the group "other" even when this devices doesn't have a LAN ethernet port.

It is better for presentation to calculate the number of total wifi clients by summing up wifi24 + wifi5. And getting the number of total clients (non-wifi + wifi) by adding the result of the previous calculation to the sum of non-wifi client in the local batman-adv translation table.

Fixes: 89a9d81 ("gluon-mesh-batman-adv-core: Announce client count by frequency")

[ghost]

I upgrade a device to Gluon v2018.2.1 and i am wondering why the total count is smaller than the wifi count most of the time.

"clients":1,
"clients_wifi24":4,
"clients_wifi5":0,
"clients_other":0

Would your commit fix that issue, too?

[ecsv]

I have no idea what the bug(?) is in 2018.2.1 - so I cannot tell you whether this would fix it.

But my initial guess is: yes

[neocturne]

@bobcanthelpyou Yes, I assume this PR will fix that "issue". It occurs when a wifi client is idle, so it will only be seen by the WLAN adapter (as it is still associated), but not by batadv (as it doesn't send any packets). This behaviour has become more visible with Gluon v2018.2, as we now ignore idle clients after 1 minute.