Re: [OpenWrt-Devel] building python3 packages outside of lang/python3
Am Freitag, 1. Mai 2020, 20:20:05 CEST schrieb Alexandru Ardelean: > On Fri, May 1, 2020 at 7:04 PM Michael Richardson wrote: > > hi, > > python packages include ../python3-package.mk, and pypi.mk > > > > But I can't do that from my own feed directory. > > I don't want to copy the file!! > > > > Is there a relative path that would get me to feeds/packages/lang/python3? > > long-story-short: no > > you'll have to settle for some sort of absolute path if you need those > files from the packages feed in some other feed > if you take a look at > https://github.com/openwrt/packages/blob/master/lang/python/README.md > there's a suggestion: > PYTHON3_PACKAGE_MK:=$(wildcard > $(TOPDIR)/feeds/*/lang/python/python3-package.mk) [ similar can be done for > pypi.mk ] > We do quite the same in our feed to solve such issue. In addition we have a check that only one match will be returned by $(wildcard). https://github.com/freifunk-berlin/firmware-packages/blob/master/freifunk-berlin-generic.mk LUCIMKFILE:=$(wildcard $(TOPDIR)/feeds/*/luci.mk) # verify that there is only one single file returned ifneq (1,$(words $(LUCIMKFILE))) ifeq (0,$(words $(LUCIMKFILE))) $(error did not find luci.mk in any feed) else $(error found multiple luci.mk files in the feeds) endif endif > reason for the wildcard, is in case the "packages" feed is not named > literally 'packages', it picks up the first feed where that mk file is > found; > if there's only one, all is fine; if there's more than one, then > [anyone doing this] it's asking for trouble anyway; > > now, i've thought [and maybe Jeffery as well] about maybe doing a > helper that makes a short-hand to the python3-package.mk path somehow > [into the 'packages' feed], but there isn't a good reason to do it; > you still need to know exactly in which feed the 'python3-package.mk' > is found; and that helper needs to be done in OpenWrt core; and core > always needs good reasons to be modified; > so, some people do 'include > $(TOPDIR)/feeds/packages/lang/python/python3-package.mk' directly; > [1] > > maybe if [one day] these 2 files move into OpenWrt core, things will > be a bit simpler; but I don't think it's very soon, and I don't feel > it's a big problem [anyway], but that's my opinion; > > > I tried the whole thing, but that didn't work. > > > > I settled on: > > include $(INCLUDE_DIR)/../feeds/packages/lang/python/python3-package.mk > > > > which I found ugly, but it worked. > > yes & no; > you can choose to do a direct include like [1] > Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Applying to Season of Docs
Hi all, Google offers a program[0] to stipend people writing technical documentation for open source projects. The stipend is possible for anyone 18+ and not living in a US embargoed country, so unlike the Google Summer of Code project not only for students. Successful writers get a stipend of about $6000, mentors $500, from my understanding these stipends are at least in some parts of the world tax free. So much about the program, question is how OpenWrt could benefit from it. * Some time ago there where some ideas on IRC to add development information to OpenWrt specific tools instead of managing it in the MediaWiki. Articles from docs/techref[1] could be updated, cleaned and ported to the project repositories. For example, move the ubus network docs[2] directly to the netifd repository[3] so developers can update it conveniently when adding new features. The existing wiki would then point to an online rendered version of such docs. Using a tool like mkdocs(.org) allows to create documentation websites based on Markdown with minimal dependencies (Python3, pip3, venv). * Device pages, important for users, are often very similar but still vary in steps and formulation, increasing the work of maintaining them. Also the varying structure complicates the user. Personally I really like the template based LineageOS device wiki[4] as it's the same structure for every device but still covers corner cases or important notes. Some time ago I created a proof-of- concept which could be an inspiration for further work[5]. For prioritization a a ranking of popular wiki pages could be used, which devices are most commonly searched? * The wiki offers guides on how to use the LuCI for common use cases, which is great because it's the most likely way for basic users to interact with OpenWrt. However this could get some extra love: Partly pictures are missing[6], pictures are outdated[7] and/or missing from the web interface overview[8]. This could be refreshed and put in nice overview, maybe even even create click-through videos. There must be tools that automatically click things in UIs and make screenshots, this could make the documentation easily future proof and translatable. A prioritization and general collaboration could happen with the participants of the '"simplified" interface for LuCI'[9] thread. I'd be happy to either be a mentor or writer. Hopefully some more people are interested in this efforts! A first step is the application to make OpenWrt a SoD project. If approved I can (try to) handle the paperwork. The deadline is 4th of May, sorry for the short notice. Best, Paul [0]: https://developers.google.com/season-of-docs/ [1]: https://openwrt.org/docs/techref/start [2]: https://openwrt.org/docs/guide-developer/ubus/network [3]: https://git.openwrt.org/?p=project/netifd.git;a=summary [4]: https://wiki.lineageos.org/devices/peach [5]: https://aparcar.github.io/openwrt-devices/devices/tp-link_tl-wdr4300/ [6]: https://openwrt.org/docs/guide-user/network/wifi/dumbap#configuration_via_openwrt_web_interface_luci [7]: https://openwrt.org/docs/guide-user/network/wifi/guestwifi/guest-wlan-webinterface [8]: https://openwrt.org/docs/guide-user/luci/start [9]: https://lists.infradead.org/pipermail/openwrt-adm/2020-April/001368.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] firewall3: add --contiguous to time-based rules where needed
From: Philip Prindeville
If the start_time > stop_time on a rule, then the --contiguous arg
should be included in the rule.
Signed-off-by: Philip Prindeville
---
iptables.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/iptables.c b/iptables.c
index
559fe7defef3be85c4eb2934884caf549f932bc5..5c02e6e26c93468f4ef6a7f917069bb49985aad8
100644
--- a/iptables.c
+++ b/iptables.c
@@ -1099,6 +1099,9 @@ fw3_ipt_rule_time(struct fw3_ipt_rule *r, struct fw3_time
*time)
fw3_ipt_rule_addarg(r, false, "--timestop", buf);
}
+ if (time->timestart && time->timestop && time->timestart >
time->timestop)
+ fw3_ipt_rule_addarg(r, false, "--contiguous", NULL);
+
if (time->monthdays & 0xFFFE)
{
for (i = 1, p = buf; i < 32; i++)
--
2.17.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH netifd] vlandev: support setting ingress/egress QoS mappings
Hi,
On Tue, Apr 28, 2020 at 9:41 AM Pau Espin Pedrol wrote:
> From: Pau Espin Pedrol
>
> It allows setting mappings for instance this way:
> """
> config device
> option name 'vlan41'
> option type '8021q'
> option vid '41'
> option ifname 'eth1'
> list ingress_qos_mapping '1:2'
> list ingress_qos_mapping '2:5'
> list egress_qos_mapping '0:3'
> """
>
> Size of mapping arrays (ingress=8, egress=16) taken from linux kernel
> "struct vlan_dev_priv".
>
> Signed-off-by: Pau Espin Pedrol
> Tested-by: Pedro
> ---
> system-linux.c | 19 -
> system.h | 5 +
> vlandev.c | 57 ++
> 3 files changed, 80 insertions(+), 1 deletion(-)
>
> diff --git a/system-linux.c b/system-linux.c
> index 62636c4..fa236ad 100644
> --- a/system-linux.c
> +++ b/system-linux.c
> @@ -1401,9 +1401,10 @@ int system_vlan_del(struct device *dev)
> int system_vlandev_add(struct device *vlandev, struct device *dev, struct
> vlandev_config *cfg)
> {
> struct nl_msg *msg;
> - struct nlattr *linkinfo, *data;
> + struct nlattr *linkinfo, *data, *qos;
> struct ifinfomsg iim = { .ifi_family = AF_UNSPEC };
> int rv;
> + int i;
>
> msg = nlmsg_alloc_simple(RTM_NEWLINK, NLM_F_REQUEST | NLM_F_CREATE
> | NLM_F_EXCL);
>
> @@ -1431,6 +1432,22 @@ int system_vlandev_add(struct device *vlandev,
> struct device *dev, struct vlande
> netifd_log_message(L_WARNING, "%s Your kernel is older
> than linux 3.10.0, 802.1ad is not supported defaulting to 802.1q",
> vlandev->type->name);
> #endif
>
> + if (!(qos = nla_nest_start(msg, IFLA_VLAN_INGRESS_QOS)))
> + goto nla_put_failure;
> + for (i = 0; i < cfg->ingress_qos_mappings_len; i++)
> + nla_put(msg, IFLA_VLAN_QOS_MAPPING,
> + sizeof(cfg->ingress_qos_mappings[i]),
> + >ingress_qos_mappings[i]);
> + nla_nest_end(msg, qos);
> +
> + if (!(qos = nla_nest_start(msg, IFLA_VLAN_EGRESS_QOS)))
> + goto nla_put_failure;
> + for (i = 0; i < cfg->egress_qos_mappings_len; i++)
> + nla_put(msg, IFLA_VLAN_QOS_MAPPING,
> + sizeof(cfg->egress_qos_mappings[i]),
> + >egress_qos_mappings[i]);
> + nla_nest_end(msg, qos);
> +
> nla_nest_end(msg, data);
> nla_nest_end(msg, linkinfo);
>
> diff --git a/system.h b/system.h
> index b377416..d8fc0c4 100644
> --- a/system.h
> +++ b/system.h
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include "device.h"
> #include "interface-ip.h"
> #include "iprule.h"
> @@ -161,6 +162,10 @@ enum vlan_proto {
> struct vlandev_config {
> enum vlan_proto proto;
> uint16_t vid;
> + struct ifla_vlan_qos_mapping ingress_qos_mappings[8];
>
+ size_t ingress_qos_mappings_len;
> + struct ifla_vlan_qos_mapping egress_qos_mappings[16];
>
Use a netifd defined struct as struct ifla_vlan_qos_mapping is a Linux
specific struct ; the usage of struct ifla_vlan_qos should be confined to
system-linux.c.
Also use lists here iso fixed arrays as at least for egress qos settings
you can define more than 16 entries after checking the Linux kernel code
> + size_t egress_qos_mappings_len;
> };
>
> static inline int system_get_addr_family(unsigned int flags)
> diff --git a/vlandev.c b/vlandev.c
> index ceaeb3e..2cc9a19 100644
> --- a/vlandev.c
> +++ b/vlandev.c
> @@ -13,6 +13,7 @@
> */
>
> #include
> +#include
>
> #include "netifd.h"
> #include "device.h"
> @@ -22,12 +23,16 @@
> enum {
> VLANDEV_ATTR_IFNAME,
> VLANDEV_ATTR_VID,
> + VLANDEV_ATTR_INGRESS_QOS_MAPPING,
> + VLANDEV_ATTR_EGRESS_QOS_MAPPING,
> __VLANDEV_ATTR_MAX
> };
>
> static const struct blobmsg_policy vlandev_attrs[__VLANDEV_ATTR_MAX] = {
> [VLANDEV_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_STRING },
> [VLANDEV_ATTR_VID] = { "vid", BLOBMSG_TYPE_INT32 },
> + [VLANDEV_ATTR_INGRESS_QOS_MAPPING] = { "ingress_qos_mapping",
> BLOBMSG_TYPE_ARRAY },
> + [VLANDEV_ATTR_EGRESS_QOS_MAPPING] = { "egress_qos_mapping",
> BLOBMSG_TYPE_ARRAY },
> };
>
> static const struct uci_blob_param_list vlandev_attr_list = {
> @@ -152,6 +157,42 @@ vlandev_config_init(struct device *dev)
> device_add_user(>parent, basedev);
> }
>
> +static size_t vlandev_qos_mappings_list_apply(struct
> ifla_vlan_qos_mapping *qos_mapping, size_t len, struct blob_attr *list)
> +{
> + struct blob_attr *cur;
> + int rem, rc;
> + int i = 0;
> +
> + blobmsg_for_each_attr(cur, list, rem) {
> + if (i == len) {
> + netifd_log_message(L_WARNING, "parsing failed: too
> many (>%d) qos mappings\n", len);
>
Check is not necessary anymore if lists are used
> + return 0;
> + }
> +
> + if
Re: [OpenWrt-Devel] building python3 packages outside of lang/python3
On Fri, May 1, 2020 at 7:04 PM Michael Richardson wrote: > > hi, > python packages include ../python3-package.mk, and pypi.mk > > But I can't do that from my own feed directory. > I don't want to copy the file!! > > Is there a relative path that would get me to feeds/packages/lang/python3? long-story-short: no you'll have to settle for some sort of absolute path if you need those files from the packages feed in some other feed if you take a look at https://github.com/openwrt/packages/blob/master/lang/python/README.md there's a suggestion: PYTHON3_PACKAGE_MK:=$(wildcard $(TOPDIR)/feeds/*/lang/python/python3-package.mk) [ similar can be done for pypi.mk ] reason for the wildcard, is in case the "packages" feed is not named literally 'packages', it picks up the first feed where that mk file is found; if there's only one, all is fine; if there's more than one, then [anyone doing this] it's asking for trouble anyway; now, i've thought [and maybe Jeffery as well] about maybe doing a helper that makes a short-hand to the python3-package.mk path somehow [into the 'packages' feed], but there isn't a good reason to do it; you still need to know exactly in which feed the 'python3-package.mk' is found; and that helper needs to be done in OpenWrt core; and core always needs good reasons to be modified; so, some people do 'include $(TOPDIR)/feeds/packages/lang/python/python3-package.mk' directly; [1] maybe if [one day] these 2 files move into OpenWrt core, things will be a bit simpler; but I don't think it's very soon, and I don't feel it's a big problem [anyway], but that's my opinion; > I tried the whole thing, but that didn't work. > > I settled on: > include $(INCLUDE_DIR)/../feeds/packages/lang/python/python3-package.mk > > which I found ugly, but it worked. yes & no; you can choose to do a direct include like [1] > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Routes disappearing when ip "ip link set down ethX" and bring it up again
> > >> On May 1, 2020, at 2:08 AM, Hans Dedecker wrote: >> >> >> On Thu, Apr 30, 2020 at 9:32 PM Philip Prindeville >> wrote: >> Hi all, >> >> I noticed that if eth5 is my “wan” interface and I do: >> >> # ip link set down dev eth5 >> >> make some firewall changes, then do: >> >> # ip link set up dev eth5 >> >> then my routes don’t get repopulated. >> >> I thought that procd installed triggers so that if an interface flaps, then >> a helper would run (in this case the network helper). > > Netifd is responsible for management of IP routes/addresses; so if a link is > forced down by an external command netifd will not be aware and will not > re-install IP routes/addresses > You can easily bring down an interface by using ifdown which is handled by > netifd Okay, I figured that netifd listened for NETLINK messages about the interfaces changing state… -Philip > >> >> >> Hans >> >> Is this not happening? >> >> Thanks, >> >> -Philip >> > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issues backporting 4-byte opcode support for w25q256 fix to 4.14 kernel and Lima board
Hey!
> > I'm working on porting your 4-byte opcode support fix for the w25q256
> > (in openwrt git master, 4745969ad7c0cb65f55c8de1f05eba786ca27f71) to
> > the 4.14 kernel used in 19.07 for the Lima board.
> >
> > The port is relatively easy just adding the post-bfpt parsing hook,
> > but I'm stuck much earlier than that. In the Lima board I'm testing
> > with (with a w25q256jv), the BFPT parsing is not even done. I've added
> > several logs along the spi-nor codebase to see why that happened, and
> > surprisingly the SFDP header version check done in
> > spi_nor_parse_sfdp() is failing; the header version read is 0xff10
> > (??)
> >
> > [0.862552] m25p80 spi0.0: found w25q256, expected m25p80
> > [0.868205] m25p80 spi0.0: running spi_nor_init_params...
> > [0.873799] m25p80 spi0.0: info->flags SPI_NOR_DUAL_READ |
> > SPI_NOR_QUAD_READ: yes
> > [0.881522] m25p80 spi0.0: info->flags !SPI_NOR_SKIP_SFDP: yes
> > [0.887553] m25p80 spi0.0: will parse SFDP
> > [0.891780] m25p80 spi0.0: parsing SFDP...
> > [0.896047] m25p80 spi0.0: SFDP header version check failed...
> > signature 0xff10 (!= 0x50444653), major 0 (!= 1)
> > [0.916268] m25p80 spi0.0: running spi_nor_setup...
> > [0.921319] m25p80 spi0.0: enabling 4 byte addressing mode...
> > [0.927294] m25p80 spi0.0: w25q256 (32768 Kbytes)
> >
> > The outcome is that the 4-byte opcode is not enabled and the spi-nor
> > ends up running in 4-byte addressing mode instead. Any idea or hint
> > why this could be happening? Does the 0xff10 header version value
> > ring any bell?
>
> That's the first word of flash content, not sfdp header. You are hit
> by a flash reading patch for ath79-spi driver.[0]
> spi_flash_read interface is used by both flash data reading and
> SFDP reading. However this patch only handles the former case
> and returns flash data when reading SFDP table.
> To fix this problem, you need to check opcode in
> ath79_spi_read_flash_data and return -ENOTSUPP on SFDP
> reading request.
>
> [0]
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch;h=7c24fc5e14e593e8945789c2ac3e37bd14ad92be;hb=33732f4a9c17921b782167a0dcaba9703d4e6753
That worked! I updated the read_flash_data() with the same logic found
in git master for kernel 5.4, looking like this:
diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
index 131e15b6b577..cf0b13a06443 100644
--- a/drivers/spi/spi-ath79.c
+++ b/drivers/spi/spi-ath79.c
@@ -214,7 +214,7 @@ static int ath79_spi_read_flash_data(struct spi_device *spi,
{
struct ath79_spi *sp = ath79_spidev_to_sp(spi);
- if (msg->addr_width > 3)
+ if (msg->addr_width > 3 || msg->dummy_bytes != 1 ||
msg->read_opcode != 0x0b)
return -EOPNOTSUPP;
/* disable GPIO mode */
And that seems to have solved the problem with reading the SFDP.
Hopefully these changes aren't breaking anything else.
--
Aleksander
https://aleksander.es
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] building python3 packages outside of lang/python3
hi, python packages include ../python3-package.mk, and pypi.mk But I can't do that from my own feed directory. I don't want to copy the file!! Is there a relative path that would get me to feeds/packages/lang/python3? I tried the whole thing, but that didn't work. I settled on: include $(INCLUDE_DIR)/../feeds/packages/lang/python/python3-package.mk which I found ugly, but it worked. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issues backporting 4-byte opcode support for w25q256 fix to 4.14 kernel and Lima board
Hi! On Fri, May 1, 2020 at 9:48 PM Aleksander Morgado wrote: > > Hey Mantas, > > I'm working on porting your 4-byte opcode support fix for the w25q256 > (in openwrt git master, 4745969ad7c0cb65f55c8de1f05eba786ca27f71) to > the 4.14 kernel used in 19.07 for the Lima board. > > The port is relatively easy just adding the post-bfpt parsing hook, > but I'm stuck much earlier than that. In the Lima board I'm testing > with (with a w25q256jv), the BFPT parsing is not even done. I've added > several logs along the spi-nor codebase to see why that happened, and > surprisingly the SFDP header version check done in > spi_nor_parse_sfdp() is failing; the header version read is 0xff10 > (??) > > [0.862552] m25p80 spi0.0: found w25q256, expected m25p80 > [0.868205] m25p80 spi0.0: running spi_nor_init_params... > [0.873799] m25p80 spi0.0: info->flags SPI_NOR_DUAL_READ | > SPI_NOR_QUAD_READ: yes > [0.881522] m25p80 spi0.0: info->flags !SPI_NOR_SKIP_SFDP: yes > [0.887553] m25p80 spi0.0: will parse SFDP > [0.891780] m25p80 spi0.0: parsing SFDP... > [0.896047] m25p80 spi0.0: SFDP header version check failed... > signature 0xff10 (!= 0x50444653), major 0 (!= 1) > [0.916268] m25p80 spi0.0: running spi_nor_setup... > [0.921319] m25p80 spi0.0: enabling 4 byte addressing mode... > [0.927294] m25p80 spi0.0: w25q256 (32768 Kbytes) > > The outcome is that the 4-byte opcode is not enabled and the spi-nor > ends up running in 4-byte addressing mode instead. Any idea or hint > why this could be happening? Does the 0xff10 header version value > ring any bell? That's the first word of flash content, not sfdp header. You are hit by a flash reading patch for ath79-spi driver.[0] spi_flash_read interface is used by both flash data reading and SFDP reading. However this patch only handles the former case and returns flash data when reading SFDP table. To fix this problem, you need to check opcode in ath79_spi_read_flash_data and return -ENOTSUPP on SFDP reading request. [0] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch;h=7c24fc5e14e593e8945789c2ac3e37bd14ad92be;hb=33732f4a9c17921b782167a0dcaba9703d4e6753 -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] wolfssl: update to 4.4.0-stable
This version adds many bugfixes, including a couple of security vulnerabilities: - For fast math (enabled by wpa_supplicant option), use a constant time modular inverse when mapping to affine when operation involves a private key - keygen, calc shared secret, sign. - Change constant time and cache resistant ECC mulmod. Ensure points being operated on change to make constant time. Signed-off-by: Eneas U de Queiroz --- This is a straight update, no change in ABI. Tested with wpad (WPA2), uhttpd, and curl. diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index cb1ab1b64c..b186a087e7 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wolfssl -PKG_VERSION:=4.3.0-stable +PKG_VERSION:=4.4.0-stable PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) -PKG_HASH:=6896f8ad6c44aff3e583006839600848a0e37118ebbb7514eca9409ae08b +PKG_HASH:=7f854804c8ae0ca49cc77809e38e9a3b5a8c91ba7855ea928e6d6651b0d35f18 PKG_FIXUP:=libtool PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] fstools: block: make extroot mount preparation more robust
On 09.04.2019 20:08, Kenneth J. Miller wrote:
The extroot mount preparation code for r/w rootfs overlay discovery, and
determining the user-defined /etc/config/fstab location within, would only
discover overlays residing on JFFS2 or UBIFS MTD storage.
This led to attempts at loading the uci fstab configuration without the
required /tmp/overlay directory prefix on devices with a non-MTD r/w
rootfs overlay, and thus failure to find any custom fstab /overlay extroot
entries on PREINIT.
(example: the default openwrt eMMC partition layout on the zyxel nbg6817)
Futher, with UBIFS_EXTROOT enabled (fstools package default), and no MTD
rootfs partitions present, check_extroot would not attempt rootfs
discovery on block devices, such as the ext4 mmcblk rootfs overlay on the
nbg6817.
With this patch:
1) main_extroot now attempts to load uci fstab configuration from an
already mounted overlay, before defaulting to the prefix-less uci
config dir when no MTD rootfs partitions are detected.
2) check_extroot now also attempts to find rootfs partitions on block >
devices when no MTD rootfs partitions are detected.
There were some questions about this old patch on IRC so I took a moment
to review it (finally). It touches some rarely used code and there are
no enough experienced people who remember how it's supposed to work.
block.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index 39212d2..3dfc4a5 100644
--- a/block.c
+++ b/block.c
@@ -1301,7 +1301,7 @@ static int find_block_ubi_RO(libubi_t libubi, char *name,
char *part, int plen)
return err;
}
-#else
+#endif
static int find_root_dev(char *buf, int len)
{
@@ -1332,8 +1332,6 @@ static int find_root_dev(char *buf, int len)
return -1;
}
-#endif
-
static int test_fs_support(const char *name)
{
char line[128], *p;
@@ -1363,25 +1361,20 @@ static int check_extroot(char *path)
struct probe_info *pr = NULL;
char devpath[32];
-#ifdef UBIFS_EXTROOT
if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
int err = -1;
+#ifdef UBIFS_EXTROOT
libubi_t libubi;
libubi = libubi_open();
err = find_block_ubi_RO(libubi, "rootfs", devpath,
sizeof(devpath));
libubi_close(libubi);
- if (err)
- return -1;
- }
-#else
- if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
- if (find_root_dev(devpath, sizeof(devpath))) {
+#endif
+ if (err && find_root_dev(devpath, sizeof(devpath))) {
ULOG_ERR("extroot: unable to determine root device\n");
return -1;
}
}
-#endif
list_for_each_entry(pr, , list) {
if (!strcmp(pr->dev, devpath)) {
@@ -1585,7 +1578,7 @@ static int main_extroot(int argc, char **argv)
}
#endif
- return mount_extroot(NULL);
+ return mount_extroot("/tmp/overlay");
Did you consider consequences of this change? This breaks reading
/etc/config/fstab from "rootfs" partition. You need to handle your
case properly (carefully). Please don't suggest random change that
just happen to work for your scenario.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Issues backporting 4-byte opcode support for w25q256 fix to 4.14 kernel and Lima board
Hey Mantas, I'm working on porting your 4-byte opcode support fix for the w25q256 (in openwrt git master, 4745969ad7c0cb65f55c8de1f05eba786ca27f71) to the 4.14 kernel used in 19.07 for the Lima board. The port is relatively easy just adding the post-bfpt parsing hook, but I'm stuck much earlier than that. In the Lima board I'm testing with (with a w25q256jv), the BFPT parsing is not even done. I've added several logs along the spi-nor codebase to see why that happened, and surprisingly the SFDP header version check done in spi_nor_parse_sfdp() is failing; the header version read is 0xff10 (??) [0.862552] m25p80 spi0.0: found w25q256, expected m25p80 [0.868205] m25p80 spi0.0: running spi_nor_init_params... [0.873799] m25p80 spi0.0: info->flags SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ: yes [0.881522] m25p80 spi0.0: info->flags !SPI_NOR_SKIP_SFDP: yes [0.887553] m25p80 spi0.0: will parse SFDP [0.891780] m25p80 spi0.0: parsing SFDP... [0.896047] m25p80 spi0.0: SFDP header version check failed... signature 0xff10 (!= 0x50444653), major 0 (!= 1) [0.916268] m25p80 spi0.0: running spi_nor_setup... [0.921319] m25p80 spi0.0: enabling 4 byte addressing mode... [0.927294] m25p80 spi0.0: w25q256 (32768 Kbytes) The outcome is that the 4-byte opcode is not enabled and the spi-nor ends up running in 4-byte addressing mode instead. Any idea or hint why this could be happening? Does the 0xff10 header version value ring any bell? If I use the 8devices openwrt git master (v2.10) instead of the upstream one, which has the original fix you implemented for the w25q256 support a while ago (commit 02c8ce11bf86dd4a99614ffa0b21f2dadb08b012) I can confirm that the fix is being applied for the w25q256jv (that implementation dumps a "Using 4B command set" message when opcodes are used). And so, I'm also assuming that the SFDP header version check is actually succeeding in this build, as that version check is done before parsing the BFPT. Is the SFDP header read failing in 19.07 for some reason I don't yet understand? I also tried to use openwrt git master with kernel 5.4 but that is not available yet for the Lima board, only for the Carambola2. Is there any plan to have the Lima board added to the ath79 target? Cheers! -- Aleksander https://aleksander.es ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] tools: add autoconf-archive
Hi On Fri, May 01, 2020 at 09:22:36AM +0200, Petr Štetiar wrote: > Karel Kočí [2020-04-29 12:47:58]: > > Hi, > > > Some autotools based build systems are using autoconf-archive scripts > > and are expecting them to almost always be available. > > like for example? I fail to see, why this should be included. Stating "some > build systems" is not enough. Any configure.ac with AX_* macro. My reason is Turris updater-ng but that is part of downstream project so it might not be relevant. I can do grep trough build_dir to see all uses of AX_* macros in configure.ac files. I suspect that they are few. There is at least a copy of files found in packages repository in packages mpc and libmpdclient. > > Including this adds little to no overhead in terms of build time as > > those are just m4 scripts copied to an appropriate location. > > Any new package adds maintenance/support overhead. This is not package but tool and can be considered as core component of GNU tools. It is set of extension macros for autoconf. It is also updated/released just once or twice a year. I am not saying that I am aware of imminent need (over ours) to include it. It is just simple enough tool that is I think pretty much "include and forget" type of thing. It would also make possible to not have to hack build systems (such as for mpc) and would instead provide these files in consistent manner to all packages. Other consideration can be that it is required for one of the core components of Turris so there is company and payed developers behind this to maintain. With regards Karel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH fstools V3 1/2] Revert "block: mount_action: handle mount/umount deps"
Sorry for a late reply :| On 02.04.2020 14:35, Jo-Philipp Wich wrote: instead of reverting the hierarchical mount handling, isn't fixing the unintended mounts just a matter of doing a prefix compare during vlist_for_first_to_element() traversal? Assuming that `the_dev` refers to the block we do want to mount and `dev` is the iterator pointing to each `dev` which is lexically ordered before `the_dev`, would something like the below code suffice? I don't really like that as it's just patching something that wasn't properly designed in the first place. 1. Not every entry has mount point but we try sorting by it anyway 2. Mounts points are only read from UCI - current code ignores those "dynamic" ones. 3. It handles a single case only (with limitations) - what if another case requires sorting by label name? That could be desired when presenting all devices to a user. Or what if I want to sort by device path (which sounds the most natural by the way)? So instead forcing fstools low level design based on a single use case we should rather have: 1) Generic low level design 2) High level code handling specific needs I posted a WIP patch showing how this could be handled without forcing the way fstools stores its entries on the low level: [PATCH fstools WIP] block: check for parent mount point before mounting I believe above PATCH could be used to handle hierarchical mounting. Your code from attached diff (dev->m->target handling) is something I didn't figure out before and could be useful in that WIP work. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [18.06][PATCH 2/2] wireguard: bump to 1.0.20200401
Rosen Penev [2020-04-09 19:15:10]: Hi, > From: "Jason A. Donenfeld" > > Recent backports to 5.5 and 5.4 broke our compat layer. This release is > to keep things running with the latest upstream stable kernels. I think, that this is a not acceptable for 18.06. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [19.07][PATCH 2/2] wireguard: bump to 1.0.20200401
[adding Jason to the Cc: loop] Rosen Penev [2020-04-09 19:11:10]: Hi, > From: "Jason A. Donenfeld" > > Recent backports to 5.5 and 5.4 broke our compat layer. This release is > to keep things running with the latest upstream stable kernels. I'm quite hesitant to bump WireGuard in stable release to such fresh version unless there is a good reason to do so. We're using 4.14 kernel in latest stable 19.07 release. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Routes disappearing when ip "ip link set down ethX" and bring it up again
On Thu, Apr 30, 2020 at 9:32 PM Philip Prindeville < philipp_s...@redfish-solutions.com> wrote: > Hi all, > > I noticed that if eth5 is my “wan” interface and I do: > > # ip link set down dev eth5 > > make some firewall changes, then do: > > # ip link set up dev eth5 > > then my routes don’t get repopulated. > I thought that procd installed triggers so that if an interface flaps, > then a helper would run (in this case the network helper). > Netifd is responsible for management of IP routes/addresses; so if a link is forced down by an external command netifd will not be aware and will not re-install IP routes/addresses You can easily bring down an interface by using ifdown which is handled by netifd Hans > > Is this not happening? > > Thanks, > > -Philip > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] tools: add autoconf-archive
Karel Kočí [2020-04-29 12:47:58]: Hi, > Some autotools based build systems are using autoconf-archive scripts > and are expecting them to almost always be available. like for example? I fail to see, why this should be included. Stating "some build systems" is not enough. > Including this adds little to no overhead in terms of build time as > those are just m4 scripts copied to an appropriate location. Any new package adds maintenance/support overhead. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
