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)")
Add support for IBSS meshing. Leave target marked as BROKEN for IBSS
as stability is unknown and WiFi LEDs are not working.
Functionality was tested in the network of Freifunk Frankfurt with other
ipq40xx and ar71xx devices.
This commit allows for binary content in patches created via 'make
update-patches'.
Binary patches are needed for BDFs required for al boards on the new
ipq40xx target. Before this commit, binaries were omitted from the
generated patch which resulted in the patch not able to apply.
Patches without binary content do not differ in case they are created
with the '--binary' flag.
Support is marked as broken because this device is sold in two variants,
one with 64M RAM and another with 128M. As of now 64M is not enough
for ath10k with 5GHz enabled.
As there is no indication known which variant one will get better mark
it as broken.
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
The new extra_image command allows to copy additional images that don't
fall into the sysupgrade or factory categories to the output directory.
These images will be placed in the "other" subdirectory.
The extra_image command takes 3 arguments: in_suffix (suffix in OpenWrt
bin directory), out_suffix (suffix in Gluon output directory) and ext (file
extension). Example:
extra_image '-tftp' '-tftp' '.bin'
The ext argument can be omitted to control the whole filename suffix
including the extension from in_suffix and out_suffix. Multiple extra_image
commands can be used for a single device; aliases work as usual.
Based-on-patch-by: David Bauer <mail@david-bauer.net>
bc7abe8729f3 include/kernel-build.mk: fix kernel rebuild on backport patch changes
c99c70e05303 kernel: backport page fragment API changes from 4.10+ to 4.9
3e81365141e4 kernel: gen_stats: Fix netlink stats dumping in the presence of padding
dd1f97b37d41 ramips: clean up and fix MT7621 NAND driver issues
68f40d7ecc4c mt76: update to the latest version
16a9ddfe64e2 ramips: ethernet: use own page_frag_cache
0e6cfb691914 ramips: ethernet: use skb_free_frag to free fragments
This commit makes use of the Power-LED as Diag-LED, allowing the LED to
work as a status indicator for config-mode.
Signed-off-by: David Bauer <mail@david-bauer.net>
