Re: [PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA
On 6/20/21 4:30 PM, Sven Roederer wrote: Am Samstag, 19. Juni 2021, 20:36:10 CEST schrieb Hauke Mehrtens: On a DSA switch the ports have an upper device, the CPU device, e.g. eth0. This device has to be in up state to bring up the lower devices like lan1. Parse the link device from "ip link show" and bring it into up stated before bringing up the actual interface. This is needed to make network in failsafe on systems with DSA work. Hauke, I tested you patches on the Mikrotik RB750Gr3 and WDR3600 (as I did in FS#3866), this time with customized IP-adresses and patches applied to OpenWrt-21.02. For the WDR3600 the issue was fixed, but for the RB750 there is no network. I was not able to usr IPv6 link-local, OpenWrt default 192.168.1.1 or my custom IP-Address. The Rb750 is DSA, so it seems there is still something wrong. I'll retest with current master soon, to rule out issues based on 21.02-rc3. Sven Hi, I tried it on a lantiq device with the DSA patches applied and it works fine. Could you please share the content of this file: /tmp/board.json and the output of "ip addr" while in failsafe on a broken device please. You need all 3 patches and I am not aware of a difference between master and 21.02 in this area, but I only tried it on top of master. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: Traffic directly on lanX not working
On 6/20/21 11:01 AM, Birger Koblitz wrote: Hi, On 19.06.21 14:25, Hauke Mehrtens wrote: Hi, I am unable to send and receive packets directly on the lan1 interface when it is not part of a bridge. In wireshark on a connected host I do not see any packets from this device, but the link is up. When I use OpenWrt's default network configuration using a bridge, network works like expected. I took care of the VLAN 100 which is used by default, but this setup does not use any VLAN. I would like to use a very similar configuration for the failsafe mode which is also not working correctly. This is the same finding tmon had: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/598 The reason is a hardware limitation on RTL chip families 8380-9300, they require a port to be a member of VLAN 1 in order to send/receive traffic: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/602 I am not sure how to proceed. One solution is to set this up silently in the driver, but then the existence of vlan 1 would be intransparent to the user, a possible security risk. Birger Hi, Thank you for the links, I was not aware of this strange problem. Do you have access to a documentation of any of these chips or only some source code? We could add some special handling for these chips in the failsafe mode, let me look into this. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] base-files: failsafe: Fix IP configuration
Adapt the preinit_config_board() to the board.json network changes. It
now looks for the device and the ports variables to configure the LAN
network.
This works with swconfig configurations.
Fixes: FS#3866
Fixes: d42640e389a8 ("base-files: use "ports" array in board.json network for
bridges")
Signed-off-by: Hauke Mehrtens
---
.../files/lib/preinit/10_indicate_preinit | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index 3c5992979016..ae9fcfecc89e 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -72,28 +72,34 @@ preinit_config_board() {
json_select network
json_select "lan"
- json_get_vars ifname
+ json_get_vars device
+ json_get_values ports ports
json_select ..
json_select ..
- [ -n "$ifname" ] || return
+ [ -n "$device" -o -n "$ports" ] || return
+
+ # swconfig uses $device and DSA uses ports
+ [ -z "$ports" ] && {
+ ports="$device"
+ }
# only use the first one
- ifname=${ifname%% *}
+ ports=${ports%% *}
if [ -x /sbin/swconfig ]; then
# configure the switch, if present
json_get_keys keys switch
for key in $keys; do
- preinit_config_switch $key $ifname
+ preinit_config_switch $key $ports
done
else
# trim any vlan ids
- ifname=${ifname%\.*}
+ ports=${ports%\.*}
fi
- pi_ifname=$ifname
+ pi_ifname=$ports
preinit_ip_config $pi_ifname
}
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA
On a DSA switch the ports have an upper device, the CPU device, e.g.
eth0. This device has to be in up state to bring up the lower devices
like lan1.
Parse the link device from "ip link show" and bring it into up stated
before bringing up the actual interface.
This is needed to make network in failsafe on systems with DSA work.
Signed-off-by: Hauke Mehrtens
---
package/base-files/files/lib/preinit/10_indicate_preinit | 6 ++
1 file changed, 6 insertions(+)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index ae9fcfecc89e..a3bc289dd663 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -12,6 +12,12 @@ preinit_ip_config() {
fi
grep -q "$netdev" /proc/net/dev || return
+
+ # Get the link interface e.g. eth0 in lan1@eth0
+ iflink=$(ip link show dev ${netdev} |sed -nr 's/.*@([a-zA-Z0-9]*):
.*/\1/p')
+ if [ -n "$iflink" ]; then
+ ip link set dev $iflink up
+ fi
if [ -n "$vid" ]; then
ip link add link $netdev name $1 type vlan id $vid
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] base-files: failsafe: Remove the VLAN modifier from interface name
Some interfaces have a VLAN modifier like :t in lan1:t, this modifier
should be removed from the interface before calling preinit_ip_config().
Signed-off-by: Hauke Mehrtens
---
package/base-files/files/lib/preinit/10_indicate_preinit | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index a3bc289dd663..2fa812e91f73 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -103,6 +103,8 @@ preinit_config_board() {
else
# trim any vlan ids
ports=${ports%\.*}
+ # trim any vlan modifiers like :t
+ ports=${ports%\:*}
fi
pi_ifname=$ports
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
realtek: Traffic directly on lanX not working
Hi, I am unable to send and receive packets directly on the lan1 interface when it is not part of a bridge. I have seen this on today's OpenWrt master. I changed the OpenWrt network configuration like this: -- root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option device 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd39:7fe0:0309::/48' config device option name 'lan1' option macaddr '9a:0d:67:06:9a:40' config interface 'lan' option device 'lan1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' root@OpenWrt:/# -- The interface is configured and brought up correctly: -- root@OpenWrt:/# ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1504 qdisc mq state UP group default qlen 1000 link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::9a0d:67ff:fe06:9a40/64 scope link valid_lft forever preferred_lft forever 3: lan1@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 9a:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global lan1 valid_lft forever preferred_lft forever inet6 fd39:7fe0:309::1/60 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::980d:67ff:fe06:9a40/64 scope link valid_lft forever preferred_lft forever 4: lan2@eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff . -- I see that some packets are received, but the RX counter do not increase anymore: -- root@OpenWrt:/# ip -s link show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped missed mcast 117616 1497 0 0 0 0 TX: bytes packets errors dropped carrier collsns 117616 1497 0 0 0 0 2: eth0: mtu 1504 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 81280 0 0 0 TX: bytes packets errors dropped carrier collsns 7310 62 0 0 0 0 3: lan1@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 9a:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 66880 0 0 0 TX: bytes packets errors dropped carrier collsns 4972 46 0 0 0 0 4: lan2@eth0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 98:0d:67:06:9a:40 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 00 0 0 0 TX: bytes packets errors dropped carrier collsns 0 00 0 0 0 . -- In wireshark on a connected host I do not see any packets from this device, but the link is up. When I use OpenWrt's default network configuration using a bridge, network works like expected. I took care of the VLAN 100 which is used by default, but this setup does not use any VLAN. I would like to use a very similar configuration for the failsafe mode which is also not working correctly. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.0 Third release candidate
Hi, The OpenWrt community is proud to announce the third release candidate of the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year. Changes between OpenWrt 21.02.0-rc2 and 21.02.0-rc3 LuCI * LuCI network migration tool now migrates custom bridge MAC addresses. Software updates * Linux kernel updated to version 5.4.124 (from 5.4.119 in v21.02.0-rc2) * mac80211 updated to version 5.10.42-1 (from 5.10.34-1 in v21.02.0-rc2) * wireless-regdb updated to version 2021.04.21 (from 2020.11.20 in v21.02.0-rc2) Misc changes * opkg: Shows better error message when some dependencies are missing * sdk, imagebuilder: json-c, libnl-tiny, libubox, ubus, uci and lua are marked nonshared and will be taken from release build and not package build. Device support * New devices: SERCOMM NA502, Linksys EA8100 v1, Amped Wireless ALLY, Linksys E5600, JCG Q20, cudy WR2100, TP-Link Archer C6U v1 (EU), TP-Link Archer A6 v3, ZyXEL NR7101, ZTE MF283+ * Device fixes for: Xiaomi Router 3 Pro, HILINK HLK-7628N, WD My Net Wi-Fi Range Extender, ALLNET ALL-WAP02860AC, Senao APs, TP-Link AD7200 Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.0-rc3 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.0-rc3#known_issues For a detailed list of all changes since 21.02.0-rc2, refer to https://openwrt.org/releases/21.02/changelog-21.02.0-rc3 To download the 21.02.0-rc2 images, navigate to: https://downloads.openwrt.org/releases/21.02.0-rc3/ - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02 00/11] ramips: mt7621: backport support for 9 devices
On 6/8/21 11:45 AM, Petr Štetiar wrote: Hi, Tee has asked today about backport for Linksys EA8100v1 on IRC, I've noticed another such request in PR#4236[1] and decided to backport most of the new devices as it saves time during rebasing/cherry-picks, review etc. All those backports are straight and clean cherry picks from master, no modifications has been done, just simple Makefile merge conflict has been resolved on "firmware-utils: zytrx: Add util for ZyXEL specific header". I've just build tested[2] that testing/mt7621-21.02-rc2-backports[3] branch and provided all build artifacts like firmware images and packages for download[4] to make testing easier. Would be nice to get some feedback and ideally your `Tested-by:` for particular device. Thanks! 1. https://github.com/openwrt/openwrt/pull/4236 2. https://gitlab.com/ynezz/openwrt/-/jobs/1326795722 3. https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=shortlog;h=refs/heads/testing/mt7621-21.02-rc2-backports 4. https://foo.true.cz/minio/openwrt/staging-builds/testing-mt7621-21-02-rc2-backports/2c462a29/ramips-mt7621/bin Cheers, Petr Aashish Kulkarni (1): ramips: add support for Linksys E5600 Andreas Böhler (1): ramips: Add support for SERCOMM NA502 Bjørn Mork (2): firmware-utils: zytrx: Add util for ZyXEL specific header ramips: mt7621: Add support for ZyXEL NR7101 Chukun Pan (1): ramips: add support for JCG Q20 Georgi Vlaev (1): ramips: add support for TP-Link Archer C6U v1 (EU) Jonathan Sturges (1): ramips: add support for Amped Wireless ALLY router and extender Kevin Darbyshire-Bryant (1): firmware-utils: fix coverity zytrx.c resource leak Leon M. George (1): ramips: add support for cudy WR2100 Tee Hao Wei (1): ramips: add support for Linksys EA8100 v1 Vinay Patil (1): ramips: add support for TP-Link Archer A6 v3 package/boot/uboot-envtools/files/ramips | 13 + .../dts/mt7621_ampedwireless_ally-00x19k.dts | 21 ++ .../dts/mt7621_ampedwireless_ally-r1900k.dts | 32 +++ .../ramips/dts/mt7621_ampedwireless_ally.dtsi | 179 ++ .../linux/ramips/dts/mt7621_cudy_wr2100.dts | 201 +++ target/linux/ramips/dts/mt7621_jcg_q20.dts| 175 ++ .../linux/ramips/dts/mt7621_linksys_e5600.dts | 182 ++ .../ramips/dts/mt7621_linksys_ea8100-v1.dts | 8 + .../linux/ramips/dts/mt7621_sercomm_na502.dts | 212 .../ramips/dts/mt7621_tplink_archer-a6-v3.dts | 188 +++ .../dts/mt7621_tplink_archer-c6u-v1.dts | 213 .../linux/ramips/dts/mt7621_zyxel_nr7101.dts | 164 + target/linux/ramips/image/mt7621.mk | 148 .../mt7621/base-files/etc/board.d/01_leds | 18 +- .../mt7621/base-files/etc/board.d/02_network | 48 ++-- .../base-files/etc/board.d/03_gpio_switches | 3 + .../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 8 +- .../mt7621/base-files/etc/init.d/bootcount| 9 +- .../mt7621/base-files/lib/upgrade/platform.sh | 18 ++ tools/firmware-utils/Makefile | 1 + tools/firmware-utils/src/tplink-safeloader.c | 75 +- tools/firmware-utils/src/zytrx.c | 228 ++ 22 files changed, 2125 insertions(+), 19 deletions(-) create mode 100644 target/linux/ramips/dts/mt7621_ampedwireless_ally-00x19k.dts create mode 100644 target/linux/ramips/dts/mt7621_ampedwireless_ally-r1900k.dts create mode 100644 target/linux/ramips/dts/mt7621_ampedwireless_ally.dtsi create mode 100644 target/linux/ramips/dts/mt7621_cudy_wr2100.dts create mode 100644 target/linux/ramips/dts/mt7621_jcg_q20.dts create mode 100644 target/linux/ramips/dts/mt7621_linksys_e5600.dts create mode 100644 target/linux/ramips/dts/mt7621_linksys_ea8100-v1.dts create mode 100644 target/linux/ramips/dts/mt7621_sercomm_na502.dts create mode 100644 target/linux/ramips/dts/mt7621_tplink_archer-a6-v3.dts create mode 100644 target/linux/ramips/dts/mt7621_tplink_archer-c6u-v1.dts create mode 100644 target/linux/ramips/dts/mt7621_zyxel_nr7101.dts create mode 100644 tools/firmware-utils/src/zytrx.c Acked-by: Hauke Mehrtens ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02 03/11] ramips: mt7621: Add support for ZyXEL NR7101
On 6/8/21 1:10 PM, Bjørn Mork wrote:
Tested-by: Bjørn Mork
Unrelated, but confused the hell out of me:
I tested this by sysupgrading from a master based installation using a
5.10 kernel. And ended up with a tmpfs overlay because of:
[9.833676] UBIFS (ubi0:1): Mounting in unauthenticated mode
[9.845003] UBIFS error (ubi0:1 pid 561): ubifs_mount: 'compressor "zstd" is
not compiled in
[9.862780] mount_root: failed to mount -t ubifs /dev/ubi0_1 /tmp/overlay:
No error information
[9.880490] mount_root: overlay filesystem has not been fully initialized yet
[9.895085] mount_root: switching to ubifs overlay
[9.904741] mount_root: switching to ubifs failed - fallback to ramoverlay
So I reinstalled the 21.02 build by sysupgrading from the running 21.02,
and everything was fine again - as expected.
I realize that I did this to myself, and that this sort of downgrade
using sysupgrade is a pretty weird usecase. But maybe there are other
similar situations where we can end up with an unmountable UBIFS due to
the missing compressor?
The problem seems to be as simple as CONFIG_UBIFS_FS_ZSTD being
undefined in target/linux/generic/config-5.4 in 21.02. It is defined
for a number of targets, though. Just not ralink.
This was fixed in master by commit
be7b56027899 ("kernel: enable lzo, zlib and zstd in ubifs").
Obvious candidate for backport to 21.02?
This problem should affect the following targets:
target/linux/apm821xx/nand
target/linux/ath79/mikrotik
target/linux/ath79/nand
target/linux/kirkwood
target/linux/lantiq/xway
target/linux/mediatek/mt7622
target/linux/mvebu
target/linux/oxnas/ox820
target/linux/ramips/mt7621
They all have CONFIG_UBIFS_FS set, but not CONFIG_UBIFS_FS_ZSTD.
OpenWrt 21.02 uses UBIFS_COMPR_LZO by default OpenWrt master uses
UBIFS_COMPR_ZSTD by default.
Downgrading a OpenWrt 21.02 installation to 19.07 should work.
Did someone check how much bigger the images are getting with
CONFIG_UBIFS_FS_ZSTD?
If they are not so much bigger I would suggest to add
CONFIG_UBIFS_FS_ZSTD to OpenWrt 21.02 then the downgrade from master
should work.
Hauke
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] libopkg: pkg_hash: print unresolved dependencies
When a package is not installed because it has unresolved dependencies
normally we get only an error message like this:
* pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app found,
but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package ltq-vdsl-app.
Log in addition the following error message:
* pkg_hash_check_unresolved: cannot find dependency ltq-dsl-base for
ltq-vdsl-app
Signed-off-by: Hauke Mehrtens
---
I am not sure if this would happen in normal cases too and spam the
error log, I only saw this in an error case.
Could some expert on opkg please give me an Acked-by or some
suggestion to improve this.
I would also like to merge this into 21.02.
Changes since
v1:
* can not -> cannot
libopkg/pkg_hash.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
index a07a25e..c58703f 100644
--- a/libopkg/pkg_hash.c
+++ b/libopkg/pkg_hash.c
@@ -263,8 +263,10 @@ pkg_hash_check_unresolved(pkg_t *maybe)
if (unresolved) {
res = 1;
tmp = unresolved;
- while (*tmp)
+ while (*tmp) {
+ opkg_msg(ERROR, "cannot find dependency %s for %s\n",
*tmp, maybe->name);
free(*(tmp++));
+ }
free(unresolved);
}
pkg_vec_free(depends);
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Should ubus be marked as target-specific "nonshared"? (broken 21.02 rc2 imagebuilder)
On 6/6/21 9:56 AM, Hannu Nyman wrote: Paul Spooren kirjoitti 5.6.2021 klo 22.49: Sounds good to me. Do you mind investigate what other packages are affected I went through the ~60 instances of "nonshared" packages in the main OpenWrt repo, and found that toggling six packages to nonshared would solve the common problems: libubox, ubus, uci, lua, libjson-c, libnl-tiny This should fix such dependency problems, but we would be unable to update these components without a new OpenWrt service release even when the ABI did not change. For critical problems we normal provide a new service release so this is probably not such a big problem. Additionally also elfutils (libelf, libdw) could be toggled to nonshared, but as that is only needed for the non-default "perf" package, I do not find it that important. (I left iptables aside from the analysis as iptables modules have lots of internal dependencies.) Analysis: Nonshared packages having a dependency to an ABI revisioned normal package: libiwinfo --> +PACKAGE_kmod-cfg80211:libnl-tiny +libuci +libubus, libiwinfo-lua --> +libiwinfo +liblua, umbim --> +libubox +kmod-usb-net +kmod-usb-net-cdc-mbim +wwan, uqmi --> +libubox +libblobmsg-json +kmod-usb-net +kmod-usb-net-qmi-wwan +wwan, mtd --> +libubox, block-mount --> +ubox +libubox +libuci +libblobmsg-json +libjson-c, blockd --> +block-mount +fstools +libubus +kmod-fs-autofs4 +libblobmsg-json +libjson-c, ltq-vdsl-app --> @TARGET_lantiq_xrx200 +libpthread +librt +ltq-dsl-base +libubox +libubus, ltq-adsl-app --> @(TARGET_lantiq_xway||TARGET_lantiq_xway_legacy||TARGET_lantiq_ase) +libpthread +ltq-dsl-base +libubox +libubus, ltq-dsl-base should be nonshared, I changed this a month ago. All kernel modules are nonshared by default. perf --> +libelf +libdw +PACKAGE_libunwind:libunwind +libpthread +librt +objdump @!IN_SDK @!TARGET_arc770 @KERNEL_PERF_EVENTS KERNEL_PERF_EVENTS is not activated in the default images, so perf is not build anyway. Solving the above ABI dependencies by toggling these to nonshared: libubox (libubox, libubox-lua, libblobmsg-json), ubus (libubus), uci (libuci), lua (liblua), libjson-c, libnl-tiny, Looks like a good solution. elfutils (libelf, libdw) Nonshared packages having a harmless dependency to normal packages (excluding packages with dependencies to just kmods or target): fstools --> +ubox +USE_GLIBC:librt +NAND_SUPPORT:ubi-utils dropbear --> +DROPBEAR_ZLIB:zlib comgt --> +chat comgt-ncm --> +comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm comgt-directip --> +comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm dsl-vrx200-firmware-xdsl-a-patch --> @TARGET_lantiq_xrx200 +dsl-vrx200-firmware-xdsl-b +bspatch ltq-dsl-base --> @TARGET_lantiq +jshn base-files --> +netifd +libc +jsonfilter +SIGNED_PACKAGES:usign +SIGNED_PACKAGES:openwrt-keyring +NAND_SUPPORT:ubi-utils +fstools +fwtool Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07] mac80211: Update to backports version 4.19.193-test1
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 6 +++---
...rolling-support-for-various-chipsets.patch | 2 +-
...700-mwl8k-missing-pci-id-for-WNR854T.patch | 2 +-
...940-mwl8k_init_devices_synchronously.patch | 4 ++--
.../100-remove-cryptoapi-dependencies.patch | 20 +--
.../subsys/150-disable_addr_notifier.patch| 6 +++---
...d-stop-start-logic-for-software-TXQs.patch | 6 +++---
...l-merge-with-minstrel_ht-always-enab.patch | 4 ++--
.../320-mac80211-Add-TXQ-scheduling-API.patch | 8
...time-accounting-and-scheduling-to-TX.patch | 14 ++---
...0211-add-hdrlen-to-ieee80211_tx_data.patch | 16 +++
...1-add-TX_NEEDS_ALIGNED4_SKBS-hw-flag.patch | 10 +-
...IF_F_LLTX-when-using-intermediate-tx.patch | 2 +-
...E80211_KEY_FLAG_GENERATE_MMIE-to-iee.patch | 4 ++--
...nd-deauth-when-expiring-inactive-STA.patch | 10 +-
.../522-mac80211_configure_antenna_gain.patch | 2 +-
16 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index e7ab90d908..e7467058dd 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=4.19.189-1
+PKG_VERSION:=4.19.193-test1
PKG_RELEASE:=1
-PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v4.19.189/
-PKG_HASH:=34a53f743b43cbb25c8e665c3932d8cdd79aa3c081b9e573fae63b5a7407422c
+PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/
+PKG_HASH:=8fa651b9a6df9c30fdac75d08e0012d29ace6c221d39d52f671ff94e18847dad
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
diff --git
a/package/kernel/mac80211/patches/ath/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
b/package/kernel/mac80211/patches/ath/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
index a5ffed6979..94ee41c9e2 100644
---
a/package/kernel/mac80211/patches/ath/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
+++
b/package/kernel/mac80211/patches/ath/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
@@ -464,7 +464,7 @@ v13:
{
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
-@@ -3996,6 +3996,8 @@ static const struct wmi_ops wmi_tlv_ops
+@@ -3999,6 +3999,8 @@ static const struct wmi_ops wmi_tlv_ops
.gen_echo = ath10k_wmi_tlv_op_gen_echo,
.gen_vdev_spectral_conf = ath10k_wmi_tlv_op_gen_vdev_spectral_conf,
.gen_vdev_spectral_enable = ath10k_wmi_tlv_op_gen_vdev_spectral_enable,
diff --git
a/package/kernel/mac80211/patches/mwl/700-mwl8k-missing-pci-id-for-WNR854T.patch
b/package/kernel/mac80211/patches/mwl/700-mwl8k-missing-pci-id-for-WNR854T.patch
index 9c5870bef8..91ba189978 100644
---
a/package/kernel/mac80211/patches/mwl/700-mwl8k-missing-pci-id-for-WNR854T.patch
+++
b/package/kernel/mac80211/patches/mwl/700-mwl8k-missing-pci-id-for-WNR854T.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/marvell/mwl8k.c
+++ b/drivers/net/wireless/marvell/mwl8k.c
-@@ -5691,6 +5691,7 @@ MODULE_FIRMWARE("mwl8k/fmimage_8366.fw")
+@@ -5692,6 +5692,7 @@ MODULE_FIRMWARE("mwl8k/fmimage_8366.fw")
MODULE_FIRMWARE(MWL8K_8366_AP_FW(MWL8K_8366_AP_FW_API));
static const struct pci_device_id mwl8k_pci_id_table[] = {
diff --git
a/package/kernel/mac80211/patches/mwl/940-mwl8k_init_devices_synchronously.patch
b/package/kernel/mac80211/patches/mwl/940-mwl8k_init_devices_synchronously.patch
index ca0b37a8a7..e66d115224 100644
---
a/package/kernel/mac80211/patches/mwl/940-mwl8k_init_devices_synchronously.patch
+++
b/package/kernel/mac80211/patches/mwl/940-mwl8k_init_devices_synchronously.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/marvell/mwl8k.c
+++ b/drivers/net/wireless/marvell/mwl8k.c
-@@ -6276,6 +6276,8 @@ static int mwl8k_probe(struct pci_dev *p
+@@ -6277,6 +6277,8 @@ static int mwl8k_probe(struct pci_dev *p
priv->running_bsses = 0;
@@ -9,7 +9,7 @@
return rc;
err_stop_firmware:
-@@ -6309,8 +6311,6 @@ static void mwl8k_remove(struct pci_dev
+@@ -6310,8 +6312,6 @@ static void mwl8k_remove(struct pci_dev
return;
priv = hw->priv;
diff --git
a/package/kernel/mac80211/patches/subsys/100-remove-cryptoapi-dependencies.patch
b/package/kernel/mac80211/patches/subsys/100-remove-cryptoapi-dependencies.patch
index 0cedfb3ac6..540ad5025e 100644
---
a/package/kernel/mac80211/patches/subsys/100-remove-cryptoapi-dependencies.patch
+++
b/package/kernel/mac80211/patches/subsys/100-remove-cryptoapi-dependencies.patch
@@ -385,7 +385,7 @@
#endif /* AES_GCM_H */
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
-@@ -314,7 +314,8 @@ ieee80211_crypto_tkip_decrypt(struct iee
+@@ -315,7 +315,8 @@ ieee80211_cryp
Re: [PATCH] realtek: Fix buffer length calculation on RTL8380 with CRC offload
On 5/9/21 7:32 PM, Birger Koblitz wrote: realtek: Fix buffer length calculation on RTL8380 with CRC offload Fixes the buffer and packet length calculations for Ethernet TX on the RTL8380 SoC when CRC calculation offload is enabled. CRC-offload is always done by the SoC, but additional CRC calculation was previously done also by the kernel. It also fixes detection of the DSA tag for packets on RTL8390 SoCs for ports > 28. Signed-off-by: Birger Koblitz Hi, This patch does not apply to master for me. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.0 second release candidate
Hi, The OpenWrt community is proud to announce the second release candidate of the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year. Changes between OpenWrt 21.02.0-rc1 and 21.02.0-rc2 New network configuration syntax There have been several changes to the network configuration syntax in /etc/config/network: * in config interface, option ifname has been renamed to device (since it refers to a device section) * in config device of type bridge, ifname has been renamed to ports * for new installs, the generated configuration now creates separate sections for layer 2 (config device) and layer 3 (config interface) configuration The old syntax is still supported to facilitate transition, and there is no automated migration when upgrading. However, the LuCI web interface detects old-style configuration and will propose to migrate it to the new syntax. This is necessary to be able to edit network configuration through LuCI. The new configuration style looks like this: -- config device option name 'br-lan' option type 'bridge' option macaddr '00:01:02:XX:XX:XX' list ports 'lan1' list ports 'lan2' list ports 'lan3' list ports 'lan4' config interface 'lan' option device 'br-lan' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' config device option name 'eth1' option macaddr '00:01:02:YY:YY:YY' config interface 'wan' option device 'eth1' option proto 'dhcp' config interface 'wan6' option device 'eth1' option proto 'dhcpv6' -- This example uses DSA with lanX interface names. A non-DSA device would use more classical ethX interface names. LuCI update LuCI has been updated to support the most recent network syntax (and migrate old config files if needed). In some cases migration will take 2 steps. Support for configuring devices (config device UCI sections) was added. It can be used for setting layer 2 options (like MTU and MAC address). It also supports bridge devices (including VLAN tagging). LuCI HTTPS LuCI is now available over HTTPS in addition to HTTP in the default images. After an upgrade from OpenWrt 19.07 to OpenWrt 21.02 unencrypted HTTP requests are redirected to HTTPS. On fresh OpenWrt 21.02 installations they are not redirected. Deactivate the redirect to HTTPS like this: -- uci set uhttpd.main.redirect_https=0 uci commit uhttpd service uhttpd reload -- Software updates * Linux kernel updated to version 5.4.119 (from 5.4.111 in v21.02.0-rc1) * mac80211 updated to version 5.10.34-1 (from 5.10.16-1 in v21.02.0-rc1) * mac80211 backport upstream fixes for the new FragAttacks vulnerabilities in 802.11 * mt76 updated to latest version * dnsmasq updated to version 2.85 (from 2.84 in v21.02.0-rc1) * busybox updated to version 1.33.1 (from 1.33.0 in v21.02.0-rc1) Misc changes * Linux kernel fix parsing fixed subpartitions * Linux kernel Activate FORTIFY_SOURCE for MIPS kernel 5.4 * busybox add SRV support to nslookup_lede.c patch * busybox disable PREFER_IPV4_ADDRESS * openwrt-keyring only copy sign key for 21.02 * sdk, imagebuilder unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives * uqmi fix network registration loop Device support * Lantiq DSL multiple backports for DSL statistics * New devices MikroTik SXTsq 5 ac, MikroTik hAP ac2 * Device fixes for ALFA Network devices, Youku YK1, TP-Link AD7200, TP-Link EAP-225, TP-Link TL-WR810N v1, MikroTik RB922UAGS-5HPaCD Known issues * LuCI network migration tool doesn't migrate custom bridge MAC addresses. Custom device MAC has to be set again manually. Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.0-rc2 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.0-rc2#known_issues For a detailed list of all changes since 21.02.0-rc1, refer to https://openwrt.org/releases/21.02/changelog-21.02.0-rc2 To download the 21.02.0-rc2 images, navigate to: https://downloads.openwrt.org/releases/21.02.0-rc2/ - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement c
Re: Luci->Network->Interfaces is broken
On 5/29/21 10:25 PM, e9hack wrote: Hi, it looks like that Luci->Network->Interfaces is broken. It shows a NotFountError (Resource not found) message. My build from 22.05. forces me to convert something related to network configuration. Afterwards, this dialogue shows the interface configuration. Starting with build from 27.05. it shows the NotFountError (Resource not found) message. Builds from 22.05., 24.05. and 26.05. do show the interfaces configuration in Luci. Regards, Hartmut Hi Hartmut, What device are you using? There were bigger changes to the switch configuration recently. Are you using a recent version of OpenWrt master and LuCi? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH luci] luci-mod-network: split config migration into 2 steps
On 5/29/21 5:25 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Problem with handling all migrations in 1 step is that uci.sections()
doesn't include changes queued using uci.callAdd() and uci.callSet().
That could result in unexpected behaviour and generating invalid
configs.
For the sake of simplicity and reliability use 2 steps migration. The
downside is that users may get prompted twice to migrate.
Reported-by: Hauke Mehrtens
Fixes: 74be304e541f ("treewide: use "device" option in UCI "interface"
sections")
Signed-off-by: Rafał Miłecki
Tested-by: Hauke Mehrtens
I tested it in OpenWrt 21.02 doing the migration in one step by clicking
continue 2 times and also interrupting it in between, both worked.
---
.../resources/view/network/interfaces.js | 48 +--
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
index 6f8fd614b1..343bc31cfd 100644
---
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
+++
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
@@ -317,11 +317,10 @@ return view.extend({
});
},
- handleMigration: function(ev) {
- var interfaces = this.interfaceBridgeWithIfnameSections();
+ handleBridgeMigration: function(ev) {
var tasks = [];
- interfaces.forEach(function(ns) {
+ this.interfaceBridgeWithIfnameSections().forEach(function(ns) {
var device_name = 'br-' + ns['.name'];
tasks.push(uci.callAdd('network', 'device', null, {
This is currently an unnamed section should this be named after br-*?
@@ -332,12 +331,32 @@ return view.extend({
tasks.push(uci.callSet('network', ns['.name'], {
'type': '',
- 'device': device_name
+ 'ifname': device_name
Should we directly assign this to "device" and set "ifname" to an empty
string?
}));
});
+ return Promise.all(tasks)
+ .then(L.bind(ui.changes.init, ui.changes))
+ .then(L.bind(ui.changes.apply, ui.changes));
+ },
+
+ renderBridgeMigration: function() {
+ ui.showModal(_('Network bridge configuration migration'), [
+ E('p', _('The existing network configuration needs to
be changed for LuCI to function properly.')),
+ E('p', _('Upon pressing "Continue", bridges
configuration will be updated and the network will be restarted to apply the updated
configuration.')),
+ E('div', { 'class': 'right' },
+ E('button', {
+ 'class': 'btn cbi-button-action
important',
+ 'click': ui.createHandlerFn(this,
'handleBridgeMigration')
+ }, _('Continue')))
+ ]);
+ },
+
+ handleIfnameMigration: function(ev) {
+ var tasks = [];
+
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] luci-mod-network: Fix migration overwriting device attribute
Without this patch we first migrate the configuration to the br-lan
device entry and change the device option of the network interface to
point to the newly created device. In the next step all device options
will be overwritten with the ifname entry, this partly reverted the
change from the previous migration.
The configuration we work on is not changed between these steps, so the
functions all work on the same initial configuration.
This patch changes the order to first migrate all ifname options to
device or ports and do the migration of the bridges as the last step.
This way the bridge migration is not overwritten any more.
Without this patch this configuration:
-
config interface 'lan'
option type 'bridge'
option ifname 'lan0 lan1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
-
Is migrated to this broken configuration:
-
config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option device 'lan0 lan1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan0'
list ports 'lan1'
-
Fixes: 74be304e541f ("treewide: use "device" option in UCI "interface"
sections")
Signed-off-by: Hauke Mehrtens
---
.../resources/view/network/interfaces.js | 28 +--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
index 6f8fd614b1..38f4b7e60c 100644
---
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
+++
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
@@ -321,18 +321,10 @@ return view.extend({
var interfaces = this.interfaceBridgeWithIfnameSections();
var tasks = [];
- interfaces.forEach(function(ns) {
- var device_name = 'br-' + ns['.name'];
-
- tasks.push(uci.callAdd('network', 'device', null, {
- 'name': device_name,
- 'type': 'bridge',
- 'ports': L.toArray(ns.ifname)
- }));
-
+ this.interfaceWithIfnameSections().forEach(function(ns) {
tasks.push(uci.callSet('network', ns['.name'], {
- 'type': '',
- 'device': device_name
+ 'ifname': '',
+ 'device': ns.ifname
}));
});
@@ -343,10 +335,18 @@ return view.extend({
}));
});
- this.interfaceWithIfnameSections().forEach(function(ns) {
+ interfaces.forEach(function(ns) {
+ var device_name = 'br-' + ns['.name'];
+
+ tasks.push(uci.callAdd('network', 'device', null, {
+ 'name': device_name,
+ 'type': 'bridge',
+ 'ports': L.toArray(ns.ifname)
+ }));
+
tasks.push(uci.callSet('network', ns['.name'], {
- 'ifname': '',
- 'device': ns.ifname
+ 'type': '',
+ 'device': device_name
}));
});
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Bridge migration breaks network configuration
Hi, The network configuration migration in the 21.02 branch results in a broken network configuration. When I start with the following old network configuration: - config interface 'lan' option type 'bridge' option ifname 'lan0 lan1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' - It gets migrated to this configuration: - config interface 'lan' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' option device 'lan0 lan1' config device option name 'br-lan' option type 'bridge' list ports 'lan0' list ports 'lan1' - Here the bridge is not created by netifd and the lan network is not working any more. Instead of this line: option device 'lan0 lan1' the following line should be added: option device 'br-lan' I didn't tag 21.02.0-rc2 because of this problem. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain: gdb: Add optional python support
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Compile gdb with python support optionally. To use the Python support in gdb some extra python files are needed, install them too. While at it also install other shared files which we did not install before. If gdb is built without Python support the python folder does not exists. Signed-off-by: Hauke Mehrtens --- toolchain/Config.in| 8 toolchain/gdb/Makefile | 11 ++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/toolchain/Config.in b/toolchain/Config.in index 6dda9af92d..8ff5438d79 100644 --- a/toolchain/Config.in +++ b/toolchain/Config.in @@ -259,6 +259,14 @@ config GDB help Enable if you want to build the gdb. +config GDB_PYTHON + bool + depends on GDB + prompt "Build gdb with python binding" + + help + Enable the python bindings for GDB to allow using python in the gdb shell. + config USE_GLIBC default y if !TOOLCHAINOPTS && !EXTERNAL_TOOLCHAIN && !NATIVE_TOOLCHAIN && (arc) bool diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile index 05e3c7de3c..2708eff869 100644 --- a/toolchain/gdb/Makefile +++ b/toolchain/gdb/Makefile @@ -36,7 +36,6 @@ HOST_CONFIGURE_ARGS = \ --without-included-gettext \ --enable-threads \ --with-expat \ - --without-python \ --disable-unit-tests \ --disable-ubsan \ --disable-binutils \ @@ -44,11 +43,21 @@ HOST_CONFIGURE_ARGS = \ --disable-gas \ --disable-sim +ifneq ($(CONFIG_GDB_PYTHON),) + HOST_CONFIGURE_ARGS+= --with-python +else + HOST_CONFIGURE_ARGS:= --without-python +endif + define Host/Install mkdir -p $(TOOLCHAIN_DIR)/bin $(INSTALL_BIN) $(HOST_BUILD_DIR)/gdb/gdb $(TOOLCHAIN_DIR)/bin/$(TARGET_CROSS)gdb ln -fs $(TARGET_CROSS)gdb $(TOOLCHAIN_DIR)/bin/$(GNU_TARGET_NAME)-gdb strip $(TOOLCHAIN_DIR)/bin/$(TARGET_CROSS)gdb + mkdir -p $(TOOLCHAIN_DIR)/share/gdb + -cp -R $(HOST_BUILD_DIR)/gdb/data-directory/python $(TOOLCHAIN_DIR)/share/gdb/ + cp -R $(HOST_BUILD_DIR)/gdb/data-directory/syscalls $(TOOLCHAIN_DIR)/share/gdb/ + cp -R $(HOST_BUILD_DIR)/gdb/data-directory/system-gdbinit $(TOOLCHAIN_DIR)/share/gdb/ endef define Host/Clean -- 2.17.1 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and reenable again
On 5/22/21 5:00 PM, André Valentin wrote:
The bootloader happily accepts this.
But devices need a fresh reinstall because of resulting ubi partition
changes. Therefore a sysupgrade will brick your device.
Please install a fresh factory image via bootloader.
Alternatively, you can flash sysupgrade-6M-Kernel.bin with
zcat sysupgrade-6M-Kernel.bin | mtd -r -e /dev/mtd 3 write - /dev/mtd3
This may thow an error, because it is a 256M image. There are
devices out there with this flash size.
Notice that you will always loose configuration.
Signed-off-by: André Valentin
---
.../linux/ath79/dts/qca9558_zyxel_nbg6716.dts | 4 ++--
target/linux/ath79/image/nand.mk | 24 +--
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
index 9aee8c362c..411b086188 100644
--- a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
+++ b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
@@ -147,12 +147,12 @@
partition@50 {
label = "kernel";
- reg = <0x50 0x40>;
+ reg = <0x50 0x60>;
};
partition@90 {
label = "ubi";
- reg = <0x90 0x770>;
+ reg = <0xb0 0x750>;
};
};
};
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index caaa01c92d..37a5713ff1 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -236,6 +236,15 @@ TARGET_DEVICES += netgear_wndr4500-v3
define Device/zyxel_nbg6716
SOC := qca9558
+ DEVICE_COMPAT_VERSION := 2.0
+ DEVICE_COMPAT_MESSAGE := Kernel partition has been resized to 6M. \
+ A sysupgrade will brick your device. \
+ Please install a fresh factory image via bootloader. \
+ Alternatively, you can flash sysupgrade-6M-Kernel.bin with \
+ zcat sysupgrade-6M-Kernel.bin | mtd -r -e /dev/mtd3 write - /dev/mtd3
.\
+ This may thow an error, because it is a 256M image. There are \
+ devices out there with this flash size. \
+ Notice that you will always loose configuration.
DEVICE_VENDOR := ZyXEL
DEVICE_MODEL := NBG6716
DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \
@@ -243,19 +252,20 @@ define Device/zyxel_nbg6716
RAS_BOARD := NBG6716
RAS_ROOTFS_SIZE := 29696k
RAS_VERSION := "OpenWrt Linux-$(LINUX_VERSION)"
- KERNEL_SIZE := 4096k
+ KERNEL_SIZE := 6144k
BLOCKSIZE := 128k
PAGESIZE := 2048
KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs | \
- check-size 4096k
This check was triggered by the build bots.
I am not sure, but I think this also adds the rootfs to the kernel image
and then it gets too big.
Hauke
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] firmware: Add cavium CPT hardware crypto firmware
On 4/18/21 9:46 AM, Daniel Danzberger wrote: The firmware consists of 2 images: - cpt8x-mc-ae.out - cpt8x-mc-se.out Both are required and requests by the kernel module 'cptpf' (drivers/crypto/cavium/cpt) to provide hardware crpyto support on cavium platforms like the octeontx Signed-off-by: Daniel Danzberger --- package/firmware/cavium-cpt/Makefile | 52 1 file changed, 52 insertions(+) create mode 100644 package/firmware/cavium-cpt/Makefile Hi, Under which license are these two files distributed? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] menuconfig: Add CONFIG_BUILD_DOCUMENTATION
On 5/15/21 1:10 AM, David Adair wrote: This provides a way to override the ccache ENABLE_DOCUMENTATION=OFF setting and restore previous behavior. It is optional since the default required to disable the doc build (and avoid the non-ascii character build failures) is !="y". It could potentially be useful: - If we want the default to be "y" - To supress docs on other packages. Would be most useful for the autoconf based tools but I could not figure out an easy way to accomplish that. Signed-off-by: David Adair Normally we deactivated building docs in most packages, where it is not done, we probably just missed it. Do you use the docs generated by OpenWrt packages? If not, I would only take the first patch to deactivate building docs for ccache. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu: 5.10: fix DVFS caused random boot crashes
On 5/18/21 7:03 PM, Robert Marko wrote:
5.10.37 introduced a lot of DVFS changes for Armada 37xx from 5.13 kernel.
Unfortunately commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/cpufreq/armada-37xx-cpufreq.c?h=v5.10.37&id=a13b110e7c9e0dc2edcc7a19d4255fc88abd83cc
This patch actually corrects the things so that 1 or 1.2GHz models would
actually get scaled to their native frequency.
However, due to a AVS setting voltages too low this will cause random crashes
on 1.2GHz models.
So, until a new safe for everybody voltage is agreed on
lets revert the patch.
Fixes: d337731 ("kernel: bump 5.10 to 5.10.37")
Signed-off-by: Robert Marko
This commit was also backported to v5.4.119 and is now in OpenWrt 21.02
branch, we should probably also revbert it there.
@Robert Are you working with upstream Linux to fix this problem upstream
too? For now this revert should be fine.
hauke
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] openwrt-keyring: Only copy sign key for 21.02
On 5/17/21 8:10 PM, Paul Spooren wrote: On 5/16/21 3:57 PM, Hauke Mehrtens wrote: On 5/16/21 3:26 PM, Hauke Mehrtens wrote: Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the OpenWrt 21.02 feeds. If one of the other keys would be compromised this would not affect users of 21.02 release builds. Signed-off-by: Hauke Mehrtens --- In my opinion this patch still lacks a *openwrt-next* key to allow a secure upgrade path between major releases. We can also add this later in some service release. Currently I wanted to remove all the personal keys from the trusted keys. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] maketag.sh/makebranch.sh: handle https download URLs
On 4/19/21 11:16 PM, Paul Spooren wrote: On 4/19/21 9:45 AM, Hauke Mehrtens wrote: Since OpenWrt 21.02 we use https for our download server, detect these URLs too. Signed-off-by: Hauke Mehrtens --- Can't you kick out anything lede-project related while at it? I will have a look at the script later again to remove stuff which is only needed for OpenWrt / LEDE 18.06 or older. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07] tools/mklibs: Fix compile with GCC 11
GCC 11 defaults to C++17, but mklibs does not compile when using the
C++17 standard. This patch switches back to the gnu++98 version like
done in master commit 9437012b9ee4 ("tools/mklibs: update to 0.1.44 and
convert to Python 3")
This fixes the following compile error message:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception specifications
52 | const section &get_section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
Signed-off-by: Hauke Mehrtens
---
tools/mklibs/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/mklibs/Makefile b/tools/mklibs/Makefile
index 507c2fd394..8826840524 100644
--- a/tools/mklibs/Makefile
+++ b/tools/mklibs/Makefile
@@ -18,6 +18,7 @@ HOST_FIXUP:=autoreconf
include $(INCLUDE_DIR)/host-build.mk
HOST_CFLAGS += -I$(CURDIR)/include
+HOST_CPPFLAGS += -std=gnu++98
define Host/Install
$(INSTALL_BIN) \
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: opkg fails to install manually downloaded packages
On 5/16/21 11:04 PM, Sven Roederer wrote: Hannu, thanks for your support to narrow this down. Am Sonntag, 2. Mai 2021, 18:43:20 CEST schrieb Hannu Nyman: Sounds like a bug, but it should be named something like "Misleading opkg catch-all error message 'incompatible architecture' " Made https://bugs.openwrt.org/index.php?do=details&task_id=3814 for it. Those opkg commits in October-November 2020 by Paul, Daniel & Baptiste made lots of changes to the opkg dependency logic, and apparently the "incompatible architecture" is now some kind of catch-all, which catches/displays all kinds of errors too easily. At least: Earlier there actually was an "incompatible architecture" message that got displayed if you tried mvebu package to x86 etc.. Apparently now that message surfaces too easily. Yeah, seems a bit unspecific. Reverting opkg to cf44c2feb606b60, at least gives the expected behaviour. Sven Hi, I debugged a similar problem a week ago and added this patch to opkg: https://patchwork.ozlabs.org/project/openwrt/patch/20210502205912.23753-1-ha...@hauke-m.de/ This shows the missing dependencies, but I am not sure if the pkg_hash_check_unresolved() function could also fail in good cases. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH] ath10k-ct: backport upstream fixes for FragAttacks
This applies the FragAttack patches also to ath10k-ct.
Signed-off-by: Hauke Mehrtens
---
I do not have a ath10k device close here at the moment, it would be nice
if someone could check if this works fine.
package/kernel/ath10k-ct/Makefile | 2 +-
...PN-replay-protection-for-fragmented-.patch | 180 ++
...fragments-with-multicast-DA-for-PCIe.patch | 66 +++
...fragments-with-multicast-DA-for-SDIO.patch | 40
...-which-has-discard-flag-set-by-firmw.patch | 54 ++
...IP-Michael-MIC-verification-for-PCIe.patch | 48 +
...first-subframe-of-A-MSDU-before-proc.patch | 109 +++
7 files changed, 498 insertions(+), 1 deletion(-)
create mode 100644
package/kernel/ath10k-ct/patches/300-ath10k-add-CCMP-PN-replay-protection-for-fragmented-.patch
create mode 100644
package/kernel/ath10k-ct/patches/301-ath10k-drop-fragments-with-multicast-DA-for-PCIe.patch
create mode 100644
package/kernel/ath10k-ct/patches/302-ath10k-drop-fragments-with-multicast-DA-for-SDIO.patch
create mode 100644
package/kernel/ath10k-ct/patches/303-ath10k-drop-MPDU-which-has-discard-flag-set-by-firmw.patch
create mode 100644
package/kernel/ath10k-ct/patches/304-ath10k-Fix-TKIP-Michael-MIC-verification-for-PCIe.patch
create mode 100644
package/kernel/ath10k-ct/patches/305-ath10k-Validate-first-subframe-of-A-MSDU-before-proc.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index a225bd8b191f..d6ad53fb5871 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=ath10k-ct
-PKG_RELEASE=2
+PKG_RELEASE=3
PKG_LICENSE:=GPLv2
PKG_LICENSE_FILES:=
diff --git
a/package/kernel/ath10k-ct/patches/300-ath10k-add-CCMP-PN-replay-protection-for-fragmented-.patch
b/package/kernel/ath10k-ct/patches/300-ath10k-add-CCMP-PN-replay-protection-for-fragmented-.patch
new file mode 100644
index ..89d4237d3409
--- /dev/null
+++
b/package/kernel/ath10k-ct/patches/300-ath10k-add-CCMP-PN-replay-protection-for-fragmented-.patch
@@ -0,0 +1,180 @@
+From: Wen Gong
+Date: Tue, 11 May 2021 20:02:52 +0200
+Subject: [PATCH] ath10k: add CCMP PN replay protection for fragmented
+ frames for PCIe
+
+PN replay check for not fragmented frames is finished in the firmware,
+but this was not done for fragmented frames when ath10k is used with
+QCA6174/QCA6377 PCIe. mac80211 has the function
+ieee80211_rx_h_defragment() for PN replay check for fragmented frames,
+but this does not get checked with QCA6174 due to the
+ieee80211_has_protected() condition not matching the cleared Protected
+bit case.
+
+Validate the PN of received fragmented frames within ath10k when CCMP is
+used and drop the fragment if the PN is not correct (incremented by
+exactly one from the previous fragment). This applies only for
+QCA6174/QCA6377 PCIe.
+
+Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
+
+Cc: sta...@vger.kernel.org
+Signed-off-by: Wen Gong
+Signed-off-by: Jouni Malinen
+Signed-off-by: Johannes Berg
+---
+
+--- a/ath10k-5.10/htt.h
b/ath10k-5.10/htt.h
+@@ -853,6 +853,7 @@ enum htt_security_types {
+
+ #define ATH10K_HTT_TXRX_PEER_SECURITY_MAX 2
+ #define ATH10K_TXRX_NUM_EXT_TIDS 19
++#define ATH10K_TXRX_NON_QOS_TID 16
+
+ enum htt_security_flags {
+ #define HTT_SECURITY_TYPE_MASK 0x3F
+--- a/ath10k-5.10/htt_rx.c
b/ath10k-5.10/htt_rx.c
+@@ -1841,16 +1841,87 @@ static void ath10k_htt_rx_h_csum_offload
+ msdu->ip_summed = ath10k_htt_rx_get_csum_state(msdu);
+ }
+
++static u64 ath10k_htt_rx_h_get_pn(struct ath10k *ar, struct sk_buff *skb,
++u16 offset,
++enum htt_rx_mpdu_encrypt_type enctype)
++{
++ struct ieee80211_hdr *hdr;
++ u64 pn = 0;
++ u8 *ehdr;
++
++ hdr = (struct ieee80211_hdr *)(skb->data + offset);
++ ehdr = skb->data + offset + ieee80211_hdrlen(hdr->frame_control);
++
++ if (enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) {
++ pn = ehdr[0];
++ pn |= (u64)ehdr[1] << 8;
++ pn |= (u64)ehdr[4] << 16;
++ pn |= (u64)ehdr[5] << 24;
++ pn |= (u64)ehdr[6] << 32;
++ pn |= (u64)ehdr[7] << 40;
++ }
++ return pn;
++}
++
++static bool ath10k_htt_rx_h_frag_pn_check(struct ath10k *ar,
++struct sk_buff *skb,
++u16 peer_id,
++u16 offset,
++enum htt_rx_mpdu_encrypt_type enctype)
++{
++ struct ath10k_peer *peer;
++ union htt_rx_pn_t *last_pn, new_pn = {0};
++ struct ieee80211_hdr *hdr;
++ bool more_frags;
++ u8 tid, frag_number;
++ u32 seq;
++
++ peer = ath10k_peer_find_by_id(ar, peer_id);
++ if (!peer) {
++ ath10k_dbg(ar, ATH10K_D
Re: [PATCH] openwrt-keyring: Only copy sign key for 21.02
On 5/16/21 3:26 PM, Hauke Mehrtens wrote: Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the OpenWrt 21.02 feeds. If one of the other keys would be compromised this would not affect users of 21.02 release builds. Signed-off-by: Hauke Mehrtens --- package/system/openwrt-keyring/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/system/openwrt-keyring/Makefile b/package/system/openwrt-keyring/Makefile index 6f3aa65622..e3078074b9 100644 --- a/package/system/openwrt-keyring/Makefile +++ b/package/system/openwrt-keyring/Makefile @@ -32,7 +32,8 @@ Build/Compile= define Package/openwrt-keyring/install $(INSTALL_DIR) $(1)/etc/opkg/keys/ - $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/* $(1)/etc/opkg/keys/ + # Public usign key for 21.02 release builds + $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/2f8b0b98e08306bf $(1)/etc/opkg/keys/ endef $(eval $(call BuildPackage,openwrt-keyring)) This patch is for the 21.02 release branch and the PKG_RELEASE should also get increased. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 1/2] openwrt-keyring: add OpenWrt 21.02 GPG/usign keys
From: Petr Štetiar 49283916005d usign: add 21.02 release build pubkey bc4d80f064f2 gpg: add OpenWrt 21.02 signing key Signed-off-by: Petr Štetiar (cherry picked from commit 1bf6d70e60fdb45d81a8f10b90904cef38c73f70) --- package/system/openwrt-keyring/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/system/openwrt-keyring/Makefile b/package/system/openwrt-keyring/Makefile index 7779e0c5a4..6f3aa65622 100644 --- a/package/system/openwrt-keyring/Makefile +++ b/package/system/openwrt-keyring/Makefile @@ -7,9 +7,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/keyring.git -PKG_SOURCE_DATE:=2019-07-25 -PKG_SOURCE_VERSION:=8080ef341b4180e40c4ae8ab63511ac6496f0ad1 -PKG_MIRROR_HASH:=000882364b953691bf02f7ac41462badb68f452f0317cdfd51cfd617c9b1e364 +PKG_SOURCE_DATE:=2021-02-20 +PKG_SOURCE_VERSION:=49283916005d7868923d34ab34f14188cf74812d +PKG_MIRROR_HASH:=7b58592bb49e4b37c8e80904c8f457ce3f0f2e6b1d2c473ccfe9204a8b7be831 PKG_MAINTAINER:=John Crispin PKG_LICENSE:=GPL-2.0 -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 2/2] openwrt-keyring: Only copy sign key for 19.07 and 21.02
Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the OpenWrt 19.07 feeds and the 21.02 feeds to allow checking the next release. If one of the other keys would be compromised this would not affect users of 19.07 release builds. Signed-off-by: Hauke Mehrtens --- package/system/openwrt-keyring/Makefile | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/package/system/openwrt-keyring/Makefile b/package/system/openwrt-keyring/Makefile index 6f3aa65622..037809a667 100644 --- a/package/system/openwrt-keyring/Makefile +++ b/package/system/openwrt-keyring/Makefile @@ -3,7 +3,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=openwrt-keyring -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/keyring.git @@ -32,7 +32,10 @@ Build/Compile= define Package/openwrt-keyring/install $(INSTALL_DIR) $(1)/etc/opkg/keys/ - $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/* $(1)/etc/opkg/keys/ + # Public usign key for 19.07 release builds + $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/f94b9dd6febac963 $(1)/etc/opkg/keys/ + # Public usign key for 21.02 release builds + $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/2f8b0b98e08306bf $(1)/etc/opkg/keys/ endef $(eval $(call BuildPackage,openwrt-keyring)) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] openwrt-keyring: Only copy sign key for 21.02
Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the OpenWrt 21.02 feeds. If one of the other keys would be compromised this would not affect users of 21.02 release builds. Signed-off-by: Hauke Mehrtens --- package/system/openwrt-keyring/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/system/openwrt-keyring/Makefile b/package/system/openwrt-keyring/Makefile index 6f3aa65622..e3078074b9 100644 --- a/package/system/openwrt-keyring/Makefile +++ b/package/system/openwrt-keyring/Makefile @@ -32,7 +32,8 @@ Build/Compile= define Package/openwrt-keyring/install $(INSTALL_DIR) $(1)/etc/opkg/keys/ - $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/* $(1)/etc/opkg/keys/ + # Public usign key for 21.02 release builds + $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/2f8b0b98e08306bf $(1)/etc/opkg/keys/ endef $(eval $(call BuildPackage,openwrt-keyring)) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] openwrt-keyring: Only copy sign key for snapshots
On 5/15/21 4:44 PM, Daniel Golle wrote: On Sat, May 15, 2021 at 04:28:58PM +0200, Hauke Mehrtens wrote: On 5/15/21 1:34 AM, Daniel Golle wrote: On Fri, May 14, 2021 at 11:31:27PM +0200, Hauke Mehrtens wrote: On 5/14/21 12:17 PM, Paul Spooren wrote: Hi, On 5/13/21 1:32 AM, Hauke Mehrtens wrote: Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the master feeds. If one of the other keys would be compromised this would not affect users of master snapshot builds. Signed-off-by: Hauke Mehrtens --- Thanks for working on this. I'm still in favor to include a *openwrt-next* key which becomes the signing key for the next release. This way a upgrade step between release branches is possible. I would prefer to create it closer to the next release. As far as I know the other keys are not compromised, this is just a precaution. I would do similar changes to 21.02 and 19.07 to only add the key which is used for this specific release. In case of 19.07 please add 21.02 release keys as well, since it's *the next key*. Yes, good idea. Instead of adding just this single key, should we add all keys of currently maintained releases like 19.07, 21.02 and master key into all 3 branches? How about adding keys like that: 19.07: 19.07 + 21.02 keys 21.02: 21.02 + openwrt-next keys snapshot: snapshot key The snapshot key stays the same "forever", it shouldn't be included in releases. The signature verification of sysupgrade images is currently not used as far as I know, so normal we do not need the keys for of other releases. If the `ucert` package is installed and the env variable `REQUIRE_IMAGE_SIGNATURE` is set, the images are verified. This should eventually become the default. How reliable is this working? I've been using ucert on many devices for a long time for now. In order to be more secure, the signed data should be normalized (ie. sorted and non-relevant data removed), which has not been done yet. Right now, hash collissions could be constructed by changing the order of fields and/or adding useless additional data -- however, that would still mean having to break SHA256. Generally, to be considered more than just a small extra barrier or even a security risk, much more review would be needed. See: https://git.openwrt.org/?p=project/ucert.git;a=blob;f=README.md;hb=refs/heads/master#l6 Currently we do not ship ucert by default and this is needed to check the image signature. People can, however, install ucert which enabled signature checks of future sysupgrade. When using 'auc' or 'luci-app-attendedsysupgrade' for upgrade, all explicitely installed packages are also kept accross updates, and that can include 'ucert' (which is what I've been doing for a while now on my local devices) Ok this is nice. I tried to check the signature of the 21.02-rc1 release and it failed: --- root@OpenWrt:/tmp# REQUIRE_IMAGE_SIGNATURE=1 sysupgrade -T openwrt-21.02.0-rc1-ath79-generic-tplink_tl-wdr4300-v1-squashfs-sysupgrade.bin cert_verify: cannot parse cert Image check failed. --- With a self build image it works. It contains "# fake certificate" where I would expect the certificate. Is this expected? Yes and no :) No, because in this way ucert is pretty useless. Yes, because this is how buildbots are configured to do things at this point: https://git.openwrt.org/?p=buildbot.git;a=blob;f=phase1/master.cfg;h=a85382ae4fd2ee52d0d102fc90be7f721a2dfe86;hb=HEAD#l986 The goal of ucert is to allow key delegation, as described in the README.md in ucert.git. Like this we could have builders generate keys with short lifetime, have them signed by a more protected instance and have the option to revoke them, if needed. Ok thank you Daniel for the clarification. So people are fine with the original patch to only include the master key into the image. I will send seperate patches for 21.02 and 19.07. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Activate https server support in 21.02 by default
On 5/14/21 4:22 PM, Etienne Champetier wrote: Hi All, Le ven. 14 mai 2021 à 05:00, Petr Štetiar a écrit : Fernando Frediani [2021-05-11 20:13:18]: Hi, I am no sure https support should still be something by default in the images as it's not something really essential to me it's like discussion about telnet versus SSH. (Puting aside, that one shouldn't be using password at all) If it's fine with you to send your root password over telnet, then SSH is not essential, I agree. FYI HTTPS wouldn't be enabled by default, it would be *available* by default, giving users of default release images choice for management of their devices over HTTPS, by doing so *explicitly*. I'm all for HTTPS to be shipped by default One painfull "bug" that some people might face having both HTTP and HTTPS, when you login using HTTPS, the sysauth cookie has secure=true, so you can't login via HTTP anymore because it's trying to modify the secure=true sysauth cookie :( Etienne I ran into this when I first used an image with luci-ssl and then changed to one without it. What about setting a not secure cookie that tells the browser that https was used when we access LuCI over https. When the browser accesses LuCI now over unencrypted http the code will check for this cookie and forward the browser to the https version. If this cookie is not found it behaves like before. If https worked once it will probably also work a second time. Is it even possible to handle the error when we want to overwrite the secure=true cookie and do a forward to https instead? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Activate https server support in 21.02 by default
On 5/16/21 2:30 AM, Fernando Frediani wrote: On 15/05/2021 18:57, Alberto Bursi wrote: If HTTPS is still an optional it makes no sense to treat it differently from all other optional packages. The only moment it should be included by default is when it becomes mandatory, and the HTTP interface is disabled. Maybe you are right here. Fernando -Alberto Hi, Adding CONFIG_PACKAGE_luci-ssl to the image will add less then 10 KBytes to the image, my initramfs image for an ath79 got 2.2 KBytes bigger. This is about 0.05% of the image. We already include a full TLS library and use it for WPA3 and HTTPS downloads. Probably some extra size if used by the X.509 certificate we generate at first boot and store on flash. With the current approach we would offer the web page under http://192.168.1.1 and https://192.168.1.1 by default, the user can choose what he would like o use. The http version will not forward to the https version. https is not deactivated by default, but the user can choose which url he uses in his browser. The certificates are not signed by a certificate authority, so the browser will not trust them by default, but this already protects the users from a attacker passively listening on the connection between the browser and the OpenWrt device. The comparison with telnet and ssh is pretty good. For SSH we "waste" a lot more memory. I am for activating it, if you do not want to use it, you can build a custom image with the image builder without luci-ssl and px5g-wolfssl. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] openwrt-keyring: Only copy sign key for snapshots
On 5/15/21 1:34 AM, Daniel Golle wrote: On Fri, May 14, 2021 at 11:31:27PM +0200, Hauke Mehrtens wrote: On 5/14/21 12:17 PM, Paul Spooren wrote: Hi, On 5/13/21 1:32 AM, Hauke Mehrtens wrote: Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the master feeds. If one of the other keys would be compromised this would not affect users of master snapshot builds. Signed-off-by: Hauke Mehrtens --- Thanks for working on this. I'm still in favor to include a *openwrt-next* key which becomes the signing key for the next release. This way a upgrade step between release branches is possible. I would prefer to create it closer to the next release. As far as I know the other keys are not compromised, this is just a precaution. I would do similar changes to 21.02 and 19.07 to only add the key which is used for this specific release. In case of 19.07 please add 21.02 release keys as well, since it's *the next key*. Yes, good idea. Instead of adding just this single key, should we add all keys of currently maintained releases like 19.07, 21.02 and master key into all 3 branches? How about adding keys like that: 19.07: 19.07 + 21.02 keys 21.02: 21.02 + openwrt-next keys snapshot: snapshot key The snapshot key stays the same "forever", it shouldn't be included in releases. The signature verification of sysupgrade images is currently not used as far as I know, so normal we do not need the keys for of other releases. If the `ucert` package is installed and the env variable `REQUIRE_IMAGE_SIGNATURE` is set, the images are verified. This should eventually become the default. How reliable is this working? I've been using ucert on many devices for a long time for now. In order to be more secure, the signed data should be normalized (ie. sorted and non-relevant data removed), which has not been done yet. Right now, hash collissions could be constructed by changing the order of fields and/or adding useless additional data -- however, that would still mean having to break SHA256. Generally, to be considered more than just a small extra barrier or even a security risk, much more review would be needed. See: https://git.openwrt.org/?p=project/ucert.git;a=blob;f=README.md;hb=refs/heads/master#l6 Currently we do not ship ucert by default and this is needed to check the image signature. People can, however, install ucert which enabled signature checks of future sysupgrade. When using 'auc' or 'luci-app-attendedsysupgrade' for upgrade, all explicitely installed packages are also kept accross updates, and that can include 'ucert' (which is what I've been doing for a while now on my local devices) Ok this is nice. I tried to check the signature of the 21.02-rc1 release and it failed: --- root@OpenWrt:/tmp# REQUIRE_IMAGE_SIGNATURE=1 sysupgrade -T openwrt-21.02.0-rc1-ath79-generic-tplink_tl-wdr4300-v1-squashfs-sysupgrade.bin cert_verify: cannot parse cert Image check failed. --- With a self build image it works. It contains "# fake certificate" where I would expect the certificate. Is this expected? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] openwrt-keyring: Only copy sign key for snapshots
On 5/14/21 12:17 PM, Paul Spooren wrote: Hi, On 5/13/21 1:32 AM, Hauke Mehrtens wrote: Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the master feeds. If one of the other keys would be compromised this would not affect users of master snapshot builds. Signed-off-by: Hauke Mehrtens --- Thanks for working on this. I'm still in favor to include a *openwrt-next* key which becomes the signing key for the next release. This way a upgrade step between release branches is possible. I would prefer to create it closer to the next release. As far as I know the other keys are not compromised, this is just a precaution. I would do similar changes to 21.02 and 19.07 to only add the key which is used for this specific release. In case of 19.07 please add 21.02 release keys as well, since it's *the next key*. Yes, good idea. Instead of adding just this single key, should we add all keys of currently maintained releases like 19.07, 21.02 and master key into all 3 branches? How about adding keys like that: 19.07: 19.07 + 21.02 keys 21.02: 21.02 + openwrt-next keys snapshot: snapshot key The snapshot key stays the same "forever", it shouldn't be included in releases. The signature verification of sysupgrade images is currently not used as far as I know, so normal we do not need the keys for of other releases. If the `ucert` package is installed and the env variable `REQUIRE_IMAGE_SIGNATURE` is set, the images are verified. This should eventually become the default. How reliable is this working? Currently we do not ship ucert by default and this is needed to check the image signature. So ideally we already start shipping the correct keys before activating the extra security measurements. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] openwrt-keyring: Only copy sign key for snapshots
Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the master feeds. If one of the other keys would be compromised this would not affect users of master snapshot builds. Signed-off-by: Hauke Mehrtens --- As far as I know the other keys are not compromised, this is just a precaution. I would do similar changes to 21.02 and 19.07 to only add the key which is used for this specific release. Instead of adding just this single key, should we add all keys of currently maintained releases like 19.07, 21.02 and master key into all 3 branches? The signature verification of sysupgrade images is currently not used as far as I know, so normal we do not need the keys for of other releases. package/system/openwrt-keyring/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/system/openwrt-keyring/Makefile b/package/system/openwrt-keyring/Makefile index 6f3aa65622d5..ceaccf1fc527 100644 --- a/package/system/openwrt-keyring/Makefile +++ b/package/system/openwrt-keyring/Makefile @@ -32,7 +32,8 @@ Build/Compile= define Package/openwrt-keyring/install $(INSTALL_DIR) $(1)/etc/opkg/keys/ - $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/* $(1)/etc/opkg/keys/ + # Public usign key for unattended snapshot builds + $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/b5043e70f9a75cde $(1)/etc/opkg/keys/ endef $(eval $(call BuildPackage,openwrt-keyring)) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Activate https server support in 21.02 by default
Hi, OpenWrt 21.02 currently ships with wolfssl and LuCI for http. It would be nice to also have https support included in the default images. To add this the following packages have to be added: * luci-ssl (969 Bytes ipkg) * px5g-wolfssl (5216 bytes ipkg) For me the images increased by 2.2 KBytes when these packages were included. We should *not* activate the automatic forwarding from http to https by default. This was deactivated here and should stay like this: https://git.openwrt.org/0cf3c5dd7257dff1c87b61c5e53e5b1787ab7015 It would be nice to have this as an option in the default LuCI configuration, see here: https://github.com/openwrt/luci/pull/4659 Where are the default packages for the 21.02 releases defined? I haven't found it here: https://git.openwrt.org/?p=buildbot.git;a=summary My proposal: * Add luci-ssl to the default packages for the 21.02 branch * merge this: https://github.com/openwrt/luci/pull/4659 @Jow what do you think about this? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] mac80211: use auto channel list by default
Hi David, On 5/3/21 1:14 AM, David Bauer wrote: Hi Hauke, On 5/3/21 12:23 AM, Hauke Mehrtens wrote: This change removes setting the channels property by default to the channel property if nothing else is specified. When hostapd detects a DFS alarm and it has to switch channels allow hostapd to switch to any channel in the frequency band if channels property is not specified. This was exactly the behavior I've tried to fix. My expectation when configuring a specific channel would be, that the radio does not switch to an arbitrary channel when it is forced to do DFS. Especially as DFS channels are required to be used when the AP is used Outdoors (At least in Germany / ETSI). When dynamic channel usage is desired, I'd expect the user to provide a chanlist or use the "auto" channel. Maybe this is something which is is flexible in how it can be interpreted, so I'm open to find an alternative solution for that. ;) I assumed that this was intentional. ;-) I was not aware of chanlist until recently, should we add this to the default configuration to promote it more? If the interface is just off for an hour and comes back this should be fine. Should we set the default 5GHz channel to auto? When we set channels to the same channel as the channel variable it will not switch channel, the interface will be deactivated and hostapd writes this error message: Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-NOP-FINISHED freq=5640 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5640 cf2=0 Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: interface state DFS->DFS Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5580 chan=116 sec_chan=1, width=0, seg0=122, seg1=0, cac_time=60s Wed Feb 10 17:24:48 2021 daemon.err hostapd: 20/40 MHz: center segment 0 (=122) and center freq 1 (=5590) not in sync Wed Feb 10 17:24:48 2021 daemon.err hostapd: Can't set freq params Wed Feb 10 17:24:48 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1 Can you share your radio settings? I've tested this back when the patch was applied and the radio reappeared after the NOP period. I used these settings: config wifi-device 'radio1' option type 'mac80211' option channel '120' option hwmode '11a' option path '1e14.pcie/pci:00/:00:01.0/:02:00.0' option htmode 'VHT80' option country 'DE' config wifi-iface 'default_radio1' option device 'radio1' option network 'lan' option mode 'ap' option ssid 'mywifi' option encryption 'sae-mixed' option key 'mykeykey' - on a Xiaomi Mi Router 3G (MT76x2E) I think hostapd tries to switch from 80MHz channel size to 40MHz to try to avoid DFS. When I debugged this further it looked like this switch is not fully working, it ends up in a mix of 80MHz and 40MHz settings and the validation fails. I am also seeing this with hostapd from April 2021. Did anyone ever ran the hostapd test suite? I would like to reproduce this problem there. I think there is a test case for this scenario already, but it could be that it needs some tweaks. Can I trigger DFS events intentional to trigger this code in hostapd? I do not want to wait 3 days till this happens. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH opkg] libopkg: pkg_hash: print unresolved dependencies
On 5/3/21 2:38 PM, Baptiste Jonglez wrote:
Hi,
On 02-05-21, Hauke Mehrtens wrote:
When a package is not installed because it has unresolved dependencies
normally we get only an error message like this:
* pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app
found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package ltq-vdsl-app.
Log in addition the following error message:
* pkg_hash_check_unresolved: can not find dependency ltq-dsl-base for
ltq-vdsl-app
Since the error has probably nothing to do with "architectures", wouldn't
it make more sense to remove or improve the first error message? Or
understand why it fails for seemingly unrelated reasons.
This "incompatible with the architectures configured" error message is
shown for more error cases than the newly added one, see here:
https://lxr.openwrt.org/source/opkg-lede/libopkg/pkg_hash.c#L395
It would probably be good to improve the error messages, but I do not
understand the full code. If someone has some suggestions on how to
improve this it would be nice.
Signed-off-by: Hauke Mehrtens
---
I am not sure if this would happen in normal cases too and spam the
error log, I only saw this in an error case.
libopkg/pkg_hash.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
index a07a25e..6c04ab2 100644
--- a/libopkg/pkg_hash.c
+++ b/libopkg/pkg_hash.c
@@ -263,8 +263,10 @@ pkg_hash_check_unresolved(pkg_t *maybe)
if (unresolved) {
res = 1;
tmp = unresolved;
- while (*tmp)
+ while (*tmp) {
+ opkg_msg(ERROR, "can not find dependency %s for %s\n",
*tmp, maybe->name);
free(*(tmp++));
+ }
free(unresolved);
}
pkg_vec_free(depends);
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] treewide: Mark packages nonshared if they depend on @TARGET_
This marks all packages which depend on a target with @TARGET nonshared. If they are not marked nonshared they would be build by the SDK build and if this happens with a different SDK, then the SDK from the target the package depends on, the package would not be added to the index. This should fix the image builder for some of these packages. Signed-off-by: Hauke Mehrtens --- package/firmware/amd64-microcode/Makefile | 2 ++ package/firmware/cypress-nvram/Makefile| 2 ++ package/firmware/intel-microcode/Makefile | 2 ++ package/firmware/layerscape/fman-ucode/Makefile| 2 ++ package/firmware/layerscape/ls-ddr-phy/Makefile| 2 ++ package/firmware/layerscape/ls-dpl/Makefile| 2 ++ package/firmware/layerscape/ls-mc/Makefile | 2 ++ package/firmware/layerscape/ls-rcw/Makefile| 2 ++ package/firmware/layerscape/ppfe-firmware/Makefile | 2 ++ package/network/utils/layerscape/restool/Makefile | 2 ++ package/system/iucode-tool/Makefile| 2 ++ package/utils/bcm4908img/Makefile | 2 ++ 12 files changed, 24 insertions(+) diff --git a/package/firmware/amd64-microcode/Makefile b/package/firmware/amd64-microcode/Makefile index e0051ab8c0b9..883c74b0 100644 --- a/package/firmware/amd64-microcode/Makefile +++ b/package/firmware/amd64-microcode/Makefile @@ -18,6 +18,8 @@ PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-3.$(PKG_VERSION).$(PKG_RELEASE) PKG_LICENSE_FILE:=LICENSE.amd-ucode +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk define Package/amd64-microcode diff --git a/package/firmware/cypress-nvram/Makefile b/package/firmware/cypress-nvram/Makefile index bccdb3fcedab..777b8260885f 100644 --- a/package/firmware/cypress-nvram/Makefile +++ b/package/firmware/cypress-nvram/Makefile @@ -18,6 +18,8 @@ PKG_SOURCE_URL:=https://github.com/openwrt/cypress-nvram.git PKG_MAINTAINER:=Álvaro Fernández Rojas +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk define Package/cypress-nvram-default diff --git a/package/firmware/intel-microcode/Makefile b/package/firmware/intel-microcode/Makefile index e8ae7bff5822..d2f61e9bf088 100644 --- a/package/firmware/intel-microcode/Makefile +++ b/package/firmware/intel-microcode/Makefile @@ -24,6 +24,8 @@ else MICROCODE:="intel-microcode" endif +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk define Package/intel-microcode diff --git a/package/firmware/layerscape/fman-ucode/Makefile b/package/firmware/layerscape/fman-ucode/Makefile index 8c76774ac753..69cc76111034 100644 --- a/package/firmware/layerscape/fman-ucode/Makefile +++ b/package/firmware/layerscape/fman-ucode/Makefile @@ -16,6 +16,8 @@ PKG_SOURCE_URL:=https://github.com/NXP/qoriq-fm-ucode.git PKG_SOURCE_VERSION:=c275e91392e2adab1ed22f3867b8269ca3c54014 PKG_MIRROR_HASH:=90b619ed501462b92f34f2fabfa09d6aaa5235990891d1c3132821c7d18a39bd +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk define Package/layerscape-fman diff --git a/package/firmware/layerscape/ls-ddr-phy/Makefile b/package/firmware/layerscape/ls-ddr-phy/Makefile index bd861962e7f0..68142b4bbf50 100644 --- a/package/firmware/layerscape/ls-ddr-phy/Makefile +++ b/package/firmware/layerscape/ls-ddr-phy/Makefile @@ -18,6 +18,8 @@ PKG_BUILD_DEPENDS:=tfa-layerscape/host PKG_LICENSE:=EULA PKG_LICENSE_FILES:=NXP-Binary-EULA.txt +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk define Package/layerscape-ddr-phy diff --git a/package/firmware/layerscape/ls-dpl/Makefile b/package/firmware/layerscape/ls-dpl/Makefile index f577c5b7e377..8ba5fafb2b74 100644 --- a/package/firmware/layerscape/ls-dpl/Makefile +++ b/package/firmware/layerscape/ls-dpl/Makefile @@ -16,6 +16,8 @@ PKG_SOURCE_URL:=https://source.codeaurora.org/external/qoriq/qoriq-components/mc PKG_SOURCE_VERSION:=8672a5f5abcd3a354dcab07e03f2a8a69b2e962d PKG_MIRROR_HASH:=4b8ad3148aee1e0c034206543472aebb435655fd03a661c4c1be545dcac7ddf0 +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk include $(INCLUDE_DIR)/kernel.mk diff --git a/package/firmware/layerscape/ls-mc/Makefile b/package/firmware/layerscape/ls-mc/Makefile index daba35a3b910..3b2cdebbf1b1 100644 --- a/package/firmware/layerscape/ls-mc/Makefile +++ b/package/firmware/layerscape/ls-mc/Makefile @@ -16,6 +16,8 @@ PKG_SOURCE_URL:=https://github.com/NXP/qoriq-mc-binary.git PKG_SOURCE_VERSION:=f73683596a7b72124d67b62e64f3dc2bb36b9321 PKG_MIRROR_HASH:=1cba30c2a6814763c3e155c1cc5fa21998bb6ad5814fcb09e99f98bf36f65d9e +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk define Package/layerscape-mc diff --git a/package/firmware/layerscape/ls-rcw/Makefile b/package/firmware/layerscape/ls-rcw/Makefile index f7f99a0c3042..fdc5c0ce24ca 100644 --- a/package/firmware/layerscape/ls-rcw/Makefile +++ b/package/firmware/layerscape/ls-rcw/Makefile @@ -16,6 +16,8 @@ PKG_SOURCE_URL:=https://source.codeaurora.org/external/qoriq/qoriq-components/rc PKG_SOUR
[RFC PATCH] mac80211: use auto channel list by default
This change removes setting the channels property by default to the
channel property if nothing else is specified.
When hostapd detects a DFS alarm and it has to switch channels allow
hostapd to switch to any channel in the frequency band if channels
property is not specified.
When we set channels to the same channel as the channel variable it will
not switch channel, the interface will be deactivated and hostapd writes
this error message:
Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-NOP-FINISHED
freq=5640 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5640 cf2=0
Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: interface state DFS->DFS
Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5580
chan=116 sec_chan=1, width=0, seg0=122, seg1=0, cac_time=60s
Wed Feb 10 17:24:48 2021 daemon.err hostapd: 20/40 MHz: center segment 0 (=122)
and center freq 1 (=5590) not in sync
Wed Feb 10 17:24:48 2021 daemon.err hostapd: Can't set freq params
Wed Feb 10 17:24:48 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1
With this patch hostapd will switch to any other channel and continue
operating there when it received a DFS event. When the channels property
was set nothing changes.
Revert "mac80211: create channel list for fixed channel operation"
This reverts commit cfd2f3bf6f4825b66e9a4ca9cba7c65b93eb89c7.
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 3 ---
1 file changed, 3 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 92c56afd24fd..d6be2ed76c36 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -111,9 +111,6 @@ mac80211_hostapd_setup_base() {
json_get_values ht_capab_list ht_capab tx_burst
json_get_values channel_list channels
- [ "$auto_channel" = 0 ] && [ -z "$channel_list" ] && \
- channel_list="$channel"
-
set_default noscan 0
[ "$noscan" -gt 0 ] && hostapd_noscan=1
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 19.07] mac80211: Update to backports version 4.19.189-test2
The removed patches were applied upstream.
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 6 +-
.../ath/500-ath9k_eeprom_debugfs.patch| 4 +-
.../ath/512-ath9k_channelbw_debugfs.patch | 4 +-
.../patches/ath/530-ath9k_extra_leds.patch| 10 +--
.../patches/ath/542-ath9k_debugfs_diag.patch | 4 +-
.../ath/548-ath9k_enable_gpio_chip.patch | 4 +-
.../ath/549-ath9k_enable_gpio_buttons.patch | 2 +-
.../mac80211/patches/ath/552-ahb_of.patch | 2 +-
.../ath/930-ath10k_add_tpt_led_trigger.patch | 4 +-
...-of-peer_bw_rxnss_override-parameter.patch | 2 +-
...dling-for-VHT160-in-recent-firmwares.patch | 2 +-
...rolling-support-for-various-chipsets.patch | 14 ++--
...75-ath10k-use-tpt-trigger-by-default.patch | 2 +-
...rt-for-configuring-management-packet.patch | 4 +-
...ble-out-of-bound-access-of-ath10k_ra.patch | 2 +-
...rect-multicast-broadcast-rate-settin.patch | 4 +-
...frameburst-mode-in-default-firmware-.patch | 2 +-
...phy_err-and-use-it-in-the-cfg80211.c.patch | 76 +--
...-code-handling-bandwidth-of-firmware.patch | 2 +-
...-firmware-reporting-160-MHz-channels.patch | 2 +-
...bphy_err-to-take-struct-brcmf_pub-ar.patch | 76 +--
...DFS_OFFLOAD-extended-feature-if-supp.patch | 2 +-
...g80211_ops-pointer-to-another-struct.patch | 2 +-
...rors-when-setting-roaming-parameters.patch | 2 +-
...B-condition-when-setting-interface-c.patch | 10 +--
...lify-building-interface-combinations.patch | 6 +-
...add-initial-support-for-monitor-mode.patch | 8 +-
.../subsys/150-disable_addr_notifier.patch| 6 +-
.../mac80211/patches/subsys/210-ap_scan.patch | 2 +-
...d-stop-start-logic-for-software-TXQs.patch | 4 +-
...l-merge-with-minstrel_ht-always-enab.patch | 4 +-
.../320-mac80211-Add-TXQ-scheduling-API.patch | 2 +-
...time-accounting-and-scheduling-to-TX.patch | 4 +-
...1-add-TX_NEEDS_ALIGNED4_SKBS-hw-flag.patch | 4 +-
...op-redundant-rcu_read_lock-unlock-ca.patch | 2 +-
...nd-deauth-when-expiring-inactive-STA.patch | 2 +-
...et-set-TDLS-STA-bandwidth-wider-than.patch | 65
...use-TX-while-changing-interface-type.patch | 57 --
...ac80211-fix-fast-rx-encryption-check.patch | 29 ---
...-station-rate-table-updates-on-assoc.patch | 49
...ential-overflow-when-multiplying-to-.patch | 34 -
.../374-mac80211-fix-rate-mask-reset.patch| 50
...c80211-fix-double-free-in-ibss_leave.patch | 69 -
.../522-mac80211_configure_antenna_gain.patch | 4 +-
44 files changed, 146 insertions(+), 499 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/subsys/369-mac80211-don-t-set-set-TDLS-STA-bandwidth-wider-than.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/370-mac80211-pause-TX-while-changing-interface-type.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/371-mac80211-fix-fast-rx-encryption-check.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/372-mac80211-fix-station-rate-table-updates-on-assoc.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/373-mac80211-fix-potential-overflow-when-multiplying-to-.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/374-mac80211-fix-rate-mask-reset.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/375-mac80211-fix-double-free-in-ibss_leave.patch
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 02d717127b..7963469bc7 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=4.19.161-1
+PKG_VERSION:=4.19.189-test2
PKG_RELEASE:=1
-PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v4.19.161/
-PKG_HASH:=01a4173ba180eb8ca67c898239d5accb49a3ea9aea51510e17d5c937d6e93f9a
+PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/
+PKG_HASH:=278035402124183aaa2a339e3eeda620e5440461ebaf22e914a78ec9deab0d36
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
diff --git a/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
b/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
index b6dc45cd96..319db41113 100644
--- a/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
+++ b/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
-@@ -1374,6 +1374,53 @@ void ath9k_deinit_debug(struct ath_softc
+@@ -1377,6 +1377,53 @@ void ath9k_deinit_debug(struct ath_softc
ath9k_cmn_spectral_deinit_debug(&sc->spec_priv);
}
@@ -54,7 +54,7 @@
int ath9k_init_debug(struct ath_hw *ah)
{
struct ath_common *common = ath9k_hw_common(ah);
-@@ -1393,6 +1440,8 @@ int ath9k_ini
[PATCH 19.07] dropbear: Fix CVE-2020-36254
This backports a fix from dropbear 2020.81.
CVE-2020-36254 description:
scp.c in Dropbear before 2020.79 mishandles the filename of . or an empty
filename, a related issue to CVE-2018-20685.
Signed-off-by: Hauke Mehrtens
---
.../patches/001-fix-CVE-2020-36254.patch | 21 +++
1 file changed, 21 insertions(+)
create mode 100644
package/network/services/dropbear/patches/001-fix-CVE-2020-36254.patch
diff --git
a/package/network/services/dropbear/patches/001-fix-CVE-2020-36254.patch
b/package/network/services/dropbear/patches/001-fix-CVE-2020-36254.patch
new file mode 100644
index 00..03f8bf9a81
--- /dev/null
+++ b/package/network/services/dropbear/patches/001-fix-CVE-2020-36254.patch
@@ -0,0 +1,21 @@
+From 8f8a3dff705fad774a10864a2e3dbcfa9779ceff Mon Sep 17 00:00:00 2001
+From: Haelwenn Monnier
+Date: Mon, 25 May 2020 14:54:29 +0200
+Subject: [PATCH] scp.c: Port OpenSSH CVE-2018-20685 fix (#80)
+
+---
+ scp.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/scp.c
b/scp.c
+@@ -935,7 +935,8 @@ sink(int argc, char **argv)
+ size = size * 10 + (*cp++ - '0');
+ if (*cp++ != ' ')
+ SCREWUP("size not delimited");
+- if ((strchr(cp, '/') != NULL) || (strcmp(cp, "..") == 0)) {
++ if (*cp == '\0' || strchr(cp, '/') != NULL ||
++ strcmp(cp, ".") == 0 || strcmp(cp, "..") == 0) {
+ run_err("error: unexpected filename: %s", cp);
+ exit(1);
+ }
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ltq-dsl-base: Make package nonshared to fix image builder
This package depends on the lantiq target and is only build for that target. A normal package would be build by the SDK builder probably under a different target and then this package will not be selected. Mark it as nonshared to build it when the lantiq target gets build. Fixes: FS#3773, FS#3774 Signed-off-by: Hauke Mehrtens --- package/network/utils/ltq-dsl-base/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/package/network/utils/ltq-dsl-base/Makefile b/package/network/utils/ltq-dsl-base/Makefile index aae07bc29925..2ff069ca4dc7 100644 --- a/package/network/utils/ltq-dsl-base/Makefile +++ b/package/network/utils/ltq-dsl-base/Makefile @@ -8,6 +8,8 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ltq-dsl-base PKG_RELEASE:=3 +PKG_FLAGS:=nonshared + include $(INCLUDE_DIR)/package.mk define Package/ltq-dsl-base -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH opkg] libopkg: pkg_hash: print unresolved dependencies
When a package is not installed because it has unresolved dependencies
normally we get only an error message like this:
* pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app found,
but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package ltq-vdsl-app.
Log in addition the following error message:
* pkg_hash_check_unresolved: can not find dependency ltq-dsl-base for
ltq-vdsl-app
Signed-off-by: Hauke Mehrtens
---
I am not sure if this would happen in normal cases too and spam the
error log, I only saw this in an error case.
libopkg/pkg_hash.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
index a07a25e..6c04ab2 100644
--- a/libopkg/pkg_hash.c
+++ b/libopkg/pkg_hash.c
@@ -263,8 +263,10 @@ pkg_hash_check_unresolved(pkg_t *maybe)
if (unresolved) {
res = 1;
tmp = unresolved;
- while (*tmp)
+ while (*tmp) {
+ opkg_msg(ERROR, "can not find dependency %s for %s\n",
*tmp, maybe->name);
free(*(tmp++));
+ }
free(unresolved);
}
pkg_vec_free(depends);
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH] mac80211: Update to version 5.10.34-test3
The removed patches were applied upstream and are not needed any more.
Signed-off-by: Hauke Mehrtens
---
I will create an official backports release soon, this is only for testing for
now.
package/kernel/mac80211/Makefile | 6 +-
.../ath/500-ath9k_eeprom_debugfs.patch| 4 +-
.../ath/512-ath9k_channelbw_debugfs.patch | 4 +-
.../patches/ath/530-ath9k_extra_leds.patch| 10 +--
.../patches/ath/542-ath9k_debugfs_diag.patch | 4 +-
.../ath/548-ath9k_enable_gpio_chip.patch | 4 +-
.../ath/549-ath9k_enable_gpio_buttons.patch | 2 +-
.../ath/551-ath9k_ubnt_uap_plus_hsr.patch | 2 +-
.../mac80211/patches/ath/552-ahb_of.patch | 2 +-
...itting-to-stations-in-dynamic-SMPS-m.patch | 49 ---
.../ath/930-ath10k_add_tpt_led_trigger.patch | 4 +-
...rolling-support-for-various-chipsets.patch | 2 +-
...75-ath10k-use-tpt-trigger-by-default.patch | 2 +-
.../100-remove-cryptoapi-dependencies.patch | 7 ++-
.../subsys/150-disable_addr_notifier.patch| 6 +-
.../mac80211/patches/subsys/210-ap_scan.patch | 2 +-
...ort-immediate-reconnect-request-hint.patch | 14 ++---
...-driver-based-disconnect-with-reconn.patch | 12 ++--
.../370-mac80211-fix-TXQ-AC-confusion.patch | 61 ---
...c80211-fix-time-is-after-bug-in-mlme.patch | 31 --
.../500-mac80211_configure_antenna_gain.patch | 8 +--
21 files changed, 48 insertions(+), 188 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/ath/560-ath9k-fix-transmitting-to-stations-in-dynamic-SMPS-m.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/370-mac80211-fix-TXQ-AC-confusion.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/374-mac80211-fix-time-is-after-bug-in-mlme.patch
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index b92df681cb2b..ecdb4c9421e5 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=5.10.16-1
+PKG_VERSION:=5.10.34-test3
PKG_RELEASE:=1
-PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v5.10.16/
-PKG_HASH:=12856db780c5023edc47e2d18486eb3346bb7c82f1f2fc48deb3b163142f7d2d
+PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/
+PKG_HASH:=1fe98d883ce041791332fb8720ae4325b4803ea18b3c38e8c9df8cf836f12bc8
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
diff --git a/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
b/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
index 786a3ed3fbcc..48ccc8130807 100644
--- a/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
+++ b/package/kernel/mac80211/patches/ath/500-ath9k_eeprom_debugfs.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
-@@ -1361,6 +1361,53 @@ void ath9k_deinit_debug(struct ath_softc
+@@ -1364,6 +1364,53 @@ void ath9k_deinit_debug(struct ath_softc
ath9k_cmn_spectral_deinit_debug(&sc->spec_priv);
}
@@ -54,7 +54,7 @@
int ath9k_init_debug(struct ath_hw *ah)
{
struct ath_common *common = ath9k_hw_common(ah);
-@@ -1380,6 +1427,8 @@ int ath9k_init_debug(struct ath_hw *ah)
+@@ -1383,6 +1430,8 @@ int ath9k_init_debug(struct ath_hw *ah)
ath9k_tx99_init_debug(sc);
ath9k_cmn_spectral_init_debug(&sc->spec_priv, sc->debug.debugfs_phy);
diff --git
a/package/kernel/mac80211/patches/ath/512-ath9k_channelbw_debugfs.patch
b/package/kernel/mac80211/patches/ath/512-ath9k_channelbw_debugfs.patch
index 80e33182f734..126d1d5c6248 100644
--- a/package/kernel/mac80211/patches/ath/512-ath9k_channelbw_debugfs.patch
+++ b/package/kernel/mac80211/patches/ath/512-ath9k_channelbw_debugfs.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
-@@ -1408,6 +1408,52 @@ static const struct file_operations fops
+@@ -1411,6 +1411,52 @@ static const struct file_operations fops
.owner = THIS_MODULE
};
@@ -53,7 +53,7 @@
int ath9k_init_debug(struct ath_hw *ah)
{
struct ath_common *common = ath9k_hw_common(ah);
-@@ -1429,6 +1475,8 @@ int ath9k_init_debug(struct ath_hw *ah)
+@@ -1432,6 +1478,8 @@ int ath9k_init_debug(struct ath_hw *ah)
debugfs_create_file("eeprom", S_IRUSR, sc->debug.debugfs_phy, sc,
&fops_eeprom);
diff --git a/package/kernel/mac80211/patches/ath/530-ath9k_extra_leds.patch
b/package/kernel/mac80211/patches/ath/530-ath9k_extra_leds.patch
index 1f194830642e..5fd5c73a2f3d 100644
--- a/package/kernel/mac80211/patches/ath/530-ath9k_extra_leds.patch
+++ b/package/kernel/mac80211/patches/ath/530-ath9k_extra_leds.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
-@@ -843,6 +843,9 @@ static
[PATCH] busybox: backport fix for CVE-2021-28831
This backports a fix for the low priority CVE-2021-28831:
decompress_gunzip.c in BusyBox through 1.32.1 mishandles the error bit
on the huft_build result pointer, with a resultant invalid free or
segmentation fault, via malformed gzip data.
Signed-off-by: Hauke Mehrtens
---
package/utils/busybox/Makefile| 2 +-
.../patches/005-backport-CVE-2021-28831.patch | 52 +++
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100644
package/utils/busybox/patches/005-backport-CVE-2021-28831.patch
diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile
index 9df358ef781e..58bc1e679524 100644
--- a/package/utils/busybox/Makefile
+++ b/package/utils/busybox/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=busybox
PKG_VERSION:=1.33.0
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_FLAGS:=essential
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
diff --git a/package/utils/busybox/patches/005-backport-CVE-2021-28831.patch
b/package/utils/busybox/patches/005-backport-CVE-2021-28831.patch
new file mode 100644
index ..7637679a69cb
--- /dev/null
+++ b/package/utils/busybox/patches/005-backport-CVE-2021-28831.patch
@@ -0,0 +1,52 @@
+From f25d254dfd4243698c31a4f3153d4ac72aa9e9bd Mon Sep 17 00:00:00 2001
+From: Samuel Sapalski
+Date: Wed, 3 Mar 2021 16:31:22 +0100
+Subject: decompress_gunzip: Fix DoS if gzip is corrupt
+
+On certain corrupt gzip files, huft_build will set the error bit on
+the result pointer. If afterwards abort_unzip is called huft_free
+might run into a segmentation fault or an invalid pointer to
+free(p).
+
+In order to mitigate this, we check in huft_free if the error bit
+is set and clear it before the linked list is freed.
+
+Signed-off-by: Samuel Sapalski
+Signed-off-by: Peter Kaestle
+Signed-off-by: Denys Vlasenko
+---
+ archival/libarchive/decompress_gunzip.c | 12 ++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/archival/libarchive/decompress_gunzip.c
b/archival/libarchive/decompress_gunzip.c
+@@ -220,10 +220,20 @@ static const uint8_t border[] ALIGN1 = {
+ * each table.
+ * t: table to free
+ */
++#define BAD_HUFT(p) ((uintptr_t)(p) & 1)
++#define ERR_RET ((huft_t*)(uintptr_t)1)
+ static void huft_free(huft_t *p)
+ {
+ huft_t *q;
+
++ /*
++ * If 'p' has the error bit set we have to clear it, otherwise we might
run
++ * into a segmentation fault or an invalid pointer to free(p)
++ */
++ if (BAD_HUFT(p)) {
++ p = (huft_t*)((uintptr_t)(p) ^ (uintptr_t)(ERR_RET));
++ }
++
+ /* Go through linked list, freeing from the malloced (t[-1]) address. */
+ while (p) {
+ q = (--p)->v.t;
+@@ -289,8 +299,6 @@ static unsigned fill_bitbuffer(STATE_PAR
+ * or a valid pointer to a Huffman table, ORed with 0x1 if incompete table
+ * is given: "fixed inflate" decoder feeds us such data.
+ */
+-#define BAD_HUFT(p) ((uintptr_t)(p) & 1)
+-#define ERR_RET ((huft_t*)(uintptr_t)1)
+ static huft_t* huft_build(const unsigned *b, const unsigned n,
+ const unsigned s, const struct cp_ext *cp_ext,
+ unsigned *m)
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: update mt7530 EEE patch from upstream
On 5/1/21 7:53 PM, Ilya Lipnitskiy wrote: On Sat, May 1, 2021 at 7:32 AM DENG Qingfang wrote: Hi Hauke, On Sat, May 1, 2021 at 10:06 PM Hauke Mehrtens wrote: Yes, I think that is a good idea. Will you prepare a patch? While trying that, I found some patches in pending-5.4 that are also supposed to be in backport, causing another patch conflict. Cc: Ilya Alternatively, you can revert the changes in 5.4 Do we need to maintain 5.4 mt7530 on master for 21.02? I haven't really looked at backporting 5.10+ changes to 5.4 and focused more on 5.10 patch upstreaming and cleanup in my efforts. If not, the easiest thing is probably to just leave 5.4 alone. Ilya Hi, I am fine with reverting this change for 5.4 and only keep it for 5.10 which compiles fine. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: update mt7530 EEE patch from upstream
On 5/1/21 4:01 PM, DENG Qingfang wrote: Hi Hauke, On Sat, May 1, 2021 at 9:48 PM Hauke Mehrtens wrote: These patches are now applied in a different order compared to the upstream kernel, could you please have a look. I think we should move 0600~0602 patches to backport-5.4, then apply René's upstream patch as-is on top of that. Yes, I think that is a good idea. Will you prepare a patch? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: update mt7530 EEE patch from upstream
On 4/22/21 7:08 AM, DENG Qingfang wrote: The new EEE patch is accepted upstream, so backport it and replace the current one. Cc: René van Dorst Signed-off-by: DENG Qingfang --- ...-mt7530-Add-support-for-EEE-features.patch | 120 + ...-mt7530-Add-support-for-EEE-features.patch | 120 + ...-net-dsa-mt7530-Support-EEE-features.patch | 121 -- ...-net-dsa-mt7530-Support-EEE-features.patch | 121 -- 4 files changed, 240 insertions(+), 242 deletions(-) create mode 100644 target/linux/generic/backport-5.10/781-v5.13-net-dsa-mt7530-Add-support-for-EEE-features.patch create mode 100644 target/linux/generic/backport-5.4/781-v5.13-net-dsa-mt7530-Add-support-for-EEE-features.patch delete mode 100644 target/linux/generic/pending-5.10/761-net-dsa-mt7530-Support-EEE-features.patch delete mode 100644 target/linux/generic/pending-5.4/761-net-dsa-mt7530-Support-EEE-features.patch Hi, The mediatek/mt7623 is not compiling any more after this change. Applying /builder/shared-workdir/build/target/linux/mediatek/patches-5.4/0602-net-dsa-mt7530-use-resolved-link-config-in-mac_link_.patch using plaintext: patching file drivers/net/dsa/mt7530.c Hunk #4 FAILED at 1394. Hunk #5 FAILED at 1403. Hunk #6 succeeded at 1441 (offset 8 lines). Hunk #7 succeeded at 1452 (offset 8 lines). 2 out of 7 hunks FAILED -- saving rejects to file drivers/net/dsa/mt7530.c.rej patching file drivers/net/dsa/mt7530.h These patches are now applied in a different order compared to the upstream kernel, could you please have a look. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.0 first release candidate
Hi, The OpenWrt community is proud to announce the first release candidate of the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year. WPA3 support included by default WPA3 was already supported in 19.07 but it was not provided by the default set of packages in OpenWrt images. With 21.02, all packages necessary to provide WPA3 are installed by default in OpenWrt images. TLS and HTTPS support included by default TLS support is now provided by default in OpenWrt images including the trusted CA certificates from Mozilla. It means that wget and opkg now support fetching resources over HTTPS out-of-the-box. The opkg download server is accessed through HTTPS by default. OpenWrt switched from mbed TLS to wolfSSL as the default SSL library, mbed TLS and OpenSSL are still available and can be installed manually. Initial DSA support DSA stands for Distributed Switch Architecture and is the Linux standard to deal with configurable Ethernet switches. OpenWrt 21.02 comes with initial support for DSA, which replaces the swconfig system that OpenWrt was using up until now. Not all targets have been ported: some devices still use swconfig while some devices already switched to DSA. This is a significant change to how switch ports and VLANs are managed. As such, sysupgrade will not be able to convert existing swconfig configuration to DSA configuration (see “Upgrading” below). The following targets are using a switch managed with DSA in OpenWrt 21.02: * ath79 (only TP-Link TL-WR941ND) * bcm4908 * gemini * kirkwood * mediatek (most boards) * mvebu * octeon * ramips/mt7621 * realtek Increased minimum hardware requirements: 8 MB flash, 64 MB RAM Due to new features being introduced and the general size increase of the Linux kernel, devices now need at least 8 MB of flash and 64 MB of RAM to run a default build of OpenWrt. It is still possible to build custom OpenWrt images (e.g. using the ImageBuilder) that may fit devices with 4 MB of flash or 32 MB of RAM. However, the level of functionality will be reduced and there is no guarantee to stability. See OpenWrt on 4/32 devices for more details and guidance. New hardware targets A new realtek target has been added, which is often found in managed switches. As a result, it is now possible to run OpenWrt on devices with a significant number of Ethernet ports. See supported devices for realtek. In addition, new bcm4908 and rockchip targets have been added. Support for many new boards was added to the existing targets. Dropped hardware targets The ar71xx was deprecated in OpenWrt 19.07 and was gradually replaced by ath79, see ar71xx-ath79 migration. With OpenWrt 21.02, the ar71xx has been removed and users must use ath79 instead. If you are still running with the ar71xx target, it is recommended to reinstall OpenWrt 21.02 from scratch. Users already on the ath79 target can use sysupgrade to upgrade to OpenWrt 21.02. Other targets were also removed: cns3xxx, rb532 and samsung. ASLR activated Network exposed user space applications are linked as position-independent executable (PIE) to allow full Address Space Layout Randomization (ASLR) support. This makes it harder for attackers to exploit OpenWrt. See Hardening build options for more details. Kernel with container support Multiple Linux kernel compile options, needed for Linux Containers (LXC) and procd-ujail are activated by default for most targets. This allows to use LXC and ujail with the normal release builds. SELinux support It is possible to compile OpenWrt with SELinux support. This is currently not activated by default. Core components update Core components have the following versions in 21.02.0-rc1: * Updated toolchain: * musl libc 1.1.24 * glibc 2.33 * gcc 8.4.0 * binutils 2.35.1 * Updated Linux kernel * 5.4.111 for all targets * Network: * hostapd 2020-06-08, dnsmasq 2.84, dropbear 2020.81 * cfg80211/mac80211 from kernel 5.10.16 * wireguard backport from upstream Linux kernel * System userland: * busybox 1.33.0 In addition to the listed applications, many others were also updated. Upgrading to 21.02.0-rc1 Sysupgrade can be used to upgrade a device from 19.07 to 21.02, and configuration will be preserved in most cases. Sysupgrade from 18.06 to 21.02 is not supported. There is no migration path for targets that switched from swconfig to DSA. In that case, sysupgrade will refuse to proceed with an appropriate error message: Image version mismatch. image 1.1 device 1.0 Please wipe config during upgrade (force required) or reinstall. Config cannot be migrated from swconfig to DSA Image check failed The default root file system partition size changed for targets/devices relying on booting from mass storage (HDD, USB flash, SD card, etc.), so MBR will change and any additional partitio
Re: OpenWrt 21.02-rc1
On 4/19/21 8:59 AM, Andre Heider wrote: On 19/04/2021 08:51, Florian Eckert wrote: Hello, If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. Since last weekend the following patch was merged into master. The patch extends ltq-vdsl ubus interface with the missing state_num and power_state_num values. https://github.com/openwrt/openwrt/commit/4407d45d9667ab3d376ad4a6b760e07f4dd43e49#diff-ff00a3f4f318bb11684e008813bd876f0865ce6c2c681ec26b0bf178b4e83163 Could we please backport this to the branch openwrt-21.02 before rc1 stable release? Let's get these two patches in too: 48162e4c0c85a7f64d9007565bf5be2c7ace3ada lantiq: enable G.INP retransmission counters 4f27ea7c33447f4b0c8e577509726927916b9625 lantiq: use ActualNetDataRate for speed reporting With those 3 patches 21.02 matches master with the big ubus dsl metric change. I added these 3 patches, but only after tagging. We should do a 21.02.0-rc2 in 2 to 3 weeks anyway. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] maketag.sh/makebranch.sh: handle https download URLs
Since OpenWrt 21.02 we use https for our download server, detect these
URLs too.
Signed-off-by: Hauke Mehrtens
---
To use the https URLs I have to provide the URL manually now:
./maketag.sh -k F1B767859CB2EBC7 -v 21.02.0-rc1 -u
https://downloads.openwrt.org/releases
makebranch.sh | 2 +-
maketag.sh| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/makebranch.sh b/makebranch.sh
index e8472d7..4b3ab77 100755
--- a/makebranch.sh
+++ b/makebranch.sh
@@ -133,7 +133,7 @@ sed -e 's!^RELEASE:=.*!RELEASE:='"$codename"'!g' \
include/version.mk > include/version.branch && \
mv include/version.branch include/version.mk
-sed -e
's!http://downloads.\(openwrt\|lede-project\).org/[^"]*!'"$base_url/$version-SNAPSHOT"'!g'
\
+sed -e
's!\(http\|https\)://downloads.\(openwrt\|lede-project\).org/[^"]*!'"$base_url/$version-SNAPSHOT"'!g'
\
package/base-files/image-config.in >
package/base-files/image-config.branch && \
mv package/base-files/image-config.branch
package/base-files/image-config.in
diff --git a/maketag.sh b/maketag.sh
index 72767b8..5152411 100755
--- a/maketag.sh
+++ b/maketag.sh
@@ -138,7 +138,7 @@ sed -e 's!\(VERSION_NUMBER:=\$(if
.*\),[^,]*)!\1,'"$version"')!g' \
include/version.mk > include/version.tagged && \
mv include/version.tagged include/version.mk
-sed -e
's!http://downloads.\(openwrt\|lede-project\).org/[^"]*!'"$base_url/$version"'!g'
\
+sed -e
's!\(http\|https\)://downloads.\(openwrt\|lede-project\).org/[^"]*!'"$base_url/$version"'!g'
\
-e '/config VERSION_CODE_FILENAMES/ { :next; n; s!default y!default n!; t
end; b next }; :end' \
package/base-files/image-config.in >
package/base-files/image-config.tagged && \
mv package/base-files/image-config.tagged
package/base-files/image-config.in
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: prereq: drop support for Python 3.5
On 4/18/21 9:33 PM, Alberto Bursi wrote: On 18/04/21 20:51, Etienne Champetier wrote: Le sam. 17 avr. 2021 à 17:47, Sven Roederer a écrit : Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer: On my Ubuntu 16.04 based build-system I also have build-failures for meson using Python3.5. Correction: it's a 18.04 LTS ... Should we just recommend to people that want to use "old stable" OS to use the buildbot container images ? Maybe. Although what's the point of using "old stable" if you are going to use it as a base for a docker setup anyway. If you migrate to a docker setup you can use pretty much anything as the base, even OpenWrt can run docker containers now. -Alberto Hi, Many libraries, like glibc, are backwards compatible when we link it against an older version, it also works when it runs with a more recent version of the library. The OpenWrt SDK is build against an old Debian so it can be used with such an old systems, but it also works with a recent Arch Linux for example. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: I found some serious regressions in the luci device config support. not sure yet how long it'll take to sort out. The netifd uci config grew so complex that it'll take a while to try all cases * changing interface settings after previously enabling certain options results in a brick * wireless networks with custom ifnames are improperly bridged * option ipv6 for ppp based protocols is broken because it clashes with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hi, I backported the changes which were requested and went tough the master logs and backported some more fixes to 21.02. If something more is needed please send a mail to the mailing list. I would like to tag OpenWrt 21.02-rc1 on tomorrow Monday evening, without the LuCI DSA support if it does not get merged before. Any objections to this plan? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] netfilter: remove no-op kconfig symbols
On 4/9/21 5:48 PM, Rui Salvaterra wrote: These have long been obsolete. For reference, here's the Linux version where each symbol has been dropped: CONFIG_IP6_NF_QUEUE - 3.5 CONFIG_IP6_NF_TARGET_LOG - 3.4 CONFIG_IP_NF_MATCH_DSCP - 2.6.19 CONFIG_NF_CONNTRACK_IPV4 - 4.19 CONFIG_NF_CONNTRACK_IPV6 - 4.19 CONFIG_NF_CONNTRACK_RTCACHE - OOT, superseded upstream by flow offloading Signed-off-by: Rui Salvaterra --- v2: also removed CONFIG_NF_CONNTRACK_RTCACHE and two references to CONFIG_NF_CONNTRACK_IPV4 in the WireGuard patches (the QEMU kconfigs). include/netfilter.mk| 6 -- ...reguard-selftests-import-harness-makefile-for-test.patch | 3 +-- ...reguard-selftests-check-that-route_me_harder-packe.patch | 3 +-- target/linux/generic/config-5.10| 2 -- target/linux/generic/config-5.4 | 2 -- 5 files changed, 2 insertions(+), 14 deletions(-) diff --git a/include/netfilter.mk b/include/netfilter.mk index 45e9dadf85..803749d931 100644 --- a/include/netfilter.mk +++ b/include/netfilter.mk @@ -64,9 +64,7 @@ $(eval $(if $(NF_KMOD),,$(call nf_add,IPT_CORE,CONFIG_NETFILTER_XT_MARK, $(P_XT) # kernel only $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK, $(P_XT)nf_conntrack),)) -$(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK_RTCACHE, $(P_XT)nf_conntrack_rtcache),)) This is still uses with a path on top of kernel 5.4 in OpenWrt. $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_DEFRAG_IPV4, $(P_V4)nf_defrag_ipv4),)) -$(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK_IPV4, $(P_V4)nf_conntrack_ipv4),)) $(eval $(call nf_add,IPT_CONNTRACK,CONFIG_NETFILTER_XT_MATCH_STATE, $(P_XT)xt_state)) $(eval $(call nf_add,IPT_CONNTRACK,CONFIG_NETFILTER_XT_TARGET_CT, $(P_XT)xt_CT)) @@ -120,7 +118,6 @@ $(eval $(call nf_add,IPT_IPOPT,CONFIG_NETFILTER_XT_MATCH_STATISTIC, $(P_XT)xt_st . # ipv6 extra diff --git a/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch b/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch index ca3853aa19..bc3d1edeb6 100644 --- a/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch +++ b/target/linux/generic/backport-5.4/080-wireguard-0073-wireguard-selftests-import-harness-makefile-for-test.patch @@ -989,7 +989,7 @@ Signed-off-by: Jason A. Donenfeld +} --- /dev/null +++ b/tools/testing/selftests/wireguard/qemu/kernel.config -@@ -0,0 +1,86 @@ +@@ -0,0 +1,85 @@ +CONFIG_LOCALVERSION="" +CONFIG_NET=y +CONFIG_NETDEVICES=y @@ -1010,7 +1010,6 @@ Signed-off-by: Jason A. Donenfeld +CONFIG_NETFILTER_XTABLES=y +CONFIG_NETFILTER_XT_NAT=y +CONFIG_NETFILTER_XT_MATCH_LENGTH=y -+CONFIG_NF_CONNTRACK_IPV4=y This is part of the original patch we backport, so it should stay here. +CONFIG_NF_NAT_IPV4=y +CONFIG_IP_NF_IPTABLES=y +CONFIG_IP_NF_FILTER=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] fortify-headers: fix compilation with GCC 10.3
On 4/13/21 6:03 AM, Rosen Penev wrote: For some reason, fortified mempcpy does not work with GCC 10.3. It worked with GCC 10.2. Some output with tvheadend: error: 'mempcpy' undeclared here (not in a function); did you mean 'memccpy'? 144 | _FORTIFY_FN(mempcpy) void *mempcpy(void *__d, const void *__s, size_t __n) | ^~~ note: in definition of macro '_FORTIFY_ORIG' 20 | #define _FORTIFY_ORIG(p,fn) __typeof__(fn) __orig_##fn __asm__(_FORTIFY_STR(p) #fn) note: in expansion of macro '_FORTIFY_FN' 144 | _FORTIFY_FN(mempcpy) void *mempcpy(void *__d, const void *__s, size_t __n) In function 'mempcpy': error: called object '__orig_mempcpy' is not a function or function pointer 151 | return _orig_mempcpy(__d, __s, __n); Signed-off-by: Rosen Penev --- toolchain/fortify-headers/Makefile | 2 +- toolchain/fortify-headers/patches/010-mempcpy.patch | 11 +++ 2 files changed, 12 insertions(+), 1 deletion(-) create mode 100644 toolchain/fortify-headers/patches/010-mempcpy.patch Could you please share your OpenWrt configuration. With this configuration it is compiling for me: - hauke@hauke-t480:~/openwrt/openwrt$ ./scripts/diffconfig.sh CONFIG_TARGET_x86=y CONFIG_TARGET_x86_64=y CONFIG_TARGET_x86_64_DEVICE_generic=y CONFIG_DEVEL=y CONFIG_TOOLCHAINOPTS=y CONFIG_GCC_USE_VERSION_10=y # CONFIG_GCC_USE_VERSION_8 is not set CONFIG_GCC_VERSION="10.3.0" CONFIG_GCC_VERSION_10=y CONFIG_OPENSSL_ENGINE=y CONFIG_OPENSSL_OPTIMIZE_SPEED=y CONFIG_OPENSSL_WITH_ASM=y CONFIG_OPENSSL_WITH_CHACHA_POLY1305=y CONFIG_OPENSSL_WITH_CMS=y CONFIG_OPENSSL_WITH_DEPRECATED=y CONFIG_OPENSSL_WITH_ERROR_MESSAGES=y CONFIG_OPENSSL_WITH_PSK=y CONFIG_OPENSSL_WITH_SRP=y CONFIG_OPENSSL_WITH_TLS13=y CONFIG_PACKAGE_libopenssl=y CONFIG_PACKAGE_tvheadend=y CONFIG_PACKAGE_zlib=y CONFIG_TVHEADEND_CWC_SUPPORT=y CONFIG_TVHEADEND_DVBSCAN_SUPPORT=y CONFIG_TVHEADEND_LINUXDVB_SUPPORT=y This could be similar to the umdns problem which only shows up on 32 bit platforms. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gemini: Bump to kernel v5.10
On 4/13/21 10:02 AM, Linus Walleij wrote: On Mon, Apr 12, 2021 at 8:32 PM Christian Lamparter wrote: Hmm, when building this with the BUILDBOT config (CONFIG_BUILDBOT) and throw in the CONFIG_ALL_* for userspace + kernel modules for good measure. It fails with the default world build (without the V=s option) because the following symbols are not yet defined in either the generic or gemini-specific kernel config. CONFIG_COMPAT_32BIT_TIME CONFIG_PCIEASPM CONFIG_MTD_PHYSMAP_IXP4XX CONFIG_GPIO_CDEV_V1 CONFIG_CPU_THERMAL CONFIG_DMA_PERNUMA_CMA At least CPU_THERMAL is also a show-stopper for apm82181 5.10, so should these just be added added as either disabled (# CONFIG_ ... is not set) or in case of CONFIG_PCIEASPM=X (whatever the default is there) in target/linux/generic/config-5.10? Hm how do I help best with this? I don't always have the big picture of what OpenWRT needs, just working in my little corner :D I get as much as that we need to fix up target/linux/generic/config-5.10 as none of these config options pertain to Gemini per se. I suppose I should make a separate patch for that setting them all to "# is not set" simply. I am unsure about the procedure to test it though, also I always get a bit confused about how these configs are even generated. Yours, Linus Walleij Hi Linus, The target kernel configurations should be small and most of the generic settings should be done in the target/linux/generic/config-* config file. The target configuration only contains the extra configuration options or the options which are different. For example do you really need CONFIG_OABI_COMPAT for gemini? You should try to remove just most of the options which are not SoC specific. You can add new generic options to target/linux/generic/config-5.10 manually. For example "# CONFIG_MTD_PHYSMAP_IXP4XX is not set" would make sense there, if some target really needs it, the target kernel config can be activated for one target again. You can refresh your kernel configuration like this: make kernel_oldconfig CONFIG_TARGET=target and this: make kernel_oldconfig CONFIG_TARGET=subtarget To test the new kernel configuration, building with all kernel modules activated is helpful. You can do it by activation CONFIG_ALL_KMODS=y in the OpenWrt configuration. This is what the build bot uses: https://downloads.openwrt.org/snapshots/targets/gemini/generic/config.buildinfo Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] realtek: revert to "standard" management configuration
On 4/12/21 2:27 PM, Bjørn Mork wrote: The default management interface should be easy to find for users doing "blind" installations without console access. There are already multiple examples in the forum of advanced early adopters having problems locating the management interface after installing OpenWrt. Requiring tagged VLAN configration to access the initial management interface creates unnecessary hassle at best. Errors on the other end are close to impossible to debug without console access, even for advanced users. Less advanced users might have problems with the concept of VLAN tagging. Limiting management access to a single arbitrary port among up to 52 possible LAN ports makes this even more difficult, for no reason at all. Users might have reasons to use a different port for management. And they might even have difficulties using the OpenWrt selected one. The port might be the wrong type for their management link (e.g copper instead of fibre). Or they might depend on PoE power from a device which they can't reconfigure. User expectations will be based on - OpenWrt defaults for other devices - stock firmware default for the device in question - common default behaviour of similar devices All 3 cases point to a static IP address accessible on the native VLAN of any LAN port. A switch does not have any WAN port. All ports are LAN ports. This changes the default network configuration in line with these expectations. Cc: John Crispin Signed-off-by: Bjørn Mork Acked-by: Hauke Mehrtens --- .../realtek/base-files/etc/board.d/02_network | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index 1e199db5897f..44f1f0a7a5c1 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do lan_list="$lan_list $(basename $lan)" done ucidef_set_bridge_device switch -ucidef_set_interface_wan "$lan_list" -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100 +ucidef_set_interface_lan "$lan_list" lan_mac="" -wan_mac="" label_mac="" case $board in *) - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr) label_mac=$lan_mac ;; esac -lan_mac=$(macaddr_setbit_la $wan_mac) - ucidef_set_interface_macaddr "lan" $lan_mac -ucidef_set_interface_macaddr "wan" $wan_mac -ucidef_set_bridge_mac "$wan_mac" -ucidef_set_network_device_mac eth0 $wan_mac +ucidef_set_bridge_mac "$lan_mac" +ucidef_set_network_device_mac eth0 $lan_mac for lan in $lan_list; do ucidef_set_network_device_mac $lan $lan_mac + lan_mac=$(macaddr_setbit_la $lan_mac) lan_mac=$(macaddr_add $lan_mac 1) done [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: lantiq: upstream Linux efforts
Hi, On 4/11/21 7:51 PM, Martin Blumenstingl wrote: Hello everyone, you are included in this email because you have previously worked on patches for the Lantiq SoCs upstream. In the past updating the kernel version for the lantiq target in OpenWrt was an unpleasant task. There are many out-of-tree patches and some of them are breaking with newer kernel versions. To improve the situation I suggest using Rafał Miłecki's approach also for the lantiq target: He is submitting patches upstream, then backporting them to OpenWrt. That way backports to the -stable tree are for free. Other patches can simply be dropped during the next major kernel version update (instead of having to rework them every time...). I like this approach. This approach however only works when there are active contributors upstream. It brings the benefit of upstream code-reviews though - which in my experience improves the quality of the resulting code. Therefore I would like to know who is interested in upstreaming more patches and cleaning up some of the code which already exists upstream? Saying that you are not interested is fine, there is no pressure on anyone. Currently I do not plan to upstream anything for the lantiq target, but I can help someone when he works on this topic. Thanks for your work on the DSA switch and fixing all the bugs in there. What do you plan to do about the other patches still in the lantiq target like the PCIe driver? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] valgrind: Fix compile problem with MIPS soft float
valgrind does not compile any more when using a GCC 10 for MIPS with
soft float. Just remove the parts which are generating assembler which
would not work.
Signed-off-by: Hauke Mehrtens
---
.../patches/130-mips_fix_soft_float.patch | 68 +++
1 file changed, 68 insertions(+)
create mode 100644 package/devel/valgrind/patches/130-mips_fix_soft_float.patch
diff --git a/package/devel/valgrind/patches/130-mips_fix_soft_float.patch
b/package/devel/valgrind/patches/130-mips_fix_soft_float.patch
new file mode 100644
index ..05be099ca5e4
--- /dev/null
+++ b/package/devel/valgrind/patches/130-mips_fix_soft_float.patch
@@ -0,0 +1,68 @@
+Disable the valgrind helpers which use MIPS floating point operations
+when floating point support is deactivated in the toolchain.
+
+The fix from this commit is not sufficient any more:
+https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=869fcf2f6739f17b4eff36ec68f8dca826c8afeb
+
+This fixes the following error message when compiling with a GCC 10 MIPS BE 32:
+-
+../VEX/priv/guest_mips_helpers.c: In function
'mips_dirtyhelper_calculate_FCSR_fp32':
+../VEX/priv/guest_mips_helpers.c:640:10: error: the register '$f21' cannot be
clobbered in 'asm' for the current target
+ 640 | ASM_VOLATILE_UNARY32_DOUBLE(round.w.d)
+ | ^
+-
+
+--- a/VEX/priv/guest_mips_helpers.c
b/VEX/priv/guest_mips_helpers.c
+@@ -617,6 +617,7 @@ extern UInt mips_dirtyhelper_calculate_F
+flt_op inst )
+ {
+UInt ret = 0;
++#ifndef __mips_soft_float
+ #if defined(__mips__)
+VexGuestMIPS32State* guest_state = (VexGuestMIPS32State*)gs;
+UInt loFsVal, hiFsVal, loFtVal, hiFtVal;
+@@ -699,6 +700,7 @@ extern UInt mips_dirtyhelper_calculate_F
+ break;
+}
+ #endif
++#endif
+return ret;
+ }
+
+@@ -708,6 +710,7 @@ extern UInt mips_dirtyhelper_calculate_F
+flt_op inst )
+ {
+UInt ret = 0;
++#ifndef __mips_soft_float
+ #if defined(__mips__) && ((__mips == 64) || \
+ (defined(__mips_isa_rev) && (__mips_isa_rev >= 2)))
+ #if defined(VGA_mips32)
+@@ -860,6 +863,7 @@ extern UInt mips_dirtyhelper_calculate_F
+ break;
+}
+ #endif
++#endif
+return ret;
+ }
+
+--- a/coregrind/m_machine.c
b/coregrind/m_machine.c
+@@ -1828,6 +1828,7 @@ Bool VG_(machine_get_hwcaps)( void )
+we are using alternative way to determine FP mode */
+ ULong result = 0;
+
++#ifndef __mips_soft_float
+ if (!VG_MINIMAL_SETJMP(env_unsup_insn)) {
+__asm__ volatile (
+ ".set push\n\t"
+@@ -1845,6 +1846,9 @@ Bool VG_(machine_get_hwcaps)( void )
+
+fpmode = (result != 0x3FF0ull);
+ }
++#else
++ fpmode = 0;
++#endif
+ }
+
+ if (fpmode != 0)
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain: gcc: Update to version 10.3.0
Signed-off-by: Hauke Mehrtens
---
toolchain/gcc/Config.version| 2 +-
toolchain/gcc/common.mk | 4 ++--
.../patches/{10.2.0 => 10.3.0}/002-case_insensitive.patch | 0
.../gcc/patches/{10.2.0 => 10.3.0}/010-documentation.patch | 0
.../patches/{10.2.0 => 10.3.0}/110-Fix-MIPS-PR-84790.patch | 0
.../gcc/patches/{10.2.0 => 10.3.0}/230-musl_libssp.patch| 0
.../{10.2.0 => 10.3.0}/300-mips_Os_cpu_rtx_cost_model.patch | 0
.../{10.2.0 => 10.3.0}/810-arm-softfloat-libgcc.patch | 0
.../gcc/patches/{10.2.0 => 10.3.0}/820-libgcc_pic.patch | 0
.../{10.2.0 => 10.3.0}/840-armv4_pass_fix-v4bx_to_ld.patch | 0
.../patches/{10.2.0 => 10.3.0}/850-use_shared_libgcc.patch | 0
.../patches/{10.2.0 => 10.3.0}/851-libgcc_no_compat.patch | 0
.../patches/{10.2.0 => 10.3.0}/870-ppc_no_crtsavres.patch | 0
.../gcc/patches/{10.2.0 => 10.3.0}/881-no_tm_section.patch | 0
.../gcc/patches/{10.2.0 => 10.3.0}/900-bad-mips16-crt.patch | 0
.../gcc/patches/{10.2.0 => 10.3.0}/910-mbsd_multi.patch | 6 +++---
.../{10.2.0 => 10.3.0}/920-specs_nonfatal_getenv.patch | 0
.../{10.2.0 => 10.3.0}/930-fix-mips-noexecstack.patch | 0
.../931-libffi-fix-MIPS-softfloat-build-issue.patch | 0
...gotools-fix-compilation-when-making-cross-compiler.patch | 0
20 files changed, 6 insertions(+), 6 deletions(-)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/002-case_insensitive.patch
(100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/010-documentation.patch (100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/110-Fix-MIPS-PR-84790.patch
(100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/230-musl_libssp.patch (100%)
rename toolchain/gcc/patches/{10.2.0 =>
10.3.0}/300-mips_Os_cpu_rtx_cost_model.patch (100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/810-arm-softfloat-libgcc.patch
(100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/820-libgcc_pic.patch (100%)
rename toolchain/gcc/patches/{10.2.0 =>
10.3.0}/840-armv4_pass_fix-v4bx_to_ld.patch (100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/850-use_shared_libgcc.patch
(100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/851-libgcc_no_compat.patch
(100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/870-ppc_no_crtsavres.patch
(100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/881-no_tm_section.patch (100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/900-bad-mips16-crt.patch (100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/910-mbsd_multi.patch (96%)
rename toolchain/gcc/patches/{10.2.0 =>
10.3.0}/920-specs_nonfatal_getenv.patch (100%)
rename toolchain/gcc/patches/{10.2.0 => 10.3.0}/930-fix-mips-noexecstack.patch
(100%)
rename toolchain/gcc/patches/{10.2.0 =>
10.3.0}/931-libffi-fix-MIPS-softfloat-build-issue.patch (100%)
rename toolchain/gcc/patches/{10.2.0 =>
10.3.0}/960-gotools-fix-compilation-when-making-cross-compiler.patch (100%)
diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
index 967ce9e4892b..4e141477a516 100644
--- a/toolchain/gcc/Config.version
+++ b/toolchain/gcc/Config.version
@@ -14,7 +14,7 @@ config GCC_VERSION
string
default "7.5.0" if GCC_VERSION_7
default "9.3.0" if GCC_VERSION_9
- default "10.2.0"if GCC_VERSION_10
+ default "10.3.0"if GCC_VERSION_10
default "8.4.0"
config GCC_USE_IREMAP
diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
index 55fad1fcc48d..ef8fd9de47fd 100644
--- a/toolchain/gcc/common.mk
+++ b/toolchain/gcc/common.mk
@@ -40,8 +40,8 @@ ifeq ($(PKG_VERSION),9.3.0)
PKG_HASH:=71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1
endif
-ifeq ($(PKG_VERSION),10.2.0)
- PKG_HASH:=b8dd4368bb9c7f0b98188317ee0254dd8cc99d1e3a18d0ff146c855fe16c1d8c
+ifeq ($(PKG_VERSION),10.3.0)
+ PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344
endif
PATCH_DIR=../patches/$(GCC_VERSION)
diff --git a/toolchain/gcc/patches/10.2.0/002-case_insensitive.patch
b/toolchain/gcc/patches/10.3.0/002-case_insensitive.patch
similarity index 100%
rename from toolchain/gcc/patches/10.2.0/002-case_insensitive.patch
rename to toolchain/gcc/patches/10.3.0/002-case_insensitive.patch
diff --git a/toolchain/gcc/patches/10.2.0/010-documentation.patch
b/toolchain/gcc/patches/10.3.0/010-documentation.patch
similarity index 100%
rename from toolchain/gcc/patches/10.2.0/010-documentation.patch
rename to toolchain/gcc/patches/10.3.0/010-documentation.patch
diff --git a/toolchain/gcc/patches/10.2.0/110-Fix-MIPS-PR-84790.patch
b/toolchain/gcc/patches/10.3.0/110-Fix-MIPS-PR-84790.patch
similarity index 100%
rename from toolchain/gcc/patches/10.2.0/110-Fix-MIPS-PR-84790.patch
rename to toolchain/gcc/patches/10.3.0/110-Fix-MIPS-P
[PATCH] kernel: Activate FORTIFY_SOURCE for MIPS kernel 5.4
CONFIG_FORTIFY_SOURCE=y is already set in the generic kernel
configuration, but it is not working for MIPS on kernel 5.4, support for
MIPS was only added with kernel 5.5, other architectures like aarch64
support FORTIFY_SOURCE already since some time.
This patch adds support for FORTIFY_SOURCE to MIPS with kernel 5.4,
kernel 5.10 already supports this and needs no changes.
This backports one patch from kernel 5.5 and one fix from 5.8 to make
fortify source also work on our kernel 5.4.
The changes are not compatible with the
306-mips_mem_functions_performance.patch patch which was also removed
with kernel 5.10, probably because of the same problems. I think it is
not needed anyway as the compiler should automatically optimize the
calls to memset(), memcpy() and memmove() even when not explicitly
telling the compiler to use the build in variant.
Signed-off-by: Hauke Mehrtens
---
I would like to backport this to 21.02 too.
...-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch | 32 ++
...11-MIPS-Fix-exception-handler-memcpy.patch | 107 ++
.../301-mips_image_cmdline_hack.patch | 2 +-
...CPU_MIPS64-for-remaining-MIPS64-CPUs.patch | 2 +-
.../300-mips_expose_boot_raw.patch| 4 +-
.../306-mips_mem_functions_performance.patch | 106 -
6 files changed, 143 insertions(+), 110 deletions(-)
create mode 100644
target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
create mode 100644
target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
delete mode 100644
target/linux/generic/pending-5.4/306-mips_mem_functions_performance.patch
diff --git
a/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
new file mode 100644
index ..e02f10354376
--- /dev/null
+++
b/target/linux/generic/backport-5.4/310-mips-Kconfig-Add-ARCH_HAS_FORTIFY_SOURCE.patch
@@ -0,0 +1,32 @@
+From a8d2bb0559b5fefa5173ff4e7496cc6250db2c8a Mon Sep 17 00:00:00 2001
+From: Dmitry Korotin
+Date: Thu, 12 Sep 2019 22:53:45 +
+Subject: [PATCH] mips: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE
+
+FORTIFY_SOURCE detects various overflows at compile and run time.
+(6974f0c4555e ("include/linux/string.h:
+add the option of fortified string.h functions)
+
+ARCH_HAS_FORTIFY_SOURCE means that the architecture can be built and
+run with CONFIG_FORTIFY_SOURCE.
+
+Since mips can be built and run with that flag,
+select ARCH_HAS_FORTIFY_SOURCE as default.
+
+Signed-off-by: Dmitry Korotin
+Signed-off-by: Paul Burton
+Cc: linux-m...@vger.kernel.org
+---
+ arch/mips/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/mips/Kconfig
b/arch/mips/Kconfig
+@@ -7,6 +7,7 @@ config MIPS
+ select ARCH_CLOCKSOURCE_DATA
+ select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
+ select ARCH_HAS_UBSAN_SANITIZE_ALL
++ select ARCH_HAS_FORTIFY_SOURCE
+ select ARCH_SUPPORTS_UPROBES
+ select ARCH_USE_BUILTIN_BSWAP
+ select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
diff --git
a/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
new file mode 100644
index ..5a6725c7a072
--- /dev/null
+++
b/target/linux/generic/backport-5.4/311-MIPS-Fix-exception-handler-memcpy.patch
@@ -0,0 +1,107 @@
+From e01c91a360793298c9e1656a61faceff01487a43 Mon Sep 17 00:00:00 2001
+From: Ben Hutchings
+Date: Sat, 23 May 2020 23:50:34 +0800
+Subject: [PATCH] MIPS: Fix exception handler memcpy()
+
+The exception handler subroutines are declared as a single char, but
+when copied to the required addresses the copy length is 0x80.
+
+When range checks are enabled for memcpy() this results in a build
+failure, with error messages such as:
+
+In file included from arch/mips/mti-malta/malta-init.c:15:
+In function 'memcpy',
+inlined from 'mips_nmi_setup' at arch/mips/mti-malta/malta-init.c:98:2:
+include/linux/string.h:376:4: error: call to '__read_overflow2' declared with
attribute error: detected read beyond size of object passed as 2nd parameter
+ 376 |__read_overflow2();
+ |^~
+
+Change the declarations to use type char[].
+
+Signed-off-by: Ben Hutchings
+Signed-off-by: YunQiang Su
+Signed-off-by: Thomas Bogendoerfer
+---
+ arch/mips/loongson64/common/init.c | 4 ++--
+ arch/mips/mti-malta/malta-init.c | 8
+ arch/mips/pistachio/init.c | 8
+ 3 files changed, 10 insertions(+), 10 deletions(-)
+
+--- a/arch/mips/loongson64/common/init.c
b/arch/mips/loongson64/common/init.c
+@@ -18,10 +18,10 @@ unsigned long __maybe_unused _loongson_a
+ static void __init mips_nmi_setup(void)
+ {
+ void *base;
+- extern char except_vec_nmi;
++ extern char except_vec_nmi[];
+
+ base = (void *
Re: OpenWrt 21.02-rc1 (backport request, WireGuard, DSA roaming, iproute2 5.11)
On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: I found some serious regressions in the luci device config support. not sure yet how long it'll take to sort out. The netifd uci config grew so complex that it'll take a while to try all cases * changing interface settings after previously enabling certain options results in a brick * wireless networks with custom ifnames are improperly bridged * option ipv6 for ppp based protocols is broken because it clashes with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke Hi, There are requests for some pretty big changes to get merged into 21.02: Bring WireGuard in-tree for 21.02 #3960 https://github.com/openwrt/openwrt/pull/3960 Adding 63482 lines, mostly backported kernel patches. kernel: DSA roaming fix for Marvell mv88e6xxx https://git.openwrt.org/920eaab1d8179035d0ae1047e75cf9a50da6a6eb Adding 1180 lines of kernel patches build: make sure asm gets built with -DPIC https://git.openwrt.org/af22991e03cae55f96b06996df2ff16752cec5d5 iproute2: backport 5.11 update and improvements, related NLS fixes #4025 https://github.com/openwrt/openwrt/pull/4025 multiple patches for packages Are there any objections to backporting these changes? If no one complains I will merge them into 21.02 in on Friday. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 - realtek and mediatek targets
On 4/7/21 12:29 AM, Hauke Mehrtens wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: I found some serious regressions in the luci device config support. not sure yet how long it'll take to sort out. The netifd uci config grew so complex that it'll take a while to try all cases * changing interface settings after previously enabling certain options results in a brick * wireless networks with custom ifnames are improperly bridged * option ipv6 for ppp based protocols is broken because it clashes with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke Hi, Do we want to keep the realtek and mediatek targets in the 21.02 branch and release or do we want to remove them link the ipq807x target? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02-rc1
Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: > I found some serious regressions in the luci device config support. > not sure yet how long it'll take to sort out. The netifd uci config > grew so complex that it'll take a while to try all cases > * changing interface settings after previously enabling certain > options results in a brick > * wireless networks with custom ifnames are improperly bridged > * option ipv6 for ppp based protocols is broken because it clashes > with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/4] import libcap from packages feed
On 3/12/21 12:25 AM, Stijn Tintel wrote: Having libcap in OpenWrt base allows us to enable libcap support in other packages in base. In lldpd, this would allow the monitor process to drop its privileges instead of running as root, improving security. It will also allow us to drop our patch to disable libcap. I suspect some people might counter this by saying lldpd belongs in the packages feed; I strongly disagree as imo LLDP is an essential service for any network device, and especially switches. Even the cheapest managed switches support LLDP for more than 5 years already. Also see: https://github.com/openwrt/openwrt/pull/3823#issuecomment-795174537 I'll bump lldpd to the latest version after this series is merged, and debug the problem reported by John on the realtek target. Stijn Tintel (4): libcap: import from packages feed libcap: drop invalid copyright header libcap: bump to 2.48 lldpd: add libcap dependency Acked-by: Hauke Mehrtens I am not a lldpd user so I can not say if we should make it depend on libcap, but I saw some packages which has implicit dependencies. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu: armada 370: dts: fix the crypto engine
On 4/4/21 11:06 PM, Daniel González Cabanelas wrote: The crypto engine in Armada 370 SoCs is currently broken. It can be checked installing the required packages for testing openssl with hw acceleration: opkg install openssl-util opkg install kmod-cryptodev opkg install libopenssl-devcrypto After configuring /etc/ssl/openssl.cnf to let openssl use the crypto engine for digest operations, and performing some checksums.. md5sum 10M-file.bin openssl md5 10M-file.bin ...we can see they don't match. There might be an alignment or size constraint issue caused by the idle-sram area. Use the whole crypto sram and disable the idle-sram area to fix it. Also disable the idle support by adding the broken-idle property to prevent accessing the disabled idle-sram. We don't care about disabling the idle support since it is already broken in Armada 370 causing a huge performance loss because it disables permanently the L2 cache. This was reported in the Openwrt forum and elsewhere by Debian users with different board models. Is the L2 cache disabled without or with this patch? Signed-off-by: Daniel González Cabanelas Could you send this also to the upstream Linux maintainers, I would like to get their opinion on this and if this is correct it should also go into upstream Linux. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] umdns: fix compilation with GCC 10
On 8/31/20 10:51 PM, Rosen Penev wrote: On Aug 31, 2020, at 9:41 AM, Hauke Mehrtens wrote: On 8/31/20 11:35 AM, Petr Štetiar wrote: Rosen Penev [2020-08-31 02:06:50]: I compile with target GCC 10, not host. Then as you can see its probably some issue with GCC 10 for that target (which one is that?) or something like that, because I'm not able to trigger that with my GCC 10. Your proposed fix seems not correct as well, as blob_name is `const char*`, so I don't see a point of replacing strncpy with memcpy just to silence (most likely) bogus compiler error. If it's not false positive, then it needs to be fixed properly, not silenced by memcpy usage. -- ynezz Hi, I am seeing the same error when compiling for the lantiq target (big endian MIPS) with GCC 10.2.0 on current master. Kevin already did a change in this part of the code to fix a compile problem with GCC 10 on x86_64: https://git.openwrt.org/?p=project/mdnsd.git;a=commitdiff;h=eadfa26a5cf31e27f551c37c1362983e9db37c4d This commit is in master. Yes. But it fails on mips and mvebu. I see this problem also on MIPS malte 32 BE, but not on Armvirt 64. It looks like this only happens on 32 bit targets. I also tried the recent GCC 10.3.0-RC-20210401 and it shows the same problem. For me this also looks like a compiler error, but we probably need a workaround for it. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH keyring] usign: drop personal + outdated keys except 21.02
On 3/30/21 10:53 AM, Paul Spooren wrote: The ./usign folder is added to every OpenWrt image, it should only contain the most necessary keys. At this point it contains both a selection of personal developer keys and keys of EOL releases. Remove them all and only keep the 21.02 key. A future commit should add a "next release" key, which is later renamed to the next release name (e.g. 21.08). This approach should allow secure upgrade between releases. Signed-off-by: Paul Spooren --- This commit should be merged into a `openwrt-21.02` branch which is then selected by the 21.02 release. --- a/usign/b5043e70f9a75cde +++ /dev/null @@ -1,2 +0,0 @@ -untrusted comment: Public usign key for unattended snapshot builds -RWS1BD5w+adc3j2Hqg9+b66CvLR7NlHbsj7wjNVj0XGt/othDgIAOJS+ This key should probably not get deleted in master. I would prefer if we only copy some keys in package/system/openwrt-keyring/Makefile to the final image. This way we can keep the existing repository and do not have to branch it, but we can just add some keys to each release. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [21.02] cherry-pick missing kernel-symbol "RTC_DRV_JZ4740"
On 4/3/21 4:53 PM, Sven Roederer wrote: Happy easter all and thanks for branching 21.02. Holidays and lockdown give me some time to keep-up with OpenWrt. During this I found that 21.02 is still missing the kernel-CONFIG for RTC_DRV_JZ4740 Can someone cherry-pick 55ed4bf6d7bf80b705d015c3b73f772db485ba9c into 21.02 to fix? Best Sven Hi, This is backported now. Thanks for the hint. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH keyring] usign: drop personal + outdated keys except 21.02
On 3/30/21 10:53 AM, Paul Spooren wrote: The ./usign folder is added to every OpenWrt image, it should only contain the most necessary keys. At this point it contains both a selection of personal developer keys and keys of EOL releases. Remove them all and only keep the 21.02 key. A future commit should add a "next release" key, which is later renamed to the next release name (e.g. 21.08). This approach should allow secure upgrade between releases. Signed-off-by: Paul Spooren Acked-by: Hauke Mehrtens --- This commit should be merged into a `openwrt-21.02` branch which is then selected by the 21.02 release. I would like to remove the personal keys also from master and 19.07. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] kernel: Move CONFIG_USERIO to generic config
The CONFIG_USERIO option is unset in multiple target configurations. On the sunxi target it is activated. Move the kernel configuration option to the generic kernel configuration. Signed-off-by: Hauke Mehrtens --- target/linux/gemini/config-5.4 | 1 - target/linux/generic/config-5.10 | 1 + target/linux/generic/config-5.4 | 1 + target/linux/layerscape/armv8_64b/config-5.4 | 1 - target/linux/malta/config-5.10 | 1 - target/linux/malta/config-5.4| 1 - target/linux/omap/config-5.4 | 1 - target/linux/oxnas/config-5.10 | 1 - target/linux/oxnas/config-5.4| 1 - target/linux/rockchip/armv8/config-5.10 | 1 - target/linux/rockchip/armv8/config-5.4 | 1 - target/linux/tegra/config-5.4| 1 - target/linux/x86/config-5.10 | 1 - target/linux/x86/config-5.4 | 1 - target/linux/zynq/config-5.4 | 1 - 15 files changed, 2 insertions(+), 13 deletions(-) diff --git a/target/linux/gemini/config-5.4 b/target/linux/gemini/config-5.4 index 7cfdb3ccdbd0..c98f66148e0b 100644 --- a/target/linux/gemini/config-5.4 +++ b/target/linux/gemini/config-5.4 @@ -441,7 +441,6 @@ CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h" CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_UNWINDER_ARM=y CONFIG_USB_SUPPORT=y -# CONFIG_USERIO is not set CONFIG_USER_NS=y CONFIG_USE_OF=y CONFIG_UTS_NS=y diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index 3bf985dc4c71..457f62b195c0 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -6688,6 +6688,7 @@ CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y # CONFIG_USB_ZR364XX is not set # CONFIG_USELIB is not set # CONFIG_USERFAULTFD is not set +# CONFIG_USERIO is not set # CONFIG_USE_OF is not set # CONFIG_UTS_NS is not set # CONFIG_UWB is not set diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4 index 1dc97ce74598..baa26221c771 100644 --- a/target/linux/generic/config-5.4 +++ b/target/linux/generic/config-5.4 @@ -6242,6 +6242,7 @@ CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y # CONFIG_USB_ZR364XX is not set # CONFIG_USELIB is not set # CONFIG_USERFAULTFD is not set +# CONFIG_USERIO is not set # CONFIG_USE_OF is not set # CONFIG_UTS_NS is not set # CONFIG_UWB is not set diff --git a/target/linux/layerscape/armv8_64b/config-5.4 b/target/linux/layerscape/armv8_64b/config-5.4 index 172a9d43b107..304d40da949f 100644 --- a/target/linux/layerscape/armv8_64b/config-5.4 +++ b/target/linux/layerscape/armv8_64b/config-5.4 @@ -925,7 +925,6 @@ CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_UNIX_DIAG=y CONFIG_UNMAP_KERNEL_AT_EL0=y CONFIG_USB_SUPPORT=y -# CONFIG_USERIO is not set CONFIG_USER_NS=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y CONFIG_UTS_NS=y diff --git a/target/linux/malta/config-5.10 b/target/linux/malta/config-5.10 index 65e82eef8c6a..b32052ada2cb 100644 --- a/target/linux/malta/config-5.10 +++ b/target/linux/malta/config-5.10 @@ -275,7 +275,6 @@ CONFIG_TIMER_PROBE=y CONFIG_TREE_RCU=y CONFIG_TREE_SRCU=y CONFIG_USB_SUPPORT=y -# CONFIG_USERIO is not set CONFIG_USE_OF=y # CONFIG_VGA_CONSOLE is not set CONFIG_VM_EVENT_COUNTERS=y diff --git a/target/linux/malta/config-5.4 b/target/linux/malta/config-5.4 index 73f6965d01a9..9bcaae2208d9 100644 --- a/target/linux/malta/config-5.4 +++ b/target/linux/malta/config-5.4 @@ -329,7 +329,6 @@ CONFIG_TIMER_PROBE=y CONFIG_TREE_RCU=y CONFIG_TREE_SRCU=y CONFIG_USB_SUPPORT=y -# CONFIG_USERIO is not set CONFIG_USE_OF=y # CONFIG_VGA_CONSOLE is not set CONFIG_VM_EVENT_COUNTERS=y diff --git a/target/linux/omap/config-5.4 b/target/linux/omap/config-5.4 index aa15fa4ad9b4..3e2cc70d27b6 100644 --- a/target/linux/omap/config-5.4 +++ b/target/linux/omap/config-5.4 @@ -731,7 +731,6 @@ CONFIG_USB_PHY=y CONFIG_USB_SUPPORT=y CONFIG_USB_TI_CPPI41_DMA=y CONFIG_USB_TUSB_OMAP_DMA=y -# CONFIG_USERIO is not set CONFIG_USE_OF=y CONFIG_VFAT_FS=y CONFIG_VFP=y diff --git a/target/linux/oxnas/config-5.10 b/target/linux/oxnas/config-5.10 index 9fc311946954..9feea93b866f 100644 --- a/target/linux/oxnas/config-5.10 +++ b/target/linux/oxnas/config-5.10 @@ -343,7 +343,6 @@ CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h" CONFIG_UNWINDER_ARM=y # CONFIG_UNWINDER_FRAME_POINTER is not set CONFIG_USB_SUPPORT=y -# CONFIG_USERIO is not set CONFIG_USE_OF=y CONFIG_VERSATILE_FPGA_IRQ=y CONFIG_VERSATILE_FPGA_IRQ_NR=4 diff --git a/target/linux/oxnas/config-5.4 b/target/linux/oxnas/config-5.4 index 11f35e295a3a..c7ac30089261 100644 --- a/target/linux/oxnas/config-5.4 +++ b/target/linux/oxnas/config-5.4 @@ -340,7 +340,6 @@ CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h" CONFIG_UNWINDER_ARM=y # CONFIG_UNWINDER_FRAME_POINTER is not set CONFIG_USB_SUPPORT=y -# CONFIG_USERIO is not set CONFIG_USE_OF=y CONFIG_VERSATILE_FPGA_IRQ=y CONFIG_VERSATILE_FPGA_IRQ_NR=4 diff --git a/target/linux/rockchip/armv8/config
[PATCH 1/2] kernel: Deactivate CONFIG_VFIO in generic kernel config
Instead of deactivating this in every target config, deactivate it once in the generic kernel config. I was asked for this config option in a x86 64 build in OpenWrt 21.02. Signed-off-by: Hauke Mehrtens --- target/linux/generic/config-5.10| 1 + target/linux/generic/config-5.4 | 1 + target/linux/rockchip/armv8/config-5.10 | 1 - target/linux/rockchip/armv8/config-5.4 | 1 - target/linux/tegra/config-5.4 | 1 - 5 files changed, 2 insertions(+), 3 deletions(-) diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index cd096b2934cc..3bf985dc4c71 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -6709,6 +6709,7 @@ CONFIG_VDSO=y # CONFIG_VF610_ADC is not set # CONFIG_VF610_DAC is not set # CONFIG_VFAT_FS is not set +# CONFIG_VFIO is not set # CONFIG_VGASTATE is not set # CONFIG_VGA_ARB is not set # CONFIG_VGA_SWITCHEROO is not set diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4 index 0f6d3d7791d7..1dc97ce74598 100644 --- a/target/linux/generic/config-5.4 +++ b/target/linux/generic/config-5.4 @@ -6259,6 +6259,7 @@ CONFIG_VDSO=y # CONFIG_VF610_ADC is not set # CONFIG_VF610_DAC is not set # CONFIG_VFAT_FS is not set +# CONFIG_VFIO is not set # CONFIG_VGASTATE is not set # CONFIG_VGA_ARB is not set # CONFIG_VGA_SWITCHEROO is not set diff --git a/target/linux/rockchip/armv8/config-5.10 b/target/linux/rockchip/armv8/config-5.10 index 3a8b534bd57d..fedbeb5c4e54 100644 --- a/target/linux/rockchip/armv8/config-5.10 +++ b/target/linux/rockchip/armv8/config-5.10 @@ -645,7 +645,6 @@ CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PLATFORM=y # CONFIG_USERIO is not set -# CONFIG_VFIO is not set # CONFIG_VIRTIO_MENU is not set CONFIG_VMAP_STACK=y CONFIG_VM_EVENT_COUNTERS=y diff --git a/target/linux/rockchip/armv8/config-5.4 b/target/linux/rockchip/armv8/config-5.4 index 53adaf7760e0..a1663b19988f 100644 --- a/target/linux/rockchip/armv8/config-5.4 +++ b/target/linux/rockchip/armv8/config-5.4 @@ -617,7 +617,6 @@ CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PLATFORM=y # CONFIG_USERIO is not set -# CONFIG_VFIO is not set # CONFIG_VIRTIO_MENU is not set CONFIG_VMAP_STACK=y CONFIG_VM_EVENT_COUNTERS=y diff --git a/target/linux/tegra/config-5.4 b/target/linux/tegra/config-5.4 index 00fc11a69bae..c5e37f8d3bb0 100644 --- a/target/linux/tegra/config-5.4 +++ b/target/linux/tegra/config-5.4 @@ -553,7 +553,6 @@ CONFIG_USB_ULPI=y CONFIG_USB_ULPI_VIEWPORT=y # CONFIG_USERIO is not set CONFIG_USE_OF=y -# CONFIG_VFIO is not set CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_WATCHDOG_CORE=y -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mwlwifi: remove target dependency
On 3/21/21 10:17 PM, Daniel Golle wrote: Users complained that building images for various mvebu Linksys devices fails when using the ImageBuilder, it complains about the package 'mwlwifi-firmware-88w8964' not being found. Turns out the package builds fine in mvebu/cortex-a9 images build, but isn't built at all for arm/cortex-a9 packages. This is because we are using the SDK for bcm53xx/generic to build packages for arm/cortex-a9, hence the dependency for @TARGET_mvebu fails. Remove the target dependency as kmod-mwlwifi as well as firmware packages actually build fine on all platforms (and people might even want to use Marvell mPCIe Wifi on non-mvebu platforms). As a result, the missing 'mwlwifi-firmware-'* packages should become available for arm/cortex-a9 (and all other platforms). Does this happen for the kmod or only for the firmware package? If this only happens for the firmware package, does it help to add this to the package Makefile: PKG_FLAGS:=nonshared I think we only have this problems with the packages build by the 2. phase build bot which is shared between different targets with the same CPU. When we make it nonshared it should be build together with the target. We had a similar problems with the mtd package some time ago. We should check if there are more places with similar problem. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uhttpd v2] client: Always close connection with request body in case of error
When we run into an error like a 404 Not Found the request body is not
read and will be parsed as part of the next request. The next Request
will then fail because there is unexpected data in it.
When we run into such a problem with a request body close return an
error and close the connection. This should be easier than trying to
recover the state.
We saw this problem when /ubus/ was not installed, but the browser tried
to access it. Then uhttpd returned a 404, but the next request done in
this connection also failed with a HTTP 400, bad request.
Fixes: FS#3378
Signed-off-by: Hauke Mehrtens
---
client.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/client.c b/client.c
index 6233d01..451f90d 100644
--- a/client.c
+++ b/client.c
@@ -138,6 +138,7 @@ void uh_request_done(struct client *cl)
void __printf(4, 5)
uh_client_error(struct client *cl, int code, const char *summary, const char
*fmt, ...)
{
+ struct http_request *r = &cl->request;
va_list arg;
uh_http_header(cl, code, summary);
@@ -151,6 +152,16 @@ uh_client_error(struct client *cl, int code, const char
*summary, const char *fm
va_end(arg);
}
+ /* Close the connection even when keep alive is set, when it
+* contains a request body, as it was not read and we are
+* currently out of sync. The alternative would be to read and
+* discard the request body here.
+*/
+ if (r->transfer_chunked || r->content_length > 0) {
+ cl->state = CLIENT_STATE_CLOSE;
+ cl->request.connection_close = true;
+ }
+
uh_request_done(cl);
}
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/2] uhttpd: Execute uci commit and reload_config once
Instead of doing uci commit and reload_config for each setting do it
only once when one of these options was changed. This should make it a
little faster when both conditions are taken.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/files/ubus.default | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/package/network/services/uhttpd/files/ubus.default
b/package/network/services/uhttpd/files/ubus.default
index b218d3f85d11..474016c1c557 100644
--- a/package/network/services/uhttpd/files/ubus.default
+++ b/package/network/services/uhttpd/files/ubus.default
@@ -1,15 +1,17 @@
#!/bin/sh
+commit=0
+
if [ -z "$(uci -q get uhttpd.main.ubus_prefix)" ]; then
uci set uhttpd.main.ubus_prefix=/ubus
- uci commit uhttpd
- /etc/init.d/uhttpd reload
+ commit=1
fi
[ "$(uci -q get uhttpd.main.ubus_socket)" = "/var/run/ubus.sock" ] && {
uci set uhttpd.main.ubus_socket='/var/run/ubus/ubus.sock'
- uci commit uhttpd
- /etc/init.d/uhttpd reload
+ commit=1
}
+[ "$commit" = 1 ] && uci commit uhttpd && /etc/init.d/uhttpd reload
+
exit 0
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] uhttpd: Reload config after uhttpd-mod-ubus was added
On 3/20/21 2:05 PM, Jo-Philipp Wich wrote:
Hi Hauke,
thanks for looking into it!
I have a couple of remarks...
[...]
[ "$(uci -q get uhttpd.main.ubus_socket)" = "/var/run/ubus.sock" ] && {
uci set uhttpd.main.ubus_socket='/var/run/ubus/ubus.sock'
uci commit uhttpd
+ reload_config
That might reload other, unrelated changes. It likely isn't that much of
a problem in practise for most users but could interfere with other
provisioning setups or custom logic.
I think it is better if we simply perform a selective /etc/init.d/uhttpd
reload call here.
thanks for the hint, I updated the code.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/2] uhttpd: Reload config after uhttpd-mod-ubus was added
Without this change the config is only committed, but the uhttpd daemon
is not reloaded. This reload is needed to apply the config. Without the
reload of uhttpd, the ubus server is not available over http and returns
a Error 404.
This caused problems when installing luci on the snapshots and
accessing it without reloading uhttpd.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/Makefile | 2 +-
package/network/services/uhttpd/files/ubus.default | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/package/network/services/uhttpd/Makefile
b/package/network/services/uhttpd/Makefile
index 796eb6129849..28a817d2e0d6 100644
--- a/package/network/services/uhttpd/Makefile
+++ b/package/network/services/uhttpd/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uhttpd
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/uhttpd.git
diff --git a/package/network/services/uhttpd/files/ubus.default
b/package/network/services/uhttpd/files/ubus.default
index ca9e72a3150a..b218d3f85d11 100644
--- a/package/network/services/uhttpd/files/ubus.default
+++ b/package/network/services/uhttpd/files/ubus.default
@@ -3,11 +3,13 @@
if [ -z "$(uci -q get uhttpd.main.ubus_prefix)" ]; then
uci set uhttpd.main.ubus_prefix=/ubus
uci commit uhttpd
+ /etc/init.d/uhttpd reload
fi
[ "$(uci -q get uhttpd.main.ubus_socket)" = "/var/run/ubus.sock" ] && {
uci set uhttpd.main.ubus_socket='/var/run/ubus/ubus.sock'
uci commit uhttpd
+ /etc/init.d/uhttpd reload
}
exit 0
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uhttpd] client: Always close connection with request body in case of error
On 3/20/21 8:28 PM, Hauke Mehrtens wrote:
When we run into an error like a 404 Not Found the request body is not
read and will be parsed as part of the next request. The next Request
will then fail because there is unexpected data in it.
When we run into such a problem with a request body close return an
error and close the connection. This should be easier than trying to
recover the state.
We saw this problem when /ubus/ was not installed, but the browser tried
to access it. Then uhttpd returned a 404, but the next request done in
this connection also failed with a HTTP 400, bad request.
Signed-off-by: Hauke Mehrtens
This should fix the following bug report:
https://bugs.openwrt.org/index.php?do=details&task_id=3378
---
client.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/client.c b/client.c
index 6233d01..1d337f3 100644
--- a/client.c
+++ b/client.c
@@ -138,6 +138,7 @@ void uh_request_done(struct client *cl)
void __printf(4, 5)
uh_client_error(struct client *cl, int code, const char *summary, const char
*fmt, ...)
{
+ struct http_request *r = &cl->request;
va_list arg;
uh_http_header(cl, code, summary);
@@ -151,6 +152,11 @@ uh_client_error(struct client *cl, int code, const char
*summary, const char *fm
va_end(arg);
}
+ if (r->transfer_chunked || r->content_length > 0) {
+ cl->state = CLIENT_STATE_CLOSE;
+ cl->request.connection_close = true;
+ }
+
uh_request_done(cl);
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uhttpd] client: Always close connection with request body in case of error
When we run into an error like a 404 Not Found the request body is not
read and will be parsed as part of the next request. The next Request
will then fail because there is unexpected data in it.
When we run into such a problem with a request body close return an
error and close the connection. This should be easier than trying to
recover the state.
We saw this problem when /ubus/ was not installed, but the browser tried
to access it. Then uhttpd returned a 404, but the next request done in
this connection also failed with a HTTP 400, bad request.
Signed-off-by: Hauke Mehrtens
---
client.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/client.c b/client.c
index 6233d01..1d337f3 100644
--- a/client.c
+++ b/client.c
@@ -138,6 +138,7 @@ void uh_request_done(struct client *cl)
void __printf(4, 5)
uh_client_error(struct client *cl, int code, const char *summary, const char
*fmt, ...)
{
+ struct http_request *r = &cl->request;
va_list arg;
uh_http_header(cl, code, summary);
@@ -151,6 +152,11 @@ uh_client_error(struct client *cl, int code, const char
*summary, const char *fm
va_end(arg);
}
+ if (r->transfer_chunked || r->content_length > 0) {
+ cl->state = CLIENT_STATE_CLOSE;
+ cl->request.connection_close = true;
+ }
+
uh_request_done(cl);
}
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] uhttpd: Reload config after uhttpd-mod-ubus was added
On 3/20/21 1:32 PM, Hauke Mehrtens wrote:
Without this change the config is only committed, but the uhttpd daemon
is not reloaded. This reload is needed to apply the config. Without the
reload of uhttpd, the ubus server is not available over http and returns
a Error 404.
This caused problems when installing luci on the snapshots and
accessing it without reloading uhttpd.
There is another bug in uhttpd that it does not discard the request data
when it returned a http error 404 for a post request and interpret it as
part of the next request on the same TCP connection.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/files/ubus.default | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/network/services/uhttpd/files/ubus.default
b/package/network/services/uhttpd/files/ubus.default
index ca9e72a3150a..35724ba57e03 100644
--- a/package/network/services/uhttpd/files/ubus.default
+++ b/package/network/services/uhttpd/files/ubus.default
@@ -3,11 +3,13 @@
if [ -z "$(uci -q get uhttpd.main.ubus_prefix)" ]; then
uci set uhttpd.main.ubus_prefix=/ubus
uci commit uhttpd
+ reload_config
fi
[ "$(uci -q get uhttpd.main.ubus_socket)" = "/var/run/ubus.sock" ] && {
uci set uhttpd.main.ubus_socket='/var/run/ubus/ubus.sock'
uci commit uhttpd
+ reload_config
}
exit 0
I will also increase the PKG_RELEASE.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] uhttpd: Execute uci commit and reload_config once
Instead of doing uci commit and reload_config for each setting do it
only once when one of these options was changed. This should make it a
little faster when both conditions are taken.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/files/ubus.default | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/package/network/services/uhttpd/files/ubus.default
b/package/network/services/uhttpd/files/ubus.default
index 35724ba57e03..019f25ae6288 100644
--- a/package/network/services/uhttpd/files/ubus.default
+++ b/package/network/services/uhttpd/files/ubus.default
@@ -1,15 +1,17 @@
#!/bin/sh
+commit=0
+
if [ -z "$(uci -q get uhttpd.main.ubus_prefix)" ]; then
uci set uhttpd.main.ubus_prefix=/ubus
- uci commit uhttpd
- reload_config
+ commit=1
fi
[ "$(uci -q get uhttpd.main.ubus_socket)" = "/var/run/ubus.sock" ] && {
uci set uhttpd.main.ubus_socket='/var/run/ubus/ubus.sock'
- uci commit uhttpd
- reload_config
+ commit=1
}
+[ "$commit" = 1 ] && uci commit uhttpd && reload_config
+
exit 0
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] uhttpd: Reload config after uhttpd-mod-ubus was added
Without this change the config is only committed, but the uhttpd daemon
is not reloaded. This reload is needed to apply the config. Without the
reload of uhttpd, the ubus server is not available over http and returns
a Error 404.
This caused problems when installing luci on the snapshots and
accessing it without reloading uhttpd.
There is another bug in uhttpd that it does not discard the request data
when it returned a http error 404 for a post request and interpret it as
part of the next request on the same TCP connection.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/files/ubus.default | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/network/services/uhttpd/files/ubus.default
b/package/network/services/uhttpd/files/ubus.default
index ca9e72a3150a..35724ba57e03 100644
--- a/package/network/services/uhttpd/files/ubus.default
+++ b/package/network/services/uhttpd/files/ubus.default
@@ -3,11 +3,13 @@
if [ -z "$(uci -q get uhttpd.main.ubus_prefix)" ]; then
uci set uhttpd.main.ubus_prefix=/ubus
uci commit uhttpd
+ reload_config
fi
[ "$(uci -q get uhttpd.main.ubus_socket)" = "/var/run/ubus.sock" ] && {
uci set uhttpd.main.ubus_socket='/var/run/ubus/ubus.sock'
uci commit uhttpd
+ reload_config
}
exit 0
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] kernel: add exfat again
On 3/13/21 6:52 AM, Rosen Penev wrote: With kernel 5.10, exfat is out of staging and in tree. Added small hack to make it work with kernel 5.4 as well. Signed-off-by: Rosen Penev --- package/kernel/linux/modules/fs.mk | 20 1 file changed, 20 insertions(+) When building this on the MIPS Malta 32bit BE target with kernel 5.4 I am missing options for the following kernel configuration options: Prohibit mounting of fat/vfat filesystems by exFAT (EXFAT_DONT_MOUNT_VFAT) [Y/n/?] (NEW) enable discard support (EXFAT_DISCARD) [Y/n/?] (NEW) enable delayed sync (EXFAT_DELAYED_SYNC) [N/y/?] (NEW) enable kernel debug features via ioctl (EXFAT_KERNEL_DEBUG) [N/y/?] (NEW) print debug messages (EXFAT_DEBUG_MSG) [N/y/?] (NEW) Default codepage for exFAT (EXFAT_DEFAULT_CODEPAGE) [437] (NEW) This should probably be added to the generic kernel configuration. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mediatek: Fix writing U-Boot env on Buffalo WSR-2533DHP2
This fixes writing to the U-Boot environment by making the partition
writable and setting the correct flash sector size of 128K.
Signed-off-by: Hauke Mehrtens
---
package/boot/uboot-envtools/files/mediatek| 2 +-
target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/package/boot/uboot-envtools/files/mediatek
b/package/boot/uboot-envtools/files/mediatek
index ce28fb31cbca..4db1c6ef4d96 100644
--- a/package/boot/uboot-envtools/files/mediatek
+++ b/package/boot/uboot-envtools/files/mediatek
@@ -25,7 +25,7 @@ case "$board" in
ubootenv_add_uci_config "$envdev" "0x8" "0x8" "0x8" "1"
;;
buffalo,wsr-2533dhp2)
- ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1000" "0x1000"
+ ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1000" "0x2"
;;
esac
diff --git a/target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
b/target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
index 397be1445bbf..ce5cd1c9be00 100644
--- a/target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
+++ b/target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
@@ -269,7 +269,6 @@
partition@14 {
label = "Config";
reg = <0x14 0x8>;
- read-only;
};
factory: partition@1c {
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 5/5] mediatek: Add support for Buffalo WSR-2533DHP2
On 3/12/21 9:55 PM, Adrian Schmutzler wrote:
Hi,
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Hauke Mehrtens
Sent: Mittwoch, 10. März 2021 00:52
To: openwrt-devel@lists.openwrt.org
Cc: musashino.o...@gmail.com; Hauke Mehrtens
Subject: [PATCH 5/5] mediatek: Add support for Buffalo WSR-2533DHP2
[...]
+ leds {
+ compatible = "gpio-leds";
+
+ wireless_amber {
+ label = "wsr-2533dhp2:amber:wireless";
+ gpios = <&pio 2 GPIO_ACTIVE_HIGH>;
+ };
Consider removing the model from the labels here and below ...
I removed the "wsr-2533dhp2:" prefix from the led labels.
I also switched from gpio-keys-polled to gpio-keys, IRQs for GPIOs are
working.
One of the buttons is a tri-state switch connected to GPIO 1 and 16, it
used the same Linux code BTN_0 for both GPIOs before, I checked this to
BTN_0 and BTN_1 now.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/5] mediatek: Add support for Buffalo WSR-2533DHP2
On 3/10/21 10:03 AM, INAGAKI Hiroshi wrote: Hi Hauke, On 2021/03/10 8:52, Hauke Mehrtens wrote: These patches are adding support for different TRX magics and later support for the Buffalo WSR-2533DHP2. This was developed mostly by INAGAKI Hiroshi and I did some fixes and cleaned the patches up in the last days. I added the two patches also for kernel 5.4, I needed this in the beginning till I found out why kernel 5.10 is not booting. Now kernel 5.10 is working fine with this device. I can also remove the kernel 5.4 patches. @Hiroshi: Could you please give your Signed-off-by if you are fine with this. I'm fine, thank you :) Signed-off-by: INAGAKI Hiroshi BTW, the word after the prefix in the commit titles may need to be lower-case[1]. [1]: https://openwrt.org/submitting-patches#submission_guidelines Thanks, I added your Signed-off-by and fixed the commit messages. Hauke OpenPGP_0x93DD20630910B515.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/5] mediatek: Add support for Buffalo WSR-2533DHP2
From: INAGAKI Hiroshi
This adds support for the Buffalo WSR-2533DHP2.
The device uses the Broadcom TRX image format with a special magic. To
be able to boot the images or load them they have to be wrapped with
different headers depending how it is loaded.
There are multiple ways to install OpenWrt on this device.
1. Boot ramdisk from U-Boot.
This will load the image and not write it into the flash.
1. Stop boot menu with "space" key
2. Select "System Load Linux to SDRAM via TFTP."
3. Load this image:
openwrt-mediatek-mt7622-buffalo_wsr-2533dhp2-initramfs-kernel.bin
4. The system boots the image
2. Write to flash from U-Boot
-
This will load the image over tftp and directly write it into the flash.
1. Stop boot menu with "space" key
2. Select "System Load Linux Kernel then write to Flash via TFTP."
3. Load this image:
openwrt-mediatek-mt7622-buffalo_wsr-2533dhp2-squashfs-factory-uboot.bin
4. The system writes this image into the flash and boots into it.
3. Write to flash from Web UI
-
This will load the image over over the Web UI and write it into the flash
1. Open the Web UI
2. Go to "管理" -> "ファームウェア更新"
3. Select "ローカルファイル指定" and click "更新実行"
4. Load this image:
openwrt-mediatek-mt7622-buffalo_wsr-2533dhp2-squashfs-factory.bin
5. The system writes this image into the flash and boots into it.
Specifications (v1)
---
* SoC: MT7622 (4x4 2.4 GHz Wifi)
* Wifi: MT7615 (4x4 5 GHz Wifi)
* Flash: Winbond W29N01HZ 128MB SLC NAND
* Ethernet: Realtek RTL8367S (4 x 1GBit/s, SoC via 2.5GBit/s)
Co-Developed-by: Hauke Mehrtens
Signed-off-by: Hauke Mehrtens
---
package/boot/uboot-envtools/files/mediatek| 3 +
package/system/mtd/src/Makefile | 1 +
.../dts/mt7622-buffalo-wsr-2533dhp2.dts | 336 ++
target/linux/mediatek/image/mt7622.mk | 64
.../mt7622/base-files/etc/board.d/02_network | 4 +
.../base-files/etc/uci-defaults/09_fix_crc| 10 +
.../mt7622/base-files/lib/upgrade/buffalo.sh | 126 +++
.../mt7622/base-files/lib/upgrade/platform.sh | 15 +
target/linux/mediatek/mt7622/config-5.10 | 1 +
9 files changed, 560 insertions(+)
create mode 100644 target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
create mode 100644
target/linux/mediatek/mt7622/base-files/etc/uci-defaults/09_fix_crc
create mode 100644
target/linux/mediatek/mt7622/base-files/lib/upgrade/buffalo.sh
diff --git a/package/boot/uboot-envtools/files/mediatek
b/package/boot/uboot-envtools/files/mediatek
index ba6d780c4926..ce28fb31cbca 100644
--- a/package/boot/uboot-envtools/files/mediatek
+++ b/package/boot/uboot-envtools/files/mediatek
@@ -24,6 +24,9 @@ case "$board" in
ubootenv_add_uci_config "$envdev" "0x0" "0x8" "0x8" "1"
ubootenv_add_uci_config "$envdev" "0x8" "0x8" "0x8" "1"
;;
+buffalo,wsr-2533dhp2)
+ ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1000" "0x1000"
+ ;;
esac
config_load ubootenv
diff --git a/package/system/mtd/src/Makefile b/package/system/mtd/src/Makefile
index 6baea52b8f03..e204ecb221d5 100644
--- a/package/system/mtd/src/Makefile
+++ b/package/system/mtd/src/Makefile
@@ -12,6 +12,7 @@ obj.gemini = $(obj.wrgg)
obj.brcm = trx.o
obj.bcm47xx = $(obj.brcm)
obj.bcm53xx = $(obj.brcm) $(obj.seama)
+obj.mediatek = $(obj.brcm)
obj.bcm63xx = imagetag.o
obj.bmips = imagetag.o
obj.ramips = $(obj.seama) $(obj.tpl) $(obj.wrg) linksys_bootcount.o
diff --git a/target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
b/target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
new file mode 100644
index ..198c78476d33
--- /dev/null
+++ b/target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts
@@ -0,0 +1,336 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+#include
+#include
+
+#include "mt7622.dtsi"
+#include "mt6380.dtsi"
+
+/ {
+ model = "Buffalo WSR-2533DHP2";
+ compatible = "buffalo,wsr-2533dhp2", "mediatek,mt7622";
+
+ aliases {
+ serial0 = &uart0;
+ led-boot = &power_green;
+ led-failsafe = &power_amber;
+ led-running = &power_green;
+ led-upgrade = &power_green;
+ };
+
+ chosen {
+ bootargs = "earlycon=uart8250,mmio32,0x11002000
console=ttyS0,115200n8 swiotlb=512";
+ };
+
+ memory {
+ reg = <0 0x4000 0 0x0F00>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ wireless_amber {
+ label = &quo
[PATCH 1/5] mediatek: Fix mtk parallel nand driver
This fixes some bugs in the mtk parallel nand driver introduced in 5.10.
This patch was send upstream.
Signed-off-by: Hauke Mehrtens
---
...Fix-WAITRDY-break-condition-and-time.patch | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
target/linux/mediatek/patches-5.10/360-mtd-rawnand-mtk-Fix-WAITRDY-break-condition-and-time.patch
diff --git
a/target/linux/mediatek/patches-5.10/360-mtd-rawnand-mtk-Fix-WAITRDY-break-condition-and-time.patch
b/target/linux/mediatek/patches-5.10/360-mtd-rawnand-mtk-Fix-WAITRDY-break-condition-and-time.patch
new file mode 100644
index ..340e80f67b12
--- /dev/null
+++
b/target/linux/mediatek/patches-5.10/360-mtd-rawnand-mtk-Fix-WAITRDY-break-condition-and-time.patch
@@ -0,0 +1,36 @@
+From 4a4854761c9dedeedbf72c25d1317ab2e7600d4f Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens
+Date: Mon, 8 Mar 2021 23:16:17 +0100
+Subject: [PATCH] mtd: rawnand: mtk: Fix WAITRDY break condition and timeout
+
+This fixes NAND_OP_WAITRDY_INSTR operation in the driver. Without this
+change the driver waits till the system is busy, but we should wait till
+the busy flag is cleared. The readl_poll_timeout() function gets a break
+condition, not a wait condition.
+
+In addition fix the timeout. The timeout_ms is given in ms, but the
+readl_poll_timeout() function takes the timeout in us. Multiple the
+given timeout by 1000 to convert it.
+
+Without this change, the driver does not work at all, it doesn't even
+identify the NAND chip.
+
+Fixes: 5197360f9e09 ("mtd: rawnand: mtk: Convert the driver to exec_op()")
+Signed-off-by: Hauke Mehrtens
+---
+ drivers/mtd/nand/raw/mtk_nand.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mtd/nand/raw/mtk_nand.c
b/drivers/mtd/nand/raw/mtk_nand.c
+@@ -488,8 +488,8 @@ static int mtk_nfc_exec_instr(struct nan
+ return 0;
+ case NAND_OP_WAITRDY_INSTR:
+ return readl_poll_timeout(nfc->regs + NFI_STA, status,
+-status & STA_BUSY, 20,
+-instr->ctx.waitrdy.timeout_ms);
++!(status & STA_BUSY), 20,
++instr->ctx.waitrdy.timeout_ms * 1000);
+ default:
+ break;
+ }
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/5] mediatek: Support non standard trx magic values
Buffalo uses the TRX format with a different magic, add support for
this.
It is planned to send these patches upstream.
Cc: Rafał Miłecki
Signed-off-by: Hauke Mehrtens
---
...trx-Allow-to-specify-trx-magic-in-DT.patch | 75 +++
...ove-dependency-to-BRCM-architectures.patch | 23 ++
...trx-Allow-to-specify-trx-magic-in-DT.patch | 75 +++
...ove-dependency-to-BRCM-architectures.patch | 23 ++
4 files changed, 196 insertions(+)
create mode 100644
target/linux/mediatek/patches-5.10/350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch
create mode 100644
target/linux/mediatek/patches-5.10/351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch
create mode 100644
target/linux/mediatek/patches-5.4/0350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch
create mode 100644
target/linux/mediatek/patches-5.4/0351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch
diff --git
a/target/linux/mediatek/patches-5.10/350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch
b/target/linux/mediatek/patches-5.10/350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch
new file mode 100644
index ..4db51a88ad19
--- /dev/null
+++
b/target/linux/mediatek/patches-5.10/350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch
@@ -0,0 +1,75 @@
+From 0600e3d81628002a5cd80cf83ee454851b0063c0 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens
+Date: Sun, 7 Mar 2021 18:19:26 +0100
+Subject: mtd: parsers: trx: Allow to specify trx-magic in DT
+
+Buffalo uses a different TRX magic for every device, to be able to use
+this trx parser, make it possible to specify the TRX magic in device
+tree. If no TRX magic is specified in device tree, the standard value
+will be used. This value should only be specified if a vendor chooses to
+use a non standard TRX magic.
+
+Signed-off-by: Hauke Mehrtens
+---
+ .../bindings/mtd/partitions/brcm,trx.txt | 5 +
+ drivers/mtd/parsers/parser_trx.c | 21 ++-
+ 2 files changed, 25 insertions(+), 1 deletion(-)
+
+--- a/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt
b/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt
+@@ -28,6 +28,11 @@ detected by a software parsing TRX heade
+ Required properties:
+ - compatible : (required) must be "brcm,trx"
+
++Optional properties:
++
++- trx-magic: TRX magic, if it is different from the default magic
++ 0x30524448 as a u32.
++
+ Example:
+
+ flash@0 {
+--- a/drivers/mtd/parsers/parser_trx.c
b/drivers/mtd/parsers/parser_trx.c
+@@ -74,6 +74,24 @@ out_default:
+ return "rootfs";
+ }
+
++static uint32_t parser_trx_get_magic(struct mtd_info *mtd)
++{
++ uint32_t trx_magic = TRX_MAGIC;
++ struct device_node *np;
++ int err;
++
++ np = mtd_get_of_node(mtd);
++ if (!np)
++ return trx_magic;
++
++ /* Get different magic from device tree if specified */
++ err = of_property_read_u32(np, "trx-magic", &trx_magic);
++ if (err != 0 && err != -EINVAL)
++ pr_err("failed to parse \"trx-magic\" DT attribute, use
default: %d\n", err);
++
++ return trx_magic;
++}
++
+ static int parser_trx_parse(struct mtd_info *mtd,
+ const struct mtd_partition **pparts,
+ struct mtd_part_parser_data *data)
+@@ -83,6 +101,7 @@ static int parser_trx_parse(struct mtd_i
+ struct trx_header trx;
+ size_t bytes_read;
+ uint8_t curr_part = 0, i = 0;
++ uint32_t trx_magic = parser_trx_get_magic(mtd);
+ int err;
+
+ parts = kcalloc(TRX_PARSER_MAX_PARTS, sizeof(struct mtd_partition),
+@@ -97,7 +116,7 @@ static int parser_trx_parse(struct mtd_i
+ return err;
+ }
+
+- if (trx.magic != TRX_MAGIC) {
++ if (trx.magic != trx_magic) {
+ kfree(parts);
+ return -ENOENT;
+ }
diff --git
a/target/linux/mediatek/patches-5.10/351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch
b/target/linux/mediatek/patches-5.10/351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch
new file mode 100644
index ..5f06cad4cd8d
--- /dev/null
+++
b/target/linux/mediatek/patches-5.10/351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch
@@ -0,0 +1,23 @@
+From 63f0cf88ab5461acb0911252f12bb94ee3bf05a2 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens
+Date: Sun, 7 Mar 2021 18:23:29 +0100
+Subject: mtd: parsers: Remove dependency to BRCM architectures
+
+Buffalo uses the TRX partition format also on Mediatek SoCs.
+
+Signed-off-by: Hauke Mehrtens
+---
+ drivers/mtd/parsers/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/parsers/Kconfig
b/drivers/mtd/parsers/Kconfig
+@@ -121,7 +121,7 @@ config MTD_AFS_PARTS
+
+ config MTD_PARSER_TRX
+ tristate "Parser for TRX format partitions"
+- depends
[PATCH 3/5] mtd: Add option for TRX magic to fixtrx
From: INAGAKI Hiroshi
Buffalo uses the TRX header with a different magic and even changes this
magic with different devices. This change allows to specify the header
to use as a command line argument.
This is needed for the Buffalo WSR-2533DHP2 based on mt7622.
Co-Developed-by: Hauke Mehrtens
Signed-off-by: Hauke Mehrtens
---
package/system/mtd/src/mtd.c | 14 --
package/system/mtd/src/mtd.h | 1 +
package/system/mtd/src/trx.c | 8
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c
index 9baed3fd5e99..fc7071d94083 100644
--- a/package/system/mtd/src/mtd.c
+++ b/package/system/mtd/src/mtd.c
@@ -94,6 +94,7 @@ int mtdsize = 0;
int erasesize = 0;
int jffs2_skip_bytes=0;
int mtdtype = 0;
+uint32_t opt_trxmagic = TRX_MAGIC;
int mtd_open(const char *mtd, bool block)
{
@@ -205,7 +206,7 @@ image_check(int imagefd, const char *mtd)
magic = ((uint32_t *)buf)[0];
- if (be32_to_cpu(magic) == TRX_MAGIC)
+ if (be32_to_cpu(magic) == opt_trxmagic)
imageformat = MTD_IMAGE_FORMAT_TRX;
else if (be32_to_cpu(magic) == SEAMA_MAGIC)
imageformat = MTD_IMAGE_FORMAT_SEAMA;
@@ -810,6 +811,7 @@ static void usage(void)
"-l the length of data that we want to
dump\n");
if (mtd_fixtrx) {
fprintf(stderr,
+ "-M magic number of the image header in
the partition (for fixtrx)\n"
"-o offset offset of the image header in the
partition(for fixtrx)\n");
}
if (mtd_fixtrx || mtd_fixseama || mtd_fixwrg || mtd_fixwrgg) {
@@ -877,7 +879,7 @@ int main (int argc, char **argv)
#ifdef FIS_SUPPORT
"F:"
#endif
- "frnqe:d:s:j:p:o:c:t:l:")) != -1)
+ "frnqe:d:s:j:p:o:c:t:l:M:")) != -1)
switch (ch) {
case 'f':
force = 1;
@@ -929,6 +931,14 @@ int main (int argc, char **argv)
usage();
}
break;
+ case 'M':
+ errno = 0;
+ opt_trxmagic = strtoul(optarg, 0, 0);
+ if (errno) {
+ fprintf(stderr, "-M: illegal numeric
string\n");
+ usage();
+ }
+ break;
case 'o':
errno = 0;
offset = strtoul(optarg, 0, 0);
diff --git a/package/system/mtd/src/mtd.h b/package/system/mtd/src/mtd.h
index fe716b715090..d2facc8e3b94 100644
--- a/package/system/mtd/src/mtd.h
+++ b/package/system/mtd/src/mtd.h
@@ -12,6 +12,7 @@
extern int quiet;
extern int mtdsize;
extern int erasesize;
+extern uint32_t opt_trxmagic;
extern int mtd_open(const char *mtd, bool block);
extern int mtd_check_open(const char *mtd);
diff --git a/package/system/mtd/src/trx.c b/package/system/mtd/src/trx.c
index 3e3b5d220c62..d7c5d832c42d 100644
--- a/package/system/mtd/src/trx.c
+++ b/package/system/mtd/src/trx.c
@@ -35,7 +35,6 @@
#include "mtd.h"
#include "crc32.h"
-#define TRX_MAGIC 0x30524448 /* "HDR0" */
#define TRX_CRC32_DATA_OFFSET 12 /* First 12 bytes are not covered by
CRC32 */
#define TRX_CRC32_DATA_SIZE16
struct trx_header {
@@ -92,7 +91,7 @@ trx_fixup(int fd, const char *name)
}
trx = ptr;
- if (trx->magic != TRX_MAGIC) {
+ if (ntohl(trx->magic) != opt_trxmagic) {
fprintf(stderr, "TRX header not found\n");
goto err;
}
@@ -127,7 +126,8 @@ trx_check(int imagefd, const char *mtd, char *buf, int *len)
}
}
- if (trx->magic != TRX_MAGIC || trx->len < sizeof(struct trx_header)) {
+ if (ntohl(trx->magic) != opt_trxmagic ||
+ trx->len < sizeof(struct trx_header)) {
if (quiet < 2) {
fprintf(stderr, "Bad trx header\n");
fprintf(stderr, "This is not the correct file format;
refusing to flash.\n"
@@ -200,7 +200,7 @@ mtd_fixtrx(const char *mtd, size_t offset, size_t data_size)
}
trx = (struct trx_header *)(first_block + offset);
- if (trx->magic != STORE32_LE(0x30524448)) {
+ if (ntohl(trx->magic) != opt_trxmagic) {
fprintf(stderr, "No trx magic found\n");
exit(1);
}
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/5] mediatek: Add support for Buffalo WSR-2533DHP2
These patches are adding support for different TRX magics and later support for the Buffalo WSR-2533DHP2. This was developed mostly by INAGAKI Hiroshi and I did some fixes and cleaned the patches up in the last days. I added the two patches also for kernel 5.4, I needed this in the beginning till I found out why kernel 5.10 is not booting. Now kernel 5.10 is working fine with this device. I can also remove the kernel 5.4 patches. @Hiroshi: Could you please give your Signed-off-by if you are fine with this. Hauke Mehrtens (3): mediatek: Fix mtk parallel nand driver tools: otrx: allow own magic mediatek: Support non standard trx magic values INAGAKI Hiroshi (2): mtd: Add option for TRX magic to fixtrx mediatek: Add support for Buffalo WSR-2533DHP2 package/boot/uboot-envtools/files/mediatek| 3 + package/system/mtd/src/Makefile | 1 + package/system/mtd/src/mtd.c | 14 +- package/system/mtd/src/mtd.h | 1 + package/system/mtd/src/trx.c | 8 +- .../dts/mt7622-buffalo-wsr-2533dhp2.dts | 336 ++ target/linux/mediatek/image/mt7622.mk | 64 .../mt7622/base-files/etc/board.d/02_network | 4 + .../base-files/etc/uci-defaults/09_fix_crc| 10 + .../mt7622/base-files/lib/upgrade/buffalo.sh | 126 +++ .../mt7622/base-files/lib/upgrade/platform.sh | 15 + target/linux/mediatek/mt7622/config-5.10 | 1 + ...trx-Allow-to-specify-trx-magic-in-DT.patch | 75 ...ove-dependency-to-BRCM-architectures.patch | 23 ++ ...Fix-WAITRDY-break-condition-and-time.patch | 36 ++ ...trx-Allow-to-specify-trx-magic-in-DT.patch | 75 ...ove-dependency-to-BRCM-architectures.patch | 23 ++ tools/firmware-utils/src/otrx.c | 15 +- 18 files changed, 822 insertions(+), 8 deletions(-) create mode 100644 target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts create mode 100644 target/linux/mediatek/mt7622/base-files/etc/uci-defaults/09_fix_crc create mode 100644 target/linux/mediatek/mt7622/base-files/lib/upgrade/buffalo.sh create mode 100644 target/linux/mediatek/patches-5.10/350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch create mode 100644 target/linux/mediatek/patches-5.10/351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch create mode 100644 target/linux/mediatek/patches-5.10/360-mtd-rawnand-mtk-Fix-WAITRDY-break-condition-and-time.patch create mode 100644 target/linux/mediatek/patches-5.4/0350-mtd-parsers-trx-Allow-to-specify-trx-magic-in-DT.patch create mode 100644 target/linux/mediatek/patches-5.4/0351-mtd-parsers-Remove-dependency-to-BRCM-architectures.patch -- 2.30.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/5] tools: otrx: allow own magic
This allows to specify an own magic instead of using the default magic
value TRX_MAGIC. If no own magic is specified the default one will be
used.
Signed-off-by: Hauke Mehrtens
---
tools/firmware-utils/src/otrx.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/firmware-utils/src/otrx.c b/tools/firmware-utils/src/otrx.c
index 223e032f2b5e..3bbbac39e3b3 100644
--- a/tools/firmware-utils/src/otrx.c
+++ b/tools/firmware-utils/src/otrx.c
@@ -287,7 +287,6 @@ static int otrx_create_write_hdr(FILE *trx, struct
trx_header *hdr) {
uint8_t buf[1024];
uint32_t crc32;
- hdr->magic = cpu_to_le32(TRX_MAGIC);
hdr->version = 1;
fseek(trx, 0, SEEK_SET);
@@ -324,9 +323,13 @@ static int otrx_create(int argc, char **argv) {
ssize_t sbytes;
size_t curr_idx = 0;
size_t curr_offset = sizeof(hdr);
+ char *e;
+ uint32_t magic;
int c;
int err = 0;
+ hdr.magic = cpu_to_le32(TRX_MAGIC);
+
if (argc < 3) {
fprintf(stderr, "No TRX file passed\n");
err = -EINVAL;
@@ -343,7 +346,7 @@ static int otrx_create(int argc, char **argv) {
fseek(trx, curr_offset, SEEK_SET);
optind = 3;
- while ((c = getopt(argc, argv, "f:A:a:b:")) != -1) {
+ while ((c = getopt(argc, argv, "f:A:a:b:M:")) != -1) {
switch (c) {
case 'f':
if (curr_idx >= TRX_MAX_PARTS) {
@@ -400,6 +403,14 @@ static int otrx_create(int argc, char **argv) {
curr_offset += sbytes;
}
break;
+ case 'M':
+ errno = 0;
+ magic = strtoul(optarg, &e, 0);
+ if (errno || (e == optarg) || *e)
+ fprintf(stderr, "illegal magic string %s\n",
optarg);
+ else
+ hdr.magic = cpu_to_le32(magic);
+ break;
}
if (err)
break;
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Please consider reverting autoconf-lean from toolchain
On 3/1/21 3:54 PM, Hannu Nyman wrote:
Apparently autoconf-lean, merged into the toolchain during last weekend,
causes problems with various packages at buildbot.
I am not sure if that is due to underlying problems in the specific
failing packages, or due to a wrong site config from autoconf-lean, but
buildbot is gradually hitting the problems as packages are built with
faulty SDKs.
I suggest that the new autoconf-lean stuff is reverted until the
failures are understood better.
I have filed bug FS#3655 and earlieralso a packages issue as that was
how I found the issue in my own build.
There are several buildbot failure logs examples in the bug FS#3655.
At least ntfs-3g, rsync, nedata, and possibly also mac80211 and mwlwifi
are failing for some targets.
(not sure about mac80211 and mwlwifi failures' relation)
I reverted autoconf-lean from my buildhost and I was again able to build
ntfs-3g.
Extract from bug FS#3655:
https://bugs.openwrt.org/index.php?do=details&task_id=3655&order=id&sort=desc
---
autoconf-lean stuff from Felix was merged by Daniel a few days ago to
master with commits
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=32c664ff02910bf39a3fbd5a5a4a8bff3191dd03�
and
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f439e291304a93b982e912dc91b80ca950a594f3
That seems to cause buildhost-specific variation in the generated site
config files, and causes variating breakage from some packages.
I stumbled upon this on weekend with ntfs-3g, which suddenly does not
compile in my Ubuntu 20.10 in Virtualbox. I filed a bug about ntfs-3g to
packages feed, but this is more generic:
https://github.com/openwrt/packages/issues/14940
The same buildhost builds 21.02 without problems (and that is still
pretty identical to master regarding packages)
Reverting autoconf-lean commits fixes things for me.
There are now others with the same symptoms, based on responses to the
packages feed bug.
Buildbot is now meeting the same problem. At least ntfs-3g, rsync,
nedata, and possibly also mac80211 and mwlwifi are failing for some
targets with some buildhosts (with the new SDK).
E.g.
https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a72/packages/ntfs-3g/compile.txt
OpenWrt does not build with glibc for me and the build bots.
When I remove this setting at least the autoconf-lean packet links, but
I still have some build problems.
ac_cv_lib_xnet_main=${ac_cv_lib_xnet_main=yes}
Hauke
OpenPGP_0x93DD20630910B515.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uboot-envtools: adjust compile patch to version v2021.01
On 2/24/21 4:50 PM, k_ronny wrote: with u-boot v2020.07 some variables have been renamed so this patch needs to be adjusted otherwise at least with macOS as build system there are build errors Signed-off-by: k_ronny --- package/boot/uboot-envtools/patches/001-compile.patch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/boot/uboot-envtools/patches/001-compile.patch b/package/boot/uboot-envtools/patches/001-compile.patch index 5413aa4a41..9b1b6b5d35 100644 --- a/package/boot/uboot-envtools/patches/001-compile.patch +++ b/package/boot/uboot-envtools/patches/001-compile.patch @@ -5,10 +5,10 @@ override HOSTCC = $(CC) +ifneq ($(TARGET_CFLAGS),) -+HOSTCFLAGS = $(TARGET_CFLAGS) ++KBUILD_HOSTCFLAGS = $(TARGET_CFLAGS) +endif +ifneq ($(TARGET_LDFLAGS),) -+HOSTLDFLAGS = $(TARGET_LDFLAGS) ++KBUILD_HOSTLDFLAGS = $(TARGET_LDFLAGS) +endif + # Compile for a hosted environment on the target Hi, This patch looks good, but could you please resend it with your full name in the From and the Signed-off-by line please. Hauke OpenPGP_0x93DD20630910B515.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek: Add generic zyxel_gs1900 image definition
On 2/27/21 6:00 PM, Bjørn Mork wrote: Hauke Mehrtens writes: I used the wrong AAHI magic and it was possible to falsh the image over the Web UI, buit the image did not boot, it was unable to find the root fs for me. That's odd. Didn't work in my tests, but I've only tested the GS1900-10HP with the latest stock firmware. But rootfs? Flashing from stock will only work with the initramfs image. The stock web ui will cut the image according to the uimage header, without warning. So everything has to be "inside" the uimage. Ok, I used the sysupgrade tar, I was surprised that this was accepted at all. ;-) But there is something wrong with our image code if you are able to flash anything else than the initramfs image from stock. Specifically: The "zyxel-vers" stuff should *not* be appended to the kernel in the sysupgrade image. Where is this check done? AFAICS, only in the stock firmware upgrade "app". I was unable to extract the original firmware with binwalk which would be nice to get some more information about how it is structured. The GPL drop at https://biot.com/gpl/GS1900-10HP(V2.60(AAZI.2)C0).zip is pretty complete. Only a few files are binary blobs. And everything necessary to build an image is included. Thanks I will have a look at this. There isn't anything weird with the stock image. It's a standard uimage with a non-standard magic. The list of supported hardware versions is an ascii text file at the end of the real image, but inside the size and checksum coverage of the uimage header. Hauke OpenPGP_0x93DD20630910B515.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] netifd: bridge: set default value for igmp_snoop
On 2/24/21 1:49 AM, sotu...@gmail.com wrote: From: Zheng Qian When luci unchecked the igmp snoop option for a bridge, it just delete the igmp_snooping key from the config file. So netifd can't change /sys/devices/virtual/net/br-lan/bridge/multicast_snooping from "1" to "0". This patch will set a default value to false for the bridge option to fix this bug. Signed-off-by: Zheng Qian --- bridge.c | 1 + 1 file changed, 1 insertion(+) diff --git a/bridge.c b/bridge.c index b70d626..464629c 100644 --- a/bridge.c +++ b/bridge.c @@ -875,6 +875,7 @@ bridge_apply_settings(struct bridge_state *bst, struct blob_attr **tb) /* defaults */ cfg->stp = false; + cfg->igmp_snoop = false; cfg->forward_delay = 2; cfg->robustness = 2; cfg->query_interval = 12500; The default setting was removed in this change: https://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=52541140f8138e31958cdc3d7e42a4029fa6bbc9 - cfg->igmp_snoop = true; - cfg->multicast_querier = true; We should probably also set multicast_querier to false here. Hauke OpenPGP_0x93DD20630910B515.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
