[OpenWrt-Devel] [PATCH] ath10k-firmware: Fix QCA6174 support

2018-05-24 Thread Rosen Penev 
Currently when installing the firmware, a bunch of files and directories
that the ath10k driver does not look for are created.

The package now installs firmware for both hw 2.1 and 3.0 devices.
2.1 is abandonware but may be useful to keep.

3.0 firmware was tested on a Killer 1535 to be relatively stable with
802.11w disabled. 802.11w causes multiple firmware crashes but that's true
of other ath10k firmwares as well.

Signed-off-by: Rosen Penev 
---
 package/firmware/ath10k-firmware/Makefile | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index eaee0ebc51..2c024905bb 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -438,8 +438,22 @@ define Package/ath10k-firmware-qca988x/install
 endef
 
 define Package/ath10k-firmware-qca6174/install
-   $(INSTALL_DIR) $(1)/lib/firmware/ath10k
-   $(CP) $(PKG_BUILD_DIR)/QCA6174 $(1)/lib/firmware/ath10k/
+   $(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA6174/hw2.1
+   $(INSTALL_DATA) \
+   $(PKG_BUILD_DIR)/QCA6174/hw2.1/board-2.bin \
+   $(1)/lib/firmware/ath10k/QCA6174/hw2.1/
+   $(INSTALL_DATA)
+   
$(PKG_BUILD_DIR)/QCA6174/hw2.1/firmware-5.bin_SW_RM.1.1.1-00157-QCARMSWPZ-1 \
+   $(1)/lib/firmware/ath10k/QCA6174/hw2.1/firmware-5.bin
+   $(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA6174/hw3.0
+   $(INSTALL_DATA) \
+   $(PKG_BUILD_DIR)/QCA6174/hw3.0/board-2.bin \
+   $(1)/lib/firmware/ath10k/QCA6174/hw3.0/
+   $(INSTALL_DATA)
+   
$(PKG_BUILD_DIR)/QCA6174/hw3.0/4.4.1.c1/firmware-6.bin_RM.4.4.1.c1-00042-QCARMSWP-1
 \
+   $(1)/lib/firmware/ath10k/QCA6174/hw3.0/firmware-6.bin
+   $(INSTALL_DATA)
+
 endef
 
 define Package/ath10k-firmware-qca99x0/install
-- 
2.17.0


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

[OpenWrt-Devel] [PATCH 1/2] ramips: Use generic board detect for GnuBee devices

2018-05-24 Thread Rosen Penev 
This is a port of an old commit from mkresin's tree:

09260cdf3e9332978c2a474a58e93a6f2b55f4a8

This has the potential to break sysupgrade but it should be fine as
there is no stable release of LEDE or OpenWrt that support these devices.

Signed-off-by: Rosen Penev 
---
 target/linux/ramips/base-files/etc/board.d/01_leds | 4 ++--
 target/linux/ramips/base-files/etc/board.d/02_network  | 4 ++--
 target/linux/ramips/base-files/etc/diag.sh | 4 ++--
 target/linux/ramips/base-files/lib/ramips.sh   | 3 ---
 target/linux/ramips/base-files/lib/upgrade/platform.sh | 4 ++--
 target/linux/ramips/dts/GB-PC1.dts | 2 +-
 target/linux/ramips/dts/GB-PC2.dts | 2 +-
 target/linux/ramips/image/mt7621.mk| 8 
 8 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 88e4c2b7fe..79f2cc2b87 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -196,8 +196,8 @@ fonera20n)
set_usb_led "$boardname:orange:usb"
set_wifi_led "$boardname:orange:wifi"
;;
-gb-pc1|\
-gnubee,gb-pc2)
+gnubee,pc1|\
+gnubee,pc2)
ucidef_set_led_switch "lan1" "lan1" "$boardname:green:lan1" "switch0" 
"0x01"
ucidef_set_led_switch "lan2" "lan2" "$boardname:green:lan2" "switch0" 
"0x10"
;;
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 3fc5e55df1..c50b5efc96 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -228,8 +228,8 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
;;
-   gb-pc1|\
-   gnubee,gb-pc2)
+   gnubee,pc1|\
+   gnubee,pc2)
ucidef_add_switch "switch0" \
"0:lan" "4:lan" "6@eth0"
;;
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 6a51778726..e8fb895529 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -95,8 +95,8 @@ get_status_led() {
dir-620-d1|\
dwr-512-b|\
dlink,dwr-116-a1|\
-   gb-pc1|\
-   gnubee,gb-pc2|\
+   gnubee,pc1|\
+   gnubee,pc2|\
hpm|\
hw550-3g|\
mac1200rv2|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index edccfcd4a8..5741cbd2ee 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -205,9 +205,6 @@ ramips_board_detect() {
*"FreeStation5")
name="freestation5"
;;
-   *"GB-PC1")
-   name="gb-pc1"
-   ;;
*"GL-MT300A")
name="gl-mt300a"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 7aa14770ca..35c6093ca5 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -62,8 +62,8 @@ platform_check_image() {
firewrt|\
fonera20n|\
freestation5|\
-   gb-pc1|\
-   gnubee,gb-pc2|\
+   gnubee,pc1|\
+   gnubee,pc2|\
gl-mt300a|\
gl-mt300n|\
gl-mt750|\
diff --git a/target/linux/ramips/dts/GB-PC1.dts 
b/target/linux/ramips/dts/GB-PC1.dts
index 2ea6582e01..77c9fb4ef0 100644
--- a/target/linux/ramips/dts/GB-PC1.dts
+++ b/target/linux/ramips/dts/GB-PC1.dts
@@ -6,7 +6,7 @@
 #include 
 
 / {
-   compatible = "gnubee,gb-pc1", "mediatek,mt7621-soc";
+   compatible = "gnubee,pc1", "mediatek,mt7621-soc";
model = "GB-PC1";
 
memory@0 {
diff --git a/target/linux/ramips/dts/GB-PC2.dts 
b/target/linux/ramips/dts/GB-PC2.dts
index ccaf54f3c8..b4648d81ca 100644
--- a/target/linux/ramips/dts/GB-PC2.dts
+++ b/target/linux/ramips/dts/GB-PC2.dts
@@ -6,7 +6,7 @@
 #include 
 
 / {
-   compatible = "gnubee,gb-pc2", "mediatek,mt7621-soc";
+   compatible = "gnubee,pc2", "mediatek,mt7621-soc";
model = "GB-PC2";
 
memory@0 {
diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index b84b74a5b0..9e1923cd4b 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -83,21 +83,21 @@ define Device/firewrt
 endef
 TARGET_DEVICES += firewrt
 
-define Device/gb-pc1
+define Device/gnubee_pc1
   DTS := GB-PC1
   DEVICE_TITLE := GnuBee Personal Cloud One
   DEVICE_PACKAGES := kmod-ata-core kmod-ata-ahci kmod-usb3 kmod-sdhci-mt7620
   IMAGE_SIZE :=

[OpenWrt-Devel] [PATCH 2/2] ramips: Fix a few other GnuBee DTS differences

2018-05-24 Thread Rosen Penev 
I was carrying a local commit that added the sdhci stuff and missed it
as a result.

Also fix the rgmii3 thing in the PC2 DTS file as that's bogus and causes
a dmesg warning that it's bogus.

Signed-off-by: Rosen Penev 
---
 target/linux/ramips/dts/GB-PC1.dts | 3 +++
 target/linux/ramips/dts/GB-PC2.dts | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/GB-PC1.dts 
b/target/linux/ramips/dts/GB-PC1.dts
index 77c9fb4ef0..8fffd5601b 100644
--- a/target/linux/ramips/dts/GB-PC1.dts
+++ b/target/linux/ramips/dts/GB-PC1.dts
@@ -58,6 +58,9 @@
 
  {
status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
 };
 
  {
diff --git a/target/linux/ramips/dts/GB-PC2.dts 
b/target/linux/ramips/dts/GB-PC2.dts
index b4648d81ca..e95839ba78 100644
--- a/target/linux/ramips/dts/GB-PC2.dts
+++ b/target/linux/ramips/dts/GB-PC2.dts
@@ -126,7 +126,7 @@
  {
state_default: pinctrl0 {
gpio {
-   ralink,group = "jtag", "rgmii3", "uart3", "wdt";
+   ralink,group = "jtag", "rgmii2", "uart3", "wdt";
ralink,function = "gpio";
};
};
-- 
2.17.0


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

Re: [OpenWrt-Devel] LEDE 17.01.5 release planning

2018-05-24 Thread Yousong Zhou 
On 25 May 2018 at 03:40, Martin Tippmann  wrote:
> On Thu, May 24, 2018 at 9:06 PM, Hauke Mehrtens  wrote:
>> Please do not hesitate to re report some request that something should
>> be backported from master or some regression compared to lede-17.01, if
>> it looks like they got ignored and didn't got a response.
>
> Hi, would be great if the recent wireguard version bump with MIPS
> assembly could be included:
> https://git.openwrt.org/aa30eb5b073c93ad00742a5a4046ac42e15b4b7a
>

I will take care of this one after simple testing.  Thank you

yousong

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

Re: [OpenWrt-Devel] LEDE 17.01.5 release planning

2018-05-24 Thread Lucian Cristian 

On 24.05.2018 22:40, Martin Tippmann wrote:

On Thu, May 24, 2018 at 9:06 PM, Hauke Mehrtens  wrote:

Please do not hesitate to re report some request that something should
be backported from master or some regression compared to lede-17.01, if
it looks like they got ignored and didn't got a response.

Hi, would be great if the recent wireguard version bump with MIPS
assembly could be included:
https://git.openwrt.org/aa30eb5b073c93ad00742a5a4046ac42e15b4b7a

thanks,
Martin

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


maybe omap fixes ? currently only ext4 images are working with this 
https://github.com/openwrt/openwrt/pull/869, the squashfs and sysupgrade 
is also working


Regards


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

Re: [OpenWrt-Devel] [PATCH] wolfssl: update to version 3.14.4

2018-05-24 Thread Daniel Golle 
Hi!

On Thu, May 24, 2018 at 10:38:45PM +0300, Alexandru Ardelean wrote:
> On Thu, May 24, 2018 at 7:34 PM, Daniel Golle  wrote:
> > Use download from github archive corresponding to v3.14.4 tag because
> > the project's website apparently only offers 3.14.0-stable release
> > downloads.
> > Drop local patch for CVE-2017-13099 as it was merged upstream.
> >
> 
> Looks good.
> On a related note, would you like to take over the package ?
> I don't seem to find time for it at the moment.

You had that nice patch to improve the build-time configuration half-
ready. It'd really be nice to still incooperate that...
I do believe you are doing a good job as a maintainer, however, if you
feel burdened by the maintainership I'm also ok to take over.


Cheers


Daniel

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

Re: [OpenWrt-Devel] LEDE 17.01.5 release planning

2018-05-24 Thread Martin Tippmann 
On Thu, May 24, 2018 at 9:06 PM, Hauke Mehrtens  wrote:
> Please do not hesitate to re report some request that something should
> be backported from master or some regression compared to lede-17.01, if
> it looks like they got ignored and didn't got a response.

Hi, would be great if the recent wireguard version bump with MIPS
assembly could be included:
https://git.openwrt.org/aa30eb5b073c93ad00742a5a4046ac42e15b4b7a

thanks,
Martin

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

Re: [OpenWrt-Devel] [PATCH] wolfssl: update to version 3.14.4

2018-05-24 Thread Alexandru Ardelean 
On Thu, May 24, 2018 at 7:34 PM, Daniel Golle  wrote:
> Use download from github archive corresponding to v3.14.4 tag because
> the project's website apparently only offers 3.14.0-stable release
> downloads.
> Drop local patch for CVE-2017-13099 as it was merged upstream.
>

Looks good.
On a related note, would you like to take over the package ?
I don't seem to find time for it at the moment.

> Signed-off-by: Daniel Golle 
> ---
>  package/libs/wolfssl/Makefile |   9 +-
>  .../wolfssl/patches/001-CVE-2017-13099.patch  | 144 --
>  .../patches/100-disable-hardening-check.patch |   2 +-
>  3 files changed, 6 insertions(+), 149 deletions(-)
>  delete mode 100644 package/libs/wolfssl/patches/001-CVE-2017-13099.patch
>
> diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
> index d0bd3b5a35..41296dd0f2 100644
> --- a/package/libs/wolfssl/Makefile
> +++ b/package/libs/wolfssl/Makefile
> @@ -8,12 +8,13 @@
>  include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=wolfssl
> -PKG_VERSION:=3.12.2
> -PKG_RELEASE:=2
> +PKG_VERSION:=3.14.4
> +PKG_RELEASE:=1
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).zip
> -PKG_SOURCE_URL:=https://www.wolfssl.com/
> -PKG_HASH:=4993844c4b7919007c4511ec3f987fb06543536c3fc933cb53491bffe9150e49
> +# PKG_SOURCE_URL:=https://www.wolfssl.com/
> +PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
> +PKG_HASH:=1da1b45dec4a455716c8547074ad883c737865225f69443bb173c0dc21683fd1
>
>  PKG_FIXUP:=libtool
>  PKG_INSTALL:=1
> diff --git a/package/libs/wolfssl/patches/001-CVE-2017-13099.patch 
> b/package/libs/wolfssl/patches/001-CVE-2017-13099.patch
> deleted file mode 100644
> index e7b63cb8d4..00
> --- a/package/libs/wolfssl/patches/001-CVE-2017-13099.patch
> +++ /dev/null
> @@ -1,144 +0,0 @@
> -From fd455d5a5e9fef24c208e7ac7d3a4bc58834cbf1 Mon Sep 17 00:00:00 2001
> -From: David Garske 
> -Date: Tue, 14 Nov 2017 14:05:50 -0800
> -Subject: [PATCH] Fix for handling of static RSA PKCS formatting failures so
> - they are indistinguishable from from correctly formatted RSA blocks (per
> - RFC5246 section 7.4.7.1). Adjusted the static RSA preMasterSecret RNG
> - creation for consistency in client case. Removed obsolete
> - `PMS_VERSION_ERROR`.
> -
> 
> - src/internal.c  | 70 
> +
> - wolfssl/error-ssl.h |  2 +-
> - 2 files changed, 61 insertions(+), 11 deletions(-)
> -
>  a/src/internal.c
> -+++ b/src/internal.c
> -@@ -14190,9 +14190,6 @@ const char* wolfSSL_ERR_reason_error_str
> - case NOT_READY_ERROR :
> - return "handshake layer not ready yet, complete first";
> -
> --case PMS_VERSION_ERROR :
> --return "premaster secret version mismatch error";
> --
> - case VERSION_ERROR :
> - return "record layer version error";
> -
> -@@ -18758,8 +18755,10 @@ int SendClientKeyExchange(WOLFSSL* ssl)
> - #ifndef NO_RSA
> - case rsa_kea:
> - {
> -+/* build PreMasterSecret with RNG data */
> - ret = wc_RNG_GenerateBlock(ssl->rng,
> --ssl->arrays->preMasterSecret, SECRET_LEN);
> -+>arrays->preMasterSecret[VERSION_SZ],
> -+SECRET_LEN - VERSION_SZ);
> - if (ret != 0) {
> - goto exit_scke;
> - }
> -@@ -23545,6 +23544,9 @@ static int DoSessionTicket(WOLFSSL* ssl,
> - word32 idx;
> - word32 begin;
> - word32 sigSz;
> -+#ifndef NO_RSA
> -+intlastErr;
> -+#endif
> - } DckeArgs;
> -
> - static void FreeDckeArgs(WOLFSSL* ssl, void* pArgs)
> -@@ -23770,6 +23772,14 @@ static int DoSessionTicket(WOLFSSL* ssl,
> - ERROR_OUT(BUFFER_ERROR, exit_dcke);
> - }
> -
> -+/* pre-load PreMasterSecret with RNG data */
> -+ret = wc_RNG_GenerateBlock(ssl->rng,
> -+>arrays->preMasterSecret[VERSION_SZ],
> -+SECRET_LEN - VERSION_SZ);
> -+if (ret != 0) {
> -+goto exit_dcke;
> -+}
> -+
> - args->output = NULL;
> - break;
> - } /* rsa_kea */
> -@@ -24234,6 +24244,20 @@ static int DoSessionTicket(WOLFSSL* ssl,
> - NULL, 0, NULL
> - #endif
> - );
> -+
> -+/*  Errors that can occur here that should be
> -+ *  indistinguishable:
> -+ *   RSA_BUFFER_E, RSA_PAD_E and 
> RSA_PRIVATE_ERROR
> -+ */
> -+if (ret < 0 && ret != BAD_FUNC_ARG) {
> -+

[OpenWrt-Devel] LEDE 17.01.5 release planning

2018-05-24 Thread Hauke Mehrtens 
We would like to create a lede 17.01.5 release soon, the last release,
lede 17.01.4, was done on 18. October 2017 which was a long time ago.
We are planning to do the build by end of next week, around 2. June 2018.

This release would be build form the lede-17.01 stable branch and
contain all the fixes which are in this branch.
For me this branch looks quite good, if there are any patches missing in
the lede-17.01 branch which you think should be backported from the
current master branch then please highlight this now, so we can have a
look at this.

I will update the kernel used in lede-17.01 to the latest version from
the stable 4.4 kernel line sometime beginning next week.

Please also report any regression which is in the current lede-17.01
branch compared to the lede 17.01.4 release.

Please do not hesitate to re report some request that something should
be backported from master or some regression compared to lede-17.01, if
it looks like they got ignored and didn't got a response.

All the developers can cherry picking some commits from master by them
self. ;-)

The versions of the packages can be found here:
https://sdwalker.github.io/uscan/index-17.01.html

The current snapshot build from the lede-17.01 branch can be found here:
https://downloads.lede-project.org/releases/17.01-SNAPSHOT/

Hauke

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

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] download: skip hash check without a download hash

2018-05-24 Thread Hauke Mehrtens 


On 05/06/2018 07:17 PM, Paul Oranje wrote:
> 
> 
>> Op 30 apr. 2018, om 08:39 heeft John Crispin  het volgende 
>> geschreven:
>>
>> On 30/03/18 17:34, Hauke Mehrtens wrote:
>>> If the package doe not contain a PKG_HASH just skip the check instead of
>>> making the download fail. The scripts/download.pl script will
>>> automatically skip the hash check in case the hash value equals skip,
>>> otherwise it fails.
>>>
>>> Signed-off-by: Hauke Mehrtens 
>>> ---
>>>  include/download.mk | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/download.mk b/include/download.mk
>>> index 2ba8a7bdf4..b14ce2a39a 100644
>>> --- a/include/download.mk
>>> +++ b/include/download.mk
>>> @@ -239,11 +239,11 @@ define Download/Defaults
>>>URL_FILE:=
>>>PROTO:=
>>>HASH=$$(MD5SUM)
>>> -  MD5SUM:=x
>>> +  MD5SUM:=skip
>>>SUBDIR:=
>>>MIRROR:=1
>>>MIRROR_HASH=$$(MIRROR_MD5SUM)
>>> -  MIRROR_MD5SUM:=x
>>> +  MIRROR_MD5SUM:=skip
>>>VERSION:=
>>>OPTS:=
>>>  endef
>>
>> Hi,
>> I am against merging this patch. b30ba14e2a858cfebcfdbc38348ab96a6d179556 
>> fixed an error where we had a copy/paste mess up of a hash causing a none 
>> valid length. we would think that there is hash that gets checked but it 
>> would never be validated. Adding your patch would introduce a similar case 
>> where a typo in the variable name would make us believe that a hash is 
>> present but in reality there it none. I'd prefer that the Makefile would 
>> have the skip inside it and that the buildsystem would then skip the 
>> validation.
>>
>> John
>>
>>
>> ___
>> Lede-dev mailing list
>> lede-...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> Sometime last year there has been some discussion about skipping hash 
> validations in development workflows and IIRC that it could (likewise) be 
> controlled with setting a HASH to skip and that once a change would be ready 
> for submission a true hash value would be set.
> 
> In the context of a development workflow the effect of a hash validation 
> being skipped is limited to the environment of the developer, but after 
> submission that would be different (and dangerous; I presume that a merge of 
> a patch without a proper hash value should never occur).
> 
> Please correct me if I'am wrong, regards,
> Paul
> 

I am ok with dropping this patch, I just wanted to get some opinions on
this topic and it makes sense to enforce the hash check.

@Paul: you can either build your package like this:
make package/foo/download PKG_HASH=skip
or you can define the skip directly in your package Makefile to skip the
hash check.

Hauke

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

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

2018-05-24 Thread Kristian Evensen 
Hi,

On Tue, May 22, 2018 at 10:33 PM, Rosen Penev  wrote:
> Looks like it's this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
> Please try reverting. Unfortunately I don't have mt7620 hardware so I
> can't test. Based on the comment, the issue should be fixed elsewhere.

I saw that you had already reverted this commit on the master-branch.
After commit 048e41f6496697863cc7d73ab95fa89a6ddf2470, GPIO on my
mt7620 device works fine again. Thanks for figuring this out and
fixing the problem so fast.

BR,
Kristian

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

Re: [OpenWrt-Devel] ipq806x and kernel 4.14 support / 18.06 kernel partition size?

2018-05-24 Thread Hannu Nyman 

John Crispin kirjoitti 24.5.2018 klo 18:44:


On 24/05/18 17:42, Hannu Nyman wrote:

John Crispin kirjoitti 24.5.2018 klo 18:36:


On 24/05/18 17:29, Hannu Nyman wrote:

...
The big question is if the sysupgrade break for regular users will be
* in the 17.01/18.06 change (enabling easy master/18.06/18.xx changes in 
future), or
* in the next version bump 18.06/18.xx (causing difficult master/18.06 
changes in the near future).


we need to break at some point regardless. we then need to break again 
when we migrate from swconfig -> DSA. my plan was to also make DSA work 
before the release and then just bite the bullet on this one.


    John



Funny, while I was writing my message to the mailing list, John actually 
did the thing that I was contemplating, moving the sysupgrade break into 
between 17.01 and 18.06 by bumping ipq806x in the 18.06 branch into 4.14. 
Hopefully a good thing. Thanks.




I postponed the QCA8K/DSA update for ages due to breaking uci upgrade now 
that we have 2 breakages we might aswell do it now and get a recent kernel 
and QCA8k support.


    John



Sounds like a plan. Now there is going to be some pain in moving to 18.06 in 
any case, so taking a double dose and suffering the QCA8K/DSA change at the 
same time sounds ok for me.


If would be super if there could be some uci-defaults transition script for 
the QCA8K/DSA bump for preventing unnecessary soft-bricks.




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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

2018-05-24 Thread Martin Blumenstingl via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Jaap,

On Thu, May 24, 2018 at 12:00 PM, Jaap Buurman  wrote:
> Dear all,
>
> I found some additional information in the system log: Thu May 24
> 11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
> requested, hw max 1500
> Digging deeper, this seems like a message that is spawned by a
> function in /net/core.dev.c of the linux kernel:
>
> if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
> net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
> dev->name, new_mtu, dev->max_mtu);
> return -EINVAL;
> }
>
> Is there anybody that happens to know where exactly this max_mtu value
> is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
> frames).
>
> Thank you very much in advance.
>
> Yours sincerely,
>
> Jaap Buurman
>
> On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
>> Dear all,
>>
>> The switch to the 4.14 kernel apparently broke the baby jumbo frames
>> support of 2048 bytes that the switch is capable off. I found out that
>> changing the mtu above 1500 via Luci no longer applies properly.
>> Trying to manually change the mtu via ssh also fails:
>>
>> root@LEDE:~# ifconfig eth0 mtu 1508 up
>> ifconfig: SIOCSIFMTU: Invalid argument
>>
>> If there is any additional information that I can supply, please let
>> me know. I am also more than willing to help test potential fixes :)
I *believe* Mathias has a fix for this in his tree (but I'm not sure
if he has the hardware to test it): [0]
maybe you can give it a go and report back?


Regards
Martin


[0] 
https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why nftables does not work in OpenWrt ?

2018-05-24 Thread Hauke Mehrtens 


On 05/22/2018 10:09 AM, Rosysong wrote:
> Hi Hauke,
> Do you mean my nftables commands (limit rate xxx) can work on 
> your lantiq (4.14 kernel)  target ?
> I also choose kmod-nf-flow and kmod-nft-offload modules, but it 
> can not restrict the traffic flow on specific ip address yet.
> 
>> On 05/20/2018 12:25 PM, Rosysong wrote:
> 
>>> I am using mips(ramips) target.
>>>
>>>
>> I tested this with lantiq and with kernel 4.9 nftables was working like
>> expected and with kernel 4.14 it does not work any more.
>> I do not know if this is caused by the more recent kernel or the flow
>> offloading.
> 
>> Hauke

Hi Rosysong,

Please do not top post.

I used this rule:
nft add table inet t1
nft create chain inet t1 k1 { type filter hook input priority 0\; }
nft add rule inet t1 k1 iif lo accept
nft add rule inet t1 k1 ct state established,related accept
nft add rule inet t1 k1 tcp dport 22 ct state new accept
nft add rule inet t1 k1 drop

from this article:
https://www.heise.de/select/ix/2018/1/1514658860742410

This works on lantiq target (MIPS BE) with kernel 4.9 as expected when I
have this patch applied:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/backport-4.9/092-netfilter-nf_tables-fix-mismatch-in-big-endian-syste.patch;h=024983142c4255bc2b4b4dd5a111632392fcb6e1;hb=HEAD
Without this patch it would block all traffic.

With the lantiq target on kernel 4.14 this rule does not work and does
not block any traffic.

I think there is a regression in kernel 4.14 or something went wrong
when we backported the flow offloading patches.

Hauke

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

[OpenWrt-Devel] [PATCH] wolfssl: update to version 3.14.4

2018-05-24 Thread Daniel Golle 
Use download from github archive corresponding to v3.14.4 tag because
the project's website apparently only offers 3.14.0-stable release
downloads.
Drop local patch for CVE-2017-13099 as it was merged upstream.

Signed-off-by: Daniel Golle 
---
 package/libs/wolfssl/Makefile |   9 +-
 .../wolfssl/patches/001-CVE-2017-13099.patch  | 144 --
 .../patches/100-disable-hardening-check.patch |   2 +-
 3 files changed, 6 insertions(+), 149 deletions(-)
 delete mode 100644 package/libs/wolfssl/patches/001-CVE-2017-13099.patch

diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index d0bd3b5a35..41296dd0f2 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -8,12 +8,13 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=wolfssl
-PKG_VERSION:=3.12.2
-PKG_RELEASE:=2
+PKG_VERSION:=3.14.4
+PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).zip
-PKG_SOURCE_URL:=https://www.wolfssl.com/
-PKG_HASH:=4993844c4b7919007c4511ec3f987fb06543536c3fc933cb53491bffe9150e49
+# PKG_SOURCE_URL:=https://www.wolfssl.com/
+PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
+PKG_HASH:=1da1b45dec4a455716c8547074ad883c737865225f69443bb173c0dc21683fd1
 
 PKG_FIXUP:=libtool
 PKG_INSTALL:=1
diff --git a/package/libs/wolfssl/patches/001-CVE-2017-13099.patch 
b/package/libs/wolfssl/patches/001-CVE-2017-13099.patch
deleted file mode 100644
index e7b63cb8d4..00
--- a/package/libs/wolfssl/patches/001-CVE-2017-13099.patch
+++ /dev/null
@@ -1,144 +0,0 @@
-From fd455d5a5e9fef24c208e7ac7d3a4bc58834cbf1 Mon Sep 17 00:00:00 2001
-From: David Garske 
-Date: Tue, 14 Nov 2017 14:05:50 -0800
-Subject: [PATCH] Fix for handling of static RSA PKCS formatting failures so
- they are indistinguishable from from correctly formatted RSA blocks (per
- RFC5246 section 7.4.7.1). Adjusted the static RSA preMasterSecret RNG
- creation for consistency in client case. Removed obsolete
- `PMS_VERSION_ERROR`.
-

- src/internal.c  | 70 +
- wolfssl/error-ssl.h |  2 +-
- 2 files changed, 61 insertions(+), 11 deletions(-)
-
 a/src/internal.c
-+++ b/src/internal.c
-@@ -14190,9 +14190,6 @@ const char* wolfSSL_ERR_reason_error_str
- case NOT_READY_ERROR :
- return "handshake layer not ready yet, complete first";
- 
--case PMS_VERSION_ERROR :
--return "premaster secret version mismatch error";
--
- case VERSION_ERROR :
- return "record layer version error";
- 
-@@ -18758,8 +18755,10 @@ int SendClientKeyExchange(WOLFSSL* ssl)
- #ifndef NO_RSA
- case rsa_kea:
- {
-+/* build PreMasterSecret with RNG data */
- ret = wc_RNG_GenerateBlock(ssl->rng,
--ssl->arrays->preMasterSecret, SECRET_LEN);
-+>arrays->preMasterSecret[VERSION_SZ],
-+SECRET_LEN - VERSION_SZ);
- if (ret != 0) {
- goto exit_scke;
- }
-@@ -23545,6 +23544,9 @@ static int DoSessionTicket(WOLFSSL* ssl,
- word32 idx;
- word32 begin;
- word32 sigSz;
-+#ifndef NO_RSA
-+intlastErr;
-+#endif
- } DckeArgs;
- 
- static void FreeDckeArgs(WOLFSSL* ssl, void* pArgs)
-@@ -23770,6 +23772,14 @@ static int DoSessionTicket(WOLFSSL* ssl,
- ERROR_OUT(BUFFER_ERROR, exit_dcke);
- }
- 
-+/* pre-load PreMasterSecret with RNG data */
-+ret = wc_RNG_GenerateBlock(ssl->rng,
-+>arrays->preMasterSecret[VERSION_SZ],
-+SECRET_LEN - VERSION_SZ);
-+if (ret != 0) {
-+goto exit_dcke;
-+}
-+
- args->output = NULL;
- break;
- } /* rsa_kea */
-@@ -24234,6 +24244,20 @@ static int DoSessionTicket(WOLFSSL* ssl,
- NULL, 0, NULL
- #endif
- );
-+
-+/*  Errors that can occur here that should be
-+ *  indistinguishable:
-+ *   RSA_BUFFER_E, RSA_PAD_E and RSA_PRIVATE_ERROR
-+ */
-+if (ret < 0 && ret != BAD_FUNC_ARG) {
-+#ifdef WOLFSSL_ASYNC_CRYPT
-+if (ret == WC_PENDING_E)
-+goto exit_dcke;
-+#endif
-+/* store error code for handling below */
-+args->lastErr = ret;
-+ret = 0;
-+}
- break;
- } /* rsa_kea */

Re: [OpenWrt-Devel] ipq806x and kernel 4.14 support / 18.06 kernel partition size?

2018-05-24 Thread John Crispin 



On 24/05/18 17:42, Hannu Nyman wrote:

John Crispin kirjoitti 24.5.2018 klo 18:36:



On 24/05/18 17:29, Hannu Nyman wrote:
Increasing the reserved kernel space in master from 2MB to 4MB due 
to kernel 4.14 for many ipq806x devices like R7800 has broken the 
sysupgrade possibility from 17.01, 18.06 or an earlier master 
snapshot build to the current master build. Same goes for the 
downgrade to stable branches.


The current situation where a jump between master and 18.06 (or 
17.01) will always require using the TFTP recovery mode, is rather 
cumbersome for people who regularly build/maintain both master and 
stable builds. I have published a community build for R7800 master 
and stable branch for the last two years, and this will make my life 
really hard with the new stable 18.06 branch.


That makes me wonder if the kernel space reservation enlargement in 
the firmware image should be done already for 18.06 although kernel 
4.9 does not force that, yet. It should be rather straightforward to 
enlarge kernel partition size in the 18.06 branch, but not do any 
other changes (so kernel would stay at 4.9 etc.). That would just 
decreases the space available for packages by 2 MB (like in master).


That kernel partition size change would enable a smooth jump between 
master and 18.06, and in future between 18.06 and the next release 
(18.12?)


The big question is if the sysupgrade break for regular users will be
* in the 17.01/18.06 change (enabling easy master/18.06/18.xx 
changes in future), or
* in the next version bump 18.06/18.xx (causing difficult 
master/18.06 changes in the near future).


we need to break at some point regardless. we then need to break 
again when we migrate from swconfig -> DSA. my plan was to also make 
DSA work before the release and then just bite the bullet on this one.


    John



Funny, while I was writing my message to the mailing list, John 
actually did the thing that I was contemplating, moving the sysupgrade 
break into between 17.01 and 18.06 by bumping ipq806x in the 18.06 
branch into 4.14. Hopefully a good thing. Thanks.




I postponed the QCA8K/DSA update for ages due to breaking uci upgrade 
now that we have 2 breakages we might aswell do it now and get a recent 
kernel and QCA8k support.


    John

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

Re: [OpenWrt-Devel] ipq806x and kernel 4.14 support / 18.06 kernel partition size?

2018-05-24 Thread Hannu Nyman 

John Crispin kirjoitti 24.5.2018 klo 18:36:



On 24/05/18 17:29, Hannu Nyman wrote:
Increasing the reserved kernel space in master from 2MB to 4MB due to 
kernel 4.14 for many ipq806x devices like R7800 has broken the sysupgrade 
possibility from 17.01, 18.06 or an earlier master snapshot build to the 
current master build. Same goes for the downgrade to stable branches.


The current situation where a jump between master and 18.06 (or 17.01) 
will always require using the TFTP recovery mode, is rather cumbersome for 
people who regularly build/maintain both master and stable builds. I have 
published a community build for R7800 master and stable branch for the 
last two years, and this will make my life really hard with the new stable 
18.06 branch.


That makes me wonder if the kernel space reservation enlargement in the 
firmware image should be done already for 18.06 although kernel 4.9 does 
not force that, yet. It should be rather straightforward to enlarge kernel 
partition size in the 18.06 branch, but not do any other changes (so 
kernel would stay at 4.9 etc.). That would just decreases the space 
available for packages by 2 MB (like in master).


That kernel partition size change would enable a smooth jump between 
master and 18.06, and in future between 18.06 and the next release (18.12?)


The big question is if the sysupgrade break for regular users will be
* in the 17.01/18.06 change (enabling easy master/18.06/18.xx changes in 
future), or
* in the next version bump 18.06/18.xx (causing difficult master/18.06 
changes in the near future).


we need to break at some point regardless. we then need to break again when 
we migrate from swconfig -> DSA. my plan was to also make DSA work before 
the release and then just bite the bullet on this one.


    John



Funny, while I was writing my message to the mailing list, John actually did 
the thing that I was contemplating, moving the sysupgrade break into between 
17.01 and 18.06 by bumping ipq806x in the 18.06 branch into 4.14. Hopefully a 
good thing. Thanks.




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

Re: [OpenWrt-Devel] ipq806x and kernel 4.14 support / 18.06 kernel partition size?

2018-05-24 Thread John Crispin 



On 24/05/18 17:29, Hannu Nyman wrote:
Increasing the reserved kernel space in master from 2MB to 4MB due to 
kernel 4.14 for many ipq806x devices like R7800 has broken the 
sysupgrade possibility from 17.01, 18.06 or an earlier master snapshot 
build to the current master build. Same goes for the downgrade to 
stable branches.


The current situation where a jump between master and 18.06 (or 17.01) 
will always require using the TFTP recovery mode, is rather cumbersome 
for people who regularly build/maintain both master and stable builds. 
I have published a community build for R7800 master and stable branch 
for the last two years, and this will make my life really hard with 
the new stable 18.06 branch.


That makes me wonder if the kernel space reservation enlargement in 
the firmware image should be done already for 18.06 although kernel 
4.9 does not force that, yet. It should be rather straightforward to 
enlarge kernel partition size in the 18.06 branch, but not do any 
other changes (so kernel would stay at 4.9 etc.). That would just 
decreases the space available for packages by 2 MB (like in master).


That kernel partition size change would enable a smooth jump between 
master and 18.06, and in future between 18.06 and the next release 
(18.12?)


The big question is if the sysupgrade break for regular users will be
* in the 17.01/18.06 change (enabling easy master/18.06/18.xx changes 
in future), or
* in the next version bump 18.06/18.xx (causing difficult master/18.06 
changes in the near future).


we need to break at some point regardless. we then need to break again 
when we migrate from swconfig -> DSA. my plan was to also make DSA work 
before the release and then just bite the bullet on this one.


    John

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

[OpenWrt-Devel] ipq806x and kernel 4.14 support / 18.06 kernel partition size?

2018-05-24 Thread Hannu Nyman 
Increasing the reserved kernel space in master from 2MB to 4MB due to kernel 
4.14 for many ipq806x devices like R7800 has broken the sysupgrade 
possibility from 17.01, 18.06 or an earlier master snapshot build to the 
current master build. Same goes for the downgrade to stable branches.


The current situation where a jump between master and 18.06 (or 17.01) will 
always require using the TFTP recovery mode, is rather cumbersome for people 
who regularly build/maintain both master and stable builds. I have published 
a community build for R7800 master and stable branch for the last two years, 
and this will make my life really hard with the new stable 18.06 branch.


That makes me wonder if the kernel space reservation enlargement in the 
firmware image should be done already for 18.06 although kernel 4.9 does not 
force that, yet. It should be rather straightforward to enlarge kernel 
partition size in the 18.06 branch, but not do any other changes (so kernel 
would stay at 4.9 etc.). That would just decreases the space available for 
packages by 2 MB (like in master).


That kernel partition size change would enable a smooth jump between master 
and 18.06, and in future between 18.06 and the next release (18.12?)


The big question is if the sysupgrade break for regular users will be
* in the 17.01/18.06 change (enabling easy master/18.06/18.xx changes in 
future), or
* in the next version bump 18.06/18.xx (causing difficult master/18.06 
changes in the near future).




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

Re: [OpenWrt-Devel] incorrect commit for dnsmasq (dnsmasq: use "hostsdir" instead of "addn-hosts")

2018-05-24 Thread Hans Dedecker 
On Thu, May 24, 2018 at 4:16 PM e9hack  wrote:

> Am 24.05.2018 um 09:16 schrieb Hans Dedecker:
> >> possible and must not load hostfiles from other instances. The entry in
> >> dnsmasq.init must be:
> >
> >> xappend "--addn-hosts=$HOSTFILE"
> > Making such a change will break the host entries learned via odhcpd as
the
> > entires are put into the odhcpd file residing in the /tmp/hosts dir

> For running two instances of dnsmasq, this is a must have. If two
instances of dnsmasq are running, than you will hide
> some informations between the instances. In this case you can't use
odhcpd or can it use for the interfaces of one
> dnsmasq instance only. In my configuration, the first dnsmasq instance
provides dhcp v4 and dns caching for a network
> with tor access only. The second instance is used for the common things
for all other networks (dhcp v4, statefull dhcp
> v6 for link local addresses, dns resolver, dnssec ...). Odhcpd is for
stateless dhcp v6 for the networks of the second
> instance only. Odhcpd doesn't create a hostfile, so I don't see this
issue.
That's not correct; odhcpd populates the odhcp file in /tmp/hosts with
hostname IPv6 address entries it has learned via statefull DHCPv6.
While I agree the current solution is not correct for multiple dnsmasq
instances; the above proposed solution will break the hostname entries
learned via odhcpd

Hans

> A solution may be, to use different hosts directories for every dnsmasq
instance.

> Regards,
> Hartmut

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

Re: [OpenWrt-Devel] incorrect commit for dnsmasq (dnsmasq: use "hostsdir" instead of "addn-hosts")

2018-05-24 Thread e9hack 
Am 24.05.2018 um 09:16 schrieb Hans Dedecker:
>> possible and must not load hostfiles from other instances. The entry in
>> dnsmasq.init must be:
> 
>> xappend "--addn-hosts=$HOSTFILE"
> Making such a change will break the host entries learned via odhcpd as the
> entires are put into the odhcpd file residing in the /tmp/hosts dir

For running two instances of dnsmasq, this is a must have. If two instances of 
dnsmasq are running, than you will hide
some informations between the instances. In this case you can't use odhcpd or 
can it use for the interfaces of one
dnsmasq instance only. In my configuration, the first dnsmasq instance provides 
dhcp v4 and dns caching for a network
with tor access only. The second instance is used for the common things for all 
other networks (dhcp v4, statefull dhcp
v6 for link local addresses, dns resolver, dnssec ...). Odhcpd is for stateless 
dhcp v6 for the networks of the second
instance only. Odhcpd doesn't create a hostfile, so I don't see this issue.

A solution may be, to use different hosts directories for every dnsmasq 
instance.

Regards,
Hartmut



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

[OpenWrt-Devel] [PATCH v2] fstools: Add the new options available in the menuconfig

2018-05-24 Thread Pierre Lebleu 
Mounting using the zlib compression and mounting with
full access accounting are now available in the
menuconfig.

Signed-off-by: Pierre Lebleu 
---
v2: change the option names
 package/system/fstools/Makefile | 16 
 1 file changed, 16 insertions(+)

diff --git a/package/system/fstools/Makefile b/package/system/fstools/Makefile
index 494f90d..f71e333 100644
--- a/package/system/fstools/Makefile
+++ b/package/system/fstools/Makefile
@@ -33,6 +33,8 @@ include $(INCLUDE_DIR)/cmake.mk
 
 TARGET_LDFLAGS += $(if $(CONFIG_USE_GLIBC),-lrt)
 CMAKE_OPTIONS += $(if $(CONFIG_FSTOOLS_UBIFS_EXTROOT),-DCMAKE_UBIFS_EXTROOT=y)
+CMAKE_OPTIONS += $(if 
$(CONFIG_FSTOOLS_OVL_MOUNT_FULL_ACCESS_TIME),-DCMAKE_OVL_MOUNT_FULL_ACCESS_TIME=y)
+CMAKE_OPTIONS += $(if 
$(CONFIG_FSTOOLS_OVL_MOUNT_COMPRESS_ZLIB),-DCMAKE_OVL_MOUNT_COMPRESS_ZLIB=y)
 
 define Package/fstools
   SECTION:=base
@@ -50,6 +52,20 @@ define Package/fstools/config
default y
help
This option makes it possible to use extroot 
functionality if the root filesystem resides on an UBIFS partition
+
+   config FSTOOLS_OVL_MOUNT_FULL_ACCESS_TIME
+   depends on PACKAGE_fstools
+   bool "Full access time accounting"
+   default n
+   help
+   This option enables the full access time accounting 
(warning: it will increase the flash writes).
+
+   config FSTOOLS_OVL_MOUNT_COMPRESS_ZLIB
+   depends on PACKAGE_fstools
+   bool "Compress using zlib"
+   default n
+   help
+   This option enables the compression using zlib on the 
storage device.
 endef
 
 define Package/snapshot-tool
-- 
1.9.1


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

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

2018-05-24 Thread Jaap Buurman 
Dear all,

I found some additional information in the system log: Thu May 24
11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
requested, hw max 1500
Digging deeper, this seems like a message that is spawned by a
function in /net/core.dev.c of the linux kernel:

if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
dev->name, new_mtu, dev->max_mtu);
return -EINVAL;
}

Is there anybody that happens to know where exactly this max_mtu value
is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
frames).

Thank you very much in advance.

Yours sincerely,

Jaap Buurman

On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
> Dear all,
>
> The switch to the 4.14 kernel apparently broke the baby jumbo frames
> support of 2048 bytes that the switch is capable off. I found out that
> changing the mtu above 1500 via Luci no longer applies properly.
> Trying to manually change the mtu via ssh also fails:
>
> root@LEDE:~# ifconfig eth0 mtu 1508 up
> ifconfig: SIOCSIFMTU: Invalid argument
>
> If there is any additional information that I can supply, please let
> me know. I am also more than willing to help test potential fixes :)
>
> Yours sincerely,
>
> Jaap Buurman

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

[OpenWrt-Devel] [PATCH 1/2] kernel: bump 4.9 to 4.9.102 for 18.06

2018-05-24 Thread Koen Vandeputte 
Refreshed all patches

Added new ARM64 symbol: ARM64_ERRATUM_1024718

Compile-tested on: ar71xx
Runtime-tested on: ar71xx

Signed-off-by: Koen Vandeputte 
---
 include/kernel-version.mk  |   4 +-
 .../ar7/patches-4.9/300-add-ac49x-platform.patch   |   4 +-
 .../403-mtd_fix_cfi_cmdset_0002_status_check.patch |  14 +-
 .../411-mtd-cfi_cmdset_0002-force-word-write.patch |   6 +-
 .../ar71xx/patches-4.9/500-MIPS-fw-myloader.patch  |   2 +-
 .../ar71xx/patches-4.9/604-MIPS-ath79-no-of.patch  |   2 +-
 ...4-ARM-at91-build-dtb-for-sama5d27-SOM1-Ek.patch |  31 +-
 ...105-ARM-at91-build-dtb-for-sama5d2-ptc-Ek.patch |  17 +-
 .../linux/ath25/patches-4.9/107-ar5312_gpio.patch  |   2 +-
 .../patches-4.9/950-0031-Add-dwc_otg-driver.patch  |   2 +-
 ...fill-user-BO-creation-requests-from-the-k.patch |   2 +-
 ...-OOPSes-from-trying-to-cache-a-partially-.patch |   2 +-
 ...01-MIPS-BCM63XX-add-clkdev-lookup-support.patch |   2 +-
 ...match_table-parsing-for-partition-parsers.patch |   6 +-
 .../322-MIPS-BCM63XX-switch-to-IRQ_DOMAIN.patch|   2 +-
 .../090-net-generalize-napi_complete_done.patch|   4 +-
 target/linux/generic/config-4.9|   1 +
 .../linux/generic/hack-4.9/220-gc_sections.patch   |   2 +-
 .../hack-4.9/301-mips_image_cmdline_hack.patch |   2 +-
 ...net-usb-add-lte-modem-wistron-neweb-d18q1.patch |   2 +-
 ...t-qmi_wwan-add-BroadMobi-BM806U-2020-2033.patch |   2 +-
 .../pending-4.9/300-mips_expose_boot_raw.patch |   4 +-
 .../generic/pending-4.9/304-mips_disable_fpu.patch |   2 +-
 ...m-remove-no-op-dma_map_ops-where-possible.patch |  12 +-
 ..._cmdset_0002-add-buffer-write-cmd-timeout.patch |   2 +-
 .../pending-4.9/630-packet_socket_type.patch   |  16 +-
 ...jecting-with-source-address-failed-policy.patch |  16 +-
 .../generic/pending-4.9/834-ledtrig-libata.patch   |   8 +-
 .../pending-4.9/890-uart_optional_sysrq.patch  |   4 +-
 .../patches-4.9/090-increase_entropy_pools.patch   |   2 +-
 .../patches-4.9/600-skb_avoid_dmabounce.patch  |   2 +-
 .../linux/lantiq/patches-4.9/0152-lantiq-VPE.patch |   2 +-
 .../202-core-linux-support-layerscape.patch|   4 +-
 .../patches-4.9/817-usb-support-layerscape.patch   |  18 +-
 .../102-powerpc-add-cmdline-override.patch |   2 +-
 .../sunxi/patches-4.9/0052-stmmac-form-4-12.patch  | 344 +++--
 .../linux/uml/patches-4.9/101-mconsole-exec.patch  |   2 +-
 37 files changed, 276 insertions(+), 275 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index cf84e31f7b0f..1c5d9161386a 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -4,13 +4,13 @@ LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .71
 LINUX_VERSION-4.4 = .121
-LINUX_VERSION-4.9 = .96
 LINUX_VERSION-4.14 = .37
+LINUX_VERSION-4.9 = .102
 
 LINUX_KERNEL_HASH-3.18.71 = 
5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240
 LINUX_KERNEL_HASH-4.4.121 = 
44a88268b5088dc326b30c9b9133ac35a9a200b636b7268d08f32abeae6ca729
-LINUX_KERNEL_HASH-4.9.96 = 
826f596eb5197f8b17304649c2990dd7b766f5c79076cae79f4261c40cea877f
 LINUX_KERNEL_HASH-4.14.37 = 
8197e7ed3620713e412905430a7bf93e2048384042ffba189a66f0eeb6908e92
+LINUX_KERNEL_HASH-4.9.102 = 
d155a36ba52d5809805cd370902582ac373c5b23a958c6424325684447119dc5
 
 remove_uri_prefix=$(subst git://,,$(subst http://,,$(subst https://,,$(1
 sanitize_uri=$(call qstrip,$(subst @,_,$(subst :,_,$(subst .,_,$(subst 
-,_,$(subst /,_,$(1)))
diff --git a/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch 
b/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch
index 67ed3e494a0d..639f09709ba8 100644
--- a/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch
+++ b/target/linux/ar7/patches-4.9/300-add-ac49x-platform.patch
@@ -37,7 +37,7 @@
  #define AR7_IRQ_UART0 15
 --- a/arch/mips/Kconfig
 +++ b/arch/mips/Kconfig
-@@ -160,7 +160,7 @@ config AR7
+@@ -161,7 +161,7 @@ config AR7
select HAVE_CLK
help
  Support for the Texas Instruments AR7 System-on-a-Chip
@@ -46,7 +46,7 @@
  
  config ATH25
bool "Atheros AR231x/AR531x SoC support"
-@@ -1004,6 +1004,7 @@ config MIPS_PARAVIRT
+@@ -1005,6 +1005,7 @@ config MIPS_PARAVIRT
  endchoice
  
  source "arch/mips/alchemy/Kconfig"
diff --git 
a/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
 
b/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
index 415d835ee348..3a7fe99e6524 100644
--- 
a/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
+++ 
b/target/linux/ar71xx/patches-4.9/403-mtd_fix_cfi_cmdset_0002_status_check.patch
@@ -1,6 +1,6 @@
 --- a/drivers/mtd/chips/cfi_cmdset_0002.c
 +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
-@@ -1630,8 +1630,8 @@ static int __xipram do_write_oneword(str
+@@ -1631,8 +1631,8 @@ static int __xipram do_write_oneword(str
break;
}
  
@@ -11,7 +11,7 @@

Re: [OpenWrt-Devel] incorrect commit for dnsmasq (dnsmasq: use "hostsdir" instead of "addn-hosts")

2018-05-24 Thread Hans Dedecker 
On Wed, May 23, 2018 at 11:43 PM e9hack  wrote:

> Hi,

> this commit and the way, who the init script handles hostfiles seams to
be completely wrong. The init script generates
> one independent hostfile per dnsmasq instance and writes it to a common
directory. Multiple dnsmasq instances are
> possible and must not load hostfiles from other instances. The entry in
dnsmasq.init must be:

> xappend "--addn-hosts=$HOSTFILE"
Making such a change will break the host entries learned via odhcpd as the
entires are put into the odhcpd file residing in the /tmp/hosts dir

Hans

> Than every dnsmasq instance loads the associated hostfile only.

> Regards,
> Hartmut

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