[OpenWrt-Devel] [PATCH] mt7621: add two extra pcie patches

2020-04-17 Thread Rosen Penev
These fix behavior with several devices where pcie0 is not connected.

Funny enough, these commits actually revert behavior to the original
driver.

Signed-off-by: Rosen Penev 
---
 target/linux/ramips/dts/mt7621.dtsi   |   9 +-
 ...perly-power-off-dual-ported-pcie-phy.patch |  70 
 ...t7621-pci-fix-pcie-interrupt-mapping.patch | 161 ++
 3 files changed, 235 insertions(+), 5 deletions(-)
 create mode 100644 
target/linux/ramips/patches-5.4/0120-staging-mt7621-pci-properly-power-off-dual-ported-pcie-phy.patch
 create mode 100644 
target/linux/ramips/patches-5.4/0121-staging-mt7621-pci-fix-pcie-interrupt-mapping.patch

diff --git a/target/linux/ramips/dts/mt7621.dtsi 
b/target/linux/ramips/dts/mt7621.dtsi
index 63befa1fdc..78979dc420 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -568,11 +568,10 @@
0x0100 0 0x 0x1e16 0 0x0001 /* io 
space */
>;
 
-   #interrupt-cells = <1>;
-   interrupt-map-mask = <0xF 0 0 1>;
-   interrupt-map = <0x1 0 0 1  GIC_SHARED 4 
IRQ_TYPE_LEVEL_HIGH>,
-   <0x2 0 0 1  GIC_SHARED 24 
IRQ_TYPE_LEVEL_HIGH>,
-   <0x3 0 0 1  GIC_SHARED 25 
IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-parent = <>;
+   interrupts = ;
 
status = "disabled";
 
diff --git 
a/target/linux/ramips/patches-5.4/0120-staging-mt7621-pci-properly-power-off-dual-ported-pcie-phy.patch
 
b/target/linux/ramips/patches-5.4/0120-staging-mt7621-pci-properly-power-off-dual-ported-pcie-phy.patch
new file mode 100644
index 00..22a5181bec
--- /dev/null
+++ 
b/target/linux/ramips/patches-5.4/0120-staging-mt7621-pci-properly-power-off-dual-ported-pcie-phy.patch
@@ -0,0 +1,70 @@
+From 5fcded5e857cf66c9592e4be28c4dab4520c9177 Mon Sep 17 00:00:00 2001
+From: Sergio Paracuellos 
+Date: Thu, 9 Apr 2020 13:16:52 +0200
+Subject: [PATCH] staging: mt7621-pci: properly power off dual-ported pcie phy
+
+Pcie phy for pcie0 and pcie1 is shared using a dual ported
+one. Current code was assuming that if nothing is connected
+in pcie0 it won't be also nothing connected in pcie1. This
+assumtion is wrong for some devices such us 'Mikrotik rbm33g'
+and 'ZyXEL LTE3301-PLUS' where only connecting a card to the
+second bus on the phy is possible. For such devices kernel
+hangs in the same point because of the wrong poweroff of the
+phy getting the following trace:
+
+mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1)
+mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0)
+mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
+mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
+mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK)
+[hangs]
+
+The wrong assumption is located in the 'mt7621_pcie_init_ports'
+function where we are just making a power off of the phy for
+slots 0 and 2 if nothing is connected in them. Hence, only
+poweroff the phy if nothing is connected in both slot 0 and
+slot 1 avoiding the kernel to hang.
+
+Fixes: 5737cfe87a9c ("staging: mt7621-pci: avoid to poweroff the phy for slot 
one")
+Signed-off-by: Sergio Paracuellos 
+Link: 
https://lore.kernel.org/r/20200409111652.30964-1-sergio.paracuel...@gmail.com
+Signed-off-by: Greg Kroah-Hartman 
+---
+ drivers/staging/mt7621-pci/pci-mt7621.c | 12 ++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
+index f58e3a51fc71..b9d460a9c041 100644
+--- a/drivers/staging/mt7621-pci/pci-mt7621.c
 b/drivers/staging/mt7621-pci/pci-mt7621.c
+@@ -502,17 +502,25 @@ static void mt7621_pcie_init_ports(struct mt7621_pcie 
*pcie)
+ 
+   mt7621_pcie_reset_ep_deassert(pcie);
+ 
++  tmp = NULL;
+   list_for_each_entry(port, >ports, list) {
+   u32 slot = port->slot;
+ 
+   if (!mt7621_pcie_port_is_linkup(port)) {
+   dev_err(dev, "pcie%d no card, disable it (RST & CLK)\n",
+   slot);
+-  if (slot != 1)
+-  phy_power_off(port->phy);
+   mt7621_control_assert(port);
+   mt7621_pcie_port_clk_disable(port);
+   port->enabled = false;
++
++  if (slot == 0) {
++  tmp = port;
++  continue;
++  }
++
++  if (slot == 1 && tmp && !tmp->enabled)
++  phy_power_off(tmp->phy);
++
+   }
+   }
+ }
+-- 
+2.25.2
+
diff --git 
a/target/linux/ramips/patches-5.4/0121-staging-mt7621-pci-fix-pcie-interrupt-mapping.patch
 
b/target/linux/ramips/patches-5.4/0121-staging-mt7621-pci-fix-pcie-interrupt-mapping.patch
new file mode 100644
index 

Re: [OpenWrt-Devel] [PATCH] prereq-build: test for perl's Data::Dumper

2020-04-17 Thread Rosen Penev
On Sun, Mar 29, 2020 at 6:13 PM Rosen Penev  wrote:
>
> Required for installation of autoconf:
>
> make[5]: Entering directory `/openwrt/build_dir/host/autoconf-2.69'
> Making all in bin
> make[6]: Entering directory `/openwrt/build_dir/host/autoconf-2.69/bin'
> autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
> ../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache
>  '' --melt ./autoconf.as -o autoconf.in
>
> Can't locate Data/Dumper.pm in @INC (@INC contains: ../lib
> /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
> /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
> ../lib/Autom4te/C4che.pm line 33.
> BEGIN failed--compilation aborted at ../lib/Autom4te/C4che.pm line 33.
> Compilation failed in require at ../bin/autom4te line 40.
> BEGIN failed--compilation aborted at ../bin/autom4te line 40.
> make[6]: *** [autoconf.in] Error 2
ping. I know most people do not encounter this issue as they have
autotools installed, but it is needed when autotools are missing on
the host.

I ran into this issue with a fairly barebones CentOS VM.
>
> Signed-off-by: Rosen Penev 
> ---
>  include/prereq-build.mk | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/prereq-build.mk b/include/prereq-build.mk
> index 830a9eff9a..71d8c3c8e7 100644
> --- a/include/prereq-build.mk
> +++ b/include/prereq-build.mk
> @@ -62,6 +62,10 @@ else
>zlib_link_flags := -lz
>  endif
>
> +$(eval $(call TestHostCommand,perl-data-dumper, \
> +   Please install the Perl Data::Dumper module, \
> +   perl -MData::Dumper -e 1))
> +
>  $(eval $(call TestHostCommand,perl-thread-queue, \
> Please install the Perl Thread::Queue module, \
> perl -MThread::Queue -e 1))
> --
> 2.25.1
>

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


Re: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck

2020-04-17 Thread Rosen Penev
On Fri, Apr 17, 2020 at 1:50 AM  wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Rosen Penev
> > Sent: Mittwoch, 15. April 2020 01:37
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck
> >
> > Warnings fixed:
> >
> > SC2004: $/${} is unnecessary on arithmetic variables.
> > SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
> > SC2086: Double quote to prevent globbing and word splitting.
> >
> > Removed most usages of ${} with $. There's no need for it. ${} is mainly
> > useful with substrings and arrays, which are not used here.
> >
> > Signed-off-by: Rosen Penev 
> > ---
> >  v3: Added quoting fixes.
> >  v2: Fixed mistake with executing PIDCOUNT.
> >  package/system/ubox/Makefile   |  2 +-
> >  package/system/ubox/files/log.init | 32 +++---
> >  2 files changed, 17 insertions(+), 17 deletions(-)
> >
> > diff --git a/package/system/ubox/Makefile
> > b/package/system/ubox/Makefile index cfa0b594e4..3970a4fc9c 100644
> > --- a/package/system/ubox/Makefile
> > +++ b/package/system/ubox/Makefile
> > @@ -1,7 +1,7 @@
> >  include $(TOPDIR)/rules.mk
> >
> >  PKG_NAME:=ubox
> > -PKG_RELEASE:=3
> > +PKG_RELEASE:=4
> >
> >  PKG_SOURCE_PROTO:=git
> >  PKG_SOURCE_URL=$(PROJECT_GIT)/project/ubox.git
> > diff --git a/package/system/ubox/files/log.init
> > b/package/system/ubox/files/log.init
> > index 250f805b44..4873a24472 100644
> > --- a/package/system/ubox/files/log.init
> > +++ b/package/system/ubox/files/log.init
> > @@ -32,19 +32,19 @@ validate_log_daemon()
> >
> >  start_service_daemon()
> >  {
> > - [ $log_buffer_size -eq 0 -a $log_size -gt 0 ] &&
> > log_buffer_size=$log_size
> > - [ $log_buffer_size -eq 0 ] && log_buffer_size=64
> > + [ "$log_buffer_size" -eq 0 ] && [ "$log_size" -gt 0 ] &&
>
> I'm never sure whether a comparison [ "$string" -eq 0 ], i.e. one with quotes 
> and one without using -eq works as expected in all cases.
> I typically use [ "$string" = "0" ] instead, but I'm not sure whether that's 
> effectively just the same.
Sounds bogus. log_buffer_size and log_size are stated to be uintegers above.
>
> Rest seems fine, despite some similar cases with -eq/-ne below.
-eq/-ne vs = is a stylistic difference.
>
> Best
>
> Adrian
>
> > log_buffer_size="$log_size"
> > + [ "$log_buffer_size" -eq 0 ] && log_buffer_size=64
> >   procd_open_instance
> >   procd_set_param command "/sbin/logd"
> > - procd_append_param command -S "${log_buffer_size}"
> > + procd_append_param command -S "$log_buffer_size"
> >   procd_set_param respawn 5 1 -1
> >   procd_close_instance
> >  }
> >
> >  start_service_file()
> >  {
> > - PIDCOUNT="$(( ${PIDCOUNT} + 1))"
> > - local pid_file="/var/run/logread.${PIDCOUNT}.pid"
> > + PIDCOUNT=$((PIDCOUNT + 1))
> > + local pid_file="/var/run/logread.$PIDCOUNT.pid"
> >
> >   [ "$2" = 0 ] || {
> >   echo "validation failed"
> > @@ -52,34 +52,34 @@ start_service_file()
> >   }
> >   [ -z "${log_file}" ] && return
> >
> > - mkdir -p "$(dirname "${log_file}")"
> > + mkdir -p "$(dirname "$log_file")"
> >
> >   procd_open_instance
> >   procd_set_param command "$PROG" -f -F "$log_file" -p "$pid_file"
> > - [ -n "${log_size}" ] && procd_append_param command -S "$log_size"
> > + [ -n "$log_size" ] && procd_append_param command -S "$log_size"
> >   procd_close_instance
> >  }
> >
> >  start_service_remote()
> >  {
> > - PIDCOUNT="$(( ${PIDCOUNT} + 1))"
> > - local pid_file="/var/run/logread.${PIDCOUNT}.pid"
> > + PIDCOUNT=$((PIDCOUNT + 1))
> > + local pid_file="/var/run/logread.$PIDCOUNT.pid"
> >
> >   [ "$2" = 0 ] || {
> >   echo "validation failed"
> >   return 1
> >   }
> > - [ "${log_remote}" -ne 0 ] || return
> > - [ -z "${log_ip}" ] && return
> > - [ -z "${log_hostname}" ] && log_hostname=$(cat
> > /proc/sys/kernel/hostname)
> > + [ "$log_remote" -ne 0 ] || return
> > + [ -z "$log_ip" ] && return
> > + [ -z "$log_hostname" ] && log_hostname=$(cat
> > +/proc/sys/kernel/hostname)
> >
> >   procd_open_instance
> > - procd_set_param command "$PROG" -f -h "$log_hostname" -r
> > "$log_ip" "${log_port}" -p "$pid_file"
> > - case "${log_proto}" in
> > + procd_set_param command "$PROG" -f -h "$log_hostname" -r
> > "$log_ip" "$log_port" -p "$pid_file"
> > + case "$log_proto" in
> >   "udp") procd_append_param command -u;;
> > - "tcp") [ "${log_trailer_null}" -eq 1 ] && procd_append_param
> > command -0;;
> > + "tcp") [ "$log_trailer_null" -eq 1 ] && procd_append_param
> > command
> > +-0;;
> >   esac
> > - [ -z "${log_prefix}" ] || procd_append_param command -P
> > "${log_prefix}"
> > + [ -z "$log_prefix" ] || procd_append_param command -P
> > 

[OpenWrt-Devel] [PATCH] build: show make output in scripts/config when V=s

2020-04-17 Thread Eneas U de Queiroz
This should make debugging build errors in scripts/config a bit easier.

Signed-off-by: Eneas U de Queiroz 

diff --git a/include/toplevel.mk b/include/toplevel.mk
index 2965f75c7c..ad8e5b8f20 100644
--- a/include/toplevel.mk
+++ b/include/toplevel.mk
@@ -104,7 +104,8 @@ scripts/config/%onf: export PATH:=$(dir 
$(DISTRO_PKG_CONFIG)):$(PATH)
 endif
 scripts/config/%onf: CFLAGS+= -O2
 scripts/config/%onf:
-   @$(_SINGLE)$(SUBMAKE) -s -C scripts/config $(notdir $@) 
CC="$(HOSTCC_WRAPPER)"
+   @$(_SINGLE)$(SUBMAKE) $(if $(findstring s,$(OPENWRT_VERBOSE)),,-s) \
+   -C scripts/config $(notdir $@) CC="$(HOSTCC_WRAPPER)"
 
 $(eval $(call rdep,scripts/config,scripts/config/mconf))
 

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


[OpenWrt-Devel] [PATCH] sdk: fix host menu config targets using ncurses

2020-04-17 Thread Eneas U de Queiroz
From: Petr Štetiar 

This applies 965f341aa9 ("build: fix host menu config targets using
ncurses") to the SDK top Makefile.

If there is a pkg-config in the staging dir, it will try to use it
instead of the host system's pkg-config; then it will fail to find the
ncurses package.  Linux's default will be used, which fails in some
cases, such as recent Gentoo systems.

CC: Petr Štetiar 
Signed-off-by: Eneas U de Queiroz 

diff --git a/target/sdk/files/Makefile b/target/sdk/files/Makefile
index 8df1904cb0..2f89ce0cf8 100644
--- a/target/sdk/files/Makefile
+++ b/target/sdk/files/Makefile
@@ -14,6 +14,7 @@ export TOPDIR LC_ALL LANG SDK
 
 world:
 
+DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -E '\/usr' | head -n 1)
 export PATH:=$(TOPDIR)/staging_dir/host/bin:$(PATH)
 
 ifneq ($(OPENWRT_BUILD),1)

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


[OpenWrt-Devel] [PATCH] openvpn: update to 2.4.9

2020-04-17 Thread Magnus Kroken
This is primarily a maintenance release with bugfixes and improvements.
This release also fixes a security issue (CVE-2020-11810) which allows
disrupting service of a freshly connected client that has not yet
negotiated session keys. The vulnerability cannot be used to
inject or steal VPN traffic.

Release announcement:
https://openvpn.net/community-downloads/#heading-13812
Full list of changes:
https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn24#OpenVPN2.4.9

Signed-off-by: Magnus Kroken 
---
Compile- and run-tested on arm.

Tests run: openvpn-mbedtls as server.

 package/network/services/openvpn/Makefile | 4 ++--
 .../patches/100-mbedtls-disable-runtime-version-check.patch   | 2 +-
 .../110-openssl-dont-use-deprecated-ssleay-symbols.patch  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/network/services/openvpn/Makefile 
b/package/network/services/openvpn/Makefile
index baa8c1d07e..5f102d967d 100644
--- a/package/network/services/openvpn/Makefile
+++ b/package/network/services/openvpn/Makefile
@@ -9,14 +9,14 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=openvpn
 
-PKG_VERSION:=2.4.8
+PKG_VERSION:=2.4.9
 PKG_RELEASE:=1
 
 PKG_SOURCE_URL:=\
https://build.openvpn.net/downloads/releases/ \
https://swupdate.openvpn.net/community/releases/
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
-PKG_HASH:=fb8ca66bb7807fff595fbdf2a0afd085c02a6aa47715c9aa3171002f9f1a3f91
+PKG_HASH:=641f3add8694b2ccc39fd4fd92554e4f089ad16a8db6d2b473ec284839a5ebe2
 
 PKG_MAINTAINER:=Felix Fietkau 
 
diff --git 
a/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
 
b/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
index 7fc0089000..cb16a906fe 100644
--- 
a/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
+++ 
b/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
@@ -1,6 +1,6 @@
 --- a/src/openvpn/ssl_mbedtls.c
 +++ b/src/openvpn/ssl_mbedtls.c
-@@ -1406,7 +1406,7 @@ const char *
+@@ -1415,7 +1415,7 @@ const char *
  get_ssl_library_version(void)
  {
  static char mbedtls_version[30];
diff --git 
a/package/network/services/openvpn/patches/110-openssl-dont-use-deprecated-ssleay-symbols.patch
 
b/package/network/services/openvpn/patches/110-openssl-dont-use-deprecated-ssleay-symbols.patch
index 7e9931f0f3..c7faf7c0c0 100644
--- 
a/package/network/services/openvpn/patches/110-openssl-dont-use-deprecated-ssleay-symbols.patch
+++ 
b/package/network/services/openvpn/patches/110-openssl-dont-use-deprecated-ssleay-symbols.patch
@@ -47,7 +47,7 @@ Signed-off-by: Gert Doering 
  #endif
 --- a/src/openvpn/ssl_openssl.c
 +++ b/src/openvpn/ssl_openssl.c
-@@ -1977,7 +1977,7 @@ get_highest_preference_tls_cipher(char *
+@@ -2008,7 +2008,7 @@ get_highest_preference_tls_cipher(char *
  const char *
  get_ssl_library_version(void)
  {
-- 
2.20.1


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


Re: [OpenWrt-Devel] Possible security issue

2020-04-17 Thread Wes Turner
>From a least privileges perspective:

- chmod o-rwx /var/run/hostapd-phyX.conf
- chmod o-x uci # setfacl?

Compromise of a service running as a different user should not result in
disclosure of sensitive keys only necessary for different services.

https://openwrt.org/docs/guide-user/security/security-features mentions
procd jail / chroot?

AFAIU, LXC is not available in the default kernel builds in any router? LXC
would be an additional layer of defenses over and above chroot, which isn't
seccomp

On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling  wrote:

> No. If you have physical access to the node and/or a valid login as Admin
> then any form of PSK is vulnerable.
>
> If you are concerned about PSK's being exposed then you have the option to
> run 802.1x auth and issue issues tokens out of radius/IDM that is secured
> elsewhere than on the AP itself.
>
> On Fri, 17 Apr 2020 at 20:16, e9hack  wrote:
>
>> Hi,
>>
>> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are
>> readable for everyone. This means everyone can read the wifi passwords. If
>> a non privileged user calls 'uci show wireless', he will also get all wifi
>> passwords. This possible e.g. for user nobody and dnsmasq.
>>
>> Is this a a security issue?
>>
>> Regards,
>> Hartmut
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] confirm d2759ee7f324c3be070a8979dccb1197ab3adb41

2020-04-17 Thread Lars Kruse
Am Sun, 12 Apr 2020 14:33:03 -0700
schrieb openwrt-devel-requ...@lists.openwrt.org:

> Your membership in the mailing list openwrt-devel has been disabled
> due to excessive bounces The last bounce received from you was dated
> 12-Apr-2020.  You will not get any more messages from this list until
> you re-enable your membership.  You will receive 3 more reminders like
> this before your membership in the list is deleted.
> 
> To re-enable your membership, you can simply respond to this message
> (leaving the Subject: line intact), or visit the confirmation page at
> 
> 
> http://lists.infradead.org/mailman/confirm/openwrt-devel/d2759ee7f324c3be070a8979dccb1197ab3adb41
> 
> 
> You can also visit your membership page at
> 
> 
> http://lists.infradead.org/mailman/options/openwrt-devel/lists%40sumpfralle.de
> 
> 
> On your membership page, you can change various delivery options such
> as your email address and whether you get digests or not.  As a
> reminder, your membership password is
> 
> niuwikan
> 
> If you have any questions or problems, you can contact the list owner
> at
> 
> openwrt-devel-ow...@lists.openwrt.org

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


Re: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck

2020-04-17 Thread Daniel Golle
On Fri, Apr 17, 2020 at 10:50:32AM +0200, m...@adrianschmutzler.de wrote:
> Hi,
> 
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Rosen Penev
> > Sent: Mittwoch, 15. April 2020 01:37
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck
> > 
> > Warnings fixed:
> > 
> > SC2004: $/${} is unnecessary on arithmetic variables.
> > SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
> > SC2086: Double quote to prevent globbing and word splitting.
> > 
> > Removed most usages of ${} with $. There's no need for it. ${} is mainly
> > useful with substrings and arrays, which are not used here.
> > 
> > Signed-off-by: Rosen Penev 
> > ---
> >  v3: Added quoting fixes.
> >  v2: Fixed mistake with executing PIDCOUNT.
> >  package/system/ubox/Makefile   |  2 +-
> >  package/system/ubox/files/log.init | 32 +++---
> >  2 files changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/package/system/ubox/Makefile
> > b/package/system/ubox/Makefile index cfa0b594e4..3970a4fc9c 100644
> > --- a/package/system/ubox/Makefile
> > +++ b/package/system/ubox/Makefile
> > @@ -1,7 +1,7 @@
> >  include $(TOPDIR)/rules.mk
> > 
> >  PKG_NAME:=ubox
> > -PKG_RELEASE:=3
> > +PKG_RELEASE:=4
> > 
> >  PKG_SOURCE_PROTO:=git
> >  PKG_SOURCE_URL=$(PROJECT_GIT)/project/ubox.git
> > diff --git a/package/system/ubox/files/log.init
> > b/package/system/ubox/files/log.init
> > index 250f805b44..4873a24472 100644
> > --- a/package/system/ubox/files/log.init
> > +++ b/package/system/ubox/files/log.init
> > @@ -32,19 +32,19 @@ validate_log_daemon()
> > 
> >  start_service_daemon()
> >  {
> > -   [ $log_buffer_size -eq 0 -a $log_size -gt 0 ] &&
> > log_buffer_size=$log_size
> > -   [ $log_buffer_size -eq 0 ] && log_buffer_size=64
> > +   [ "$log_buffer_size" -eq 0 ] && [ "$log_size" -gt 0 ] &&
> 
> I'm never sure whether a comparison [ "$string" -eq 0 ], i.e. one with quotes 
> and one without using -eq works as expected in all cases.
> I typically use [ "$string" = "0" ] instead, but I'm not sure whether that's 
> effectively just the same.

It's not:
i="0 -eq 0 -o 1"

[ $i -eq 1 ] && echo 1
1

[ "$i" -eq 0 ] && echo 1
bash: [: 0 -eq 0 -o 0: integer expression expected

So as a general rule, it does make sense to use quotes.

> 
> Rest seems fine, despite some similar cases with -eq/-ne below.
> 
> Best
> 
> Adrian
> 
> > log_buffer_size="$log_size"
> > +   [ "$log_buffer_size" -eq 0 ] && log_buffer_size=64
> > procd_open_instance
> > procd_set_param command "/sbin/logd"
> > -   procd_append_param command -S "${log_buffer_size}"
> > +   procd_append_param command -S "$log_buffer_size"
> > procd_set_param respawn 5 1 -1
> > procd_close_instance
> >  }
> > 
> >  start_service_file()
> >  {
> > -   PIDCOUNT="$(( ${PIDCOUNT} + 1))"
> > -   local pid_file="/var/run/logread.${PIDCOUNT}.pid"
> > +   PIDCOUNT=$((PIDCOUNT + 1))
> > +   local pid_file="/var/run/logread.$PIDCOUNT.pid"
> > 
> > [ "$2" = 0 ] || {
> > echo "validation failed"
> > @@ -52,34 +52,34 @@ start_service_file()
> > }
> > [ -z "${log_file}" ] && return
> > 
> > -   mkdir -p "$(dirname "${log_file}")"
> > +   mkdir -p "$(dirname "$log_file")"
> > 
> > procd_open_instance
> > procd_set_param command "$PROG" -f -F "$log_file" -p "$pid_file"
> > -   [ -n "${log_size}" ] && procd_append_param command -S "$log_size"
> > +   [ -n "$log_size" ] && procd_append_param command -S "$log_size"
> > procd_close_instance
> >  }
> > 
> >  start_service_remote()
> >  {
> > -   PIDCOUNT="$(( ${PIDCOUNT} + 1))"
> > -   local pid_file="/var/run/logread.${PIDCOUNT}.pid"
> > +   PIDCOUNT=$((PIDCOUNT + 1))
> > +   local pid_file="/var/run/logread.$PIDCOUNT.pid"
> > 
> > [ "$2" = 0 ] || {
> > echo "validation failed"
> > return 1
> > }
> > -   [ "${log_remote}" -ne 0 ] || return
> > -   [ -z "${log_ip}" ] && return
> > -   [ -z "${log_hostname}" ] && log_hostname=$(cat
> > /proc/sys/kernel/hostname)
> > +   [ "$log_remote" -ne 0 ] || return
> > +   [ -z "$log_ip" ] && return
> > +   [ -z "$log_hostname" ] && log_hostname=$(cat
> > +/proc/sys/kernel/hostname)
> > 
> > procd_open_instance
> > -   procd_set_param command "$PROG" -f -h "$log_hostname" -r
> > "$log_ip" "${log_port}" -p "$pid_file"
> > -   case "${log_proto}" in
> > +   procd_set_param command "$PROG" -f -h "$log_hostname" -r
> > "$log_ip" "$log_port" -p "$pid_file"
> > +   case "$log_proto" in
> > "udp") procd_append_param command -u;;
> > -   "tcp") [ "${log_trailer_null}" -eq 1 ] && procd_append_param
> > command -0;;
> > +   "tcp") [ "$log_trailer_null" -eq 1 ] && procd_append_param
> > command
> > +-0;;
> > esac
> > -   [ -z "${log_prefix}" ] || procd_append_param command -P
> > "${log_prefix}"
> > +   [ -z "$log_prefix" ] || procd_append_param 

Re: [OpenWrt-Devel] Possible security issue

2020-04-17 Thread Joel Wirāmu Pauling
No. If you have physical access to the node and/or a valid login as Admin
then any form of PSK is vulnerable.

If you are concerned about PSK's being exposed then you have the option to
run 802.1x auth and issue issues tokens out of radius/IDM that is secured
elsewhere than on the AP itself.

On Fri, 17 Apr 2020 at 20:16, e9hack  wrote:

> Hi,
>
> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are
> readable for everyone. This means everyone can read the wifi passwords. If
> a non privileged user calls 'uci show wireless', he will also get all wifi
> passwords. This possible e.g. for user nobody and dnsmasq.
>
> Is this a a security issue?
>
> Regards,
> Hartmut
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck

2020-04-17 Thread mail
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rosen Penev
> Sent: Mittwoch, 15. April 2020 01:37
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck
> 
> Warnings fixed:
> 
> SC2004: $/${} is unnecessary on arithmetic variables.
> SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
> SC2086: Double quote to prevent globbing and word splitting.
> 
> Removed most usages of ${} with $. There's no need for it. ${} is mainly
> useful with substrings and arrays, which are not used here.
> 
> Signed-off-by: Rosen Penev 
> ---
>  v3: Added quoting fixes.
>  v2: Fixed mistake with executing PIDCOUNT.
>  package/system/ubox/Makefile   |  2 +-
>  package/system/ubox/files/log.init | 32 +++---
>  2 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/package/system/ubox/Makefile
> b/package/system/ubox/Makefile index cfa0b594e4..3970a4fc9c 100644
> --- a/package/system/ubox/Makefile
> +++ b/package/system/ubox/Makefile
> @@ -1,7 +1,7 @@
>  include $(TOPDIR)/rules.mk
> 
>  PKG_NAME:=ubox
> -PKG_RELEASE:=3
> +PKG_RELEASE:=4
> 
>  PKG_SOURCE_PROTO:=git
>  PKG_SOURCE_URL=$(PROJECT_GIT)/project/ubox.git
> diff --git a/package/system/ubox/files/log.init
> b/package/system/ubox/files/log.init
> index 250f805b44..4873a24472 100644
> --- a/package/system/ubox/files/log.init
> +++ b/package/system/ubox/files/log.init
> @@ -32,19 +32,19 @@ validate_log_daemon()
> 
>  start_service_daemon()
>  {
> - [ $log_buffer_size -eq 0 -a $log_size -gt 0 ] &&
> log_buffer_size=$log_size
> - [ $log_buffer_size -eq 0 ] && log_buffer_size=64
> + [ "$log_buffer_size" -eq 0 ] && [ "$log_size" -gt 0 ] &&

I'm never sure whether a comparison [ "$string" -eq 0 ], i.e. one with quotes 
and one without using -eq works as expected in all cases.
I typically use [ "$string" = "0" ] instead, but I'm not sure whether that's 
effectively just the same.

Rest seems fine, despite some similar cases with -eq/-ne below.

Best

Adrian

> log_buffer_size="$log_size"
> + [ "$log_buffer_size" -eq 0 ] && log_buffer_size=64
>   procd_open_instance
>   procd_set_param command "/sbin/logd"
> - procd_append_param command -S "${log_buffer_size}"
> + procd_append_param command -S "$log_buffer_size"
>   procd_set_param respawn 5 1 -1
>   procd_close_instance
>  }
> 
>  start_service_file()
>  {
> - PIDCOUNT="$(( ${PIDCOUNT} + 1))"
> - local pid_file="/var/run/logread.${PIDCOUNT}.pid"
> + PIDCOUNT=$((PIDCOUNT + 1))
> + local pid_file="/var/run/logread.$PIDCOUNT.pid"
> 
>   [ "$2" = 0 ] || {
>   echo "validation failed"
> @@ -52,34 +52,34 @@ start_service_file()
>   }
>   [ -z "${log_file}" ] && return
> 
> - mkdir -p "$(dirname "${log_file}")"
> + mkdir -p "$(dirname "$log_file")"
> 
>   procd_open_instance
>   procd_set_param command "$PROG" -f -F "$log_file" -p "$pid_file"
> - [ -n "${log_size}" ] && procd_append_param command -S "$log_size"
> + [ -n "$log_size" ] && procd_append_param command -S "$log_size"
>   procd_close_instance
>  }
> 
>  start_service_remote()
>  {
> - PIDCOUNT="$(( ${PIDCOUNT} + 1))"
> - local pid_file="/var/run/logread.${PIDCOUNT}.pid"
> + PIDCOUNT=$((PIDCOUNT + 1))
> + local pid_file="/var/run/logread.$PIDCOUNT.pid"
> 
>   [ "$2" = 0 ] || {
>   echo "validation failed"
>   return 1
>   }
> - [ "${log_remote}" -ne 0 ] || return
> - [ -z "${log_ip}" ] && return
> - [ -z "${log_hostname}" ] && log_hostname=$(cat
> /proc/sys/kernel/hostname)
> + [ "$log_remote" -ne 0 ] || return
> + [ -z "$log_ip" ] && return
> + [ -z "$log_hostname" ] && log_hostname=$(cat
> +/proc/sys/kernel/hostname)
> 
>   procd_open_instance
> - procd_set_param command "$PROG" -f -h "$log_hostname" -r
> "$log_ip" "${log_port}" -p "$pid_file"
> - case "${log_proto}" in
> + procd_set_param command "$PROG" -f -h "$log_hostname" -r
> "$log_ip" "$log_port" -p "$pid_file"
> + case "$log_proto" in
>   "udp") procd_append_param command -u;;
> - "tcp") [ "${log_trailer_null}" -eq 1 ] && procd_append_param
> command -0;;
> + "tcp") [ "$log_trailer_null" -eq 1 ] && procd_append_param
> command
> +-0;;
>   esac
> - [ -z "${log_prefix}" ] || procd_append_param command -P
> "${log_prefix}"
> + [ -z "$log_prefix" ] || procd_append_param command -P
> "$log_prefix"
>   procd_close_instance
>  }
> 
> --
> 2.25.2
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

[OpenWrt-Devel] Possible security issue

2020-04-17 Thread e9hack
Hi,

the configuration files for hostapd (/var/run/hostapd-phyX.conf) are readable 
for everyone. This means everyone can read the wifi passwords. If a non 
privileged user calls 'uci show wireless', he will also get all wifi passwords. 
This possible e.g. for user nobody and dnsmasq.

Is this a a security issue?

Regards,
Hartmut

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


[OpenWrt-Devel] [PATCH] mvebu: add support for GL.iNet GL-MV1000

2020-04-17 Thread Li Zhang
This patch adds supports for GL-MV1000.

Specification:
- SOC: Marvell Armada 88F3720 (1GHz)
- Flash: 16MB (W25Q128FWSIG)
- RAM: 1GB DDR4
- Ethernet: 3x GE (1 WAN + 2 LAN)
- EMMC: 8GB EMMC (KLM8G1GETF-B041)
- MicroSD: 1x microSD slot
- USB: 1x USB 2.0 port(TypeA),1x USB 3.0 port(TypeC)
- Button: 1x reset button,1x slide switch
- LED: 3x greed LED
- UART: 1x UART on PCB (JP1: 3.3V, RX, TX, GND)

Update firmware instructions

In the compiled,please gzip -d xxx.img.gz,then update firmware on uboot 
web.

Signed-off-by: Li Zhang 
---
 package/boot/uboot-envtools/files/mvebu|   3 +
 .../cortexa53/base-files/etc/board.d/02_network|   3 +-
 .../arm64/boot/dts/marvell/armada-gl-mv1000.dts| 165 +
 target/linux/mvebu/image/cortexa53.mk  |   9 ++
 4 files changed, 179 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-gl-mv1000.dts

diff --git a/package/boot/uboot-envtools/files/mvebu 
b/package/boot/uboot-envtools/files/mvebu
index 7902384..b883f0a 100644
--- a/package/boot/uboot-envtools/files/mvebu
+++ b/package/boot/uboot-envtools/files/mvebu
@@ -24,6 +24,9 @@ globalscale,espressobin-v7-emmc|\
 marvell,armada8040-mcbin)
ubootenv_add_uci_config "/dev/mtd0" "0x3f" "0x1" "0x1" "1"
;;
+glinet,gl-mv1000)
+   ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8000" "0x8000" "1"
+   ;;
 linksys,caiman|\
 linksys,cobra|\
 linksys,shelby)
diff --git a/target/linux/mvebu/cortexa53/base-files/etc/board.d/02_network 
b/target/linux/mvebu/cortexa53/base-files/etc/board.d/02_network
index ba4b930..9b1d97d 100755
--- a/target/linux/mvebu/cortexa53/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/cortexa53/base-files/etc/board.d/02_network
@@ -14,7 +14,8 @@ case "$board" in
 globalscale,espressobin|\
 globalscale,espressobin-emmc|\
 globalscale,espressobin-v7|\
-globalscale,espressobin-v7-emmc)
+globalscale,espressobin-v7-emmc|\
+glinet,gl-mv1000)
ucidef_set_interfaces_lan_wan "lan0 lan1" "wan"
;;
 marvell,armada-3720-db|\
diff --git 
a/target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-gl-mv1000.dts
 
b/target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-gl-mv1000.dts
new file mode 100644
index 000..9d7963c
--- /dev/null
+++ 
b/target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-gl-mv1000.dts
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for GL.iNet GL-MV1000
+ */
+
+/dts-v1/;
+#include 
+#include "armada-372x.dtsi"
+
+/ {
+   model = "GL.inet GL-MV1000";
+   compatible = "glinet,gl-mv1000", "marvell,armada3720";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x 0x 0x 0x2000>;
+   };
+
+   vcc_sd_reg1: regulator {
+   compatible = "regulator-gpio";
+   regulator-name = "vcc_sd1";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+
+   gpios-states = <0>;
+   states = <180 0x1
+   330 0x0>;
+   enable-active-high;
+   };
+};
+
+ {
+   status = "okay";
+
+   flash@0 {
+   reg = <0>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <10400>;
+   m25p,fast-read;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0 0xf>;
+   };
+
+   partition@f {
+   label = "u-boot-env";
+   reg = <0Xf 0x8000>;
+   };
+
+   factory: partition@f8000 {
+   label = "factory";
+   reg = <0xf8000 0x8000>;
+   };
+   };
+   };
+};
+
+ {
+   wp-inverted;
+   bus-width = <4>;
+   cd-gpios = < 17 GPIO_ACTIVE_LOW>;
+   marvell,pad-type = "sd";
+   no-1-8-v;
+   vqmmc-supply = <_sd_reg1>;
+   status = "okay";
+};
+
+ {
+   bus-width = <8>;
+   mmc-ddr-1_8v;
+   mmc-hs400-1_8v;
+   non-removable;
+   no-sd;
+   no-sdio;
+   marvell,pad-type = "fixed-1-8v";
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   switch0: switch0@1 {
+