[OpenWrt-Devel] [PATCH ustream-ssl] ustream-openssl: clear error stack before SSL_read/SSL_write

2020-03-13 Thread Jo-Philipp Wich
The OpenSSL library uses a global error queue per thread which needs to
be cleared prior to calling I/O functions in order to get reliable error
results.

Failure to do so will lead to stray errors reported by SSL_get_error()
when an unrelated connection within the same thread encountered a TLS
error since the last SSL_read() or SSL_write() on the current connection.

This issue was frequently triggered by Google Chrome which usually
initiates simultaneous TLS connections (presumably for protocol support
probing) and subsequently closes most of them with a "certificate unknown"
TLS error, causing the next SSL_get_error() to report an SSL library error
instead of the expected SSL_WANT_READ or SSL_WANT_WRITE error states.

Solve this issue by invoking ERR_clear_error() prior to invoking SSL_read()
or SSL_write() to ensure that the subsequent SSL_get_error() returns
current valid results.

Signed-off-by: Jo-Philipp Wich 
---
 ustream-openssl.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ustream-openssl.c b/ustream-openssl.c
index 049aa40..f8e848d 100644
--- a/ustream-openssl.c
+++ b/ustream-openssl.c
@@ -266,6 +266,8 @@ __hidden enum ssl_conn_status __ustream_ssl_connect(struct 
ustream_ssl *us)
void *ssl = us->ssl;
int r;
 
+   ERR_clear_error();
+
if (us->server)
r = SSL_accept(ssl);
else
@@ -287,7 +289,11 @@ __hidden enum ssl_conn_status __ustream_ssl_connect(struct 
ustream_ssl *us)
 __hidden int __ustream_ssl_write(struct ustream_ssl *us, const char *buf, int 
len)
 {
void *ssl = us->ssl;
-   int ret = SSL_write(ssl, buf, len);
+   int ret;
+
+   ERR_clear_error();
+
+   ret = SSL_write(ssl, buf, len);
 
if (ret < 0) {
int err = SSL_get_error(ssl, ret);
@@ -303,7 +309,11 @@ __hidden int __ustream_ssl_write(struct ustream_ssl *us, 
const char *buf, int le
 
 __hidden int __ustream_ssl_read(struct ustream_ssl *us, char *buf, int len)
 {
-   int ret = SSL_read(us->ssl, buf, len);
+   int ret;
+
+   ERR_clear_error();
+
+   ret = SSL_read(us->ssl, buf, len);
 
if (ret < 0) {
ret = SSL_get_error(us->ssl, ret);
-- 
2.25.1


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


Re: [OpenWrt-Devel] Security implications for consideration [Was: Re: [openwrt/openwrt] rpcd: add respawn param]

2020-03-04 Thread Jo-Philipp Wich
Hi,

> [...]

feel free to revert it.

~ Jo



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] [PATCH v2] wireguard: fix interface remove for lonely peers

2020-03-03 Thread Jo-Philipp Wich
Hi Florian,

> Deleting an interface section in LuCI is generic. So I don't know if we should
> do this and make an exception for wireguard.

proper removal of wg peer sections is in LuCI master and openwrt-19.07 now.

~ Jo



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] Next maintenance releases

2020-02-21 Thread Jo-Philipp Wich
Hi,

I'd like to release 19.07.2 and 18.06.8 sometime between Sun 23rd and
Tue 25th. If you have pending important fixes you like to see backported
to the respective branches please do so ASAP or mention the commits in a
reply to this mail.


Regards,
Jo

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


[OpenWrt-Devel] [PATCH uclient] uclient-fetch: support specifying advertised TLS ciphers

2020-02-15 Thread Jo-Philipp Wich
Introduce a new `--ciphers` option which allows specifying a colon separated
list of usable TLS ciphers.

Depending on the underlying ustream-ssl provider, the list either follows
OpenSSL's cipher string format or, in case of mbedTLS, is a simple colon
separated cipher whitelist.

Signed-off-by: Jo-Philipp Wich 
---
 uclient-fetch.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 38c9c53..a06be5d 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -467,6 +467,7 @@ static int usage(const char *progname)
"HTTPS options:\n"
"   --ca-certificate= Load CA certificates 
from file \n"
"   --no-check-certificate  don't validate the 
server's certificate\n"
+   "   --ciphers=  Set the cipher list 
string\n"
"\n", progname);
return 1;
 }
@@ -510,6 +511,7 @@ static int no_ssl(const char *progname)
 enum {
L_NO_CHECK_CERTIFICATE,
L_CA_CERTIFICATE,
+   L_CIPHERS,
L_USER,
L_PASSWORD,
L_USER_AGENT,
@@ -525,6 +527,7 @@ enum {
 static const struct option longopts[] = {
[L_NO_CHECK_CERTIFICATE] = { "no-check-certificate", no_argument },
[L_CA_CERTIFICATE] = { "ca-certificate", required_argument },
+   [L_CIPHERS] = { "ciphers", required_argument },
[L_USER] = { "user", required_argument },
[L_PASSWORD] = { "password", required_argument },
[L_USER_AGENT] = { "user-agent", required_argument },
@@ -568,6 +571,15 @@ int main(int argc, char **argv)
if (ssl_ctx)

ssl_ops->context_add_ca_crt_file(ssl_ctx, optarg);
break;
+   case L_CIPHERS:
+   if (ssl_ctx) {
+   if 
(ssl_ops->context_set_ciphers(ssl_ctx, optarg)) {
+   if (!quiet)
+   fprintf(stderr, "No 
recognized ciphers in cipher list\n");
+   exit(1);
+   }
+   }
+   break;
case L_USER:
if (!strlen(optarg))
break;
-- 
2.25.0


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


[OpenWrt-Devel] [PATCH uhttpd] tls: support specifying accepted TLS ciphers

2020-02-15 Thread Jo-Philipp Wich
Introduce a new `-P` option which allows specifying a colon separated list
of accepted TLS ciphers.

Depending on the underlying ustream-ssl provider, the list either follows
OpenSSL's cipher string format or, in case of mbedTLS, is a simple colon
separated cipher whitelist.

Signed-off-by: Jo-Philipp Wich 
---
 main.c | 12 +---
 tls.c  |  7 ++-
 tls.h  |  4 ++--
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/main.c b/main.c
index 6c29afe..26e74ec 100644
--- a/main.c
+++ b/main.c
@@ -139,6 +139,7 @@ static int usage(const char *name)
"   -s [addr:]port  Like -p but provide HTTPS on this 
port\n"
"   -C file ASN.1 server certificate file\n"
"   -K file ASN.1 server private key file\n"
+   "   -P ciphers  Colon separated list of allowed TLS 
ciphers\n"
"   -q  Redirect all HTTP requests to HTTPS\n"
 #endif
"   -h directorySpecify the document root, default is 
'.'\n"
@@ -249,7 +250,7 @@ int main(int argc, char **argv)
int bound = 0;
 #ifdef HAVE_TLS
int n_tls = 0;
-   const char *tls_key = NULL, *tls_crt = NULL;
+   const char *tls_key = NULL, *tls_crt = NULL, *tls_ciphers = NULL;
 #endif
 #ifdef HAVE_LUA
const char *lua_prefix = NULL, *lua_handler = NULL;
@@ -261,7 +262,7 @@ int main(int argc, char **argv)
init_defaults_pre();
signal(SIGPIPE, SIG_IGN);
 
-   while ((ch = getopt(argc, argv, 
"A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
+   while ((ch = getopt(argc, argv, 
"A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
switch(ch) {
 #ifdef HAVE_TLS
case 'C':
@@ -272,6 +273,10 @@ int main(int argc, char **argv)
tls_key = optarg;
break;
 
+   case 'P':
+   tls_ciphers = optarg;
+   break;
+
case 'q':
conf.tls_redirect = 1;
break;
@@ -282,6 +287,7 @@ int main(int argc, char **argv)
 #else
case 'C':
case 'K':
+   case 'P':
case 'q':
case 's':
fprintf(stderr, "uhttpd: TLS support not compiled, "
@@ -523,7 +529,7 @@ int main(int argc, char **argv)
return 1;
}
 
-   if (uh_tls_init(tls_key, tls_crt))
+   if (uh_tls_init(tls_key, tls_crt, tls_ciphers))
return 1;
}
 #endif
diff --git a/tls.c b/tls.c
index d969b82..1da0881 100644
--- a/tls.c
+++ b/tls.c
@@ -31,7 +31,7 @@ static struct ustream_ssl_ops *ops;
 static void *dlh;
 static void *ctx;
 
-int uh_tls_init(const char *key, const char *crt)
+int uh_tls_init(const char *key, const char *crt, const char *ciphers)
 {
static bool _init = false;
 
@@ -63,6 +63,11 @@ int uh_tls_init(const char *key, const char *crt)
return -EINVAL;
}
 
+   if (ciphers && ops->context_set_ciphers(ctx, ciphers)) {
+   fprintf(stderr, "No recognized ciphers in cipher list\n");
+   return -EINVAL;
+   }
+
return 0;
 }
 
diff --git a/tls.h b/tls.h
index 9be74ba..f457cb7 100644
--- a/tls.h
+++ b/tls.h
@@ -22,13 +22,13 @@
 
 #ifdef HAVE_TLS
 
-int uh_tls_init(const char *key, const char *crt);
+int uh_tls_init(const char *key, const char *crt, const char *ciphers);
 void uh_tls_client_attach(struct client *cl);
 void uh_tls_client_detach(struct client *cl);
 
 #else
 
-static inline int uh_tls_init(const char *key, const char *crt)
+static inline int uh_tls_init(const char *key, const char *crt, const char 
*ciphers)
 {
return -1;
 }
-- 
2.25.0


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


[OpenWrt-Devel] [PATCH ustream-ssl] add support for specifying usable ciphers

2020-02-15 Thread Jo-Philipp Wich
Implement a new ustream_ssl_ops.context_set_ciphers() function which allows
to specify the usable ciphers for TLS context which is useful to restrict
the accepted cipher subset especially for ustream-ssl server applications.

For the OpenSSL backend, the given cipher string is passed as-is to the
SSL_CTX_set_cipher_list().

For mbedTLS, the given string is split on colons and each item of the list
is resolved through mbedtls_ssl_get_ciphersuite_id() to construct a numeric
list of allowed ciphers.

Note that OpenSSL and mbedTLS use different names for their ciphers but both
implementations simply ignore unknown names, so it is possible to specify
cipherstrings which are applicable to either library, e.g. `-ALL:ECDHE-
ECDSA-AES128-GCM-SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` would
enable ChaCha20/Poly1305 in both OpenSSL and mbedTLS.

Another crucial difference between the libraries is that the cipherstring
in mbedTLS is effectively a whitelist of allowed ciphers while, without
additional syntax elements, OpenSSL's cipherstring merely appends ciphers
to the default selection.

Ref: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html
Ref: https://tls.mbed.org/api/ssl_8h.html#a9914cdf5533e813e1ea7ca52981aa006
Signed-off-by: Jo-Philipp Wich 
---
 ustream-internal.h |  1 +
 ustream-mbedtls.c  | 66 ++
 ustream-mbedtls.h  |  1 +
 ustream-openssl.c  | 11 +++-
 ustream-ssl.c  |  1 +
 ustream-ssl.h  |  3 +++
 6 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/ustream-internal.h b/ustream-internal.h
index 8d5d0db..147141a 100644
--- a/ustream-internal.h
+++ b/ustream-internal.h
@@ -38,6 +38,7 @@ struct ustream_ssl_ctx *__ustream_ssl_context_new(bool 
server);
 int __ustream_ssl_add_ca_crt_file(struct ustream_ssl_ctx *ctx, const char 
*file);
 int __ustream_ssl_set_crt_file(struct ustream_ssl_ctx *ctx, const char *file);
 int __ustream_ssl_set_key_file(struct ustream_ssl_ctx *ctx, const char *file);
+int __ustream_ssl_set_ciphers(struct ustream_ssl_ctx *ctx, const char 
*ciphers);
 void __ustream_ssl_context_free(struct ustream_ssl_ctx *ctx);
 enum ssl_conn_status __ustream_ssl_connect(struct ustream_ssl *us);
 int __ustream_ssl_read(struct ustream_ssl *us, char *buf, int len);
diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
index 74c27a5..9f73c58 100644
--- a/ustream-mbedtls.c
+++ b/ustream-mbedtls.c
@@ -225,6 +225,71 @@ __hidden int __ustream_ssl_set_key_file(struct 
ustream_ssl_ctx *ctx, const char
return 0;
 }
 
+__hidden int __ustream_ssl_set_ciphers(struct ustream_ssl_ctx *ctx, const char 
*ciphers)
+{
+   int *ciphersuites = NULL, *tmp, id;
+   char *cipherstr, *p, *last, c;
+   size_t len = 0;
+
+   if (ciphers == NULL)
+   return -1;
+
+   cipherstr = strdup(ciphers);
+
+   if (cipherstr == NULL)
+   return -1;
+
+   for (p = cipherstr, last = p;; p++) {
+   if (*p == ':' || *p == 0) {
+   c = *p;
+   *p = 0;
+
+   id = mbedtls_ssl_get_ciphersuite_id(last);
+
+   if (id != 0) {
+   tmp = realloc(ciphersuites, (len + 2) * 
sizeof(int));
+
+   if (tmp == NULL) {
+   free(ciphersuites);
+   free(cipherstr);
+
+   return -1;
+   }
+
+   ciphersuites = tmp;
+   ciphersuites[len++] = id;
+   ciphersuites[len] = 0;
+   }
+
+   if (c == 0)
+   break;
+
+   last = p + 1;
+   }
+
+   /*
+* mbedTLS expects cipher names with dashes while many sources 
elsewhere
+* like the Firefox wiki or Wireshark specify ciphers with 
underscores,
+* so simply convert all underscores to dashes to accept both 
notations.
+*/
+   else if (*p == '_') {
+   *p = '-';
+   }
+   }
+
+   free(cipherstr);
+
+   if (len == 0)
+   return -1;
+
+   mbedtls_ssl_conf_ciphersuites(>conf, ciphersuites);
+   free(ctx->ciphersuites);
+
+   ctx->ciphersuites = ciphersuites;
+
+   return 0;
+}
+
 __hidden void __ustream_ssl_context_free(struct ustream_ssl_ctx *ctx)
 {
 #if defined(MBEDTLS_SSL_CACHE_C)
@@ -234,6 +299,7 @@ __hidden void __ustream_ssl_context_free(struct 
ustream_ssl_ctx *ctx)
mbedtls_x509_crt_free(>ca_cert);
mbedtls_x509_crt_free(>cert);
mbedtls_ssl_config_free(>conf);
+   free(ctx->ciphersuites);
free(ctx);
 }
 
diff --git a/ustream-mbedtls.h b/ustream-mbedtls.h
index 0e5988a..e622e5e 100644
--- a/ustream-mb

Re: [OpenWrt-Devel] [PATCH] ath79: introduces KERNEL_LZMA variable for common build sequence

2020-02-03 Thread Jo-Philipp Wich
Hi,

what is the actual benefit of this? The image building recipes are hard enough
to understand as-is, is it really worth it to replace a plain "kernel-bin |
append-dtb | lzma" command sequence with yet another variable indirection just
to safe a few bytes in the Makefile?

I could understand the appeal of introducing a macro (or variable) if there's
a lot of repeated complex expressions in each KERNEL := ... recipe but that
isn't the case here.

If you really want to go down this route, then introducing an actual new build
step which aggregates the three steps into one would be cleaner imho.

Something similar to the following;

define Build/kernel-dtb-lzma
$(call Build/kernel-bin)
$(call Build/append-dtb)
$(call Build/lzma)
endef

And then

KERNEL := kernel-dtb-lzma | uImage lzma


~ Jo



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] Merged: buildbot: signall.sh store usign.key asusign.sec

2020-02-02 Thread Jo-Philipp Wich
Merged into buildbot.git, branch master at
http://git.lede-project.org/?p=buildbot.git.

Thank you!


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


Re: [OpenWrt-Devel] RFI: OpenWRT Upgrade System; ENH,SEC suggestions

2020-02-01 Thread Jo-Philipp Wich
Hi Wes,

> It's definitely an issue that the sha256 checksum check was broken.
> But, can someone explain why a person who is MITM'ing ipk downloads
> would change the package and not the checksum?

the repository index files containing the SHA256 checksums are signed using
usign, which is a derivate of the ECDSA based OpenBSD signify utility. The
public ECDSA key is built into the firmware image and used to check the
signify-signed repository index. Forging the index itself is not possible
without possession of the secret key.

> Are there GPG signatures of the package checksums signed with a key
> that ships with the release?

There are usign (signify) ECDSA ones.

> Are package repos downloaded over HTTPS? Is there a CA bundle in the
> release with which repo x.509 certs are validated?

No since so far the required storage footprint for a functional SSL stack
(library plus certs etc.) exceeded the available space on a large fraction of
supported models.

> The OpenWRT firmware couldn't access https sites without installing
> multiple packages first. Then they had me install all the root certs
> over an unencrypted connection. The opkg repos and install files are
> all downloaded over http.

Yes but they are (assuming fixed SHA256 issue) verified using preshared EC keys.

1) opkg downloads Packages.gz and Packages.sig, if either of these fail,
   the repo is ignored
2) opkg verifies that the uncompressed contents of Packages.gz match the
   Packages.sig signature using EC keys built into the image, if the signature
   cannot be verified, the downloaded lists are deleted and the repo is
   ignored
3) opkg translates package names to actual file names using the verified
   package index information and downloads these .ipk files
4) opkg verifies that the size of the downloaded .ipk files match the size
   mentioned in the verified package index information, if not the downloaded
   package is deleted and the installation aborted
5) opkg computes the sha256 sums of the downloaded .ipk files and verifies
   that they match the ones specified in the verified package index
   information, if not the downloaded package is deleted and the installation
   aborted [this step has been fixed]
6) opkg unpacks and installs the .ipk

> With full seriousness, I really hope nobody expects operational
> security using these routers.

Depends on the thread model of course but without an encrypted transport
channel, there'll be no confidentiality about the packages being installed,
but [assuming a fixed opkg] it is not possible to modify the contents in-flight.

> Side note: something like these would be great to have; IDK which
> repos are appropriate for possible new issues to be owned by someone
> who knows what is going on:
> 
> ENH: CDN for package repos and latest version file

We're in the process of testing cdn.openwrt.org which has been sponsored by
KeyCDN but so far the results are mixed and we're having consistency issues yet.

> ENH,SEC: firmware update check script

Yeah, that would be good.

> ENH,SEC: send an email when the firmware is out of date

I don't see how this can be done reliably as most mails sent directly from
dynamic dialup IPs are classified spam nowadays. Any other solution would
require embedding secrets in the firmware images.

> ENH,SEC: luci: display firmware update check result and link to latest 
> firmware

Yes, that would be useful.

> ENH,SEC: add package repo (and firmware?) signing key to keyring

They are.

> ENH,SEC: include ca-certificates and/or openwrt-certificates in builds?

That wasn't feasible so far due to the 4MB flash support target.

HTH,
Jo



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] Security Advisory 2020-01-31-2 - libubox tagged binary data JSON serialization vulnerability (CVE-2020-7248)

2020-01-31 Thread Jo-Philipp Wich
DESCRIPTION

Possibly exploitable vulnerability exists in the libubox library of OpenWrt,
specifically in the parts related to JSON conversion of tagged binary data,
so called blobs.  An attacker could possibly exploit this behavior by
providing specially crafted binary blob or JSON which would then be translated
into blob internally.

This malicious blobmsg input would contain blob attribute holding large enough
numeric value of type double which then processed by blobmsg_format_json would
overflow the buffer array designated for JSON output allocated on the stack.

The libubox library is a core component in the OpenWrt project and utilized in
other parts of the project. Those interdependencies are visible by looking up
of the above mentioned vulnerable blobmsg_format_json function in the
project's LXR[1], which reveals references in netifd, procd, ubus, rpcd,
uhttpd.

Apart from this core components, there is also auc[2] package providing
Attended sysUpgrade CLI in the packages feeds repository, which seems to be
using this vulnerable function.

CVE-2020-7248 has been assigned to this issue.


REQUIREMENTS

In order to exploit this vulnerability, a malicious attacker would need to
provide specially crafted binary blobs or JSON input to blobmsg_format_json,
thus creating stack based overflow condition during serialization of the
double value into the JSON buffer.

It was verified, that its possible to crash rpcd by following shell command:

  $ ubus call luci getFeatures \
  '{ "banik": 00192200197600198000198100200400.1922 }'


MITIGATIONS

To fix this issue, update the affected libubox using the command below.

   opkg update; opkg upgrade libubox

The fix is contained in the following and later versions:

 - OpenWrt master: 2020-01-20 reboot-12063-g5c73bb12c82c
 - OpenWrt 19.07:  2019-01-29 v19.07.1-1-g4668ae3bed
 - OpenWrt 18.06:  2019-01-29 v18.06.7-1-g6bfde67581



AFFECTED VERSIONS

To our knowledge, OpenWrt versions 18.06.0 to 18.06.6 and versions 19.07.0-rc1
to 19.07.0 are affected. The fixed packages will be integrated in the OpenWrt
19.07.1, 18.06.7 and subsequent releases. Older versions of OpenWrt (e.g.
OpenWrt 15.05 and LEDE 17.01) are end of life and not supported any more.

Other users of libubox should update to the latest version ASAP.


CREDITS

The issues were discovered and fixed by Petr Štetiar and Jo-Philipp Wich.


REFERENCES

1. https://lxr.openwrt.org/ident?i=blobmsg_format_json
2. https://github.com/openwrt/packages/blob/master/utils/auc/src/auc.c#L676



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] Security Advisory 2020-01-31-1 - Opkg susceptible to MITM (CVE-2020-7982)

2020-01-31 Thread Jo-Philipp Wich
DESCRIPTION

A bug in the package list parse logic of OpenWrt's opkg fork caused the
package manager to ignore SHA-256 checksums embedded in the signed repository
index, effectively bypassing integrity checking of downloaded .ipk artifacts.

The bug has been introduced with commit https://git.openwrt.org/54cc7e3 which
failed to advance the proper string pointer when skipping the leading white-
space portition of the checksum string, causing the subsequent hex decoding
loop to return early with a zero length checksum.

Due to the fact that opkg on OpenWrt runs as root and has write access to the
entire filesystem, arbitrary code could be injected by the means of forged
.ipk packages with malicious payload.

CVE-2020-7982 has been assigned to this issue.


REQUIREMENTS

In order to exploit this vulnerability, a malicious actor needs to pose as
MITM, serving a valid and signed package index - e.g. one obtained from
downloads.openwrt.org - and one or more forged .ipk packages having the same
size as specified in the repository index while an `opkg install` command
is invoked on the victim system.


MITIGATIONS

To fix this issue, upgrade to the latest OpenWrt version. The fix is contained
in the following and later OpenWrt releases:

  * OpenWrt master: 2020-01-29 reboot-12146-gc69c20c667
  * OpenWrt 19.07:  2019-01-29 v19.07.1-1-g4668ae3bed
  * OpenWrt 18.06:  2019-01-29 v18.06.7-1-g6bfde67581

The fixed opkg package will carry the version 2020-01-25.


Alternatively, to update the opkg package itself without upgrading the entire
firmware, the following commands may be used once all repositories have been
updated:

   cd /tmp
   opkg update
   opkg download opkg
   zcat ./opkg-lists/openwrt_base | grep -A10 "Package: opkg" | grep SHA256sum
   sha256sum ./opkg_2020-01-25-c09fe209-1_*.ipk

Compare both checksums and, if matching, proceed with installing the package:

   opkg install ./opkg_2020-01-25-c09fe209-1_*.ipk


AFFECTED VERSIONS

To our knowledge, OpenWrt versions 18.06.0 to 18.06.6 and 19.07.0 as well as
LEDE 17.01.0 to 17.01.7 are affected. The fixed packages are integrated in
the OpenWrt 18.06.7, OpenWrt 19.07.1 and subsequent releases.

Older versions of OpenWrt (e.g. OpenWrt 15.05 and LEDE 17.01) are end of life
and not supported any more.


CREDITS

The issue was discovered by Guido Vranken for ForAllSecure, Inc.





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] OpenWrt 19.07.1 service release

2020-01-31 Thread Jo-Philipp Wich
Hi,

The OpenWrt Community is proud to announce the first service release of
the stable OpenWrt 19.07 series. OpenWrt 19.07.1 incorporates important
security updates for base packages, fixes for 5GHz performance issues and flow
offloading memory leaks as well as new versions of the Linux kernel and fixes
for various devices.


Selected highlights of this service release are:

 * Linux kernel updated from 4.14.162 to 4.14.167
 * Important security fixes for opkg and libubox
 * Flow offloading memory leak fixes
 * 5GHz performance fixes
 * Device support fixes for Ubiquiti Rocket M Titanium, Netgear WN2500RP v1,
   Zyxel NSA325, Netgear WNR3500 V2, Archer C6 v2, Ubiquiti EdgeRouter-X,
   Archer C20 v4, Archer C50 v4 Archer MR200, TL-WA801ND v5, HiWiFi HC5962,
   Xiaomi Mi Router 3 Pro, Netgear R6350

For a detailed list of changes since 19.07.0 refer to
https://openwrt.org/releases/19.07/changelog-19.07.1



For latest information about the 19.07 series, refer to the wiki at:
https://openwrt.org/releases/19.07/

To download the v19.07.1 images, navigate to:
https://downloads.openwrt.org/releases/19.07.1/

As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.

Have fun!

The OpenWrt Community





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] OpenWrt 18.06.7 service release

2020-01-31 Thread Jo-Philipp Wich
Hi,

The OpenWrt Community is proud to announce the seventh service release of
the stable OpenWrt 18.06 series. OpenWrt 18.06.7 incorporates important
security updates for base packages, new versions of the Linux kernel and fixes
for various devices.


Selected highlights of this service release are:

 * Linux kernel updated from 4.9.208 to 4.9.211 and
   from 4.14.162 to 4.14.167
 * Important security fixes for opkg and libubox
 * Device support fixes for Zyxel NSA325, Netgear WN2500RP v1,
   Netgear WNR3500 v2, HiWiFi HC5962

For a detailed list of changes since 18.06.6 refer to
https://openwrt.org/releases/18.06/changelog-18.06.7



For latest information about the 18.06 series, refer to the wiki at:
https://openwrt.org/releases/18.06/

To download the v18.06.7 images, navigate to:
https://downloads.openwrt.org/releases/18.06.7/

As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.

Have fun!

The OpenWrt Community



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] Merged: fw3: robustify flow table detection.

2020-01-28 Thread Jo-Philipp Wich
Merged into project/firewall3.git, branch master at
http://git.lede-project.org/?p=project/firewall3.git.

Thank you!


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


Re: [OpenWrt-Devel] [PATCH] fw3: robustify flow table detection.

2020-01-23 Thread Jo-Philipp Wich
Hi,

> This doesn't seem right to me in case target > 12,
> MIN(sizeof(line), strlen(target)) perhaps?

a simple strcmp() without len will be the most appropriate since both
line (produced by fgets()) and target (a constant string literal) will
be \0 terminated.

~ Jo



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] [PATCH v2 5/5] hostapd: wpa_supplicant: enable proper GCMP cipher support

2020-01-16 Thread Jo-Philipp Wich
Hi,

> + case "$wpa_cipher" in
> + GCMP)
> + append network_data "pairwise=GCMP" "$N$T"
> + append network_data "group=GCMP" "$N$T"
> + ;;
> + esac
> +

how is this supposed to work and look like in uci? I couldn't find any
other references to `$wpa_cipher` in hostapd.sh

>   [ "$mode" = mesh ] || {
>   case "$wpa" in
>   1)
> 


~ Jo

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


Re: [OpenWrt-Devel] [PATCH v2] wireguard: skip peer config if public key of the peer is not defined

2020-01-16 Thread Jo-Philipp Wich
Hi,

> + if [ -z "$public_key" ]; then
> + echo "Skipping peer config $peer_config because public key is 
> not defined."
> + return 0
> + fi

I guess there will be other error conditions that could cause the wg
setup to fail... is there any more robust way to check the config for
validity? Could some `wg` sub command be used for that?

~ Jo



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] [PATCH v2] wireguard: fix interface remove for lonely peers

2020-01-16 Thread Jo-Philipp Wich
Hi,

I think this behavior is not really acceptable. Programs, init scripts,
hotplug events etc. should not automatically modify (and commit) uci
configurations, especially not such vital ones like the network config.

The main problem I see is that you do not know what state the config is
in at any point in time, whether there are other (intentionally!)
uncommitted user changes etc.

Wouldn't it be better to modify the code deleting the wireguard
interface to delete the peer sections as well? Or to remodel the
wireguard configuration model to cope with orphaned peer sections?


~ Jo



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] Merged: cryptodev-linux: remove DEFAULT redefinition

2020-01-15 Thread Jo-Philipp Wich
Merged into my staging tree at
http://git.openwrt.org/?p=openwrt/staging/jow.git.

Thank you!


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


Re: [OpenWrt-Devel] dev.archive.openwrt.org cert expired

2020-01-01 Thread Jo-Philipp Wich
Hi,

thanks. The cert was auto-renewed but the nginx reload failed due to
`service` not being in $PATH for cronjobs.

~ Jo



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] [PATCH 1/2] scripts/flashing: Switch from echo -en to printf

2020-01-01 Thread Jo-Philipp Wich
Hi.

$ patch -p1 < 1216552.patch
patching file scripts/flashing/flash.sh
Hunk #1 FAILED at 51.
1 out of 1 hunk FAILED -- saving rejects to file
scripts/flashing/flash.sh.rej

~ Jo



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] [PATCH] scripts/gen_image_generic.sh: Replace -o with ||

2020-01-01 Thread Jo-Philipp Wich
Hi,

> [...]
> +if [ ! $# -eq 5 ] || [ ! $# -eq 6 ]; then

why not simply "-ne" ?

~ Jo



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] Merged: scripts/gen-dependencies.sh: replacebackticks with $()

2020-01-01 Thread Jo-Philipp Wich
Merged into master at
http://git.openwrt.org/?p=openwrt/openwrt.git.

Thank you!


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


[OpenWrt-Devel] Merged: scripts/gen-dependencies.sh: use /bin/sh

2020-01-01 Thread Jo-Philipp Wich
Merged into master at
http://git.openwrt.org/?p=openwrt/openwrt.git.

Thank you!


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


[OpenWrt-Devel] Merged: libcxx: Build with the libsupc++ ABI

2020-01-01 Thread Jo-Philipp Wich
Merged into master at
http://git.openwrt.org/?p=openwrt/openwrt.git.

Thank you!


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


[OpenWrt-Devel] Merged: libcxx: Add size optimizations

2020-01-01 Thread Jo-Philipp Wich
Merged into master at
http://git.openwrt.org/?p=openwrt/openwrt.git.

Thank you!


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


[OpenWrt-Devel] Merged: openssl: update to version 1.0.2u

2020-01-01 Thread Jo-Philipp Wich
Merged into openwrt-18.06 at
http://git.openwrt.org/?p=openwrt/openwrt.git.

Thank you!


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


Re: [OpenWrt-Devel] [PATCH] busybox: Include hdparm by default on nas type device

2020-01-01 Thread Jo-Philipp Wich
Hi Linus,

can you move the condition before the sed program populating the initial
config? That should restore the ability for users to deselect busybox
hdparm (e.g. to replace it with something different).

~ Jo



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] Preserving configs over sysupgrade on ath79/tiny broken for some boards (on 19.07 and master), possible solutions

2019-12-30 Thread Jo-Philipp Wich
Hi,

given that (binary release) support for 4MB devices will end with 19.07,
I'd vote for reverting the 4K sector change in ath79 and stick with 64K
ones as common denominator across the entire target. That will be the
least invasive and most robust fix.

Regards,
Jo



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] [PATCH] zones: enforce forward policy with zone_NAME_src_POLICY

2019-12-13 Thread Jo-Philipp Wich
Hi,

per definition, zone forward policies were only ever meant to apply to
traffic between interfaces within the same zone *not* to traffic
anywhere else.

Your patch would break that assumption as far as I can see.

~ Jo



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] [RFC][PATCH] base-files: send informational UDP message each second waiting

2019-12-11 Thread Jo-Philipp Wich
Hi,

> Question is, if it's worth the hassle for a feature which is targeted more
> towards the expert users.

from my pov - it is not worth overengineering this feature. The proposed
patch is more than adequate. It increases the probability of the message
getting delivered without additional code complexity.

~ Jo

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


Re: [OpenWrt-Devel] The meaning of Signed-off-by for netifd [Was: Re: [PATCH netifd] interface: warn if ip6hint is truncated]

2019-12-04 Thread Jo-Philipp Wich
Hi,

> ok, so you claim my SoB means that *I* confirmed that my change is
> compatible to the netifd's license. I didn't do that though.

as it has been pointed out on this list, adding a S-o-b without consent
should not be done, so I reverted the offending commit.

Kind regards,
Jo



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] Kernel version for OpenWrt 20.X

2019-11-27 Thread Jo-Philipp Wich
Hi Hauke,

I agree with aiming for a kernel 5.4 based release in April.

If we decide to go this route, we should also set a fixed feature freeze date 
(maybe end of March?) on which we branch off and drop targets not ported by 
then.

~ Jo

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


Re: [OpenWrt-Devel] [PATCH] generic ar8xxx: increase VLAN table for AR83x7

2019-11-25 Thread Jo-Philipp Wich
Hi,

does it make sense to keep the vlan/vid indirection if we increase the
table size to 4096? A simple 1:1 mapping of the vid to the table index
would be simpler and more robust from the configuration pov.

~ Jo

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


[OpenWrt-Devel] [PATCH 16/17] ramips: disable WR512-3GN 4MB variant by default

2019-11-16 Thread Jo-Philipp Wich
Disable the WR512-3GN 4MB image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/rt305x.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index cb2fe628bc..9e599b4125 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -838,6 +838,7 @@ define Device/wr512-3gn-4M
   DTS := WR512-3GN-4M
   IMAGE_SIZE := $(ralink_default_fw_size_4M)
   DEVICE_TITLE := WR512-3GN (4M)
+  DEFAULT := n
 endef
 TARGET_DEVICES += wr512-3gn-4M
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 17/17] ramips: disable ZyXel Keenetic by default

2019-11-16 Thread Jo-Philipp Wich
Disable the ZyXel Keenetic images by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/rt305x.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index 9e599b4125..38fd1747a3 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -908,6 +908,7 @@ define Device/kn
   IMAGE_SIZE := $(ralink_default_fw_size_4M)
   DEVICE_TITLE := ZyXEL Keenetic
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ehci 
kmod-usb-ledtrig-usbport
+  DEFAULT := n
 endef
 TARGET_DEVICES += kn
 
@@ -915,6 +916,7 @@ define Device/zyxel_keenetic-start
   DTS := kn_st
   IMAGE_SIZE := $(ralink_default_fw_size_4M)
   DEVICE_TITLE := ZyXEL Keenetic Start
+  DEFAULT := n
 endef
 TARGET_DEVICES += zyxel_keenetic-start
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 14/17] ar71xx: disable TP-Link TL-WA855RE by default

2019-11-16 Thread Jo-Philipp Wich
Disable the TP-Link TL-WA855RE image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ar71xx/image/tiny-tp-link.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/image/tiny-tp-link.mk 
b/target/linux/ar71xx/image/tiny-tp-link.mk
index 8354823d3e..3a32452f95 100644
--- a/target/linux/ar71xx/image/tiny-tp-link.mk
+++ b/target/linux/ar71xx/image/tiny-tp-link.mk
@@ -264,6 +264,7 @@ define Device/tl-wa855re-v1
   TPLINK_HWREV := 0
   IMAGE_SIZE := 3648k
   MTDPARTS := 
spi0.0:128k(u-boot)ro,1344k(kernel),2304k(rootfs),256k(config)ro,64k(art)ro,3648k@0x2(firmware)
+  DEFAULT := n
 endef
 TARGET_DEVICES += tl-wa855re-v1
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 13/17] brcm47xx: disable Netgear WNR2000 v2 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the Netgear WNR2000 v2 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/brcm47xx/image/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/brcm47xx/image/Makefile 
b/target/linux/brcm47xx/image/Makefile
index c2bf9d41d5..969d523956 100644
--- a/target/linux/brcm47xx/image/Makefile
+++ b/target/linux/brcm47xx/image/Makefile
@@ -916,6 +916,7 @@ define Device/netgear-wnr2000v2
   $(Device/netgear)
   NETGEAR_BOARD_ID := U12H114T00_NETGEAR
   NETGEAR_REGION := 2
+  DEFAULT := n
 endef
 TARGET_DEVICES += netgear-wnr2000v2
 
@@ -925,6 +926,7 @@ define Device/netgear-wnr3500l-v1-na
   $(Device/netgear)
   NETGEAR_BOARD_ID := U12H136T99_NETGEAR
   NETGEAR_REGION := 2
+  DEFAULT := n
 endef
 TARGET_DEVICES += netgear-wnr3500l-v1-na
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 11/17] ramips: disable TP-Link TL-WA750RE by default

2019-11-16 Thread Jo-Philipp Wich
Disable the TP-Link TL-WA750RE image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/30
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ar71xx/image/tiny-tp-link.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/image/tiny-tp-link.mk 
b/target/linux/ar71xx/image/tiny-tp-link.mk
index 1c849cff32..8354823d3e 100644
--- a/target/linux/ar71xx/image/tiny-tp-link.mk
+++ b/target/linux/ar71xx/image/tiny-tp-link.mk
@@ -164,6 +164,7 @@ define Device/tl-wa750re-v1
   BOARDNAME := TL-WA750RE
   DEVICE_PROFILE := TLWA750
   TPLINK_HWID := 0x0751
+  DEFAULT := n
 endef
 TARGET_DEVICES += tl-wa750re-v1
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 10/17] ar71xx: disable TP-Link TL-WA850RE by default

2019-11-16 Thread Jo-Philipp Wich
Disable the TP-Link TL-WA850RE image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/30
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ar71xx/image/tiny-tp-link.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/image/tiny-tp-link.mk 
b/target/linux/ar71xx/image/tiny-tp-link.mk
index db5f735498..1c849cff32 100644
--- a/target/linux/ar71xx/image/tiny-tp-link.mk
+++ b/target/linux/ar71xx/image/tiny-tp-link.mk
@@ -272,6 +272,7 @@ define Device/tl-wa860re-v1
   BOARDNAME := TL-WA860RE
   DEVICE_PROFILE := TLWA860
   TPLINK_HWID := 0x0861
+  DEFAULT := n
 endef
 TARGET_DEVICES += tl-wa860re-v1
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 09/17] ramips: disable TP-Link TL-WR840N v5 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the TP-Link TL-WR840N v5 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/29
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/mt76x8.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/mt76x8.mk 
b/target/linux/ramips/image/mt76x8.mk
index 2280a1a618..054935e595 100644
--- a/target/linux/ramips/image/mt76x8.mk
+++ b/target/linux/ramips/image/mt76x8.mk
@@ -243,6 +243,7 @@ define Device/tl-wr840n-v5
   KERNEL_INITRAMFS := $(KERNEL_DTB) | tplink-v2-header -e
   IMAGE/sysupgrade.bin := tplink-v2-image -s -e | append-metadata | \
check-size (IMAGE_SIZE)
+  DEFAULT := n
 endef
 TARGET_DEVICES += tl-wr840n-v5
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 15/17] ramips: disable A5-V11 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the A5-V11 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/rt305x.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index de3d788563..cb2fe628bc 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -69,6 +69,7 @@ define Device/a5-v11
$$(sysupgrade_bin) | check-size (IMAGE_SIZE) | poray-header -B 
A5-V11 -F 4M
   DEVICE_TITLE := A5-V11
   DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2
+  DEFAULT := n
 endef
 TARGET_DEVICES += a5-v11
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 12/17] brcm47xx: disable Linksys E1000 v1 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the Linksys E1000 v1 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/brcm47xx/image/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/brcm47xx/image/Makefile 
b/target/linux/brcm47xx/image/Makefile
index 47f031b8b4..c2bf9d41d5 100644
--- a/target/linux/brcm47xx/image/Makefile
+++ b/target/linux/brcm47xx/image/Makefile
@@ -715,6 +715,7 @@ define Device/linksys-e1000
   $(Device/linksys)
   DEVICE_ID := E100
   VERSION := 1.1.3
+  DEFAULT := n
 endef
 TARGET_DEVICES += linksys-e1000
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 05/17] ar71xx: disable Netgear WNR2000v4 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the Netgear WNR2000v4 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/11
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ar71xx/image/tiny-legacy-devices.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/image/tiny-legacy-devices.mk 
b/target/linux/ar71xx/image/tiny-legacy-devices.mk
index 32912f79d6..4703e08541 100644
--- a/target/linux/ar71xx/image/tiny-legacy-devices.mk
+++ b/target/linux/ar71xx/image/tiny-legacy-devices.mk
@@ -105,6 +105,7 @@ LEGACY_DEVICES += WNR2000V3
 define LegacyDevice/WNR2000V4
   DEVICE_TITLE := NETGEAR WNR2000V4
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
+  DEFAULT := n
 endef
 LEGACY_DEVICES += WNR2000V4
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 03/17] ar71xx: disable TP-Link TL-WA850RE v2 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the TP-Link TL-WA850RE v2 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/9
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ar71xx/image/tiny-tp-link.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/image/tiny-tp-link.mk 
b/target/linux/ar71xx/image/tiny-tp-link.mk
index 5b0ab3e970..db5f735498 100644
--- a/target/linux/ar71xx/image/tiny-tp-link.mk
+++ b/target/linux/ar71xx/image/tiny-tp-link.mk
@@ -249,6 +249,7 @@ define Device/tl-wa850re-v2
   TPLINK_HWREV := 0
   IMAGE_SIZE := 3648k
   MTDPARTS := 
spi0.0:128k(u-boot)ro,1344k(kernel),2304k(rootfs),256k(config)ro,64k(art)ro,3648k@0x2(firmware)
+  DEFAULT := n
 endef
 TARGET_DEVICES += tl-wa850re-v2
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 07/17] ramips: disable D-Link DIR-645 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the D-Link DIR-645 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/23
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/rt3883.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/rt3883.mk 
b/target/linux/ramips/image/rt3883.mk
index 4844abd1b7..2892ed9844 100644
--- a/target/linux/ramips/image/rt3883.mk
+++ b/target/linux/ramips/image/rt3883.mk
@@ -38,6 +38,7 @@ define Device/dir-645
   SEAMA_SIGNATURE := wrgn39_dlob.hans_dir645
   DEVICE_TITLE := D-Link DIR-645
   DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 swconfig
+  DEFAULT := n
 endef
 TARGET_DEVICES += dir-645
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 06/17] ramips: disable D-Link DIR-300 B5/B6/B7 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the D-Link DIR-300 B5/B6/B7 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/18
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/rt305x.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index f2be88b73f..3e2977cb96 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -237,6 +237,7 @@ define Device/dir-300-b7
   BLOCKSIZE := 4k
   IMAGE_SIZE := $(ralink_default_fw_size_4M)
   DEVICE_TITLE := D-Link DIR-300 B7
+  DEFAULT := n
 endef
 TARGET_DEVICES += dir-300-b7
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 08/17] ramips: disable Sitecom WL-351 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the Sitecom WL-351 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/24
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/rt305x.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index 3e2977cb96..de3d788563 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -817,6 +817,7 @@ define Device/wl-351
   IMAGE_SIZE := $(ralink_default_fw_size_4M)
   DEVICE_TITLE := Sitecom WL-351 v1
   DEVICE_PACKAGES := kmod-switch-rtl8366rb kmod-swconfig swconfig
+  DEFAULT := n
 endef
 TARGET_DEVICES += wl-351
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 04/17] ar71xx: disable On Networks N150R by default

2019-11-16 Thread Jo-Philipp Wich
Disable the On Networks N150R image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/10
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ar71xx/image/tiny-legacy-devices.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/image/tiny-legacy-devices.mk 
b/target/linux/ar71xx/image/tiny-legacy-devices.mk
index 98d45557a6..32912f79d6 100644
--- a/target/linux/ar71xx/image/tiny-legacy-devices.mk
+++ b/target/linux/ar71xx/image/tiny-legacy-devices.mk
@@ -116,6 +116,7 @@ LEGACY_DEVICES += REALWNR612V2
 
 define LegacyDevice/N150R
   DEVICE_TITLE := On Networks N150
+  DEFAULT := n
 endef
 LEGACY_DEVICES += N150R
 
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 01/17] ramips: disable ASUS RT-N10+ B1 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the ASUS RT-N10+ B1 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/1
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ramips/image/rt305x.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index d74e196a8b..f2be88b73f 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -650,6 +650,7 @@ define Device/rt-n10-plus
   BLOCKSIZE := 64k
   IMAGE_SIZE := $(ralink_default_fw_size_4M)
   DEVICE_TITLE := Asus RT-N10+
+  DEFAULT := n
 endef
 TARGET_DEVICES += rt-n10-plus
 
-- 
2.20.1


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


[OpenWrt-Devel] [RFC PATCH 00/17] disable known broken device images for 19.07

2019-11-16 Thread Jo-Philipp Wich
This patch series is to be applied against openwrt-19.07 and disables
known broken devices that were unable to retain configuration according
to https://forum.openwrt.org/t/devices-too-big-to-save/18161 .

The actual number of broken device images is likely higher but I wanted
to be conservative here and only disable the ones explicitly reported.

Jo-Philipp Wich (17):
  ramips: disable ASUS RT-N10+ B1 by default
  ar71xx: disable Netgear WNR612 v2 by default
  ar71xx: disable TP-Link TL-WA850RE v2 by default
  ar71xx: disable On Networks N150R by default
  ar71xx: disable Netgear WNR2000v4 by default
  ramips: disable D-Link DIR-300 B5/B6/B7 by default
  ramips: disable D-Link DIR-645 by default
  ramips: disable Sitecom WL-351 by default
  ramips: disable TP-Link TL-WR840N v5 by default
  ar71xx: disable TP-Link TL-WA850RE by default
  ramips: disable TP-Link TL-WA750RE by default
  brcm47xx: disable Linksys E1000 v1 by default
  brcm47xx: disable Netgear WNR2000 v2 by default
  ar71xx: disable TP-Link TL-WA855RE by default
  ramips: disable A5-V11 by default
  ramips: disable WR512-3GN 4MB variant by default
  ramips: disable ZyXel Keenetic by default

 target/linux/ar71xx/image/tiny-legacy-devices.mk | 3 +++
 target/linux/ar71xx/image/tiny-tp-link.mk| 4 
 target/linux/brcm47xx/image/Makefile | 3 +++
 target/linux/ramips/image/mt76x8.mk  | 1 +
 target/linux/ramips/image/rt305x.mk  | 7 +++
 target/linux/ramips/image/rt3883.mk  | 1 +
 6 files changed, 19 insertions(+)

-- 
2.20.1


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


[OpenWrt-Devel] [PATCH 02/17] ar71xx: disable Netgear WNR612 v2 by default

2019-11-16 Thread Jo-Philipp Wich
Disable the Netgear WNR612 v2 image by default as the device has
insufficient flash space for release build images.

Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/4
Signed-off-by: Jo-Philipp Wich 
---
 target/linux/ar71xx/image/tiny-legacy-devices.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ar71xx/image/tiny-legacy-devices.mk 
b/target/linux/ar71xx/image/tiny-legacy-devices.mk
index bcf77de443..98d45557a6 100644
--- a/target/linux/ar71xx/image/tiny-legacy-devices.mk
+++ b/target/linux/ar71xx/image/tiny-legacy-devices.mk
@@ -110,6 +110,7 @@ LEGACY_DEVICES += WNR2000V4
 
 define LegacyDevice/REALWNR612V2
   DEVICE_TITLE := NETGEAR WNR612V2
+  DEFAULT := n
 endef
 LEGACY_DEVICES += REALWNR612V2
 
-- 
2.20.1


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


[OpenWrt-Devel] OpenWrt 19.07.0 first release candidate

2019-11-08 Thread Jo-Philipp Wich
Hi,

The OpenWrt community is proud to announce the first release candidate
of the upcoming OpenWrt 19.07 stable version series. It incorporates
over 3700 commits since branching the previous OpenWrt 18.06 release and
has been under  development for about one a half year.

With this release the OpenWrt project brings all supported targets back
to a single common kernel version and to further refines and broadens
existing device support. It also provides initial support for the new
ath79 target, the future device tree based successor of the popular
ar71xx target.

---

Some selected highlights this release since the previous OpenWrt 18.06
version are:

  * Updated toolchain:
* musl libc 1.1.24
* uClibc-ng 1.0.31
* glibc 2.27
* gcc 7.4.0
* binutils 2.31.1
  * Updated Linux kernel
* 4.14.151 for all targets
* Flow offloading bugfixes
  * Network userland:
* Fixes in network and wireless configuration handling
* Bugfixes in DHCPv6 client and server
* WPA3 configuration support
  * System userland:
* Sysupgrade support for backup and upgrade capability checks
* Bugfixes in the process manager, system message bus, embedded web
  server  and the configuration management library
  * Platform and Driver Support
* Dropped adm5120, adm8668, ar7, au1000, ixp4xx, mcs814x, omap24xx,
  ppc40x, ppc44x and xburst targets
* Updates and new device support across all targets
  * Web interface:
* Client side rendering of views for improved performance
* Security fixes

For a detailed list of changes since branching of the 18.06 release
series, see https://openwrt.org/releases/19.07/changelog-19.07.0

---

Known issues:

  * Sysupgrade from ar71xx to ath79 and vice versa is not officially
supported, a full manual reinstall is recommended to switch targets
for devices supported by both ar71xx and ath79
  * Images for some device became too big to support a persistent
overlay, causing such models to lose configuration after a reboot.
If you  experience this problem, please report the affected device
and consider downgrading to OpenWrt 18.06 or using the Image Builder
to pack a smaller custom image
  * Some optional GUI packages crash with an error about missing
"cbi.lua", install the "luci-compat"  package to fix these
  * Any outstanding issues reported at https://bugs.openwrt.org/

---

For latest information about the 19.07 series, refer to the wiki at:
https://openwrt.org/releases/19.07/

To download the v19.07.0-rc1 images, navigate to:
https://downloads.openwrt.org/releases/19.07.0-rc1/

---

As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.

Have fun!

The OpenWrt Community



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] [19.07] cherry-pick ipqx0xx-generic profile

2019-11-03 Thread Jo-Philipp Wich
Hi Sven,

done.

~ Jo



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] uhttpd/luci/rpcd is broken?

2019-11-02 Thread Jo-Philipp Wich
Hi,

thanks for checking.

Can you please pm me your /tmp/dhcp.leases, /tmp/hosts/odhcpd and 
/etc/config/dhcp?

Thanks!

~ Jo

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


Re: [OpenWrt-Devel] uhttpd/luci/rpcd is broken?

2019-11-02 Thread Jo-Philipp Wich
Hi,

please try to find out which procedure is crashing rpcd by testing the
following commands:

- ubus call luci-rpc getNetworkDevices
- ubus call luci-rpc getWirelessDevices
- ubus call luci-rpc getHostHints
- ubus call luci-rpc getBoardJSON
- ubus call luci-rpc getDSLStatus
- ubus call luci-rpc getDHCPLeases

The one that hangs/times out is the culprit.

~ Jo

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


Re: [OpenWrt-Devel] [PATCH] rules.mk: remove "$(STAGING_DIR)/include"

2019-11-01 Thread Jo-Philipp Wich
Hi,

[...]

> Removing this directory from TARGET_CPPFLAGS will cut down the log noise
> a bit. Not only will CPPFLAGS be shorter, there will be less warnings
> set off by "-Wmissing-include-dirs" (or even failures when paired with
> "-Werror"). After all the directory does not even _exist_ in the SDKs,
> which are used on the build bots when building packages (see [1] and
> [2]).

[...]

> Signed-off-by: Sebastian Kemper 

Acked-by: Jo-Philipp Wich 


I wanted to look into this for a long time but never had the motivation
to actually do comprehensive tests of the impacts of the removal.

So, thanks for looking into that - its fine from my side.

~ Jo



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] [PATCH rpcd v2 0/6] memory issue fixes

2019-10-29 Thread Jo-Philipp Wich
Hi Yousong,

thank you for the series. I applied it with slight whitespace changes
after some valgrind testing on-target.

~ Jo



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] [PATCH] rpcd: uci: fix segfault and double free on set method

2019-10-29 Thread Jo-Philipp Wich
Hi Daniel, Yousong,

thanks for the reporting issue and the proposed patch. I'd prefer to go
with a minimal variant which merely zeroes the flags to avoid touching
too much code.

Imho the current uci_set() behavior of freeing uci_ptr members without
zeroing them is a bug that should be corrected as well.

~ Jo



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] How to trigger wifi reload from wifi.lua

2019-10-24 Thread Jo-Philipp Wich
Hi,

> On the Luci GUI, the current behaviour of Save of changes to the
> items in wifi.lua and wireless_modefreq.htm is to invoke a network
> restart. I would like to to change this behavior to invoke wifi restart
> directly from wifi.lua.

This is not supported and will confuse the netifd wireless state
tracking. You should instead extend the netifd wireless handlers to
properly deal with updated values.


~ Jo

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


Re: [OpenWrt-Devel] How to add items to Luci wireless_modefreq template

2019-10-24 Thread Jo-Philipp Wich
Hi,

you need to extend the netifd wireless handler to recognize your
proprietary options.

LuCI does not perform any wireless or network restarting by itself, it
relies on netifd doing the reloading of changed values.

If you introduce new options not yet known to netifd, it will do nothing
when you set these values.

~ Jo

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


Re: [OpenWrt-Devel] Hang on setting $PROMPT in master

2019-10-21 Thread Jo-Philipp Wich
Hi,

might be related to this:
http://lists.busybox.net/pipermail/busybox/2019-October/087535.html

Regards,
Jo

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


Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?

2019-10-18 Thread Jo-Philipp Wich
Hi,

thanks Bjørn - this looks similar to a fix I had in mind. I'll give it
some more thorough tries later.

~ Jo

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


Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?

2019-10-17 Thread Jo-Philipp Wich
Hi,

further blockers:

* opkg, under some circumstances fails to install
  local packages:

root@mir3g:~# opkg install ./rpcd_2019-09-01-821045f6-3_x86_64.ipk
Installing rpcd (2019-09-21-95f0973c-1) to root...
Collected errors:
 * opkg_download_pkg: Package rpcd is not available from any configured src.
 * opkg_install_pkg: Failed to download rpcd. Perhaps you need to run
'opkg update'?
 * opkg_install_cmd: Cannot install package rpcd.
root@mir3g:~#

* sysupgrade on ath79 is broken since the test image
  procedure modifies the image:

root@gateway:/tmp# cp
openwrt-ath79-generic-tplink_archer-c7-v5-squashfs-sysupgrade.bin meh.bin

root@gateway:/tmp# ubus call system validate_firmware_image
'{"path":"/tmp/meh.bin"}'
{
"tests": {
"fwtool_signature": true,
"fwtool_device_match": true
},
"valid": true,
"forceable": true,
"allow_backup": true
}

root@gateway:/tmp# ubus call system validate_firmware_image
'{"path":"/tmp/meh.bin"}'
{
"tests": {
"fwtool_signature": true,
"fwtool_device_match": false
},
"valid": false,
"forceable": true,
"allow_backup": true
}

* rpcd leaks memory

~ Jo



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] OpenWrt 19.07 release schedule ?

2019-10-16 Thread Jo-Philipp Wich
Hi,

> Silly question, does 18.6 have the same issue or is this a regression in 
> relation to 18.6?

I believe it is a regression but I am not 100% sure yet.

~ Jo



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] OpenWrt 19.07 release schedule ?

2019-10-16 Thread Jo-Philipp Wich
Hi,

> Does it impact OpenWrt ? or just some OpenWrt based distributions ?
> (might influence who need to fix this ;) )

it impacts the usage of the kmod compatibility repositories - apparently
they're completely ignored by opkg.

This problem was reported in the forum by a user who was unable to
install openvpn-openssl on a 19.07 snapshot, due to the dependency on
kmod-tun.

I was able to confirm the problem locally here as well.
While this might not strictly affect tagged builds, I still wouldn't
like to ship 19.07 with a known broken version of opkg.

~ Jo



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] OpenWrt 19.07 release schedule ?

2019-10-16 Thread Jo-Philipp Wich
Hi,

another blocker:

opkg fails to select the correct provider package in case multiple
repositories provide the same kmod with different versions and only one
of the provider satisfied version dependency constraints.

Someone needs to debug and fix this.

~ Jo



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] OpenWrt 19.07 release schedule ?

2019-10-11 Thread Jo-Philipp Wich
Hi Bjørn,

> Or: Start discussing the release blockers here and now.  Thanks.

1) Blocker: LuCI master needs to be backported to 19.07
   Time estimate: 2-3 weeks

2) Blocker: All relevant sub-components for WPA-3 + GUI support, such as
   hostapd, iwinfo etc. need to be backported to 19.07
   Time estimate: 2 weeks

3) Blocker: Some weaknesses in libustream-ssl client certificate
   handling need to  be addressed, which can only be solved by an API
   redesign. Band-aid fixes available but not merged, nobody worked
   on API redesign yet
   Time estimate: 1 week

4) Blocker: Need to assert the state of the Dragonblood WPA3
   vulnerabilities in 19.07's hostapd
   Time estimate: a few days I guess

~ Jo

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


Re: [OpenWrt-Devel] [PATCH] libnl-tiny: move source code into separate Git repository

2019-10-07 Thread Jo-Philipp Wich
Hi,

On 10/7/19 4:28 PM, Petr Štetiar wrote:
> In order to make the source code usable and testable separately out of
> buildroot.
> 
> Signed-off-by: Petr Štetiar 

Acked-by: Jo-Philipp Wich 




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] rpcd: file: add path based read/write/exec ACL checks

2019-09-22 Thread Jo-Philipp Wich
Hi,

> What do I have to do to enable access again, without calling ubus
> session grant like in the commit? Thank you!

you need to add the following sections:

"superuser": {
...
"read": {
"file": {
"/": [ "stat", "read" ],
"/*": [ "stat", "read" ]
}
},
"write": {
"file": {
"/": [ "write" ],
"/*": [ "write", "exec" ]
}
}
}

Depending on your use case, you might not need the "write" and "exec"
permissions at all.

The "exec" entry will allow invoking commands matching the path "/*"
(so, everything) and the "write" permission will allow (over)writing and
removing files matching the wildcard path.

Regards,
Jo



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] OpenWrt 19.07 release schedule ?

2019-09-04 Thread Jo-Philipp Wich
Hi,

> Buildbot is already crunching the images and packages, and pretty much
> all targets are green. So there are no obvious build related issues
> preventing the release. I have also not noticed any franctic discussion
> about specific major bugs blocking the release, so it looks pretty good
> at the moment.

there are various LuCI bugs which need to be addressed first.

> Has the actual release timetable been discussed? When could we expect
> first official release builds?

Afair there's been no recent discussions.

> I think that it would be good to get the initial .0 done, so that the
> wider user base could sysupgrade from 18.06 to 19.07 and the testing by
> the larger user base could start.

I'll try to allocate some time during the next week to produce tagged
builds.


~ Jo

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


[OpenWrt-Devel] Merged: bzip2: Fix CVE-2019-12900

2019-09-03 Thread Jo-Philipp Wich
Merged into openwrt-18.06.
Thank you!


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


[OpenWrt-Devel] Merged: phase1: run prepare instead of diffconfig

2019-09-03 Thread Jo-Philipp Wich
Merged into buildbot.git, branch master.
Thank you!


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


[OpenWrt-Devel] Merged: upslug2: Update to git repository

2019-09-03 Thread Jo-Philipp Wich
Merged into master.
Thank you!


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


[OpenWrt-Devel] Merged: firewall3: Fix some format string problems

2019-09-03 Thread Jo-Philipp Wich
Merged into project/firewall3.git, branch master.
Thank you!


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


[OpenWrt-Devel] Merged: rpcd: Switch to nanosleep

2019-09-03 Thread Jo-Philipp Wich
Merged into project/rpcd.git, branch master.
Thank you!


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


[OpenWrt-Devel] Merged: libblkid-tiny: addsblkid_probe_set_utf8label support

2019-09-03 Thread Jo-Philipp Wich
Merged into project/fstools.git, branch master.
Thank you!


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


[OpenWrt-Devel] Merged: libblkid-tiny: useblkid_probe_set_utf8label for label set

2019-09-03 Thread Jo-Philipp Wich
Merged into project/fstools.git, branch master.
Thank you!


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


Re: [OpenWrt-Devel] [PATCH procd] system: reject sysupgrade of broken firmware images

2019-08-30 Thread Jo-Philipp Wich
Hi,

> [snip]
> + blobmsg_parse(validation_policy, __VALIDATION_MAX, validation, 
> blob_data(b.head), blob_len(b.head));
> +
> + valid = validation[VALIDATION_VALID] && 
> blobmsg_get_bool(validation[VALIDATION_VALID]);
> + forceable = validation[VALIDATION_FORCEABLE] && 
> blobmsg_get_bool(validation[VALIDATION_FORCEABLE]);
> +
> + if (!valid && !forceable) {
> + fprintf(stderr, "Firmware image is broken and cannot be 
> installed\n");
> + return UBUS_STATUS_UNKNOWN_ERROR;

Maybe UBUS_STATUS_NOT_SUPPORTED could make sense here.

> + }
> +
>   sysupgrade_exec_upgraded(blobmsg_get_string(tb[SYSUPGRADE_PREFIX]),
>blobmsg_get_string(tb[SYSUPGRADE_PATH]),
>tb[SYSUPGRADE_COMMAND] ? 
> blobmsg_get_string(tb[SYSUPGRADE_COMMAND]) : NULL,
> 



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] [PATCH procd] system: support passing "options" to the "sysupgrade" ubus method

2019-08-17 Thread Jo-Philipp Wich
Hi,

> [...]
> +
> + blobmsg_for_each_attr(option, options, rem) {
> + const char *prefix = "UPGRADE_OPT_";
> + char *name = malloc(strlen(prefix) + 
> strlen(blobmsg_name(option)));
> + char value[11];
> + char *c;
> + int tmp;
> +
> + if (!name) {
> + continue;
> + }
> + sprintf(name, "%s%s", prefix, blobmsg_name(option));
> + for (c = name + strlen(prefix); *c; c++) {

I'd propose some more sanity checking here:
 if (isalnum(*c) || *c == '_') {
> + *c = toupper(*c);

 }
 else {
c = NULL;
break;
 }
> + }

if (!c) {
 fprintf(stderr, "Option \"%s\" contains invalid
characters\n", blobmsg_name(option));
 free(name);
 continue;
}

> +
> + switch (blobmsg_type(option)) {
> + case BLOBMSG_TYPE_INT32:
> + tmp = blobmsg_get_u32(option);
> + break;
> + case BLOBMSG_TYPE_INT16:
> + tmp = blobmsg_get_u16(option);
> + break;
> + case BLOBMSG_TYPE_INT8:
> + tmp = blobmsg_get_u8(option);
> + break;
> + default:
> + fprintf(stderr, "Option \"%s\" has unsupported type: 
> %d\n",
> + blobmsg_name(option), blobmsg_type(option));
> + free(name);
> + continue;
> + }
> + snprintf(value, sizeof(value), "%u", tmp);
> +
> + setenv(name, value, 1);
> +
> + free(name);
> + }
> +
>   execvp(argv[0], argv);
>  
>   /* Cleanup on failure */
> diff --git a/sysupgrade.h b/sysupgrade.h
> index 8c09fc9..c84e494 100644
> --- a/sysupgrade.h
> +++ b/sysupgrade.h
> @@ -14,8 +14,10 @@
>  #ifndef __PROCD_SYSUPGRADE_H
>  #define __PROCD_SYSUPGRADE_H
>  
> +struct blob_attr;
>  
> -void sysupgrade_exec_upgraded(const char *prefix, char *path, char *command);
> +void sysupgrade_exec_upgraded(const char *prefix, char *path, char *command,
> +   struct blob_attr *options);
>  
>  
>  #endif
> 



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] [PATCH] ubox: Run init script through shellcheck

2019-07-24 Thread Jo-Philipp Wich
Hi,

I suppose this has no been runtime tested since `$(${PIDCOUNT} + 1)`
will attempt to execute `${PIDCOUNT}` as command in a subshell with '+'
and '1' passed as arguments to it:

  root@OpenWrt:~# PIDCOUNT=1; PIDCOUNT="$(${PIDCOUNT} + 1)"; echo
"$PIDCOUNT"
  -ash: 1: not found

I think the proper fix should be something like:

  PIDCOUNT=$((PIDCOUNT + 1))

or even:

  local pid_file="/var/run/logread.$((++PIDCOUNT)).pid"

... without an explicit separate assignment.

~ Jo



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] Problem with "base" release repositories

2019-06-25 Thread Jo-Philipp Wich
Hi,

the base repositories have been fully restored and should be safe to use
again.

Once again, please excuse any inconvenience caused.

Will follow up with some more post mortem details later today.

~ Jo



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] Problem with "base" release repositories

2019-06-25 Thread Jo-Philipp Wich
Hi,

another update.

I applied local workarounds to the phase2 builders to simply append the
proper branch specification where missing in order to avoid the need to
rebuild all SDKs first which will save some time.

Additionally I diverted all free resources to the builder so that all
targets should be built after at most two cycles.

I'll start to re-enable repaired repositories at tomorrow (Wed, 26th) at
around 04:00 UTC.

You can follow the build process at

http://release-builds.lede-project.org/18.06/packages/waterfall (the
purple exceptions are harmless in this case)


To make matters worse, we've noticed some network throughput troubles at
the OSUOSL gccfarm so there's still some chance that rsync uploads could
timeout but I hope things will work out...


~ Jo



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] Problem with "base" release repositories

2019-06-25 Thread Jo-Philipp Wich
Hi,

some updates.

I managed to track down the root cause to some bad interaction between
buildbot and Git.

When buildbot tries to switch an already cloned repo back from a
previously checked out tag to a branch, it performs this series of commands:

git clean -f -d -x
git fetch -t https://git.openwrt.org/openwrt/openwrt.git $BRANCHNAME
git reset --hard $SHA1
git branch -M $BRANCHNAME

The last command currently fails with:

error: refname refs/heads/HEAD not found
fatal: Branch rename failed

... leaving the Git tree in detached HEAD state neither pointing to a
proper tag, nor a proper branch.

Eventually, during the SDK build, buildroot will call "git rev-parse
--abbrev-ref HEAD" to determine the current branch name which will
simply return "HEAD" in detached head state, which is then subsequently
filtered away, leading to a branchless base URL getting emitted in the
SDKs which ultimately leads to the broken base repos getting built.


It appears that an unconditional "git checkout master" before buildbot's
native Git clone/pull magic will solve the issue for now, I am going to
implement this workaround now and see if the situation improves.

I'll also add further checks to abort future builds early in case the
problem ever resurfaces.

~ Jo



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] Problem with "base" release repositories

2019-06-25 Thread Jo-Philipp Wich
Hi all,

unfortunately there appears to be an issue with the build cluster which
causes it to produce slightly broken SDKs with a wrong embedded package
feeds configuration.

Due to yet unknown issues in the buildroot (or the build setup itself),
the target/sdk Make target fails to identify the current Git branch,
causing it to emit feeds.conf.default files with

src-git base https://git.openwrt.org/openwrt/openwrt.git

instead of the expected

src-git base https://git.openwrt.org/openwrt/openwrt.git;openwrt-18.06


As a consequence, bad base packages from the master branch have been
built and uploaded to the release repositories.

To limit the amount of further damage, I have taken down the broken
"base" repositories now and will investigate the size of the problem and
potential root causes.

This process will unfortunately also delay 18.06.3 and 17.07.7 releases
until further notice.


Will follow up with further information as it becomes available.

I am very sorry for the inconvenience.


~ Jo



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] block bugged

2019-06-20 Thread Jo-Philipp Wich
Hi,

make dirclean will fix it.

~ Jo



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] LEDE 17.01.7 and OpenWrt 18.06.3 deadline on Friday

2019-06-20 Thread Jo-Philipp Wich
Hi,

please merge any outstanding changes that should be
part of LEDE 17.07.7 and OpenWrt 18.06.3 into the
respective lede-17.01 and openwrt-18.06 branches until
Friday, the 21st of June at 09:00 UTC.

I will tag these branches then and start building
corresponding binary releases shortly after.

The v17.01.7 release will also mark the end-of-life of
the LEDE 17.01 series - we'll decommission the LEDE
17.01 related build resources and repurpose them for
producing 19.07 binaries.

Regards,
Jo



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] [PATCH v2 opkg] alternatives: special-case busybox as alternatives provider

2019-06-13 Thread Jo-Philipp Wich
Hi Yousong,

> From: Yousong Zhou 
> 
> Almost all busybox applets are alternatives to some other existing
> "full" utilities.  To lift the maintenance burden of enumerating CONFIG
> symbols, symlink path of each applet, we special case busybox here as a
> known alternatives provider.
> 
> All file pathes provided by busybox will serve as fallback alternatives
> with -inf priority.  Packages intending to switch to using alternatives
> mechanism will also not need to depend on the same kind of change be
> applied on busybox in base system
> 
> Signed-off-by: Yousong Zhou 

Acked-by: Jo-Philipp Wich 



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] [PATCH opkg] alternatives: special-case busybox as alternatives provider

2019-06-13 Thread Jo-Philipp Wich
Hi,

ACK on the patch. I was thinking about whether it makes sense to move out
the hardcoded package "busybox" -> "/bin/busybox" path facts into some kind
of external pkgname => multicall-executable-path mapping configuration but
there's probably not that many other relevant packages where this would apply.

Still I'd like to see the code somewhat generalized... rename the
"pkg_alternatives_check_busybox()" procedure to something like 
"pkg_alternatives_find_fallback()" and have it iterate an array of
"struct { char *pkgname; char *multicallpath; }" which may initially contain
just { { "busybox", "/bin/busybox" }, }.


Regards,
Jo



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] [firewall3] utils: coverity resource leak warning

2019-06-12 Thread Jo-Philipp Wich
Hi Kevin,

ACK. Feel free to push.

~ Jo

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


Re: [OpenWrt-Devel] lua bug introduction

2019-06-05 Thread Jo-Philipp Wich
Hi,

> Does it zero out itself or when using LuCI? The commit above will
> touch rc.local when LuCI is not used.

This should have been: "will *not* touch rc.local when LuCI is not used"

~ Jo



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] lua bug introduction

2019-06-05 Thread Jo-Philipp Wich
Hi,

> Something has started zeroing out /etc/rc.local contents, maybe:
> 
> https://git.openwrt.org/?p=project/luci.git;a=commit;h=1c09ee5e42550d6339bffa58d4cba3461948e19c

Does it zero out itself or when using LuCI? The commit above will
touch rc.local when LuCI is not used.

~ Jo



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] [PATCH 2/2] script/feeds: add a new command that allows generating a new feeds.conf

2019-06-04 Thread Jo-Philipp Wich
Hi,

comments inline.

On 6/4/19 7:55 AM, John Crispin wrote:
> This can be used inside build setups for easy feeds.conf generation.
> 
> Signed-off-by: John Crispin 
> ---
>  scripts/feeds | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/scripts/feeds b/scripts/feeds
> index 304ef6cbaf..6f8c7be31d 100755
> --- a/scripts/feeds
> +++ b/scripts/feeds
> @@ -7,6 +7,7 @@ use metadata;
>  use warnings;
>  use strict;
>  use Cwd 'abs_path';
> +use File::Copy

Missing semicolon.

>  
>  chdir "$FindBin::Bin/..";
>  $ENV{TOPDIR} //= getcwd();
> @@ -819,6 +820,37 @@ sub update {
>   return $failed;
>  }
>  
> +sub setup {
> + my %opts;
> +
> + getopts('bh', \%opts);
> +
> + if ($opts{h}) {
> + usage();
> + return 0;
> + }
> +
> + if ($opts{b}) {
> + copy("feeds.conf.default", "feeds.conf") or die "Copy failed: 
> $!"
> + } else {
> + unlink "feeds.conf"
> + }
> +
> + open(my $fd, ">>feeds.conf");
> + while (my $entry = shift @ARGV) {
> + my ($type, $name, $src) = split /,/, $entry;

I think it would make sense to check $name and $src to not contain whitespace 
here,
for example like this:

if ($name =~ /\s/ || $src =~ /\s/) {
warn "Feed names or sources may not contain whitespace characters in 
parameter $entry\n";
unlink "feeds.conf";
return 1;
}

> +
> + $update_method{$type} or do {
> + warn "Unknown type '$type' in parameter $entry\n";
> + unlink "feeds.conf";
> + return 1;
> + };
> + printf $fd "%s %s %s\n", $type, $name, $src;
> + }
> +
> + return 0;
> +}
> +
>  sub feed_config() {
>   foreach my $feed (@feeds) {
>   my $installed = (-f "feeds/$feed->[1].index");
> @@ -870,6 +902,10 @@ Commands:
>   -i :   Recreate the index only. No feed update from 
> repository is performed.
>   -f :   Force updating feeds even if there are changed, 
> uncommitted files.
>  
> + setup [options]   ...: generate 
> feeds.conf
> + Options:
> + -b :   Use feeds.conf.default as base for new feeds.conf.
> +
>   clean: Remove downloaded/generated files.
>  
>  EOF
> @@ -883,6 +919,7 @@ my %commands = (
>   'search' => \,
>   'uninstall' => \,
>   'feed_config' => \_config,
> + 'setup' => \,
>   'clean' => sub {
>   system("rm -rf ./feeds ./package/feeds");
>   }
> 



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] [PATCH 1/2] image: make the folder that gets included intot he RootFS configurable

2019-06-04 Thread Jo-Philipp Wich
Hi,

comments inline.

~ Jo

On 6/4/19 7:55 AM, John Crispin wrote:
> This allows managing several different folder for varying env profiles.
> 
> Signed-off-by: John Crispin 
> ---
>  config/Config-images.in | 6 ++
>  package/Makefile| 2 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/config/Config-images.in b/config/Config-images.in
> index 8548c7cd24..a618da1b6c 100644
> --- a/config/Config-images.in
> +++ b/config/Config-images.in
> @@ -286,4 +286,10 @@ menu "Target Images"
> it will be mounted by PARTUUID which makes the kernel find the
> appropriate disk automatically.
>  
> + config TARGET_ROOTFS_INCLUDE_FOLDER
> + string "RootFS include folder"
> + default "files"
> + help
> +   Override the folder that is included into the RootFS by 
> default.
> +
>  endmenu
> diff --git a/package/Makefile b/package/Makefile
> index abbf5f91f2..054e5b5820 100644
> --- a/package/Makefile
> +++ b/package/Makefile
> @@ -76,7 +76,7 @@ $(curdir)/install: $(TMP_DIR)/.build $(curdir)/merge $(if 
> $(CONFIG_TARGET_PER_DE
>  
>   $(CP) $(TARGET_DIR) $(TARGET_DIR_ORIG)
>  
> - $(call prepare_rootfs,$(TARGET_DIR),$(TOPDIR)/files)
> + $(call prepare_rootfs,$(TARGET_DIR),$(TOPDIR)/$(if ifeq 
> "$(CONFIG_TARGET_ROOTFS_INCLUDE_FOLDER)" 
> "",files,$(CONFIG_TARGET_ROOTFS_INCLUDE_FOLDER)))

I don't think that $(if ifeq ...) is a valid Make construct, to me it looks
as if it'll simply always evaluate to $(CONFIG_TARGET_ROOTFS_INCLUDE_FOLDER).
Also don't we need to filter this through the "qstrip" macro? The .config
symbol will contain leading and trailing quotes for string value options.

>  
>  $(curdir)/index: FORCE
>   @echo Generating package index...
> 



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] [PATCH][RFC] opkg: add License to info command

2019-05-13 Thread Jo-Philipp Wich
Hi,

please make sure that the license info is only parsed when it is required by
the toplevel command being executed, look at the other usages of the PFM_*
macros in the source.

Without this, the in-memory representation of the package trees will consume
way more RAM due to the redundant license string copies held by each abstract
package node.

~ Jo



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] [PATCH] procd: add procd_running() helper for checking running state

2019-05-01 Thread Jo-Philipp Wich
Hi,

comment inline below.

> From: Rafał Miłecki 
> 
> This should be helpful for implementing service_running() in procd init
> scripts.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  package/system/procd/files/procd.sh | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/package/system/procd/files/procd.sh 
> b/package/system/procd/files/procd.sh
> index 72f25fe0c0..ade55a344f 100644
> --- a/package/system/procd/files/procd.sh
> +++ b/package/system/procd/files/procd.sh
> @@ -26,6 +26,9 @@
>  # procd_close_instance():
>  #   Complete the instance being prepared
>  #
> +# procd_running(service, [instance]):
> +#   Checks if service/instance is currently running
> +#
>  # procd_kill(service, [instance]):
>  #   Kill a service instance (or all instances)
>  #
> @@ -398,6 +401,18 @@ _procd_add_instance() {
>   _procd_close_instance
>  }
>  
> +procd_running() {
> + local service="$1"
> + local instance="${2:-instance1}"
> + local running
> +
> + json_init
> + json_add_string name "$service"
> + running=$(_procd_ubus_call list | jsonfilter -e 
> "@.$service.instances.${instance}.running")

Pass '{ "name": "'"$service"'" }' as argument to the list call to reduce the 
amount of output you
need to filter.

> +
> + [ "$running" = "true" ]
> +}
> +
>  _procd_kill() {
>   local service="$1"
>   local instance="$2"
> 


~ Jo



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] Backport request

2019-04-23 Thread Jo-Philipp Wich
Hi Rosen,

> There are two patches in master that fix long range build failures:
> 
> https://github.com/openwrt/openwrt/commit/042d68a19593ac796098845366a235f5465816da#diff-41aaa89c68b8575d420435d3e892f369
> https://github.com/openwrt/packages/commit/5c823596dd4f51969425b7a39f9b3c2730aa4e72
> 
> Can these be backported to 18.06?

Backported, thanks.

~ Jo



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] SDK enhancement proposal - add external toolchains via feeds

2019-04-23 Thread Jo-Philipp Wich
Hello Mirko,

> Problem statement
> 
> To support new chipsets, it is sometimes necessary to work with
> vendor-specific toolchains. Until now, the process to add these
> toolchains to the build environment is a manual one. This leads
> companies to create their own automation scripts, creating a parallel SDK. 

can you elaborate a little bit on this manual process? I assume the
mentioned companies already utilize the CONFIG_EXTERNAL_TOOLCHAIN
feature in menuconfig but you intend to steamline the process of setting
related configuration symbols such as CONFIG_TARGET_NAME,
CONFIG_TOOLCHAIN_ROOT, CONFIG_TOOLCHAIN_BIN_PATH etc.?

> Proposed solution
> 
> We propose to extend the build system to enable the addition of external
> toolchains via feeds.

Do you intend to host the actual toolchain executables in such a feed or
just a set of configuration manifests to tie already installed host
toolchains into the buildroot?

Either variant does not align well with the existing feed concept which
basically represents a collection of build recipes organized in a directory.

The toolchain "repository" suggestion aims more into the direction of
buildroot configuration management so /maybe/ something interacting with
scripts/env to prime .config values with appropriate per-toolchain
settings would be a way forward, but first we need to better understand
the requirements.

> Benefit
> 
> This would remove the need for anyone to perform any manual steps or
> maintain their own script. Enabling their addition through feeds would
> streamline the way these toolchains are to be added and make removing
> them later in the development cycle almost transparent and therefore a
> lot less difficult.

Would it be possible for you to provide a more detailed description
regarding the typical manual steps required to hook an external
toolchain into OpenWrt? Are all require modifications strictly .config
changes or are modifications to Makefiles, scripts etc. required?

> Implementation proposal 
> 
> We propose to extend the scripts/feeds script and other parts of the
> build system to detect external toolchains in feeds and adds them
> accordingly.

As written above, the feeds infrastructure might not the place where the
feature should end up, but let us better understand the requirements first.

> Next steps
> 
> If there is support for the idea by the community, member companies of
> prpl start development and will propose a series of patches to this
> mailing list.

Sounds good to me.


Regards,
Jo

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


Re: [OpenWrt-Devel] [PATCH 2/2 netifd] proto-shell: return error in case setup fails

2019-04-01 Thread Jo-Philipp Wich
Hi,

minor nitpick below

On 4/1/19 10:34 AM, Hans Dedecker wrote:
> In case PROTO_CMD_SETUP cannot be handled due to an invalid state; return
> -1 so the calling functions are aware the PROTO_CMD_SETUP has failed.
> 
> Signed-off-by: Hans Dedecker 
> ---
>  proto-shell.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/proto-shell.c b/proto-shell.c
> index 9653f4c..fd9cad4 100644
> --- a/proto-shell.c
> +++ b/proto-shell.c
> @@ -184,8 +184,6 @@ proto_shell_handler(struct interface_proto_state *proto,
>   case S_SETUP_ABORT:
>   case S_TEARDOWN:
>   case S_SETUP:
> - return 0;
> -

If I'm reading this correctly, this would join the above cases with the
default case, so it is probably better to either drop the other "case"
statements and only leave the "default:" one or to keep explicit
redundancy by having two "return -1".

>   default:
>   return -1;
>   }
> 


~ Jo



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


<    1   2   3   4   5   6   7   8   9   10   >