[OpenWrt-Devel] [PATCH] iwinfo: Complete device IDs for Ubiquiti airOS XM/XW devices

[Vincent Wiemann]

This commit includes all power offsets and subsystem device IDs
for Ubiquiti XM and XW devices. The device ID is wildcarded.
Consistency has been tested among all Ubiquiti platforms.
These values seem to be PA gains and likely do not include
antenna gains. I expect the antenna gains to be defined in ART-
partitions.

Signed-off-by: Vincent Wiemann 
---
 hardware.txt | 103
---
 1 file changed, 98 insertions(+), 5 deletions(-)

diff --git a/hardware.txt b/hardware.txt
index f36c476..727c607 100644
--- a/hardware.txt
+++ b/hardware.txt
@@ -17,6 +17,99 @@
 0x 0x 0x 0xc1055  0  "Ubiquiti" "NanoStation Loco5"
 0x 0x 0x 0xc202   10  0  "Ubiquiti" "Bullet2"
 0x 0x 0x 0xc2055  0  "Ubiquiti" "Bullet5"
+0x168c 0x 0x0777 0xe0026  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0033  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0055  0  "Ubiquiti" "NanoStation M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe0065  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0096  0  "Ubiquiti" "NanoStation Loco
M9" /* airOS XM */
+0x168c 0x 0x0777 0xe012   10  0  "Ubiquiti" "NanoStation M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe0353  0  "Ubiquiti" "NanoStation M3" /*
airOS XM */
+0x168c 0x 0x0777 0xe0a22  0  "Ubiquiti" "NanoStation Loco
M2" /* airOS XM */
+0x168c 0x 0x0777 0xe0a51  0  "Ubiquiti" "NanoStation Loco
M5" /* airOS XM */
+0x168c 0x 0x0777 0xe1026  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1055  0  "Ubiquiti" "Rocket M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe112   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1153  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1a33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1a55  0  "Ubiquiti" "PowerBridge M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe1b2   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b55  0  "Ubiquiti" "Rocket M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe1b65  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b96  0  "Ubiquiti" "Rocket M9" /*
airOS XM */
+0x168c 0x 0x0777 0xe1c2   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1c33  0  "Ubiquiti" "Rocket M3" /*
airOS XM */
+0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "Rocket M5 GPS" /*
airOS XM */
+0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1d2   10  0  "Ubiquiti" "Rocket M2
Titanium" /* airOS XM/XW */
+0x168c 0x 0x0777 0xe1d33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1d55  0  "Ubiquiti" "airOS XM/XW"
+0x168c 0x 0x0777 0xe1d96  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1e33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1e55  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe202   12  0  "Ubiquiti" "Bullet M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe2056  0  "Ubiquiti" "Bullet M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe2121  0  "Ubiquiti" "AirGrid M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe2151  0  "Ubiquiti" "AirGrid M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe2322  0  "Ubiquiti" "NanoBridge M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe2333  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2351  0  "Ubiquiti" "NanoBridge M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe2396  0  "Ubiquiti" "NanoBridge M9" /*
airOS XM */
+0x168c 0x 0x0777 0xe2429  0  "Ubiquiti" "AirGrid M2 HP" /*
airOS XM */
+0x168c 0x 0x0777 0xe2433  0  "Ubiquiti" "NanoBridge M3" /*
airOS XM */
+0x168c 0x 0x0777 0xe2456  0  "Ubiquiti" "AirGrid M5 HP" /*
airOS XM */
+0x168c 0x 0x0777 0xe2529  0  "Ubiquiti" "AirGrid M2 HP" /*
airOS XM */
+0x168c 0x 0x0777 0xe2556  0  "Ubiquiti" "AirGrid M5 HP" /*
airOS XM */
+0x168c 0x 0x0777 0xe2a33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2a55  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2b2   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2b51  0  "Ubiquiti" "NanoBridge M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe2b96  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2c2   10  0  "Ubiquiti" "NanoBeam M2 Int"
/* airOS XW */
+0x168c 0x 0x0777 0xe2c36  0  "Ubiquiti" "Bullet M2 XW" /*
airOS XW */
+0x168c 0x 0x0777 0xe2c46  0  "Ubiquiti" "airOS XW"
+0x168c 0x 0x0777 0xe2d2   12  0  "Ubiquiti" "Bullet M2 Titanium
HP" /* airOS XM */
+0x168c 0x 0x0777 0xe2d46  0  "Ubiquiti" "airOS XW"
+0x168c 0x 0x0777 0xe2d56  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2e54  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe302   12  0  "Ubiquiti" "PicoStation M2" /*

Re: [OpenWrt-Devel] [PATCH] ath79: add support for tplink tl-wdr3600 modified with 16M flash

[Lech Perczak]

Hi,

W dniu 2019-03-15 o 10:18, Chuanhong Guo pisze:

Hi!
On Fri, Mar 15, 2019 at 2:42 PM Russell Senior
 wrote:

To modify a WDR3600 with 16MB flash, you will need an external SPI programmer
and soldering tools.  First, obtain a copy of the starting contents either with
the external programmer or from commands in OpenWrt:

Unfortunately OpenWrt never accepts device support requiring hardware
modifications.
I think part of the reason is that there are too many possible
variants when it comes to hardware modifications and all those
variants will make users confused.


Yeah, that's the rule.

In ar71xx such Device Tree mods weren't needed at all, flash size was 
autodetected at bootup.


Maybe you can think about implementing such generic autodetection 
mechanism for ath79 target instead, so there would be no need to support 
modded routers explicitly, so standard images could be used on modded 
routers too.

I think that quite many users could benefit from this.

Some maintainers talked about this problem in a past thread but I
can't find it now.

Regards,
Chuanhong Guo

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



--
Pozdrawiam,
Lech Perczak
lech.perc...@gmail.com
Mobile: +48 694 309 185

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

[OpenWrt-Devel] [RFC] ipq40xx: qca8x / ipqess: 10_indicate_preinit Likely Needs Adjustment

[Jeff Kletsky]

In working with an IPQ4019 device with qca8x and ipqess,
using a handful of patches[1] from


it appears that `10_indicate_preinit` has some behavior that needs to
be addressed in the future, prior to calling `preinit_net_echo`.

The two issues that I see include

  * eth0 needs to be "up" for lan1@eth0 to be "up"

  * qca8x takes a little over a second from interface up request
    to the time that the bridge has reconfigured itself

The timing issue may be "hidden" once UCI-based switch configuration
is present in `preinit_config_switch`, but should be considered if the
`preinit_net_echo` functionality is to be reliably supported.


Indication of the issues can be seen in the boot log (serial) as

  [    4.024645] init: - preinit -
  ip: SIOCSIFFLAGS: Network is down
  sendto(): Network unreachable
  Press the [f] key and hit [enter] to enter failsafe mode


An "ugly hack" for this is to `ip link set dev eth0 up`
prior to trying to bring up lan1, then `sleep 2` after lan1 is up


The delay in qca8k is just a little over a second:

  [    5.165257] qca8k c00.switch lan1: configuring for phy/ link mode
  DEBUG: Snoozing for 2 seconds to allow qca8k to respond
  [    6.246260] qca8k c00.switch lan1: Link is Up - 1Gbps/Full - 
flow control rx/tx

  [    6.246654] IPv6: ADDRCONF(NETDEV_CHANGE): lan1: link becomes ready


I've thought about bringing up any interfaces that match `ethN`, as
well as waiting for the "up" condition before `preinit_net_echo` as
potentially more robust approaches. Other suggestions are welcome.



Jeff



[1]

1db1612bbc ipq40xx: include ipq40xx-ized qca8k version
2db429cf34 ipq40xx: fix NPE related to bogus use of fixed phy
505cfcfb1c ipq40xx: extend DT mdio node to be more accessible
abf050221c ipq40xx: add ipqess ethernet driver
2d6352f8b1 ipq40xx: add resets for individual MAC1-5 and PSGMII
fce445b243 ipq40xx: decouple mdio-ipq40xx and ar40xx
99e74d2e90 phytool: add phytool utility
c83b9fec9e ipq40xx: fix phy interrupt setting

The last of these patches appears to now be present in `master`
as commit 784f2e73df


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

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Etienne Champetier]

Hi Petr,

Le ven. 15 mars 2019 à 13:01, Petr Štetiar  a écrit :
>
> Etienne Champetier  [2019-03-15 10:46:09]:
>
> Hi,
>
> > Just a side note, on first boot we save a random seed using getrandom()
> > https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/init.d/urandom_seed
> > https://github.com/openwrt/openwrt/blob/master/package/base-files/files/sbin/urandom_seed
> >
> > And we restore it in preinit
> > https://github.com/openwrt/openwrt/blob/master/package/base-files/files/lib/preinit/81_urandom_seed
>
> Well, it seems like we're writing the /etc/urandom.seed to the /dev/urandom
> which doesn't help with initialization of CRNG, just seeding the /dev/urandom.
>
> > So even if kernel PRNG is considered not initialized, in reality it
> > is, so starting from second boot we are ~ok
>
> Nope, see bellow.
>
> 1st boot:
>
>  [3.944674] urandom-seed: Seed file not found (/etc/urandom.seed)
>  [   75.120166] random: fast init done
>  [  140.917418] random: crng init done
>
> 2nd boot:
>
>  [3.938414] urandom-seed: Seeding with /etc/urandom.seed
>  [   22.440981] random: fast init done
>  [  135.737309] random: crng init done

I was not precise enough, writing to /dev/urandom do add entropy to
the internal CSPRNG state, but the kernel count it as 0 because he
doesn't trust it
So after urandom-seed you are ~ok from a security stand point, but yes
getrandom() still blocks

>
> -- ynezz

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

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Petr Štetiar]

Petr Štetiar  [2019-03-15 15:09:23]:

> I see it more as a problem of the implementation of getrandom syscall in
> Linux kernel

I've just found following interesting upstream commits in v4.18:

 commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
 Author: Theodore Ts'o 
 Date:   Tue Jul 17 18:24:27 2018 -0400

random: add a config option to trust the CPU's hwrng

This gives the user building their own kernel (or a Linux
distribution) the option of deciding whether or not to trust the CPU's
hardware random number generator (e.g., RDRAND for x86 CPU's) as being
correctly implemented and not having a back door introduced (perhaps
courtesy of a Nation State's law enforcement or intelligence
agencies).

This will prevent getrandom(2) from blocking, if there is a
willingness to trust the CPU manufacturer.

 commit 9b25436662d5fb4c66eb527ead53cab15f596ee0
 Author: Kees Cook 
 Date:   Mon Aug 27 14:51:54 2018 -0700

random: make CPU trust a boot parameter

Instead of forcing a distro or other system builder to choose
at build time whether the CPU is trusted for CRNG seeding via
CONFIG_RANDOM_TRUST_CPU, provide a boot-time parameter for end users to
control the choice. The CONFIG will set the default state instead.

So this actually might be a better direction for exploration.

-- ynezz

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

Re: [OpenWrt-Devel] ipq40xx: bootarg Manipulation Failing

[Jeff Kletsky]

On 3/14/19 3:39 PM, Jeff Kletsky wrote:


I'm trying to bring up an IPQ4019-based Linksys EA8300 and have a
challenge with the OEM bootargs from U-Boot. While they could be
modified once in OpenWrt, I'm hoping to provide a serial-less way
for users to easily flash OpenWrt from the OEM web interface.

[...]

TL;DR
=

  * I've tried 0067-generic-Mangle-bootloader-s-kernel-arguments.patch
    It doesn't seem to be able to modify the FDT

  * Can I better confirm if atags_to_fdt() is executing?

  * If it is executing, what am I not doing properly to modify the FDT?

  * If it is not executing:
    * Is there an example of command-line modification in `init`?
    * Is there a better way, short of changing U-Boot, to make the 
change?

[...]



While still something of a puzzle, I've been able to find a solution
in early `init`.

For future manipulations of this sort, working in `init/` where there
are fuller memory-management facilities, access to richer C calls,
in-built command-line parsing, as well as a console to be able to
more easily trace and understand execution flow.


Jeff



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

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Petr Štetiar]

Etienne Champetier  [2019-03-15 10:46:09]:

Hi,

> Just a side note, on first boot we save a random seed using getrandom()
> https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/init.d/urandom_seed
> https://github.com/openwrt/openwrt/blob/master/package/base-files/files/sbin/urandom_seed
> 
> And we restore it in preinit
> https://github.com/openwrt/openwrt/blob/master/package/base-files/files/lib/preinit/81_urandom_seed

Well, it seems like we're writing the /etc/urandom.seed to the /dev/urandom
which doesn't help with initialization of CRNG, just seeding the /dev/urandom.

> So even if kernel PRNG is considered not initialized, in reality it
> is, so starting from second boot we are ~ok

Nope, see bellow.

1st boot:

 [3.944674] urandom-seed: Seed file not found (/etc/urandom.seed)
 [   75.120166] random: fast init done
 [  140.917418] random: crng init done

2nd boot:

 [3.938414] urandom-seed: Seeding with /etc/urandom.seed
 [   22.440981] random: fast init done
 [  135.737309] random: crng init done

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Petr Štetiar]

Kristian Evensen  [2019-03-15 13:57:41]:

Hi,

> I had a similar problem on some x86-devices.  The problem is that
> OpenWRT-devices are so "quiet" that it takes a while before a sufficient
> amount of entropy is generated.

I don't see it as problem of devices, I see it more as a problem of the
implementation of getrandom syscall in Linux kernel, musl libc (blocking
getentropy) and OpenSSL (blocking getrandom). I find it quite amusing, that
following:

 $ cat /etc/rc.local
 cat /dev/random &
 getrandom 1 | hexdump > /tmp/getrandom.log
 exit 0

would never finish booting on my QEMU machine.

> Instead of disabling the blocking getrandom()-call, what I did to "solve"
> the issue was to install the haveged-packet on devices where I could not
> find a driver for the hardware generator.

Or we can switch to systemd :-) Putting jokes aside, I'm not sure if we want
to add another dependency just because we've bumped OpenSSL.

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Etienne Champetier]

Hi All,

Le ven. 15 mars 2019 à 09:29, Petr Štetiar  a écrit :
>
> While testing simple firmware image for x86/64 in QEMU I've discovered
> some weird behavior today. This image contains simple package with
> simple init script to bootstrap the device UCI configuration from
> network server. This init script uses uclient-fetch and libustream-openssl.
>
> This image was booting fine until today, usually finished booting under
> 10s, but today it was booting much slowly, boot times were in range from
> 60s to a few minutes. I was also unable to power off the QEMU with
> poweroff command.
>
> I've found out, that it's all happening because of uclient-fetch being
> blocked in getrandom syscall, leading for example to following:
>
>  root@OpenWrt:~# time uclient-fetch
>  ^CCommand terminated by signal 2
>  real   8m 31.08s
>
> The problem passes away after `random: crng init done` hits
> the system log, but this step can take ages in some cases (usually when there
> are more processes calling getrandom in parallel), but I couldn't get it
> under 60s on my QEMU machine. I've similar weird reports from users on
> MIPS devices as well.
>
>  [   13.786576] random: fast init done
>  ...
>  [  653.153740] random: crng init done
>
> I've bisected the problem down to the following commit (reverting it
> fixed the problem):
>
>   # first bad commit: [d872d00b2f] openssl: update to version 1.1.1a
>
> So this patch tries to fix this issue by making getrandom syscall
> nonblocking, and also removes possible usage of getentropy libc call,
> which in case of musl libc results again in use of getrandom syscall in
> blocking mode.
>
> I've also added new config option just in case someone would prefer to
> have probably safer but much slower boot times on some devices.

Just a side note, on first boot we save a random seed using getrandom()
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/init.d/urandom_seed
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/sbin/urandom_seed

And we restore it in preinit
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/lib/preinit/81_urandom_seed

So even if kernel PRNG is considered not initialized, in reality it
is, so starting from second boot we are ~ok

I'm not sure if we block on getrandom to generate ssh keys (and any
other keys) on first boot though

Regards
Etienne

>
> Fixes: d872d00b2f ("openssl: update to version 1.1.1a")
> Reviewed-by: Eneas U de Queiroz 
> Signed-off-by: Petr Štetiar 
> ---
>  package/libs/openssl/Config.in | 12 ++
>  package/libs/openssl/Makefile  |  7 +++-
>  .../openssl/patches/150-unblock-getrandom.patch| 45 
> ++
>  3 files changed, 63 insertions(+), 1 deletion(-)
>  create mode 100644 package/libs/openssl/patches/150-unblock-getrandom.patch
>
> diff --git a/package/libs/openssl/Config.in b/package/libs/openssl/Config.in
> index ecb9eea..0809afa 100644
> --- a/package/libs/openssl/Config.in
> +++ b/package/libs/openssl/Config.in
> @@ -70,6 +70,18 @@ config OPENSSL_WITH_ERROR_MESSAGES
> This option aids debugging, but increases package size and
> memory usage.
>
> +config OPENSSL_BLOCKING_GETRANDOM
> +   bool
> +   prompt "Enable back getrandom in blocking mode"
> +   help
> +   Enable back the default (upstream) blocking behavior.  By 
> default, when
> +   reading from the random source, getrandom() blocks if no 
> random bytes are
> +   available, and when reading from the urandom source, it 
> blocks if the entropy
> +   pool has not yet been initialized.
> +
> +   Please note, that turning this option on may affect the boot 
> time, which can
> +   in some cases take minutes.
> +
>  comment "Protocol Support"
>
>  config OPENSSL_WITH_TLS13
> diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
> index 56e95af..6e7a603 100644
> --- a/package/libs/openssl/Makefile
> +++ b/package/libs/openssl/Makefile
> @@ -11,7 +11,7 @@ PKG_NAME:=openssl
>  PKG_BASE:=1.1.1
>  PKG_BUGFIX:=b
>  PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
> -PKG_RELEASE:=3
> +PKG_RELEASE:=4
>  PKG_USE_MIPS16:=0
>  ENGINES_DIR=engines-1.1
>
> @@ -30,6 +30,7 @@ PKG_LICENSE:=OpenSSL
>  PKG_LICENSE_FILES:=LICENSE
>  PKG_CPE_ID:=cpe:/a:openssl:openssl
>  PKG_CONFIG_DEPENDS:= \
> +   CONFIG_OPENSSL_BLOCKING_GETRANDOM \
> CONFIG_OPENSSL_ENGINE \
> CONFIG_OPENSSL_ENGINE_BUILTIN \
> CONFIG_OPENSSL_ENGINE_BUILTIN_AFALG \
> @@ -327,6 +328,10 @@ ifdef CONFIG_i386
>endif
>  endif
>
> +ifdef CONFIG_OPENSSL_BLOCKING_GETRANDOM
> +  OPENSSL_OPTIONS += -DOPENSSL_BLOCKING_GETRANDOM
> +endif
> +
>  OPENSSL_TARGET:=linux-$(call qstrip,$(CONFIG_ARCH))-openwrt
>
>  STAMP_CONFIGURED := $(STAMP_CONFIGURED)_$(shell echo $(OPENSSL_OPTIONS) | 
> mkhash md5)
> diff --git 

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Kristian Evensen]

Hi,

On Fri, Mar 15, 2019 at 1:29 PM Petr Štetiar  wrote:
>
> While testing simple firmware image for x86/64 in QEMU I've discovered
> some weird behavior today. This image contains simple package with
> simple init script to bootstrap the device UCI configuration from
> network server. This init script uses uclient-fetch and libustream-openssl.
>
> This image was booting fine until today, usually finished booting under
> 10s, but today it was booting much slowly, boot times were in range from
> 60s to a few minutes. I was also unable to power off the QEMU with
> poweroff command.
>
> I've found out, that it's all happening because of uclient-fetch being
> blocked in getrandom syscall, leading for example to following:
>
>  root@OpenWrt:~# time uclient-fetch
>  ^CCommand terminated by signal 2
>  real   8m 31.08s
>
> The problem passes away after `random: crng init done` hits
> the system log, but this step can take ages in some cases (usually when there
> are more processes calling getrandom in parallel), but I couldn't get it
> under 60s on my QEMU machine. I've similar weird reports from users on
> MIPS devices as well.
>
>  [   13.786576] random: fast init done
>  ...
>  [  653.153740] random: crng init done
>
> I've bisected the problem down to the following commit (reverting it
> fixed the problem):
>
>   # first bad commit: [d872d00b2f] openssl: update to version 1.1.1a
>
> So this patch tries to fix this issue by making getrandom syscall
> nonblocking, and also removes possible usage of getentropy libc call,
> which in case of musl libc results again in use of getrandom syscall in
> blocking mode.
>
> I've also added new config option just in case someone would prefer to
> have probably safer but much slower boot times on some devices.

I  had a similar problem on some x86-devices. The problem is that
OpenWRT-devices are so "quiet" that it takes a while before a
sufficient amount of entropy is generated. Instead of disabling the
blocking getrandom()-call, what I did to "solve" the issue was to
install the haveged-packet on devices where I could not find a driver
for the hardware generator. haveged attempts to provide an
unpredictable random number generator, and I was able to get the crng
init down to a couple of sections. haveged apparently has/had some
issues with VMs (https://wiki.archlinux.org/index.php/Haveged), but
most of them seems to have been resolved.

BR,
Kristian

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

[OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Petr Štetiar]

While testing simple firmware image for x86/64 in QEMU I've discovered
some weird behavior today. This image contains simple package with
simple init script to bootstrap the device UCI configuration from
network server. This init script uses uclient-fetch and libustream-openssl.

This image was booting fine until today, usually finished booting under
10s, but today it was booting much slowly, boot times were in range from
60s to a few minutes. I was also unable to power off the QEMU with
poweroff command.

I've found out, that it's all happening because of uclient-fetch being
blocked in getrandom syscall, leading for example to following:

 root@OpenWrt:~# time uclient-fetch
 ^CCommand terminated by signal 2
 real   8m 31.08s

The problem passes away after `random: crng init done` hits
the system log, but this step can take ages in some cases (usually when there
are more processes calling getrandom in parallel), but I couldn't get it
under 60s on my QEMU machine. I've similar weird reports from users on
MIPS devices as well.

 [   13.786576] random: fast init done
 ...
 [  653.153740] random: crng init done

I've bisected the problem down to the following commit (reverting it
fixed the problem):

  # first bad commit: [d872d00b2f] openssl: update to version 1.1.1a

So this patch tries to fix this issue by making getrandom syscall
nonblocking, and also removes possible usage of getentropy libc call,
which in case of musl libc results again in use of getrandom syscall in
blocking mode.

I've also added new config option just in case someone would prefer to
have probably safer but much slower boot times on some devices.

Fixes: d872d00b2f ("openssl: update to version 1.1.1a")
Reviewed-by: Eneas U de Queiroz 
Signed-off-by: Petr Štetiar 
---
 package/libs/openssl/Config.in | 12 ++
 package/libs/openssl/Makefile  |  7 +++-
 .../openssl/patches/150-unblock-getrandom.patch| 45 ++
 3 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 package/libs/openssl/patches/150-unblock-getrandom.patch

diff --git a/package/libs/openssl/Config.in b/package/libs/openssl/Config.in
index ecb9eea..0809afa 100644
--- a/package/libs/openssl/Config.in
+++ b/package/libs/openssl/Config.in
@@ -70,6 +70,18 @@ config OPENSSL_WITH_ERROR_MESSAGES
This option aids debugging, but increases package size and
memory usage.
 
+config OPENSSL_BLOCKING_GETRANDOM
+   bool
+   prompt "Enable back getrandom in blocking mode"
+   help
+   Enable back the default (upstream) blocking behavior.  By 
default, when
+   reading from the random source, getrandom() blocks if no random 
bytes are
+   available, and when reading from the urandom source, it blocks 
if the entropy
+   pool has not yet been initialized.
+
+   Please note, that turning this option on may affect the boot 
time, which can
+   in some cases take minutes.
+
 comment "Protocol Support"
 
 config OPENSSL_WITH_TLS13
diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 56e95af..6e7a603 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -11,7 +11,7 @@ PKG_NAME:=openssl
 PKG_BASE:=1.1.1
 PKG_BUGFIX:=b
 PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 PKG_USE_MIPS16:=0
 ENGINES_DIR=engines-1.1
 
@@ -30,6 +30,7 @@ PKG_LICENSE:=OpenSSL
 PKG_LICENSE_FILES:=LICENSE
 PKG_CPE_ID:=cpe:/a:openssl:openssl
 PKG_CONFIG_DEPENDS:= \
+   CONFIG_OPENSSL_BLOCKING_GETRANDOM \
CONFIG_OPENSSL_ENGINE \
CONFIG_OPENSSL_ENGINE_BUILTIN \
CONFIG_OPENSSL_ENGINE_BUILTIN_AFALG \
@@ -327,6 +328,10 @@ ifdef CONFIG_i386
   endif
 endif
 
+ifdef CONFIG_OPENSSL_BLOCKING_GETRANDOM
+  OPENSSL_OPTIONS += -DOPENSSL_BLOCKING_GETRANDOM
+endif
+
 OPENSSL_TARGET:=linux-$(call qstrip,$(CONFIG_ARCH))-openwrt
 
 STAMP_CONFIGURED := $(STAMP_CONFIGURED)_$(shell echo $(OPENSSL_OPTIONS) | 
mkhash md5)
diff --git a/package/libs/openssl/patches/150-unblock-getrandom.patch 
b/package/libs/openssl/patches/150-unblock-getrandom.patch
new file mode 100644
index 000..f74abaa
--- /dev/null
+++ b/package/libs/openssl/patches/150-unblock-getrandom.patch
@@ -0,0 +1,45 @@
+--- a/crypto/rand/rand_unix.c
 b/crypto/rand/rand_unix.c
+@@ -20,6 +20,7 @@
+ #include "internal/dso.h"
+ #if defined(__linux)
+ # include 
++# include 
+ #endif
+ #if defined(__FreeBSD__)
+ # include 
+@@ -292,7 +293,8 @@ static ssize_t syscall_random(void *buf,
+  */
+ 
+ /*
+- * Do runtime detection to find getentropy().
++ * Do runtime detection to find getentropy(). Please note, that at least
++ * on musl libc (version 1.2.21) getentropy() uses getrandom() in 
blocking mode.
+  *
+  * Known OSs that should support this:
+  * - Darwin since 16 (OSX 10.12, IOS 10.0).
+@@ -301,6 +303,7 @@ static ssize_t syscall_random(void *buf,
+  * 

Re: [OpenWrt-Devel] [PATCH 1/3] ramips: ethernet: Replace alloc_etherdev with devm variant

[Paul Oranje]

> Op 13 mrt. 2019, om 22:05 heeft Rosen Penev  het volgende 
> geschreven:
> 
> Allows simplifying the code slightly.
> 
> Also get rid of devm_iounmap as it is not necessary.
> 
> Tested on GnuBee PC1.
> 
> Signed-off-by: Rosen Penev 
> ---
> .../net/ethernet/mediatek/mtk_eth_soc.c   | 38 ++-
> 1 file changed, 11 insertions(+), 27 deletions(-)
> 
> diff --git 
> a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 2e0c8f94ca..d110787731 100644
> --- 
> a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ 
> b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -1559,16 +1559,13 @@ static int fe_probe(struct platform_device *pdev)
>   soc->reg_table = fe_reg_table;
> 
>   fe_base = devm_ioremap_resource(>dev, res);
> - if (IS_ERR(fe_base)) {
> - err = -EADDRNOTAVAIL;
> - goto err_out;
> - }
> + if (IS_ERR(fe_base))
> +  return PTR_ERR(fe_base);
> 
> - netdev = alloc_etherdev(sizeof(*priv));
> + netdev = devm_alloc_etherdev(>dev, sizeof(*priv));
>   if (!netdev) {
> - dev_err(>dev, "alloc_etherdev failed\n");
> - err = -ENOMEM;
> - goto err_iounmap;
> + dev_err(>dev, "devm_alloc_etherdev failed\n");
> + return -ENOMEM;
>   }
> 
>   SET_NETDEV_DEV(netdev, >dev);
> @@ -1578,8 +1575,7 @@ static int fe_probe(struct platform_device *pdev)
>   netdev->irq = platform_get_irq(pdev, 0);
>   if (netdev->irq < 0) {
>   dev_err(>dev, "no IRQ resource found\n");
> - err = -ENXIO;
> - goto err_free_dev;
> + return -ENXIO;
>   }
> 
>   if (soc->init_data)
> @@ -1598,10 +1594,8 @@ static int fe_probe(struct platform_device *pdev)
>   spin_lock_init(>page_lock);
>   if (fe_reg_table[FE_REG_FE_COUNTER_BASE]) {
>   priv->hw_stats = kzalloc(sizeof(*priv->hw_stats), GFP_KERNEL);
> - if (!priv->hw_stats) {
> - err = -ENOMEM;
> - goto err_free_dev;
> - }
> + if (!priv->hw_stats)
> + return -ENOMEM;
>   spin_lock_init(>hw_stats->stats_lock);
>   }
> 
> @@ -1610,15 +1604,13 @@ static int fe_probe(struct platform_device *pdev)
>   priv->sysclk = clk_get_rate(sysclk);
>   } else if ((priv->flags & FE_FLAG_CALIBRATE_CLK)) {
>   dev_err(>dev, "this soc needs a clk for calibration\n");
> - err = -ENXIO;
> - goto err_free_dev;
> + return -ENXIO;
>   }
> 
>   priv->switch_np = of_parse_phandle(pdev->dev.of_node, 
> "mediatek,switch", 0);
>   if ((priv->flags & FE_FLAG_HAS_SWITCH) && !priv->switch_np) {
>   dev_err(>dev, "failed to read switch phandle\n");
> - err = -ENODEV;
> - goto err_free_dev;
> + return -ENODEV;
>   }
> 
>   priv->netdev = netdev;
> @@ -1644,7 +1636,7 @@ static int fe_probe(struct platform_device *pdev)
>   err = register_netdev(netdev);
>   if (err) {
>   dev_err(>dev, "error bringing up device\n");
> - goto err_free_dev;
> + return err;
>   }
> 
>   platform_set_drvdata(pdev, netdev);
> @@ -1653,13 +1645,6 @@ static int fe_probe(struct platform_device *pdev)
>  netdev->base_addr, netdev->irq);
> 
>   return 0;
> -
> -err_free_dev:
> - free_netdev(netdev);
> -err_iounmap:
> - devm_iounmap(>dev, fe_base);
> -err_out:
> - return err;
> }
> 
> static int fe_remove(struct platform_device *pdev)
> @@ -1673,7 +1658,6 @@ static int fe_remove(struct platform_device *pdev)
>   cancel_work_sync(>pending_work);
> 
>   unregister_netdev(dev);
> - free_netdev(dev);
>   platform_set_drvdata(pdev, NULL);
> 
>   return 0;
> -- 
> 2.17.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

For some of the other architectures similar patches have been submitted [0].
Would an approach using Coccinelle be feasible ?

LWN ran an article on Coccinelle where "devmification" wqs given as an example 
[1].
Anyhow, interesting read, also because it shows a few caveats with 
devmification irrespective of using Coccinelle.

Also LWN features an 2007 article on devm [2].

[0] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a4eef43a120d51bb5386730b820704e5cb5e1acf
[1] https://lwn.net/Articles/698724/
[2] https://lwn.net/Articles/222860/

Regards,
Paul


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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for tplink tl-wdr3600 modified with 16M flash

[Chuanhong Guo]

Hi!
On Fri, Mar 15, 2019 at 2:42 PM Russell Senior
 wrote:
>
>
> To modify a WDR3600 with 16MB flash, you will need an external SPI programmer
> and soldering tools.  First, obtain a copy of the starting contents either 
> with
> the external programmer or from commands in OpenWrt:
Unfortunately OpenWrt never accepts device support requiring hardware
modifications.
I think part of the reason is that there are too many possible
variants when it comes to hardware modifications and all those
variants will make users confused.

Some maintainers talked about this problem in a past thread but I
can't find it now.

Regards,
Chuanhong Guo

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

[OpenWrt-Devel] script error in target-metadata.pl

[Koen Vandeputte]

Hi Daniel,

When running the image builder for my targets, I'm getting following error:


"Can't use an undefined value as an ARRAY reference at 
/mnt/ramdisk/koen/firmware/.21128/openwrt-imagebuilder-cns3xxx.Linux-x86_64/scripts/target-metadata.pl 
line 426."



It seems you made 2 changes last week on this script file:

d6fa04a43703 IB: include SUPPORTED_DEVICES in 'make info' output
13c379e5c6e3 ib: display whether profile comes with image metadata


Any idea what's causing this?


Thanks,

Koen


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

Re: [OpenWrt-Devel] WPJ428HV board - OpenWRT

[Sven Eckelmann]

On Thursday, 14 March 2019 22:39:54 CET Lloyed Emmanuel wrote:
[...]
> I have loaded  the following OpenWRT firmware to  WPJ428HV boards.
> 
> http://downloads.openwrt.org/releases/18.06.2/targets/ipq40xx/generic/openwrt-18.06.2-ipq40xx-compex_wpj428-squashfs-sysupgrade.bin
> 
> and I followed your steps in the following website
> 
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2796ab85ed5097d91623e60abf22325bd9086407
> 
> Everything is working fine but I am losing configuration when the board is 
> rebooted or restarted. What could be reasons for losing configurations?
> Any idea on how to fix this issue?

overlayfs could not be mounted or rootfs_data wasn't created in the first 
place.

You can solve it by figuring out why this wasn't done and then fix the 
underlying problem.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath79: add support for tplink tl-wdr3600 modified with 16M flash

[Russell Senior]

To modify a WDR3600 with 16MB flash, you will need an external SPI programmer
and soldering tools.  First, obtain a copy of the starting contents either with
the external programmer or from commands in OpenWrt:

 # dd if=/dev/mtdblock0 of=/tmp/uboot.img
 # dd if=/dev/mtdblock1 of=/tmp/firmware.img
 # dd if=/dev/mtdblock5 of=/tmp/art.img

Copy the files off the router.

In order to make clean reads/writes with the external SPI programmer, it
is helpful to hold the CPU in reset. To do this, solder a shunt across
R2 near the JTAG header so that a jumper between pin 10 and pin 11 of
the JTAG header can hold the RESET pin low. It is probabaly worth trying
out your external SPI programmer by reading a few copies before
desoldering the original flash part.

Desolder the SPI flash in the middle of the board. Solder on the new one,
noting the correct orientation.

Build the pepe2k u-boot for the WDR3600 (branch with support added):

 $ git clone https://github.com/RussellSenior/u-boot_mod/tree/add-wdr3600-16m
 $ make tp-link_tl-wdr3600_16m

Extract the novel bits from your original uboot.img, thusly:

 $ dd if=uboot.img of=macaddr.bin bs=1 skip=130048 count=6
 $ dd if=uboot.img of=model.bin bs=1 skip=130304 count=8
 $ dd if=uboot.img of=pin.bin bs=1 skip=130560 count=8
 $ dd if=/dev/zero bs=64k count=2 | tr '\000' '\377' > u-boot-new.img
 $ dd if=u-boot_mod.bin of=u-boot-new.img conv=notrunc
 $ dd if=macaddr.bin of=u-boot-new.img bs=1 count=6 seek=130048 conv=notrunc
 $ dd if=model.bin of=u-boot-new.img bs=1 count=8 seek=130304 conv=notrunc
 $ dd if=pin.bin of=u-boot-new.img bs=1 count=8 seek=130560 conv=notrunc

where u-boot_mod.bin is the u-boot image built using the pepe2k tree with
patches for the 16MB flash size.

Compose a new 16MB image:

 $ dd if=/dev/zero bs=1M count=16 | tr '\000' '\377' > 16MB-new.img
 $ dd if=u-boot-new.img of=16MB-new.img conv=notrunc
 $ dd if=openwrt-ath79-generic-tplink_tl-wdr3600-16m-squashfs-sysupgrade.bin 
of=16MB-new.img bs=64k seek=2 conv=notrunc
 $ dd if=art.bin of=16MB-new.img bs=64k seek=255 conv=notrunc

Then, use your external SPI flash programmer to write 16MB-new.img to the new
flash part.

Signed-off-by: Russell Senior 
---
 .../ath79/base-files/etc/board.d/02_network   |  1 +
 .../etc/hotplug.d/firmware/10-ath9k-eeprom|  1 +
 .../dts/ar9344_tplink_tl-wdr3600-16m.dts  | 46 +++
 target/linux/ath79/image/generic-tp-link.mk   | 10 
 4 files changed, 58 insertions(+)
 create mode 100644 target/linux/ath79/dts/ar9344_tplink_tl-wdr3600-16m.dts

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index e66eb938fd..5701372ed5 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -170,6 +170,7 @@ ath79_setup_interfaces()
tplink,archer-c7-v4|\
tplink,archer-c7-v5|\
tplink,tl-wdr3600|\
+   tplink,tl-wdr3600-16m|\
tplink,tl-wdr4300)
ucidef_add_switch "switch0" \
"0@eth0" "2:lan:1" "3:lan:2" "4:lan:3" "5:lan:4" "1:wan"
diff --git 
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom 
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 84e4d07b35..40ea3f3a42 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -146,6 +146,7 @@ case "$FIRMWARE" in
;;
ocedo,raccoon|\
tplink,tl-wdr3600|\
+   tplink,tl-wdr3600-16m|\
tplink,tl-wdr4300|\
tplink,tl-wdr4900-v2|\
winchannel,wb2000)
diff --git a/target/linux/ath79/dts/ar9344_tplink_tl-wdr3600-16m.dts 
b/target/linux/ath79/dts/ar9344_tplink_tl-wdr3600-16m.dts
new file mode 100644
index 00..ca8fd077e3
--- /dev/null
+++ b/target/linux/ath79/dts/ar9344_tplink_tl-wdr3600-16m.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar9344_tplink_tl-wdr4300.dtsi"
+
+/ {
+   model = "TP-Link WDR3600 16M";
+   compatible = "tplink,tl-wdr3600-16m", "qca,ar9344";
+};
+
+ {
+   num-cs = <1>;
+
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2500>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   uboot: partition@0 {
+   label = "u-boot";
+   reg = <0x00 0x02>;
+   read-only;
+   };
+
+   partition@2 {
+   compatible = "tplink,firmware";
+   label = "firmware";
+   reg