Re: AW: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
Hi,
I am also fine if the user has to use image builder. This board is a bit
special.
Maybe we should allow board specific initram fs root file systems in the
future. This would also help in other cases where the user has to bot an
initramfs system for initial flashing. We can do this later.
Hauke
On 10/25/22 08:50, kestrel1...@t-online.de wrote:
Hi,
I can understand that it took a long time. The wasp loader kernel module v5 is
the next in the review list of the remoteproc-linux kernel list.
I will try to deal with Haukes suggestions by the end of the week. With regards
to the packages, I think wpad is a left over from my tests and I can remove it
and I will rework the kernel patches.
But for the special packages that are not honored by the build bots, I do not
really have a solution. For now I was thinking of instructions to use the image
builder, which also means, that as a start there will not be any downloadable
images that cover all possible functionality.
Daniel.
-Original-Nachricht-
Betreff: Re: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
Datum: 2022-10-25T00:24:57+0200
Von: "Hauke Mehrtens"
An: "Torsten Duwe" , "openwrt-devel@lists.openwrt.org"
On 10/23/22 13:19, Torsten Duwe wrote:
Hi all,
Here is my second attempt for initial FritzBox x490 support. 22.03 now
has all the necessary prerequisites, so support can be added according
to the rules.
The original code snippets were submitted by John Crispin (IIRC),
Andreas Böhler and Daniel Kestrel. I carved out the changes I
considered necessary, integrated and tested them and cleaned them up
(hopefully ;)
These are the minimal changes required to run the FB {3,7}490 as DSL
router (tested!). The 5490 is reported to be similar, so I included
it, but could not test it due to lack of hardware.
The wireless on these boxes is offloaded to a secondary SoC which
needs to be provided its own OS. This feature is explicitly left out
here in order to go step by step. I kept some loose ends where they
don't hurt, for future reference.
Changes from v1:
* return to squashfs for the rootfs; ubifs causes too much complexity
esp. for updates, when even the same model can be equipped with
varying flash chip geometries. UBI partitioning and volumes are kept
though.
Hi,
How is this related to the pull request adding support for these devices
on github?
https://github.com/openwrt/openwrt/pull/5075
The pull request on github looks mostly ok to me, I just had some minor
questions.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On 10/25/22 17:21, Dave Taht wrote: On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls wrote: On 10/24/22 18:21, Hauke Mehrtens wrote: Hauke, thanks for replying! As I said on a related thread - if an eu body can be found to care more deeply on these issues, I'm pretty sure 30-50k of funding is available via one or more of nlnet's grant programs. Applications for this round close december 1st. https://nlnet.nl/ Thanks for pointing it out. If someone wants to apply for this and improve the security of OpenWrt it would be nice. One problem is still the constant maintenance which is needed to keep it up to date. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On 10/25/22 16:29, Peter Naulls wrote: On 10/24/22 18:21, Hauke Mehrtens wrote: Hauke, thanks for replying! I also prefer if the CVE number is named in the patch. If this is missing somewhere you could send a patch or pull request to rename the patch. I'm afraid I don't have any explicit examples, but I'll let you know if find any. There are some concerns with the older lua I mentioned below, but I'll need to come back to those. In any case, a suggestion for future CVE patches. The OpenWrt project does not have enough resources to maintain security patches for the kernel on our own. OpenWrt relays on the LTS kernel maintenance and we update to the most recent LTS version every few days or weeks in the maintained branches. If some security patches are missing in the LTS kernel versions used by OpenWrt it is probably best to approach the Linux stable team directly. See this blog post from Greg Kroah-Hartman, especially the "Keeping a secure system" section: http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/ Yes, sure. And whether you or I agree with this or not is to some degree irrelevant, since what matters to the security people is that they see the bug fixed. In 90% of the cases I was able to dismiss CVEs since the subsystems in question are not in use by us (or most of OpenWrt for that matter. e.g, frame buffers), but some tricky ones remain. I do not care much about such security experts which are just able to hand a list of "problems" their broken tool found and now want fixes. If you found a real problem patches are welcome, but best is probably to inform the stable Linux group. Many security problems in the Linux kernel do not even get CVE numbers, relaying only on CVE numbers for the kernel is not reliable. That said, there's a very large number of patches to the kernel in OpenWrt; mostly for new device function, pending fixes or whatnot; I guess few of these are actual security fixes. It would be good if someone could create a script finds all patches which have a Fixes tag referencing a patch we backported. So, to user space: dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't go over particularly well, even though they have been properly dismissed by the Simon Kelley and others. See my mail on the dnsmasq mailing list: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html Yes, and was referred to and well understood by myself at least. Still, the objection is that Mitre have this as "disputed", which is rather unhelpful, and that is what is being focused upon. Obviously I cannot fix something that isn't broken and has no fix, so there's no satisfactory answer here to a security review beyond getting the CVEs dismissed from Mitre. tcpdump 4.9.3 - CVE-2018-16303 This CVE is not for tcpdump, but PDF-XChange Editor: https://nvd.nist.gov/vuln/detail/CVE-2018-16303 Sorry, trying to juggle lots of items here. https://nvd.nist.gov/vuln/detail/CVE-2018-16301 Long since in OpenWrt patches. e2fsprogs 1.46.5 - CVE-2022-1304 This is pretty hard to attack. You could provide a patch. This was the patch I provided here: I brought in this patch: diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c index b324c7b0..1a206a16 100644 Yes, very large files on OpenWrt are unlikely without external media. If would be simply easier on the optics if I was able to ditch 5.1.5 in the build and just use 5.3 - is this possible; I'm sure there's been much discussion on this before, so please point me at that - will it break luci? An update to Lua 5.4 would be good, but I do not know which impact it has. Understood. I'm going to come back to this later in another post. There's much more, but that's quite enough for now. OpenWrt is a mostly volunteer run project. Especially (security) maintenance does not get paid by companies. If you have some fixes tested patches would be really helpful. Yes, I know, and to say my reliance upon OpenWrt over the years is considerable would be an understatement, but my time is limited as well, and my focus must be on addressing specifics to the security review. Still, I felt it better to at least have a partial discussion here, and do what little I can. I don't necessarily have time to roll patches in a format suitable for OpenWrt upstreaming; sometimes I think it's more constructive to simply point out what can be done, and have the maintainers do it. Maybe not ideal, but it's something. Look for some more posts on specific topics in the near future. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/2] realtek: use assisted learning on CPU port
On 26.10.22 at 00:20, Jan Hoffmann wrote:
L2 learning on the CPU port is currently not consistently configured and
relies on the default configuration of the device. On RTL83xx, it is
disabled for packets transmitted with a TX header, as hardware learning
corrupts the forwarding table otherwise. As a result, unneeded flooding
of traffic for the CPU port can already happen on some devices now. It
is also likely that similar issues exist on RTL93xx, which doesn't have
a field to disable learning in the TX header.
To address this, disable hardware learning for the CPU port globally on
all devices. Instead, enable assisted learning to let DSA write FDB
entries to the switch.
For now, this does not sync local/bridge entries to the switch. However,
support for that was added in Linux 5.14, so the next switch to a newer
kernel version is going to fix this.
Signed-off-by: Jan Hoffmann
---
.../files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 16
.../files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h | 6 ++
2 files changed, 22 insertions(+)
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 474d540945d1..319f171eaacc 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -162,6 +162,16 @@ static void rtl83xx_setup_bpdu_traps(struct
rtl838x_switch_priv *priv)
priv->r->set_receive_management_action(i, BPDU, COPY2CPU);
}
+static void rtl83xx_port_set_salrn(struct rtl838x_switch_priv *priv,
+ int port, bool enable)
+{
+ int shift = SALRN_PORT_SHIFT(port);
+ int val = enable ? SALRN_MODE_HARDWARE : SALRN_MODE_DISABLED;
While looking at the patch again, I noticed that the type of these
variables should probably be u32 (to avoid possible undefined behaviour
when shift is 30).
As the patch is already accepted now, I'll send a separate fix.
+
+ sw_w32_mask(SALRN_MODE_MASK << shift, val << shift,
+ priv->r->l2_port_new_salrn(port));
+}
+
static int rtl83xx_setup(struct dsa_switch *ds)
{
int i;
@@ -205,6 +215,9 @@ static int rtl83xx_setup(struct dsa_switch *ds)
priv->r->l2_learning_setup();
+ rtl83xx_port_set_salrn(priv, priv->cpu_port, false);
+ ds->assisted_learning_on_cpu_port = true;
+
/*
* Make sure all frames sent to the switch's MAC are trapped to the
CPU-port
* 0: FWD, 1: DROP, 2: TRAP2CPU
@@ -263,6 +276,9 @@ static int rtl93xx_setup(struct dsa_switch *ds)
priv->r->l2_learning_setup();
+ rtl83xx_port_set_salrn(priv, priv->cpu_port, false);
+ ds->assisted_learning_on_cpu_port = true;
+
rtl83xx_enable_phy_polling(priv);
priv->r->pie_init(priv);
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
index e2b82a4975f0..10913dacef42 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl838x.h
@@ -245,6 +245,12 @@
#define RTL839X_L2_PORT_NEW_SALRN(p) (0x38F0 + (((p >> 4) << 2)))
#define RTL930X_L2_PORT_SALRN(p) (0x8FEC + (((p >> 4) << 2)))
#define RTL931X_L2_PORT_NEW_SALRN(p) (0xC820 + (((p >> 4) << 2)))
+
+#define SALRN_PORT_SHIFT(p)((p % 16) * 2)
+#define SALRN_MODE_MASK0x3
+#define SALRN_MODE_HARDWARE0
+#define SALRN_MODE_DISABLED2
+
#define RTL838X_L2_PORT_NEW_SA_FWD(p) (0x3294 + (((p >> 4) << 2)))
#define RTL839X_L2_PORT_NEW_SA_FWD(p) (0x3900 + (((p >> 4) << 2)))
#define RTL930X_L2_PORT_NEW_SA_FWD(p) (0x8FF4 + (((p / 10) << 2)))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/2] realtek: fix L2 entry setup and learning on CPU port
On 26.10.22 at 10:20, Sander Vanheule wrote:
Hi Jan,
On Wed, 2022-10-26 at 00:20 +0200, Jan Hoffmann wrote:
This is a follow-up to the patch "realtek: don't set L2LEARNING flag in
rtl83xx TX header". An undesired effect of that patch is flooding of
some packets destined for the switch CPU port, which is addressed by
this additional patch series.
This patch series switches to assisted learning for the CPU port on all
devices, and also fixes some existing issues with setup of unicast L2
entries.
Together with the kernel 5.15 pull request, entries for local/bridge
addresses are added to the switch. I am still not sure why that doesn't
work with the patches in the current kernel. However, the pull request
for the kernel update seems to be in a good shape, so I don't think it
is worth it to investigate that any further.
Tested on RTL838x (HPE 1920-8G) and RTL839x (HPE 1920-48G).
Changes in v2:
- don't explicitly specify struct name as parameter to sizeof
- make calculation of SALRN shift offset clearer
- define SALRN values, mask and shift offset in header
Jan Hoffmann (2):
realtek: set up L2 table entries properly
realtek: use assisted learning on CPU port
.../files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 45 ++-
.../drivers/net/dsa/rtl83xx/rtl838x.h | 6 +++
2 files changed, 41 insertions(+), 10 deletions(-)
Thanks for the respin! Both patches have been applied on master.
Thank you for applying the patches.
My intention for this series was for it to be applied in addition to the
previous patch "realtek: don't set L2LEARNING flag in rtl83xx TX
header", but that patch isn't applied. I guess my wording in the cover
letter was somewhat ambiguous here, and maybe I should have just
included the change in this series.
However, in terms of actual functionality it shouldn't matter anyways,
as the L2LEARNING flag in the TX header doesn't have any effect now that
learning is disabled using the SALRN register. In the end, it just means
that the explanation of the FDB corruption issue isn't in the Git
history, and the commit message of eb456aedfe24 ("realtek: use assisted
learning on CPU port") is now slightly confusing, as it references the
change to the TX header which doesn't actually exist.
Best,
Jan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 2022-10-26 18:55, Etienne Champetier wrote: Le mar. 25 oct. 2022 à 17:47, Michael Richardson a écrit : Peter Naulls wrote: > It might also be better if uhttpd could be configured to bind > to a specific interface rather than knowing its IP upfront, but > that might be impractical. It's totally impractical. Can't we bind to 0.0.0.0 and use SO_BINDTODEVICE to make sure it's really only responding on the right interface ? With complicated routing setup it changes a bit the behavior, but this might be the simplest option if we don't want to rely only on the firewall I have an experimental branch with SO_BINDTODEVICE support, but I haven't tested it with the latest stable or snapshot releases yet. https://cgit.m7n.se/pub/openwrt/uhttpd/log/?h=bind-to-device-master /Mikael ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On Wed, Oct 26, 2022 at 11:58 AM Etienne Champetier wrote: > > Le mar. 25 oct. 2022 à 17:47, Michael Richardson > a écrit : > > > > > > Peter Naulls wrote: > > > Nevertheless, the security people are looking at this config > > > statically, and not seeing that it's bound to the LAN interface IP > > > only. > > > > I don't think they are really security people, but... > > > > > For my use, I've changed the default binding to the LAN IP, and also > > > added another init.d script to check the current LAN address, and > > > update the uhttpd config if need be and then restart it (and add > > > a config hook to the network config). Obviously this isn't > > > very satisfactory, open to better suggestions here. > > > > So, it needs to bound to *all* the IPv6 "LAN" IPs. > > That means: > > a) the ULA that is created. > > b) the LL-IPv6 that are always present > > c) the GUA IPv6 that is delegated > > > > And when we make guest LANs, we may also need to bind it to that, because > > there are things that guests might need to know, such as seeing the status > > page to see if the network is up. > > > > > It might also be better if uhttpd could be configured to bind > > > to a specific interface rather than knowing its IP upfront, but > > > that might be impractical. > > > > It's totally impractical. I also have to reiterate these "security audits", and this is in now way related to OpenWRT, but the people who like to think they know security. o just because a package is installed does not mean it is listening o go read some docs o learn how to port scan yourself o go read some docs o learn how to write your own exploits o go read some docs o quit reading CVEs that are not related to your product(s) o go read some docs o join LKML and read what is being done o go read some docs Leave us alone - my company uses Linux exclusively - the threats are handled way faster than any other platform (OpenWRT aside), so tell your *security* people to hire someone that is not a straight out of college noob running some 3rd part package collector and actually learn how to examine a system for exploits. Just because something is installed absolutely does not mean it is vulnerable to attack. This is becoming a headache trying to teach the recently graduated kids with security degrees or certifications (that are easily handed out nowadays) how to handle security. Everyone wants to package inspect versus network inspect. Let me tell you something - if I have physical access, there is not a damn thing you can do to stop me - so just worry about network access like everyone is telling you. If your company is not amenable to that - I would find another job. I have a rule of thumb - I do not work for people dumber than me - you should try that rather than trying to force dumber people to make you change. Rules of the world progressing (college class 101). > Can't we bind to 0.0.0.0 and use SO_BINDTODEVICE to make sure it's > really only responding on the right interface ? > With complicated routing setup it changes a bit the behavior, but this > might be the simplest option if we don't want to rely only on the > firewall ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: touch stampfile after subtarget run
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.--- Begin Message --- Each individual build directory has stampfiles that are touched as part of their build process when each stage of the build process completes. However, the subtargets themselves do not touch the stampfiles that are defined for them. They are only touched when a target that has that stampfile as a prerequisite is ran. For example, "make tools/compile" will not touch .tools_compile_... but "make toolchain/compile" will, after each build directory in tools/ is checked again, because the stampfile is a prerequisite, not the tools/compile target itself. This makes each subtarget touch a stampfile, if defined, when the subtarget has completed successfully. A small amount of build time is expected to be saved when rebuilding after 'make clean' or an interruption. Signed-off-by: Michael Pratt --- include/subdir.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/include/subdir.mk b/include/subdir.mk index 95009f814e..6d3bd55994 100644 --- a/include/subdir.mk +++ b/include/subdir.mk @@ -16,6 +16,7 @@ subtarget-default = $(filter-out ., \ define subtarget $(call warn_eval,$(1),t,T,$(1)/$(2): $($(1)/) $(foreach bd,$(call subtarget-default,$(1),$(2)),$(1)/$(bd)/$(2))) + -touch $($(1)/stamp-$(2)) endef -- 2.30.2 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
Le mar. 25 oct. 2022 à 17:47, Michael Richardson a écrit : > > > Peter Naulls wrote: > > Nevertheless, the security people are looking at this config > > statically, and not seeing that it's bound to the LAN interface IP > > only. > > I don't think they are really security people, but... > > > For my use, I've changed the default binding to the LAN IP, and also > > added another init.d script to check the current LAN address, and > > update the uhttpd config if need be and then restart it (and add > > a config hook to the network config). Obviously this isn't > > very satisfactory, open to better suggestions here. > > So, it needs to bound to *all* the IPv6 "LAN" IPs. > That means: > a) the ULA that is created. > b) the LL-IPv6 that are always present > c) the GUA IPv6 that is delegated > > And when we make guest LANs, we may also need to bind it to that, because > there are things that guests might need to know, such as seeing the status > page to see if the network is up. > > > It might also be better if uhttpd could be configured to bind > > to a specific interface rather than knowing its IP upfront, but > > that might be impractical. > > It's totally impractical. Can't we bind to 0.0.0.0 and use SO_BINDTODEVICE to make sure it's really only responding on the right interface ? With complicated routing setup it changes a bit the behavior, but this might be the simplest option if we don't want to rely only on the firewall > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
On 10/25/22 18:20, openwrt-devel-requ...@lists.openwrt.org wrote: From: Nathan Lutchansky My hands are tied, we gotta do the dance. I mean this as gently as possible, but I think what a lot of us are missing is the benefit to the OpenWrt project to carry an increased maintenance burden in response to your internal requirements, which you openly state add no value. Maybe your time is better spent fixing your organization's processes, rather than trying to make volunteers responsive to what we all agree are pointless requirements?? -Nathan Apologies, due to volume, I had put this list on digest and am missing some of the responses not CCed to me and am going to be breaking the threading here. Thanks to everyone for taking the time. My company is small, there's little disagreement on what I've mentioned to date about these issues internally. These audits are done by much (much) larger partner companies - e.g, MS/Intel that I mentioned recently, so there's no chance there to change process. The best response in many cases is well reasoned arguments, but sometimes not. I'm not asking anyone here to do anything; but if my comments serve as useful reference in future to someone who is going through the same process, then I'll consider it time well spent. And if the commentary turns into practical measures, then I'll contribute back what I can. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: lua 5.1.5 CVEs / lua 5.3 with luci
Hi, > Can one be curious and ask what is gonna be used instead of lua, or is > that still not 100% decided yet? you can find more details at https://forum.openwrt.org/t/luci-rewrite-in-ucode-testers-wanted/137250 ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: lua 5.1.5 CVEs / lua 5.3 with luci
Ah thanks On Wed, Oct 26, 2022 at 3:57 PM Jo-Philipp Wich wrote: > > Hi, > > > Can one be curious and ask what is gonna be used instead of lua, or is > > that still not 100% decided yet? > > you can find more details at > https://forum.openwrt.org/t/luci-rewrite-in-ucode-testers-wanted/137250 > > ~ Jo > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: lua 5.1.5 CVEs / lua 5.3 with luci
Can one be curious and ask what is gonna be used instead of lua, or is that still not 100% decided yet? On Wed, Oct 26, 2022 at 3:54 PM Jo-Philipp Wich wrote: > > Hi, > > all errors you quoted are occurring within Lua code. The view rendering etc. > mostly happens in JavaScript on the client side, this is why things /seem/ to > work. Many backend actions are implemented as rpcd plugins in Lua code though, > and all those seem to fail (not register with rpcd in the first place, likely > because the requested interpreter /usr/bin/lua is not there). > > Newer Lua versions do have various incompatibilities with Lua 5.1 and the > deprecation of setfenv(), getfenv() in favor to _ENV will require a lot of > refactoring in LuCI framework code. > > Since LuCI is in the process of migrating away from Lua, only keeping an > optional compatibility Lua runtime for legacy applications, it is unlikely > that any work will be spent to convert the framework code to later Lua > versions. > > ~ Jo > > ___ > 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: lua 5.1.5 CVEs / lua 5.3 with luci
Hi, all errors you quoted are occurring within Lua code. The view rendering etc. mostly happens in JavaScript on the client side, this is why things /seem/ to work. Many backend actions are implemented as rpcd plugins in Lua code though, and all those seem to fail (not register with rpcd in the first place, likely because the requested interpreter /usr/bin/lua is not there). Newer Lua versions do have various incompatibilities with Lua 5.1 and the deprecation of setfenv(), getfenv() in favor to _ENV will require a lot of refactoring in LuCI framework code. Since LuCI is in the process of migrating away from Lua, only keeping an optional compatibility Lua runtime for legacy applications, it is unlikely that any work will be spent to convert the framework code to later Lua versions. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: lua 5.1.5 CVEs / lua 5.3 with luci
On 10/25/22 20:45, Reuben Dowle wrote: My opinion is that openwrt should try and move to a newer version of lua. This old 5.1.5 version appears to be unmaintained, and there does not seem to be the resources within the openwrt community to change that. So I naively adjusted the lua5.3 package to add PROVIDES for lua and liblua and symlinked the /usr/bin/lua5.3 binary to /usr/bin/lua. In some very superficial testing, skimming through pages, luci almost works correctly. What I do see on all pages, is this: RPCError: RPC call to luci/getFeatures failed with error -32000: Object not found at handleCallReply (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:82:7) at promise callback*parseCallReply (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:66:5) at promise callback*call (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:41:6) at declare/(http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:342:9) at declare/< (http://192.168.113.1/luci-static/resources/rpc.js?v=unknown:302:11) at probeSystemFeatures (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:2588:7) at setupDOM (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:2737:10) at promise callback*__init__ (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:2254:7) at ClassConstructor (http://192.168.113.1/luci-static/resources/luci.js?v=unknown:104:20) Just bear in mind that although this is 22.03, I have some heavyish changes to customize luci too. I don't know this particular code, but I can't imagine it being hard to fix. There's some additional similar errors on other pages. Switch config: RPCError: RPC call to luci/getSwconfigFeatures failed with error -32000: Object not found Firewall: RPCError: RPC call to luci/getConntrackHelpers failed with error -32000: Object not found The system log tabs also report: "Unable to load log data: Not Found". Wireguard: RPC call to luci.wireguard/getWgInstances failed with error -32000: Object not found Suggested fixes? In any case, this seems like it would be a major internal change in OpenWrt. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH procd] ubus: add state measurement
Procd has different states during booting. When the system is
booted, it is in the 'running' state. This state is only exited when the
system is shut down cleanly. This state is called 'shutdown'. To find out
what state the system is in and how long it will take to complete this,
the commit adds a new section 'state' to the ubus call system info. There
you can read which state the procd is in and how long it has been in
this state or how long it has been running in the state.
command:
ubus call system info
output:
{
"localtime": 1666795909,
"state": {
"load": {
"active": false,
"duration": 42.667914
},
"early": {
"active": false,
"duration": 1.107519
},
"ubus": {
"active": false,
"duration": 0.536634
},
"init": {
"active": false,
"duration": 123.176279
},
"running": {
"active": true,
"duration": 226.491805
},
"shutdown": {
"active": false,
"duration": 0.00
}
},
Signed-off-by: Florian Eckert
---
This is a followup of pullrequest with the proposed changes.
https://github.com/openwrt/openwrt/pull/10937
procd.h | 2 ++
state.c | 82
system.c | 2 ++
3 files changed, 86 insertions(+)
diff --git a/procd.h b/procd.h
index fd29a12..3299b41 100644
--- a/procd.h
+++ b/procd.h
@@ -15,6 +15,7 @@
#ifndef __PROCD_H
#define __PROCD_H
+#include
#include
#include
#include
@@ -36,6 +37,7 @@ void ubus_init_system(struct ubus_context *ctx);
void procd_state_next(void);
void procd_state_ubus_connect(void);
+void procd_state_event(struct blob_buf *b);
void procd_shutdown(int event);
void procd_early(void);
void procd_preinit(void);
diff --git a/state.c b/state.c
index fb81248..acbcece 100644
--- a/state.c
+++ b/state.c
@@ -13,6 +13,7 @@
*/
#include
+#include
#include
#include
#include
@@ -20,6 +21,7 @@
#include
#include
#include
+#include
#include "container.h"
#include "procd.h"
@@ -43,6 +45,22 @@ enum {
static int state = STATE_NONE;
static int reboot_event;
+struct state_event {
+ struct timespec ts_event;
+ bool active;
+ const char *name;
+};
+
+static struct state_event s_event[__STATE_MAX] = {
+ [STATE_NONE] = {{0, 0}, true, "load" },
+ [STATE_EARLY] = {{0, 0}, false, "early" },
+ [STATE_UBUS] = {{0, 0}, false, "ubus" },
+ [STATE_INIT] = {{0, 0}, false, "init" },
+ [STATE_RUNNING] = {{0, 0}, false, "running" },
+ [STATE_SHUTDOWN] = {{0, 0}, false, "shutdown" },
+ [STATE_HALT] = {{0, 0}, false, "halt" },
+};
+
static void set_stdio(const char* tty)
{
if (chdir("/dev") ||
@@ -123,11 +141,23 @@ static void perform_halt()
sleep(1);
}
+static void update_state_event(void)
+{
+ // set previous state inactive
+ s_event[state-1].active = false;
+
+ s_event[state].active = true;
+ clock_gettime(CLOCK_BOOTTIME, _event[state].ts_event);
+}
+
static void state_enter(void)
{
char ubus_cmd[] = "/sbin/ubusd";
struct passwd *p;
+ if (state > STATE_NONE && state < __STATE_MAX)
+ update_state_event();
+
switch (state) {
case STATE_EARLY:
LOG("- early -\n");
@@ -228,3 +258,55 @@ void procd_shutdown(int event)
state = STATE_SHUTDOWN;
state_enter();
}
+
+void procd_state_event(struct blob_buf *b)
+{
+ void *c, *s;
+ struct timespec *ts_start;
+ struct timespec *ts_stop;
+ struct timespec ts_active;
+ struct timespec ts_res;
+ double duration;
+
+ c = blobmsg_open_table(b, "state");
+
+ for (int i = 0; i < __STATE_MAX - 1; i++)
+ {
+ ts_start = _event[i].ts_event;
+ ts_stop = _event[i+1].ts_event;
+
+ if (ts_stop->tv_sec > 0) {
+ ts_res.tv_sec = ts_stop->tv_sec - ts_start->tv_sec;
+ ts_res.tv_nsec = ts_stop->tv_nsec - ts_start->tv_nsec;
+ }
+ else if (s_event[i].active) {
+ clock_gettime(CLOCK_BOOTTIME, _active);
+ ts_res.tv_sec = ts_active.tv_sec - ts_start->tv_sec;
+ ts_res.tv_nsec = ts_active.tv_nsec - ts_start->tv_nsec;
+ }
+ else {
+ ts_res.tv_sec = 0;
+ ts_res.tv_nsec = 0;
+ }
+
+ // correct overflow calculation
+ if (ts_res.tv_nsec < 0) {
+ --ts_res.tv_sec;
+
Re: [PATCH v2 0/2] realtek: fix L2 entry setup and learning on CPU port
Hi Jan, On Wed, 2022-10-26 at 00:20 +0200, Jan Hoffmann wrote: > This is a follow-up to the patch "realtek: don't set L2LEARNING flag in > rtl83xx TX header". An undesired effect of that patch is flooding of > some packets destined for the switch CPU port, which is addressed by > this additional patch series. > > This patch series switches to assisted learning for the CPU port on all > devices, and also fixes some existing issues with setup of unicast L2 > entries. > > Together with the kernel 5.15 pull request, entries for local/bridge > addresses are added to the switch. I am still not sure why that doesn't > work with the patches in the current kernel. However, the pull request > for the kernel update seems to be in a good shape, so I don't think it > is worth it to investigate that any further. > > Tested on RTL838x (HPE 1920-8G) and RTL839x (HPE 1920-48G). > > Changes in v2: > - don't explicitly specify struct name as parameter to sizeof > - make calculation of SALRN shift offset clearer > - define SALRN values, mask and shift offset in header > > Jan Hoffmann (2): > realtek: set up L2 table entries properly > realtek: use assisted learning on CPU port > > .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 45 ++- > .../drivers/net/dsa/rtl83xx/rtl838x.h | 6 +++ > 2 files changed, 41 insertions(+), 10 deletions(-) Thanks for the respin! Both patches have been applied on master. Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] libnl-tiny: set SOCK_CLOEXEC if available
From: Joerg Vehlow
If CLOEXEC is not set on the netlink socket, restarting netifd using ubus
fails with "Failed to initialize system control", because the bind call
in nl_connect fails with EADDRINUSE, due to the inherited socket handle.
Also it does not make sense, to leak the handle to child processes.
See libnl3: ca0fc7558 ("socket: Set SOCK_CLOEXEC if available")
Signed-off-by: Joerg Vehlow
---
nl.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/nl.c b/nl.c
index c875573..32d26a3 100644
--- a/nl.c
+++ b/nl.c
@@ -106,9 +106,14 @@
int nl_connect(struct nl_sock *sk, int protocol)
{
int err;
+ int flags = 0;
socklen_t addrlen;
- sk->s_fd = socket(AF_NETLINK, SOCK_RAW, protocol);
+#ifdef SOCK_CLOEXEC
+ flags = SOCK_CLOEXEC;
+#endif
+
+ sk->s_fd = socket(AF_NETLINK, SOCK_RAW | flags, protocol);
if (sk->s_fd < 0) {
err = -nl_syserr2nlerr(errno);
goto errout;
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
