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>
Gluon has multiple ways to obtain unique MAC-addresses. They are either
provided by the WiFi driver or derived from the primary MAC-address.
Quoting the same file:
> It's necessary that the first 45 bits of the MAC address don't
> vary on a single hardware interface, since some chips are using
> a hardware MAC filter. (e.g 'rt305x')
This currently fails in case the rt35xx based chips mac address differs
from the primary MAC. In this case, the MAC address for the client0 radio
(vif 1) comes from the WiFi driver. As there is only a single
MAC-address provided by '/sys/class/ieee80211/phyX/addresses' but the
MAC-address for mesh 0 (vif 2) is derived from the Node-ID, resulting in
different first 45 bits. The WiFi won't come up altogether in this case.
This commit verifies at least 4 MAC-Addresses are provided by the WiFi
driver. If this is not the case, all MAC-addresses are derived from the
primary MAC. This way, affected radios are working correctly.
This commit distributes dualband radios evenly on 2.4 GHz and 5GHz with
2.4 GHz being prioritised higher than 5 GHz. This means in case a device
has only a single radio and this radio supports operation in both bands,
it will be set to 2.4 GHz.
Tested-by: Martin Weinelt <martin@darmstadt.freifunk.net>
Signed-off-by: David Bauer <mail@david-bauer.net>
Allow odhcp6c to fork the script to handle router
advertisments in 30 seconds intervals. This is the value
that was previously used in Gluon v2018.1 / LEDE 17.01.
The default value is 3 seconds and while it is RFC compliant
it can put alot of pressure on even moderately sized devices.
Signed-off-by: Martin Weinelt <martin@darmstadt.freifunk.net>
log-file /dev/stderr is broken for babeld as it eats log messages for debug log.
This commit gets rid of the option. This allows -d N to be used as babeld command
line option.
This patch makes use of the new feature in l3roamd to gracefully
add, remove and list the mesh interfaces that are currently in use. This
helps when changing mesh interfaces often - a characteristic of the
wireguard protocol implementation as in the previous behavior all local
clients are dropped when adjusting mesh interfaces.
gluon-wan is a sudo-like exec wrapper that switches the process group to
gluon-mesh-vpn, making it use the WAN dnsmasq rather than resolving over
the mesh.
Note that this only affects DNS at the moment. Processes running under
gluon-wan will still use the regular mesh IPv6 routing table, and not the
WAN routing table. This is not a problem for IPv4, as there is only one
IPv4 routing table.
Fixes#1575
Rename to respondd.c / respondd.so, gluon.mk expects these names. This way
we can remove the install code. The installed filename is changed to
gluon-mesh-babel.so, bringing it in line with out common naming scheme.
The redirect and dnat target are needed for gluon-alt-esc-client to
forward frames to the selected, alternative gateways.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
This adds support for the TP-Link TL-WR902Ac v1 travel router.
The device is marked as broken due to 64MB which might be insufficient
in certain environments.
Before 7827f89, mandatory hostname field in config mode was
pre-filled with the default hostname.
This commit adds the config_mode.hostname.prefill option for
controlling the default value.
this activates the package by default when using the batman feature
while still allowing to explicitly remove it like this:
GLUON_SITE_PACKAGES := \
-gluon-ebtables-limit-arp
gluon-config-mode-geo-location-osm extends the
gluon-config-mode-geo-location with a location picker based on
OpenStreetMaps.
Based-on-patch-by: Jan-Tarek Butt <tarek@ring0.de>
The new code is shorter and uses more readable variable names. It does not
depend on specifically named input fields anymore (allowing to use multiple
maps on the same page), and only uses well-defined interfaces to trigger
revalidation of input fields.
The Map model class allows to add OSM maps to gluon-web forms.
Let gluon-respondd expose "MemAvailable" from /proc/meminfo to allow for
a more realistic memory-usage estimation.
Information on MemAvailable can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773
As already done with other config mode texts, the altitude field now has
default texts that are used when they are not set in the site i18n files.
The altitude-help text has been removed from site i18n; instead, the
geo-location-help text now overrides the whole section description
including the part that mentions the altitude.
This reverts commit b3d7011130.
with this change, DNS in batman-adv based networks is broken.
although the revert breaks babel based networks, this is not as big of a problem.
This device is a dual 5GHz device. It is recommended to manually change the
radio of the first device to the lower 5GHz channels and the second radio
to the upper 5GHz channels.
The commit b3762fc61c ("gluon-client-bridge: move IPv4 local subnet route
to br-client (#1312)") moves the IPv4 prefix from the local-port interface
to br-client. A client requesting an IPv4 connection to the IPv4 anycast
address of the node (the device running gluon) will create following
packets:
1. ARP packet from client to get the MAC of the mac address of the anycast
IPv4 address
2. ARP reply from node to client with the anycast MAC address for the IPv4
anycast address
3. IPv4 packet from client which requires reply (for example ICMP echo
request)
4. ARP request for the client MAC address for its IPv4 address in prefix4
(done with the mac address of br-client and transmitted over br-client)
5. IPv4 packet from node (transmitted over br-client with br-client MAC
address) as reply for the client IPv4 packet (for example ICMP echo
reply)
The step 4 and 5 are problematic here because packets use the node specific
MAC addresses from br-client instead of the anycast MAC address. The client
will receive the ARP packet with the node specific MAC address and change
their own neighbor IP (translation) table. This will for example break the
access to the status page to the connected device or the anycast DNS
forwarder implementation when the client roams to a different node.
This reverts commit b3762fc61c and adds an
upgrade code to remove local_node_route on on existing installations.
The commit b3762fc61c ("gluon-client-bridge: move IPv4 local subnet route
to br-client (#1312)") moves the IPv4 prefix from the local-port interface
to br-client. A client requesting an IPv4 connection to the IPv4 anycast
address of the node (the device running gluon) will create following
packets:
1. ARP packet from client to get the MAC of the mac address of the anycast
IPv4 address
2. ARP reply from node to client with the anycast MAC address for the IPv4
anycast address
3. IPv4 packet from client which requires reply (for example ICMP echo
request)
4. ARP request for the client MAC address for its IPv4 address in prefix4
(done with the mac address of br-client and transmitted over br-client)
5. IPv4 packet from node (transmitted over br-client with br-client MAC
address) as reply for the client IPv4 packet (for example ICMP echo
reply)
The step 4 is extremely problematic here. ARP replies with the anycast IPv4
address must not be submitted or received via bat0 - expecially not when it
contains an node specific MAC address as source. When it is still done then
the wrong MAC address is stored in the batadv DAT cache and ARP packet is
maybe even forwarded to clients. This latter is especially true for ARP
requests which are broadcast and will be flooded to the complete mesh.
Clients will see these ARP packets and change their own neighbor IP
(translation) table. They will then try to submit the packets for IPv4
anycast addresses to the complete wrong device in the mesh. This will for
example break the access to the status page to the connected device or the
anycast DNS forwarder implementation. Especially the latter causes extreme
latency when clients try to connect to server using a domain name or even
breaks the connection setup process completely. Both are caused by the
unanswered DNS requests which at first glance look like packet loss.
An node must therefore take care of:
* not transmitting ARP packets related to the anycast IPv4 address over
bat0
* drop ARP packets related to the anycast IPv4 when they are received on
bat0 from a still broken node
* don't accept ARP packets related to the anycast IPv4 replies on local
node when it comes from bat0
Fixes: b3762fc61c ("gluon-client-bridge: move IPv4 local subnet route to br-client (#1312)")
optional = true does not make sense without a datatype. When no datatype is
set, the empty string will be a valid value, so data is never unset in the
write function. Restore the minlength(1) datatype so the contact setting is
deleted as intended when no value is provided.
