can not -> can't
routers -> router's
continure -> continue
to next -> to the next
TMP -> temporary
for current -> for the current
continure -> continue
with next -> with the next
thier -> there
provides -> provide
possition -> position
therfore -> therefore
This MR includs only the VPN MODE of the hoodselector whitch simply set
hoods base on their geopositions.
Signed-off-by: Jan-Tarek Butt <tarek@ring0.de>
The batctl v2013.4 build was removed from the batman-adv-legacy package
as the current, upstream batctl releases work with batman-adv-legacy,
too.
As a replacement we need to add the upstream batctl dependency to
gluon-mesh-batman-adv-14 to have a batctl available again here.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
The commit a080049735 ("gluon-status-page-mesh-batman-adv: Retrieve TQ of
neighbors with non-best direct link") removed the check whether a neighbor
has the BATADV_ATTR_FLAG_BEST set. But consumers may still want to filter
out or mark neighbors which don't have this flag set. To assist with such a
feature, enhance the neighbor object with an extra boolean "best" attribute
which stores whether the BATADV_ATTR_FLAG_BEST was found or not.
Reported-by: Vincent Wiemann <webmaster@codefetch.de>
The commit ee63ed42fe ("gluon-mesh-batman-adv: List neighbors with
non-best direct link") removed the check whether a neighbor has the
BATADV_ATTR_FLAG_BEST set. But consumers may still want to filter out or
mark neighbors which don't have this flag set. To assist with such a
feature, enhance the neighbor object with an extra boolean "best" attribute
which stores whether the BATADV_ATTR_FLAG_BEST was found or not.
Reported-by: Vincent Wiemann <webmaster@codefetch.de>
Links between two direct neighbors are not always the best route between
these devices. The flag BATADV_ATTR_FLAG_BEST would not be set for these
originator entries and the respondd module would just ignore this entry.
If these neighbors are not accepted and returned to the status page then
some of the neighbor entries will show a name, (acceptable) signal strength
and mac address but no TQ value.
Fixes: 28668c8c52 ("gluon-status-page: API")
Links between two direct neighbors are not always the best route between
these devices. The flag BATADV_ATTR_FLAG_BEST would not be set for these
originator entries and the respondd module would just ignore this entry.
This causes missing links in meshviewer and similar tools. And when the
link quality is nearly equal and but fluctuates slightly, these links will
from time to time appear and disappear on the map.
Fixes: 2e0e24a992 ("announce neighbours using alfred/gluon-announce")
The device is broken until the next release. The LEDs are currently not
working (fixed in current OpenWRT master).
Also give a brief explanation about the BROKEN status being dependent on
the WiFi chip used and not the SoC family in general.
When two domains alias the same name (or one aliases another), display a
meaningful error message like:
Failed to alias domain 'foo' as 'bar', name already taken by
domain 'baz'.
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: 89a9d8138c ("gluon-mesh-batman-adv-core: Announce client count by frequency")
Reported-by: Pascal Wettin <p.wettin@gmx.de>
