[OpenWrt-Devel] cherry-pick wolfssl-3.15.7 update to 19.07
Can someone please cherry-pick this to 19.07: 2792daab5a wolfssl: update to 3.15.7, fix Makefile This includes a fix for a medium-level potential cache attack with a variant of Bleichenbacher’s attack. Patches were refreshed. Increased FP_MAX_BITS to allow 4096-bit RSA keys. Fixed poly1305 build option, and some Makefile updates. Signed-off-by: Eneas U de Queiroz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wolfssl: fix PKG_HASH
I forgot to mention it, but this is fix is for 19.07 only. Eneas Em seg, 8 de jul de 2019 às 11:20, Eneas U de Queiroz escreveu: > > Commit 3167a57 missed it. > > Signed-off-by: Eneas U de Queiroz > > diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile > index 7aaa562539..264be02496 100644 > --- a/package/libs/wolfssl/Makefile > +++ b/package/libs/wolfssl/Makefile > @@ -13,7 +13,7 @@ PKG_RELEASE:=1 > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz > PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) > -PKG_HASH:=dc97c07a7667b39a890e14f4b4a209f51524a4cabee7adb6c80822ee78c1f62a > +PKG_HASH:=70e4fbeb91284a269b25a84fc526755c670475aee4034a6f237b1f754d108af3 > > PKG_FIXUP:=libtool > PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ramips/rt**** and kernel 5.4
Hi On Sat, Aug 1, 2020 at 10:54 AM wrote: > > Hi, > > with a 20.xx branch coming closer, we still have 3 of 6 ramips subtargets > (rt288x, rt305x, rt3883) on kernel 4.14 by default (though 5.4 testing > support is available in principle). > > I've recently tried to build those with 5.4 and buildbot settings (including > packages), they all compile nicely (4M devices have already been disabled) > out-of-the-box. > > However, I don't have any devices for these platforms, and I have not > followed the ramips 5.4 transitions closely enough to know which problems > might appear on the devices. > > At the moment, we have the following number of supported devices (i.e. > 4M): > rt288x: 1 device > rt305x: 57 devices > rt3883: 10 devices I've tested 5.4 (a3ffeb413b to be precise) with an Asus RT-N56U (rt3883) lightly, and all appears to be in order. It is a backup remote AP with light traffic. There is nothing unusual in the logs, and the single client I have there can connect fine. I imagine this would be enough to avoid dropping support for rt3883. Cheers, Eneas > > So, any input on the situation on those platform and/or on-device testing > would be quite helpful. > > Otherwise, we would have to drop these subtargets for 20.xx release. > > Best > > Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ramips/rt**** and kernel 5.4
On Thu, Aug 6, 2020 at 6:13 PM Adrian Schmutzler wrote: > > > I've tested 5.4 (a3ffeb413b to be precise) with an Asus RT-N56U > > (rt3883) lightly, and all appears to be in order. It is a backup remote AP > > with > > light traffic. There is nothing unusual in the logs, and the single client > > I have > > there can connect fine. I imagine this would be enough to avoid dropping > > support for rt3883. > > Thanks, perfect, would you provide a Tested-by? > > Best > > Adrian Tested-by: Eneas U de Queiroz [rt3883/Asus RT-N56U] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ipq40xx: QCE/crypto fixes & enhancements (PR #2518)
Hi I have finished working on https://github.com/openwrt/openwrt/pull/2518, fixing some bugs with the crypto engine, and adding asm modules to crypto algorithms, since the engine is not very fast when using "network-sized" (<1500-bytes) requests. Since it's been started a while back, it appears on page 4 of the PR list, so I'm sending a note here so that people can review it. Can someone please remove the "RFC" and "work in progress" labels, since I can't do that myself. Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ipq40xx: QCE/crypto fixes & enhancements (PR #2518)
On Wed, Feb 26, 2020 at 10:48 AM Paul Oranje wrote: > > Having read the whole conversation: an impressive piece of work. > > Could this helps with ipq806x ? > On ipq806x qce isn't available on all SOCs (supposedly only on ipq8064) and > therefore support has been removed from the kernel [1]. > > > [1] commit ad07166ea7286f350628f1093e4385db9be63d31 (ipq806x: remove > unsupported hw-crypto qce driver) > > Regards, > Paul > Hi Paul I'm glad you like it, thanks. I don't know much about the ipq8064 crypto engine, other than it is not compatible with the ipq40xx one, and that's why I removed it from the image. I looked into it superficially, but couldn't find much information about it. What we can do right away is to enable the neon/arm-asm modules, as I did for ipq40xx. I'll wait for ipq40xx's fate, before I apply the same logic to ipq806x, and perhaps others. If I were to just grep for CONFIG_NEON=y, but not CONFIG_ARM_CRYPTO=y: $ git grep -L '^CONFIG_ARM_CRYPTO=y' -- $(git grep -l '^CONFIG_NEON=y' -- target/linux/) | xargs -r dirname | sort -u target/linux/armvirt/32 target/linux/at91 target/linux/bcm27xx/bcm2709 target/linux/ipq40xx target/linux/ipq806x target/linux/layerscape/armv7 target/linux/mediatek/mt7623 target/linux/omap target/linux/samsung/s5pv210 target/linux/sunxi target/linux/zynq Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] build: update scritps/config to kconfig-v5.6
On Tue, Apr 7, 2020 at 5:19 AM Petr Štetiar wrote: > > Eneas U de Queiroz [2020-04-06 17:10:30]: > > Hi, > > > TLDR: You can't review this by only looking at the patches. > > Just tried to build[1] test it on x86/64 sunxi/a53 imx6 ipq40xx and it fails > to build: > > make -s -C scripts/config conf CC=cc: build failed. > > 1. https://gitlab.com/ynezz/openwrt/pipelines/133543034 > > -- ynezz Thanks for trying to test this. I'm in the dark here with exactly what went wrong, but I've caught an oversight on my part: Linux now requires flex & bison to build files that it used to ship prebuilt. I can either restore the previous behavior, or we can require them as well, and then I'll add a check for them--and later perhaps remove them from tools/? What do you think? BTW, here's the output of that make subcommand if you take out '-s' in include/toplevel.mk:107: cc -O2 -c -o conf.o conf.c cc -O2 -c -o confdata.o confdata.c cc -O2 -c -o expr.o expr.c bison -l -d -b parser parser.y flex -L -olexer.lex.c lexer.l cc -O2 -I ./. -c -o lexer.lex.o lexer.lex.c cc -O2 -I ./. -c -o parser.tab.o parser.tab.c cc -O2 -c -o preprocess.o preprocess.c cc -O2 -c -o symbol.o symbol.c cc -O2 -c -o util.o util.c cc conf.o confdata.o expr.o lexer.lex.o parser.tab.o preprocess.o symbol.o util.o -o conf rm lexer.lex.c That's why I assume it's missing bison & flex. Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Phase2 packages buildbot has failed since the kconfig changes
Hi
On Sat, Apr 11, 2020 at 11:07 AM Hannu Nyman wrote:
>
> Looks like the recent kconfig changes broke the whole packages buildbot.
>
> (For some weird reason, the arc targets succeed, but all others fail
> miserably... )
>
>
> http://buildbot.openwrt.org/master/packages/grid
>
> http://buildbot.openwrt.org/master/packages/one_line_per_build
>
>
> Some of errors in the logs are possibly related to the TARGET_MULTI_PROFILE
> error preventing some default packages, and for that bug there is already a
> proposed patch.
This should be fixed with https://patchwork.ozlabs.org/patch/1268895/.
Tell me if it does not work.
>
> But most errors seem to be related to recursive errors inside the rather
> complex mac80211 wifi driver collection. I have a hunch that for buildbot the
> "treat recursive dependencies as warnings instead of errors" option (from
> 3204430e3 ) should be activated in the config binary, or alternatively some
> major work for re-organising the mac80211 submodule dependencies needs to be
> done.
Yes, I've added the WARN_RECURSIVE_DEP option to be used by the bots.
I wasn't sure if this option should be default or not. My reasoning
was that erroring out would make it harder for new circular
dependencies to creep in, and bots could run with it on.
Clean the scripts/config directory with make config-clean (if bots
don't start with a clean slate), then add WARN_RECURSIVE_DEP=1 to the
bots make flags.
Most of the time, the recursive dependencies reported by config the
ones causing the trouble. It usually occur because some package
selects (DEPENDS= +) another package that depends on another
symbol without either selecting the symbol (DEPENDS=+ +) or
only selecting the package if symbol is on (DEPENDS=+:).
The most common case is a package selecting a module that depends on
some global feature. The ones I've fixed in 2e6b6f9fca ("kernel: add
@IPV6 dependency to ipv6 modules") had kmod packages selecting ipv6
modules without checking if CONFIG_IPV6 is enabled or not.
>
> Example:
>
> http://buildbot.openwrt.org/master/packages/builders/mips_24kc/builds/219/steps/compile/logs/stdio
>
>
>
> Config-build.in:10377:error: recursive dependency detected!
> Config-build.in:10377: symbol PACKAGE_kmod-cfg80211 depends on
> PACKAGE_kmod-cfg80211
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> Config-build.in:10273:error: recursive dependency detected!
> Config-build.in:10273: symbol PACKAGE_kmod-b43 depends on PACKAGE_kmod-b43
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> tmp/.config-package.in:10656:error: recursive dependency detected!
> tmp/.config-package.in:10656: symbol PACKAGE_kmod-acx-mac80211 depends on
> PACKAGE_kmod-acx-mac80211
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> Config-build.in:10665:error: recursive dependency detected!
> Config-build.in:10665: symbol PACKAGE_kmod-wl18xx depends on
> PACKAGE_kmod-wl18xx
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> tmp/.config-package.in:11992:error: recursive dependency detected!
> tmp/.config-package.in:11992: symbol PACKAGE_kmod-mwlwifi depends on
> PACKAGE_kmod-mwlwifi
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> Config-build.in:8941:error: recursive dependency detected!
> Config-build.in:8941: symbol PACKAGE_kmod-batman-adv depends on
> PACKAGE_kmod-batman-adv
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> Config-build.in:10501:error: recursive dependency detected!
> Config-build.in:10501: symbol PACKAGE_kmod-mwifiex-sdio depends on
> PACKAGE_kmod-mwifiex-sdio
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> Config-build.in:10545:error: recursive dependency detected!
> Config-build.in:10545: symbol PACKAGE_kmod-rt2400-pci depends on
> PACKAGE_kmod-rt2400-pci
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> Config-build.in:10425:error: recursive dependency detected!
> Config-build.in:10425: symbol PACKAGE_kmod-mac80211 depends on
> PACKAGE_kmod-mac80211
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> Config-build.in:10229:error: recursive dependency detected!
> Config-build.in:10229: symbol PACKAGE_kmod-ath10k-ct-smallbuffers depends on
> PACKAGE_kmod-ath10k-ct-smallbuffers
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitati
Re: [OpenWrt-Devel] Phase2 packages buildbot has failed since the kconfig changes
It would be easier if I could reproduce the bug locally. I would like to take a look at the failed 'Config-build.in' (haven't seen this file ever), and 'tmp/.config-package.in'. Meanwhile, I will try my luck with the SDK, which I don't do very often myself. Do the phase1 bots have the feeds enabled? Perhaps something in the packages feed generates the unmet direct dependency. I recall python bluetooth module picking up kmod-bluetooth without checking one of its dependencies (USB_SUPPORT, perhaps). Anyway, I hope I can find out something by looking at the config.in sources. On Sat, Apr 11, 2020 at 1:17 PM Hannu Nyman wrote: > > Hannu Nyman kirjoitti 11.4.2020 klo 17.07: > > > > But most errors seem to be related to recursive errors inside the rather > > complex mac80211 wifi driver collection. I have a hunch that for buildbot > > the "treat recursive dependencies as warnings instead of errors" option > > (from 3204430e3 ) should be activated in the config binary, or > > alternatively some major work for re-organising the mac80211 submodule > > dependencies needs to be done. > > > > One interesting aspect: > > The kmod related errors surface in the phase2 buildbot that uses SDK to > compile non-kernel packages. The kernel and related packages are built by the > phase1 images buildbot that also builds the SDK, so this phase2 packages > buildbot should not even touch the kmods. But still the recursive config > error realted to them apparently break the buildbot run. > > That makes me wonder if the current settings have wider impact on SDK usage. > Possibly the SDK reacts badly to the current config logic. (Personally I only > compile with the full toolchain, so I have no experience with the SDK.) > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 0/6] build: update scritps/config to kconfig-v5.6
On Sat, Apr 11, 2020 at 7:23 PM Jo-Philipp Wich wrote: > > Hi Eneas, > > I am sorry but I had to completely revert the kconfig bump. It thoroughly > broke the package repository builds since multiple days and the fatal > recursive dependencies make it a no-go for master, at least as far as our > build infrastructure is concerned. > > Right now, a single malformed feed package can entirely break the builder, > across all architectures. > > I am happy to reapply it but first we have to figure out why things like > http://builds.openwrt.org/master/packages/builders/arm_fa526/builds/224/steps/compile/logs/stdio > happen and how we can prevent them in the future. > > I'm also strongly in favor of making recursive deps a warning, at least when > CONFIG_BUILDBOT=y. > > Regards, > Jo Hi I'm really sorry--and embarrassed, really--to have caused all this trouble. I'll see what I can do from here, but I'm not familiar enough with the build bot system to do much on my own--and that was the origin of all problems. As for the recursive dependency warning/error, at first I thought about using CONFIG_BUILDBOT but then scripts/config/conf may be built before .config even exist. I added a make option, so the bots could just add WARN_RECURSIVE_DEPS=1 to the make args. Even changing the recursive dep to a warning would not have been enough to overcome this, for example: feeds/base/package/utils/busybox/config/Config.in:712: invalid statement I'm not sure if the feeds/base/package structure is the same as $(TOPDIR)/package, but 1da014f should have quoted the source filenames in package/utils/busybox/config/Config.in. Does anybody have any suggestion about how this could be moved forward? Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: always use -minterlink-mips16 if USE_MIPS16
On Mon, May 25, 2020 at 5:06 AM Felix Fietkau wrote: > > On 2020-05-25 02:19, Eneas U de Queiroz wrote: > > Individual packages may turn off MIPS16 ISA individually with > > PKG_USE_MIPS16. However, they may link to a library compiled with > > MIPS16. In such cases, the -minterlink-mips16 is needed to ensure there > > are no direct jumps to code compiled with a different ISA. > > > > Instead of adding -minterlink-mips16 only when PKG_USE_MIPS16 is on, add > > it when global USE_MIPS16 is on. > > > > Signed-off-by: Eneas U de Queiroz > > --- > > Tested by compiling all packages in base, packages, routing and > > telephony feeds for mips_74kc, with MIPS16 enabled. > > > > This was discovered while working on lxc fixes > > (https://github.com/openwrt/packages/pull/12241), where compilation with > > mips16 would fail because of '-fstack-check=specific not implemented for > > MIPS16', and it would fail with PKG_USE_MIPS16=0 because of jumping to a > > different ISA mode: > > > > lxc-4.0.2/src/lxc/caps.c:24:(.text+0xa4): unsupported jump between ISA > > modes; consider recompiling with interlinking enabled > > > > In theory this could happen in more places, so set interlinking on > > whenever MIPS16 is turned on globally. > I think there needs be a way to opt-out of this behavior. > The -minterlink-mips16 flag affects the performance and code size of > generated code, so libraries that disable MIPS16 for performance reasons > and don't depend on other MIPS16 enabled libraries should not be > compiled with this flag. > > - Felix Let's leave it as is, then. Right now this failure appears to be an exception, not a rule. Packages can opt-in by adding the -minterlink-mips16 flag themselves, as was done with lxc. Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH ustream-ssl v2 3/3] wolfssl: enable CN validation
I just realized now that my reply went to Hauke only, so I'm sending
it again to the mailing list, as it may be useful for more people.
On Fri, Sep 20, 2019 at 5:43 PM Hauke Mehrtens wrote:
>
> On 9/19/19 4:18 AM, Eneas U de Queiroz wrote:
> > WolfSSL added a wolfSSL_X509_check_host function to perform CN
> > validation in v3.10.4, depending on the build-time configure options:
> > --enable-nginx enables it for all supported versions;
> > --enable-opensslextra, since v3.14.2.
> >
> > If the function is unavailable, then SSL_get_verify_result will be
> > called, and 'valid_cert' will be true if that call suceeds and we
> > have a peer certificate, just as it happens with openssl. Only
> > 'valid_cn' will not be set.
> >
> > Signed-off-by: Eneas U de Queiroz
> >
> > diff --git a/CMakeLists.txt b/CMakeLists.txt
> > index 6b3fc8c..86e1b07 100644
> > --- a/CMakeLists.txt
> > +++ b/CMakeLists.txt
> > @@ -21,6 +21,12 @@ ELSEIF(WOLFSSL)
> >IF (NOT HAVE_WOLFSSL_SSLSETIORECV)
> > ADD_DEFINITIONS(-DNO_WOLFSSL_SSLSETIO_SEND_RECV)
> >ENDIF()
> > + CHECK_SYMBOL_EXISTS (wolfSSL_X509_check_host
> > +"wolfssl/options.h;wolfssl/ssl.h"
> > +HAVE_WOLFSSL_X509_CHECK_HOST)
> > + IF (NOT HAVE_WOLFSSL_X509_CHECK_HOST)
> > +ADD_DEFINITIONS(-DNO_X509_CHECK_HOST)
> > + ENDIF()
> > ELSE()
> >SET(SSL_SRC ustream-io-openssl.c ustream-openssl.c)
> >SET(SSL_LIB crypto ssl)
> > diff --git a/ustream-openssl.c b/ustream-openssl.c
> > index 21abf61..c830618 100644
> > --- a/ustream-openssl.c
> > +++ b/ustream-openssl.c
> > @@ -203,7 +203,7 @@ static void ustream_ssl_error(struct ustream_ssl *us,
> > int ret)
> > uloop_timeout_set(&us->error_timer, 0);
> > }
> >
> > -#ifndef WOLFSSL_OPENSSL_H_
> > +#ifndef NO_X509_CHECK_HOST
> >
> > static bool ustream_ssl_verify_cn(struct ustream_ssl *us, X509 *cert)
> > {
> > @@ -212,10 +212,15 @@ static bool ustream_ssl_verify_cn(struct ustream_ssl
> > *us, X509 *cert)
> > if (!us->peer_cn)
> > return false;
> >
> > +# ifndef WOLFSSL_OPENSSL_H_
> > ret = X509_check_host(cert, us->peer_cn, 0,
> > X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS, NULL);
> > +# else
> > + ret = wolfSSL_X509_check_host(cert, us->peer_cn, 0, 0, NULL);
> > +# endif
> > return ret == 1;
> > }
> >
> > +#endif
> >
> > static void ustream_ssl_verify_cert(struct ustream_ssl *us)
> > {
> > @@ -235,11 +240,12 @@ static void ustream_ssl_verify_cert(struct
> > ustream_ssl *us)
> > return;
> >
> > us->valid_cert = true;
> > +#ifndef NO_X509_CHECK_HOST
> > us->valid_cn = ustream_ssl_verify_cn(us, cert);
> > +#endif
> > X509_free(cert);
> > }
> >
> > -#endif
> >
> > __hidden enum ssl_conn_status __ustream_ssl_connect(struct ustream_ssl *us)
> > {
> > @@ -252,9 +258,7 @@ __hidden enum ssl_conn_status
> > __ustream_ssl_connect(struct ustream_ssl *us)
> > r = SSL_connect(ssl);
> >
> > if (r == 1) {
> > -#ifndef WOLFSSL_OPENSSL_H_
> > ustream_ssl_verify_cert(us);
> > -#endif
> > return U_SSL_OK;
> > }
>
> I am getting this error message with this patch:
>
> [ 12%] Building C object CMakeFiles/ustream-ssl.dir/ustream-ssl.c.o
> In file included from
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-internal.h:27:0,
> from
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-ssl.c:25:
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-openssl.h:
> In function '__ustream_ssl_set_server_name':
> /home/hauke/openwrt/openwrt/build_dir/target-mipsel_24kc_musl/ustream-ssl-wolfssl/ustream-ssl-2019-08-17-e8f9c22d/ustream-openssl.h:48:2:
> error: implicit declaration of function 'SSL_set_tlsext_host_name'; did
> you mean 'SSL_set_tlsext_debug_arg'? [-Werror=implicit-function-declaration]
> SSL_set_tlsext_host_name(us->ssl, us->server_name);
> ^~~~
> SSL_set_tlsext_debug_arg
> cc1: all warnings being treated as errors
> make[6]: *** [CMakeFiles/ustream-ssl.dir/build.make:63:
> CMakeFiles/ustream-ssl.dir/ustream-ssl.c.o] Error 1
>
>
> and this config:
> CONFIG_WOLFSSL_HAS_AES_CCM=y
> CONFIG_WOLFSSL_HAS_ARC4=y
> CONFIG_WOLFSSL_HAS_CHACHA_POLY=y
> CONFIG_WOLFSSL_HAS_DH=y
> CONFIG_WOLFSSL_HAS_NO_HW=y
> CONFIG_WOLFSSL_HAS_OCSP=y
> CONFIG_WOLFSSL_HAS_SESSION_TICKET=y
> CONFIG_WOLFSSL_HAS_TLSV10=y
> CONFIG_WOLFSSL_HAS_TLSV13=y
> CONFIG_WOLFSSL_HAS_WPAS=y
>
>
> Hauke
>
>
I should have mentioned it before, but you need to update the
references from cyassl to wolfssl in openwrt to be able to compile it.
I will send the patch to openwrt once ustream-ssl is updated.
Meanwhile, this should do the trick:
--- a/package/libs/ustream-ssl/Makefile
+++ b/package/libs/ustream-ssl/Makefile
@@ -49,8 +49,8 @@ define Package
Re: [OpenWrt-Devel] [PATCH] openssl: bump to 1.1.1d
On Tue, Sep 17, 2019 at 10:52 AM Eneas U de Queiroz wrote: > > This version fixes 3 low-severity vulnerabilities: > > - CVE-2019-1547: ECDSA remote timing attack > - CVE-2019-1549: Fork Protection > - CVE-2019-1563: Padding Oracle in PKCS7_dataDecode and > CMS_decrypt_set1_pkey > > Patches were refreshed. > > Signed-off-by: Eneas U de Queiroz > > -- > Run-tested on WRT3200ACM, mvebu, running openwrt master, using uhttpd, > nginx, openssl-util, and uclient-fetch; devcrypto engine specifically > tested. > > This should be cherry-picked to openwrt-19.07 as well. > Can someone please cherry pick this to 19.07: d868d0a5d7e1d76bb1a8980346d222fae55fa18b If I should rather send a proper patch to list, please let me know. BR Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: fix hw-crypto detection of qce driver
On Fri, Sep 20, 2019 at 5:48 PM Eneas U de Queiroz wrote: > > This adds the CRYPTO_ALG_KERN_DRIVER_ONLY flag to Qualcomm crypto engine > driver algorithms, so that openssl devcrypto can recognize them as > hardware-accelerated. > > Signed-off-by: Eneas U de Queiroz I noticed this was moved to ipq40xx, but ipq806x is also enabling the qce driver: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/config-4.14#l119 So I imagine we need to either copy the patch to ipq806x, or disable the qce driver in ipq806x/config-4.14. I don't have enough knowledge to decide what to do, so can someone more knowledgeable, please, either do it or point me to the right direction. Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: fix hw-crypto detection of qce driver
On Mon, Sep 23, 2019 at 2:12 PM Rosen Penev wrote: > > On Mon, Sep 23, 2019 at 5:28 AM Eneas Queiroz wrote: > > > > On Fri, Sep 20, 2019 at 5:48 PM Eneas U de Queiroz > > wrote: > > > > > > This adds the CRYPTO_ALG_KERN_DRIVER_ONLY flag to Qualcomm crypto engine > > > driver algorithms, so that openssl devcrypto can recognize them as > > > hardware-accelerated. > > > > > > Signed-off-by: Eneas U de Queiroz > > > > I noticed this was moved to ipq40xx, but ipq806x is also enabling the > > qce driver: > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq806x/config-4.14#l119 > > > > So I imagine we need to either copy the patch to ipq806x, or disable > > the qce driver in ipq806x/config-4.14. I don't have enough knowledge > > to decide what to do, so can someone more knowledgeable, please, > > either do it or point me to the right direction. > Probably a mistake from the splitting of ipq targets (used to be just one). > > Also see: > > https://github.com/openwrt/openwrt/commit/fff65dbe2436351ea1feee6c79110971ec4d5881 I thought about that, but then I saw the specs here: https://www.qualcomm.com/products/ipq8064 It does list the crypto engine for ipq8064, but not for the rest of the ipq806x family. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig
This is still failing on gentoo. The problem is that when
scripts/config/lxdialog/check-lxdialog.sh is run, it will still use
the staging_dir/host/bin/pkg-config script without STAGING_PREFIX set.
See my suggestion below.
On Mon, Sep 23, 2019 at 4:39 AM Petr Štetiar wrote:
>
> On a recent Gentoo Linux installation, invoking `make kernel_menuconfig`
> in the build system fails, whereas `make menuconfig` in the kernel tree
> alone works as expected.
>
> This is happening because STAGING_PREFIX is not defined when kernel's
> menuconfig target calls pkg-config from the toolchain/host and thus
> pkg-config returns an empty value, and the fallback values in the kernel
> config script are applied but those are off and the linking fails.
>
> Solution is to use system's pkg-config for kernel_menuconfig target in
> order to provide proper compiler/linker flags.
>
> Ref: FS#2423
> Cc: Thomas Albers
> Signed-off-by: Petr Štetiar
> ---
>
> changes in v2:
>
> * fixed kernel_nconfig path
>
> Makefile| 1 +
> include/toplevel.mk | 8 +++-
> scripts/config/Makefile | 2 --
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ab97eacc9d2b..65ee10a84b8d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -18,6 +18,7 @@ $(if $(findstring $(space),$(TOPDIR)),$(error ERROR: The
> path to the OpenWrt dir
>
> world:
>
> +DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -E '\/usr' | head -n 1)
If we export this, then we can check its existence in
tools/pkg-config/files/pkg-config, and decide which pkg-config we want
to run.
The following is optional, since it already works as is, but I would
suggest not using `/usr` as a filter here; TOPDIR may be in /usr.
Instead, we can filter-out "staging_dir/host/bin", which is what we
are adding to PATH below:
export DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -vE
'/staging_dir/host/bin/pkg-config' | head -n 1)
Then, we can use the variable in our pkg-config script to decide what
to run, using just pkg-config.real as a fallback if nothing is defined
(alternatively, we can fail instead):
--- a/tools/pkg-config/files/pkg-config
+++ b/tools/pkg-config/files/pkg-config
@@ -1,3 +1,9 @@
#!/bin/sh
-pkg-config.real --define-variable=prefix=${STAGING_PREFIX}
--define-variable=exec_prefix=${STAGING_PREFIX}
--define-variable=bindir=${STAGING_PREFIX}/bin $@
+if [ -n "${STAGING_PREFIX}" ]; then
+ pkg-config.real --define-variable=prefix=${STAGING_PREFIX}
--define-variable=exec_prefix=${STAGING_PREFIX}
--define-variable=bindir=${STAGING_PREFIX}/bin $@
+elif [ -n "${DISTRO_PKG_CONFIG}" ]; then
+ ${DISTRO_PKG_CONFIG} $@
+else
+ pkg-config.real $@
+fi
Regards,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig
Sorry for the double reply, Peter, this did not make it to the list. On Tue, Sep 24, 2019 at 5:42 PM Petr Štetiar wrote: > > Eneas Queiroz [2019-09-24 17:06:28]: > > Hi, > > > The problem is that when scripts/config/lxdialog/check-lxdialog.sh is run, > > it will still use the staging_dir/host/bin/pkg-config script without > > STAGING_PREFIX set. > > it doesn't work like that here, I've just added following into > check-lxdialog.sh: > > echo "$(command -v pkg-config)" > $TOPDIR/meh.log > > and meh.log contains /usr/bin/pkg-config after kernel_menuconfig run. > > > > +DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -E '\/usr' | head > > > -n 1) > > If we export this, then we can check its existence in > > tools/pkg-config/files/pkg-config, and decide which pkg-config we want > > to run. > > if I understand it correctly this global exports are not welcome. > > > Then, we can use the variable in our pkg-config script to decide what > > to run, using just pkg-config.real as a fallback if nothing is defined > > (alternatively, we can fail instead): > > similar approach was already suggested[1] by Thomas originally and was > considered > brittle (and I agreed with that), so I've reworked it to current version. > > 1. https://patchwork.ozlabs.org/patch/1163120/ > > -- ynezz I've got your patch applied, and it still fails make menuconfig if I start from scratch or after make -C scripts/config clean. I haven't tried kernel_menuconfig yet--it will have to compile a lot of stuff if I start fresh. I've tried to run it like you did, but my meh.log points to /home/equeiroz/src/openwrt/staging_dir/host/bin/pkg-config. How will it get past $(TOPDIR)/staging_dir/host/bin, if that's the first thing--at least here--in PATH? I can certainly agree that globals are not really the best way. To avoid that, we can set DISTRO_PKG_CONFIG inside tools/pkg-config/files/pkg-config, and go from there: DISTRO_PKG_CONFIG="$(which -a pkg-config | grep -Ev 'staging_dir/host/bin/pkg-config' | head -n 1)" What do you think? Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig
On Tue, Sep 24, 2019 at 7:07 PM Petr Štetiar wrote:
>
> Eneas Queiroz [2019-09-24 18:28:44]:
>
> > I've got your patch applied, and it still fails make menuconfig if I
> > start from scratch or after make -C scripts/config clean. I haven't
> > tried kernel_menuconfig yet--it will have to compile a lot of stuff if
> > I start fresh.
>
> Ok, my bad, I can't read properly, you're talking about `make menuconfig` but
> I've assumed `make kernel_menuconfig` :-)
>
> So as the commit subject[1] says `build: fix make kernel_{menu,n}config ` this
> patch is about fixing only kernel_{menu,n}config targets, no desire to fix
> other broken targets.
>
> > What do you think?
>
> That it should be probably fixed in a similar manner as the other broken
> config targets, perhaps something like this would work?
>
> diff --git a/include/toplevel.mk b/include/toplevel.mk
> index 12586e87c09a..2b3b55db9f75 100644
> --- a/include/toplevel.mk
> +++ b/include/toplevel.mk
> @@ -99,6 +99,9 @@ prepare-tmpinfo: FORCE
> $(_SINGLE)$(NO_TRACE_MAKE) menuconfig $(PREP_MK); \
> fi
>
> +ifneq ($(DISTRO_PKG_CONFIG),)
> +scripts/config/mconf: export PATH:=$(dir $(DISTRO_PKG_CONFIG)):$(PATH)
> +endif
> scripts/config/mconf:
> @$(_SINGLE)$(SUBMAKE) -s -C scripts/config all CC="$(HOSTCC_WRAPPER)"
>
> Anyway, I've already deleted my testing Gentoo Docker image and don't want to
> emerge a new one in foreseeable future, so it would be nice if you could
> simply confirm, that my proposed patch[1] is ok and works, I'll merge it
> tomorrow and then you can add your fix(es) on top of that, what do you think?
>
> 1.
> https://gitlab.com/ynezz/openwrt/commit/0a20a3c08652af0d21accae6e76e8946cb4c1b84
>
> -- ynezz
I've applied both your patches ([1] plus the one inline), and tested
with all three affected targets, and they're all working now.
Tested-by: Eneas U de Queiroz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq40xx: fix hw-crypto detection of qce driver
This is meant for 19.07, as it's already in master. I just now realized it was missing from the subject line. Sorry about that. Eneas On Wed, Sep 25, 2019 at 2:03 PM Eneas U de Queiroz wrote: > > This adds the CRYPTO_ALG_KERN_DRIVER_ONLY flag to Qualcomm crypto engine > driver algorithms, so that openssl devcrypto can recognize them as > hardware-accelerated. > > Signed-off-by: Eneas U de Queiroz > > diff --git > a/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch > > b/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch > new file mode 100644 > index 00..58b0ebf5e7 > --- /dev/null > +++ > b/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch > @@ -0,0 +1,31 @@ > +From: Eneas U de Queiroz > +Subject: [PATCH] crypto: qce - add CRYPTO_ALG_KERN_DRIVER_ONLY flag > + > +Set the CRYPTO_ALG_KERN_DRIVER_ONLY flag to all algorithms exposed by > +the qce driver, since they are all hardware accelerated, accessible > +through a kernel driver only, and not available directly to userspace. > + > +Signed-off-by: Eneas U de Queiroz > + > +--- a/drivers/crypto/qce/ablkcipher.c > b/drivers/crypto/qce/ablkcipher.c > +@@ -373,7 +373,7 @@ static int qce_ablkcipher_register_one(c > + > + alg->cra_priority = 300; > + alg->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC | > +- CRYPTO_ALG_NEED_FALLBACK; > ++ CRYPTO_ALG_NEED_FALLBACK | > CRYPTO_ALG_KERN_DRIVER_ONLY; > + alg->cra_ctxsize = sizeof(struct qce_cipher_ctx); > + alg->cra_alignmask = 0; > + alg->cra_type = &crypto_ablkcipher_type; > +--- a/drivers/crypto/qce/sha.c > b/drivers/crypto/qce/sha.c > +@@ -526,7 +526,7 @@ static int qce_ahash_register_one(const > + base = &alg->halg.base; > + base->cra_blocksize = def->blocksize; > + base->cra_priority = 300; > +- base->cra_flags = CRYPTO_ALG_ASYNC; > ++ base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY; > + base->cra_ctxsize = sizeof(struct qce_sha_ctx); > + base->cra_alignmask = 0; > + base->cra_module = THIS_MODULE; > -- > 2.21.0 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wait on syslog-ng
On Fri, Sep 27, 2019 at 8:05 AM W. Michael Petullo wrote:
>
> A daemon I wrote for OpenWrt depends on a running syslogd. I use
> syslog-ng, and I have noticed that its init script completes before the
> daemon begins to listen on /dev/log. This causes my daemon to terminate
> if it starts quickly after syslog-ng.
>
> There are a few obvious solutions:
>
> (1) My daemon could sleep and try again if its connection to
> syslogd fails.
>
> (2) My daemon's init script could sleep for one second before
> running the daemon.
>
> (3) Syslog-ng's init script could sleep for one second after
> executing syslog-ng and before exiting.
>
> (3) seems the most universal, but all of these feel a little kludgy due
> to the reliance on a timeout. I say this becasue you cannot precisely
> predict what the timeout value should be (in practice a second or so
> seems to suffice).
>
> Does the init system provide a more general way to solve this problem?
> The START=n statements seem to impose only the ordering of init script
> execution and have no bearing on whether the services the scripts run
> are ready. Do I have this right?
>
> I did see sleep in a few other scripts such as network.
How about something like this?
#!/bin/sh
exitservice() {
if [ -n "$!" ]; then
echo Killing timout
kill $! 2> /dev/null
wait $! 2> /dev/null
fi
}
timeout() {
sleep 10
echo 'ERROR: socket not open. Is syslog running?' >&2
kill $$
exit 1
}
trap exitservice EXIT
timeout &
while ! grep -q /dev/log /proc/net/unix; do
sleep 1
done
exit 0
Cheers,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] kernel: add backported phy/phylink/sfp patches
On Wed, Nov 27, 2019 at 10:28 AM Russell King - ARM Linux admin
wrote:
> The build system is just very painful for a new-comer to understand.
> I don't doubt that it does what you need it to, but trying to work
> out stuff from it is a nightmare unless you have some knowledge
> about how it is setup.
>
> For example, referencing:
>
> https://openwrt.org/docs/guide-developer/single.package
>
> and trying to build just the kernel. So:
>
> $ make tools/install
> $ make toolchain/install
> $ make target/linux/install
>
> fails because there is no opkg host tool present.
I'm no build system expert, so if I say anything too wrong, anyone,
please correct me. This is just what I do while testing changes. For
the final test, I do a whole build with 'make dirclean && make' to
avoid any trouble.
I'm assuming you just want to build the kernel modules, not the full
image, right? If you want a flashable image, then a plain 'make' is
probably the best way to do it.
TLDR: Whenever I need to compile just the kernel, I use 'make
{toolchain,target,package/linux}/compile package/index'.
These steps will not need opkg built or anything else.
make toolchain/compile
- This step should only be needed once, unless you change the
toolchain. This will perform tools/compile, so that step is not
really necessary.
make target/compile
- This builds the kernel image, including the built-in modules, but
does not make the flashable image--you'll need target/install for
that.
make package/linux/compile
- Builds the module packages. If you're building a module package,
you won't need to perform make target/install.
make package/index
- Builds the files needed to be able to publish the bin dir to use
with opkg. I tend to copy the ipk file and install it from there, to
not have to worry about opkg downloading the package from the original
repository.
If I need to start from a clean kernel, I use 'make
target/{clean,compile} package/linux/compile'
make target/clean
- Removes the kernel build directory, (including the files compiled
with "make package/linux/compile", but not the final ipks under bin).
This is useful, so you won't clean and have to rebuild too much.
>
> Trying to find out how to build opkg is really not easy. You find
> "host-compile" and "host-install" targets in the makefiles, so you
> assume that if you try make package/system/opkg/host-install, maybe
> it'll install a host built opkg into staging_dir/host/bin - but no,
> that doesn't work. That seems to be utterly impossible to do.
> That has alone made me develop a great hate for the implementation
> after spending a lot of time trying to figure it out.
'make package/opkg/host/compile' does the trick.
Cheers,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.07 final timeline
On Wed, Jan 1, 2020 at 6:54 PM Hauke Mehrtens wrote: > I will shift both releases (18.06.6 and 19.07.0 final) to Monday 6. > January to get some security fixes in, please get your changes in till > Saturday so we have some testing before. > > I would suggest a cherry-pick from d5ede68f8b (wolfssl: bump to 4.3.0-stable) It's a security update, and appears to make WPA3 Personal work using wpad-wolfssl (mesh is still failing). Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.07 final timeline
On Mon, Jan 6, 2020 at 1:59 PM Hauke Mehrtens wrote: > > I cherry-picked it, but WPA3 still does not work for me. > > Hauke TLDR: WPA3 support with wolfssl is still not ideal. WPA3 success was reported to me here: https://forum.openwrt.org/t/wpa3-wolfssl-fail-openssl-success/50161/7 Another user reports that it "feels a bit wonky with WolfSSL 4.3.0", that it takes several tries to connect to the network with a Nokia 8.1, and his laptop does not connect at all. I'm not using WPA3, and haven't got around to see if I can test this myself. I know WolfSSL deliberately fails to perform some actions that it deems insecure, while openssl succeeds. I've tried to spot some of these situations just by looking at the hostapd code, but I couldn't find anything extremely obvious. Judging by the partial success, it may not be the case. I'm short on time right now, but I'll open an issue with wolfssl as soon as I can. Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.07 final timeline
On Tue, Jan 7, 2020 at 6:42 PM Hauke Mehrtens wrote: > > On 1/7/20 9:09 PM, Eneas Queiroz wrote: > > On Mon, Jan 6, 2020 at 1:59 PM Hauke Mehrtens wrote: > >> > >> I cherry-picked it, but WPA3 still does not work for me. > >> > >> Hauke > > > > TLDR: WPA3 support with wolfssl is still not ideal. > > > > WPA3 success was reported to me here: > > https://forum.openwrt.org/t/wpa3-wolfssl-fail-openssl-success/50161/7 > > > > Another user reports that it "feels a bit wonky with WolfSSL 4.3.0", > > that it takes several tries to connect to the network with a Nokia > > 8.1, and his laptop does not connect at all. > > > > I'm not using WPA3, and haven't got around to see if I can test this > > myself. I know WolfSSL deliberately fails to perform some actions > > that it deems insecure, while openssl succeeds. I've tried to spot > > some of these situations just by looking at the hostapd code, but I > > couldn't find anything extremely obvious. Judging by the partial > > success, it may not be the case. I'm short on time right now, but > > I'll open an issue with wolfssl as soon as I can. > > Hi, > > I used an ipq40xx (ath10k) device as an WAP3 AP with wpad-wolfssl and > tried to connect with my Android 10 Pixel 3a phone and it failed. it > works against my other ath10k AP using wpad-openssl. > > Daniel said wpad-wolfssl with WPA3 works for him with an older OpenWrt > version, this could be related to the hostapd update we did. > > This topic needs some investigation. > > Hauke > The fact that it works with an older version is the reason I think that a new behavior-changing feature is responsible for it not working. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] build failure on 18.06 from git (usbip)
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 --- Try this:https://patch-diff.githubusercontent.com/raw/openwrt/packages/pull/6062.patch This was merged in master, but not in 18.06. It will compile, but I wasn't able to make it run myself. I have no experience with the package to know if it's a build/configuration failure, or plain incompatibility with any library used in openwrt. The changes I proposed should not break it, in theory anyway. You might want to test it with 18.06, and either make a new PR, or just ask for a straight cherry-pick, as @hnyman suggested. https://patch-diff.githubusercontent.com/raw/openwrt/packages/pull/6062 I hope this helps. It might be better to discuss this in the package feed repo, as this list is for the main openwrt development. Cheers, Eneas Em sábado, 28 de julho de 2018 11:07:00 BRT, Torbjorn Jansson escreveu: Hello i tried building openwrt 18.06 branch today but i got stuck due to a build failure on this: - Applying ./patches-2.0/100-musl-compat.patch using plaintext: patching file src/usbipd.c Hunk #1 FAILED at 453. 1 out of 1 hunk FAILED -- saving rejects to file src/usbipd.c.rej Patch failed! Please fix ./patches-2.0/100-musl-compat.patch! - any idea whats wrong and how to fix it? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
