[OpenWrt-Devel] [PATCH] iproute2: add libcap support, enabled in ip-full

2019-07-01 Thread Alin Nastac 
Preserve optionality of libcap by having configuration script follow the
HAVE_CAP environment variable, used similarly to the HAVE_ELF variable.

Signed-off-by: Alin Nastac 
---
 package/network/utils/iproute2/Makefile| 18 ++
 .../iproute2/patches/150-keep_libcap_optional.patch| 12 
 2 files changed, 22 insertions(+), 8 deletions(-)
 create mode 100644 
package/network/utils/iproute2/patches/150-keep_libcap_optional.patch

diff --git a/package/network/utils/iproute2/Makefile 
b/package/network/utils/iproute2/Makefile
index 0f09b79..8792eb9 100644
--- a/package/network/utils/iproute2/Makefile
+++ b/package/network/utils/iproute2/Makefile
@@ -49,7 +49,7 @@ $(call Package/iproute2/Default)
  VARIANT:=full
  PROVIDES:=ip
  ALTERNATIVES:=300:/sbin/ip:/usr/libexec/ip-full
- DEPENDS:=+libnl-tiny +libelf +(PACKAGE_devlink||PACKAGE_rdma):libmnl
+ DEPENDS:=+libnl-tiny +libelf +(PACKAGE_devlink||PACKAGE_rdma):libmnl +libcap
 endef
 
 define Package/tc
@@ -57,43 +57,43 @@ $(call Package/iproute2/Default)
   TITLE:=Traffic control utility
   VARIANT:=tc
   PROVIDES:=tc
-  DEPENDS:=+kmod-sched-core +libxtables +libelf 
+(PACKAGE_devlink||PACKAGE_rdma):libmnl
+  DEPENDS:=+kmod-sched-core +libxtables +libelf 
+(PACKAGE_devlink||PACKAGE_rdma):libmnl +PACKAGE_ip-full:libcap
 endef
 
 define Package/genl
 $(call Package/iproute2/Default)
   TITLE:=General netlink utility frontend
-  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf
+  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf +PACKAGE_ip-full:libcap
 endef
 
 define Package/ip-bridge
 $(call Package/iproute2/Default)
   TITLE:=Bridge configuration utility from iproute2
-  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf
+  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf +PACKAGE_ip-full:libcap
 endef
 
 define Package/ss
 $(call Package/iproute2/Default)
   TITLE:=Socket statistics utility
-  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf
+  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf +PACKAGE_ip-full:libcap
 endef
 
 define Package/nstat
 $(call Package/iproute2/Default)
   TITLE:=Network statistics utility
-  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf
+  DEPENDS:=+libnl-tiny +(PACKAGE_devlink||PACKAGE_rdma):libmnl 
+(PACKAGE_tc||PACKAGE_ip-full):libelf +PACKAGE_ip-full:libcap
 endef
 
 define Package/devlink
 $(call Package/iproute2/Default)
   TITLE:=Network devlink utility
-  DEPENDS:=+libmnl +(PACKAGE_tc||PACKAGE_ip-full):libelf
+  DEPENDS:=+libmnl +(PACKAGE_tc||PACKAGE_ip-full):libelf 
+PACKAGE_ip-full:libcap
 endef
 
 define Package/rdma
 $(call Package/iproute2/Default)
   TITLE:=Network rdma utility
-  DEPENDS:=+libmnl +(PACKAGE_tc||PACKAGE_ip-full):libelf
+  DEPENDS:=+libmnl +(PACKAGE_tc||PACKAGE_ip-full):libelf 
+PACKAGE_ip-full:libcap
 endef
 
 ifeq ($(BUILD_VARIANT),tiny)
@@ -102,6 +102,7 @@ endif
 
 ifeq ($(BUILD_VARIANT),full)
   HAVE_ELF:=y
+  HAVE_CAP:=y
 endif
 
 ifeq ($(BUILD_VARIANT),tc)
@@ -132,6 +133,7 @@ MAKE_FLAGS += \
IP_CONFIG_TINY=$(IP_CONFIG_TINY) \
HAVE_ELF=$(HAVE_ELF) \
HAVE_MNL=$(HAVE_MNL) \
+   HAVE_CAP=$(HAVE_CAP) \
IPT_LIB_DIR=/usr/lib/iptables \
XT_LIB_DIR=/usr/lib/iptables \
FPIC="$(FPIC)"
diff --git 
a/package/network/utils/iproute2/patches/150-keep_libcap_optional.patch 
b/package/network/utils/iproute2/patches/150-keep_libcap_optional.patch
new file mode 100644
index 000..8fe23ae
--- /dev/null
+++ b/package/network/utils/iproute2/patches/150-keep_libcap_optional.patch
@@ -0,0 +1,12 @@
+diff -Nru a/configure b/configure
+--- a/configure2019-07-01 10:35:39.142807973 +0200
 b/configure2019-07-01 10:46:40.518832990 +0200
+@@ -307,7 +307,7 @@
+ 
+ check_cap()
+ {
+-  if ${PKG_CONFIG} libcap --exists; then
++  if [ "${HAVE_CAP}" = "y" ] && ${PKG_CONFIG} libcap --exists; then
+   echo "HAVE_CAP:=y" >>$CONFIG
+   echo "yes"
+ 
-- 
2.7.4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Patch review

2019-07-01 Thread Ansuel Smith 
Can someone review this series of patch i sent some times ago?

https://patchwork.ozlabs.org/patch/1116584/

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] runqueue: Fix the callbacks order in runqueue_task_kill()

2019-07-01 Thread John Crispin 


On 21/06/2019 17:38, Alban Bedel wrote:

Since commit 11e8afea (runqueue should cal the complete handler from
more places) the call to the complete() callback has been moved to
runqueue_task_complete().  However in runqueue_task_kill()
runqueue_task_complete() is called before the kill() callback.
This will result in a use after free if the complete() callback free
the task struct.

Furthermore runqueue_start_next() is already called at the end of
runqueue_task_complete(), so there is no need to call it again in
runqueue_task_kill().

Signed-off-by: Alban Bedel 
---
  runqueue.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/runqueue.c b/runqueue.c
index a1d0133..4c621aa 100644
--- a/runqueue.c
+++ b/runqueue.c
@@ -196,11 +196,9 @@ void runqueue_task_kill(struct runqueue_task *t)
if (!t->queued)
return;
  
-	runqueue_task_complete(t);

if (running && t->type->kill)
t->type->kill(q, t);
-
-   runqueue_start_next(q);
+   runqueue_task_complete(t);
  }
  
  void runqueue_stop(struct runqueue *q)


Hi,

runqueue_task_complete() will decrement running which, if called after the kill 
clause might not even trigger the kill() call. I am assuming you are running a 
custom runqueue_task_type ?

 John



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] libubox: add macros for remaining logging severities

2019-07-01 Thread John Crispin 

Hi,

patch is malformed and fails to apply

    John

--2019-07-01 15:54:52-- http://patchwork.ozlabs.org/patch/1117474/mbox/
Resolving patchwork.ozlabs.org (patchwork.ozlabs.org)... 203.11.71.1, 
2401:3900:2:1::2
Connecting to patchwork.ozlabs.org 
(patchwork.ozlabs.org)|203.11.71.1|:80... connected.

HTTP request sent, awaiting response... 200 OK
Length: 5055 (4.9K) [text/plain]
Saving to: ‘1117474.patch’

1117474.patch 
100%[>] 
4.94K  --.-KB/s    in 0.001s


2019-07-01 15:54:53 (4.31 MB/s) - ‘1117474.patch’ saved [5055/5055]

Patch is empty.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [openwrt] Patch notification: 1 patch updated

2019-07-01 Thread Patchwork 
Hello,

The following patch (submitted by you) has been updated in Patchwork:

 * openwrt: [OpenWrt-Devel] libubox: add macros for remaining logging severities
 - http://patchwork.ozlabs.org/patch/1117474/
 - for: OpenWrt development
was: New
now: Changes Requested

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the Patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: sysupgrade: Bring down wifi just before killall

2019-07-01 Thread John Crispin 


On 16/06/2019 00:10, Jeff Kletsky wrote:

From: Jeff Kletsky 

Wifi can, in certain situations, cause sysupgrade to fail silently
with a 256 return value as all processes can't be killed.
One of these situations is mesh with batman-adv active.

Added `wifi down` just prior to the killall sequence in stage2

Run-tested-on: Linksys EA8300

Signed-off-by: Jeff Kletsky 
---
  package/base-files/files/lib/upgrade/stage2 | 4 
  1 file changed, 4 insertions(+)

diff --git a/package/base-files/files/lib/upgrade/stage2 
b/package/base-files/files/lib/upgrade/stage2
index bdc12c7426..d911614e36 100755
--- a/package/base-files/files/lib/upgrade/stage2
+++ b/package/base-files/files/lib/upgrade/stage2
@@ -124,6 +124,10 @@ kill_remaining() { # [  [  ] ]
  
  indicate_upgrade
  
+if [ -x "$(which wifi)" ] ; then

+wifi down
+sleep 1


the sleep 1 is really not good. could you try to figure out what 
actually causes the 256 and try to fix that instead please ?


    John



+fi
  killall -9 telnetd
  killall -9 dropbear
  killall -9 ash


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] runqueue: Fix the callbacks order in runqueue_task_kill()

2019-07-01 Thread Alban 
On Mon, 1 Jul 2019 15:48:47 +0200
John Crispin  wrote:

> On 21/06/2019 17:38, Alban Bedel wrote:
> > Since commit 11e8afea (runqueue should cal the complete handler from
> > more places) the call to the complete() callback has been moved to
> > runqueue_task_complete().  However in runqueue_task_kill()
> > runqueue_task_complete() is called before the kill() callback.
> > This will result in a use after free if the complete() callback free
> > the task struct.
> >
> > Furthermore runqueue_start_next() is already called at the end of
> > runqueue_task_complete(), so there is no need to call it again in
> > runqueue_task_kill().
> >
> > Signed-off-by: Alban Bedel 
> > ---
> >   runqueue.c | 4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/runqueue.c b/runqueue.c
> > index a1d0133..4c621aa 100644
> > --- a/runqueue.c
> > +++ b/runqueue.c
> > @@ -196,11 +196,9 @@ void runqueue_task_kill(struct runqueue_task
> > *t) if (!t->queued)
> > return;
> >   
> > -   runqueue_task_complete(t);
> > if (running && t->type->kill)
> > t->type->kill(q, t);
> > -
> > -   runqueue_start_next(q);
> > +   runqueue_task_complete(t);
> >   }
> >   
> >   void runqueue_stop(struct runqueue *q)  
> 
> Hi,
> 
> runqueue_task_complete() will decrement running which, if called
> after the kill clause might not even trigger the kill() call. I am
> assuming you are running a custom runqueue_task_type ?

No, TBH I haven't tested this, but as there is no documentation I had
to go through the code and noticed this suspicious construct. I then
saw commit 6a7fb7d8d (runqueue: fix use-after-free bug) which confirmed
that complete() is expected to free the task struct, which with the
above code will clearly lead to an access after free.

But I don't really see what you mean, 'running' is a boolean so it
can't be decremented. Did you mean 'running_tasks'?

Alban


pgps5j2wNQeAk.pgp
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] runqueue: Fix the callbacks order in runqueue_task_kill()

2019-07-01 Thread John Crispin 



On 01/07/2019 16:23, Alban wrote:

On Mon, 1 Jul 2019 15:48:47 +0200
John Crispin  wrote:


On 21/06/2019 17:38, Alban Bedel wrote:

Since commit 11e8afea (runqueue should cal the complete handler from
more places) the call to the complete() callback has been moved to
runqueue_task_complete().  However in runqueue_task_kill()
runqueue_task_complete() is called before the kill() callback.
This will result in a use after free if the complete() callback free
the task struct.

Furthermore runqueue_start_next() is already called at the end of
runqueue_task_complete(), so there is no need to call it again in
runqueue_task_kill().

Signed-off-by: Alban Bedel 
---
   runqueue.c | 4 +---
   1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/runqueue.c b/runqueue.c
index a1d0133..4c621aa 100644
--- a/runqueue.c
+++ b/runqueue.c
@@ -196,11 +196,9 @@ void runqueue_task_kill(struct runqueue_task
*t) if (!t->queued)
return;
   
-	runqueue_task_complete(t);

if (running && t->type->kill)
t->type->kill(q, t);
-
-   runqueue_start_next(q);
+   runqueue_task_complete(t);
   }
   
   void runqueue_stop(struct runqueue *q)

Hi,

runqueue_task_complete() will decrement running which, if called
after the kill clause might not even trigger the kill() call. I am
assuming you are running a custom runqueue_task_type ?

No, TBH I haven't tested this, but as there is no documentation I had
to go through the code and noticed this suspicious construct. I then
saw commit 6a7fb7d8d (runqueue: fix use-after-free bug) which confirmed
that complete() is expected to free the task struct, which with the
above code will clearly lead to an access after free.

But I don't really see what you mean, 'running' is a boolean so it
can't be decremented. Did you mean 'running_tasks'?

Alban



i did actually mean running_task, I'll have another look later on today

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 0/3] wolfssl update

2019-07-01 Thread Eneas U de Queiroz 
This series starts with an update to version 3.15.7, which includes a
security fix, and should be cherry-picked to 19.07.  I'm not
cherry-picking it to 18.06 because it changes ABI, and it would cause
package breakage because 18.06 is not ABI version-aware.

I've increased the FP_MAX_BITS parameter to 8192, to allow usage of
4096-bit RSA keys.  Otherwise it would fail to verify many CA
certificates that use 4096-bit keys, including Microsoft's.

Update master to 4.0.0.  This version adds support to TLS 1.3, hardware
acceleration using /dev/crypto and AF_ALG.  The features were added in
3.15.7, but only enabled here in 4.0.0.

Many of the current build options were not effective, they were always
built into the library because of an unconditional --enable-stunnel
parameter to configure, so they can be removed.  Since hostapd selected
some of these options, they are being removed there as well.  The
hostapd change includes the removal of the selection of the library
itself, allowing libwolfssl to be built as a module when hostapd depends
on it, and is built as a module.

I've ensured dependent packages are successfully built with this
version, opening a couple of PRs in the packages feed.  They had been
broken for a while now, which makes me wonder how many people are
actually using wolfssl today.  Nonetheless, a TLS library supporting hw
crypto acceleration and TLS 1.3 under 300KB seems interesting.

The library was run-tested on WRT-3200ACM using uhttpd, uclient-fetch,
and curl with different build options, turning them on one by one
cumulatively.  The size varied from 227K with all options off, to 312K
with all options on, and defaults to 297K.

Enabling hardware acelleration and AES-CCM at the same time results in a
build failure, which dents my confidence.  Nonetheless, uhttpd connects
without a problem, and I can confirm /dev/crypto or AF_ALG sockets open.

The package currently lacks a maintainer, so I've added myself.

--
Changelog:
v1->v2:

* Increased FP_MAX_BITS to allow 4096-bit RSA keys.
* Update master to 4.0.0

Eneas U de Queiroz (3):
  wolfssl: update to 3.15.7, fix Makefile
  wolfssl: update to 4.0.0-stable
  hostapd: adjust removed wolfssl options

 package/libs/wolfssl/Config.in|  51 ---
 package/libs/wolfssl/Makefile | 124 +-
 .../patches/100-disable-hardening-check.patch |   4 +-
 .../101-AR-flags-configure-update.patch   |  23 
 .../900-remove-broken-autoconf-macros.patch   |   2 +-
 package/network/services/hostapd/Config.in|   4 -
 6 files changed, 70 insertions(+), 138 deletions(-)
 delete mode 100644 
package/libs/wolfssl/patches/101-AR-flags-configure-update.patch


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 1/3] wolfssl: update to 3.15.7, fix Makefile

2019-07-01 Thread Eneas U de Queiroz 
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 

diff --git a/package/libs/wolfssl/Config.in b/package/libs/wolfssl/Config.in
index 50b0bb9cdf..4aa163b361 100644
--- a/package/libs/wolfssl/Config.in
+++ b/package/libs/wolfssl/Config.in
@@ -53,7 +53,7 @@ config WOLFSSL_HAS_ECC25519
depends on WOLFSSL_HAS_ECC
default n
 
-config WOLFSSL_HAS_POLY_1305
+config WOLFSSL_HAS_POLY1305
bool "Include Poly-1305 support"
default n
 
diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index 23bb1c5220..7aaa562539 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -8,11 +8,10 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=wolfssl
-PKG_VERSION:=3.15.3-stable
-PKG_RELEASE:=2
+PKG_VERSION:=3.15.7-stable
+PKG_RELEASE:=1
 
-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).zip
-# PKG_SOURCE_URL:=https://www.wolfssl.com/
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
 PKG_HASH:=dc97c07a7667b39a890e14f4b4a209f51524a4cabee7adb6c80822ee78c1f62a
 
@@ -20,15 +19,16 @@ PKG_FIXUP:=libtool
 PKG_INSTALL:=1
 PKG_USE_MIPS16:=0
 PKG_BUILD_PARALLEL:=1
-PKG_LICENSE:=GPL-2.0+
-PKG_CPE_ID:=cpe:/a:yassl:cyassl
+PKG_LICENSE:=GPL-2.0-or-later
+PKG_LICENSE_FILES:=LICENSING COPYING
+PKG_CPE_ID:=cpe:/a:wolfssl:wolfssl
 
 PKG_CONFIG_DEPENDS:=\
CONFIG_WOLFSSL_HAS_AES_CCM CONFIG_WOLFSSL_HAS_AES_GCM \
CONFIG_WOLFSSL_HAS_ARC4 CONFIG_WOLFSSL_HAS_CHACHA \
CONFIG_WOLFSSL_HAS_DES3 CONFIG_WOLFSSL_HAS_DH CONFIG_WOLFSSL_HAS_DTLS \
CONFIG_WOLFSSL_HAS_ECC CONFIG_WOLFSSL_HAS_ECC25519 \
-   CONFIG_WOLFSSL_HAS_OCSP CONFIG_WOLFSSL_HAS_POLY_1305 \
+   CONFIG_WOLFSSL_HAS_OCSP CONFIG_WOLFSSL_HAS_POLY1305 \
CONFIG_WOLFSSL_HAS_PSK CONFIG_WOLFSSL_HAS_SESSION_TICKET \
CONFIG_WOLFSSL_HAS_WPAS
 
@@ -42,7 +42,7 @@ define Package/libwolfssl
   URL:=http://www.wolfssl.com/
   MENU:=1
   PROVIDES:=libcyassl
-  ABI_VERSION:=18
+  ABI_VERSION:=19
 endef
 
 define Package/libwolfssl/description
@@ -54,7 +54,7 @@ define Package/libwolfssl/config
source "$(SOURCE)/Config.in"
 endef
 
-TARGET_CFLAGS += $(FPIC)
+TARGET_CFLAGS += $(FPIC) -DFP_MAX_BITS=8192
 
 # --enable-stunnel needed for OpenSSL API compatibility bits
 CONFIGURE_ARGS += \
diff --git a/package/libs/wolfssl/patches/100-disable-hardening-check.patch 
b/package/libs/wolfssl/patches/100-disable-hardening-check.patch
index d913b5fdea..8a51434633 100644
--- a/package/libs/wolfssl/patches/100-disable-hardening-check.patch
+++ b/package/libs/wolfssl/patches/100-disable-hardening-check.patch
@@ -1,6 +1,6 @@
 --- a/wolfssl/wolfcrypt/settings.h
 +++ b/wolfssl/wolfcrypt/settings.h
-@@ -1624,7 +1624,7 @@ extern void uITRON4_free(void *p) ;
+@@ -1759,7 +1759,7 @@ extern void uITRON4_free(void *p) ;
  #endif
  
  /* warning for not using harden build options (default with ./configure) */
@@ -8,4 +8,4 @@
 +#if 0
  #if (defined(USE_FAST_MATH) && !defined(TFM_TIMING_RESISTANT)) || \
  (defined(HAVE_ECC) && !defined(ECC_TIMING_RESISTANT)) || \
- (!defined(NO_RSA) && !defined(WC_RSA_BLINDING) && !defined(HAVE_FIPS))
+ (!defined(NO_RSA) && !defined(WC_RSA_BLINDING) && !defined(HAVE_FIPS) 
&& \
diff --git 
a/package/libs/wolfssl/patches/900-remove-broken-autoconf-macros.patch 
b/package/libs/wolfssl/patches/900-remove-broken-autoconf-macros.patch
index 66582cfc46..6b0861288f 100644
--- a/package/libs/wolfssl/patches/900-remove-broken-autoconf-macros.patch
+++ b/package/libs/wolfssl/patches/900-remove-broken-autoconf-macros.patch
@@ -1,6 +1,6 @@
 --- a/configure.ac
 +++ b/configure.ac
-@@ -4198,7 +4198,6 @@ AC_CONFIG_FILES([stamp-h], [echo timesta
+@@ -4614,7 +4614,6 @@ AC_CONFIG_FILES([stamp-h], [echo timesta
  AC_CONFIG_FILES([Makefile wolfssl/version.h wolfssl/options.h 
cyassl/options.h support/wolfssl.pc rpm/spec])
  
  AX_CREATE_GENERIC_CONFIG

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 3/3] hostapd: adjust removed wolfssl options

2019-07-01 Thread Eneas U de Queiroz 
This edjusts the selection of recently removed wolfssl options which
have always been built into the library even in their abscence.
Also remove the selection of libwolfssl itself, allowing the library to
be built as a module.

Signed-off-by: Eneas U de Queiroz 

diff --git a/package/network/services/hostapd/Config.in 
b/package/network/services/hostapd/Config.in
index 1966067219..9ce4b243cc 100644
--- a/package/network/services/hostapd/Config.in
+++ b/package/network/services/hostapd/Config.in
@@ -51,15 +51,11 @@ config WPA_WOLFSSL
PACKAGE_wpad-wolfssl ||\
PACKAGE_wpad-mesh-wolfssl ||\
PACKAGE_eapol-test-wolfssl
-   select PACKAGE_libwolfssl
select WOLFSSL_HAS_AES_CCM
select WOLFSSL_HAS_AES_GCM
select WOLFSSL_HAS_ARC4
-   select WOLFSSL_HAS_DES3
select WOLFSSL_HAS_DH
-   select WOLFSSL_HAS_ECC
select WOLFSSL_HAS_OCSP
-   select WOLFSSL_HAS_PSK
select WOLFSSL_HAS_SESSION_TICKET
select WOLFSSL_HAS_WPAS
 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/3] wolfssl: update to 4.0.0-stable

2019-07-01 Thread Eneas U de Queiroz 
Removed options that can't be turned off because we're building with
--enable-stunnel, some of which affect hostapd's Config.in.
Adjusted the title of OCSP option, as OCSP itself can't be turned off,
only the stapling part is selectable.
Mark options turned on when wpad support is selected.
Add building options for TLS 1.0, and TLS 1.3.
Add hardware crypto support, which due to a bug, only works when CCM
support is turned off.
Reorganized option conditionals in Makefile.
Add Eneas U de Queiroz as maintainer.

Signed-off-by: Eneas U de Queiroz 

diff --git a/package/libs/wolfssl/Config.in b/package/libs/wolfssl/Config.in
index 4aa163b361..875ff5e6a3 100644
--- a/package/libs/wolfssl/Config.in
+++ b/package/libs/wolfssl/Config.in
@@ -8,12 +8,8 @@ config WOLFSSL_HAS_AES_GCM
bool "Include AES-GCM support"
default y
 
-config WOLFSSL_HAS_CHACHA
-   bool "Include ChaCha cipher suite support"
-   default n
-
-config WOLFSSL_HAS_ECC
-   bool "Include ECC (Elliptic Curve Cryptography) support"
+config WOLFSSL_HAS_CHACHA_POLY
+   bool "Include ChaCha20-Poly1305 cipher suite support"
default y
 
 config WOLFSSL_HAS_DH
@@ -24,12 +20,17 @@ config WOLFSSL_HAS_ARC4
bool "Include ARC4 support"
default y
 
-config WOLFSSL_HAS_DES3
-   bool "Include DES3 (Tripple-DES) support"
+config WOLFSSL_HAS_TLSV10
+   bool "Include TLS 1.0 support"
default y
 
-config WOLFSSL_HAS_PSK
-   bool "Include PKS (Pre Share Key) support"
+if !(WOLFSSL_HAS_AES_CCM||WOLFSSL_HAS_AES_GCM||WOLFSSL_HAS_CHACHA_POLY)
+   comment "! TLS 1.3 support needs one of: AES-CCM, AES-GCM, 
ChaCha20-Poly1305"
+endif
+
+config WOLFSSL_HAS_TLSV13
+   bool "Include TLS 1.3 support"
+   depends on 
WOLFSSL_HAS_AES_CCM||WOLFSSL_HAS_AES_GCM||WOLFSSL_HAS_CHACHA_POLY
default y
 
 config WOLFSSL_HAS_SESSION_TICKET
@@ -41,20 +42,40 @@ config WOLFSSL_HAS_DTLS
default n
 
 config WOLFSSL_HAS_OCSP
-   bool "Include OSCP support"
+   bool "Include OSCP stapling support"
default y
 
 config WOLFSSL_HAS_WPAS
bool "Include wpa_supplicant support"
+   select WOLFSSL_HAS_ARC4
+   select WOLFSSL_HAS_OCSP
+   select WOLFSSL_HAS_SESSION_TICKET
default y
 
 config WOLFSSL_HAS_ECC25519
bool "Include ECC Curve 22519 support"
-   depends on WOLFSSL_HAS_ECC
default n
 
-config WOLFSSL_HAS_POLY1305
-   bool "Include Poly-1305 support"
-   default n
+if WOLFSSL_HAS_AES_CCM
+   comment "! Hardware Acceleration does not build with AES-CCM enabled"
+endif
+if !WOLFSSL_HAS_AES_CCM
+   choice
+   prompt "Hardware Acceleration"
+   default WOLFSSL_HAS_NO_HW
+
+   config WOLFSSL_HAS_NO_HW
+   bool "None"
+
+   config WOLFSSL_HAS_AFALG
+   bool "AF_ALG"
+
+   config WOLFSSL_HAS_DEVCRYPTO_AES
+   bool "/dev/crypto - AES-only"
+
+   config WOLFSSL_HAS_DEVCRYPTO_FULL
+   bool "/dev/crypto - full"
+   endchoice
+endif
 
 endif
diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index 7aaa562539..678eb4936b 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=wolfssl
-PKG_VERSION:=3.15.7-stable
+PKG_VERSION:=4.0.0-stable
 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:=6cf678c72b485d1904047c40c20f85104c96b5f39778822783a2c407ccb23657
 
 PKG_FIXUP:=libtool
 PKG_INSTALL:=1
@@ -21,15 +21,17 @@ PKG_USE_MIPS16:=0
 PKG_BUILD_PARALLEL:=1
 PKG_LICENSE:=GPL-2.0-or-later
 PKG_LICENSE_FILES:=LICENSING COPYING
+PKG_MAINTAINER:=Eneas U de Queiroz 
 PKG_CPE_ID:=cpe:/a:wolfssl:wolfssl
 
 PKG_CONFIG_DEPENDS:=\
CONFIG_WOLFSSL_HAS_AES_CCM CONFIG_WOLFSSL_HAS_AES_GCM \
-   CONFIG_WOLFSSL_HAS_ARC4 CONFIG_WOLFSSL_HAS_CHACHA \
-   CONFIG_WOLFSSL_HAS_DES3 CONFIG_WOLFSSL_HAS_DH CONFIG_WOLFSSL_HAS_DTLS \
-   CONFIG_WOLFSSL_HAS_ECC CONFIG_WOLFSSL_HAS_ECC25519 \
-   CONFIG_WOLFSSL_HAS_OCSP CONFIG_WOLFSSL_HAS_POLY1305 \
-   CONFIG_WOLFSSL_HAS_PSK CONFIG_WOLFSSL_HAS_SESSION_TICKET \
+   CONFIG_WOLFSSL_HAS_AFALG CONFIG_WOLFSSL_HAS_ARC4 \
+   CONFIG_WOLFSSL_HAS_CHACHA_POLY CONFIG_WOLFSSL_HAS_DEVCRYPTO_AES \
+   CONFIG_WOLFSSL_HAS_DEVCRYPTO_FULL, CONFIG_WOLFSSL_HAS_DH \
+   CONFIG_WOLFSSL_HAS_DTLS CONFIG_WOLFSSL_HAS_ECC25519 \
+   CONFIG_WOLFSSL_HAS_OCSP CONFIG_WOLFSSL_HAS_SESSION_TICKET \
+   CONFIG_WOLFSSL_HAS_TLSV10 CONFIG_WOLFSSL_HAS_TLSV13 \
CONFIG_WOLFSSL_HAS_WPAS
 
 include $(INCLUDE_DIR)/package.mk
@@ -42,6 +44,7 @@ define Package/libwolfssl
   URL:=http://www.wolfssl.com/
   MENU:=1
   PROVIDES:=libcyassl
+  DEPENDS:=+WOLFSSL_HAS_DEVCRYPTO:kmod-cryptode

[OpenWrt-Devel] build: sysupgrade: kernel: mtd: Image too SMALL to Restore Config

2019-07-01 Thread Jeff Kletsky 

I've run across some seemingly "wrong" behavior related to sysupgrade
where if the image is "too small" the contents of /sysupgrade.tgz are
not properly recovered on reboot.

It seems as if the various pieces are functioning as expected, but
that they do not work in concert under certain situations. It seems as
though /sysupgrade.tgz is written where

  mtd write -j /tmp/sysupgrade.tgz -

intends, but when the kernel splits the partition into rootfs and
rootfs_data, the split is 0x1 "early", likely resulting in the
JFFS2 believing that rootfs_data is "empty".

Prior to trying to "fix" this, I'd like to confirm the expected
behavior. `default_do_upgrade()` is writing the upgrade.


---


The smaller, "failing" image contains

003eb6f0  3e 30 0d 8b 02 00 00 00  00 01 59 5a de b2 20 00 
|>0YZ.. .|
003eb700  00 00 00 00 04 80 00 00  00 00 04 b7 20 00 00 00 | 
...|
003eb710  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003eb720  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  de ad c0 de 00 00 00 00  00 00 00 00 7b 20 20 22 
|{  "|
00400010  6d 65 74 61 64 61 74 61  5f 76 65 72 73 69 6f 6e 
|metadata_version|



and results in the MTD firmware partition containing

003eb6f0  3e 30 0d 8b 02 00 00 00  00 01 59 5a de b2 20 00 
|>0YZ.. .|
003eb700  00 00 00 00 04 80 00 00  00 00 04 b7 20 00 00 00 | 
...|
003eb710  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003eb720  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. 
..`..|
00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 
|...6]DH.|
00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b 
|...[|
00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 
|1.=.sysupgrade.t|
00400040  67 7a ff ff 19 85 e0 02  00 00 10 44 ee 2d 30 6f 
|gz.D.-0o|




The larger, "succeeding" image contains

003effe0  3e 30 0d 8b 02 00 00 00  00 01 59 5a ce fb 20 00 
|>0YZ.. .|
003efff0  00 00 00 00 04 80 00 00  00 00 f4 ff 20 00 00 00 | 
...|
003f  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003f0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  de ad c0 de 00 00 00 00  00 00 00 00 7b 20 20 22 
|{  "|
00400010  6d 65 74 61 64 61 74 61  5f 76 65 72 73 69 6f 6e 
|metadata_version|



and results in the MTD firmware partition containing

003effe0  3e 30 0d 8b 02 00 00 00  00 01 59 5a ce fb 20 00 
|>0YZ.. .|
003efff0  00 00 00 00 04 80 00 00  00 00 f4 ff 20 00 00 00 | 
...|
003f  00 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
003f0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. 
..`..|
00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 
|...6]DH.|
00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b 
|...[|
00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 
|1.=.sysupgrade.t|
00400040  67 7a ff ff 19 85 e0 02  00 00 10 44 ee 2d 30 6f 
|gz.D.-0o|



Note that the difference between the two is the length of the squashfs
crossing an erase-block boundary.

It appears from the build logs that `padjffs2` is being called in the
default image-generation process.  I have not yet located where in the
make files the default rule(s) are defined.

The on-flash data appears to be consistent with the code in
package/system/mtd/src/mtd.c which looks for JFFS2_EOF
#define JFFS2_EOF "\xde\xad\xc0\xde"

---

When the system boots, in the "failing" case, the MTD split is
"early", at at 0x3f, compared to the location of the
JFFS2_NODETYPE_CLEANMARKER `19 85 20 03` at 0x40

[    0.435672] 0x0005-0x00ff : "firmware"
[    0.444132] 2 uimage-fw partitions found on MTD device firmware
[    0.450255] Creating 2 MTD partitions on "firmware":
[    0.455441] 0x-0x001e : "kernel"
[    0.461418] 0x001e-0x00fa : "rootfs"
[    0.467345] mtd: device 4 (rootfs) set to be root filesystem
[    0.474785] mtdsplit: squashfs length: 0x20b712
[    0.479477] mtdsplit_squashfs: part_offset:  0x001e
[    0.484828] mtdsplit_squashfs: squashfs_len: 0x0020b712
[    0.490222] mtdsplit_squashfs: sum:  0x003eb712
[    0.494923] mtdsplit_squashfs: part->offset: 0x0021
[    0.505635] 1 squashfs-split partitions found on MTD device rootfs
[    0.512029] 0x003f-0x00fa : "rootfs_data"
[    0.518440] 0x00ff-0x0100 : "art"


In the "succeeding" case, the split is at the CLEANMARKER

[    0.435680] 0x0005-0x00ff : "firmware"
[    0.444143] 2 uimage-fw partitions found on MTD device firmware
[    0.450264] Creating 2 MTD partitions on "firmware":
[    0.455449] 0x00

Re: [OpenWrt-Devel] build: sysupgrade: kernel: mtd: Image too SMALL to Restore Config

2019-07-01 Thread Hannu Nyman 

The smaller, "failing" image contains in /dev/mtd2:



003eebd0 00 01 59 5a be e7 20 00  00 00 00 00 04 80 00 00  |..YZ.. .|
003eebe0  00 00 dc eb 20 00 00 00  00 00 ff ff ff ff ff ff  | ...|
003eebf0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff ||
*
0040  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. ..`..|
00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 |...6]DH.|
00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b |...[|
00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 |1.=.sysupgrade.t|



The failure may actually be on the image sysupgrade appending logic during 
sysupgrade/flash time, not in the boot time logic. The interesting part is 
that the appended sysupgrade data starts at 0x40 in both cases, 
eventhough the firmware image ends at 0x3eb3710 in the failing case. In the 
failing case, there is thus an extra 64 kB of empty 0xff before the appended 
sysupgrade.tgz, and that causes the sysupgrade archive detection problem at 
the boot time (as the detection looks properly at 0x3f and finds nothing).


Possible mismatch in the eraseblock size detection? Maybe the sysupgrade 
creation script or padjffs thinks that you have a 128 kB erase block instead 
of 64 kB, and pads up to 0x40 instead of 0x3f, so that theer is no 
deadcode indicator at 0x3f.


Your secondary NAND flash seems to have 128 kB block size?
 spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048, OOB 
size: 128


Any way that you get into picture here and create confusion about the NOR 
flash block size?  Dual NOR/NAND flash systems are rare, which could explain 
why nobody has stumbled into this earlier.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] build: sysupgrade: kernel: mtd: Image too SMALL to Restore Config

2019-07-01 Thread Hannu Nyman 

The smaller, "failing" image contains in /dev/mtd2:



003eebd0 00 01 59 5a be e7 20 00  00 00 00 00 04 80 00 00  |..YZ.. .|
003eebe0  00 00 dc eb 20 00 00 00  00 00 ff ff ff ff ff ff  | ...|
003eebf0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff ||
*
0040  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. ..`..|
00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 |...6]DH.|
00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b |...[|
00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 |1.=.sysupgrade.t|



The failure may actually be on the image sysupgrade appending logic during 
sysupgrade/flash time, and not in the boot time logic. The interesting part 
is that the appended sysupgrade data starts at 0x40 in both cases, 
eventhough the firmware image ends at 0x3eb3710 in the failing case. In the 
failing case, there is thus an extra 64 kB of empty 0xff before the appended 
sysupgrade.tgz, and that possibly causes the sysupgrade archive detection 
problem at the boot time (as the detection looks properly at 0x3f based 
on the split-detected jffs2 size and finds nothing).


Possible mismatch in the eraseblock size detection? Maybe the sysupgrade 
creation script or padjffs thinks that you have a 128 kB erase block instead 
of 64 kB, and pads up to 0x40 instead of 0x3f, so that theer is no 
deadcode indicator at 0x3f.


Your secondary NAND flash seems to have 128 kB block size?
 spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048, OOB 
size: 128


Any way that you get into picture here and create confusion about the NOR 
flash block size?  Dual NOR/NAND flash systems are rare, which could explain 
why nobody has stumbled into this earlier.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: have scripts/feeds honor all toplevel .mk-files of a feed

2019-07-01 Thread Sven Roederer 
Hi,

based on the recent commit of "scripts/feeds: add src-include method" 
I remembered in my patch I sent some time ago.
As Jo suggested it's now adding a dependency to all .mk files in a feeds
root-folder.

I assume it was just overseen or is there something bad? We use it for
some time for our freifunk-firmware already.

Sven

Am Samstag, 9. März 2019, 15:00:15 CEST schrieb Sven Roederer:
> The luci and freifunk feed having a common Makefile included by the
> individual packages. Currently a change to this file will be ignored
> when running "scripts/feeds update".
> When we are updating for a feed, add a dependency for all .mk files
> in the root of it.
> 
> Signed-off-by: Sven Roederer 
> ---
>  include/scan.mk | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/include/scan.mk b/include/scan.mk
> index d9cd4f7e8c..7df5dc6486 100644
> --- a/include/scan.mk
> +++ b/include/scan.mk
> @@ -12,10 +12,17 @@
> OVERRIDELIST:=$(TMP_DIR)/info/.overrides-$(SCAN_TARGET)-$(SCAN_COOKIE)
> 
>  export PATH:=$(TOPDIR)/staging_dir/host/bin:$(PATH)
> 
> +define feedname
> +$(if $(patsubst feeds/%,,$(1)),,$(word 2,$(subst /, ,$(1
> +endef
> +
>  ifeq ($(SCAN_NAME),target)
>SCAN_DEPS=image/Makefile profiles/*.mk $(TOPDIR)/include/kernel*.mk
> $(TOPDIR)/include/target.mk image/*.mk else
>SCAN_DEPS=$(TOPDIR)/include/package*.mk
> +ifneq ($(call feedname,$(SCAN_DIR)),)
> +  SCAN_DEPS += $(TOPDIR)/feeds/$(call feedname,$(SCAN_DIR))/*.mk
> +endif
>  endif
> 
>  ifeq ($(IS_TTY),1)
> @@ -34,10 +41,6 @@ else
>endef
>  endif
> 
> -define feedname
> -$(if $(patsubst feeds/%,,$(1)),,$(word 2,$(subst /, ,$(1
> -endef
> -
>  define PackageDir
>$(TMP_DIR)/.$(SCAN_TARGET): $(TMP_DIR)/info/.$(SCAN_TARGET)-$(1)
>$(TMP_DIR)/info/.$(SCAN_TARGET)-$(1): $(SCAN_DIR)/$(2)/Makefile $(foreach
> DEP,$(DEPS_$(SCAN_DIR)/$(2)/Makefile) $(SCAN_DEPS),$(wildcard $(if $(filter
> /%,$(DEP)),$(DEP),$(SCAN_DIR)/$(2)/$(DEP





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] build: sysupgrade: kernel: mtd: Image too SMALL to Restore Config

2019-07-01 Thread Jeff Kletsky 
Thanks! Blocksize turned out to be the issue -- resolved for the devices 
in question.


I'm still interested in finding out where the definition of the 
"default" sysupgrade.img

is found in make files of the build system.

Jeff


On 7/1/19 1:47 PM, Hannu Nyman wrote:

The smaller, "failing" image contains in /dev/mtd2:


003eebd0 00 01 59 5a be e7 20 00  00 00 00 00 04 80 00 00  |..YZ.. 
.|
003eebe0  00 00 dc eb 20 00 00 00  00 00 ff ff ff ff ff ff | 
...|
003eebf0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
0040  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. 
..`..|
00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 
|...6]DH.|
00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b 
|...[|
00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 
|1.=.sysupgrade.t|



The failure may actually be on the image sysupgrade appending logic 
during sysupgrade/flash time, and not in the boot time logic. The 
interesting part is that the appended sysupgrade data starts at 
0x40 in both cases, eventhough the firmware image ends at 
0x3eb3710 in the failing case. In the failing case, there is thus an 
extra 64 kB of empty 0xff before the appended sysupgrade.tgz, and that 
possibly causes the sysupgrade archive detection problem at the boot 
time (as the detection looks properly at 0x3f based on the 
split-detected jffs2 size and finds nothing).


Possible mismatch in the eraseblock size detection? Maybe the 
sysupgrade creation script or padjffs thinks that you have a 128 kB 
erase block instead of 64 kB, and pads up to 0x40 instead of 
0x3f, so that theer is no deadcode indicator at 0x3f.


Your secondary NAND flash seems to have 128 kB block size?
 spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048, 
OOB size: 128


Any way that you get into picture here and create confusion about the 
NOR flash block size?  Dual NOR/NAND flash systems are rare, which 
could explain why nobody has stumbled into this earlier.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel