Re: [rpcd PATCH 3/4] rc: add option to skip running check for list method
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
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
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
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
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); > +
Re: [iwinfo PATCH 1/2] iwinfo: add support for indoor only chan restriction
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
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
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 = &led_sys; + led-failsafe = &led_sys; + led-upgrade = &led_sys; + serial0 = &uart; + }; + + /* +* 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 = <&gpio 11 GPIO_ACTIVE_LOW>; + }; + }; + */ + + + leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&switch_led_disable_pins>; + + lan { + label = "red:lan"; + gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + }; + + wan { + label = "red:wan"; + gpios = <&gpio 17 GPIO_ACTIVE_LOW>; + }; + + wlan { + label = "red:wlan"; + gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "phy0tpt"; + }; + + led_sys: sys { + label = "red:sys"; + gpios = <&gpio 28 GPIO_ACTIVE_HIGH>; + }; + + }; +}; + +&uart { + status = "okay"; +}; + +&usb { + dr_mode = "host"; + status = "okay"; +}; + +&usb_phy { + status = "okay"; +}; + +ð0 { + status = "okay"; + nvmem-cells = <&macaddr_art_0>; + nvmem-cell-names = "mac-address"; +}; + +ð1 { + status = "okay"; + nvmem-cells = <&macaddr_art_6>; + nvmem-cell-names = "mac-address"; +}; + +&spi { + num-chipselects = <1>; + status = "okay"; + + flash@0 { + compatible = "jedec,spi-nor"; + spi-max-freque
Re: [PATCH] base-files: add blink and turnoff commands to the led script
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
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
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
"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
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
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
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
"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
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
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
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
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
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
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
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
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
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
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(&ufd->fd, flags); + uloop_fd_add(&ufd->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
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
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]
--- 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]
--- 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]
--- 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]
--- 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(&ufd->fd, flags); + uloop_fd_add(&ufd->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]
--- 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
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?
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
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
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&task_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
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&task_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
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
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 = &up->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(&up->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 */ > ++
[OpenWrt-Devel] [PATCH] uboot-envtools: ath79: add etactica eg200 support
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
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 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
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
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
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
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
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
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
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' => \&search, > 'uninstall' => \&uninstall, > 'feed_config' => \&feed_config, > + 'setup' => \&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
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
"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 /home/karl
Re: [OpenWrt-Devel] [PATCH] usbgadget: Add new package
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
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
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
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 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)
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
"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
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
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
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
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
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
"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
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?
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
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
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
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
> > 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
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
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
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
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
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 GIC_SHARED 24 > IRQ_TYPE_LEVEL_HIGH>, > <0x2 0 0 1 &gic 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
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
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
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
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
Philip Prindeville 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?
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
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
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
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 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
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
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)
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 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)
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?
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
"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.
From: Karl Palsson The "ignore" option is correctly loaded. Actually observe it as documented. Signed-off-by: Karl Palsson --- 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.
From: Karl Palsson Drop pointless syslog. The single line just doubles the amount of lines logged to syslog without adding any value. Signed-off-by: Karl Palsson --- 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.in.sin_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
From: Karl Palsson 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 --- 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.
From: Karl Palsson The "ignore" option is correctly loaded. Actually observe it as documented. Signed-off-by: Karl Palsson --- 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 2/3] remove superfluous log output.
From: Karl Palsson Drop pointless syslog. The single line just doubles the amount of lines logged to syslog without adding any value. Signed-off-by: Karl Palsson --- 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.in.sin_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: [PATCH 1/3] enable loglevel setting via envvar ODHCPD_LOG_LEVEL
From: Karl Palsson 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 --- 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, &end, 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
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] procd: uClibc O_PATH backwards compatibility fixes
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
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 > + &eckey_asn1_meth, > + #endif > + &hmac_asn1_meth, > ++#ifndef OPENSSL_NO_CMAC > + &cmac_asn1_meth, > ++#endif > + #ifndef OPENSSL_NO_DH > + &dhx_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 > + &ec_pkey_meth, > + #endif > + &hmac_pkey_meth, > ++#ifndef OPENSSL_NO_CMAC > + &cmac_pkey_meth, > ++#endif > + #ifndef OPENSSL_NO_DH > + &dhx_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
Dirk Feytons wrote: > On 9 June 2016 at 13:55, Karl Palsson > 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