Buttons of AVM FritzBox 4020 are incorrectly flagged as active high.
This was an oversight as RFKill button was working as expected even
with incorrectly flagged GPIO.
Config mode is still accessable but will start on any button press, not
only for the ones >= 10 seconds.
This commit corrects this behavior to the expected one (10 second long
press necessary to enter config mode).
8f5c55f63ece tools/e2fsprogs: update to 1.44.1
d35a7bf4b462 e2fsprogs: bump to 1.44.0
79ac69d9c926 tools/e2fsprogs: Update to 1.43.7
5d9114c9cb3b tools/e2fsprogs: Update to 1.43.6
7955fab22ac4 tools/e2fsprogs: Update to 1.43.5
866e5b495677 tools/e2fsprogs: Update to 1.43.4
a964738a5c88 Revert "tools/e2fsprogs: fix building on a glibc 2.27 host"
1e09cbf11844 tools/bison: Update to 3.0.5
9e864bfccea5 mac80211: brcmfmac: fix compilation with SDIO support
13f219569d4c mac80211: brcmfmac: backport patch setting WIPHY_FLAG_HAVE_AP_SME
0c76265d0819 mac80211: brcmfmac: backport important changes from the 4.19
9d8940c5b92f mac80211: brcmfmac: backport important changes from the 4.18
84ef414bd422 mac80211: brcmfmac: backport important changes from the 4.16
57102f6c0633 mac80211: brcmfmac: backport important changes from the 4.15
6805e44004b7 mac80211: brcmfmac: backport important changes from the 4.14
e3bc2e488d03 mac80211: brcmfmac: backport important changes from the 4.13
00b4e6567726 mac80211: brcmfmac: backport important changes from the 4.12
f8c364b72042 mac80211: brcmfmac: backport use-after-free fix from 4.11
85e6ac468efc mac80211: brcmfmac: group 4.11 backport patches
d3b8b5be3455 openssl: update to version 1.0.2p
f3865bd4efa8 kernel: bump kernel 4.4 to version 4.4.148
5886a5060a4c mbedtls: update to version 2.7.5
9bc43f3e65bc curl: fix some security problems
b3983323a1f2 wpa_supplicant: fix CVE-2018-14526
6449ed155301 tools: findutils: fix compilation with glibc 2.28
6e78c5502c94 tools: m4: fix compilation with glibc 2.28
583fd4b229b0 brcm47xx: revert upstream commit breaking BCM4718A1
Fixes build with glibc 2.28.
309414ee8d uclient: update to latest git HEAD
bcf91e578c downloads.mk: introduce name-agnostic PROJECT_GIT variable
b7e3f10e80 sdk: include arch/arm/ Linux includes along with arch/arm64/ ones
d93ef3c8c8 sdk: bundle usbip userspace sources
e5b7404f25 kmod-sched-cake: bump to 20180716
2725ad8de4 iproute2: merge upstream CAKE support
28d4e55432 WDR4900v1 remove dt node for absent hw crypto.
21c317a892 build: fix compile error when a package includes itself in PROVIDES
aee5c53a8d apm821xx: fix sata access freezes
54b91c85e7 Revert "iproute2: tc: bump to support kmod-sched-cake"
90eac8984a Revert "kmod-sched-cake: bump to 20180716"
91c9400816 scripts: bundle-libraries: fix build on OS X (FS#1493)
54c0ef6ff5 build: bundle-libraries.sh: patch bundled ld.so
79c8f2f50b mtd: improve check for TRX header being already fixed
828eaeee25 mtd: support bad blocks within the mtd_fixtrx()
8d4da3c589 iproute2: tc: bump to support kmod-sched-cake
0e1606ba3d kmod-sched-cake: bump to 20180716
c6a46c6e1d LEDE v17.01.5: revert to branch defaults
248b358903 LEDE v17.01.5: adjust config defaults
38e704be71 kernel: bump kernel 4.4 to version 4.4.140
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)")
aaecfecdcd kernel: bump kernel 4.4 to version 4.4.139
b08003223a base-files: fix links in banner.failsafe
71019a7605 ar71xx: fix 5 GHz Wi-Fi on NBG6716
ba5c0a1dea Revert "base-files: fix UCI config parsing and callback handling"
5c6a8a9cdb kernel: bump kernel 4.4 to version 4.4.138
cf4a37a581 uci: add missing 'option' support to uci_rename()
7fc94b2a25 mac80211: rt2x00: no longer use TXOP_BACKOFF for probe frames
b03826d8aa kernel: bump kernel 4.4 to version 4.4.137
21f44e3389 map: add ealen as configurable uci parameter
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
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>
