Re: [rpcd PATCH 3/4] rc: add option to skip running check for list method

[Karl Palsson]

Christian Marangi  wrote:
> On Wed, Feb 01, 2023 at 10:50:24AM -0000, Karl Palsson wrote:
> > 
> > 
> > 
> > Christian Marangi  wrote:
> > > Running check may be slow and increase result time in the other
> > > of 70ms for the list method.
> > > 
> > > Add an option to skip running check by passing the
> > > skip_running_check as true in the list method args to speedup
> > > execution if the running info is not needed.
> > > 
> > > With the option set to true the execution time lower to just
> > > 5ms.
> > 
> > Can I ask what you're doing that you are calling ubus service
> > list so often that 70ms vs 5ms is meaningful? You're complicating
> > APIs and adding code for what seems wildly unnecessary?
> > 
> 
> I may have messed up the times...
> 
> But just compare yourselt...
> 
> time ubus call rc list
> 
> time ubus call luci getInitList
> 
> The difference is quite drammatic...
> 
> This series just allign the rc feature to the luci one and it's
> really not bloating, just adding feature... The added option
> are all optional.

Well, it certainly sounds like bloat when there's two services
doing the same thing :) Surely one of these needs to be removed?

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

Re: [rpcd PATCH 3/4] rc: add option to skip running check for list method

[Karl Palsson]

Christian Marangi  wrote:
> Running check may be slow and increase result time in the other
> of 70ms for the list method.
> 
> Add an option to skip running check by passing the
> skip_running_check as true in the list method args to speedup
> execution if the running info is not needed.
> 
> With the option set to true the execution time lower to just
> 5ms.

Can I ask what you're doing that you are calling ubus service
list so often that 70ms vs 5ms is meaningful? You're complicating
APIs and adding code for what seems wildly unnecessary?

Sincerely,
Karl Palsson

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

Re: [PATCH] libtasn1: CVE-2021-46848

[Karl Palsson]

This is superseded by
https://github.com/openwrt/packages/commit/b1d112c5d2a1bba095033a59a761f50216840a4e
anyway.

Peter Naulls  wrote:
> On 11/3/22 12:01, Etienne Champetier wrote:
> > Hi Peter,
> > 
> > Can you resend this as a proper patch ready to be applied ?
> > Or as a PR on Github if this is easier for you ?
> > 
> 
> Sorry, retry. I wasn't 100% sure of the filename setup for
> submitted patches. I've got a couple more to come.
> 

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

Re: Security changes - restricting uhttpd addresses

[Karl Palsson]

Peter Naulls  wrote:
> On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote:
> is much easier to let the firewall zones deal with that.
> > 
> >> As aside, they don't see the iptables tool in the system, and don't
> >> understand that that's been deprecated (although I since did add it
> >> for some unrelated legacy usage), and think there's no firewall at all.
> > 
> > 22.03? Did you read the release notes? nftables.
> 
> Luiz, I think you might have missed the context of my post -
> perhaps you missed my earlier ones. I'm well aware that
> nftables is in use, but this is in a security review, and they
> see what they want to see.

If they see what they want to see, then why should anyone else
get involved in their wish fulfilment?

Security review is fine, security should not be entertained, and
certainly foisted on other people?

Sincerely,
Karl Palsson

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

Re: [PATCH] packages: pagekitec: fix crashing due to musl time64

[Karl Palsson]

Classically, as a patch for a package, this should be filed here:
https://github.com/openwrt/packages/pulls

Ideally, even make the patch against upstream:
https://github.com/pagekite/libpagekite so they are involved and
can help with it going forward, especially for cases like this,
where it's not anything that's OpenWrt related.

I'll try and poke upstream about this personally too.

Sincerely,
Karl Palsson

l...@plan44.ch wrote:
> From: Lukas Zeller 
> 
> [Please note: this is my first attempt at submitting a patch,
> please apologize/advise if something is not as it should be. I
> tried to follow the guideline in the wiki]
> 
> upstream pagekitec/libpagekite is not compatible with
> musl>=1.2.0 time64 (time_t being 64 bit rather than 32 bit) due
> to several format strings using "%d" for a time_t parameter.
> 
> With time_t becoming 64bit, these (mostly log output) printfs
> display invalid numbers, or even crash when mixed with "%s"
> format specifiers.
> 
> Most prominently visible case is the "Tick!" message which
> causes any real world use of pagekitec/libpagekite crash
> immediately.
> 
> This patch now uses "%lld" with an explicit cast of the
> arguments to uint64_t. The cast ensures that the code is still
> safe to compile with 32 bit time_t (but introduces a slight
> performance penalty in that case).
> 
> Signed-off-by: Lukas Zeller 
> ---
>  net/pagekitec/patches/500-time64-fixes.patch | 70 
>  1 file changed, 70 insertions(+)
>  create mode 100644 net/pagekitec/patches/500-time64-fixes.patch
> 
> diff --git a/net/pagekitec/patches/500-time64-fixes.patch
> b/net/pagekitec/patches/500-time64-fixes.patch new file mode
> 100644 index 0..a052a16c4
> --- /dev/null
> +++ b/net/pagekitec/patches/500-time64-fixes.patch
> @@ -0,0 +1,70 @@
> +--- a/libpagekite/pklogging.c
>  b/libpagekite/pklogging.c
> +@@ -208,9 +208,9 @@ void pk_dump_conn(char* prefix, struct p
> +   if (conn->sockfd < 0) return;
> + 
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/sockfd: %d", prefix, conn->sockfd);
> +-  pk_log(PK_LOG_MANAGER_DEBUG, "%s/activity: %x (%ds ago)", prefix,
> +-   conn->activity,
> +-   pk_time(0) - conn->activity);
> ++  pk_log(PK_LOG_MANAGER_DEBUG, "%s/activity: %llx (%llds ago)", prefix,
> ++   (uint64_t)conn->activity,
> ++   (uint64_t)(pk_time(0) - conn->activity));
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/read_bytes: %d", prefix, 
> conn->read_bytes);
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/read_kb: %d", prefix, conn->read_kb);
> +   pk_log(PK_LOG_MANAGER_DEBUG, "%s/sent_kb: %d", prefix, conn->sent_kb);
> +@@ -281,8 +281,8 @@ void pk_dump_state(struct pk_manager* pk
> +   pk_log(LL, "pk_manager/kite_max: %d", pkm->kite_max);
> +   pk_log(LL, "pk_manager/tunnel_max: %d", pkm->tunnel_max);
> +   pk_log(LL, "pk_manager/be_conn_max: %d", pkm->be_conn_max);
> +-  pk_log(LL, "pk_manager/last_world_update: %x", pkm->last_world_update);
> +-  pk_log(LL, "pk_manager/next_tick: %d", pkm->next_tick);
> ++  pk_log(LL, "pk_manager/last_world_update: %llx", 
> (uint64_t)pkm->last_world_update);
> ++  pk_log(LL, "pk_manager/next_tick: %lld", (uint64_t)pkm->next_tick);
> +   pk_log(LL, "pk_manager/enable_timer: %d", 0 < pkm->enable_timer);
> +   pk_log(LL, "pk_manager/fancy_pagekite_net_rejection_url: %s", 
> pkm->fancy_pagekite_net_rejection_url);
> +   pk_log(LL, "pk_manager/want_spare_frontends: %d", 
> pkm->want_spare_frontends);
> +--- a/libpagekite/pkmanager.c
>  b/libpagekite/pkmanager.c
> +@@ -1070,8 +1070,8 @@ static void pkm_tick_cb(EV_P_ ev_async* 
> + pkm->timer.repeat = pkm->next_tick;
> + ev_timer_again(pkm->loop, &(pkm->timer));
> + pk_log(PK_LOG_MANAGER_INFO,
> +-   "Tick!  [repeating=%s, next=%d, status=%d, tunnels=%d, v=%s]",
> +-   pkm->enable_timer ? "yes" : "no", pkm->next_tick,
> ++   "Tick!  [repeating=%s, next=%lld, status=%d, tunnels=%d, v=%s]",
> ++   pkm->enable_timer ? "yes" : "no", (uint64_t)pkm->next_tick,
> +pkm->status, pk_state.live_tunnels, PK_VERSION);
> + 
> + /* We slow down exponentially by default... */
> +@@ -1122,8 +1122,8 @@ static void pkm_tick_cb(EV_P_ ev_async* 
> +   fe->last_ping = now;
> +   pkc_write(&(fe->conn), ping, pingsize);
> +   pk_log(P

Re: [iwinfo PATCH 1/2] iwinfo: add support for indoor only chan restriction

[Karl Palsson]

Ansuel Smith  wrote:
> Some country permit a specific channel to be used only indoor.
> Introduce a new restriction_flags entry to declare different
> restrition of a specific channel.
> 
> Signed-off-by: Ansuel Smith 
> ---
>  include/iwinfo.h |  4 
>  iwinfo_nl80211.c | 14 ++
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index 8469ee7..3543b91 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -61,6 +61,9 @@
>  #define IWINFO_FREQ_NO_160MHZ(1 << 5)
>  #define IWINFO_FREQ_NO_2160MHZ   (1 << 6)
>  
> +#define IWINFO_FREQ_NO_IR(1 << 0)
> +#define IWINFO_FREQ_NO_OUTDOOR   (2 << 0)

That's a pretty non-standard way of defining bits? Did you really
mean (1<<0) and (1<<1) ?

Sincerely,
Karl Palsson

> +
>  extern const char *IWINFO_CIPHER_NAMES[IWINFO_CIPHER_COUNT];
>  extern const char *IWINFO_KMGMT_NAMES[IWINFO_KMGMT_COUNT];
>  extern const char *IWINFO_AUTH_NAMES[IWINFO_AUTH_COUNT];
> @@ -168,6 +171,7 @@ struct iwinfo_freqlist_entry {
>   uint8_t channel;
>   uint32_t mhz;
>   uint8_t restricted;
> + uint32_t restricted_flags;
>   uint32_t flags;
>  };
>  
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index c4b0ee2..57f820a 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -2911,10 +2911,16 @@ static int nl80211_get_freqlist_cb(struct nl_msg 
> *msg, void *arg)
>   e->mhz = 
> nla_get_u32(freqs[NL80211_FREQUENCY_ATTR_FREQ]);
>   e->channel = 
> nl80211_freq2channel(e->mhz);
>  
> - e->restricted = (
> - 
> freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
> - 
> !freqs[NL80211_FREQUENCY_ATTR_RADAR]
> - ) ? 1 : 0;
> + e->restricted = 
> (freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
> +  
> !freqs[NL80211_FREQUENCY_ATTR_RADAR]) ||
> +  
> freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY];
> +
> + if (freqs[NL80211_FREQUENCY_ATTR_NO_IR] 
> &&
> + 
> !freqs[NL80211_FREQUENCY_ATTR_RADAR])
> + e->restricted_flags |= 
> IWINFO_FREQ_NO_IR;
> +
> + if 
> (freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY])
> + e->restricted_flags |= 
> IWINFO_FREQ_NO_OUTDOOR;
>  
>   if 
> (freqs[NL80211_FREQUENCY_ATTR_NO_HT40_MINUS])
>   e->flags |= 
> IWINFO_FREQ_NO_HT40MINUS;
> -- 
> 2.32.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: LUCI behaviour

[Karl Palsson]

Paul D  wrote:
> 
> If I use js e.g. :
> 
> o = ss.option(form.TextValue, 'blah', _('blah'), _('blah.'));
> o.optional = true; o.monospace = true;
> 
> 
> And add either:
> 
> o.width = "500px";
> 
> or:
> 
> o.width = "60ch";
> 
> I do not get the desired effect. Is this normal?
> 
> Here (
> https://openwrt.github.io/luci/jsapi/LuCI.form.TextValue.html )
> it says about width:
> 
> ==
> When the property is set to a string value, it is applied as-is
> to the CSS width property.
> 
> This property has no effect on options that are not children of
> grid or table section elements.
> ==
> 
> How does one know that it's a child of said element? ( Is it
> talking about HTML elements? Or LUCI? Also, which 'options'? )

I can answer this at least.  If you are in a 

s = m.section(form.GridSection, 'blah, _('blah blah'));
or
s = m.section(form.TableSection.

You will be able to use the width property. Otherwise, no affect.

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

[RFC: PATCH] ath79: port dragino ms14 to DTS

[Karl Palsson]

Changes:
* Dropped buttons. There's only one physical button, and it
  isn't wired up to be functional as per schematic.  Didn't work
  in ar71xx either.
* partition layout was always wrong.  uboot env was actually last
  portion of uboot partition.

Missing (RFC):
* link detection on eth0 (lan) doesn't work.  This worked in 19.07 w/
  ar71xx, and "swconfig dev switch0 show" correctly shows the link state
  changing for port 1 when I pull the cable.
  eth0 is simply permanently up.  Hints?  Link detection works perfectly
  well for eth1 (wan)

  From schematic and inspection, the old "wan" port (left hand side
  looking at the ports is "P4" on the ar9331, and the old "lan" port
  (right ahnd side) is "P0"

I'm stuck here on getting link detection.  Poking things like gmac
config and port switching is just stabbing in the dark, and I'm getting
nowhere with it.

Same as before:
* usb works
* leds work (wan led toggles with wan/eth1 link state, lan led is
  permanently up, but can be toggled manually)
* wifi works
* all interfaces have same MACs as before, and wan/lan are same physical
  locations as before.

Signed-off-by: Karl Palsson 
---
 package/boot/uboot-envtools/files/ath79   |   1 +
 .../linux/ath79/dts/ar9331_dragino_ms14.dts   | 152 ++
 .../generic/base-files/etc/board.d/01_leds|   4 +
 target/linux/ath79/image/generic.mk   |   9 ++
 4 files changed, 166 insertions(+)
 create mode 100644 target/linux/ath79/dts/ar9331_dragino_ms14.dts

diff --git a/package/boot/uboot-envtools/files/ath79 
b/package/boot/uboot-envtools/files/ath79
index 91ba587bf8..d0b24d68dc 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -22,6 +22,7 @@ allnet,all-wap02860ac|\
 arduino,yun|\
 buffalo,bhr-4grv2|\
 devolo,magic-2-wifi|\
+dragino,ms14|\
 engenius,eap1200h|\
 engenius,eap300-v2|\
 engenius,eap350-v1|\
diff --git a/target/linux/ath79/dts/ar9331_dragino_ms14.dts 
b/target/linux/ath79/dts/ar9331_dragino_ms14.dts
new file mode 100644
index 00..e7772ac383
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_dragino_ms14.dts
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "ar9331.dtsi"
+
+/ {
+   model = "Dragino MS14";
+   compatible = "dragino,ms14", "qca,ar9331";
+
+   /* label serial is at hexdump -v -e '1/1 "%c"' -s $((0x904)) -n 11 
/dev/mtd6 (art partition) */
+
+   aliases {
+   led-boot = _sys;
+   led-failsafe = _sys;
+   led-upgrade = _sys;
+   serial0 = 
+   };
+
+   /*
+* The physical switch on board is nominally connected to 
+* GPIO11, "jumpstart" but has no pullup from the factory
+* and consequently doesn't actually work.
+* See ms14_schematic_v2.2.pdf
+* Swapping R7 and R215 will "fix" it.
+   keys {
+   compatible = "gpio-keys";
+   jumpstart {
+   linux,code = ;
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+   };
+   */
+
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_led_disable_pins>;
+
+   lan {
+   label = "red:lan";
+   gpios = < 13 GPIO_ACTIVE_LOW>;
+   };
+
+   wan {
+   label = "red:wan";
+   gpios = < 17 GPIO_ACTIVE_LOW>;
+   };
+
+   wlan {
+   label = "red:wlan";
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "phy0tpt";
+   };
+
+   led_sys: sys {
+   label = "red:sys";
+   gpios = < 28 GPIO_ACTIVE_HIGH>;
+   };
+
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   dr_mode = "host";
+   status = "okay";
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   nvmem-cells = <_art_0>;
+   nvmem-cell-names = "mac-address";
+};
+
+ {
+   status = "okay";
+   nvmem-cells = <_art_6>;
+   nvmem-cell-names = "mac-address";
+};
+
+ {
+   num-chipselects = <1>;
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <5000>;
+   reg = <0>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #a

Re: [PATCH] base-files: add blink and turnoff commands to the led script

[Karl Palsson]

John Crispin  wrote:
> This allows us to make all leds blink or force all leds to off.
> It is also possible to force the default behaviour to not load
> any led states/triggers by setting system.@system[-1].leds_off
> to 1.

You actually force them all off though, rather than "not load any
state" ? Is the intention for "leds_off" like the name, or the
intention to be "don't touch any leds" in which case the name and
implementation don't match the commit description?

Also, what's the use case for blink in the default install? It's
not pushing any stack for a temporary blink, it just hard sets
all led to blink. I can see plenty of uses for this in
private testing builds, I have something similar myself for
production testing that all leds function, but i'm having a hard
time seeing what the use case for it is in general, and why it
should be in the default build.

Sincerely,
Karl Palsson


> 
> Signed-off-by: John Crispin 
> ---
>  package/base-files/files/etc/init.d/led | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/package/base-files/files/etc/init.d/led
> b/package/base-files/files/etc/init.d/led index
> 51cb8b5178..252bba623a 100755
> --- a/package/base-files/files/etc/init.d/led
> +++ b/package/base-files/files/etc/init.d/led
> @@ -3,6 +3,9 @@
>  
>  START=96
>  
> +extra_command "turnoff" "Turn all leds off"
> +extra_command "blink" "Blink all leds"
> +
>  load_led() {
>   local name
>   local sysfs
> @@ -121,7 +124,25 @@ load_led() {
>   }
>  }
>  
> +turnoff() {
> + for led in `ls /sys/class/leds/`; do
> + echo none > /sys/class/leds/$led/trigger
> + echo 0 > /sys/class/leds/$led/brightness
> + done
> +}
> +
> +blink() {
> + for led in `ls /sys/class/leds/`; do
> + echo 0 > /sys/class/leds/$led/brightness
> + echo timer > /sys/class/leds/$led/trigger
> + done
> +}
> +
>  start() {
> + [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
> + turnoff
> + exit 0
> + }
>   [ -e /sys/class/leds/ ] && {
>   [ -s /var/run/led.state ] && {
>   local led trigger brightness
> @@ -137,5 +158,7 @@ start() {
>  
>   config_load system
>   config_foreach load_led led
> + . /etc/diag.sh
> + set_state done
>   }
>  }
> -- 
> 2.25.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[PATCH] prereq-build: g++ formatting and consistency fixes

[Karl Palsson]

Remove \n that mangles output, and fix inconsistent version name check.

Example before:

Build dependency: Please install the GNU C++ Compiler (g++) 6 or later
Build dependency: \nPlease reinstall the GNU C++ Compiler (4.8 or later) - it 
appears to be broken
Build dependency: Please install ncurses. (Missing libncurses.so or ncurses.h)

Signed-off-by: Karl Palsson 
---
 include/prereq-build.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index 8adf0d03dd..639d1ad0fa 100644
--- a/include/prereq-build.mk
+++ b/include/prereq-build.mk
@@ -31,7 +31,7 @@ $(eval $(call SetupHostCommand,gcc, \
gcc --version | grep -E 'Apple.(LLVM|clang)' ))
 
 $(eval $(call TestHostCommand,working-gcc, \
-   \nPlease reinstall the GNU C Compiler (6 or later) - \
+   Please reinstall the GNU C Compiler (6 or later) - \
it appears to be broken, \
echo 'int main(int argc, char **argv) { return 0; }' | \
gcc -x c -o $(TMP_DIR)/a.out -))
@@ -43,7 +43,7 @@ $(eval $(call SetupHostCommand,g++, \
g++ --version | grep -E 'Apple.(LLVM|clang)' ))
 
 $(eval $(call TestHostCommand,working-g++, \
-   \nPlease reinstall the GNU C++ Compiler (4.8 or later) - \
+   Please reinstall the GNU C++ Compiler (6 or later) - \
it appears to be broken, \
echo 'int main(int argc, char **argv) { return 0; }' | \
g++ -x c++ -o $(TMP_DIR)/a.out - -lstdc++ && \
-- 
2.31.1


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

Re: [PATCH] pcre: disable C++ bindings

[Karl Palsson]

Rosen Penev  wrote:
> On Sun, Mar 14, 2021 at 7:40 AM Jan Kardell
>  wrote:
> >
> > Rosen Penev skrev:
> > > Nothing uses them. Allows to simplify the Makefile.
> > Actually I use it for stuff that is not in openwrt repos. That means I
> > must keep pcrecpp out-of-tree. Maybe others do too, but have not yet
> > discovered this change. Is really a few saved lines in a makefile worth
> > to make life more difficult for people who uses openwrt as a base for
> > there own projects? Or is openwrt not meant to be used that way?
> >
> > So I kindly request that this change is reverted.
> News to me. From the small research I did on Arch and Debian,
> all packages use the C API.

I would presume they were refering to their own packages not in
the openwrt repos, not "random package frrom arch/debian"

Given how much support _is_ given to downstream openwrt builds,
it doesn't seem unreasonable that for a general package like this
we should offer all of it?

Sincerely,
Karl Palsson

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

RE: [PATCH] rockchip: use stable MAC-address for NanoPi R2S

[Karl Palsson]

"Adrian Schmutzler"  wrote:
> > +   local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd
> > bs=1 count=12 2>/dev/null)")
> 
> bs=12 count=1 ?


Why? unless you're passing other flags to try and magically avoid
the block layer, you're only operating on a 1k block read out
anyway. This sort of suggestion is pointless noise that just
makes things harder to read.

Sincerely,
Karl Palsson

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

Re: [PATCH] state: check return value of chown

[Karl Palsson]

Daniel Golle  wrote:
> On Mon, Jan 04, 2021 at 05:08:22PM -0000, Karl Palsson wrote:
> > 
> > Daniel Golle  wrote:
> > > On Sat, Jan 02, 2021 at 10:01:36PM +0800, yehol...@outlook.com
> > > wrote:
> > 
> > > > -   chown(p->pw_dir, p->pw_uid, p->pw_gid);
> > > > +   if (chown(p->pw_dir, p->pw_uid, p->pw_gid))
> > > > +   fprintf(stderr, "Failed to change 
> > > > ownership for %s\n", p->pw_dir);
> > > 
> > > Please let's not have a custom error message for cases which
> > > practically never occur. If we would really cover all that,
> > > around 80% of the size of executables like procd would be error
> > > messages. Imho an assertion is the right thing to do here.
> > > 
> > 
> > Do we compile with assertions enabled?
> 
> Interesting point actually: I just checked, assertions are
> compiled into code unless NDEBUG is defined which we don't.
> Could be an idea for tiny targets to do so...

That... might make things worse :) For instance, in the patch as
it is proposed now...

-   chown(p->pw_dir, p->pw_uid, p->pw_gid);
+   assert(chown(p->pw_dir, p->pw_uid, p->pw_gid) == 0);

the chown will never get called if you compile with NDEBUG
eg, (We want to get 2 printed in every case, this is when the
asserts pass)


karlp@beros:~/src/junk$ cat hate.c 
#include 
#include 

static int k;

void call_it_safe(void) {
assert(++k > 0);
}

void yolo(void) {
k++;
}

int main() {
call_it_safe();
yolo();
printf("y0: %d\n", k);
}
karlp@beros:~/src/junk$ cc hate.c -DNDEBUG -o hate_ndebug
karlp@beros:~/src/junk$ cc hate.c -o hate karlp@beros:~/src/junk$
./hate y0: 2 << good karlp@beros:~/src/junk$ ./hate_ndebug y0: 1
<<< oops! karlp@beros:~/src/junk$

This is akin to the classic problem of logging macros turning off
code. You need to introduce an extra variable for the assert to
check. (If you want to keep going down this path)

Sincerely,
Karl Palsson

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

Re: [PATCH] state: check return value of chown

[Karl Palsson]

Daniel Golle  wrote:
> On Sat, Jan 02, 2021 at 10:01:36PM +0800, yehol...@outlook.com
> wrote:

> > -   chown(p->pw_dir, p->pw_uid, p->pw_gid);
> > +   if (chown(p->pw_dir, p->pw_uid, p->pw_gid))
> > +   fprintf(stderr, "Failed to change ownership for 
> > %s\n", p->pw_dir);
> 
> Please let's not have a custom error message for cases which
> practically never occur. If we would really cover all that,
> around 80% of the size of executables like procd would be error
> messages. Imho an assertion is the right thing to do here.
> 

Do we compile with assertions enabled?

Sincerely,
Karl Palsson

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

Re: [PATCH] base-files: read all 5 bytes in get_magic_fat32() at once

[Karl Palsson]

The fact that you had to introduce iflags to work around changing IBS/OBS which 
afffected skip size would make me consider this sort of patch to be of 
incredibly marginal utilty, largely even negative value if this isn't some sort 
of hot path.  You've made it more complicated for an _extremely_ small, un 
measured pseudo gain.  

I'd kinda imagine that the underlying layer already read a bigger
block anyway...

Sincerely,
Karl Palsson


Adrian Schmutzler  wrote:
> While the speed improvement might be negligible, there is still
> no reason to read individual bytes.
> 
> Suggested-by: Paul Spooren 
> Signed-off-by: Adrian Schmutzler 
-
>  
>  get_magic_fat32() {
> - (get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
> + (get_image "$@" | dd iflag=skip_bytes bs=5 count=1 skip=82) 2>/dev/null
>  }
>  

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

Re: 20.xx: postponse LuCI HTTPS per default

[Karl Palsson]

"Paul Spooren"  wrote:
> Hi,
> 
> The current list of release goals for 20.xx states[0] that LuCI
> should use HTTPS per default. This works by creating on-device
> a self-signed certificate. Self-signed certificates result in
> warnings and may cause more harm than good, multiple discussion
> are found in the mail archive.
> 
> As no clean solution seems in reach while 20.xx seems close,
> I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs
> `luci`) per default.
> 
> This isn't a vote but a request for developer/user opinions.

Very much in favour of leaving this off, self-signed isn't viable
by default

Sincerely,
Karl Palsson

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

Re: [PATCH] ath25: fix preinit Ethernet port configuration

[Karl Palsson]

Sergey Ryazanov  wrote:
> On Wed, Sep 9, 2020 at 6:08 PM Adrian Schmutzler
>  wrote:
> > > - vconfig add eth0 1
> > > + ip link add dev eth0.1 link eth0 type vlan 
> > > id 1
> >
> > Are you sure this is correct?
> 
> Yes, I tested this command with an OpenWrt ip package :)
> 
> > I only find the following syntax:
> >
> > ip link add link eth0 name eth0.1 type vlan id 1
> >
> 
> According to ip-link(8) a user should use 'name' argument for a
> new interface, but in fact the iplink.c have the following code
> in the interface creation handler:
> > /* Allow "ip link add dev" and "ip link add name" */
> >if (!name)
> >name = dev;
> 

Relying on undocumented behaviour seems like a risky move, when
we could just do it the documented way up front?

Sincerely,
Karl Palsson


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

Re: [PATCH 1/2] build: ipkg-build add -r option for all-root

[Karl Palsson]

Paul Spooren  wrote:
> 
> diff --git a/scripts/ipkg-build b/scripts/ipkg-build
> index e3a9a882cf..38149c4432 100755
> --- a/scripts/ipkg-build
> +++ b/scripts/ipkg-build
> @@ -1,5 +1,7 @@
>  #!/bin/sh
>  
> +set -x
> +

Do you mean to have this in the patch?

Sincerely,
Karl Palsson

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

Re: [PATCH] uhttpd: Increase default certificate validate from 2 to 10 years

[Karl Palsson]

Hauke Mehrtens  wrote:

> 
> We will still over normal http, using https is only an
> addition.

So you will change <> back to 0 by
default then? So it's actually optional? It's currently hardset
to 1 here:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/uhttpd/files/uhttpd.config;h=39089ca25b34bfdcc065682360030e3d3d6433ac;hb=HEAD#l13

This then forces the self signed problematic behaviour anyway.

Sincerely,
Karl Palsson


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

Re: [PATCH] uhttpd: Increase default certificate validate from 2 to 10 years

[Karl Palsson]

Yousong Zhou  wrote:
> It's worth mentioning that recent versions of macos since 10.15
> have a restriction on certificate validity period, self-signed
> or not. It's a strong restriction that the browser ui will have
> no buttons or knobs to bypass the certificate validation,
> rendering such sites inaccessible. I remembered it's also a
> system wide enforcement that chrome on macos also respects
> this.
> 
> [1] Requirements for trusted certificates in iOS 13 and macOS
> 10.15, https://support.apple.com/en-us/HT210176
> 
> > TLS server certificates must have a validity period of 825 days or fewer 
> > (as expressed in the NotBefore and NotAfter fields of the certificate).
> 
> [2] About upcoming limits on trusted certificates,
> https://support.apple.com/en-us/HT211025
> 
> > TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC 
> > must not have a validity period greater than 398 days.
> 

Are they blocking or planning to block non-http sites? This would
be further arguments that self-signed certs by default for luci
are actively bad.

Latest reference I can find for chromium is that HTTP will be
marked as insecure, but not with the click through horror show of
self signed certs.

https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

Sincerely,
Karl Palsson

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

Re: [RFC] self-signed certificates for LuCI

[Karl Palsson]

Paul Spooren  wrote:
> Hi team,
> 
> I recently rewrote px5g[1] to use WolfSSL instead of MbedTLS,
> as the former will be included in OpenWrt 20.x per default.

Cool, more options for ssl libraries is always good.

> 
> If px5g is added to the next release, certificates are
> generated on first boot and most users are unlikely to manually
> recreate RSA ones, not?

I urge this [luci using self-signed certs by default] to be
reconsidered. Or at the very least, considered at all, not just
happening by default because the ssl library was included for
WPA3.

With this change, the very first thing users see is a browser
warning telling the user very very very bad things about what
they would have to do to continue, and we are simply going to
train users to "just click through the warnings" I see that as a
serious step backwards for security and society as a whole.

Please consider the threat model. "Classic" out of the box
OpenWrt on a consumer LAN router is only offering LuCI to the LAN
already. If you have a hostile LAN, self signed certificates
aren't helping you. If you have a more complex threat model, you
_already_ need something more than these self signed certs can
offer. Even when they're accepted, the browser offers zero
warning if the certs changed, merely the same "this is self
signed" warning again.

Note that even with the self-signed certs, you still receive
warnings in the browser. This is sacrificing usability and user
experience for security theatre and the checkbox marketting of
"TLS out of the box"

Should we have more documentation on how you _could_ setup secure
HTTP access? Sure! But this isn't it.

Sincerely,
Karl Palsson

* Yes, I completely agree, the browser vendors are the root of the problem, but 
that's harder to solve, and can't be solved here.  TOFU for private lans would 
be a good start.
* Just because other vendors have gone for that checkbox and are using 
self-signed certs is in no way support for doing it, merely agreeing that the 
situation is bad.
* 
https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings
 is a decent start.



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

Re: [PATCH 2/3] build: sort default packages and split by newlines

[Karl Palsson]

Paul Spooren  wrote:
> The line of default packages became very long and it is easier
> to read one package per line, therefore split it by newlines
> and sort it alphabetically.

If you're going to do that, why not use += as well, so you don't
have to worry about people getting the \ right, and adding
entries at the end doesn't break things?

DEFAULT_PACKAGES+=base-files
DEFAULT_PACKAGES+=busybox
DEFAULT_PACKAGES+=ca-bundle
.


Sincerely,
Karl Palsson


> 
> Signed-off-by: Paul Spooren 
> ---
>  include/target.mk | 35 ---
>  1 file changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/include/target.mk b/include/target.mk
> index b0c563a0ef..03550c6ca6 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -13,13 +13,42 @@ __target_inc=1
>  DEVICE_TYPE?=router
>  
>  # Default packages - the really basic set
> -DEFAULT_PACKAGES:=base-files busybox ca-bundle dropbear
> fstools libc libgcc logd libustream-wolfssl mtd netifd opkg uci
> uclient-fetch urandom-seed urngd +DEFAULT_PACKAGES:=\
> + base-files \
> + busybox \
> + ca-bundle \
> + dropbear \
> + fstools \
> + libc \
> + libgcc \
> + libustream-wolfssl \
> + logd \
> + mtd \
> + netifd \
> + opkg \
> + uci \
> + uclient-fetch \
> + urandom-seed \
> + urngd
>  # For the basic set
>  DEFAULT_PACKAGES.basic:=
>  # For nas targets
> -DEFAULT_PACKAGES.nas:=block-mount fdisk lsblk mdadm
> +DEFAULT_PACKAGES.nas:=\
> + block-mount \
> + fdisk \
> + lsblk \
> + mdadm
>  # For router targets
> -DEFAULT_PACKAGES.router:=dnsmasq iptables ip6tables ppp
> ppp-mod-pppoe firewall odhcpd-ipv6only odhcp6c kmod-ipt-offload
> +DEFAULT_PACKAGES.router:=\
> + dnsmasq \
> + firewall \
> + ip6tables \
> + iptables \
> + kmod-ipt-offload \
> + odhcp6c \
> + odhcpd-ipv6only \
> + ppp \
> + ppp-mod-pppoe
>  
>  ifneq ($(DUMP),)
>all: dumpinfo
> -- 
> 2.25.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [PATCH 1/3] build: add libustream and certs to default pkgs

[Karl Palsson]

Paul Spooren  wrote:
> To allow HTTPS usage on a router it requires both certificates
> (ca-bundle) and a fitting libustream library
> (libustream-wolfssl)
> 
> By adding both, uclient-fetch and wget can connect to encrypted
> HTTP.

Doesn't the availability of ustream-*ssl also trigger uhttpd to
generate self signed certs? That's still (IMO) a major step
backwards while browsers still obstinately treat them as
insecure.

That could be _separated_ of course....

Sincerely,
Karl Palsson

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

PATCH libubox: arg checking and examples

[Karl Palsson]

Minor tweaks to hopefully help people avoid some sharp corners.

Patches 2 and 3 are optional, and have no functional change, but IMO
make the code easier to follow for subsequent developers.



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

[PATCH libubox 4/4] examples/lua: attempt to highlight some traps

[Karl Palsson]

Ran into some issues with my fd event being garbage collected.  As I
never wanted to call :delete, I had seen no reason to keep the returned
object, as my callback and upvalues were still valid.

Signed-off-by: Karl Palsson 
---
 examples/uloop-example.lua | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/examples/uloop-example.lua b/examples/uloop-example.lua
index 9b0684e..511b9ea 100755
--- a/examples/uloop-example.lua
+++ b/examples/uloop-example.lua
@@ -9,7 +9,7 @@ local udp = socket.udp()
 udp:settimeout(0)
 udp:setsockname('*', 8080)
 
--- timer example 1
+-- timer example 1 (will run repeatedly)
 local timer
 function t()
print("1000 ms timer run");
@@ -18,10 +18,10 @@ end
 timer = uloop.timer(t)
 timer:set(1000)
 
--- timer example 2
+-- timer example 2 (will run once)
 uloop.timer(function() print("2000 ms timer run"); end, 2000)
 
--- timer example 3
+-- timer example 3 (will never run)
 uloop.timer(function() print("3000 ms timer run"); end, 3000):cancel()
 
 -- process
@@ -46,6 +46,8 @@ uloop.timer(
end, 2000
 )
 
+-- Keep udp_ev reference, events will be gc'd, even if the callback is still 
referenced
+-- .delete will manually untrack.
 udp_ev = uloop.fd_add(udp, function(ufd, events)
local words, msg_or_ip, port_or_nil = ufd:receivefrom()
print('Recv UDP packet from '..msg_or_ip..':'..port_or_nil..' : 
'..words)
-- 
2.21.3


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

[PATCH libubox 1/4] lua/uloop: fd_add() better args checking

[Karl Palsson]

Actually check for flags being valid, instead of simply ignoring the
call if flags was zero.

Use standard lua checks for the function argument, so you can get a
normal "argument #2 was invalid, expected function, got xxx" instead of
the vague, "invalid arg list"

Signed-off-by: Karl Palsson 
---
 lua/uloop.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/lua/uloop.c b/lua/uloop.c
index 1b0389f..fcbe274 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -232,17 +232,14 @@ static int ul_ufd_add(lua_State *L)
int ref;
int fd_ref;
 
-   if (lua_isnumber(L, -1)) {
-   flags = lua_tointeger(L, -1);
-   lua_pop(L, 1);
-   }
-
-   if (!lua_isfunction(L, -1)) {
-   lua_pushstring(L, "invalid arg list");
+   flags = luaL_checkinteger(L, -1);
+   if (!flags) {
+   lua_pushstring(L, "flags cannot be zero");
lua_error(L);
-
-   return 0;
}
+   lua_pop(L, 1);
+
+   luaL_checktype(L, -1, LUA_TFUNCTION);
 
fd = get_sock_fd(L, -2);
 
@@ -261,8 +258,7 @@ static int ul_ufd_add(lua_State *L)
ufd->fd.fd = fd;
ufd->fd_r = fd_ref;
ufd->fd.cb = ul_ufd_cb;
-   if (flags)
-   uloop_fd_add(>fd, flags);
+   uloop_fd_add(>fd, flags);
 
return 1;
 }
-- 
2.21.3


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

[PATCH libubox 2/4] lua/uloop: make get_sock_fd capable of absolute addresses

[Karl Palsson]

The original code required the use of relative addresses into the lua
stack.  It should accept either.

Signed-off-by: Karl Palsson 
---
 lua/uloop.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lua/uloop.c b/lua/uloop.c
index fcbe274..394970d 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -188,7 +188,8 @@ static int get_sock_fd(lua_State* L, int idx) {
lua_getfield(L, idx, "getfd");
if(lua_isnil(L, -1))
return luaL_error(L, "socket type missing 'getfd' 
method");
-   lua_pushvalue(L, idx - 1);
+   /* if we have absolute, no need to adjust for getfield() call */
+   lua_pushvalue(L, idx > 0 ? idx: idx - 1);
lua_call(L, 1, 1);
fd = lua_tointeger(L, -1);
lua_pop(L, 1);
-- 
2.21.3


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

[PATCH libubox 3/4] lua/uloop: fd_add: use absolute indices for arguments

[Karl Palsson]

Instead of having to adjust the index repeatedly as the stack is
manipulated, use absolute addressing for the function arguments, so they
stay the same throughout the call.  Zero functional change, just
subjectively easier to follow variables.

Signed-off-by: Karl Palsson 
---
 lua/uloop.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/lua/uloop.c b/lua/uloop.c
index 394970d..ee82104 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -233,24 +233,23 @@ static int ul_ufd_add(lua_State *L)
int ref;
int fd_ref;
 
-   flags = luaL_checkinteger(L, -1);
+   flags = luaL_checkinteger(L, 3);
if (!flags) {
lua_pushstring(L, "flags cannot be zero");
lua_error(L);
}
-   lua_pop(L, 1);
 
-   luaL_checktype(L, -1, LUA_TFUNCTION);
+   luaL_checktype(L, 2, LUA_TFUNCTION);
 
-   fd = get_sock_fd(L, -2);
+   fd = get_sock_fd(L, 1);
 
lua_getglobal(L, "__uloop_cb");
-   lua_pushvalue(L, -2);
+   lua_pushvalue(L, 2);
ref = luaL_ref(L, -2);
lua_pop(L, 1);
 
lua_getglobal(L, "__uloop_fds");
-   lua_pushvalue(L, -3);
+   lua_pushvalue(L, 1);
fd_ref = luaL_ref(L, -2);
lua_pop(L, 1);
 
-- 
2.21.3


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

[no subject]

[Karl Palsson via openwrt-devel]

--- Begin Message ---
The original code required the use of relative addresses into the lua
stack.  It should accept either.

Signed-off-by: Karl Palsson 
---
 lua/uloop.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lua/uloop.c b/lua/uloop.c
index fcbe274..394970d 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -188,7 +188,8 @@ static int get_sock_fd(lua_State* L, int idx) {
lua_getfield(L, idx, "getfd");
if(lua_isnil(L, -1))
return luaL_error(L, "socket type missing 'getfd' 
method");
-   lua_pushvalue(L, idx - 1);
+   /* if we have absolute, no need to adjust for getfield() call */
+   lua_pushvalue(L, idx > 0 ? idx: idx - 1);
lua_call(L, 1, 1);
fd = lua_tointeger(L, -1);
lua_pop(L, 1);
-- 
2.21.3


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

[no subject]

[Karl Palsson via openwrt-devel]

--- Begin Message ---
Some minor improvements to argument handling and docs.

Patches 2 and 3 are optional, they have zero functional change, but IMO
make the code easier to follow for future workers.




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

[no subject]

[Karl Palsson via openwrt-devel]

--- Begin Message ---
Instead of having to adjust the index repeatedly as the stack is
manipulated, use absolute addressing for the function arguments, so they
stay the same throughout the call.  Zero functional change, just
subjectively easier to follow variables.

Signed-off-by: Karl Palsson 
---
 lua/uloop.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/lua/uloop.c b/lua/uloop.c
index 394970d..ee82104 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -233,24 +233,23 @@ static int ul_ufd_add(lua_State *L)
int ref;
int fd_ref;
 
-   flags = luaL_checkinteger(L, -1);
+   flags = luaL_checkinteger(L, 3);
if (!flags) {
lua_pushstring(L, "flags cannot be zero");
lua_error(L);
}
-   lua_pop(L, 1);
 
-   luaL_checktype(L, -1, LUA_TFUNCTION);
+   luaL_checktype(L, 2, LUA_TFUNCTION);
 
-   fd = get_sock_fd(L, -2);
+   fd = get_sock_fd(L, 1);
 
lua_getglobal(L, "__uloop_cb");
-   lua_pushvalue(L, -2);
+   lua_pushvalue(L, 2);
ref = luaL_ref(L, -2);
lua_pop(L, 1);
 
lua_getglobal(L, "__uloop_fds");
-   lua_pushvalue(L, -3);
+   lua_pushvalue(L, 1);
fd_ref = luaL_ref(L, -2);
lua_pop(L, 1);
 
-- 
2.21.3


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

[no subject]

[Karl Palsson via openwrt-devel]

--- Begin Message ---
Actually check for flags being valid, instead of simply ignoring the
call if flags was zero.

Use standard lua checks for the function argument, so you can get a
normal "argument #2 was invalid, expected function, got xxx" instead of
the vague, "invalid arg list"

Signed-off-by: Karl Palsson 
---
 lua/uloop.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/lua/uloop.c b/lua/uloop.c
index 1b0389f..fcbe274 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -232,17 +232,14 @@ static int ul_ufd_add(lua_State *L)
int ref;
int fd_ref;
 
-   if (lua_isnumber(L, -1)) {
-   flags = lua_tointeger(L, -1);
-   lua_pop(L, 1);
-   }
-
-   if (!lua_isfunction(L, -1)) {
-   lua_pushstring(L, "invalid arg list");
+   flags = luaL_checkinteger(L, -1);
+   if (!flags) {
+   lua_pushstring(L, "flags cannot be zero");
lua_error(L);
-
-   return 0;
}
+   lua_pop(L, 1);
+
+   luaL_checktype(L, -1, LUA_TFUNCTION);
 
fd = get_sock_fd(L, -2);
 
@@ -261,8 +258,7 @@ static int ul_ufd_add(lua_State *L)
ufd->fd.fd = fd;
ufd->fd_r = fd_ref;
ufd->fd.cb = ul_ufd_cb;
-   if (flags)
-   uloop_fd_add(>fd, flags);
+   uloop_fd_add(>fd, flags);
 
return 1;
 }
-- 
2.21.3


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

[no subject]

[Karl Palsson via openwrt-devel]

--- Begin Message ---
Ran into some issues with my fd event being garbage collected.  As I
never wanted to call :delete, I had seen no reason to keep the returned
object, as my callback and upvalues were still valid.

Signed-off-by: Karl Palsson 
---
 examples/uloop-example.lua | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/examples/uloop-example.lua b/examples/uloop-example.lua
index 9b0684e..511b9ea 100755
--- a/examples/uloop-example.lua
+++ b/examples/uloop-example.lua
@@ -9,7 +9,7 @@ local udp = socket.udp()
 udp:settimeout(0)
 udp:setsockname('*', 8080)
 
--- timer example 1
+-- timer example 1 (will run repeatedly)
 local timer
 function t()
print("1000 ms timer run");
@@ -18,10 +18,10 @@ end
 timer = uloop.timer(t)
 timer:set(1000)
 
--- timer example 2
+-- timer example 2 (will run once)
 uloop.timer(function() print("2000 ms timer run"); end, 2000)
 
--- timer example 3
+-- timer example 3 (will never run)
 uloop.timer(function() print("3000 ms timer run"); end, 3000):cancel()
 
 -- process
@@ -46,6 +46,8 @@ uloop.timer(
end, 2000
 )
 
+-- Keep udp_ev reference, events will be gc'd, even if the callback is still 
referenced
+-- .delete will manually untrack.
 udp_ev = uloop.fd_add(udp, function(ufd, events)
local words, msg_or_ip, port_or_nil = ufd:receivefrom()
print('Recv UDP packet from '..msg_or_ip..':'..port_or_nil..' : 
'..words)
-- 
2.21.3


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

Re: [OpenWrt-Devel] Problems with e-mail DMARC policy, and other usability issues

[Karl Palsson]

 wrote:
> 
> However, the basic concept of a mailing list requires it to
> change the From header.

... does it though?  I know it does traditionally, but... is that really the 
only way?  IFF you keep this, then yeah, sure, all the other justifications are 
fine, but it's clearly not working well.

If the purpose of the mailling list is for human interaction,
then I'd argue it most certainly does _not_ need to be doing
this.

If the purpose of the mailing list is for automated processes to
handle patches from specially formatted mails, then. is it
really the best tool? (hahah oh, I made myself sad)

Sincerely,
Karl Palsson

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

Re: [OpenWrt-Devel] Ubus based service watchdog?

[Karl Palsson]

Michael Jones  wrote:
> On Fri, May 15, 2020 at 4:35 AM Petr Štetiar 
> wrote:
> 
> > Michael Jones  [2020-05-15 02:39:52]:
> >
> > > What's wrong with monit is that it's documentation is gigantic
> >
> > Good documentation with a lot of examples is hardly a problem, its a bonus
> > point for me.
> >
> >
> I think you misunderstood.
> 
> Monit has a massive feature surface. I'm not even going to
> consider it, it goes far far beyond the level of capability
> that's appropriate for my use case.

fwiw, I've been using monit for exactly the sort of "my processes
are important, my code is not perfect, and things should get
restarted" since before procd even had process restarting. It
_just works_ and has been a major help. I'm sure procd could be
expanded with some basic pieces, sure, but where does it end?
monit works right now, and has been tested and used by a large
cast.

Sincerely,
Karl Palsson

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

Re: [OpenWrt-Devel] [PATCH] rpcd: fix respawn settings

[Karl Palsson]

Petr Štetiar   wrote:
> Commit 432ec292ccc8 ("rpcd: add respawn param") has introduced
> infinite restarting of the service which could be reached over
> network. 

Didn't we already decide that this wasn't the case?

This is not recommended security practice as it might
> give potential adversary infinite number of tries in case there
> might be some issue in the rpcd or its surrounding stack.

Sure, now it's a DoS instead :) It's always a tradeoff, but I
think you're glossing over the tradeoff here.

> 
> So lets remove the currently bogus `respawn_retry` variable (it
> wasn't possible to override it anyway), reverting to the
> previous default max. of 5 service restarts which could be now
> overriden via system's UCI settings if desired.
> 
> Cc: Jo-Philip Wich 
> Cc: Florian Eckert 
> Cc: Hauke Mehrtens 
> Fixes: 432ec292ccc8 ("rpcd: add respawn param")
> Signed-off-by: Petr Štetiar 
> ---
>  package/system/rpcd/files/rpcd.init | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/system/rpcd/files/rpcd.init
> b/package/system/rpcd/files/rpcd.init index
> 3e9ea5bbf329..f75d0e0f0eea 100755
> --- a/package/system/rpcd/files/rpcd.init
> +++ b/package/system/rpcd/files/rpcd.init
> @@ -12,7 +12,7 @@ start_service() {
>  
>   procd_open_instance
>   procd_set_param command "$PROG" ${socket:+-s "$socket"} ${timeout:+-t 
> "$timeout"}
> - procd_set_param respawn ${respawn_retry:-0}
> + procd_set_param respawn
>   procd_close_instance
>  }
>  
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Next maintenance releases

[Karl Palsson]

Petr  Štetiar   wrote:
> Karl Palsson  [2020-02-21 13:14:29]:
> 
> Hi,
> 
> > I would very much like to see
> > https://bugs.openwrt.org/index.php?do=details_id=2833 merged
> > (it contains a fix and tests) for 19.07, as it fixes a regression
> > in behaviour there. (umdns stopped working)
> 
> [puting aside the fact, that the patches weren't send via the
> standard way[1] so they weren't reviewed yet]
> 
> please note, that this proposed fix is not included in the
> master yet, thus untested by the wider audience and you're
> requesting inclusion into stable release 19.07.

Correct. Breaking umdns is a regression that should be fixed. I'm
honestly more surprised that this still isn't fixed in master
either.

> 
> 1. https://openwrt.org/submitting-patches

Not my patch, just another person with the same breakage so I
can't control how they submitted it. They filed a bug report,
using the formal bug tracking tool, and happened to include a
patch and test.

Sincerely,
Karl Palsson

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

Re: [OpenWrt-Devel] Next maintenance releases

[Karl Palsson]

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

I would very much like to see
https://bugs.openwrt.org/index.php?do=details_id=2833 merged
(it contains a fix and tests) for 19.07, as it fixes a regression
in behaviour there. (umdns stopped working)

I've tested the fix locally at least

Sincerely,
Karl Palsson

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

Re: [OpenWrt-Devel] [PATCH v4 1/2] serial: ar933x_uart: add rs485 support

[Karl Palsson]

Petr  Štetiar   wrote:

> 
> I really dont get this part and BTW it possibly breaks
> `rs485-rx-during-tx` DTS binding.

Just as an aside, that's not a required binding, and not used all
that often either. Not all hardware even supports this, even if
you make sure the driver handles it well. The transceivers
normally have separate pins for driver enable and (not) receiver
enable, but they're (very) often wired together, so you _can't_
rx during tx. If your hardware does offer it, it can be used to
do collision detection, but it's definitely an optional binding.
I'd _MUCH_ rather see the basic bindings working _at all_ rather
than asking for this optional one.

Sincerely,
Karl Palsson

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

Re: [OpenWrt-Devel] [PATCH v2 1/2] ath79: ar9330-uart: add support for half-duplex using DTR signal

[Karl Palsson]

Is there any reason why we can't implement the required peices to
use upstreams rs485 support instead of just redoing it the way
that Teltonika bolted it in? From past attempts this sort of
change would never be allowed upstream as is. Your device using
DTR would just have a binding of "rts-gpios: dtr-gpio-pin-id" And
anyone else on ath79 who wants to use rs485 can then use their
own gpios, instead of hardcoded DTR like you have here.

Sincerely,
Karl Palsson

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/rs485.yaml
and
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/serial.txt

(Apologies if people are getting this a third time, I've been
attempting to coerce spamhaus into allowing me to send email, and
i've not seen any replies to my earlier posts anyway)

Daniel Golle  wrote:
> Add support for RS485 tranceiver with transmit/receive switch
> hooked to the DTR GPIO. This is how RS485 is implemented on the
> Teltonika RUT955 device and this patch immitates the behaviour
> of the driver found in their SDK[1].
> 
> [1]:
> https://wiki.teltonika.lt/gpl/RUT9XX_R_GPL_00.06.05.3.tar.gz
> Signed-off-by: Daniel Golle 
> ---
>  ...41-tty-serial-ar933x-uart-rs485-gpio.patch | 129 ++
>  1 file changed, 129 insertions(+)
>  create mode 100644 
> target/linux/ath79/patches-4.19/0041-tty-serial-ar933x-uart-rs485-gpio.patch
> 
> diff --git
> a/target/linux/ath79/patches-4.19/0041-tty-serial-ar933x-uart-rs485-gpio.patch
> b/target/linux/ath79/patches-4.19/0041-tty-serial-ar933x-uart-rs485-gpio.patch
> new file mode 100644 index 00..2b6b32be26
> --- /dev/null
> +++ 
> b/target/linux/ath79/patches-4.19/0041-tty-serial-ar933x-uart-rs485-gpio.patch
> @@ -0,0 +1,129 @@
> +--- a/drivers/tty/serial/Kconfig
>  b/drivers/tty/serial/Kconfig
> +@@ -1296,6 +1296,7 @@ config SERIAL_AR933X
> + tristate "AR933X serial port support"
> + depends on HAVE_CLK && ATH79
> + select SERIAL_CORE
> ++select SERIAL_MCTRL_GPIO if GPIOLIB
> + help
> +   If you have an Atheros AR933X SOC based board and want to use the
> +   built-in UART of the SoC, say Y to this option.
> +--- a/drivers/tty/serial/ar933x_uart.c
>  b/drivers/tty/serial/ar933x_uart.c
> +@@ -13,6 +13,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + #include 
> + #include 
> + #include 
> +@@ -29,6 +30,8 @@
> + 
> + #include 
> + 
> ++#include "serial_mctrl_gpio.h"
> ++
> + #define DRIVER_NAME "ar933x-uart"
> + 
> + #define AR933X_UART_MAX_SCALE   0xff
> +@@ -47,6 +50,7 @@ struct ar933x_uart_port {
> + unsigned intmin_baud;
> + unsigned intmax_baud;
> + struct clk  *clk;
> ++struct mctrl_gpios  *gpios;
> + };
> + 
> + static inline unsigned int ar933x_uart_read(struct ar933x_uart_port *up,
> +@@ -103,10 +107,48 @@ static inline void ar933x_uart_stop_tx_i
> + static inline void ar933x_uart_putc(struct ar933x_uart_port *up, int ch)
> + {
> + unsigned int rdata;
> ++unsigned int timeout = 6;
> ++unsigned long flags;
> ++unsigned int status;
> ++struct serial_rs485 *rs485conf = >port.rs485;
> ++struct gpio_desc *dtr_gpio = mctrl_gpio_to_gpiod(up->gpios, 
> UART_GPIO_DTR);
> + 
> + rdata = ch & AR933X_UART_DATA_TX_RX_MASK;
> + rdata |= AR933X_UART_DATA_TX_CSR;
> +-ar933x_uart_write(up, AR933X_UART_DATA_REG, rdata);
> ++
> ++if (rs485conf->flags & SER_RS485_ENABLED) {
> ++/* Disable RX interrupt */
> ++spin_lock_irqsave(>port.lock, flags);
> ++up->ier &= ~AR933X_UART_INT_RX_VALID;
> ++ar933x_uart_write(up, AR933X_UART_INT_EN_REG, up->ier);
> ++
> ++if (!IS_ERR_OR_NULL(dtr_gpio))
> ++gpiod_set_value(dtr_gpio, 0);
> ++
> ++ar933x_uart_write(up, AR933X_UART_DATA_REG, rdata);
> ++
> ++/* wait for transmission to end */
> ++do {
> ++status = ar933x_uart_read(up, AR933X_UART_CS_REG);
> ++if (--timeout == 0)
> ++break;
> ++udelay(1);
> ++} while ((status & AR933X_UART_CS_TX_BUSY) != 0);
> ++
> ++ar933x_uart_write(up, AR933X_UART_INT_REG, 
> AR933X_UART_INT_RX_VALID);
> ++/* remove the character from the FIFO */
> ++ar933x_uart_write(up, AR933X_UART_DATA_REG, 
> AR933X_UART_DATA_RX_CSR);
> ++/* Enable RX interrupt */
> ++up->ier |= AR933X_UART_

[OpenWrt-Devel] [PATCH] uboot-envtools: ath79: add etactica eg200 support

[Karl Palsson]

Was inadvertantly missed from the inital forward port from ar71xx to
ath79.

Fixes: 1588114cf2 ath79: add etactica-eg200 support

Signed-off-by: Karl Palsson 
---
 package/boot/uboot-envtools/files/ath79 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boot/uboot-envtools/files/ath79 
b/package/boot/uboot-envtools/files/ath79
index 1499aa19a2..f956cf4ed4 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -16,6 +16,7 @@ case "$board" in
 alfa-network,ap121f|\
 buffalo,bhr-4grv2|\
 engenius,ecb1750|\
+etactica,eg200|\
 glinet,gl-ar300m-lite|\
 glinet,gl-ar300m-nand|\
 glinet,gl-ar300m-nor|\
-- 
2.21.0


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

Re: [OpenWrt-Devel] [PATCH] ath79: eg200: enable status led usage

[Karl Palsson]

David Bauer  wrote:
> 
> Git won't let me push to master without a on-matching SoB.
> 
> $ git push upstream upstream-master:master
> Enumerating objects: 21, done.
> Counting objects: 100% (21/21), done.
> Delta compression using up to 4 threads
> Compressing objects: 100% (11/11), done.
> Writing objects: 100% (11/11), 1.20 KiB | 616.00 KiB/s, done.
> Total 11 (delta 7), reused 0 (delta 0) remote: No matching SoB
> line found for author Karl Pálsson  remote:
> in commit a155a153e0949aefd9147061f9a00a0d91d4400a remote: To
> git.openwrt.org:openwrt/openwrt.git
>  ! [remote rejected]   upstream-master -> master (pre-receive hook 
> declined)
> error: failed to push some refs to
> 'g...@git.openwrt.org:openwrt/openwrt.git'

Thanks for trying.

I'll have to find another mail server to send through. It was
previously sending through my private mail server, but that
wasn't really appropriate for mail being sent for work. I've then
finally managed to get git-send-email to work via the work email
server, but get this sort of problem.

The commits themselves _do_ have the author.

I've just been suggested a method of adding a second From: field
to the annotated patch when sending, which may help, otherwise
I'll revert to the (clearly second tier) method of sending PRs
via github, where the actual git commits are preserved, instead
of whatever the world of mail decides to mangle and rewrite on
the way.

Sincerely,
Karl Palsson 

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

Re: [OpenWrt-Devel] [PATCH] ath79: eg200: enable status led usage

[Karl Palsson]

Karl Pálsson   wrote:
> 
> Signed-off-by: Karl Palsson 
> ---

It's minor, but if someone picks this, please _don't_ change my
SoB to match the email. The original source commits and all git
config names are unaccented, and it's how I use my name, it's
just the office365 mail server that is "mangling" my name, and
it's not to be trusted. (ref:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=075c570cde08c2a27f7e2a64995cc74ae52b5704
where it actually was "matched SoB to email" unlike the comment)

Sincerely,
Karl Palsson

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

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

[Karl Palsson]

What's the point of "force" if it doesn't force? Are we going to
add a second -F to "really force" ? Or is it going to be "oh, -F
failed for some lame reason, so I'll use mtd write, and still
complain anyway"

Cheers,
Karl P

Rafał Miłecki   wrote:
> From: Rafał Miłecki 
> 
> This uses recently added "validate_firmware_image" to validate
> passed firmware. If it happens to be invalid and marked as
> impossible to force then sysupgrade simply exits with an error.
> 
> This change is needed to avoid bricking devices with some
> totally broken images.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> This patch depends on the:
> [PATCH procd] system: add "validate_firmware_image" ubus method
> ---
>  system.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/system.c b/system.c
> index 35d5a23..7f49758 100644
> --- a/system.c
> +++ b/system.c
> @@ -507,7 +507,18 @@ static int sysupgrade(struct ubus_context *ctx, struct 
> ubus_object *obj,
> struct ubus_request_data *req, const char *method,
> struct blob_attr *msg)
>  {
> + enum {
> + VALIDATION_VALID,
> + VALIDATION_FORCEABLE,
> + __VALIDATION_MAX
> + };
> + static const struct blobmsg_policy validation_policy[__VALIDATION_MAX] 
> = {
> + [VALIDATION_VALID] = { .name = "valid", .type = 
> BLOBMSG_TYPE_BOOL },
> + [VALIDATION_FORCEABLE] = { .name = "forceable", .type = 
> BLOBMSG_TYPE_BOOL },
> + };
> + struct blob_attr *validation[__VALIDATION_MAX];
>   struct blob_attr *tb[__SYSUPGRADE_MAX];
> + bool valid, forceable;
>  
>   if (!msg)
>   return UBUS_STATUS_INVALID_ARGUMENT;
> @@ -516,6 +527,19 @@ static int sysupgrade(struct ubus_context *ctx, struct 
> ubus_object *obj,
>   if (!tb[SYSUPGRADE_PATH] || !tb[SYSUPGRADE_PREFIX])
>   return UBUS_STATUS_INVALID_ARGUMENT;
>  
> + if 
> (validate_firmware_image_call(blobmsg_get_string(tb[SYSUPGRADE_PATH])))
> + return UBUS_STATUS_UNKNOWN_ERROR;
> +
> + blobmsg_parse(validation_policy, __VALIDATION_MAX, validation, 
> blob_data(b.head), blob_len(b.head));
> +
> + valid = validation[VALIDATION_VALID] && 
> blobmsg_get_bool(validation[VALIDATION_VALID]);
> + forceable = validation[VALIDATION_FORCEABLE] && 
> blobmsg_get_bool(validation[VALIDATION_FORCEABLE]);
> +
> + if (!valid && !forceable) {
> + fprintf(stderr, "Firmware image is broken and cannot be 
> installed\n");
> + return UBUS_STATUS_UNKNOWN_ERROR;
> + }
> +
>   sysupgrade_exec_upgraded(blobmsg_get_string(tb[SYSUPGRADE_PREFIX]),
>blobmsg_get_string(tb[SYSUPGRADE_PATH]),
>tb[SYSUPGRADE_COMMAND] ? 
> blobmsg_get_string(tb[SYSUPGRADE_COMMAND]) : NULL,
> -- 
> 2.21.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] lua: create lua symlink for host installation

[Karl Palsson]

How is this meant to work when you have both?

David Bauer  wrote:
> Since the binaries for both lua as well as lua5.3 contain the
> version number, invocations of the "lua" binary are failing, as
> it's not created anymore for the host package.
> 
> Fixes: fe59b46 ("lua: include version number in installed
> files") Signed-off-by: David Bauer 
> ---
>  package/utils/lua/Makefile| 4 +++-
>  package/utils/lua5.3/Makefile | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/package/utils/lua/Makefile
> b/package/utils/lua/Makefile index a2870448bd..e376e8c472
> 100644
> --- a/package/utils/lua/Makefile
> +++ b/package/utils/lua/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=lua
>  PKG_VERSION:=5.1.5
> -PKG_RELEASE:=5
> +PKG_RELEASE:=6
>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>  PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
> @@ -133,6 +133,8 @@ define Host/Install
>   $(MAKE) -C $(HOST_BUILD_DIR) \
>   INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
>   install
> +
> + $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
>  endef
>  
>  define Build/InstallDev
> diff --git a/package/utils/lua5.3/Makefile
> b/package/utils/lua5.3/Makefile index c9e9bebb1a..7f835dd41f
> 100644
> --- a/package/utils/lua5.3/Makefile
> +++ b/package/utils/lua5.3/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=lua
>  PKG_VERSION:=5.3.5
> -PKG_RELEASE:=4
> +PKG_RELEASE:=5
>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>  PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
> @@ -118,6 +118,8 @@ define Host/Install
>   $(MAKE) -C $(HOST_BUILD_DIR) \
>   INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
>   install
> +
> + $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.3 $(STAGING_DIR_HOSTPKG)/bin/lua
>  endef
>  
>  define Build/InstallDev
> -- 
> 2.23.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH v2] ath79: convert devices to interrupt-driven gpio-keys

[Karl Palsson]

Adrian Schmutzler  wrote:
> This converts all remaining devices to use interrupt-driven
> gpio-keys compatible instead of gpio-keys-polled. The
> poll-interval is removed.
> 
> Only ar7240_netgear_wnr612-v2 is kept at gpio-keys-polled, as
> this one is using ath9k keys.
> 
> Signed-off-by: Adrian Schmutzler 
> 
> ---
> 
> Changed in v2:
> - Rebased and retained ar7240_netgear_wnr612-v2 at polled keys
> ---
>  target/linux/ath79/dts/ar9331_etactica_eg200.dts | 3 +--
> diff --git a/target/linux/ath79/dts/ar9331_etactica_eg200.dts
> b/target/linux/ath79/dts/ar9331_etactica_eg200.dts index
> d18a239d32..721e676ed7 100644
> --- a/target/linux/ath79/dts/ar9331_etactica_eg200.dts
> +++ b/target/linux/ath79/dts/ar9331_etactica_eg200.dts
> @@ -15,8 +15,7 @@
>   };
>  
>   keys {
> - compatible = "gpio-keys-polled";
> - poll-interval = <50>;
> + compatible = "gpio-keys";
>  
>   restore {
>   linux,code = ;


Tested-by: Karl Palsson 

(Only this hardware, don't have any of the others nearby)


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

Re: [OpenWrt-Devel] [PATCH 1/2] toolchain: add support for custom toolchains

[Karl Palsson]

John Crispin  wrote:
> The requirement for being able to add custom src toolchains to
> the build system has been brought forward by the members of the
> prpl foundation. This patch tries to address this requirement
> by allowing a ned folder to be loaded into the tree call
> toolchain_custom. The subfolders contained within have the same
> layout as the toolchain folder. By placing optional Makefiles
> into these subfolders It is possible to override the versions
> of the various toolchain components aswell as their patch sets
> and make templates.
> 
> Signed-off-by: John Crispin 
> ---
> diff --git a/toolchain/Config.in b/toolchain/Config.in index
> 82dddbc209..cad492aa1e 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -155,6 +155,11 @@ menuconfig EXTERNAL_TOOLCHAIN
> Specify additional directories searched for libraries 
> (override LDFLAGS).
> Use ./DIR for directories relative to the root above.
>  
> +config CUSTOM_TOOLCHAIN
> + depends on DEVEL
> +
> +source "toolchain_custom/*.in"


Could we add help text here, based on the commit comment that
says how this option is to be used?

Sincerely,
Karl Palsson

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

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Karl Palsson]

John Crispin  wrote:
> 
> On 05/06/2019 12:17, Karl Palsson wrote:
> > John Crispin  wrote:
> >> This can be used inside build setups for easy feeds.conf
> >> generation.
> >
> > Could you give us an example of how this is actually easy, or
> > what sort of functionality this is providing beyond "cat
> > feeds.conf.default feeds.conf.extra > feeds.conf"
> >
> > It seems like a lot of perl for a narrow usecase.
> >
> > Sincerely,
> > Karl Palsson
> 
> This was brought up as a missing feature by the prpl folks. I
> considered on how to best implement this and find that having
> proper tooling is much better than having to carry around an
> extra file that is cat. being able to build the feeds.conf
> dynamically like this just seems much cleaner to me and will
> allow downstream users, vendors, odms and integrators to have
> less need to patch their trees to death.

So, they still have to have a script, but now the script has...


...
./scripts/feeds setup -b src-git,private-aa,git://blah
src-link,private-bb,/wop/blah
...

instead of
...
cp feeds.conf.default feeds.conf
echo "src-git private-aa git://blah" >> feeds.conf
echo "src-link private-bb /wop/blah" >> feeds.conf
...

I mean, _yes_ it's "simpler" but it's only simpler by bringing in
new tools with new layers of abstraction. I really question
whether that's actually simpler for anyone in the long run, and
also how this really counts as a "missing feature" There's still
going to be a requirement for that vendor script.

Sincerely,
Karl Palsson



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

Re: [OpenWrt-Devel] [PATCH V2 1/2] image: make the folder that gets included intot he RootFS configurable

[Karl Palsson]

John Crispin  wrote:
> This allows managing several different folder for varying env
> profiles.

This is neat, very cool! Thanks for this, I hadn't even thought
it could be done so simply.

Cheers,
Karl Palsson


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

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Karl Palsson]

John Crispin  wrote:
> This can be used inside build setups for easy feeds.conf
> generation.


Could you give us an example of how this is actually easy, or
what sort of functionality this is providing beyond "cat
feeds.conf.default feeds.conf.extra > feeds.conf"

It seems like a lot of perl for a narrow usecase.

Sincerely,
Karl Palsson


> 
> Signed-off-by: John Crispin 
> ---
>  scripts/feeds | 42 ++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/scripts/feeds b/scripts/feeds
> index 304ef6cbaf..7cd4639ca6 100755
> --- a/scripts/feeds
> +++ b/scripts/feeds
> @@ -7,6 +7,7 @@ use metadata;
>  use warnings;
>  use strict;
>  use Cwd 'abs_path';
> +use File::Copy;
>  
>  chdir "$FindBin::Bin/..";
>  $ENV{TOPDIR} //= getcwd();
> @@ -819,6 +820,42 @@ sub update {
>   return $failed;
>  }
>  
> +sub setup {
> + my %opts;
> +
> + getopts('bh', \%opts);
> +
> + if ($opts{h}) {
> + usage();
> + return 0;
> + }
> +
> + if ($opts{b}) {
> + copy("feeds.conf.default", "feeds.conf") or die "Copy failed: 
> $!"
> + } else {
> + unlink "feeds.conf"
> + }
> +
> + open(my $fd, ">>feeds.conf");
> + while (my $entry = shift @ARGV) {
> + my ($type, $name, $src) = split /,/, $entry;
> +
> + $update_method{$type} or do {
> + warn "Unknown type '$type' in parameter $entry\n";
> + unlink "feeds.conf";
> + return 1;
> + };
> + if ($name =~ /\s/ || $src =~ /\s/) {
> + warn "Feed names or sources may not contain whitespace 
> characters in parameter $entry\n";
> + unlink "feeds.conf";
> + return 1;
> + }
> + printf $fd "%s %s %s\n", $type, $name, $src;
> + }
> +
> + return 0;
> +}
> +
>  sub feed_config() {
>   foreach my $feed (@feeds) {
>   my $installed = (-f "feeds/$feed->[1].index");
> @@ -870,6 +907,10 @@ Commands:
>   -i :   Recreate the index only. No feed update from 
> repository is performed.
>   -f :   Force updating feeds even if there are changed, 
> uncommitted files.
>  
> + setup [options]   ...: generate 
> feeds.conf
> + Options:
> + -b :   Use feeds.conf.default as base for new feeds.conf.
> +
>   clean: Remove downloaded/generated files.
>  
>  EOF
> @@ -883,6 +924,7 @@ my %commands = (
>   'search' => \,
>   'uninstall' => \,
>   'feed_config' => \_config,
> + 'setup' => \,
>   'clean' => sub {
>   system("rm -rf ./feeds ./package/feeds");
>   }
> -- 
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] lua: lnum: fix strtoul based number parsing

[Karl Palsson]

Petr Štetiar   wrote:
> From: Liangbin Lian 
> 
> Lua's LNUM patch currently doesn't parse properly certain
> numbers as it's visible from the following simple tests.
> 


Tested-by: Karl Palsson 

This makes some busted unit tests of ours pass for the first time
on the openwrt target itself :) It will also mean we can drop
some places where we use "0x4000 * 2" instead of the more
understandable 0x8000 form :) (We've had problems with lnum
and reading arrays of 16bit numbers into various 32bit
singed/unsigned floating point forms in the past)

Sincerely,
Karl Palsson

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

Re: [OpenWrt-Devel] A second 'make' always rebuilds something

[Karl Palsson]

"Daniel F. Dickinson"  wrote:
> On 2019-01-30 5:51 a.m., Jo-Philipp Wich wrote:
> > Hi,
> >
> > please share the exact steps used to trigger the issue. Running a simple
> > "make" after an initial build here does not trigger the recompilation of
> > uci or the kernel.
> >
> > ~ Jo
> >
> And environment (OS, distro, version) please!

After a full build finished, just running "time make" repeatedly
again takes ~5 minutes for me. There's some extra packages in my
tree, but there's _something_ less than ideal. This is on fedora
27 desktop, as of reboot-9214-gb3bd82b041

$ time make
WARNING: Makefile 'package/feeds/routing/nodogsplash/Makefile'
has a dependency on 'libmicrohttpd-no-ssl', which does not exist
 make[1] world
 make[2] target/compile
 make[3] -C target/linux compile
 make[2] diffconfig
 make[2] package/cleanup
 make[2] package/compile
 make[3] -C package/libs/libjson-c host-compile
 make[3] -C package/libs/libubox host-compile
 make[3] -C package/system/opkg host-compile
 make[3] -C package/libs/toolchain compile
 make[3] -C package/libs/libnl-tiny compile
 make[3] -C package/libs/libjson-c compile
 make[3] -C package/utils/lua compile
 make[3] -C package/libs/libubox compile
 make[3] -C package/system/ubus compile
 make[3] -C package/system/uci compile
 make[3] -C package/network/config/netifd compile
 make[3] -C package/firmware/linux-firmware compile
 make[3] -C package/firmware/prism54-firmware compile
 make[3] -C package/kernel/linux compile
 make[3] -C package/system/ubox compile
 make[3] -C package/libs/ncurses host-compile
 make[3] -C package/libs/zlib compile
 make[3] -C package/libs/ncurses compile
 make[3] -C package/utils/util-linux compile
 make[3] -C package/system/fstools compile
 make[3] -C package/system/fwtool host-compile
 make[3] -C package/system/fwtool compile
 make[3] -C package/system/procd compile
 make[3] -C package/system/usign host-compile
 make[3] -C package/system/ucert host-compile
 make[3] -C package/utils/jsonfilter compile
 make[3] -C package/system/openwrt-keyring compile
 make[3] -C package/system/usign compile
 make[3] -C package/base-files compile
 make[3] -C package/boot/uboot-envtools compile
 make[3] -C package/libs/readline compile
 make[3] -C package/devel/gdb compile
 make[3] -C package/devel/strace compile
 make[3] -C package/devel/valgrind compile
 make[3] -C feeds/luci/modules/luci-base host-compile
 make[3] -C package/utils/lua host-compile
 make[3] -C feeds/luci/contrib/package/csstidy host-compile
 make[3] -C feeds/luci/applications/luci-app-commands compile
 make[3] -C feeds/luci/applications/luci-app-diag-core compile
 make[3] -C feeds/luci/applications/luci-app-openvpn compile
 make[3] -C package/libs/mbedtls compile
 make[3] -C package/libs/ustream-ssl compile
 make[3] -C package/network/services/uhttpd compile
 make[3] -C feeds/luci/applications/luci-app-uhttpd compile
 make[3] -C package/libs/libmnl compile
 make[3] -C package/utils/bzip2 compile
 make[3] -C package/libs/gettext compile
 make[3] -C package/libs/libiconv compile
 make[3] -C package/libs/argp-standalone compile
 make[3] -C package/libs/elfutils compile
 make[3] -C package/network/utils/iptables compile
 make[3] -C package/network/utils/iproute2 compile
 make[3] -C package/network/services/wireguard compile
 make[3] -C feeds/luci/protocols/luci-proto-wireguard compile
 make[3] -C feeds/luci/applications/luci-app-wireguard compile
 make[3] -C feeds/luci/libs/luci-lib-ip compile
 make[3] -C feeds/luci/libs/luci-lib-jsonc compile
 make[3] -C feeds/luci/libs/luci-lib-nixio compile
 make[3] -C feeds/luci/contrib/package/lucihttp compile
 make[3] -C package/network/utils/iwinfo compile
 make[3] -C package/system/rpcd compile
 make[3] -C feeds/luci/modules/luci-base compile
 make[3] -C feeds/luci/libs/luci-lib-json compile
 make[3] -C feeds/luci/modules/luci-mod-network compile
 make[3] -C feeds/luci/modules/luci-mod-status compile
 make[3] -C feeds/luci/modules/luci-mod-system compile
 make[3] -C feeds/luci/modules/luci-mod-admin-full compile
 make[3] -C feeds/luci/modules/luci-mod-rpc compile
 make[3] -C feeds/packages/libs/check compile
 make[3] -C /home/karlp/src/owrt_private_feeds/libcbms compile
 make[3] -C /home/karlp/src/owrt_private_feeds/remake_shared compile
 make[3] -C /home/karlp/src/owrt_private_feeds/uglylogging compile
 make[3] -C feeds/packages/net/net-snmp compile
 make[3] -C package/libs/openssl compile
 make[3] -C package/libs/libevent2 compile
 make[3] -C feeds/packages/libs/c-ares compile
 make[3] -C feeds/packages/libs/libcap compile
 make[3] -C feeds/packages/libs/libuv compile
 make[3] -C feeds/packages/libs/libwebsockets compile
 make[3] -C /home/karlp/src/owrt_pub_feeds/net/mosquitto compile
 make[3] -C /home/karlp/src/owrt_pub_feeds/net/mosquitto compile
 make[3] -C /home/karlp/src/owrt_pub_feeds/net/mosquitto compile
 make[3] -C /home/karlp/src/owrt_private_feeds/agent_etactica compile
 make[3] -C feeds/packages/libs/libmodbus compile
 make[3] -C 

Re: [OpenWrt-Devel] [PATCH] usbgadget: Add new package

[Karl Palsson]

Does this work for providing a console on the ACM interface?

Petr Štetiar   wrote:
> This package allows easier configuration of USB gadgets via
> standard UCI interface. So far only CDC/ACM has been
> implemented and tested.
> 
> Signed-off-by: Petr Štetiar 

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/7] procd: console hotplugging support

[Karl Palsson]

Hi,

I'll save that for when I get back to it :)

Here's how I packaged the g_cdc (ethernet+cdc-acm together)

https://github.com/karlp/openwrt/commit/40c791f5bfbbf6825087db2fc87f88a73f7fa94c

I've got a few other patches for gadgetmode, but some of it needs
a bitmore testing yet, so I've not proposed it to openwrt yet.

Cheers,
Karl P


Michael Heimpold  wrote:
> Hi Karl,
> 
> if you want to test it, here are the missing pieces roughly
> explained:
> - I used kmod-usb-gadget-eth and kmod-usb-gadget-serial
>   I know that there is another (older?) kernel module which also provides
>   a network and console interface at the same time, but this must be
>   configured via kernel command line parameter if I understand correctly
>   so I've chosen to test this configfs approach
> - add a line to inittab like this:
>ttyGS0::askfirst:/usr/libexec/login.sh
> - patch /etc/hotplug.json on your device like this:
> 
> diff --git a/package/system/procd/files/hotplug.json
> b/package/system/procd/
> files/hotplug.json 
> index 1c949bbea3..25806637cc 100644   
>  
> --- a/package/system/procd/files/hotplug.json 
>  
> +++ b/package/system/procd/files/hotplug.json 
>  
> @@ -33,6 +33,10 @@
>  
> [ "load-firmware", "/lib/firmware" ], 
>  
> [ "return" ]  
>  
> ] 
>  
> + ],  
>  
> + [ "if", 
>  
> + [ "regex", "DEVNAME", "^tty[A-Za-z0-9]" ],  
>  
> + [ "start-console", "%DEVNAME%" ]
>  
> ] 
>  
> ],
>  
> "remove" : [
> 
> - I used a shell script found at 
> http://irq5.io/2016/12/22/raspberry-pi-zero-as-multiple-usb-gadgets/
>  to configure the gadget
> 
> I'll send a patch for hotplug.json after I got some feedback
> for this procd stuff or better - in case this is merged,
> because otherwise we have a dependency issue otherwise...
> Another point on my list is auto-mounting of configfs to the
> right place. I'm feeling that this should not be part of the
> shell script but be done at a central place - still unsure
> where to put it because configfs is an optional kernel module
> and thus available later during boot...
> 
> Best regards,
> Michael
> 
> Am Mittwoch, 2. Januar 2019, 12:38:30 CET schrieb Karl Palsson:
> > Michael Heimpold  wrote:
> > > This series extends procd to allow starting consoles for
> > > devices which are not present during boot or after kernel
> > > module loading. This is for example the case when a USB gadget
> > > serial device is created with configfs. Here the kernel module
> > > is loaded but the tty device only appears after gadget is
> > > configured. Having a console configured in inittab for e.g.
> > > ttyGS0 does not work at the moment due to late appearing of
> > > this device.
> > 
> > Thanks for doing this, I had been planning on using this (console
> > on gadget serial), and didn't even know it didn't work (yet)
> > until your mails! Much appreciated!
> > 
> > Cheers,
> > Karl P
> 
> 
> 
> 

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade

[Karl Palsson]

Henrique de Moraes Holschuh  wrote:
> Em 05/12/2018 21:20, Thomas Endt escreveu:
> >> Auftrag von Henrique de Moraes Holschuh
> >> Do we have a wiki table somewhere that has the device name, ar71xx info
> >> and ath79 info, which could be expanded with ar71xx->ath79 status (no,
> >> yes but unverified, yes verified to be complete)?
> >>
> >> That would be really useful to direct efforts on adding ath79 support
> >> to something that is still ar71xx-only, as well as adding ar71xx->ath79
> >> support to targets of interest (i.e. those one happens to know what
> >> changes are required for the migration, really).
> >>
> >> I suppose one would also add any remarks about ath79 support being
> >> incomplete or any regressions for each target one knows about, too.
> >> That would help steering the ar71xx deprecation.
> > 
> > There is a table that documents the ath79 status in the OpenWrt forum:
> > https://forum.openwrt.org/t/ath79-target-status/18614/9
> > 
> > The place to put this into the wiki would be:
> > https://openwrt.org/docs/techref/targets/ath79
> > 
> > 
> > We can define a new target "ar71xx-ath79" for the dataentries, which would 
> > then give us these 3 options:
> > 
> > 1) "ar71xx"  # device is ar71xx only
> > 2) "ath79"   # device is ath79 only
> > 3) "ar71xx-ath79"# device is migrated (and working, if nothing in 
> > "Unsupported Functions")
> > 
> > ---> devices will automatically show up on the ath79 and/or ar71xx wikipage 
> > (slight modifications necessary).
> > 
> > For "ath79 WIP" devices, we can set the "Unsupported Functions" datafield 
> > (that's where WIP usually is found) to "ath79 WIP, see forum".
> > Any detailed discussion or description of incomplete support should happen 
> > elsewhere, i.e. either in the forum or on the respective devicepages.
> > 
> > Please let me know if this meets your requirements.
> 
> Yes, this would do it nicely, provided that we take care to
> describe in the web pages what ar71xx-ath79 means.
> 
> Note that my answer assumes "migrated" (i.e. ar71xx-ath79)
> means the glue to migrate and convert low-level config (LEDs,
> etc) when updating from ar71xx -> ath79 is in place on the
> ath79 port.
> 
> If it just does ar71xx _and_ ath79, BUT one has to manually
> adjust configuration when migrating from ar71xx to ath79, it
> would have to be flagged as WIP or something like that, even if
> all of its functions are fully implemented and working in
> ath79.

One thing we want to avoid meanwhile is keeping the old stuff
"just because" The whole point of moving to ath79 is to be closer
to upstream. If we just go and repatch everythign to make it
compatible with the past, we might as well not have bothered. We
want to make sure that any migrations are migrations to new stuff
_only_ not adapting things to stay in the same place.

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade

[Karl Palsson]

John Crispin  wrote:
> 
> On 03/12/2018 19:04, Henrique de Moraes Holschuh wrote:
> > (openwrt-adm dropped from this subthread)
> >
> > Em 03/12/2018 15:29, Stijn Segers escreveu:
> >> Op ma, 3 dec 2018 om 5:51 , schreef John Crispin :
> >>> The idea was to fade out ar71xx after the next release and only accept
> >>> new boards for ath79. However i'd been fine taking that step as of now.
> >>> i have noticed that the ath79 patches far out number the ar71xx 
> >>> ones. we
> >>> have lots of patches that migrate boards and i have seen a few new
> >>> boards added only to ath79. lets see how the thread goes, looking 
> >>> fwd to
> >>> hearing opinions...
> >
> >> Rather than further duplicating efforts, I'd 'encourage'* ath79 only 
> >> submissions.
> >
> > Is there a viable way to "sysupgrade" from ar71xx to ath79?
> >
> > Even if it would require a model-by-model "update map" for the 
> > lower-level stuff (LEDs, switch ports?, etc), that would be valuable. 
> > Otherwise, it will be difficult for people with fleets of ar71xx 
> > devices to remotely switch them to ath79...
> >
> afaik this works ootb, if not its easy to make work. it was
> indeed one of the primary concerns in the early stages of the
> task

Compat names are in the makefiles for at least some of the
targets that are known to upgrade nicely, where they're not
directly compatible by name alone.

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] umdns vs avahi: differences in browse (missing ip addresses)

[Karl Palsson]

Karl Palsson  wrote:
> 
> Hi,
> 
> I've been using umdns to advertise some services for a little
> while, and when browsing from my desk, with avahi-browse, it
> has worked well. I've finally gotten around to using "ubus
> umdns browse" and have found some
> inconsistences/differences/quirks. Any insights appreciated.

Similarly, even without having avahi/umdns handle the
advertisements, just looking at printers/scanners on the network
shows very different results

umdns browse: 
"_scanner._tcp": {
"HP Color LaserJet MFP M477fdw (BC9380)": {

},
"Officejet Pro 8500 A909g [985C10]": {
"txt": "txtvers=1",
"txt": "ty=Officejet Pro 8500 A909g",
"txt": "mfg=HP",
"txt": "mdl=Officejet Pro 8500 A909g",
"txt": "adminurl=http:\/\/dhcppc4.local.",
"txt": "button=T",
"txt": "flatbed=T",
"txt": "feeder=T"
}
},


avahi-browse:

= enp0s25 IPv6 HP Color LaserJet MFP M477fdw (BC9380)_scanner._tcp  
  local
   hostname = [NPIBC9380.local]
   address = [192.168.1.121]
   port = [8289]
   txt = ["note=" "flatbed=T" "feeder=T" "button=T" "usb_MDL=HP Color LaserJet 
MFP M477fdw" "usb_MFG=Hewlett-Packard" "mdl=MFP M477fdw" "mfg=Hewlett Packard" 
"ty=HP Color LaserJet MFP M477fdw" "adminurl=http://NPIBC9380.local.; 
"txtvers=1" "UUID=564e4238-4a37-3935-574a-ec8eb5bc9380"]

= enp0s25 IPv6 Officejet Pro 8500 A909g [985C10] _scanner._tcp  
  local
   hostname = [dhcppc4.local]
   address = [192.168.1.126]
   port = [9500]
   txt = ["feeder=T" "flatbed=T" "button=T" "adminurl=http://dhcppc4.local.; 
"mdl=Officejet Pro 8500 A909g" "mfg=HP" "ty=Officejet Pro 8500 A909g" 
"txtvers=1"]


Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] umdns vs avahi: differences in browse (missing ip addresses)

[Karl Palsson]

Hi,

I've been using umdns to advertise some services for a little
while, and when browsing from my desk, with avahi-browse, it has
worked well. I've finally gotten around to using "ubus umdns
browse" and have found some inconsistences/differences/quirks.
Any insights appreciated.

Two hosts on the local network, 

192.168.1.123 eg-03A19D is broadcasting using avahi-daemon and a
service file [1] 192.168.1.194 eg-037BCC is broadcasting using
umdns using "procd_add_mdns rme-sg tcp 22 "info=eTactica gateway
locator""

avahi-browse shows both services ~same. Both have a hostname,
both have a similar txt record, both have the correct IP address
shown.

$ avahi-browse -r _rme-sg._tcp

= enp0s25 IPv4 eTactica gateway Locator on eg-03A19D _rme-sg._tcp   
  local
   hostname = [eg-03A19D.local]
   address = [192.168.1.123]
   port = [22]
   txt = ["info=This record is used to help find a gateway when using DHCP."]
= enp0s25 IPv4 eg-037BCC _rme-sg._tcp   
  local
   hostname = [eg-037BCC.local]
   address = [192.168.1.194]
   port = [22]
   txt = ["info=eTactica gateway locator"]


But "ubus call umdns browse" is a different matter. The ipv4/v6
addresses are missing.

[other keys snipped]
"_rme-sg._tcp": {
"eg-037BCC": {
"ipv4": "192.168.1.194",
"ipv6": "fe80::c693:ff:fe03:7bcc",
"port": 22,
"txt": "info=eTactica gateway locator"
},
"eTactica gateway Locator on eg-03A19D": {
"txt": "info=This record is used to help find a gateway 
when using DHCP."
}



"ubus call fetch" returns more information, but it's clearly
missing the host information for the "failing" one.
$ ubus call umdns fetch '{"question": "_rme-sg._tcp.local", "interface": 
"eth0"}'

{
"name": "_rme-sg._tcp.local",
"type": "PTR",
"ttl": 4375,
"target": "eg-037BCC._rme-sg._tcp.local"
},
{
"name": "eg-037BCC._rme-sg._tcp.local",
"type": "SRV",
"ttl": 4375,
"priority": 2405,
"weight": 26413,
"port": 22,
"target": "eg-037BCC.local"
},
{
"name": "eg-037BCC.local",
"type": "A",
"ttl": 4039,
"target": "192.168.1.194"
},
{
"name": "eg-037BCC.local",
"type": "",
"ttl": 4039,
"target": "fe80::c693:ff:fe03:7bcc"
},
{
"name": "eg-037BCC._rme-sg._tcp.local",
"type": "TXT",
"ttl": 4375,
"data": [
"info=eTactica gateway locator"
]
},

{
"name": "_rme-sg._tcp.local",
        "type": "PTR",
"ttl": 4375,
"target": "eTactica gateway Locator on 
eg-03A19D._rme-sg._tcp.local"
},
{
"name": "eTactica gateway Locator on 
eg-03A19D._rme-sg._tcp.local",
"type": "TXT",
"ttl": 4375,
"data": [
"info=This record is used to help find a 
gateway when using DHCP."
]
}


Is this a bug in umdns? is this a problem with the avahi
advertisements?

Sincerely,
Karl Palsson



[1] Avahi service conf file.


 eTactica gateway Locator on %h
  
   _rme-sg._tcp
   22
   info=This record is used to help find a gateway when using 
DHCP.
  


signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] GitHub and -devel; differentiating between voting committers and random community comments

[Karl Palsson]

"Daniel F. Dickinson"  wrote:
> Hi,
> 
> This isn't my first preference, but I think this is becoming a
> bit of a problem, especially for people not all that familiar
> with who's who in OpenWrt.
> 
> I've noticed that community (vs. voting committers) often jump
> in with (presumably well-meant) advice that might not actually
> match what voting committers want (e.g. on a patch or for
> policy), and for those not familiar with emails and names of
> the voting OpenWrt team this can lead to changing patches or
> PR's in ways that are counter-productive to actually getting
> merged.
> 
> I'm not a voting member myself, so this isn't necessarily going
> to help me get heard, but I'd also hate for someone take me as
> canonical advice in contrast to a voting committer. I know some
> community members can be quite helpful, but others tend to
> sounding authoritative while not being an 'official' openwrt
> team member, which leads to mis-perception (in my view) about
> what the project would like to see.

The comments in github show this for you already:

if it shows "Contributor" it's just "someone" THey might be a
regular contributor, but they're not a committer. if it shows
"Member" they have commit rights.

What people choose to do with that information is up to them
though really.

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] liblua vs. CMake

[Karl Palsson]

Welcome to the joys of lua's packaging, not just in OpenWrt, but
across the bsds and desktop distros as well.

You need "lua" to find it for OpenWrt. (There will be only one
lua) On ~most recent distros, as you may have noticed, this will
however be lua 5.2 or 5.3. On those distros you need "lua5.1, or
lua-5.1 or lua51 to find it, if it's supported at all.

It _might_ be nice if OpenWrt moved everything to versioned lua
installs, it would reduce the patches on quite a lot of packages,
and pave the way for having two versions of lua installed, but
that's "not happening" anytime soon. In the meantime, you're
going to have a bit of a mess of "if it's openwrt, look for lua,
if not, look for lua-5.1 and friends"

Hope that helps,
Karl P


Lev  wrote:
> Hello list,
> 
> 
> I'm still struggling finding liblua in the build system by
> CMake.
> 
> This is a simple executable project and I have this at the top
> of the CMakeLists.txt file:
> 
> cmake_minimum_required (VERSION 3.0)
> 
> project(hmd C)
> 
> SET(CMAKE_INSTALL_PREFIX /)
> 
> IF(NOT LUA_CFLAGS)
>   INCLUDE(FindPkgConfig)
>   pkg_search_module(LUA lua5.1 lua-5.1)
>   message("Lua found cflags: ${LUA_CFLAGS}")
> ENDIF()
> 
> As the build system configures my project, the LUA_CFLAGS gets
> empty. I've seen this snippet in libubox as suggested earlier.
> What I don't really understand, how could this even work? If i
> grep for a file lua5.1.pc or lua-5.1.pc, there is none. What is
> present is lua.pc.
> 
> The difference between libubox and my application is mine is
> just a simple executable, libubox is a library.
> 
> What do I miss?
> 
> 
> Thanks,
> Levente
> 

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage

[Karl Palsson]

David Bauer  wrote:
> The current make-ras.sh image generation script for the ZyXEL
> NBG6617 has portability issues with bash. Because of this,
> factory images are currently not built correctly by the OpenWRT
> buildbots.
> 
> This commit replaces the make-ras.sh by C-written mkrasimage.
> The old script is still kept but can be deleted in the future.

You need to update your commit message, this is no longer the
case.

> 
> The new mkrasimage is also compatible with other ZyXEL devices
> using the ras image-format. This is not tested with a OpenWRT
> build but it correctly builds the header for ZyXEL factory
> images for all devices it is added to.
> 
> Signed-off-by: David Bauer 
> ---
> 
> v2 changes:
>  - Rework image-generation code
>  - Add factory image for NBG6616
>  - Add factory image for NBG6817
> 
>  include/image-commands.mk |  18 +-
>  scripts/make-ras.sh   | 196 ---
>  target/linux/ar71xx/image/generic.mk  |   6 +-
>  target/linux/ipq40xx/image/Makefile   |   2 +-
>  target/linux/ipq806x/image/Makefile   |   6 +-
>  tools/firmware-utils/Makefile |   1 +
>  tools/firmware-utils/src/mkrasimage.c | 474 ++
>  7 files changed, 495 insertions(+), 208 deletions(-)
>  delete mode 100755 scripts/make-ras.sh
>  create mode 100644 tools/firmware-utils/src/mkrasimage.c
> 
> diff --git a/include/image-commands.mk
> b/include/image-commands.mk index 3cc5dc21e1..61ba49de51 100644
> --- a/include/image-commands.mk
> +++ b/include/image-commands.mk
> @@ -49,17 +49,17 @@ define Build/eva-image
>   mv $@.new $@
>  endef
>  
> -define Build/make-ras
> +define Build/zyxel-ras-image
>   let \
>   newsize="$(subst k,* 1024,$(RAS_ROOTFS_SIZE))"; \
> - $(TOPDIR)/scripts/make-ras.sh \
> - --board $(RAS_BOARD) \
> - --version $(RAS_VERSION) \
> - --kernel $(call 
> param_get_default,kernel,$(1),$(IMAGE_KERNEL)) \
> - --rootfs $@ \
> - --rootfssize $$newsize \
> - $@.new
> - @mv $@.new $@
> + $(STAGING_DIR_HOST)/bin/mkrasimage \
> + -b $(RAS_BOARD) \
> + -v $(RAS_VERSION) \
> + -r $@ \
> + -s $$newsize \
> + -o $@.new \
> + $(if $(findstring seperate-kernel,$(word 1,$(1))),-k 
> $(IMAGE_KERNEL)) \
> + && mv $@.new $@
>  endef
>  
>  define Build/mkbuffaloimg
> diff --git a/scripts/make-ras.sh b/scripts/make-ras.sh deleted
> file mode 100755 index ccddaa0016..00
> --- a/scripts/make-ras.sh
> +++ /dev/null
> @@ -1,196 +0,0 @@
> -#!/usr/bin/env bash
> -#
> -# --- ZyXEL header format ---
> -# Original Version by Benjamin Berg 
> -#
> -# The firmware image prefixed with a header (which is written into the MTD 
> device).
> -# The header is one erase block (~64KiB) in size, but the checksum only 
> convers the
> -# first 2KiB. Padding is 0xff. All integers are in big-endian.
> -#
> -# The checksum is always a 16-Bit System V checksum (sum -s) stored in a 
> 32-Bit integer.
> -#
> -#   4 bytes:  checksum of the rootfs image
> -#   4 bytes:  length of the contained rootfs image file (big endian)
> -#  32 bytes:  Firmware Version string (NUL terminated, 0xff padded)
> -#   4 bytes:  checksum over the header partition (big endian - see below)
> -#  32 bytes:  Model (e.g. "NBG6617", NUL termiated, 0xff padded)
> -#   4 bytes:  checksum of the kernel partition
> -#   4 bytes:  length of the contained kernel image file (big endian)
> -#  rest: 0xff padding
> -#
> -# The checksums are calculated by adding up all bytes and if a 16bit
> -# overflow occurs, one is added and the sum is masked to 16 bit:
> -#   csum = csum + databyte; if (csum > 0x) { csum += 1; csum &= 0x };
> -# Should the file have an odd number of bytes then the byte len-0x800 is
> -# used additionally.
> -#
> -# The checksum for the header is calculated over the first 2048 bytes with
> -# the rootfs image checksum as the placeholder during calculation.
> -#
> -# The header is padded with 0xff to the erase block size of the device.
> -#
> -board=""
> -version=""
> -kernel=""
> -rootfs=""
> -outfile=""
> -err=""
> -
> -while [ "$1" ]; do
> - case "$1" in
> - "--board")
> - board="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--version")
> - version="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--kernel")
> - kernel="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--rootfs")
> - rootfs="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--rootfssize")
> - rootfssize="$2"
> - shift
> - 

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020

[Karl Palsson]

Rosen Penev  wrote:
> On Sat, Aug 18, 2018 at 5:04 AM David Bauer
>  wrote:
> >
> > Sysupgrading to ath79 from ar71xx currently fails because of mismatching
> > supported_devices. ar71xx is expecting "tl-mr3020" which is missing in
> > the ath79 image. Upgrading from ath79 is unaffected, as the image
> > contains the old string for ar71xx and the new one coming from the
> > device-tree.
> NAK from me.

No explanation?  Just NAK? That's helpful.

Sincerely,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020

[Karl Palsson]

David Bauer  wrote:
> Sysupgrading to ath79 from ar71xx currently fails because of
> mismatching supported_devices. ar71xx is expecting "tl-mr3020"
> which is missing in the ath79 image. Upgrading from ath79 is
> unaffected, as the image contains the old string for ar71xx and
> the new one coming from the device-tree.

These were removed as "it was intended to be required to force
when switching "architectures"" I disagreed then, but it got
railed through, so it's good to see I'm not the only one who
thought you should be able to upgrade from ar71xx to ath79 on the
same hardware

See also https://github.com/openwrt/openwrt/pull/1222

Cheers,
Karl P

> 
> Signed-off-by: David Bauer 
> ---
>  target/linux/ath79/image/tiny-tp-link.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/ath79/image/tiny-tp-link.mk
> b/target/linux/ath79/image/tiny-tp-link.mk index
> 6ccc9d7dba..dadcd24b42 100644
> --- a/target/linux/ath79/image/tiny-tp-link.mk
> +++ b/target/linux/ath79/image/tiny-tp-link.mk
> @@ -17,7 +17,7 @@ define Device/tplink_tl-mr3020-v1
>DEVICE_TITLE := TP-LINK TL-MR3020 v1
>DEVICE_PACKAGES := kmod-usb-core kmod-usb-chipidea2 
> kmod-usb-ledtrig-usbport
>TPLINK_HWID := 0x3021
> -  SUPPORTED_DEVICES += tl-mr3020-v1
> +  SUPPORTED_DEVICES += tl-mr3020
>  endef
>  TARGET_DEVICES += tplink_tl-mr3020-v1
>  
> -- 
> 2.18.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] build: add mkrasimage

[Karl Palsson]

David Bauer  wrote:
> The current make-ras.sh image generation script for the ZyXEL
> NBG6617 has portability issues with bash. Because of this,
> factory images are currently not built correctly by the OpenWRT
> buildbots.
> 
> This commit replaces the make-ras.sh by C-written mkrasimage.
> The old script is still kept but can be deleted in the future.

1) how bad are the portability issues that you felt
reimplementing in _C_ was the best path? 2) if it's that bad, why
keep it? How will future people knwo what to use. Either get rid
of it, or fix it.

Cheers,
Karl P

> 
> Signed-off-by: David Bauer 
> ---
>  include/image-commands.mk |  13 +
>  target/linux/ipq40xx/image/Makefile   |   2 +-
>  tools/firmware-utils/Makefile |   1 +
>  tools/firmware-utils/src/mkrasimage.c | 374 ++
>  4 files changed, 389 insertions(+), 1 deletion(-)
>  create mode 100644 tools/firmware-utils/src/mkrasimage.c
> 
> diff --git a/include/image-commands.mk
> b/include/image-commands.mk index 3cc5dc21e1..bb5fe46e1a 100644
> --- a/include/image-commands.mk
> +++ b/include/image-commands.mk
> @@ -62,6 +62,19 @@ define Build/make-ras
>   @mv $@.new $@
>  endef
>  
> +define Build/zyxel-ras-image
> + let \
> + newsize="$(subst k,* 1024,$(RAS_ROOTFS_SIZE))"; \
> + $(STAGING_DIR_HOST)/bin/mkrasimage \
> + -b $(RAS_BOARD) \
> + -v $(RAS_VERSION) \
> + -k $(call 
> param_get_default,kernel,$(1),$(IMAGE_KERNEL)) \
> + -r $@ \
> + -s $$newsize \
> + -o $@.new
> + @mv $@.new $@
> +endef
> +
>  define Build/mkbuffaloimg
>   $(STAGING_DIR_HOST)/bin/mkbuffaloimg -B $(BOARDNAME) \
>   -R $$(($(subst k, * 1024,$(ROOTFS_SIZE \
> diff --git a/target/linux/ipq40xx/image/Makefile
> b/target/linux/ipq40xx/image/Makefile index
> d1ee1004fd..6e4125db0b 100644
> --- a/target/linux/ipq40xx/image/Makefile
> +++ b/target/linux/ipq40xx/image/Makefile
> @@ -221,7 +221,7 @@ define Device/zyxel_nbg6617
>  #at least as large as the one of the initial firmware image (not the 
> current
>  #one on the device). This only applies to the Web-UI, the bootlaoder 
> ignores
>  #this minimum-size. However, the larger image can be flashed both ways.
> - IMAGE/factory.bin := append-rootfs | pad-rootfs | check-size 
> (ROOTFS_SIZE) | make-ras
> + IMAGE/factory.bin := append-rootfs | pad-rootfs | check-size 
> (ROOTFS_SIZE) | zyxel-ras-image
>   IMAGE/sysupgrade.bin/squashfs := append-rootfs | pad-rootfs | 
> check-size (ROOTFS_SIZE) | sysupgrade-tar rootfs=@ | append-metadata
>   DEVICE_PACKAGES := ipq-wifi-zyxel_nbg6617 uboot-envtools
>  endef
> diff --git a/tools/firmware-utils/Makefile
> b/tools/firmware-utils/Makefile index 436a43794c..00917c3417
> 100644
> --- a/tools/firmware-utils/Makefile
> +++ b/tools/firmware-utils/Makefile
> @@ -70,6 +70,7 @@ define Host/Compile
>   $(call cc,fix-u-media-header cyg_crc32,-Wall)
>   $(call cc,hcsmakeimage bcmalgo)
>   $(call cc,mkporayfw, -Wall)
> + $(call cc,mkrasimage, --std=gnu99)
>   $(call cc,mkhilinkfw, -lcrypto)
>   $(call cc,mkdcs932, -Wall)
>   $(call cc,mkheader_gemtek,-lz)
> diff --git a/tools/firmware-utils/src/mkrasimage.c
> b/tools/firmware-utils/src/mkrasimage.c new file mode 100644
> index 00..1cac7b5da9
> --- /dev/null
> +++ b/tools/firmware-utils/src/mkrasimage.c
> @@ -0,0 +1,374 @@
> +/*
> + * --- ZyXEL header format ---
> + * Original Version by Benjamin Berg 
> + * C implementation based on generation-script by Christian Lamparter 
> 
> + *
> + * The firmware image prefixed with a header (which is written into the MTD 
> device).
> + * The header is one erase block (~64KiB) in size, but the checksum only 
> convers the
> + * first 2KiB. Padding is 0xff. All integers are in big-endian.
> + *
> + * The checksum is always a 16-Bit System V checksum (sum -s) stored in a 
> 32-Bit integer.
> + *
> + *   4 bytes:  checksum of the rootfs image
> + *   4 bytes:  length of the contained rootfs image file (big endian)
> + *  32 bytes:  Firmware Version string (NUL terminated, 0xff padded)
> + *   4 bytes:  checksum over the header partition (big endian - see below)
> + *  64 bytes:  Model (e.g. "NBG6617", NUL termiated, 0xff padded)
> + *   4 bytes:  checksum of the kernel partition
> + *   4 bytes:  length of the contained kernel image file (big endian)
> + *  rest:  0xff padding (To erase block size)
> + *
> + * The checksums are calculated by adding up all bytes and if a 16bit
> + * overflow occurs, one is added and the sum is masked to 16 bit:
> + *   csum = csum + databyte; if (csum > 0x) { csum += 1; csum &= 0x 
> };
> + * Should the file have an odd number of bytes then the byte len-0x800 is
> + * used additionally.
> + *
> + * The checksum for the header is calculated over the first 2048 bytes with
> + 

Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus

[Karl Palsson]

"Daniel F. Dickinson"  wrote:
> Posting on list as I think the discussion should include as
> folks as possible in the discussion.
> 
> https://github.com/openwrt/packages/issues/6745
> 
> > Especially when getting started with OpenWrt finding things in menuconfig 
> > is complicated by the second level menus that are sometimes used and 
> > sometimes not, even when the category exists.
> > 
> > Further not everything fits neatly in a category.
> > 
> > Finally when, years ago, I tried to improve the situation the above 
> > resulted in titles that I think make it harder to find things (in 
> > retrospect).
> > 
> > Therefore I would like to do a mass removal of the second-level menus, 
> > leaving only the broad top-level categories like 'net', and 'utlitiies'.
> > 
> > Thoughts?

I agree that the earlier attempts at adding more categories was
probably unhelpful, and just required more places to try checking
for things. I think there's still room for _some_ second level
menus (all of the iotivity stuff is fine in it's own menu for
instance) , but they would need to have a "maintainer" of sorts,
to try and sheperd new packages into that menu. You're only
talking about the net/utilities/libraries trees right?
luci/languages/kernel are all well maintained.

What I honestly think is the biggest missing thing sometimes is
proper package descriptions.

I'd support undoing many of the nestings that were done,
especially under networking. Especially the vague ones like "file
transfer" and "bit torrent" and "download managers" and the
"routing" ""vpn" "wwan" "firewall tunnel

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4] base-files: make wifi report unknown command

[Karl Palsson]

Thibaut VARÈNE   wrote:
> Avoid having /sbin/wifi silently ignore unknown keywords and
> execute "up"; instead display the help message and exit with an
> error.
> 
> Spell out the "up" keyword (which has users), add it to usage
> output, and preserve the implicit assumption that runing
> /sbin/wifi without argument performs "up".
> 
> Signed-off-by: Thibaut VARÈNE 
> ---
>  package/base-files/files/sbin/wifi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/package/base-files/files/sbin/wifi
> b/package/base-files/files/sbin/wifi index
> 83befc0d6f..f7a10de215 100755
> --- a/package/base-files/files/sbin/wifi
> +++ b/package/base-files/files/sbin/wifi
> @@ -6,7 +6,7 @@
>  
>  usage() {
>   cat < -Usage: $0 [config|down|reload|status]
> +Usage: $0 [config|up|down|reload|status]
>  enables (default), disables or configures devices not yet configured.

so, which one is "enable" is it config, up, down, reload, or
status? Perhaps update this to say which command is the default?

>  EOF
>   exit 1
> @@ -241,5 +241,6 @@ case "$1" in
>   reload) wifi_reload "$2";;
>   reload_legacy) wifi_reload_legacy "$2";;
>   --help|help) usage;;
> - *) ubus call network reload; wifi_updown "enable" "$2";;
> + ''|up) ubus call network reload; wifi_updown "enable" "$2";;
> + *) usage; exit 1;;
>  esac
> -- 
> 2.14.3 (Apple Git-98)
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] watchdog against router crash freezes?

[Karl Palsson]

Marcel Partap  wrote:
> Dear OpenWRT/LEDE team,
> my WNR2200 on fresh 18.06 r7188 frequently dies with LEDs
> frozen.. The device has had some troubles on stock firmware as
> well.
> 
> How do I set up a watchdog to reset the device when it gets
> stuck? I've had a look at freifunk-watchdog, kmod-softdog &
> watchcat packages but couldn't quite figure out a way. Also (to
> my suprise) didn't find anything about watchdogs in the wiki..

https://openwrt.org/docs/guide-developer/ubus/system has watchdog
information, but also, bear in mind that it just uses the normal
kernel infrastructure for watchdogs, so there's no particular
openwrt specific information.

That said, you may be seeing:
https://dev.openwrt.org/ticket/12121 where people have reported
watchdog resets causing hard lockup on and off for a few years.
If that sounds familiar, you could potentially try the patch in
https://github.com/openwrt/openwrt/pull/747 and see if that
helps.

Sincerely,
Karl Palsson

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: make wifi report unknown command

[Karl Palsson]

Jo-Philipp Wich  wrote:
> Hi,
> 
> > respectfully, the behaviour of the "wifi" command is one of the most
> > obtuse parts of openwrt's tooling.  It does "something" with no
> > command output, and responds ~instantly.This is expected
> > behaviour for very few people.  even "wifi asdfasdfa" returns
> > ~instantly, with no warning that it is an unknown command.  Does the
> > command perhaps not take arguments?  What would they be?
> 
> The (implicit) default command could be explicitly spelled out
> as "wifi apply" or similar, mentioned in the usage and called
> when no argument is provided.
> 
> Is that what you were thinking?

Personally I'd like to see the "apply" (or any other name) added,
and the implicit action dropped. Or at the very least, the
implicit action only taken when there are no arguments. At
present, you get the implicit action with no args, and with any
arg that doesn't match some other args. I'd suggest it is more
reasonable that unknown args are not treated as some default,
which is what the original patch suggested. It was definitely
broken however in that the implicit step was no longer available.


Something like this say

This lets "wifi" still do the same as before.
This makes "wifi adsfads" print usage arguments
This makes "wifi enable interfacename" do the same as "wifi
interfacename" did before, if anyone knew about that.

The usage text could/should be expanded still, but hoenstly, I
don't know the difference between them all. What's the difference
between config and detect? should detect be listed in the usage?
what's reload_legacy? when would I want it? Should it be listed
in the usage? What's the difference between enable and reload?
Why is there down but no up? (it's like "enable" but not quite?)

Sincerely,
Karl Palsson

diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi index 83befc0d6f..cbe7e950bd
100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -6,7 +6,7 @@
 
 usage() {
cat <

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: make wifi report unknown command

[Karl Palsson]

John Crispin  wrote:
> 
> 
> On 03/08/18 18:18, Thibaut VARÈNE wrote:
> > Avoid having /sbin/wifi silently ignore unknown keywords and execute
> > "enable"; instead display the help message and exit with an error.
> >
> > Signed-off-by: Thibaut VARÈNE 
> > ---
> >   package/base-files/files/sbin/wifi | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/package/base-files/files/sbin/wifi 
> > b/package/base-files/files/sbin/wifi
> > index 83befc0d6f..09e483ec55 100755
> > --- a/package/base-files/files/sbin/wifi
> > +++ b/package/base-files/files/sbin/wifi
> > @@ -241,5 +241,5 @@ case "$1" in
> > reload) wifi_reload "$2";;
> > reload_legacy) wifi_reload_legacy "$2";;
> > --help|help) usage;;
> > -   *) ubus call network reload; wifi_updown "enable" "$2";;
> > +   *) usage; exit 1;;
> >   esac
> 
> NAK, this changes expected behaviour. i regularly call "wifi"
> to resync my config with runstate.
>      John

respectfully, the behaviour of the "wifi" command is one of the most obtuse 
parts of openwrt's tooling.  It does "something" with no command output, and 
responds ~instantly.This is expected behaviour for very few people.  even 
"wifi asdfasdfa" returns ~instantly, with no warning that it is an unknown 
command.  Does the command perhaps not take arguments?  What would they be?  

Do we _reallly_ have to keep it's behaviour this way? 

What this patch _is_ missing, is a new command to replace the old
"anything but the other commands".

ie, the one that does "ubus call network reload; wifi_updown
"enable" "$2""

Sincerely,
Karl Palsson

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] verbose.mk: quote SUBMAKE options

[Karl Palsson]

Lucian Cristian  wrote:
> On 06.07.2018 14:09, Lucian Cristian wrote:
> > On 06.07.2018 13:03, 李国 wrote:
> >> build openwrt on centos 6 I should use devtoolset-3 to get gcc 4.9, but
> >> it fail when make menuconfig. so I have to give option HOSTCC='gcc
> >> -Wl,--copy-dt-needed-entries' to make. But it passed to sub make to
> >> HOSTCC=gcc as micro SUBMAKE expand to HOSTCC=gcc
> >> -Wl,--copy-dt-needed-entries. This patch fix this issue.
> >>
> >> make -C build menuconfig HOSTCC='gcc -Wl,--copy-dt-needed-entries' V='1'
> >> make: Entering directory `/work/openwrt/openwrt/build'
> >> /opt/rh/devtoolset-3/root/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/ld:
> >> lxdialog/checklist.o: undefined reference to symbol 'acs_map'
> >> //lib64/libtinfo.so.5: error adding symbols: DSO missing from command 
> >> line
> >> collect2: error: ld returned 1 exit status
> >> make[1]: *** [mconf] Error 1
> >> make -s -C scripts/config all CC=gcc -Wl,--copy-dt-needed-entries: build
> >> failed. Please re-run make with -j1 V=s to see what's going on
> >> make: *** [scripts/config/mconf] Error 1
> >> make: Leaving directory `/work/openwrt/openwrt/build'
> >>
> >> Signed-off-by: 李国 
> >> ---
> >>   include/verbose.mk | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/verbose.mk b/include/verbose.mk
> >> index b7e43f7430..e02aefe8dd 100644
> >> --- a/include/verbose.mk
> >> +++ b/include/verbose.mk
> >> @@ -54,7 +54,7 @@ ifeq ($(findstring s,$(OPENWRT_VERBOSE)),)
> >>     else
> >>   SILENT:=>/dev/null $(if $(findstring w,$(OPENWRT_VERBOSE)),,2>&1)
> >>   export QUIET:=1
> >> -    SUBMAKE=cmd() { $(SILENT) $(MAKE) -s $$* < /dev/null || { echo 
> >> "make $$*: build failed. Please re-run make with -j1 V=s to see 
> >> what's going on"; false; } } 8>&1 9>&2; cmd
> >> +    SUBMAKE=cmd() { $(SILENT) $(MAKE) -s "$$@" < /dev/null || { echo 
> >> "make $$*: build failed. Please re-run make with -j1 V=s to see 
> >> what's going on"; false; } } 8>&1 9>&2; cmd
> >>     endif
> >>       .SILENT: $(MAKECMDGOALS)
> >
> > I've just successfully ran make menuconfig on centos 6 with devtoolset-3
> >
> > $ rpm -qa | grep devtoolset
> >
> > devtoolset-3-runtime-3.1-12.el6.x86_64
> > devtoolset-3-libstdc++-devel-4.9.2-6.2.el6.x86_64
> > devtoolset-3-gcc-4.9.2-6.2.el6.x86_64
> > devtoolset-3-binutils-2.24-18.el6.x86_64
> > devtoolset-3-gcc-c++-4.9.2-6.2.el6.x86_64
> >
> > $ scl enable devtoolset-3 bash
> > $ make menuconfig
> >
> >
> > *** End of the configuration.
> > *** Execute 'make' to start the build or try 'make help'.
> >
> 
> I meant to say I've successfully built a target on centos 6
> with devtoolset-3
> 

Right, but it doesn't make the patch wrong at all.  

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uhttpd: add configurable client Cache-Control http header

[Karl Palsson]

> > I just made all my code request js files with ?ver= version
> > suffixes, so that only the right versions were cached.
> 
> Yes i have seen this in luci but not in luci-ng.

well, fix that? :)

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uhttpd: add configurable client Cache-Control http header

[Karl Palsson]

Florian Eckert  wrote:
> I am working with luci-ng. And i have problems with caching
> with the following Browser Edge, Internet-Explorer and Firefox.
> Chrome is working fine. If the javascript or html files have
> changed on the system for example on sysupgrade then the new
> files will not get loaded from uhttpd server. The browsers
> always used the cached version and not the new version from
> uhttpd.
> 
> To fix this tell the uhttpd to send the header Cache-Control
> no-cache on file download. This header tells the browser to
> always check if the file has changed on the server. If the file
> has not changed then the server send a 302 status header. The
> status header 302 tells the browser to load the file from the
> browser cache because nothing has changed. On the other side if
> the file has changed then the browser will deliver the new one.

That _seems_ like an exceptionally big hammer.

I just made all my code request js files with ?ver= version suffixes, so 
that only the right versions were cached.  

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] iputils packaging

[Karl Palsson]

Noah Meyerhans via openwrt-devel
 wrote:
> Some time ago, David
> Heidelberg forked the iputils packages found at
> http://www.skbuff.net/iputils. The fork is maintained at
> https://github.com/iputils/iputils/
> 
> Many Linux distros, including Debian, Ubuntu, Fedora, and
> probably others, have switched to the fork. As the package
> maintainer within Debian, I've found David to be responsive as
> upstream, and have had an easy time integrating all the Debian
> patches back into his repository.
> 
> Is there a reason OpenWRT hasn't switched? I'm happy to send
> patches if they'll be considered.

Perhaps a better question would be, why should they? Personally I
don't find the "some other distros did" to be at all compelling,
but I'd certainly be interested in hearing the _reasoning_ of why
they switched?

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] brcm2708: cosmetic changes

[Karl Palsson]

Christo Nedev  wrote:
> bcm2709: rename kernel.img to image7.img
>   kernel8.img boot in 64 bit mode
>   kernel8-32.img boot in 32 bit mode
>   kernel7.img 32 bit mode
>   kernel.img 32 bit mode
> 

Couldyou perhaps elaborate on the _why_ of your change? The what
of your change is visible in the diff itself.

Cheers,
Karl P

> bcm2710: sort order
> 
> Signed-off-by: Christo Nedev 
> ---
>  target/linux/brcm2708/image/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/brcm2708/image/Makefile
> b/target/linux/brcm2708/image/Makefile index
> 80a019270d..8a94375600 100644
> --- a/target/linux/brcm2708/image/Makefile
> +++ b/target/linux/brcm2708/image/Makefile
> @@ -54,6 +54,7 @@ define Device/Default
>  endef
>  
>  define Device/rpi
> +  KERNEL_IMG := kernel.img
>DEVICE_TITLE := Raspberry Pi B/B+/CM/Zero/ZeroW
>DEVICE_DTS := bcm2708-rpi-b bcm2708-rpi-b-plus bcm2708-rpi-cm 
> bcm2708-rpi-0-w
>SUPPORTED_DEVICES := rpi-b rpi-b-plus rpi-cm rpi-zero rpi-zero-w 
> raspberrypi,model-b raspberrypi,model-b-plus raspberrypi,compute-module-1 
> raspberrypi,model-b-rev2 raspberrypi,model-zero raspberrypi,model-zero-w
> @@ -64,6 +65,7 @@ ifeq ($(SUBTARGET),bcm2708)
>  endif
>  
>  define Device/rpi-2
> +  KERNEL_IMG := kernel7.img
>DEVICE_TITLE := Raspberry Pi 2B/3B/3B+/3CM
>DEVICE_DTS := bcm2709-rpi-2-b bcm2710-rpi-3-b bcm2710-rpi-3-b-plus 
> bcm2710-rpi-cm3
>SUPPORTED_DEVICES := rpi-2-b rpi-3-b rpi-3-b-plus rpi-cm 
> raspberrypi,2-model-b raspberrypi,3-model-b raspberrypi,3-model-b-plus 
> raspberrypi,compute-module-3
> @@ -78,7 +80,7 @@ define Device/rpi-3
>DEVICE_TITLE := Raspberry Pi 3B/3B+
>DEVICE_DTS := broadcom/bcm2710-rpi-3-b broadcom/bcm2710-rpi-3-b-plus
>SUPPORTED_DEVICES := rpi-3-b rpi-3-b-plus raspberrypi,3-model-b 
> raspberrypi,3-model-b-plus
> -  DEVICE_PACKAGES := brcmfmac-firmware-43430-sdio brcmfmac-board-rpi2 
> brcmfmac-firmware-43455-sdio brcmfmac-board-rpi3 kmod-brcmfmac wpad-mini
> +  DEVICE_PACKAGES := brcmfmac-firmware-43430-sdio 
> brcmfmac-firmware-43455-sdio brcmfmac-board-rpi2 brcmfmac-board-rpi3 
> kmod-brcmfmac wpad-mini
>  endef
>  ifeq ($(SUBTARGET),bcm2710)
>TARGET_DEVICES += rpi-3
> -- 
> 2.11.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/listinfo/openwrt-devel

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: Fix WiFi after 5f7396ebef09b224edf08b0bda113613a42f0928

[Karl Palsson]

Rosen Penev  wrote:
> That commit exposed a bug in the DTS files used by mt7621 where
> the wrong reg value for pcie1 (and potentially pcie2) was being
> used. This was causing WiFi failures for interfaces in pcie1.
> 
> eg. 2.4GHz working but not 5GHz.
> 
> As all of these dts entries are already specified in
> mt7621.dtsi, remove them.
> 
> Signed-off-by: Rosen Penev 
> ---
>  target/linux/ramips/dts/DIR-860L-B1.dts  | 4 
>  target/linux/ramips/dts/EW1200.dts   | 4 
>  target/linux/ramips/dts/FIREWRT.dts  | 4 
>  target/linux/ramips/dts/HC5962.dts   | 4 
>  target/linux/ramips/dts/Newifi-D1.dts| 4 
>  target/linux/ramips/dts/Newifi-D2.dts| 4 
>  target/linux/ramips/dts/PBR-M1.dts   | 4 
>  target/linux/ramips/dts/R6220.dts| 4 
>  target/linux/ramips/dts/RE350.dts| 4 
>  target/linux/ramips/dts/RE6500.dts   | 4 
>  target/linux/ramips/dts/SAP-G3200U3.dts  | 4 
>  target/linux/ramips/dts/SK-WB8.dts   | 4 
>  target/linux/ramips/dts/TL-WR902ACV3.dts | 2 --
>  target/linux/ramips/dts/WF-2881.dts  | 4 
>  target/linux/ramips/dts/WITI.dtsi| 4 
>  target/linux/ramips/dts/WNDR3700V5.dts   | 4 
>  target/linux/ramips/dts/WR1200JS.dts | 4 
>  target/linux/ramips/dts/WSR-1166.dts | 4 
>  target/linux/ramips/dts/WSR-600.dts  | 4 
>  target/linux/ramips/dts/ZBT-WE1326.dts   | 4 

Confirmed this fixes missing 2.4g radios on WE1326.

Sincerely,
Karl Palsson 

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Wifi on ZBT-WE1326 broken after commit 5f7396ebef09

[Karl Palsson]

Kristian Evensen  wrote:
> Hello,
> 
> On Tue, May 29, 2018 at 5:24 PM, Kristian Evensen
>  wrote:
> > Carrying a local revert of the commit in question is always a
> > possibility (and does not seem to have any unintentional
> > side-effects), but I would rather try to fix the problem properly.
> > Does anyone have any suggestions on where to look?
> 
> Banging my head in the wall for some hours seems to have
> resulted in a solution.
> 
> The default PCIe interrupt mapping in mt7621.dtsi is wrong for
> WE1326. After taking a look at which IRQs were set up before
> commit 5f7396ebef09, I noticed that the IRQs in mt7621.dtsi.
> After adding the following to the pcie-node of ZBT-WE1326.dts,
> wifi is working fine:
> 
> interrupt-map = <0x1 0 0 1  GIC_SHARED 24
> IRQ_TYPE_LEVEL_HIGH>,
>  <0x2 0 0 1  GIC_SHARED 25 
> IRQ_TYPE_LEVEL_HIGH>;
> 
> I will prepare and submit a patch.


There were a few people on this today it seems :)

See also https://github.com/openwrt/mt76/issues/173 and
https://forum.lede-project.org/t/mt76-stopped-working-with-latest-updates/14623/41

There's a patch at the bottom of that from mangix/neheb that
removes from overrides that just set 0s, and that fixed it for my
we1326

Sincerely,
Karl P



signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] libevent2: update to version 2.1.8

[Karl Palsson]

Eneas U de Queiroz via openwrt-devel
 wrote:
> The sender domain has a DMARC Reject/Quarantine policy which
> disallows sending mailing list messages using the original
> "From" header.
> 
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.This version is
> compatible with openssl-1.1.0.
> 


a) I don't think that message is right, did you copy the text
from your other email about updating openssl? b) packages are
maintained on github.com/openwrt/packages, send a PR there. c)
libevent2.1 is not binary compatible with libevent2, and has a
different sonumber. I'd rather much prefer seeing a separate
package for libevent2.1 rather than trying to just replace
libevent2.0 with 2.1

Cheers,
Karl P


> Signed-off-by: Eneas U de Queiroz 
> ---
>  package/libs/libevent2/Makefile | 35 ---
>  1 file changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/package/libs/libevent2/Makefile
> b/package/libs/libevent2/Makefile index 5d56f37c51..12295f657c
> 100644
> --- a/package/libs/libevent2/Makefile
> +++ b/package/libs/libevent2/Makefile
> @@ -8,12 +8,16 @@
>  include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=libevent2
> -PKG_VERSION:=2.0.22
> +PKG_VERSION:=2.1.8

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] regarding procd and manually controlling hardware watchdog

[Karl Palsson]

Valent Turkovic  wrote:
> Using internal hardware watchdog would mean that we could
> remove external hardware watchdog that we currently have on
> some customers products. I'm working on embedded products based
> upon OpenWrt and mips hardware that use usb lte modems,
> openvpn, spi flash memory (actually now replaced with onboard
> emmc drive)...
> 
> These are very complex devices when compared to "standard"
> embedded devices, and with complexity you get more issues. We
> have software watchdog scripts that try to fix things
> automatically, and last resort is to reboot the device.
> 
> Have you even seen that device doesn't reboot after giving it
> reboot command? Well, I have seen it. It is rare, but still it
> happens some times. So if reboot command fails for three times
> in a row then we stop tickling external watchdog which cuts
> power for 1 second.

yes! see https://github.com/openwrt/openwrt/pull/747
and
https://dev.openwrt.org/ticket/12121
and
https://dev.openwrt.org/ticket/17839#comment:51
and also, for what's likely the same issue...
errata ERR007117 for IMX6DQCE

though, honestly, these are cases where the _watchdog_ is the
problem. You _need_ to do a "nice" reboot, watchdog reboots make
it worse.

> 
> Now I would tickle internal watchdog in same way. Other way
> would be to just issue ubus command to stop tickling watchdog
> but when system (very rarely) get into this weird state I'm not
> sure if ubus commands would work.
> 
> Because our devices are spread all around Germany it is better
> to have a really good and redundant watchdog then to drive
> somewhere for few hundred kilometres.
> 
> Hope this satisfies your curiosity, John.
> 
> Cheers,
> Valent.
> 
> On Fri, Mar 16, 2018 at 8:14 PM, John Crispin
>  wrote:
> >
> >
> > On 16/03/18 19:48, Valent Turkovic wrote:
> >>
> >> Hi,
> >> i just finished writing a detailed blog post regarding how to use
> >> hardware watchdog and how to manually take control over from procd:
> >>
> >> http://kernelreloaded.com/manually-controlling-openwrt-hardware-watchdog/
> >>
> >> Over the years there were few questions regarding this and first there
> >> was no way to do it (missing magicclose feature) and documentation was
> >> lacking even after it was implemented.
> >>
> >> Hopefully this helps some people.
> >>
> >> If you have any suggestions or comments regarding this blog post feel
> >> free to write here or contact me directly.
> >>
> >> Cheers,
> >> Valent.
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> > Hey,
> >
> > just coz I am curious, why would you want to manually control the WDT ?
> >
> > John
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Karl Palsson]

Felix Fietkau  wrote:
> On 2018-03-04 16:15, Hauke Mehrtens wrote:
> > There is also a pull request for busybox 2.28.1 at github, this will
> > probably also introduce some more regressions, so I am not sure if we
> > should take it before or after the release.
> > https://github.com/openwrt/openwrt/pull/733
> > I do not have a real opinion on this and I am probably the wrong person
> > to judge this.
> Anything useful in there?
> 

Actually getting NTP resolution if you have any unreachable
addresses listed? (ok, doesn't happen for everyone) NTP is _far_
more resilient in the face of problems with upstreams than it was
in 1.27 and 1.26. 1.25 worked well, but for different reasons :)

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] kernel version status

[Karl Palsson]

Hauke Mehrtens  wrote:
> The following targets are on kernel 4.4 and will probably not
> be included in the next release:
> * gemini

This is a platform that upstream seems to be actually working on,
would it not be at least polite to keep it alive while it's
landing in mainline? I don't have any hardware or care myself, it
just seems odd to kill the one that's being worked on.

Cheers,
Karl P


signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Karl Palsson]

Philip Prindeville <phil...@redfish-solutions.com> wrote:
> 
> 
> In a perfect world, no one should ever have to build with
> patches, anything in files/, cherry-picked commits, etc.
> Everything would be expressed in the .config (or
> kernel-config).

I think this is probably the root of all the discussion. I agree
with you that most people shouldn't want patches, but I think
it's rather silly to say that it should all be via .config.
Putting things in files/ is vastly easier and more flexible than
trying to create something for everyone in makefile and kconfig
syntax!

I'd generally rather see a lot _less_ of things created via an
ever expanding .config and _more_ local customizations applied as
local customizations :)

Cheers,
Karl Palsson



signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Toolchain for armv7-ar?

[Karl Palsson]

That part is armv7-m (not -a, not -r). They don't generally run
linux at all, so don't have toolchains targetting linux, and
don't generally have existing targets in openwrt.

You _can_ run linux on them, but it's a fa bigger task than
just, "which toolchain do I need to select in menuconfig"

Cheers,
Karl P

Ajay Garg  wrote:
> Experts,
> 
> Waiting for your kind reply/replies.
> 
> 
> Thanks and Regards,
> Ajay
> 
> On 7 Nov 2017 11:22 a.m., "Ajay Garg" 
> wrote:
> 
> > Hi All.
> >
> > I have been trying to build the toolchain+packages (especially openssl)
> > using openwrt, but have been unable to do so for a armv7-ar architecture.
> >
> > The processor on our SOC is
> > https://www.digikey.com/product-detail/en/microchip-
> > technology/ATSAM4E8CA-AUR/ATSAM4E8CA-AURCT-ND/4140758
> >
> > So, is there an (already existing) configuration (in "make menuconfig", or
> > otherwise) that builds everything (toolchain plus packages) for armv7-ar?
> >
> >
> > Will be grateful to listen from you experts.
> >
> >
> > Thanks and Regards,
> > Ajay
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding

[Karl Palsson]

Hannu Nyman  wrote:
> Zoltan HERPAI kirjoitti 26.10.2017 klo 18:41:
> > + -
> > +  * 2 oz. Orange Juice Combine all juices in a
> > +  * 2 oz. Pineapple Juice  tall glass filled with
> > +  * 2 oz. Grapefruit Juice ice, stir well.
> > +  * 2 oz. Cranberry Juice
> > + -
> 
> 
> Still promoting the drink recipe although the voting is clearly
> going against release names and also all given feedback about
> drinks has been negative?

Not all.  I quite like the drinks, I was just strongly against going back to 
the old name. right now.  

When DD was chosen it was far from 100% one way or the other too.

Cheers,
Karl P



signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] merge: add OpenWrt branding

[Karl Palsson]

Zoltan HERPAI  wrote:
> Given that we've decided to sail under the same flag for the
> benefit of the whole community, and acknowledge the
> achievements of the LEDE project, let's start the final steps
> of the merge.
> 
> The git and other sources are untouched until the infra merge.
> 


I'd like to leave Designated Driver as the period of time for
OpenWrt's trunk branch before LEDE, and have "something
different" for the new path going forward. The YY.MM naming is
boring, but functional. Alphabetical names are fine too, but I
don't think it should go back to the old name.

Sincerely,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if upstream network goes down

[Karl Palsson]

I've been advised this is "expected" though I find it
disappointing, as you do.

It's agreed that this behaviour is "non optimal" for various use
cases, and it was suggested that it could be possible to provider
better fallback behaviour by modifying hostapd. It's currently
prioritizing the STA mode, and keeps rescanning and trying to
associate, which blocks the AP from coming up.

You can see the same behaviour if you enter the wrong password
for the network you're trying to attach to. It will continually
retry the bad password and never bring up the AP.

As far as getting worked on, the general response was, "use two
radios if you want two networks dummy" which was, accurate
perhaps, but... unhelpful :)

Sincerely,
Karl Palsson


Nick Malyon <n...@fishun.co.uk> wrote:
> Hi all,
> 
> I tried to open the following bug report but Trac's spam filter
> wouldn't let me, so I thought I'd raise it on the mailing list
> to see what you think...
> 
> I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm
> using it to provide a WiFi access point to my phone/tablet
> while I travel, and it's acting as a WiFi client for the
> various hostels I visit.
> 
> If you configure it as a wifi client with a wwan interface
> using the LuCI scan/join wizard, and then you configure a wifi
> access point on the same radio, the router works as expected
> and when you connect to the router's AP, you get Internet via
> the client connection.
> 
> However, if you move out of range of the network the router is
> a client of, or if it goes down, when you power off the OpenWrt
> router and power back on, the access point won't come up.
> 
> The AP will only come up if the client network you configured
> is also working; so you have no way to connect to the router
> over wifi, and no way to reconfigure the router, if that client
> network is down or out of range.
> 
> This is a particular problem for a travel router because it
> will often move it out of range of the original upstream
> network, and you may only have a wifi-capable device with which
> to reconfigure it.
> 
> The Ethernet port on the router does remain active, so I can
> tell it does actually boot. It's just the radio that doesn't
> come up. I managed to get back in range of a network once, and
> the router worked as expected.
> 
> It doesn't matter whether the AP or client connection are
> configured first or second on the radio interface, and,
> unticking "bring up on boot" for the wwan interface has no
> effect on the behaviour.
> 
> Steps to reproduce: Connect the router to a wifi network as a
> client using the Join wizard. Add a wifi master-mode access
> point on the same radio interface. Verify you can access the
> Internet by joining the router's new master AP. Reboot the
> router with the original network it was a client of turned off.
> Notice the router's AP you configured never comes up.
> 
> Expected behaviour: The master access point of the router
> should always come up, regardless of the availability of the
> client network.
> 
> If anyone has a workaround that would be great — currently I
> managed to get back in range of a network to make it accessible
> again, and now I run from batteries and delete the wifi client
> configuration every night before the jungle power goes out.
> 
> If this is indeed a bug, if you could please raise it in Trac
> for me — sorry, I get a "rejected due to possible spam" error,
> maybe because of my location.
> 
> Many thanks!
> - Nick
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] LED uci policy for not actively used LEDs

[Karl Palsson]

Mathias Kresin  wrote:
> 2016-11-10 16:41 GMT+01:00 Jo-Philipp Wich :
> > Hi Karl,
> >
> > I think there is not much speaking against making the led init script
> > run earlier. I think it would make sense to have it START=11, right
> > after /etc/init.d/boot.
> 
> I've a TDW-8980 here, where the ath9k driver acts as GPIO
> controller for the wireless LED [0]. The wireless led is
> populated to sysfs only after the ath9k driver is loaded. This
> might take some time, since the ath9k EEPROM needs to be loaded
> from flash first to fixup an invalid PCI vendor and device id.
> 
> Long story short, changing the START param might lead to a
> start of the led init script before all referenced leds are
> available in sysfs. At the moment I see this issue already on
> the TDW-8980 on first boot. And yes, I know that a propper fix
> would be some kind of hotplug script.
> 

hehe, it's almost like a pile of shell scripts is a problematic
way of ordering startup, and we should build something that can
handle dependencies of interrelated items or something

hang on...

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] LED uci policy for not actively used LEDs

[Karl Palsson]

Given that the current leds init script only looks for some
explicit values, I've done the following to have a led _listed_
in the UCI file, and available to leds.sh, but not actually
touched by the init script...


>  ucidef_set_led_default "etactica" "etactica" "eg200:red:etactica" "ignored"

It's non-ideal, but the current init scripts run so late
(S96) that it's annoying when something is already using the LED,
and the init script comes along and sets it's "default" value.

Cheers,
Karl P

Jo-Philipp Wich  wrote:
> Hi Sven,
> 
> imho it is preferable to have usable, but inactive LEDs
> available by default in the system configuration.
> 
> ~ Jo
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Package updates in the for-15.05 branch (libuv)

[Karl Palsson]

libuv was recently udpated too:
https://github.com/openwrt/packages/commit/d8d457e52c2560bab4cf49182762bb4a8fe6019c

from 1.4.2 to 1.9.1, though fortunately that at least seems to be
ABI compatible:
https://abi-laboratory.pro/tracker/timeline/libuv/

I'm concerned that given the lack of release from both LEDE and
OpenWrt, people are starting to treat the for-15.05 branch like a
free for all "mainline" branch again.

Karl Palsson <ka...@tweak.net.au> wrote:
> 
> Again, we're getting major version package updates in the
> stable for-15.05 branch. haproxy has just been updated from
> 1.5.x to 1.6.x, with no pull request, no mailing list
> discussion and by a committer without a proper name.
> 
> Again, if packages in the stable release aren't enough for you,
> _use your own feed_ and stop dumping major changes on people
> using a stable branch. The commit updating haproxy had to be
> immediately followed with fixup commits _already_
> 
> https://github.com/openwrt/packages/commit/bec6d8fc8d3f0a18ab965933e4b9187c30aab743
> 
> What's going on?!
> 
> Sincerely,
> Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Package updates in the for-15.05 branch (haproxy)

[Karl Palsson]

Again, we're getting major version package updates in the stable
for-15.05 branch. haproxy has just been updated from 1.5.x to
1.6.x, with no pull request, no mailing list discussion and by a
committer without a proper name.

Again, if packages in the stable release aren't enough for you,
_use your own feed_ and stop dumping major changes on people
using a stable branch. The commit updating haproxy had to be
immediately followed with fixup commits _already_

https://github.com/openwrt/packages/commit/bec6d8fc8d3f0a18ab965933e4b9187c30aab743

What's going on?!

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Why was libwebswocekts bumped in the for-15.05 branch?

[Karl Palsson]

It seems highly inappropriate to bump a package to a completely
incompatible version in the stable 15.05 branch. It was always
beaten into me that the only updates for packages in stable
branches were for point releases and bugfixes. Bumping
libwebsockets to the _very_ incompatible 2.x from the 1.3 release
that had been stable in the 15.05 branch makes no sense to me,
and I see no emails even complaining about the old version in
15.05, let alone asking for a new one.

Ref:
https://github.com/openwrt/packages/commit/e245e2b8246d0d25892d3dc2af0d3834ef95a02e

If this is for some project of your own, please use your own
private feed instead of trampling over everyone's stable branch.
If the stable branch is too old, perhaps consider whether a new
release is due.

Re ABI compatibility:
https://libwebsockets.org/abi/timeline/libwebsockets/index.html
the version you've updated from is so different it's not even
listed on the page!

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] odhcp sending RAs to wrong interface

[Karl Palsson]

"Brian J. Murrell"  wrote:
> I have an OpenWRT router that has been running stably for many
> many (many!) months if not years on BB (r42625).
> 
> When I reboot it, it sends a couple of initial RAs to the
> br-lan interface but subsequently switches to sending them out
> of (one of) the WAN interfaces.
> 
> To be clear, it is sending the RAs that should be going to
> br-lan to wan0 which is eth0.2.
> 
> Restarting odhcpd doesn't even fix it. It continues to send the
> RAs to the WAN interface.
> 
> Some configuration files:
> 
> #  cat /etc/config/dhcp
> 
> 
> config dhcp 'wan0'
> option interface 'wan0'
> option ignore '1'
> 
> config dhcp 'wan1'
> option ignore '1'
> option interface 'wan1'
> option dynamicdhcp '0'
> 


Note that odhcpd doesn't actually observe that "ignore" setting.
See http://patchwork.ozlabs.org/patch/676305/ (and maybe help
push for it to be actually merged)

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] odhcpd [PATCHv2 3/3] Respect interface "ignore" settings as documented.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

The "ignore" option is correctly loaded.  Actually observe it as
documented.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
Changes since v1:
 * nothing, no feedback received on this item

 src/config.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/config.c b/src/config.c
index ef51112..a1b6ab7 100644
--- a/src/config.c
+++ b/src/config.c
@@ -695,10 +695,10 @@ void odhcpd_reload(void)
i->ndp = (master && master->ndp == 
RELAYD_RELAY) ?
RELAYD_RELAY : RELAYD_DISABLED;
 
-   setup_router_interface(i, true);
-   setup_dhcpv6_interface(i, true);
-   setup_ndp_interface(i, true);
-   setup_dhcpv4_interface(i, true);
+   setup_router_interface(i, !i->ignore);
+   setup_dhcpv6_interface(i, !i->ignore);
+   setup_ndp_interface(i, !i->ignore);
+   setup_dhcpv4_interface(i, !i->ignore);
} else {
close_interface(i);
}
-- 
2.4.11
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] odhcpd [PATCHv2 2/3] remove superfluous log output.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Drop pointless syslog.  The single line just doubles the amount of lines
logged to syslog without adding any value.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
Change since v1:
 Nothing

 src/odhcpd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index 4341369..e83a700 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -465,7 +465,6 @@ static void odhcpd_receive_packets(struct uloop_fd *u, 
_unused unsigned int even
else if (addr.in.sin_family == AF_INET)
inet_ntop(AF_INET, _addr, ipbuf, 
sizeof(ipbuf));
 
-   syslog(LOG_DEBUG, "--");
syslog(LOG_DEBUG, "Received %li Bytes from %s%%%s", (long)len,
ipbuf, (iface) ? iface->ifname : "netlink");
 
-- 
2.4.11
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] odhcpd: [PATCHv2 1/3] enable loglevel setting via command line

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Currently the loglevel is hardcoded to LOG_WARNING, even though there is
debug log messages.  Allow setting the loglevel via cli option.
Include basic help text because we're adding command line options.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---

Changes since v1:
 Use command line arg instead of env var.

 src/odhcpd.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index 74830ac..4341369 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -54,11 +54,33 @@ static void sighandler(_unused int signal)
uloop_end();
 }
 
+static void print_usage(const char *app)
+{
+   printf(
+   "== %s Usage ==\n\n"
+"  -h, --help   Print this help\n"
+"  -l level Specify log level 0..7 (default %d)\n",
+   app, LOG_WARNING
+   );
+}
 
-int main()
+int main(int argc, char **argv)
 {
openlog("odhcpd", LOG_PERROR | LOG_PID, LOG_DAEMON);
-   setlogmask(LOG_UPTO(LOG_WARNING));
+   int opt;
+   int log_level = LOG_WARNING;
+   while ((opt = getopt(argc, argv, "hl:")) != -1) {
+   switch (opt) {
+   case 'h':
+   print_usage(argv[0]);
+   return 0;
+   case 'l':
+   log_level = atoi(optarg);
+   fprintf(stderr, "Log level set to %d\n", log_level);
+   break;
+   }
+   }
+   setlogmask(LOG_UPTO(log_level));
uloop_init();
 
if (getuid() != 0) {
-- 
2.4.11
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] odhcpd: [PATCH 3/3] Respect interface "ignore" settings as documented.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

The "ignore" option is correctly loaded.  Actually observe it as
documented.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---

 src/config.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/config.c b/src/config.c
index ef51112..a1b6ab7 100644
--- a/src/config.c
+++ b/src/config.c
@@ -695,10 +695,10 @@ void odhcpd_reload(void)
i->ndp = (master && master->ndp == 
RELAYD_RELAY) ?
RELAYD_RELAY : RELAYD_DISABLED;
 
-   setup_router_interface(i, true);
-   setup_dhcpv6_interface(i, true);
-   setup_ndp_interface(i, true);
-   setup_dhcpv4_interface(i, true);
+   setup_router_interface(i, !i->ignore);
+   setup_dhcpv6_interface(i, !i->ignore);
+   setup_ndp_interface(i, !i->ignore);
+   setup_dhcpv4_interface(i, !i->ignore);
} else {
close_interface(i);
}
-- 
2.4.11
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] odhcpd: [PATCH 1/3] enable loglevel setting via envvar ODHCPD_LOG_LEVEL

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Currently the loglevel is hardcoded to LOG_WARNING, even though there is
debug log messages.  Allow an env var to control the log threshold.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 src/odhcpd.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index 74830ac..c51cfa1 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -58,7 +58,21 @@ static void sighandler(_unused int signal)
 int main()
 {
openlog("odhcpd", LOG_PERROR | LOG_PID, LOG_DAEMON);
-   setlogmask(LOG_UPTO(LOG_WARNING));
+   char *env_log_level = getenv("ODHCPD_LOG_LEVEL");
+   int log_level = LOG_WARNING;
+   if (env_log_level) {
+   char *end;
+   errno = 0;
+   long temp = strtol(env_log_level, , 0);
+   if (end == env_log_level || *end != '\0'
+   || ((temp == LONG_MIN || temp == LONG_MAX) && errno == 
ERANGE)
+   || (log_level > LOG_DEBUG) || log_level < LOG_EMERG) {
+   syslog(LOG_ERR, "ODHCPD_LOG_LEVEL envvar was invalid");
+   } else {
+   log_level = temp;
+   }
+   }
+   setlogmask(LOG_UPTO(log_level));
uloop_init();
 
if (getuid() != 0) {
-- 
2.4.11
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] odhcpd: [PATCH 2/3] remove superfluous log output.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Drop pointless syslog.  The single line just doubles the amount of lines
logged to syslog without adding any value.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 src/odhcpd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index c51cfa1..50f3c9f 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -457,7 +457,6 @@ static void odhcpd_receive_packets(struct uloop_fd *u, 
_unused unsigned int even
else if (addr.in.sin_family == AF_INET)
inet_ntop(AF_INET, _addr, ipbuf, 
sizeof(ipbuf));
 
-   syslog(LOG_DEBUG, "--");
syslog(LOG_DEBUG, "Received %li Bytes from %s%%%s", (long)len,
ipbuf, (iface) ? iface->ifname : "netlink");
 
-- 
2.4.11
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] procd: uClibc O_PATH backwards compatibility fixes

[Karl Palsson]

Does this actually preserve what O_PATH implies or does it just
make it compile properly when people use the O_PATH attribute?

Cheers,
Karl P


Hans Dedecker  wrote:
> Signed-off-by: Hans Dedecker 
> ---
>  inittab.c | 4 
>  utils/utils.c | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/inittab.c b/inittab.c
> index 6dde11a..ae2c431 100644
> --- a/inittab.c
> +++ b/inittab.c
> @@ -31,6 +31,10 @@
>  #include "procd.h"
>  #include "rcS.h"
>  
> +#ifndef O_PATH
> +#define O_PATH   01000
> +#endif
> +
>  #define TAG_ID   0
>  #define TAG_RUNLVL   1
>  #define TAG_ACTION   2
> diff --git a/utils/utils.c b/utils/utils.c
> index 8f14aad..e239eda 100644
> --- a/utils/utils.c
> +++ b/utils/utils.c
> @@ -26,6 +26,10 @@
>  
>  #include "../log.h"
>  
> +#ifndef O_PATH
> +#define O_PATH   01000
> +#endif
> +
>  void
>  __blobmsg_list_init(struct blobmsg_list *list, int offset, int len, 
> blobmsg_list_cmp cmp)
>  {
> -- 
> 1.9.1
> 
> 
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 5/6] openssl: remove some unneeded functionality and algorithms

[Karl Palsson]

On this one, does SRP have to be included? I'm not using it, and
i know it's super uncommon, but it's like PSK, only easier to
use, and disabling it in even more places is just guaranteeing
that it's never going to be used. Totally understand tossing all
the others though.

Cheers,
Karl P


Dirk Feytons  wrote:
> The patch needed for this commit has been sent upstream:
> https://github.com/openssl/openssl/pull/1155
> 
> Signed-off-by: Dirk Feytons 
> ---
>  package/libs/openssl/Makefile  |7 +++---
>  .../openssl/patches/302-fix_no_cmac_build.patch|   24 
> 
>  2 files changed, 28 insertions(+), 3 deletions(-)
>  create mode 100644 package/libs/openssl/patches/302-fix_no_cmac_build.patch
> 
> diff --git a/package/libs/openssl/Makefile
> b/package/libs/openssl/Makefile index 2fbb566..4782c42 100644
> --- a/package/libs/openssl/Makefile
> +++ b/package/libs/openssl/Makefile
> @@ -96,8 +96,9 @@ This package contains the OpenSSL command-line utility.
>  endef
>  
>  
> -OPENSSL_NO_CIPHERS:= no-idea no-md2 no-mdc2 no-rc5 no-sha0
> no-camellia no-krb5 -OPENSSL_OPTIONS:= shared no-err no-sse2
> no-ssl2 +OPENSSL_NO_CIPHERS:= no-idea no-md2 no-mdc2 no-rc5
> no-sha0 no-camellia no-krb5 no-srp \
> + no-whrlpool no-whirlpool no-bf no-ripemd no-seed no-cast no-cmac
> +OPENSSL_OPTIONS:= shared no-err no-sse2 no-ssl2 no-ssl2-method
> no-heartbeats
>  
>  ifdef CONFIG_OPENSSL_ENGINE_CRYPTO
>OPENSSL_OPTIONS += -DHAVE_CRYPTODEV
> @@ -117,7 +118,7 @@ ifndef CONFIG_OPENSSL_WITH_EC2M
>  endif
>  
>  ifndef CONFIG_OPENSSL_WITH_SSL3
> -  OPENSSL_OPTIONS += no-ssl3
> +  OPENSSL_OPTIONS += no-ssl3 no-ssl3-method
>  endif
>  
>  ifndef CONFIG_OPENSSL_HARDWARE_SUPPORT
> diff --git
> a/package/libs/openssl/patches/302-fix_no_cmac_build.patch
> b/package/libs/openssl/patches/302-fix_no_cmac_build.patch new
> file mode 100644 index 000..1b94f24
> --- /dev/null
> +++ b/package/libs/openssl/patches/302-fix_no_cmac_build.patch
> @@ -0,0 +1,24 @@
> +--- a/crypto/asn1/ameth_lib.c
>  b/crypto/asn1/ameth_lib.c
> +@@ -93,7 +93,9 @@ static const EVP_PKEY_ASN1_METHOD *stand
> + _asn1_meth,
> + #endif
> + _asn1_meth,
> ++#ifndef OPENSSL_NO_CMAC
> + _asn1_meth,
> ++#endif
> + #ifndef OPENSSL_NO_DH
> + _asn1_meth
> + #endif
> +--- a/crypto/evp/pmeth_lib.c
>  b/crypto/evp/pmeth_lib.c
> +@@ -91,7 +91,9 @@ static const EVP_PKEY_METHOD *standard_m
> + _pkey_meth,
> + #endif
> + _pkey_meth,
> ++#ifndef OPENSSL_NO_CMAC
> + _pkey_meth,
> ++#endif
> + #ifndef OPENSSL_NO_DH
> + _pkey_meth
> + #endif___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/6] openssl: add option to disable PSK support

[Karl Palsson]

Dirk Feytons <dirk.feyt...@gmail.com> wrote:
> On 9 June 2016 at 13:55, Karl Palsson <ka...@tweak.net.au>
> wrote:
> >
> > This is turning off PSK by default right? I actually use that
> > option, and it's a relatively common use with mosquitto, which
> > supports PSK for client auth. Could you leave it on by default
> > please? PSK, and SRP are badly treated by people who wants certs
> > everywhere, but they're perfectly reasonable, if only people
> > would remember they exist.
> 
> Yes, PSK would be off by default. My reasoning was that OpenSSL
> is most often used for traditional HTTPS with certs and the
> default OpenSSL would support that but not (much) more. I know
> that Mosquitto requires it (IIRC it also needs
> CONFIG_OPENSSL_WITH_DEPRECATED but that's still enabled by
> default). I'm working on a patch for Mosquitto to depend on
> CONFIG_OPENSSL_WITH_PSK and CONFIG_OPENSSL_WITH_DEPRECATED.
> Would that be OK for you or do you still want the default for
> PSK to be 'y'?

Can people still do opkg install mosquitto-ssl? If they have to
recompile their own image, I think it's a no-go

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel