[OpenWrt-Devel] [PATCH] strace: update to version 5.5
Changelog: https://strace.io/files/5.5/ Signed-off-by: Josef Schlehofer --- package/devel/strace/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/devel/strace/Makefile b/package/devel/strace/Makefile index 0d22b0bb23..cdf4067ad2 100644 --- a/package/devel/strace/Makefile +++ b/package/devel/strace/Makefile @@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=strace -PKG_VERSION:=5.4 +PKG_VERSION:=5.5 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=https://strace.io/files/$(PKG_VERSION) -PKG_HASH:=f7d00514d51290b6db78ad7a9de709baf93caa5981498924cbc9a744cfd2a741 +PKG_HASH:=9f58958c8e59ea62293d907d10572e352b582bd7948ed21aa28ebb47e5bf30ff PKG_MAINTAINER:=Felix Fietkau PKG_LICENSE:=LGPL-2.1-or-later -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Next maintenance releases
Rosen Penev [2020-02-22 14:31:14]: > That’s totally bogus. That's my interpretation of your commit description, where you're talking about errors, changes, but didn't provide actual output, commit hashes etc. You simply assume, that every reviewer is NASM and ffmpeg expert. > ffmpeg is the only user of NASM. This wasnt clear from your commit description. > Note that I’ve already worked around this in the packages feed by passing > —disable-x86asm to ffmpeg for these platforms. Ok, how could I deduce this important detail from that commit description? > Also note that ASM optimizations help with the PCEngines APUs, which are > quite popular here. Good, then make it clear in v2 description of your patch. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] tplink and gl devices accidentally removed from 02_network?
Hi, > In 19.07.1 and master, I don't find definitions for a few devices in > 02_network. > > I'm debugging an issue and did not find a definition for gl-ar150. It > appears a few devices were accidentally removed: > > - comfast,cf-e5|\ > - glinet,gl-ar150|\ > - glinet,gl-ar300m-nand|\ > - glinet,gl-ar300m-nor|\ > - glinet,gl-x750|\ > - tplink,tl-wr810n-v1|\ > - tplink,tl-wr810n-v2|\ > - yuncore,a770) I haven't checked all of them explicitly, but those I know just use the default case in 02_network. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Next maintenance releases
Sent from my iPhone > On Feb 22, 2020, at 5:31 AM, Petr Štetiar wrote: > > Rosen Penev [2020-02-21 14:55:55]: > > Hi, > >> I would like https://patchwork.ozlabs.org/patch/1221697/ to be applied. >> It makes no sense to have broken functionality in the tree. > > thank you for taking care, but I'm not going to merge this into 19.07. > > It looks like it doesn't fix anything, "just" a build failure of ffmpeg by not > building it. ffmpeg won't build even after this change, so I don't see a point > of this change in the stable release, in sensitive toolchain area, which might > potentialy introduce some regression in other parts. That’s totally bogus. ffmpeg is the only user of NASM. None of the object files built by NASM for these platforms are valid. Note that I’ve already worked around this in the packages feed by passing —disable-x86asm to ffmpeg for these platforms. Also note that ASM optimizations help with the PCEngines APUs, which are quite popular here. > > -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] target: bump minimum CPU type to pentium-mmx
Sent from my iPhone > On Feb 22, 2020, at 6:13 AM, Hauke Mehrtens wrote: > > On 1/12/20 5:44 AM, Rosen Penev wrote: >> f4f8f4a180366ee90fd8e153213db2cb746ca361 broke ffmpeg compilation with x86 >> >> The reason is that ffmpeg's x86 assembly requires at least MMX, which the >> pentium CPU_TYPE was preventing. > > As far as I understand it MMX is already needed and you just want to > rename the toolchain from pentium to pentium_mmx, is this correct? Yeah. Changing the CPU_TYPE to pentium-mmx fixes NASM. > >> >> Fixes ffmpeg compilation on x86_legacy and x86_geode. >> >> Signed-off-by: Rosen Penev >> --- >> include/target.mk | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/target.mk b/include/target.mk >> index a813ba2d2d..a30400c5bc 100644 >> --- a/include/target.mk >> +++ b/include/target.mk >> @@ -177,8 +177,8 @@ ifeq ($(DUMP),1) >> CPU_CFLAGS_octeonplus = -march=octeon+ -mabi=64 >> endif >> ifeq ($(ARCH),i386) >> -CPU_TYPE ?= pentium >> -CPU_CFLAGS_pentium = -march=pentium-mmx >> +CPU_TYPE ?= pentium-mmx >> +CPU_CFLAGS_pentium-mmx = -march=pentium-mmx >> CPU_CFLAGS_pentium4 = -march=pentium4 >> endif >> ifneq ($(findstring arm,$(ARCH)),) >> > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [19.07] kernel: avoid underscore in *6lowpan package names
Am Dienstag, 18. Februar 2020, 21:47:20 CET schrieb Eneas U de Queiroz: > Packages kmod-bluetooth_6lowpan and kmod-ieee802154_6lowpan contain an > underscore in the package name. This causes problems in package/install > because when building a list of package files to install offline using > opkg, it uses a wildcard of the form $(dir)/$(pkg)_*.ipk. > > If you were to select kmod-bluetooth=y, but kmod-bluetooth_6lowpan=m, > the latter would be picked up by that wildcard, and make package/install > would fail: > Hi, this patch was added in 07e1d88d7beb43a4152460b82976dbe49919b264. The same problem exists for 19.07. Can somebody cherry-pick this? Thanks Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] mbedtls: update to version 2.16.5
Changelog: https://tls.mbed.org/tech-updates/releases/mbedtls-2.16.5-and-2.7.14-released Security advisory: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-02 Signed-off-by: Josef Schlehofer --- package/libs/mbedtls/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile index 618a74703a..ad1da70268 100644 --- a/package/libs/mbedtls/Makefile +++ b/package/libs/mbedtls/Makefile @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk PKG_NAME:=mbedtls -PKG_VERSION:=2.16.4 +PKG_VERSION:=2.16.5 PKG_RELEASE:=1 PKG_USE_MIPS16:=0 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-gpl.tgz PKG_SOURCE_URL:=https://tls.mbed.org/download/ -PKG_HASH:=5fdb9c43ab43fd9bcc3631508170b089ede7b86dd655253a93cb0ffeb42309f3 +PKG_HASH:=6ebdea6565c714f1315b9af6a802afb4b4e89976f7d5d2b15aa8028eb52e7d09 PKG_BUILD_PARALLEL:=1 PKG_LICENSE:=GPL-2.0+ -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] mbedtls: use correct SPDX License Identifier and add License file
License "GPL-2.0+" is deprecated License Identifier according to SPDX License list [1]. The correct one is GPL-2.0-or-later. While at it, also add the License file. [1] https://spdx.org/licenses/ Signed-off-by: Josef Schlehofer --- package/libs/mbedtls/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile index ad1da70268..7ceb0dc4af 100644 --- a/package/libs/mbedtls/Makefile +++ b/package/libs/mbedtls/Makefile @@ -17,7 +17,8 @@ PKG_SOURCE_URL:=https://tls.mbed.org/download/ PKG_HASH:=6ebdea6565c714f1315b9af6a802afb4b4e89976f7d5d2b15aa8028eb52e7d09 PKG_BUILD_PARALLEL:=1 -PKG_LICENSE:=GPL-2.0+ +PKG_LICENSE:=GPL-2.0-or-later +PKG_LICENSE_FILES:=gpl-2.0.txt PKG_CPE_ID:=cpe:/a:arm:mbed_tls PKG_CONFIG_DEPENDS:=CONFIG_LIBMBEDTLS_DEBUG_C -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] tplink and gl devices accidentally removed from 02_network?
In 19.07.1 and master, I don't find definitions for a few devices in 02_network. I'm debugging an issue and did not find a definition for gl-ar150. It appears a few devices were accidentally removed: - comfast,cf-e5|\ - glinet,gl-ar150|\ - glinet,gl-ar300m-nand|\ - glinet,gl-ar300m-nor|\ - glinet,gl-x750|\ - tplink,tl-wr810n-v1|\ - tplink,tl-wr810n-v2|\ - yuncore,a770) https://github.com/openwrt/openwrt/commit/c3a85189181827c8d5c2ab736428be30e4c13128 bug? or more to the story? Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Subject: [PATCH 1/1] blobmsg_json: allow to add full json files
Current function "blobmsg_add_json_from_file" only adds json file if it
is an object, and it only returns the properties, not a full object
attribute.
This version allows to read any valid json file and returns the complete
corresponding attribute.
Signed-off-by: Adrian Panella
---
blobmsg_json.c | 16
blobmsg_json.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/blobmsg_json.c b/blobmsg_json.c
index dce81e9..b8f91f1 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -87,6 +87,22 @@ bool blobmsg_add_json_element(struct blob_buf *b, const char
*name, json_object
return ret;
}
+bool blobmsg_add_json_file(struct blob_buf *b, const char *name, const char
*file)
+{
+ struct json_object *obj;
+ bool ret;
+
+ obj = json_object_from_file(file);
+
+ if (!obj)
+ return false;
+
+ ret = blobmsg_add_json_element(b, name, obj);
+
+ json_object_put(obj);
+ return ret;
+}
+
static bool __blobmsg_add_json(struct blob_buf *b, json_object *obj)
{
bool ret = false;
diff --git a/blobmsg_json.h b/blobmsg_json.h
index 9dfc02d..61cdbe5 100644
--- a/blobmsg_json.h
+++ b/blobmsg_json.h
@@ -23,6 +23,7 @@ struct json_object;
bool blobmsg_add_object(struct blob_buf *b, struct json_object *obj);
bool blobmsg_add_json_element(struct blob_buf *b, const char *name, struct
json_object *obj);
+bool blobmsg_add_json_file(struct blob_buf *b, const char *name, const char
*file);
bool blobmsg_add_json_from_string(struct blob_buf *b, const char *str);
bool blobmsg_add_json_from_file(struct blob_buf *b, const char *file);
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] firmware-utils/mkcameofw for TEW-810DR
I have successfully adapted OpenWRT's D-Link DIR-810L build for a Trendnet TEW-810DR. It was low-hanging fruit, the devices essentially use the same board. One difference is that Trendnet firmware has what I've seen described as a cameo signature appended at the end. For my own use, I could use the cameo tool: ncc_att_hwid as described here: https://openwrt.org/toh/trendnet/trendnet_tew-810dr_1.0_1.1 I think if I take the extra step to incorporate the cameo signature, the patch would be committable. I've searched the git code base for an example of how to append the code during the build and have come up empty. Source for mkcameofw.c has "Options:\n" " -kread kernel image from the file \n" " -c use the kernel image as a combined image\n" " -M set model to \n" " -owrite output to the file \n" " -rread rootfs image from the file \n" " -S set image signature to \n" " -R set image region to \n" " -V set image version to \n" " -Iset image size to \n" " -Kset kernel size to \n" " -h show this screen\n" If I read this correctly -M TEW-810DR -V 1.0R -R WW #I'm guessing WW is Region code -S 1.0 Could someone point me to a *dts that utilizes this tool or a *dts that reaches the same goal? Thanks in advance -- J. Scott Heppler ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] linux-atm: Fix compile warning
The function trace_on_exit() is given to atexit() as a parameter, but
atexit() only takes a function pointer to a function with a void
parameter.
This problem was introduced when the on_exit() function was incompletely
replaced by atexit().
Fixes: ba6c8bd6142f ("linux-atm: add portability fixes")
Signed-off-by: Hauke Mehrtens
---
.../patches/400-portability_fixes.patch | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git
a/package/network/utils/linux-atm/patches/400-portability_fixes.patch
b/package/network/utils/linux-atm/patches/400-portability_fixes.patch
index 9fe3e1faea..41425eed19 100644
--- a/package/network/utils/linux-atm/patches/400-portability_fixes.patch
+++ b/package/network/utils/linux-atm/patches/400-portability_fixes.patch
@@ -34,7 +34,21 @@
#include
--- a/src/sigd/atmsigd.c
+++ b/src/sigd/atmsigd.c
-@@ -517,7 +517,7 @@ int main(int argc,char **argv)
+@@ -283,12 +283,11 @@ static void setup_signals(void)
+ /* --- main ... ---
*/
+
+
+-static void trace_on_exit(int status,void *dummy)
++static void trace_on_exit(void)
+ {
+ char path[PATH_MAX+1];
+ FILE *file;
+
+-if (!status) return;
+ if (!dump_dir) file = stderr;
+ else {
+ sprintf(path,"atmsigd.%d.trace.exit",getpid());
+@@ -517,7 +516,7 @@ int main(int argc,char **argv)
exit(0);
}
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 2/3] ath10k-ct: Update to version 2020-02-18
This adds AP vlans support.
Signed-off-by: Hauke Mehrtens
---
package/kernel/ath10k-ct/Makefile | 6 ++--
...rolling-support-for-various-chipsets.patch | 36 +--
...h10k-4.16-use-tpt-trigger-by-default.patch | 4 +--
3 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index 6317fc7912..62004cd490 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -8,9 +8,9 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
PKG_SOURCE_PROTO:=git
-PKG_SOURCE_DATE:=2020-01-29
-PKG_SOURCE_VERSION:=3e3d0adb3cc6c6cf56a05ff661796948f09c5aa8
-PKG_MIRROR_HASH:=6341de2d3b19b2a32205a1633bf9556815943a2cff38acbbe5f61c6c0164fdcc
+PKG_SOURCE_DATE:=2020-02-18
+PKG_SOURCE_VERSION:=bed49a5f6824fcd8757fd27f6b2a4f6ea933bf2f
+PKG_MIRROR_HASH:=4f16b1b44b0be6c2dba92754e7533fdc6bfbf63ae673301a49c47c5e53ea
# Build the 5.2 ath10k-ct driver version. Other option is "-4.19".
# Probably this should match as closely as
diff --git
a/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
b/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
index d526e2795b..a7525841c6 100644
---
a/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
+++
b/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
@@ -161,7 +161,7 @@ v13:
.patch_load_addr = QCA9888_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_EACH,
-@@ -3170,6 +3176,10 @@ int ath10k_core_start(struct ath10k *ar,
+@@ -3176,6 +3182,10 @@ int ath10k_core_start(struct ath10k *ar,
ath10k_wmi_check_apply_board_power_ctl_table(ar);
}
@@ -172,7 +172,7 @@ v13:
return 0;
err_hif_stop:
-@@ -3424,9 +3434,18 @@ static void ath10k_core_register_work(st
+@@ -3430,9 +3440,18 @@ static void ath10k_core_register_work(st
goto err_spectral_destroy;
}
@@ -191,7 +191,7 @@ v13:
err_spectral_destroy:
ath10k_spectral_destroy(ar);
err_debug_destroy:
-@@ -3484,6 +3503,8 @@ void ath10k_core_unregister(struct ath10
+@@ -3490,6 +3509,8 @@ void ath10k_core_unregister(struct ath10
if (!test_bit(ATH10K_FLAG_CORE_REGISTERED, &ar->dev_flags))
return;
@@ -218,7 +218,7 @@ v13:
bool p2p;
bool ct_all_pkts_htt; /* CT firmware only: native-wifi for all pkts */
-@@ -1389,6 +1389,13 @@ struct ath10k {
+@@ -1391,6 +1391,13 @@ struct ath10k {
} testmode;
struct {
@@ -514,7 +514,7 @@ v13:
static struct sk_buff *
ath10k_wmi_op_gen_set_psmode(struct ath10k *ar, u32 vdev_id,
enum wmi_sta_ps_mode psmode)
-@@ -9822,6 +9865,9 @@ static const struct wmi_ops wmi_ops = {
+@@ -9824,6 +9867,9 @@ static const struct wmi_ops wmi_ops = {
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
.gen_echo = ath10k_wmi_op_gen_echo,
@@ -524,7 +524,7 @@ v13:
/* .gen_bcn_tmpl not implemented */
/* .gen_prb_tmpl not implemented */
/* .gen_p2p_go_bcn_ie not implemented */
-@@ -9892,6 +9938,8 @@ static const struct wmi_ops wmi_10_1_ops
+@@ -9894,6 +9940,8 @@ static const struct wmi_ops wmi_10_1_ops
.fw_stats_fill = ath10k_wmi_10x_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
.gen_echo = ath10k_wmi_op_gen_echo,
@@ -533,7 +533,7 @@ v13:
/* .gen_bcn_tmpl not implemented */
/* .gen_prb_tmpl not implemented */
/* .gen_p2p_go_bcn_ie not implemented */
-@@ -9970,6 +10018,8 @@ static const struct wmi_ops wmi_10_2_ops
+@@ -9972,6 +10020,8 @@ static const struct wmi_ops wmi_10_2_ops
.gen_delba_send = ath10k_wmi_op_gen_delba_send,
.fw_stats_fill = ath10k_wmi_10x_op_fw_stats_fill,
.get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
@@ -542,7 +542,7 @@ v13:
/* .gen_pdev_enable_adaptive_cca not implemented */
};
-@@ -10040,6 +10090,8 @@ static const struct wmi_ops wmi_10_2_4_o
+@@ -10042,6 +10092,8 @@ static const struct wmi_ops wmi_10_2_4_o
.gen_pdev_enable_adaptive_cca =
ath10k_wmi_op_gen_pdev_enable_adaptive_cca,
.get_vdev_subtype = ath10k_wmi_10_2_4_op_get_vdev_subtype,
@@ -551,7 +551,7 @@ v13:
/* .gen_bcn_tmpl not implemented */
/* .gen_prb_tmpl not implemented */
/* .gen_p2p_go_bcn_ie not implemented */
-@@ -10120,6 +10172,8 @@ static const struct wmi_ops wmi_10_4_ops
+@@ -10122,6 +10174,8 @@ static const struct wmi_ops wmi_10_4_ops
.gen_pdev_bss_chan_info_req = ath10k_wmi_10_2_op_gen_pdev_bss_chan_info,
.gen_ech
[OpenWrt-Devel] [PATCH v2 3/3] ath10k-ct: Use ath10k-ct version 5.4
This makes ath10k-ct use the version based on kernel 5.4 by default.
Signed-off-by: Hauke Mehrtens
---
The update to version 5.4 is needed to make this driver compile against
kernel 5.4.
This got some minimal testing on IPQ4019 by me.
package/kernel/ath10k-ct/Makefile | 4 +-
...64-ath10k-commit-rates-from-mac80211.patch | 26 +
...rolling-support-for-various-chipsets.patch | 514 ++
...h10k-4.16-use-tpt-trigger-by-default.patch | 37 ++
...0-0010-ath10k-limit-htt-rx-ring-size.patch | 14 +
...60-0011-ath10k-limit-pci-buffer-size.patch | 50 ++
6 files changed, 643 insertions(+), 2 deletions(-)
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index 62004cd490..ca4fa93788 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -12,10 +12,10 @@ PKG_SOURCE_DATE:=2020-02-18
PKG_SOURCE_VERSION:=bed49a5f6824fcd8757fd27f6b2a4f6ea933bf2f
PKG_MIRROR_HASH:=4f16b1b44b0be6c2dba92754e7533fdc6bfbf63ae673301a49c47c5e53ea
-# Build the 5.2 ath10k-ct driver version. Other option is "-4.19".
+# Build the 5.4 ath10k-ct driver version. Other option is "-4.19".
# Probably this should match as closely as
# possible to whatever mac80211 backports version is being used.
-CT_KVER="-4.19"
+CT_KVER="-5.4"
PKG_MAINTAINER:=Ben Greear
PKG_BUILD_PARALLEL:=1
diff --git
a/package/kernel/ath10k-ct/patches/164-ath10k-commit-rates-from-mac80211.patch
b/package/kernel/ath10k-ct/patches/164-ath10k-commit-rates-from-mac80211.patch
index 9a31164fcc..05d65e24ea 100644
---
a/package/kernel/ath10k-ct/patches/164-ath10k-commit-rates-from-mac80211.patch
+++
b/package/kernel/ath10k-ct/patches/164-ath10k-commit-rates-from-mac80211.patch
@@ -61,3 +61,29 @@ Signed-off-by: Sven Eckelmann
vdev_param = ar->wmi.vdev_param->mgmt_rate;
ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
hw_rate_code);
+--- a/ath10k-5.4/mac.c
b/ath10k-5.4/mac.c
+@@ -6793,6 +6793,7 @@ static void ath10k_bss_info_changed(stru
+ "mac vdev %d mcast_rate %x\n",
+ arvif->vdev_id, rate);
+
++ arvif->mcast_rate[band] = rate;
+ vdev_param = ar->wmi.vdev_param->mcast_data_rate;
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+ vdev_param, rate);
+@@ -6801,6 +6802,7 @@ static void ath10k_bss_info_changed(stru
+ "failed to set mcast rate on vdev %i: %d\n",
+ arvif->vdev_id, ret);
+
++ arvif->bcast_rate[band] = rate;
+ vdev_param = ar->wmi.vdev_param->bcast_data_rate;
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+ vdev_param, rate);
+@@ -6827,6 +6829,7 @@ static void ath10k_bss_info_changed(stru
+ return;
+ }
+
++ arvif->mgt_rate[def.chan->band] = hw_rate_code;
+ vdev_param = ar->wmi.vdev_param->mgmt_rate;
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
+ hw_rate_code);
diff --git
a/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
b/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
index a7525841c6..696da7b455 100644
---
a/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
+++
b/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
@@ -1118,3 +1118,517 @@ v13:
struct wmi_ext_resource_config_10_4_cmd {
/* contains enum wmi_host_platform_type */
__le32 host_platform_config;
+--- a/ath10k-5.4/Kconfig
b/ath10k-5.4/Kconfig
+@@ -66,6 +66,16 @@ config ATH10K_DEBUGFS
+
+ If unsure, say Y to make it easier to debug problems.
+
++config ATH10K_LEDS
++ bool "Atheros ath10k LED support"
++ depends on ATH10K
++ select MAC80211_LEDS
++ select LEDS_CLASS
++ select NEW_LEDS
++ default y
++ ---help---
++This option is necessary, if you want LED support for chipset
connected led pins. If unsure, say N.
++
+ config ATH10K_SPECTRAL
+ bool "Atheros ath10k spectral scan support"
+ depends on ATH10K_DEBUGFS
+--- a/ath10k-5.4/Makefile
b/ath10k-5.4/Makefile
+@@ -19,6 +19,7 @@ ath10k_core-$(CONFIG_ATH10K_SPECTRAL) +=
+ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
+ ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
+ ath10k_core-$(CONFIG_THERMAL) += thermal.o
++ath10k_core-$(CONFIG_ATH10K_LEDS) += leds.o
+ ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
+ ath10k_core-$(CONFIG_PM) += wow.o
+ ath1
[OpenWrt-Devel] [PATCH v2 1/3] mac80211: Allow ADHOC mode and different beacon intervals
ath10k-ct supports the combination to select ADHOC (IBSS) mode and
different beacon intervals together. mac80211 does not like this
combination, but Ben says this is ok, so remove this check.
Signed-off-by: Hauke Mehrtens
---
.../patches/subsys/400-allow-ibss-mixed.patch | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
package/kernel/mac80211/patches/subsys/400-allow-ibss-mixed.patch
diff --git a/package/kernel/mac80211/patches/subsys/400-allow-ibss-mixed.patch
b/package/kernel/mac80211/patches/subsys/400-allow-ibss-mixed.patch
new file mode 100644
index 00..52200b6ecc
--- /dev/null
+++ b/package/kernel/mac80211/patches/subsys/400-allow-ibss-mixed.patch
@@ -0,0 +1,29 @@
+ath10k-ct starting with version 5.2 allows the combination of
+NL80211_IFTYPE_ADHOC and beacon_int_min_gcd in ath10k_10x_ct_if_comb
+which triggers this warning. Ben told me that this is not a big problem
+and we should ignore this.
+
+--- a/net/wireless/core.c
b/net/wireless/core.c
+@@ -613,21 +613,6 @@ static int wiphy_verify_combinations(str
+ c->limits[j].max > 1))
+ return -EINVAL;
+
+- /*
+- * This isn't well-defined right now. If you have an
+- * IBSS interface, then its beacon interval may change
+- * by joining other networks, and nothing prevents it
+- * from doing that.
+- * So technically we probably shouldn't even allow AP
+- * and IBSS in the same interface, but it seems that
+- * some drivers support that, possibly only with fixed
+- * beacon intervals for IBSS.
+- */
+- if (WARN_ON(types & BIT(NL80211_IFTYPE_ADHOC) &&
+- c->beacon_int_min_gcd)) {
+- return -EINVAL;
+- }
+-
+ cnt += c->limits[j].max;
+ /*
+* Don't advertise an unsupported type
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k QCA9880 firmware TX hang
On 10/19/19 1:43 PM, David Bauer wrote: > Hello, > > while preparing the switch to 19.07 for the mesh-framework Gluon, we found an > issue > with ath10k, which results in an overflowing TX queue in the kernel. The > QCA9880 does > not send TX_DONE or TX_FAILED messages back to the driver, which results in > the SKBs never > being freed. Both HTT_COOKIES counters are also frozen when this happens. > > This happens when using 10.2.4-1.0-00045 (current in linux-firmware) and > 10.2.4-1.0-00037 firmware (shipped with OpenWrt 18.06). However, it seems to > be fixed in > 10.2.4-1.0-00047. > > We have some statistical data about this issue here. [1] > As you can see, the issue started with the switch to OpenWrt on 26. September > and > was resolved on 5th October (we did some testing afterwards, so we didn't > reach a continuous > uptime) > > We've also tried ath10k-ct firmware (which does not seem to show the issue), > however this is > an option for us, as we need 802.11s meshing on our devices (the described > issue however does also > happen when using a single AP VIF). > > As an interim fix, i would propose to switch to the 10.2.4-1.0-00047 firmware > for the QCA9880/QCA9887. > This would include switching to ath10k-firmware repository from kvalo for > both firmware files. > > Any objections on this? > > [1] > https://stats.darmstadt.freifunk.net/d/00021/router-meshviewer-export?orgId=1&var-node=f09fc2dec4c5&from=1569466967823&to=1570394540260 > > Best wishes > David Hi David, The linux-firmeware package was updated and contains the new ath10k firmware now: ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.9.0.2-00070 ath10k: QCA988X hw2.0: update firmware-5.bin to 10.2.4-1.0-00047 ath10k: QCA9888 hw2.0: update firmware-5.bin to 10.4-3.9.0.2-00070 ath10k: QCA9887 hw1.0: update firmware-5.bin to 10.2.4-1.0-00047 Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] rtl8812au-ct: Update to version 2020-01-12
This fixes compile problems with kernel 5.4 Signed-off-by: Hauke Mehrtens --- We need this update to make this driver compile against kernel 5.4, but I do not have the hardware to run time test this change. package/kernel/rtl8812au-ct/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/kernel/rtl8812au-ct/Makefile b/package/kernel/rtl8812au-ct/Makefile index b7f6d225b1..aac754de7f 100644 --- a/package/kernel/rtl8812au-ct/Makefile +++ b/package/kernel/rtl8812au-ct/Makefile @@ -7,10 +7,10 @@ PKG_LICENSE:=GPLv2 PKG_LICENSE_FILES:= PKG_SOURCE_URL:=https://github.com/greearb/rtl8812AU_8821AU_linux.git -PKG_MIRROR_HASH:=42b32c56cf31bdf3c9cd4e304c9aac761b623c8737d8c57518117acdc5a84cfe +PKG_MIRROR_HASH:=fa689e034cad9e4683ea784b8f3cb590492ab5c68e8babd492a4e8bf2de3b114 PKG_SOURCE_PROTO:=git -PKG_SOURCE_DATE:=2018-11-16 -PKG_SOURCE_VERSION:=661268fd174d4a74834c82d7d3987b0a560e6c57 +PKG_SOURCE_DATE:=2020-01-12 +PKG_SOURCE_VERSION:=e0d586aa93cb8687dd7dc0e593b6a820df2d6e1d PKG_MAINTAINER:=Ben Greear PKG_BUILD_PARALLEL:=1 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Next maintenance releases
Petr Štetiar wrote: > Karl Palsson [2020-02-21 13:14:29]: > > Hi, > > > I would very much like to see > > https://bugs.openwrt.org/index.php?do=details&task_id=2833 merged > > (it contains a fix and tests) for 19.07, as it fixes a regression > > in behaviour there. (umdns stopped working) > > [puting aside the fact, that the patches weren't send via the > standard way[1] so they weren't reviewed yet] > > please note, that this proposed fix is not included in the > master yet, thus untested by the wider audience and you're > requesting inclusion into stable release 19.07. Correct. Breaking umdns is a regression that should be fixed. I'm honestly more surprised that this still isn't fixed in master either. > > 1. https://openwrt.org/submitting-patches Not my patch, just another person with the same breakage so I can't control how they submitted it. They filed a bug report, using the formal bug tracking tool, and happened to include a patch and test. Sincerely, Karl Palsson OpenPGP-digital-signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Some questions - help needed
On 20. 2. 22. 9:48 PM, m...@adrianschmutzler.de wrote: to make a variable "per-device", you have to add it to DEVICE_VARS, e.g. DEVICE_VARS += DEVICE_TYPE I've tried it, but it did not work. DEVICE_VARS is used in include/image.mk but DEVICE_TYPE is used in include/target.mk, I guess that is the cause. It seems "DEVICE_TYPE:=nas" does two things: 1. add more packages to DEFAULT_PACKAGES 2. add hdparm in busybox The first one might be done in a device-specific way, but I'm not sure about the second one... I've once tried to solve this for the same problem but with kmod-i2c-core IIRC, and then quit at some point because I couldn't find the initial source of the problem. I found it: i2c-gpio-custom. If I remove the package directory, all i2c packages are nested now. Maybe scripts/package-metadata.pl has some bugs? But it's not the main topic here. I replaced all "DEPENDS:=kmod-i2c-core" with "DEPENDS:=+kmod-i2c-core", and removed unnecessary kmod-i2c-core in DEVICE_PACKAGES. And build test (on ramips) was successful. So I think I can provide a patch for it (though it needs more build tests). But what I'm wondering is, how far will we go? Can we add "+" to all kernel packages (unless it leads to a dependency error)? If "select" alone is enough, then why do we also use "depends on"? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mkrasimage: fix segmentation fault
Code was attempting to determine the size of the file before it was actually known and allocating insufficient memory space. Images above a certain size caused a segmentation fault. Moving the calloc() ensured ensured that large images didn't result in a buffer overflow on memcpy(). Signed-off-by: Michael T Farnworth diff --git a/tools/firmware-utils/src/mkrasimage.c b/tools/firmware-utils/src/mkrasimage.c index cff3a533d1..d8cec527fb 100644 --- a/tools/firmware-utils/src/mkrasimage.c +++ b/tools/firmware-utils/src/mkrasimage.c @@ -317,6 +317,16 @@ int build_image() map_file(&kernel); map_file(&rootfs); +/* As ZyXEL Web-GUI only accept images with a rootfs equal or larger than the first firmware shipped + * for the device, we need to pad rootfs partition to this size. To perform further calculations, we + * decide the size of this part here. In case the rootfs we want to integrate in our image is larger, + * take it's size, otherwise the supplied size. + * + * Be careful! We rely on assertion of correct size to be performed beforehand. It is unknown if images + * with a to large rootfs are accepted or not. + */ +rootfs_out.size = rootfs_size < rootfs.size ? rootfs.size : rootfs_size; + /* * Allocate memory and copy input rootfs for temporary output rootfs. * This is important as we have to generate the rootfs checksum over the @@ -451,14 +461,5 @@ int main(int argc, char *argv[]) if (ret) usage(EXIT_FAILURE); -/* As ZyXEL Web-GUI only accept images with a rootfs equal or larger than the first firmware shipped - * for the device, we need to pad rootfs partition to this size. To perform further calculations, we - * decide the size of this part here. In case the rootfs we want to integrate in our image is larger, - * take it's size, otherwise the supplied size. - * - * Be careful! We rely on assertion of correct size to be performed beforehand. It is unknown if images - * with a to large rootfs are accepted or not. - */ -rootfs_out.size = rootfs_size < rootfs.size ? rootfs.size : rootfs_size; return build_image(); } ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] target: bump minimum CPU type to pentium-mmx
On 1/12/20 5:44 AM, Rosen Penev wrote: > f4f8f4a180366ee90fd8e153213db2cb746ca361 broke ffmpeg compilation with x86 > > The reason is that ffmpeg's x86 assembly requires at least MMX, which the > pentium CPU_TYPE was preventing. As far as I understand it MMX is already needed and you just want to rename the toolchain from pentium to pentium_mmx, is this correct? > > Fixes ffmpeg compilation on x86_legacy and x86_geode. > > Signed-off-by: Rosen Penev > --- > include/target.mk | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/target.mk b/include/target.mk > index a813ba2d2d..a30400c5bc 100644 > --- a/include/target.mk > +++ b/include/target.mk > @@ -177,8 +177,8 @@ ifeq ($(DUMP),1) > CPU_CFLAGS_octeonplus = -march=octeon+ -mabi=64 >endif >ifeq ($(ARCH),i386) > -CPU_TYPE ?= pentium > -CPU_CFLAGS_pentium = -march=pentium-mmx > +CPU_TYPE ?= pentium-mmx > +CPU_CFLAGS_pentium-mmx = -march=pentium-mmx > CPU_CFLAGS_pentium4 = -march=pentium4 >endif >ifneq ($(findstring arm,$(ARCH)),) > signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Next maintenance releases
Rosen Penev [2020-02-21 14:55:55]: Hi, > I would like https://patchwork.ozlabs.org/patch/1221697/ to be applied. > It makes no sense to have broken functionality in the tree. thank you for taking care, but I'm not going to merge this into 19.07. It looks like it doesn't fix anything, "just" a build failure of ffmpeg by not building it. ffmpeg won't build even after this change, so I don't see a point of this change in the stable release, in sensitive toolchain area, which might potentialy introduce some regression in other parts. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] R: Next maintenance releases
Lech Perczak [2020-02-22 01:30:53]: > > https://github.com/openwrt/openwrt/pull/2769 > > Can this be merged? It fix important performance problem for ipq806x Done, once it passes the build test, I'm going to push it. > I'd very much like to see this merged too: > https://github.com/openwrt/openwrt/pull/2683 > As I stated in PR: > Tested-By: Lech Perczak Done, once it passes the build test, I'm going to push it. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Some questions - help needed
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of mans0n > Sent: Samstag, 22. Februar 2020 13:25 > To: openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] Some questions - help needed > > Hi, > > I can't find the answers on my own, so I'm seeking help here. Any opinions > would be appreciated. > > 1. I found that currently four devices have set DEVICE_TYPE to nas in their > Device definition. > But when I tried defconfig, none of them actually had > DEFAULT_PACKAGES.nas in their .config. > It seems DEVICE_TYPE cannot be set per device, it only works on a per- > (sub)target basis. > Then why DEVICE_TYPE was added to these devices? > https://github.com/openwrt/openwrt/commit/7a1497fd601d8803f60845034 > 4113db2bdc470e7 > Is this intended or a bug? to make a variable "per-device", you have to add it to DEVICE_VARS, e.g. DEVICE_VARS += DEVICE_TYPE Based on a quick grep, I haven't found this anywhere. If this is not done, the variable will have the state of the latest assignment for _all_ devices, i.e. the last device setting it will determine the value for all devices. When looking through the targets, it seems like DEVICE_TYPE has been partially used target-wide and partially device-specifically, where the latter is a misuse IMO (or in your words, a "bug"). The easiest option would be to add this to DEVICE_VARS for all targets directly in include/target.mk. However, that would be a little shady as there the variable DEVICE_TYPE would still be set in a global context, while it is then overwritten per-device. In contrast, the classical case of a device-specific variable is DEVICE_DTS, where default values are not set globally in include/target.mk, but in Device/Default for each target separately (if required). > > 2. kmod-usb2 automatically selects kmod-usb-core, but kmod-ata-ahci does > not select kmod-ata-core. > Is there a reason to use "DEPENDS += +kmod-usb-core" somewhere and use > "DEPENDS += kmod-ata-core" elsewhere? > Can we make a rule here to unify this? This somehow depends on the organization of those options, where one is nested and the other isn't (in make menuconfig). I've once tried to solve this for the same problem but with kmod-i2c-core IIRC, and then quit at some point because I couldn't find the initial source of the problem. From my point of view, you are very welcome to solve this mystery. Best Adrian > > 3. Could somebody suggest a way to configure port 1 as WAN in ipq40xx DTS? > https://forum.openwrt.org/t/how-can-i-configure-port-1-as-wan-on- > ipq40xx/54783 > > Thanks in advance. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Some questions - help needed
Hi, I can't find the answers on my own, so I'm seeking help here. Any opinions would be appreciated. 1. I found that currently four devices have set DEVICE_TYPE to nas in their Device definition. But when I tried defconfig, none of them actually had DEFAULT_PACKAGES.nas in their .config. It seems DEVICE_TYPE cannot be set per device, it only works on a per-(sub)target basis. Then why DEVICE_TYPE was added to these devices? https://github.com/openwrt/openwrt/commit/7a1497fd601d8803f608450344113db2bdc470e7 Is this intended or a bug? 2. kmod-usb2 automatically selects kmod-usb-core, but kmod-ata-ahci does not select kmod-ata-core. Is there a reason to use "DEPENDS += +kmod-usb-core" somewhere and use "DEPENDS += kmod-ata-core" elsewhere? Can we make a rule here to unify this? 3. Could somebody suggest a way to configure port 1 as WAN in ipq40xx DTS? https://forum.openwrt.org/t/how-can-i-configure-port-1-as-wan-on-ipq40xx/54783 Thanks in advance. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Next maintenance releases
Karl Palsson [2020-02-21 13:14:29]: Hi, > I would very much like to see > https://bugs.openwrt.org/index.php?do=details&task_id=2833 merged > (it contains a fix and tests) for 19.07, as it fixes a regression > in behaviour there. (umdns stopped working) [puting aside the fact, that the patches weren't send via the standard way[1] so they weren't reviewed yet] please note, that this proposed fix is not included in the master yet, thus untested by the wider audience and you're requesting inclusion into stable release 19.07. > I've tested the fix locally at least I'm always testing everything, preferably with unit tests, runtime tests, but it's still quite common in the software universe, that one fix introduces two or more regressions in other parts, so I'm really unsure whether I'm going to merge this into stable release just a few hours before the point release. IIRC something similar has been done with last minute CVE fixes before 19.07.0, which didnt worked well. 1. https://openwrt.org/submitting-patches -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ppp: activate PIE ASLR by default
On 2020-02-22 10:22, Stijn Tintel wrote: > On 22/02/2020 11:10, Felix Fietkau wrote: >> On 2020-02-22 09:54, Stijn Tintel wrote: >>> On 20/02/2020 11:56, Petr Štetiar wrote: This activates PIE ASLR support by default when the regular option is selected. >>> Unfortunately this seems to break build on x86/64: >>> >>> x86_64-openwrt-linux-musl-gcc -O2 -pipe -fno-caller-saves -fno-plt >>> -fhonour-copts -Wno-error=unused-but-set-variable >>> -Wno-error=unused-result >>> -ffile-prefix-map=/home/stijn/Development/LEDE/source/build_dir/target-x86_64_musl/linux-x86_64/ppp-default/ppp-2.4.8=ppp-2.4.8 >>> -Wformat -Werror=format-security -fpic -fstack-protector-strong >>> -D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro -ffunction-sections >>> -fdata-sections -flto -DHAVE_PATHS_H -DHAVE_MMAP -I../include >>> '-DDESTDIR="/usr"' -DCHAPMS=1 -DMPPE=1 -DHAS_SHADOW -DHAVE_CRYPT_H=1 >>> -DUSE_CRYPT=1 -DPLUGIN -DPPP_FILTER -DPPP_PRECOMPILED_FILTER >>> -I/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/include >>> -DINET6=1 -DMAXOCTETS >>> -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib >>> -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/lib >>> -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib >>> -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib >>> -fpic >>> -specs=/home/stijn/Development/LEDE/source/include/hardened-ld-pie.specs >>> -znow -zrelro -Wl,--gc-sections -flto -fuse-linker-plugin -Wl,-E -o >>> pppd main.o magic.o fsm.o lcp.o ipcp.o upap.o chap-new.o md5.o ccp.o >>> ecp.o auth.o options.o demand.o utils.o sys-linux.o ipxcp.o tty.o eap.o >>> chap-md5.o session.o md4.o chap_ms.o sha1.o pppcrypt.o pcap_pcc.o >>> ipv6cp.o eui64.o -lcrypt -ldl >>> /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a >>> /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: >>> /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a(bpf_filter.c.o): >>> relocation R_X86_64_32S against `.rodata' can not be used when making a >>> PIE object; recompile with -fPIC >>> /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: >>> final link failed: nonrepresentable section on output >>> collect2: error: ld returned 1 exit status >>> >>> So NACK from me until this is fixed. >> This one can most likely be fixed by setting PKG_ASLR_PIE_REGULAR:=1 in >> libpcap as well. That way -fPIC gets passed for the static library build. >> > Interesting. I've added this in the libpcap Makefile and that seems to > fix it. But I am actually building with CONFIG_PKG_ASLR_PIE_ALL=y, so > would assume it would enable PIE even if PKG_ASLR_PIE_REGULAR is not set > in the Makefile. Anyway, I'll send a patch for libpcap, thanks for the > suggestion. Maybe it was built before you made that config change? It seems to me that the ALSR_PIE stuff is missing some PKG_CONFIG_DEPENDS handling. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] libpcap: activate PIE ASLR by default
This activates PIE ASLR support by default when the regular option is selected. This is required to enable PIE ASLR support by default in ppp, as it fails to build without it, on x86/64. The .so file size stays identical. Suggested-by: Felix Fietkau Signed-off-by: Stijn Tintel --- package/libs/libpcap/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/package/libs/libpcap/Makefile b/package/libs/libpcap/Makefile index 69af9d0700..1a2cdcdd98 100644 --- a/package/libs/libpcap/Makefile +++ b/package/libs/libpcap/Makefile @@ -19,6 +19,7 @@ PKG_HASH:=635237637c5b619bcceba91900666b64d56ecb7be63f298f601ec786ce087094 PKG_MAINTAINER:=Felix Fietkau CMAKE_INSTALL:=1 +PKG_ASLR_PIE_REGULAR:=1 PKG_BUILD_PARALLEL:=1 PKG_LICENSE:=BSD-3-Clause -- 2.24.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ppp: activate PIE ASLR by default
On 22/02/2020 11:10, Felix Fietkau wrote: > On 2020-02-22 09:54, Stijn Tintel wrote: >> On 20/02/2020 11:56, Petr Štetiar wrote: >>> This activates PIE ASLR support by default when the regular option is >>> selected. >>> >> Unfortunately this seems to break build on x86/64: >> >> x86_64-openwrt-linux-musl-gcc -O2 -pipe -fno-caller-saves -fno-plt >> -fhonour-copts -Wno-error=unused-but-set-variable >> -Wno-error=unused-result >> -ffile-prefix-map=/home/stijn/Development/LEDE/source/build_dir/target-x86_64_musl/linux-x86_64/ppp-default/ppp-2.4.8=ppp-2.4.8 >> -Wformat -Werror=format-security -fpic -fstack-protector-strong >> -D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro -ffunction-sections >> -fdata-sections -flto -DHAVE_PATHS_H -DHAVE_MMAP -I../include >> '-DDESTDIR="/usr"' -DCHAPMS=1 -DMPPE=1 -DHAS_SHADOW -DHAVE_CRYPT_H=1 >> -DUSE_CRYPT=1 -DPLUGIN -DPPP_FILTER -DPPP_PRECOMPILED_FILTER >> -I/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/include >> -DINET6=1 -DMAXOCTETS >> -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib >> -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/lib >> -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib >> -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib >> -fpic >> -specs=/home/stijn/Development/LEDE/source/include/hardened-ld-pie.specs >> -znow -zrelro -Wl,--gc-sections -flto -fuse-linker-plugin -Wl,-E -o >> pppd main.o magic.o fsm.o lcp.o ipcp.o upap.o chap-new.o md5.o ccp.o >> ecp.o auth.o options.o demand.o utils.o sys-linux.o ipxcp.o tty.o eap.o >> chap-md5.o session.o md4.o chap_ms.o sha1.o pppcrypt.o pcap_pcc.o >> ipv6cp.o eui64.o -lcrypt -ldl >> /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a >> /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: >> /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a(bpf_filter.c.o): >> relocation R_X86_64_32S against `.rodata' can not be used when making a >> PIE object; recompile with -fPIC >> /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: >> final link failed: nonrepresentable section on output >> collect2: error: ld returned 1 exit status >> >> So NACK from me until this is fixed. > This one can most likely be fixed by setting PKG_ASLR_PIE_REGULAR:=1 in > libpcap as well. That way -fPIC gets passed for the static library build. > Interesting. I've added this in the libpcap Makefile and that seems to fix it. But I am actually building with CONFIG_PKG_ASLR_PIE_ALL=y, so would assume it would enable PIE even if PKG_ASLR_PIE_REGULAR is not set in the Makefile. Anyway, I'll send a patch for libpcap, thanks for the suggestion. Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ppp: activate PIE ASLR by default
On 2020-02-22 09:54, Stijn Tintel wrote: > On 20/02/2020 11:56, Petr Štetiar wrote: >> This activates PIE ASLR support by default when the regular option is >> selected. >> > Unfortunately this seems to break build on x86/64: > > x86_64-openwrt-linux-musl-gcc -O2 -pipe -fno-caller-saves -fno-plt > -fhonour-copts -Wno-error=unused-but-set-variable > -Wno-error=unused-result > -ffile-prefix-map=/home/stijn/Development/LEDE/source/build_dir/target-x86_64_musl/linux-x86_64/ppp-default/ppp-2.4.8=ppp-2.4.8 > -Wformat -Werror=format-security -fpic -fstack-protector-strong > -D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro -ffunction-sections > -fdata-sections -flto -DHAVE_PATHS_H -DHAVE_MMAP -I../include > '-DDESTDIR="/usr"' -DCHAPMS=1 -DMPPE=1 -DHAS_SHADOW -DHAVE_CRYPT_H=1 > -DUSE_CRYPT=1 -DPLUGIN -DPPP_FILTER -DPPP_PRECOMPILED_FILTER > -I/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/include > -DINET6=1 -DMAXOCTETS > -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib > -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/lib > -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib > -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib > -fpic > -specs=/home/stijn/Development/LEDE/source/include/hardened-ld-pie.specs > -znow -zrelro -Wl,--gc-sections -flto -fuse-linker-plugin -Wl,-E -o > pppd main.o magic.o fsm.o lcp.o ipcp.o upap.o chap-new.o md5.o ccp.o > ecp.o auth.o options.o demand.o utils.o sys-linux.o ipxcp.o tty.o eap.o > chap-md5.o session.o md4.o chap_ms.o sha1.o pppcrypt.o pcap_pcc.o > ipv6cp.o eui64.o -lcrypt -ldl > /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a > /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: > /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a(bpf_filter.c.o): > relocation R_X86_64_32S against `.rodata' can not be used when making a > PIE object; recompile with -fPIC > /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: > final link failed: nonrepresentable section on output > collect2: error: ld returned 1 exit status > > So NACK from me until this is fixed. This one can most likely be fixed by setting PKG_ASLR_PIE_REGULAR:=1 in libpcap as well. That way -fPIC gets passed for the static library build. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ppp: activate PIE ASLR by default
On 20/02/2020 11:56, Petr Štetiar wrote: > This activates PIE ASLR support by default when the regular option is > selected. > Unfortunately this seems to break build on x86/64: x86_64-openwrt-linux-musl-gcc -O2 -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -ffile-prefix-map=/home/stijn/Development/LEDE/source/build_dir/target-x86_64_musl/linux-x86_64/ppp-default/ppp-2.4.8=ppp-2.4.8 -Wformat -Werror=format-security -fpic -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro -ffunction-sections -fdata-sections -flto -DHAVE_PATHS_H -DHAVE_MMAP -I../include '-DDESTDIR="/usr"' -DCHAPMS=1 -DMPPE=1 -DHAS_SHADOW -DHAVE_CRYPT_H=1 -DUSE_CRYPT=1 -DPLUGIN -DPPP_FILTER -DPPP_PRECOMPILED_FILTER -I/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/include -DINET6=1 -DMAXOCTETS -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib -L/home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/lib -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/stijn/Development/LEDE/source/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -fpic -specs=/home/stijn/Development/LEDE/source/include/hardened-ld-pie.specs -znow -zrelro -Wl,--gc-sections -flto -fuse-linker-plugin -Wl,-E -o pppd main.o magic.o fsm.o lcp.o ipcp.o upap.o chap-new.o md5.o ccp.o ecp.o auth.o options.o demand.o utils.o sys-linux.o ipxcp.o tty.o eap.o chap-md5.o session.o md4.o chap_ms.o sha1.o pppcrypt.o pcap_pcc.o ipv6cp.o eui64.o -lcrypt -ldl /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: /home/stijn/Development/LEDE/source/staging_dir/target-x86_64_musl/usr/lib/libpcap.a(bpf_filter.c.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.3.0/../../../../x86_64-openwrt-linux-musl/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status So NACK from me until this is fixed. Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
