fec1aa6dfb mt76: update to the latest version
224fa47bf9 ramips: mark toggle input on EX6150 as a switch
3a05aa17db mac80211: Remove 357-mac80211-optimize-skb-resizing.patch
171d8bce0c ramips: remove factory image for TP-Link Archer C2 v1
2eb8444363 ath79: fix USB power GPIO for TP-Link TL-WR810N v1
d5a8e85878 wolfssl: Backport fix for CVE-2021-3336
cf5e5204d9 bcm63xx: sprom: override the PCI device ID
4465b44fc1 kernel: bump 4.14 to 4.14.219
4b9ade65ec bcm63xx: R5010UNv2: fix flash partitions for 16MB flash
ab9cb390be hostapd: fix P2P group information processing vulnerability
1e90091c5d opkg: update to latest git HEAD of branch openwrt-19.07
312c05611b kernel: bump 4.14 to 4.14.218
3100649458 wolfssl: enable HAVE_SECRET_CALLBACK
e9d2aa9dc6 wolfssl: Fix hostapd build with wolfssl 4.6.0
2044c01de8 wolfssl: Update to v4.6.0-stable
5ac0b2b431 mvebu: omnia: make initramfs image usable out of the box
[ Upstream commit 851d0a73c90e6c8c63fef106c6c1e73df7e05d9d ]
From: Joseph Huang <Joseph.Huang@garmin.com>
When enabling multicast snooping, bridge module deadlocks on multicast_lock
if 1) IPv6 is enabled, and 2) there is an existing querier on the same L2
network.
The deadlock was caused by the following sequence: While holding the lock,
br_multicast_open calls br_multicast_join_snoopers, which eventually causes
IP stack to (attempt to) send out a Listener Report (in igmp6_join_group).
Since the destination Ethernet address is a multicast address, br_dev_xmit
feeds the packet back to the bridge via br_multicast_rcv, which in turn
calls br_multicast_add_group, which then deadlocks on multicast_lock.
The fix is to move the call br_multicast_join_snoopers outside of the
critical section. This works since br_multicast_join_snoopers only deals
with IP and does not modify any multicast data structures of the bridge,
so there's no need to hold the lock.
Steps to reproduce:
1. sysctl net.ipv6.conf.all.force_mld_version=1
2. have another querier
3. ip link set dev bridge type bridge mcast_snooping 0 && \
ip link set dev bridge type bridge mcast_snooping 1 < deadlock >
A typical call trace looks like the following:
[ 936.251495] _raw_spin_lock+0x5c/0x68
[ 936.255221] br_multicast_add_group+0x40/0x170 [bridge]
[ 936.260491] br_multicast_rcv+0x7ac/0xe30 [bridge]
[ 936.265322] br_dev_xmit+0x140/0x368 [bridge]
[ 936.269689] dev_hard_start_xmit+0x94/0x158
[ 936.273876] __dev_queue_xmit+0x5ac/0x7f8
[ 936.277890] dev_queue_xmit+0x10/0x18
[ 936.281563] neigh_resolve_output+0xec/0x198
[ 936.285845] ip6_finish_output2+0x240/0x710
[ 936.290039] __ip6_finish_output+0x130/0x170
[ 936.294318] ip6_output+0x6c/0x1c8
[ 936.297731] NF_HOOK.constprop.0+0xd8/0xe8
[ 936.301834] igmp6_send+0x358/0x558
[ 936.305326] igmp6_join_group.part.0+0x30/0xf0
[ 936.309774] igmp6_group_added+0xfc/0x110
[ 936.313787] __ipv6_dev_mc_inc+0x1a4/0x290
[ 936.317885] ipv6_dev_mc_inc+0x10/0x18
[ 936.321677] br_multicast_open+0xbc/0x110 [bridge]
[ 936.326506] br_multicast_toggle+0xec/0x140 [bridge]
Fixes: 4effd28c1245 ("bridge: join all-snoopers multicast address")
Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Link: https://lore.kernel.org/r/20201204235628.50653-1-Joseph.Huang@garmin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[linus.luessing@c0d3.blue: backported to 4.4]
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
Some newer MT7628 based routers (notably the TP-Link Archer C50 v4) are
shipped with a chip-id of 0x7600 in the on-flash EEPROM. Add this as a
possible valid ID.
This fixes unstable WiFi on some units of the TP-Link Archer C50 v4.
Implement a configurable MLD Querier wake-up calls "feature" which
works around a widely spread Android bug in connection with IGMP/MLD
snooping.
Currently there are mobile devices (e.g. Android) which are not able
to receive and respond to MLD Queries reliably because the Wifi driver
filters a lot of ICMPv6 when the device is asleep - including
MLD. This in turn breaks IPv6 communication when MLD Snooping is
enabled. However there is one ICMPv6 type which is allowed to pass and
which can be used to wake up the mobile device: ICMPv6 Echo Requests.
If this bridge is the selected MLD Querier then setting
"multicast_wakeupcall" to a number n greater than 0 will send n
ICMPv6 Echo Requests to each host behind this port to wake
them up with each MLD Query. Upon receiving a matching ICMPv6 Echo
Reply an MLD Query with a unicast ethernet destination will be sent
to the specific host(s).
Link: https://issuetracker.google.com/issues/149630944
Link: https://github.com/freifunk-gluon/gluon/issues/1832
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
This backports two fixes related to operation on DFS-required
channels.
When a DFS-required channel was selected as the regular
(non-outdoor-mode) 5 GHz channel, hostapd would switch to a non-DFS
channel as OpenWrt did not pass a chanlist of allowed ACS channels.
When hostapd is given a single channel for the chanlist or there's no
available channel left (all allowed channels are in the no-occupancy
period), hostapd prints "no DFS channels left, waiting for NOP to
finish" to the syslog but never stopped transmitting on this channel,
still sending out beacon frames and allowing client data transfer.
When the GTK is offloaded, MT7610 won't transmit any multicast frames.
This is most likely due to a bug in the offloading datapath. MT7612 is
not affected.
Disable GTK offloading for now. It can be re-enabled once the bug in the
offloading path is fixed.
Signed-off-by: David Bauer <mail@david-bauer.net>
This gives us WPA3 support out of the box without having to manually disable
hardware crypto. The driver will fall back to software crypto if the connection
requires management frame protection.
THis allows us to use WPA3 features (Private-WiFi SAE & OWE) on
ramips-mt7620.
d9244a1b5b generic: ar8216: fix unknown packet flooding for ar8229/ar8236
429e4490c4 libpcap: fix library packaging issues
e678cb1595 kernel: bump 4.14 to 4.14.179
8fa4ed9ef7 fstools: update to the latest version
5c6dfb5bc0 fstools: update to the latest version
607809dcdc mac80211: Update to version 4.19.120
96d280cc37 scripts/download: add sources CDN as first mirror
55ccb04046 upgs: Remove extra _DEFAULT_SOURCE definition
ee480c50c1 dante: Fix compile with glibc
5f0e25d966 perf: build with NO_LIBCAP=1
005adba939 mac80211: ath10k: increase rx buffer size to 2048
0974d59b5f kernel: backport fix for non-regular inodes on f2fs
f40947a8c0 ath79: indicate boot/failsafe/upgrade for NanoBeam/Nanostation AC
65cf72d5d2 ath79: add SUPPORTED_DEVICES based on ar71xx for some devices
f9ef0c5705 kernel: bump 4.14 to 4.14.178
2df0ea042d wpad-wolfssl: fix crypto_bignum_sub()
ec6cb33452 mac80211: backport fix for an no-ack tx status issue
f141cdd200 hostapd: unconditionally enable ap/mesh for wpa-cli
54b6683390 wireless-regdb: backport three upstream fixes
55591e63bc curl: backport fix for CVE-2019-15601
35ea808b97 uboot-kirkwood: fix ethernet and usb
Compile-tested: all targets
This patch fixes a regression introduced in kernel v4.14. While the
commit message only mentions a performance penalty, the issue is
suspected to be the cause of spurious data bus errors on MIPS CPUs
(ar71xx target).
Fixes: #1982
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.
For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.
This patch now increases the maxmimum frame size from 1528 to 1656
bytes.
Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.
Fix originally found and developed by Ben Greear.
6160f773fef2 ipq40xx: add support for AVM FRITZ!Repeater 1200
63b1e8f8d226 ipq-wifi: add AVM FRITZ!Repeater 1200 bdf
496489ea95af uboot-fritz4040: update to latest HEAD
e30ca0d90a98 mac80211: update to version 4.19.85
b1ef0e443720 layerscape: Fix kernel patch
ad0463c2e875 kernel: Add missing configuration option
b0adf79c9e7c firewall: update to latest Git HEAD
b41619592792 firewall: update to latest git HEAD
3685f86cefac cns3xxx: use proper macros for defining partition regions
db345220b485 kernel: bump 4.14 to 4.14.155
538ca42ddad8 wireless-regdb: fix build when python2 from package feeds exists
2751c5c75219 wireless-regdb: fix patch fuzz
d6ecadb05c2b wireless-regdb: fix Makefile indentation
0a4071b550eb wireless-regdb: set PKGARCH:=all
e8d528af7e91 wireless-regdb: prefer python provided by make variable
53d8de0207e8 wireless-regdb: Make it build with python2
f2ef9b4feafe wireless-regdb: update to 2019.06.03
8fac0b398c34 ar71xx: fix buttons for TP-Link TL-WDR4900 v2
3c65c47ce6fd ar71xx: fix LED setup for TL-WDR4900 v2
b6c80f85cb7b ramips: set uImage name of WeVO 11AC NAS and W2914NS v2
e945c43142ab ar71xx: fix MAC address setup for TL-WDR4900 v2
8a21bc36229d ar71xx: fix MAC addresses for Archer C5 v1, C7 v1/v2, WDR4900 v2
As of OpenWrt commit b3d8b3ab8e6f ("mac80211: set noscan=1 if sta/adhoc/
mesh interfaces are present"), the issue workarounded by this patch cannot
occur anymore.
The factory firmware omits the JFFS2 end-marker while flashing via
web-interface. Add a 64k padding after the marker fixes this problem.
When the end-marker is not present, OpenWRT won't save the overlayfs
after initial flash.
If no mcast_rate is set for the wifi-iface then there is no rate_idx (0)
set for the bss. This breaks for example 5GHz meshpoint interfaces because
0 maps to a CCK rate (11Mbit/s).
It must also be avoided that the ath10k-ct internal state for the rates is
not synced with the mac80211 rates state. Otherwise, the user specified
rate (e.g. a wifi-iface mcast_rate for a meshpoint interface) will only be
set on startup. And a short while after that, ath10k-ct specific code in
ath10k_check_apply_special_rates is missing a valid rate in its own
structures and is then recalculating a new default rate. This default rate
is in most situations not the requested rate.
Fixes: a399b60735 ("ath10k/ath10k-ct: support multicast and management rate control")
Drivers with software rate control can directly use the selected multicast
rate for multicast/broadcast frames and the minimal basic rate for
management frames. But drivers with offloaded rate control algorithms must
be informed about such upper layer decisions to configure the
hardware/firmware.
A new BSS_CHANGED_MCAST_RATE is introduced in mac80211 to automatically
inform all drivers. ath10k can detect this event and forward it via WMI to
the driver. The already existing BSS_CHANGED_BASIC_RATES can be used to
select the management rate.
Without the WMI commands, a low rate (not necessarily one from the basic
rates) is used for bcast/mcast/management frames. This means that the
/etc/config/wireless settings basic_rate and mcast_rate would have no
effect on the rates selected by this driver for the mentioned frames.
This backports the TP-Link Archer C50 v4.
We are dropping the following upstream commits. They add support for the
TP-Link recovery-flag which enabled the web-recovery. As they are not
needed for the router to work, we drop them for now.
28cd2ca base-files: sysupgrade: support additional mtd options
1e06482 mtd: add logic for TP-Link ramips recovery magic
6e16dd1234 mt76: update to the latest version
76037756d0 kernel: bump 4.14 to 4.14.94
455bfd1065 kernel: bump 4.9 to 4.9.151
fafd7691e6 opkg: update to latest Git head
e789bd2243 opkg: drop argument from check_signature in opkg.conf
3603c2321d ramips: mt7621: fix 5GHz WiFi LED on ZBT WG3526
7f98cd8d50 odhcpd: fix onlink IA check (FS#2060)
abd0f7995e kmod-sched-cake: bump to latest cake
Compile-tested: ar71xx-{tiny,generic}, ramips-mt7621, x86-64
