Re: procd/ujail behaviour
Am 11.12.2021 um 08:02 schrieb e9hack: The easiest way to make the timeout configurable is to add an additional parameter to the ujail call if the timeout deviates from the default value. You did it implemented in this way already. Thanks! Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: procd/ujail behaviour
Am 10.12.2021 um 15:18 schrieb Daniel Golle: It'd be nice if you can try the patch attached (to be put in package/system/procd/patches) and let me know what you think. Hi Daniel, the attached patch solves my issue with stubby. The easiest way to make the timeout configurable is to add an additional parameter to the ujail call if the timeout deviates from the default value. For some reason gmail did eat your mail as spam. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
Hi all, We have 5 Mikrotik 912UAG in our Freifunk Network and just build and updated them this week from ar71xx 2020 to latest tunk ath79...so far so cool.. all wifi routers mesh .. thx for the upstream work! The first thing that was (is) not working: we can not get your 2nd wifi card in the mPCIe port up and running.. Denis provided a test patch to enable pcie early in the dts file .. works now… thx a mill! Second issue: 5/5 of our productive Freifunk mesh rb912uag nodes are able to provide 1G Ethernet with the old ar71xx but not with current ath79 trunk … force a Ethernet speed downgrade to just 100M (ethtool -s eth0 advertise 0x008) works for 4/5 … 1 node does not even work with this… there is a 30m CAT5 ethernet cable between the rb912uag mesh router and the first openwrt xiaomi 4A AP (Gigabit version) .. working properly under ar71xx with 1G … with ath79 trunk 1G is not working and 100M is not working either… my guess is that the ethernet power for tx or rx or both is in ath79 different compared to ar71xx … so I would expect to find different register settings on ar71xx and ath79 for the ar8003 chip.. what do you think ? .. devmem2 read the register space from ar71xx und ath79 and compare ? Greetings Thomas > On 10. Dec 2021, at 16:41, Denis K wrote: > >> Added to my staging tree. > Thank you, Koen! It is very good news for me this Friday night. > > Regards, Denis > > ___ > 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: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
> Added to my staging tree. Thank you, Koen! It is very good news for me this Friday night. Regards, Denis ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: procd/ujail question
On Fri, Dec 10, 2021 at 04:03:34PM +0100, e9hack wrote: > > Hi, > > usually the files for a jailed process must be given via procd_add_jail_mount > or procd_add_jail_mount_rw. It looks like that this isn't necessary for > hostapd. Why not? I can't found this two parameters in '/etc/init.d/wpad'. Using namespaces is not mandatory when using other ujail features (ie. capabilities or seccomp can be used also without namespaces). So hostapd doesn't use mount/filesystem namespaces at this moment but rather only uses ujail to retain some capabilities while being run as user and group 'network' (instead of 'root'). I choose to do it in that way because the files needed for hostapd at run-time depend on the configuration (think: tls certificates or credentials stored in files) which isn't known by the init script and may also change without having to restart the process. Hence limiting filesystem access would always conflict with configurations which are using addtional files. Another example is umdns which uses ujail only for setting up seccomp filter and doesn't make use of any other ujail features. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
On 10.12.21 16:14, Denis K wrote: Mikrotik RB912UAG needs to be better supported in ath79, imho and I'm working on it. Reset key, Gigabit Ethernet, mPCIe slot, UART -- all need to be fixed. This patch adds support for reset key, next one I'm working on will fix mPCIe slot. No ideas about how to fix Gigabit, sigh. Guys, please tell me what should I change in this patch to make it useful for upstream? Regards, Denis Kalashnikov I missed these as I'm doing lots of stuff outside of OpenWRT the past few months. Added to my staging tree. Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
Mikrotik RB912UAG needs to be better supported in ath79, imho and I'm working on it. Reset key, Gigabit Ethernet, mPCIe slot, UART -- all need to be fixed. This patch adds support for reset key, next one I'm working on will fix mPCIe slot. No ideas about how to fix Gigabit, sigh. Guys, please tell me what should I change in this patch to make it useful for upstream? Regards, Denis Kalashnikov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
procd/ujail question
Hi, usually the files for a jailed process must be given via procd_add_jail_mount or procd_add_jail_mount_rw. It looks like that this isn't necessary for hostapd. Why not? I can't found this two parameters in '/etc/init.d/wpad'. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: procd/ujail behaviour
Hi Hartmut,
yes, this is a known problem affecting jailed services not terminating
on TERM signal (or not terminating fast enough).
As trapping KILL signal is not possible, simply forwarding this signal
to the jailed process is not possible.
I have a patch ready which lets ujail handle the timeout and sending of
SIGKILL (instead of letting procd send SIGKILL to ujail which will not
have the desired effect). However, in this way the termination timeout
can not be adjusted and is hard-coded to 5 seconds for now (passing the
term-timeout as paramter to ujail would be possible, but I haven't
implemented that yet).
Another option would be to hijack another signal (SIGUSR2, for example)
to be sent to ujail by procd which would make ujail then send SIGKILL
to the jailed process. While hat approach is more easy to implement and
allows using the existing timeout logic in procd (which is adjustable),
it then no longer allows forwarding that hijacked signal (SIGUSR2) to
the jailed process which is also not nice.
An even more complicated option would be to let ujail *always* expose
an ubus object and then let procd tell ujail to send signals via ubus.
(this is currently implemented for OCI containers, but not for ujail'ed
services).
It'd be nice if you can try the patch attached (to be put in
package/system/procd/patches) and let me know what you think.
Cheers
Daniel
On Fri, Dec 10, 2021 at 02:12:30PM +0100, e9hack wrote:
>
> Hi,
>
> I did update the init script for stubby, that it runs with ujail. Stubby does
> run, but it isn't possible to stop it via '/etc/init.d/stubby stop'. The
> ujail process is stopped, but stubby itself not. It looks like that it isn't
> possible to stop stubby with SIGTERM. Stubby will be ended by SIGKILL only.
> Procd sends first SIGTERM and than SIGKILL to ujail, but ujail sends SIGTERM
> only. Either ujail doesn't send SIGKILL if the jailed process doesn't
> terminate or procd sends SIGKILL to early so that ujail can't send SIGKILL
> any more. In the log I see the following messages:
>
> Fri Dec 10 13:35:52 2021 user.err : jail: forwarding signal 15 to the jailed
> process
> Fri Dec 10 13:35:52 2021 daemon.err stubby[6669]: jail: forwarding signal 15
> to the jailed process
> Fri Dec 10 13:35:57 2021 daemon.info procd: Instance stubby::stubby pid 6669
> not stopped on SIGTERM, sending SIGKILL instead
>
> 6669 was the pid of the ujail process.
>
> In ujail, I changed a few DEBUG() calls to ERROR(). Without this, the first
> two lines are not shown.
>
> Any ideas?
>
> Regards,
> Hartmut
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>From 478ef55cdc2d0e0a615a4fb19430d2ca34c21b31 Mon Sep 17 00:00:00 2001
From: Daniel Golle
Date: Fri, 10 Dec 2021 13:48:59 +
Subject: [PATCH] jail: make sure jailed process is terminated
Don't ever send SIGKILL to ujail, as that will kill ujail but not the
jailed process.
Instead, let ujail send SIGKILL in case of SIGTERM not succeeding after
a fixed timeout of 5 seconds.
Signed-off-by: Daniel Golle
---
jail/jail.c| 8 +++-
service/instance.c | 9 ++---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/jail/jail.c b/jail/jail.c
index 6e9306d..bc2c039 100644
--- a/jail/jail.c
+++ b/jail/jail.c
@@ -1093,11 +1093,17 @@ static void jail_handle_signal(int signo)
if (hook_running) {
DEBUG("forwarding signal %d to the hook process\n", signo);
kill(hook_process.pid, signo);
+ /* set timeout to send SIGKILL hook process in case SIGTERM
doesn't succeed */
+ if (signo == SIGTERM)
+ uloop_timeout_set(_process_timeout, 5000);
}
if (jail_running) {
DEBUG("forwarding signal %d to the jailed process\n", signo);
kill(jail_process.pid, signo);
+ /* set timeout to send SIGKILL jail process in case SIGTERM
doesn't succeed */
+ if (signo == SIGTERM)
+ uloop_timeout_set(_process_timeout, 5000);
}
}
@@ -1112,7 +1118,7 @@ static void signals_init(void)
if (!sigismember(, i))
continue;
- if ((i == SIGCHLD) || (i == SIGPIPE) || (i == SIGSEGV))
+ if ((i == SIGCHLD) || (i == SIGPIPE) || (i == SIGSEGV) || (i ==
SIGSTOP) || (i == SIGKILL))
continue;
s.sa_handler = jail_handle_signal;
diff --git a/service/instance.c b/service/instance.c
index 748c1e5..07a6239 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -867,7 +867,8 @@ instance_stop(struct service_instance *in, bool halt)
in->halt = halt;
in->restart = in->respawn = false;
kill(in->proc.pid, SIGTERM);
- uloop_timeout_set(>timeout, in->term_timeout * 1000);
+ if (!in->has_jail)
+
procd/ujail behaviour
Hi, I did update the init script for stubby, that it runs with ujail. Stubby does run, but it isn't possible to stop it via '/etc/init.d/stubby stop'. The ujail process is stopped, but stubby itself not. It looks like that it isn't possible to stop stubby with SIGTERM. Stubby will be ended by SIGKILL only. Procd sends first SIGTERM and than SIGKILL to ujail, but ujail sends SIGTERM only. Either ujail doesn't send SIGKILL if the jailed process doesn't terminate or procd sends SIGKILL to early so that ujail can't send SIGKILL any more. In the log I see the following messages: Fri Dec 10 13:35:52 2021 user.err : jail: forwarding signal 15 to the jailed process Fri Dec 10 13:35:52 2021 daemon.err stubby[6669]: jail: forwarding signal 15 to the jailed process Fri Dec 10 13:35:57 2021 daemon.info procd: Instance stubby::stubby pid 6669 not stopped on SIGTERM, sending SIGKILL instead 6669 was the pid of the ujail process. In ujail, I changed a few DEBUG() calls to ERROR(). Without this, the first two lines are not shown. Any ideas? Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 00/13] Switch realtek target to upstream platform
Hi, On 09.12.21 22:26, Sander Vanheule wrote: > This patch series is intended to reduce the maintenance burden, without > introducing > breaking changes to devices already in OpenWrt. No promises are made for > out-of-tree code. This patch will unfortunately considerably increase the maintenance burden, because it pushes the code into a direction which does not reflect what these devices are. They use SMT, SMP and they have different cpu-architectures. This should be reflected by any new choice for the core architecture of the realtek code in OpenWRT. With regard to out-of tree code: This is where the features come from. They come from that development and it's the features users care for, the reason they are willing to test new stuff and the reason some users provide access to development devices. Also, the RTL9300 and RTL9310 code is in-tree. This is how we make sure that new developments are consistent across all architectures. > Of course we need to discuss how we should move forward to implement working > SMT support > etc., but I feel that this patch series should not depend on that discussion. > There is > upstream code that runs on RTL8380 and RTL8390, and OpenWrt code provides the > same > features in a different way. If we want to support SMT upstream, we may have > to submit > code there anyway, so why do things twice? It is much too early to submit this upstream. We have already provided code upstream before we had sufficient understanding of how things work several times. Example: the interrupt controller code was pushed to mainline before we understood that this actually is at the core of how to make VSMP work on the RTL9300. We did not even understand why there was a double set of registers already on the RTL8390, because of course there this is not necessary. But now you just told me that the patches for this IRQ controller do not apply to the patches that provide that controller from mainline? Patches on top of patches are not a maintenance burden? When in addition the controller needs a complete re-write because we had no clue what it really was supposed to do? And another example: the GPIO driver went to mainline before we understood how it works on the RTL9300. Again, in order to use it on these devices we have patches on top of patches and this is not a figure of speech, this is reality. And it still does not work on the RTL9300, at least not for me. But I need this to work reliably to be able to provide support. And don't let me get started how it works on the RTL931x. I am really happy I resisted the push to have the RTL9300 timer code upstreamed, because again, it is doing something completely different from what we thought at that time: the timer is not about being able to do precision cable diagnostics, it is about making VSMP work on the RTL9300. And for that it needs to work quite differently including a big re-write. > > If you would like code to be supported, please submit patches we can review. > Frequent > small, incremental changes would be fine for me; maybe even preferable. IMHO > you're not > doing yourself a favour by keeping months worth of changes out-of-tree. I have been providing code bit by bit in the past, such as the RTL9300 support and there are even bits of the RTL931x architecture which allow booting of such devices. But now this is not being recognised, since there are no devices in tree to use that code. Well, I tried to add those, I tried with the GS1900-48 using the RTL8390 and I tried with the XGS1210 using the RTL9300. But guess what? I was told to come back in a couple of months because the support was not complete and SFP/SFP+ and the like worked. I really would like to provide more often code, but something as simple as adding Routing Offload needed 3k lines of code and that needs time to develop. Providing half of it is not going to fly: which user wants half of their traffic end in nirvana, or all of their traffic being uncontrollable by any firewall? Add on top of that that routing offload works quite differently on the different platforms and the fact that you need to make a reasonable choice how to support them under one hat, and unfortunately this means months of work. I would love to provide 10GBit SFP+ support on the RTL9300 quickly at this point, but then I am having real trouble with the GPIO driver on that platform which I need for the SFP cages but is patches on top of mainline patches. > Does enabling those different options on one build have that big an impact on > SoCs that > don't support all selected features? (I really don't know, don't normally do > any > performance testing.) The differences to be expected are about 50-120% more speed for optimized architectures plus (V)SMP support. 50% for VSMP, 100% for SMP, plus maybe 20% for optimized compiler settings. I did some promising tests with dropbearkey. > > I would be happy to continue discussing the interrupt controller,
ath79: MikroTik RB912UAG: not working Wi-Fi card in mPCIe slot
> Thomas Hühn wrote:
>
> We have 5 Mikrotik 912UAG in our Freifunk Network and just build and updated
> them today with latest tunk .. we moved vom ar71xx to ath79 successfully,
> so far so good .. thx for your upstream work!
>
> The only thing that is not working: we can not get your 2nd wifi card in the
> mPCIe port up and running. Only the USB Port is working. We have tried
> several things to switch from USB to mPCIe .. without success:
>
> * change the dts file ar9342_mikrotik_routerboard-912uag-2hpnd.dts in
> the gpio-export section to have usb_power output = 0 and pcie_power = 1
> mPCIe port is powered with 3,3V (measured on in 2 & 4) but mPCIe WiFi
> cards (ath9k - mikrotik) are not detected, tried to rescan the PCI bus
> as well
> * change on a running 912UAG i the /sys/class/gpio/power_usb
> ../power-pcie/values ... not WiFi Card detection
> * compare the running und working mPCIe port ar71xx image on the router ...
> found out there is gpio52 used, but different latch setup .. our good
> gues was that GPIO20 could be responsible for the usb switch for the mPCIe
> port .. add gpio20 to the export folder and set it to 1.. but no WiFi card
> detection
>
> Who has some troubleshooting tips for how to disable the usb port and enable
> the mPCIe port?
I've done some tests with RB912UAG-2HPnD and R11e-5HacT.
It seems that you need to set power-pcie gpio before pci controller
driver starts. Since it doesn't support hotplug or rescan (I suppose).
gpio-export starts after, so I've used this temporarily hack in ssr
node in dts (gpio-hog):
ssr: ssr@1 {
compatible = "fairchild,74hc595";
gpio-controller;
#gpio-cells = <2>;
registers-number = <1>;
reg = <1>;
spi-max-frequency = <5000>;
power_pcie {
gpio-hog;
gpios = <7 0>;
output-high;
};
power_usb {
gpio-hog;
gpios = <6 0>;
output-low;
};
};
root@OpenWrt:~# lspci
00:00.0 Class 0280: 168c:003c
This workaround works, but it is better to make pci rescan working.
power_usb and power_pcie gpio lines are on the Serial Shift Register (ssr).
It seems that RouterBoot left both =1. But SSR while init set them =0. Then
the PCI controller (arch/mips/pci-ar724x) starts... and says: "PCIe link is
down", remembers this in the internal link_up field and never re-check
AR724x_PCI_RESET_LINK_UP register bit. When link_up is false, pci read/write
handlers always return error. When I patched it to actually check link status
before reading, I had kernel panic with Device bus error when trying to read
Vendor ID from config register (see "MIPS: pci-ar724x: avoid data bus error
due to a missing PCIe module" Gabor Juhos patch). It seems that we need to
somehow reinit the PCI host controller.
Does anyone have any ideas?
Regards, Denis
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: P2812HNUF3
12/9/21 10:14 PM, Ivar Orskaug:
Hi,
P2812HNUF3 is currently broken in main because of the kernel 5.10
increase in size. This patch increases the kernel flash partition to
3072k, aligning with P2812HNUF1. Would it be possible to apply it to
main?
Regards Ivar
diff --git
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
index 376cdaeb61..86520247d0 100644
---
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
+++
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
@@ -55,11 +55,11 @@
partition@0 {
label = "kernel";
- reg = <0x0 0x20>;
+ reg = <0x0 0x30>;
};
- partition@20 {
+ partition@30 {
label = "ubi";
- reg = <0x20 0x7e0>;
+ reg = <0x30 0x7d0>;
};
};
};
diff --git a/target/linux/lantiq/image/vr9.mk b/target/linux/lantiq/image/vr9.mk
index 909479587c..9e9818bdbf 100644
--- a/target/linux/lantiq/image/vr9.mk
+++ b/target/linux/lantiq/image/vr9.mk
@@ -282,7 +282,7 @@ define Device/zyxel_p-2812hnu-f3
DEVICE_VARIANT := F3
BOARD_NAME := P2812HNUF3
DEVICE_PACKAGES := kmod-rt2800-pci wpad-basic-wolfssl kmod-usb-dwc2
- KERNEL_SIZE := 2048k
+ KERNEL_SIZE := 3072k
SUPPORTED_DEVICES += P2812HNUF3
DEFAULT := n
endef
I'm quite sure it's only half of the fix. Isn't is necessary to change
u-boots bootcmd as well to increase the number of to be read bytes to 3072k?
Please provide some kind of migration guide in the commit message. I'm
in doubt that only sysupgrading to the changed image is all that's required.
Finally, if you have a migration path, you can enable the default build
of the P2812HNUF3 image by dropping the "DEFAULT := n".
Mathias
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
