Re: [LEDE-DEV] [RFC 2/3] ipq: Don't force selection of the IPQ4019 firmware.

2017-11-14 Thread Matthew McClintock 
What ever came of this? Did something upstream or in LEDE/OpenWrt
resolve what files should be loaded from where?

-M

On Sat, Nov 4, 2017 at 11:38 AM, Ben Greear  wrote:
>
>
> On 11/04/2017 08:14 AM, Christian Lamparter wrote:
>>
>> On Friday, November 3, 2017 8:15:00 PM CET Ben Greear wrote:
>>>
>>>
>>> On 11/03/2017 05:58 PM, Christian Lamparter wrote:

 On Friday, November 3, 2017 5:05:39 PM CET gree...@candelatech.com
 wrote:
>
> From: Ben Greear 
>
> This will allow us to select the CT IPQ4019 firmware instead if
> desired.
>
> Signed-off-by: Ben Greear 
> ---
>  package/firmware/ipq-wifi/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/firmware/ipq-wifi/Makefile
> b/package/firmware/ipq-wifi/Makefile
> index aec8bf2..31d0fbf 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -20,7 +20,7 @@ define Package/ipq-wifi-default
>SUBMENU:=ath10k IPQ4019 Boarddata
>SECTION:=firmware
>CATEGORY:=Firmware
> -  DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
> +  DEPENDS:=@TARGET_ipq806x

 Hm, this would break the WIFI in the default configuration for the
 FritzBox 4040 image. Currently it only has a dependency on the
 ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)

 Please also note that the ipq-wifi boards need to overwrite the
 board-2.bin provided by the ath10k-firmware-qca4019(-ct) packages.
 So switching (or up-/downgrading) these wifi-firmwares will always
 require the (manual) reinstallation of the ipq-wifi board
 (if available).
>>>
>>>
>>> Maybe have the custom board.data file named slightly differently
>>> and then have an early fixup script to copy it into the proper place
>>> on first boot?  And, we could hack the driver to look for a custom
>>> board-2.bin first and just install both board-x.bin images.
>>
>> Depends, can you convince the ath10k upstream to do that?
>
>
> Upstream is unlikely to accept such a patch, but I can at least
> patch my driver, and we can patch lede's 'upstream' driver too if
> we need to.
>
> We can also have a ath10k-pre-startup.sh that copies a custom board
> file into place when starting LEDE, with no driver modifications needed
> at all.  I think several targets do something like this already by grabbing
> the board file
> from a flash location on the AP, for instance.
>
>>>
>>> And, can we have the IPQ boards select the stock 4019 firmware by default
>>> but still allow it to be de-selected so CT firmware can be selected?
>>>
>>> Or if not, then I can call my firmware something different, and have my
>>> driver look for it before the firmware-5.bin.
>>
>>
>> I think there's a another way to do this. But it will require to break
>> with
>> the existing convention of adding the board-2.bin that comes with the
>> firmware repository to the ath10k-firmware-qca4019 file.
>>
>> This way, the custom board-2.bin will stay in place when you switch/update
>> the firmware-5.bin.
>
>
> That seems fine to me.  Then targets could select a custom board file or
> a stock board file, independent of the firmware and driver.
>
>>
>> (The board-2.bin for the reference boards can simply be packaged just like
>> one of the ipq-wifi board firmwares). And furhtermore, you could provide a
>> "easy to use/install" custom ipq-wifi.ipk for the board-2.bin you
>> currently
>> host on your webside.
>
>
> The only board-2.bin that I (might?) have on my web site is one modified for
> some newer 9984 NICs from Compex.  The 'ath10k-ct' firmware target just uses
> the
> default board-2.bin file from upstream.
>
> I guess someone could host/build ath10k-ct firmware ipks, but I think that
> might
> be more useful for some more standard LEDE build-farm to host since the goal
> is to
> have all of this in LEDE anyway.
>
> Thanks,
> Ben
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 2/2] bcm53xx: use otrx for creating TRX images

2017-11-14 Thread Rafał Miłecki 
From: Rafał Miłecki 

The advantage is that we don't have to specify max TRX size anymore and
otrx doesn't allocate a buffer of that size. It saves us allocating
32 MiB for every image we generate.

Signed-off-by: Rafał Miłecki 
---
 target/linux/bcm53xx/image/Makefile | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index e4dca0c4e9..596cb5ddb2 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -59,9 +59,7 @@ define Build/trx
 endef
 
 define Build/trx-serial
-   $(STAGING_DIR_HOST)/bin/trx \
-   -o $@.new \
-   -m 33554432 \
+   $(STAGING_DIR_HOST)/bin/otrx create $@.new \
-f $(IMAGE_KERNEL) -a 1024 \
-f $@ -a 0x1 -A $(KDIR)/fs_mark
mv $@.new $@
@@ -72,9 +70,7 @@ define Build/trx-nand
# if it grows up between releases
# root: UBI with one extra block containing UBI mark to trigger erasing
#   rest of partition
-   $(STAGING_DIR_HOST)/bin/trx \
-   -o $@.new \
-   -m 33554432 \
+   $(STAGING_DIR_HOST)/bin/otrx create $@.new \
-f $(IMAGE_KERNEL) -a 0x2 -b 0x40 \
-f $@ \
-A $(KDIR)/ubi_mark -a 0x2
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 1/2] firmware-utils: add otrx tool for handling TRX images

2017-11-14 Thread Rafał Miłecki 
From: Rafał Miłecki 

It can be a replacement for the trx tool. The advantage is that otrx
doesn't alloc buffer for the whole TRX which can be a nice optimization
when creating big images.

Signed-off-by: Rafał Miłecki 
---
 tools/firmware-utils/Makefile   |   1 +
 tools/firmware-utils/src/otrx.c | 595 
 2 files changed, 596 insertions(+)
 create mode 100644 tools/firmware-utils/src/otrx.c

diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index b7addbbb93..ca41387b5e 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -20,6 +20,7 @@ define Host/Compile
$(call cc,addpattern)
$(call cc,asustrx)
$(call cc,trx)
+   $(call cc,otrx)
$(call cc,motorola-bin)
$(call cc,dgfirmware)
$(call cc,mksenaofw md5)
diff --git a/tools/firmware-utils/src/otrx.c b/tools/firmware-utils/src/otrx.c
new file mode 100644
index 00..8833e43a89
--- /dev/null
+++ b/tools/firmware-utils/src/otrx.c
@@ -0,0 +1,595 @@
+/*
+ * otrx
+ *
+ * Copyright (C) 2015 Rafał Miłecki 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if !defined(__BYTE_ORDER)
+#error "Unknown byte order"
+#endif
+
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define cpu_to_le32(x) bswap_32(x)
+#define le32_to_cpu(x) bswap_32(x)
+#elif __BYTE_ORDER == __LITTLE_ENDIAN
+#define cpu_to_le32(x) (x)
+#define le32_to_cpu(x) (x)
+#else
+#error "Unsupported endianness"
+#endif
+
+#define TRX_MAGIC  0x30524448
+#define TRX_FLAGS_OFFSET   12
+#define TRX_MAX_PARTS  3
+
+struct trx_header {
+   uint32_t magic;
+   uint32_t length;
+   uint32_t crc32;
+   uint16_t flags;
+   uint16_t version;
+   uint32_t offset[3];
+};
+
+char *trx_path;
+size_t trx_offset = 0;
+char *partition[TRX_MAX_PARTS] = {};
+
+static inline size_t otrx_min(size_t x, size_t y) {
+   return x < y ? x : y;
+}
+
+/**
+ * CRC32
+ **/
+
+static const uint32_t crc32_tbl[] = {
+   0x, 0x77073096, 0xee0e612c, 0x990951ba,
+   0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
+   0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
+   0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
+   0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+   0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
+   0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
+   0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
+   0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
+   0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
+   0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
+   0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
+   0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
+   0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
+   0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
+   0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
+   0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
+   0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
+   0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
+   0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
+   0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
+   0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
+   0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
+   0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
+   0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
+   0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
+   0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
+   0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
+   0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
+   0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
+   0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
+   0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
+   0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
+   0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
+   0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
+   0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
+   0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
+   0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
+   0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
+   0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
+   0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
+   0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
+   0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
+   0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
+   0xcb61b38c, 0xbc66831a, 0x256fd2a0,

[LEDE-DEV] [PATCH resend 1/3] hostapd: Expose the tdls_prohibit option to UCI

2017-11-14 Thread Timo Sigurdsson 
wpa_disable_eapol_key_retries can't prevent attacks against the
Tunneled Direct-Link Setup (TDLS) handshake. Jouni Malinen suggested
that the existing hostapd option tdls_prohibit can be used to further
complicate this possibility at the AP side. tdls_prohibit=1 makes
hostapd advertise that use of TDLS is not allowed in the BSS.

Note: If an attacker manages to lure both TDLS peers into a fake
AP, hiding the tdls_prohibit advertisement from them, it might be
possible to bypass this protection.

Make this option configurable via UCI, but disabled by default.

Signed-off-by: Timo Sigurdsson 
---
 package/network/services/hostapd/files/hostapd.sh | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 16925d5..dc7640a 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -151,6 +151,8 @@ hostapd_common_add_bss_config() {
wpa_group_rekey wpa_pair_rekey wpa_master_rekey
config_add_boolean wpa_disable_eapol_key_retries
 
+   config_add_boolean tdls_prohibit
+
config_add_boolean rsn_preauth auth_cache
config_add_int ieee80211w
config_add_int eapol_version
@@ -215,7 +217,7 @@ hostapd_set_bss_options() {
 
json_get_vars \
wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey \
-   wpa_disable_eapol_key_retries \
+   wpa_disable_eapol_key_retries tdls_prohibit \
maxassoc max_inactivity disassoc_low_ack isolate auth_cache \
wps_pushbutton wps_label ext_registrar wps_pbc_in_m1 
wps_ap_setup_locked \
wps_independent wps_device_type wps_device_name 
wps_manufacturer wps_pin \
@@ -232,6 +234,7 @@ hostapd_set_bss_options() {
set_default wmm 1
set_default uapsd 1
set_default wpa_disable_eapol_key_retries 0
+   set_default tdls_prohibit 0
set_default eapol_version 0
set_default acct_port 1813
 
@@ -252,6 +255,8 @@ hostapd_set_bss_options() {
append bss_conf "ignore_broadcast_ssid=$hidden" "$N"
append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
 
+   [ "$tdls_prohibit" -gt 0 ] && append bss_conf 
"tdls_prohibit=$tdls_prohibit" "$N"
+
[ "$wpa" -gt 0 ] && {
[ -n "$wpa_group_rekey"  ] && append bss_conf 
"wpa_group_rekey=$wpa_group_rekey" "$N"
[ -n "$wpa_pair_rekey"   ] && append bss_conf 
"wpa_ptk_rekey=$wpa_pair_rekey""$N"
-- 
2.1.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH resend 2/3] hostapd: Backport Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case

2017-11-14 Thread Timo Sigurdsson 
wpa_disable_eapol_key_retries can't prevent attacks against the Wireless
Network Management (WNM) Sleep Mode handshake. Currently, hostapd
processes WNM Sleep Mode requests from clients regardless of the setting
wnm_sleep_mode. Backport Jouni Malinen's upstream patch 114f2830 in
order to ignore such requests by clients when wnm_sleep_mode is disabled
(which is the default).

Signed-off-by: Timo Sigurdsson 
---
 ...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch

diff --git 
a/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
 
b/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
new file mode 100644
index 000..13426e4
--- /dev/null
+++ 
b/package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
@@ -0,0 +1,35 @@
+From 114f2830d2c2aee6db23d48240e93415a256a37c Mon Sep 17 00:00:00 2001
+From: Jouni Malinen 
+Date: Fri, 20 Oct 2017 17:39:42 +0300
+Subject: [PATCH] WNM: Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case
+
+The hostapd wnm_sleep_mode parameter was previously used to control
+advertisement of WNM-Sleep Mode support, but it was not used when
+processing a request to use WNM-Sleep Mode. Add an explicit check during
+request processing as well so that any misbehaving station is ignored.
+
+Signed-off-by: Jouni Malinen 
+---
+ src/ap/wnm_ap.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/src/ap/wnm_ap.c b/src/ap/wnm_ap.c
+index 7c4fde0..973e4d3 100644
+--- a/src/ap/wnm_ap.c
 b/src/ap/wnm_ap.c
+@@ -200,6 +200,13 @@ static void ieee802_11_rx_wnmsleep_req(struct 
hostapd_data *hapd,
+   u8 *tfsreq_ie_end = NULL;
+   u16 tfsreq_ie_len = 0;
+ 
++  if (!hapd->conf->wnm_sleep_mode) {
++  wpa_printf(MSG_DEBUG, "Ignore WNM-Sleep Mode Request from "
++ MACSTR " since WNM-Sleep Mode is disabled",
++ MAC2STR(addr));
++  return;
++  }
++
+   dialog_token = *pos++;
+   while (pos + 1 < frm + len) {
+   u8 ie_len = pos[1];
+-- 
+2.1.4
-- 
2.1.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH resend 0/3] hostapd: Address some limitations of wpa_disable_eapol_key_retries

2017-11-14 Thread Timo Sigurdsson 
Hi,

I'm resending this series of patches as they seem to have gone
unnoticed so far on the mailing list.

In a discussion on the hostap mailing list about the limitations of the
new hostapd parameter wpa_disable_eapol_key_retries as an AP side
workaround for the Key Reinstallation Attacks (KRACK), two corner cases
were mentioned along with suggestions how to address them [1][2].

The changes are fairly simple and may help users to further narrow the
attack surface from the AP side (in case there are clients that are
still vulnerable).

The first allows to prohibit the use of TDLS on the network via an
already existing hostapd parameter that just needs to be made
configurable via UCI.

The second is an upstream patch to ensure WNM Sleep Mode requests are
ignored unless WNM Sleep Mode is enabled (which it isn't by default).

I'm planning to post patches backporting these changes to the v17.01
branch as well.

Regards,

Timo

Timo Sigurdsson (3):
  hostapd: Expose the tdls_prohibit option to UCI
  hostapd: Backport Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0
case
  hostapd: bump PKG_RELEASE

 package/network/services/hostapd/Makefile  |  2 +-
 package/network/services/hostapd/files/hostapd.sh  |  7 -
 ...WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch | 35 ++
 3 files changed, 42 insertions(+), 2 deletions(-)
 create mode 100644 
package/network/services/hostapd/patches/013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch

-- 
2.1.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH resend 3/3] hostapd: bump PKG_RELEASE

2017-11-14 Thread Timo Sigurdsson 
Increase PKG_RELEASE after latest changes to hostapd, so downstream
users can fetch updates via opkg.

Signed-off-by: Timo Sigurdsson 
---
 package/network/services/hostapd/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index 5a353e6..f1d057d 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=hostapd
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 
 PKG_SOURCE_URL:=http://w1.fi/hostap.git
 PKG_SOURCE_PROTO:=git
-- 
2.1.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Untangling 4K to 64K EB size JFFS2 migration

2017-11-14 Thread Thibaut VARÈNE 
Summary of the situation:

Situation:
Following c082938, PR#1495 attempts to switch ramips devices from 4K to 64K 
eraseblocks to speed up flash operations which are currently very slow. 
Furthermore, mktplinkfw does not support 4k sectors, which means that on Archer 
ramips devices the current image will always fail to restore the config.

Issue:
On NOR flash devices with jffs2 overlay, running `syupgrade -c` from a system 
with 4K sectors to flash an image with 64k sectors triggers filesystem 
corruption after a few reboots

Assumptions:
- we want to preserve config backup when flashing a system with 4K sectors with 
an image with 64k sectors
- using an intermediary upgrade image before changing blocksize is not 
acceptable

Observations:
1. when sysupgrade -c is invoked to preserve config files over reflash, it 
saves the current configuration files into `/sysupgrade.tgz` and appends that 
data as jffs2 via `mtd -j` option (in /lib/common.sh `default_do_upgrade()`)
2. the resulting jffs2 data has an EB size that matches the settings from the 
current running kernel, i.e. 4k: jffs2 nodes are written at 4k boundary with 
cleanmarkers and deadc0de marker also located at 4k boundary.
3. when the system is rebooted after flashing the new image, the jjfs2 driver 
finds the backup data before the deadc0de marker and complains about the 
invalid alignment of cleanmarkers, however the data appears to be valid at this 
point;
4. the preinit job will detect the presence of /sysupgrade.tgz in the resulting 
overlay, it will extract it and after the boot has completed it will remove 
`/sysupgrade.tgz` (in `/lib/preinit/80_mount_root` and then `/etc/init.d/done`)
5. when the device is rebooted one more time the jffs2 filesystem gets 
apparently so badly corrupted that it no longer complete the boot sequence.

Preliminary analysis:
When the system is rebooted after the flash, the initial jffs2 nodes that have 
been written by `mtd` at step 1. above have a 4k alignment and length. I assume 
(but I haven’t checked the code) that this sets jffs2 to operate on a 
filesystem that has 4k nodes, and this conflicts with the real EB size as 
reported by the kernel which is now 64k. This ends up in filesystem corruption.

Questions:
- To David: can jffs2 be “fixed” to cope with such a situation? Ideally it 
would preserve the backup data, but if that is not possible it should probably 
start from a clean slate instead of totally corrupting the partition?
- To LEDE devs: in the latter case, is it okay to break config preservation 
this one time? Note: 17.01 has 4K sectors enabled since 925e63e

Thanks,
Thibaut

PS: I’m not subscribed
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH packages 2/2] shadow: add packages for newgidmap and newuidmap applets

2017-11-14 Thread Rafał Miłecki 
From: Rafał Miłecki 

They are needed by LXC for unprivileged containers.

Signed-off-by: Rafał Miłecki 
---
 utils/shadow/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/utils/shadow/Makefile b/utils/shadow/Makefile
index 2cefe8b0..3ab40d9a 100644
--- a/utils/shadow/Makefile
+++ b/utils/shadow/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=shadow
 PKG_VERSION:=4.2.1
-PKG_RELEASE:=7
+PKG_RELEASE:=8
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://pkg-shadow.alioth.debian.org/releases
@@ -27,7 +27,8 @@ include $(INCLUDE_DIR)/nls.mk
 SHADOW_APPLETS := \
chage chpasswd chfn chsh expiry faillog gpasswd \
groupadd groupdel groupmems groupmod groups \
-   lastlog login newgrp nologin passwd su \
+   lastlog login newgidmap newgrp newuidmap nologin \
+   passwd su \
useradd userdel usermod vipw
 
 CONFIGURE_ARGS += \
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH packages 1/2] shadow: use proper fix for checking subordinate IDs support

2017-11-14 Thread Rafał Miłecki 
From: Rafał Miłecki 

During 4.2.1 version update support for subordinate IDs has been
disabled. It was handled by:

1) Adding --disable-subordinate-ids to avoid:
configure: error: cannot run test program while cross compiling

2) Adding patch 003-fix-disabling-subids.patch to avoid:
usermod.c: In function 'process_flags':
usermod.c:1364:10: error: 'vflg' undeclared (first use in this function)
  if (   (vflg || Vflg)
  ^

This commit adds a patch with a proper configure.in fix. We don't need
to disable subordinate IDs anymore.

Signed-off-by: Rafał Miłecki 
---
 utils/shadow/Makefile  |  5 ++--
 ...-of-uid_t-and-gid_t-using-AC_CHECK_SIZEOF.patch | 35 ++
 .../shadow/patches/003-fix-disabling-subids.patch  | 32 
 .../patches/004-fix-su-controoling-term.patch  |  2 +-
 4 files changed, 38 insertions(+), 36 deletions(-)
 create mode 100644 
utils/shadow/patches/003-Check-size-of-uid_t-and-gid_t-using-AC_CHECK_SIZEOF.patch
 delete mode 100644 utils/shadow/patches/003-fix-disabling-subids.patch

diff --git a/utils/shadow/Makefile b/utils/shadow/Makefile
index db9f7fb6..2cefe8b0 100644
--- a/utils/shadow/Makefile
+++ b/utils/shadow/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=shadow
 PKG_VERSION:=4.2.1
-PKG_RELEASE:=6
+PKG_RELEASE:=7
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://pkg-shadow.alioth.debian.org/releases
@@ -37,8 +37,7 @@ CONFIGURE_ARGS += \
--without-acl \
--without-attr \
--without-tcb \
-   --without-nscd \
-   --disable-subordinate-ids \
+   --without-nscd
 
 define Package/shadow/Default
   SECTION:=utils
diff --git 
a/utils/shadow/patches/003-Check-size-of-uid_t-and-gid_t-using-AC_CHECK_SIZEOF.patch
 
b/utils/shadow/patches/003-Check-size-of-uid_t-and-gid_t-using-AC_CHECK_SIZEOF.patch
new file mode 100644
index ..046523df
--- /dev/null
+++ 
b/utils/shadow/patches/003-Check-size-of-uid_t-and-gid_t-using-AC_CHECK_SIZEOF.patch
@@ -0,0 +1,35 @@
+From 2cb54158b80cdbd97ca3b36df83f9255e923ae3f Mon Sep 17 00:00:00 2001
+From: James Le Cuirot 
+Date: Sat, 23 Aug 2014 09:46:39 +0100
+Subject: [PATCH] Check size of uid_t and gid_t using AC_CHECK_SIZEOF
+
+This built-in check is simpler than the previous method and, most
+importantly, works when cross-compiling.
+
+Signed-off-by: Serge Hallyn 
+---
+ configure.in | 14 --
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+--- a/configure.in
 b/configure.in
+@@ -334,16 +334,10 @@ if test "$enable_subids" != "no"; then
+   dnl
+   dnl FIXME: check if 32 bit UIDs/GIDs are supported by libc
+   dnl
+-  AC_RUN_IFELSE([AC_LANG_SOURCE([
+-#include 
+-int main(void) {
+-  uid_t u;
+-  gid_t g;
+-  return (sizeof u < 4) || (sizeof g < 4);
+-}
+-  ])], [id32bit="yes"], [id32bit="no"])
++  AC_CHECK_SIZEOF([uid_t],, [#include "sys/types.h"])
++  AC_CHECK_SIZEOF([gid_t],, [#include "sys/types.h"])
+ 
+-  if test "x$id32bit" = "xyes"; then
++  if test "$ac_cv_sizeof_uid_t" -ge 4 && test "$ac_cv_sizeof_gid_t" -ge 
4; then
+   AC_DEFINE(ENABLE_SUBIDS, 1, [Define to support the subordinate 
IDs.])
+   enable_subids="yes"
+   else
diff --git a/utils/shadow/patches/003-fix-disabling-subids.patch 
b/utils/shadow/patches/003-fix-disabling-subids.patch
deleted file mode 100644
index bbc65c7d..
--- a/utils/shadow/patches/003-fix-disabling-subids.patch
+++ /dev/null
@@ -1,32 +0,0 @@
 a/src/usermod.c
-+++ b/src/usermod.c
-@@ -1361,6 +1361,7 @@ static void process_flags (int argc, cha
-   exit (E_UID_IN_USE);
-   }
- 
-+#ifdef ENABLE_SUBIDS
-   if (   (vflg || Vflg)
-   && !is_sub_uid) {
-   fprintf (stderr,
-@@ -1376,6 +1377,7 @@ static void process_flags (int argc, cha
-Prog, sub_gid_dbname (), "-w", "-W");
-   exit (E_USAGE);
-   }
-+#endif
- }
- 
- /*
 a/src/Makefile.am
-+++ b/src/Makefile.am
-@@ -52,7 +52,10 @@ usbin_PROGRAMS = \
- noinst_PROGRAMS = id sulogin
- 
- suidbins   = su
--suidubins  = chage chfn chsh expiry gpasswd newgrp passwd newuidmap 
newgidmap
-+suidubins  = chage chfn chsh expiry gpasswd newgrp passwd
-+if ENABLE_SUBIDS
-+  suidubins += newuidmap newgidmap
-+endif
- if ACCT_TOOLS_SETUID
-   suidubins += chage chgpasswd chpasswd groupadd groupdel groupmod 
newusers useradd userdel usermod
- endif
diff --git a/utils/shadow/patches/004-fix-su-controoling-term.patch 
b/utils/shadow/patches/004-fix-su-controoling-term.patch
index 4c130c73..2f7a670b 100644
--- a/utils/shadow/patches/004-fix-su-controoling-term.patch
+++ b/utils/shadow/patches/004-fix-su-controoling-term.patch
@@ -1,6 +1,6 @@
 --- a/src/su.c
 +++ b/src/su.c
-@@ -1090,8 +1090,12 @@
+@@ -1090,8 +1090,12 @@ int main (int argc, char **argv)

[LEDE-DEV] [PATCH] cns3xxx: refresh kernel config

2017-11-14 Thread Koen Vandeputte 
Signed-off-by: Koen Vandeputte 
---
 target/linux/cns3xxx/config-4.9 | 6 --
 1 file changed, 6 deletions(-)

diff --git a/target/linux/cns3xxx/config-4.9 b/target/linux/cns3xxx/config-4.9
index 4e5e016..36b4857 100644
--- a/target/linux/cns3xxx/config-4.9
+++ b/target/linux/cns3xxx/config-4.9
@@ -36,7 +36,6 @@ CONFIG_ATAGS=y
 CONFIG_ATA_VERBOSE_ERROR=y
 CONFIG_AUTO_ZRELADDR=y
 CONFIG_BCM_NET_PHYLIB=y
-# CONFIG_BINFMT_FLAT is not set
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_MQ_PCI=y
 CONFIG_BROADCOM_PHY=y
@@ -173,12 +172,9 @@ CONFIG_LEDS_GPIO=y
 # CONFIG_LEDS_TRIGGER_NETDEV is not set
 CONFIG_LIBFDT=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
-CONFIG_LZO_COMPRESS=y
-CONFIG_LZO_DECOMPRESS=y
 # CONFIG_MACH_CNS3420VB is not set
 CONFIG_MACH_GW2388=y
 CONFIG_MDIO_BOARDINFO=y
-# CONFIG_MFD_MAX77620 is not set
 CONFIG_MIGHT_HAVE_CACHE_L2X0=y
 CONFIG_MIGHT_HAVE_PCI=y
 CONFIG_MMC=y
@@ -265,7 +261,6 @@ CONFIG_SMP_ON_UP=y
 CONFIG_SPARSE_IRQ=y
 CONFIG_SPI=y
 CONFIG_SPI_BITBANG=y
-# CONFIG_SPI_CADENCE_QUADSPI is not set
 CONFIG_SPI_CNS3XXX=y
 CONFIG_SPI_MASTER=y
 CONFIG_SRCU=y
@@ -288,7 +283,6 @@ CONFIG_USB_DWC2_HOST=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_EHCI_PCI=y
-# CONFIG_USB_ETH is not set
 CONFIG_USB_GADGET=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Planned Server Maintenance

2017-11-14 Thread Jo-Philipp Wich 
Hi,

just fyi. Digital Ocean plans urgent maintenance on the host serving our
wiki between Thursday, 18:00 and 19:00 UTC.

Downtime is not expected but may occur.

Original notice below.

Regards,
Jo

--

FRA1 Emergency Maintenance 2017-11-16 18:00 UTC

Start: 2017-11-16 18:00 UTC
End: 2017-11-16 19:00 UTC

Hi there,

We are currently performing an urgent software upgrade impacting a
subset of FRA1 physical machines. In most scenarios, this upgrade occurs
seamlessly, with no impact to Droplets, however we have identified that
a very small number of upgrades require manual intervention and may
result in a brief Droplet downtime.

Your Droplets that may be potentially impacted by this maintenance are
listed below.

We're extremely sorry for the short notice, and inconvenience here, but
performing these upgrades are critical to significant improvements to
the performance and reliability of the platform.
If you have any questions, or concerns, please feel free to reply to
this email or open up a support ticket on your account.

Kind Regards,
DigitalOcean Customer Success

Affected Droplets:
wiki-01.infra.lede-project.org

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev