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.
8be3af93b4 uclient: update to latest git HEAD
2589f8589c sdk: include arch/arm/ Linux includes along with arch/arm64/ ones
7d15f96eaf iperf: bump to 2.0.12
4f3082583a sdk: bundle usbip userspace sources
5f23d0f3db include/feeds.mk: fix distfeeds.conf without per-feed repos
5828113986 bcm53xx: backport BCM5301X/BCM53573 dts commits from 4.19+
f7e647ca7b bcm53xx: switch USB 3.0 PHY DT description to use MDIO bus
9c110b97c6 bcm53xx: backport DT fix for I2C controller interrupt
b5b5f5dfa6 kernel: backport mtd support for subpartitions in DT
f8e57f450d kernel: backport mtd patches with Broadcom of_match_table-s
f7668334a8 Re-enable arbitrary IPv6 addresses as outer ip4-in-ip6 tunnel source address
d700eb187b kernel: remove duplicate #define's in at803x Ethernet PHY driver
20c64dabb6 kernel: re-add patch for AT8032 Ethernet PHY
93782d5e8e ca-certificates[18.06]]: remove myself as PKG_MAINTAINER
ce234299bc OpenWrt v18.06.0: revert to branch defaults
03b693064b OpenWrt v18.06.0: adjust config defaults
b0b5c64c22 Revert "ar71xx: define switch for rb-952ui-5ac2nd"
3442ec5d57 ar71xx: define switch for rb-952ui-5ac2nd
f4798d37f1 imagebuilder: add function to show manifest
a3dd6c939d ar71xx:add support for E750G v8
11a5128b98 ar71xx:add support for E750A v4
21ad5fb1ea ar71xx:add support for E558 v2
4dc0ff8183 brcm2708: split sdcard.img.gz into a sysupgrade and factory image
f24e012997 base-files: network.sh: gracefully handle missing network.interface ubus ns
d4a4f06589 iwinfo: update to version 2018-07-24
4a39d8cfd0 iwinfo: bump to latest git HEAD
cb73dd21a3 ar71xx: rbspi: fix RB wAP AC gpio conflict and LED
bb06f6d3ba ar71xx: add missing diag LED support for RB wAP 2nD
c8e8ff1c9f brcm47xx: rework model detection
ca0c649a38 bcm53xx: revert SPI controller commit breaking flash reads
cf5a892430 dnsmasq: bump to dnsmasq v2.80test3
bf1b0fad2b dnsmasq: don't use network functions at boottime (FS#1542)
cb9d5f0a7c dnsmasq: bump to latest patches on 2.80rc2
962e86d9af brcm47xx: revert upstream commit breaking BCM4718A1
29aab93ea2 mac80211: backport brcmfmac fixes & debugging helpers from 4.18
4e7f4777b0 odhcpd: update to latest git HEAD
da0dd6adc2 ubus: update to latest git HEAD
3f0d44b8de firewall: update to latest git HEAD and build with LTO
69021e9b89 ubus: update to latest git HEAD
6302f0161b libubox: update to latest git HEAD
f91a0f3b1a wireguard-tools: add wireguard_watchdog script
f1dbfa1937 wireguard: bump to 0.0.20180718
ff91b32d26 wireguard: bump to 0.0.20180708
b84a1c56f3 build: do not alter global default package selection from profiles
90b15b00a2 WDR4900v1 remove dt node for absent hw crypto.
a80276235a iproute2: tc: backport canonical cake support
5b12057d7c build: fix compile error when a package includes itself in PROVIDES
8a0ad2660a apm821xx: fix sata access freezes
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)")
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>
