Re: Revisiting ABI_VERSION handling policy
On 2021-02-09 23:56, Jo-Philipp Wich wrote: > Hi, > >> The last stable update didn't change SONAME, but it included changes to >> the same data structure that triggered the bug that I ran into. It could >> very likely have introduced very similar subtle breakage. > > this is a clear upstream bug then. Might make sense to look into how other > distributions deal with that. > >> Looking at the abi-laboratory timeline, there have been many incremental >> wolfssl releases that did not change the SONAME, but introduced >> potentially ABI incompatible changes. In fact, it seems to me that there >> are more breaking than non-breaking updates. > > That doesn't inspire confidence into wolfSSL at all then. Maybe we should > reconsider using it by default. If upstream is not able to deliver a stable > ABI for a crypto library, I'd say it isn't really fit for our purposes. > >> If we were to peg the ABI_VERSION to the package version, we could still >> deliver security updates by backporting relevant patches and review >> potential ABI isuses of those patches. > > If we at the same time ensure that the library SONAME is properly modified to > always match ABI_VERSION and that the packaged shared object filename matches > SONAME then it is fine for me. Merely bumping ABI_VERSION while continue > shipping the same lib*.so.123 would not work as it'd lead to the previously > mentioned file conflicts (e.g. libfoobar1.1 (ABI_VERSION:=1.1) and > libfoobar1.2 (ABI_VERSION:=1.2) both shipping libfoobar.so.123 as incorrectly > specified by upstream) It looks to me like we already have the above problem in most of those packages where you set the ABI_VERSION explicitly. Quite a few of our packages intentionally have no stable ABI. I think adjusting soname a good idea. I will look into automating it using something like this: https://github.com/NixOS/patchelf >>> [...] >> The breakage that I was seeing has nothing to do with exported symbols. >> The layout of a data structure changed. I'm not sure how to detect that >> from readelf/objdump output. > > Okay, I missed that. Still, not changing exported data structures while > keeping the current SONAME should be common sense for any library maintainer. > > The ABI_VERSION mechanism as it is right now relies on upstream being sane > obviously. I wrongly assumed that wolfSSL does proper ABI hygiene. Apparently > it doesn't so no wonder it breaks down in subtle ways. > > As for the ability to detect it - it should be possible to reconstruct > effective binary struct layout from DWARF debug info. So given debug builds of > both the old and the new library versions, the output of a utility such as > dwarfdump can be compared. I'm pretty sure this will catch changes to non-exposed structs as well, possibly with enough false positives to render it completely useless. For now I think it's much safer to simply assume every version update to be ABI-breaking unless it has explicitly been proven to be compatible. >>> [...] >> How do we address this in a proper way that isn't a potential foot-gun >> on every version upgrade? > > Apart from investing time on our end to paper over versioning deficiencies, we > should talk to upstream, raise awareness for proper SONAME versioning. Also > look how Debian deals with it (if at all). Sounds good. While some core upstream libraries might be able to do a good job on maintaining a stable ABI, I don't think we can rely on this being the case for most of them, regardless of how much awareness we raise. To sum it up, here's my current plan for resolving the immediate issues: 1. implement automatic soname patching to include ABI_VERSION 2. add config based suffix to wolfssl ABI_VERSION 3. switch back packages to automatic ABI_VERSION When we want to deliver security updates or critical bugfixes, they should either come in patch form (which won't affect ABI_VERSION), or should be verified to be fully ABI compatible and override ABI_VERSION for just that one upgrade with a comment to remove it on the next major upgrade. If we need to fix ABI_VERSION to a particular value for an incremental update, we should only ever do it in the release branch and only after a thorough review. Do you agree? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86/64: Add CONFIG_DEVMEM=y for targets/x86/64
On 09/02/21 17:46, Supriya Mane wrote: Setting 'CONFIG_DEVMEM=y' provides access to /dev/mem. Fixes "cannot access '/dev/mem' : No such file or directory" Signed-off-by: Supriya Mane --- target/linux/x86/64/config-5.4 | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/x86/64/config-5.4 b/target/linux/x86/64/config-5.4 index f09deca5b0..a483d6ea2a 100644 --- a/target/linux/x86/64/config-5.4 +++ b/target/linux/x86/64/config-5.4 @@ -115,6 +115,7 @@ CONFIG_CRYPTO_SIMD=y # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set CONFIG_CRYPTO_XTS=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set +CONFIG_DEVMEM=y CONFIG_DMA_ACPI=y CONFIG_DMA_SHARED_BUFFER=y # CONFIG_DPTF_POWER is not set It's disabled by default because it is a debugging feature that is not terribly secure (lets anyone see the RAM contents, to an extent). I'm not sure this should be enabled for all x86_64 target like that. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Revisiting ABI_VERSION handling policy
Hi, > The last stable update didn't change SONAME, but it included changes to > the same data structure that triggered the bug that I ran into. It could > very likely have introduced very similar subtle breakage. this is a clear upstream bug then. Might make sense to look into how other distributions deal with that. > Looking at the abi-laboratory timeline, there have been many incremental > wolfssl releases that did not change the SONAME, but introduced > potentially ABI incompatible changes. In fact, it seems to me that there > are more breaking than non-breaking updates. That doesn't inspire confidence into wolfSSL at all then. Maybe we should reconsider using it by default. If upstream is not able to deliver a stable ABI for a crypto library, I'd say it isn't really fit for our purposes. > If we were to peg the ABI_VERSION to the package version, we could still > deliver security updates by backporting relevant patches and review > potential ABI isuses of those patches. If we at the same time ensure that the library SONAME is properly modified to always match ABI_VERSION and that the packaged shared object filename matches SONAME then it is fine for me. Merely bumping ABI_VERSION while continue shipping the same lib*.so.123 would not work as it'd lead to the previously mentioned file conflicts (e.g. libfoobar1.1 (ABI_VERSION:=1.1) and libfoobar1.2 (ABI_VERSION:=1.2) both shipping libfoobar.so.123 as incorrectly specified by upstream) >> [...] > The breakage that I was seeing has nothing to do with exported symbols. > The layout of a data structure changed. I'm not sure how to detect that > from readelf/objdump output. Okay, I missed that. Still, not changing exported data structures while keeping the current SONAME should be common sense for any library maintainer. The ABI_VERSION mechanism as it is right now relies on upstream being sane obviously. I wrongly assumed that wolfSSL does proper ABI hygiene. Apparently it doesn't so no wonder it breaks down in subtle ways. As for the ability to detect it - it should be possible to reconstruct effective binary struct layout from DWARF debug info. So given debug builds of both the old and the new library versions, the output of a utility such as dwarfdump can be compared. >> [...] > How do we address this in a proper way that isn't a potential foot-gun > on every version upgrade? Apart from investing time on our end to paper over versioning deficiencies, we should talk to upstream, raise awareness for proper SONAME versioning. Also look how Debian deals with it (if at all). ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86/64: Add CONFIG_DEVMEM=y for targets/x86/64
Hi. W dniu 09.02.2021 o 17:46, Supriya Mane pisze: > Setting 'CONFIG_DEVMEM=y' provides access to /dev/mem. > Fixes "cannot access '/dev/mem' : No such file or directory" > > Signed-off-by: Supriya Mane > --- > target/linux/x86/64/config-5.4 | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/x86/64/config-5.4 b/target/linux/x86/64/config-5.4 > index f09deca5b0..a483d6ea2a 100644 > --- a/target/linux/x86/64/config-5.4 > +++ b/target/linux/x86/64/config-5.4 > @@ -115,6 +115,7 @@ CONFIG_CRYPTO_SIMD=y > # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set > CONFIG_CRYPTO_XTS=y > # CONFIG_DEBUG_HOTPLUG_CPU0 is not set > +CONFIG_DEVMEM=y > CONFIG_DMA_ACPI=y > CONFIG_DMA_SHARED_BUFFER=y > # CONFIG_DPTF_POWER is not set > Normally for Your own compiled images You set it in: Global build settings > Kernel build options > /dev/mem virtual device support Why do You need it enabled by default for OpenWrt provided images at https://openwrt.org/downloads? Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] x86/64: Add CONFIG_DEVMEM=y for targets/x86/64
Setting 'CONFIG_DEVMEM=y' provides access to /dev/mem. Fixes "cannot access '/dev/mem' : No such file or directory" Signed-off-by: Supriya Mane --- target/linux/x86/64/config-5.4 | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/x86/64/config-5.4 b/target/linux/x86/64/config-5.4 index f09deca5b0..a483d6ea2a 100644 --- a/target/linux/x86/64/config-5.4 +++ b/target/linux/x86/64/config-5.4 @@ -115,6 +115,7 @@ CONFIG_CRYPTO_SIMD=y # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set CONFIG_CRYPTO_XTS=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set +CONFIG_DEVMEM=y CONFIG_DMA_ACPI=y CONFIG_DMA_SHARED_BUFFER=y # CONFIG_DPTF_POWER is not set -- 2.17.1 -- Disclaimer:This message is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to other confidentiality protections. If you are not a designated recipient, you may not review, copy or distribute this message. Please notify the sender by e-mail and delete this message. GlobalEdge does not accept any liability for virus infected mails. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Compile and install OBS Studio in openwrt.
On 09/02/21 16:41, Tom Psyborg wrote: On 09/02/2021, Alberto Bursi wrote: On 09/02/21 11:45, Hongyi Zhao wrote: Hi, Is it possible for me to compile and install OBS Studio in openwrt, so that I can use it as a media server? Any hints will be highly appreciated. Regards OBS Studio is an application to record or stream your own screen, not a media server. Maybe you mean a different application? -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel actually there is a possibility to stream media files/slideshows. maybe that's what he wants? I hope not, because it's a huge application to do things that much smaller media servers (in OpenWrt packages) can also do. I doubt anyone has even tried to compile/run OBS on OpenWrt. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] openpgm: Add Pragmatic General Multicast library
On 09/02/21 04:20, Ye Holmes wrote: openpgm: Add Pragmatic General Multicast library Signed-off-by: Ye Holmes --- Sorry for the late reply; I found the messages in the "Junk" section from my thunderbird email client, my bad, :) On Sun, 7 Feb 2021 21:31:45 +, Paul Spooren wrote: Can't this package go to packages.git? Yes, I indeed wanted to push the package into packages.git, but I didn't and don't know how to push it, I can't find related information from official website, sorry again... I have now added a paragraph on the submitting patches article to send contributions to the right repository https://openwrt.org/submitting-patches -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Compile and install OBS Studio in openwrt.
On 09/02/2021, Alberto Bursi wrote: > > > On 09/02/21 11:45, Hongyi Zhao wrote: >> Hi, >> >> Is it possible for me to compile and install OBS Studio in openwrt, so >> that I can use it as a media server? >> >> Any hints will be highly appreciated. >> >> Regards >> > > OBS Studio is an application to record or stream your own screen, not a > media server. Maybe you mean a different application? > > -Alberto > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > actually there is a possibility to stream media files/slideshows. maybe that's what he wants? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Compile and install OBS Studio in openwrt.
On 09/02/21 11:45, Hongyi Zhao wrote: Hi, Is it possible for me to compile and install OBS Studio in openwrt, so that I can use it as a media server? Any hints will be highly appreciated. Regards OBS Studio is an application to record or stream your own screen, not a media server. Maybe you mean a different application? -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Revisiting ABI_VERSION handling policy
On 2021-02-09 13:00, Jo-Philipp Wich wrote: > Hi, > >> The goal of reducing unnecessary build churn makes perfect sense to me, >> but I think we need to reconsider the trade-off we're making here, and >> the failure modes of each option. > > the motivation wasn't about build-churn at all but to ensure that library > packages can be cleanly upgraded and that different versions of libraries can > coexist on the same system without trashing userspace mid-upgrade. The other > major consideration is hard package version dependencies to ensure that > library users actually depend on the binary library ABI version they've been > linked against at build time. Ah, that wasn't really clear to me from reading the commit I pointed out. >> I believe that having to manually consider whether the ABI changed when >> updating a package comes with a nasty foot-gun that can deliver very >> subtle and hard to debug failure cases. > > Upgrading a very central library package like wolfSSL which is used by uclient > (and thus opkg), wpad (wireless connectivity) and uhttpd through ustream > (webinterface access) is a sensible operation. In my view, sanely maintaining > the ABI_VERSION is simply part of the work when dealing with such a package. > > Throwing all that over board just because you've been annoyed by a bug that > cost you a few hours is not the right way forward. By that metric, we > should've dropped most of buildroot years ago already. This has nothing to do with being annoyed by that particular bug. The issue that I'm annoyed about is how easy it is for these things to creep in, even with careful checks. >> To fix this situation, I would like to switch wolfssl and maybe a few >> other packages prone to ABI breakage back to version based ABI_VERSION. >> At least wolfssl also needs a short suffix generated from config vars. > > It makes little sense to peg the ABI_VERSION to the package version, at least > without revising the packaging at the same time. The ABI version should only > change if the shipped shared objects become incompatible (or more > specifically, if the SONAME changes). The last stable update didn't change SONAME, but it included changes to the same data structure that triggered the bug that I ran into. It could very likely have introduced very similar subtle breakage. Looking at the abi-laboratory timeline, there have been many incremental wolfssl releases that did not change the SONAME, but introduced potentially ABI incompatible changes. In fact, it seems to me that there are more breaking than non-breaking updates. If we were to peg the ABI_VERSION to the package version, we could still deliver security updates by backporting relevant patches and review potential ABI isuses of those patches. > By tying the ABI version to the package version without also ensuring that the > shipped .so files are differently named, you'll also introduce file level > package conflicts. A sanely managed ABI_VERSION should ensure that it is > possible for libfoo1 (ABI_VERSION 1) and libfoo2 (ABI_VERSION 2) to coexist on > the system which is a precondition for being able to cleanly opkg-upgrading > library packages without trashing the currently running userspace. > > Especially for libraries with frequent security updates like wolfSSL, I'd > rather retain this ability. > >> If we want to reduce build churn, we should find a way to automate >> setting the ABI version, since clearly our package maintainers + review >> process cannot (and in my opinion also should not) be trusted with this >> extra responsibility. > > It should be possible to use readelf/objdump to examine the exported symbols > of a given shared object and see if either the size of a symbol changed or if > previously present ones were removed - addition should be fine. > > Maybe this is something that can be added to the FIXUP=1 stuff. The breakage that I was seeing has nothing to do with exported symbols. The layout of a data structure changed. I'm not sure how to detect that from readelf/objdump output. >> Maybe we can replace it with a hash of all installed header files. This >> might be a better way to resolve cases like this wolfssl instance, but >> we likely will still be rebuilding dependent packages on most updates. > > A hash of installed header files makes little sense imho as it does not really > tell which symbols are exported by a shared object in the end. To me it seems > you conflate two different problems here: > > a) maintaining ABI versions > b) ABI depending on compile time optionsI'm not conflating the two. I'm > saying that in the instance that I ran into, the compile time options were the cause, but the last package version update (which did not increase ABI_VERSION or soname) introduced ABI changes that could have very similar effects. Simple runtime tests often don't catch these issues (in my test only a very specific runtime config ran into it), soname version changes are not a reliable indicator, symbol chan
Re: [PATCH 0/2] enable procd security features by default
Hi! On Tue, Feb 09, 2021 at 10:28:32AM +0100, Petr Štetiar wrote: > > Daniel Golle [2020-11-07 14:17:12]: > > Hi, > > > Please report back > > FYI just noticed following on imx6q latest master: Thank you for reporting! This indeed looks like a problem. > > user.notice firewall: Reloading firewall due to ifup of wan (eth0) > user.err : jail: failed to clone/fork: Invalid argument > user.err : jail: failed to clone/fork: Invalid argument > user.err : jail: failed to clone/fork: Invalid argument > user.err : jail: failed to clone/fork: Invalid argument > user.err : jail: failed to clone/fork: Invalid argument > user.err : jail: failed to clone/fork: Invalid argument What you are seeing here is the return value of the clone() call, indicating that it has failed. As it doesn't fail on other similar ARM-32 targets (I'm testing myself on ipq4xxx), I assume that imx6 is lacking some kernel features. From CLONE(2) man page: ... EINVAL CLONE_NEWIPC was specified in the flags mask, but the kernel was not configured with the CONFIG_SYSVIPC and CONFIG_IPC_NS options. EINVAL CLONE_NEWNET was specified in the flags mask, but the kernel was not configured with the CONFIG_NET_NS option. EINVAL CLONE_NEWPID was specified in the flags mask, but the kernel was not configured with the CONFIG_PID_NS option. EINVAL CLONE_NEWUSER was specified in the flags mask, but the kernel was not configured with the CONFIG_USER_NS option. EINVAL CLONE_NEWUTS was specified in the flags mask, but the kernel was not configured with the CONFIG_UTS_NS option. ... (among a lot of other possible reasons for EINVAL, but all those should occur equally on my testing platforms as well) Can you share the output of ubus call container get_features and if that looks all good, maybe check the running kernel (ie. build with kmod-ikconfig and look at /proc/config.gz). If you haven't arrived at something obvious at that point, I guess the next thing I'd do is testing if `runc` works, ie. pull a random small docker container and see if that starts. Last imx6 hardware I touched was SolidRun's CuBox and that's a while ago, I have vague memories of giving it away to a friend to run Kodi... Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
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 --- Op 5 feb. 2021, om 00:59 heeft Paul Spooren het volgende geschreven: > > The script improves readability by using an automatic code formatter. The decreases of the switch case indentation levels make sense, but IMHO the removals of the space between redirection and source (e.g. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Revisiting ABI_VERSION handling policy
Hi, > The goal of reducing unnecessary build churn makes perfect sense to me, > but I think we need to reconsider the trade-off we're making here, and > the failure modes of each option. the motivation wasn't about build-churn at all but to ensure that library packages can be cleanly upgraded and that different versions of libraries can coexist on the same system without trashing userspace mid-upgrade. The other major consideration is hard package version dependencies to ensure that library users actually depend on the binary library ABI version they've been linked against at build time. > I believe that having to manually consider whether the ABI changed when > updating a package comes with a nasty foot-gun that can deliver very > subtle and hard to debug failure cases. Upgrading a very central library package like wolfSSL which is used by uclient (and thus opkg), wpad (wireless connectivity) and uhttpd through ustream (webinterface access) is a sensible operation. In my view, sanely maintaining the ABI_VERSION is simply part of the work when dealing with such a package. Throwing all that over board just because you've been annoyed by a bug that cost you a few hours is not the right way forward. By that metric, we should've dropped most of buildroot years ago already. > To fix this situation, I would like to switch wolfssl and maybe a few > other packages prone to ABI breakage back to version based ABI_VERSION. > At least wolfssl also needs a short suffix generated from config vars. It makes little sense to peg the ABI_VERSION to the package version, at least without revising the packaging at the same time. The ABI version should only change if the shipped shared objects become incompatible (or more specifically, if the SONAME changes). By tying the ABI version to the package version without also ensuring that the shipped .so files are differently named, you'll also introduce file level package conflicts. A sanely managed ABI_VERSION should ensure that it is possible for libfoo1 (ABI_VERSION 1) and libfoo2 (ABI_VERSION 2) to coexist on the system which is a precondition for being able to cleanly opkg-upgrading library packages without trashing the currently running userspace. Especially for libraries with frequent security updates like wolfSSL, I'd rather retain this ability. > If we want to reduce build churn, we should find a way to automate > setting the ABI version, since clearly our package maintainers + review > process cannot (and in my opinion also should not) be trusted with this > extra responsibility. It should be possible to use readelf/objdump to examine the exported symbols of a given shared object and see if either the size of a symbol changed or if previously present ones were removed - addition should be fine. Maybe this is something that can be added to the FIXUP=1 stuff. > Maybe we can replace it with a hash of all installed header files. This > might be a better way to resolve cases like this wolfssl instance, but > we likely will still be rebuilding dependent packages on most updates. A hash of installed header files makes little sense imho as it does not really tell which symbols are exported by a shared object in the end. To me it seems you conflate two different problems here: a) maintaining ABI versions b) ABI depending on compile time options Unless I missed something, it appears your original issue was due to b) and it can be solved by appending a hash of CONFIG_* symbol values to the explicitly set ABI version. Regards, 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: [PATCH v2] openpgm: Add Pragmatic General Multicast library
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Ye Holmes
> Sent: Dienstag, 9. Februar 2021 04:20
> To: m...@adrianschmutzler.de; ros...@gmail.com
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH v2] openpgm: Add Pragmatic General Multicast library
>
> openpgm: Add Pragmatic General Multicast library
Your "v2" still lacks a commit message, explaining what you do and _why_.
Note that the primary way to submit to the packages repository is via GitHub
PRs:
https://github.com/openwrt/packages/pulls
This comes with certain helpers like build tests etc.
Further help may be found here:
https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md
Best
Adrian
>
> Signed-off-by: Ye Holmes
> ---
> Sorry for the late reply; I found the messages in the "Junk"
> section from my thunderbird email client, my bad, :)
>
> On Sun, 7 Feb 2021 21:31:45 +, Paul Spooren wrote:
> > Can't this package go to packages.git?
>
> Yes, I indeed wanted to push the package into packages.git, but I didn't and
> don't know how to push it, I can't find related information from official
> website, sorry again...
>
> On Sonntag, 3. Januar 2021 12:43, Adrian wrote:
> > this lacks a commit message.
>
> Sorry, again!
> ---
> libs/openpgm/Makefile | 64 +++
> .../0001-Rename-openpgm-5.2.pc.in.patch | 22 +++
> ...hecksum.c-fix-build-with-32-bits-MMX.patch | 38 +++
> 3 files changed, 124 insertions(+)
> create mode 100644 libs/openpgm/Makefile create mode 100644
> libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
> create mode 100644 libs/openpgm/patches/0002-openpgm-pgm-
> checksum.c-fix-build-with-32-bits-MMX.patch
>
> diff --git a/libs/openpgm/Makefile b/libs/openpgm/Makefile new file mode
> 100644 index 0..15a03e926
> --- /dev/null
> +++ b/libs/openpgm/Makefile
> @@ -0,0 +1,64 @@
> +#
> +# Copyright (C) 2021 OpenWrt.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +# This Makefile for OpenPGM
> +#
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=openpgm
> +PKG_VERSION:=5.3.128
> +PKG_RELEASE:=1
> +
> +PKG_SOURCE:=release-5-3-128.tar.gz
> +PKG_SOURCE_URL:=https://github.com/steve-o/openpgm/archive
> +PKG_HASH:=8d707ef8dda45f4a7bc91016d7f2fed6a418637185d76c7ab30b30
> 6499c6d
> +393
> +
> +PKG_MAINTAINER:=Ye Holmes
> +PKG_LICENSE:=LGPL-2.1-or-later
> PKG_LICENSE_FILES:=openpgm/pgm/LICENSE
> +PKG_CPE_ID:=cpe:/a:openpgm:openpgm
> +
> +PKG_FIXUP:=autoreconf
> +PKG_BUILD_DIR:=$(BUILD_DIR)/openpgm-release-5-3-128
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/openpgm
> + TITLE:=OpenPGM, an implementation of the PGM protocol
> + URL:=http://openpgm.googlecode.com/
> + SECTION:=libs
> + CATEGORY:=Libraries
> +endef
> +
> +define Package/openpgm/description
> + OpenPGM is a library implementing the PGM reliable multicast
> + network protocol. For more information about OpenPGM, see:
> + http://openpgm.googlecode.com/
> +endef
> +
> +CONFIGURE_VARS += ac_cv_file__proc_cpuinfo=yes \
> +ac_cv_file__dev_rtc=no ac_cv_file__dev_hpet=no CONFIGURE_ARGS +=
> +--enable-static=no --enable-shared=yes
> +
> +define Build/Prepare
> + $(call Build/Prepare/Default)
> + mv $(PKG_BUILD_DIR)/openpgm/pgm/* $(PKG_BUILD_DIR)/ endef
> +
> +define Build/InstallDev
> + $(INSTALL_DIR) $(1)/usr/include/pgm
> + $(CP) $(PKG_BUILD_DIR)/include/pgm/* $(1)/usr/include/pgm/
> + $(INSTALL_DIR) $(1)/usr/lib/pkgconfig
> + $(CP) $(PKG_BUILD_DIR)/.libs/libpgm*.so* $(1)/usr/lib/
> + $(CP) $(PKG_BUILD_DIR)/openpgm-5.3.pc $(1)/usr/lib/pkgconfig/
> endef
> +
> +define Package/openpgm/install
> + $(INSTALL_DIR) $(1)/usr/lib
> + $(CP) $(PKG_BUILD_DIR)/.libs/libpgm*.so* $(1)/usr/lib/ endef
> +
> +$(eval $(call BuildPackage,openpgm))
> diff --git a/libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
> b/libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
> new file mode 100644
> index 0..a51a026f9
> --- /dev/null
> +++ b/libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
> @@ -0,0 +1,22 @@
> +From 240634b1afb968a051f8c68696eae2a582a02450 Mon Sep 17 00:00:00
> 2001
> +From: Fabrice Fontaine
> +Date: Mon, 31 Aug 2020 20:16:25 +0200
> +Subject: [PATCH 1/2] Rename openpgm-5.2.pc.in
> +
> +This will fix the following build failure:
> +
> +config.status: error: cannot find input file: `openpgm-5.3.pc.in'
> +
> +Signed-off-by: Fabrice Fontaine
> +---
> + openpgm/pgm/{openpgm-5.2.pc.in => openpgm-5.3.pc.in} | 0
> + 1 file changed, 0 insertions(+), 0 deletions(-) rename
> +openpgm/pgm/{openpgm-5.2.pc.in => openpgm-5.3.pc.in} (100%)
> +
> +diff --git a/openpgm/pgm/openpgm-5.2.pc.in
> +b/openpgm/pgm/openpgm-5.3.pc.in similarity index 100% rename from
> +openpgm/pgm/openpgm-5.2.pc.in rename to openpgm/pgm/openpgm-
> 5.3.pc.in
> +--
> +2.25.1
> +
> diff --git a
Compile and install OBS Studio in openwrt.
Hi, Is it possible for me to compile and install OBS Studio in openwrt, so that I can use it as a media server? Any hints will be highly appreciated. Regards -- Assoc. Prof. Hongyi Zhao Theory and Simulation of Materials Hebei Polytechnic University of Science and Technology engineering NO. 552 North Gangtie Road, Xingtai, China ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] odhcpd: add option to use absolute timestamps
Maybe I will just inject via ubus a prefix, that is not reflected by the
config, like the
"UBUS_METHOD("add_prefix", handle_add_prefix, prefix_attrs)"
At the end that gives me the flexibility I need without the need to
insert absolute timestamps.
Best,
Nick
On 2/6/21 9:33 PM, Nick wrote:
I see that more as setting a preferred lifetime with a relative
time-span.
E.g. I will get a a preferred_lft of 120 from now, and I would set it
like:
date '+%d %b %Y %T' --date="@$(($(date +%s)+120))"
So it does not need to be synced, since I'm only interested in the
timespan from now + 120s.
Setting this as abs time-span will prevent a reload or restart of the
daemon setting the value again to now + 120.
Bests,
Nick
On 2/6/21 9:14 PM, Hans Dedecker wrote:
On Sat, Jan 30, 2021 at 5:33 PM Nick Hainke > wrote:
Until now it is not possible to give absolute timestamps in odhcpd.
This means that on every new RA or request, the timestamp is
renewed.
Further, the valid and preferred lifetimes are not synced between
all
devices.
There are several usecases when it is needed to have absolute
timestamp
that needed to be synced across all devices, e.g. your ISP delegates
you a prefix for some certain time, or you want to change to another
prefix.
The purpose of having this as a absolute timestamp is to make it
easier
to track. An example configuration is
option absolute_lifetime '1'
option valid_lifetime '05 Jan 2021 23:00:00'
option preferred_lifetime '05 Jan 2021 23:00:00'
If the valid_lifetime is in the past, the preferred lifetime and
valid
lifetime are set to 1 minute.
I have my reservations about the patch as it requires knowledge of
absolute time on devices.
This is a problem as not all devices have a RTC; or the time needs to
be synchronized with a wan NTP server.
This is also the reason why netifd does not to support absolute
lifetimes for configured prefixes
Hans
Signed-off-by: Nick Hainke mailto:vinc...@systemli.org>>
---
README | 8 --
src/config.c | 69
++---
src/dhcpv6-ia.c | 10 +++
src/odhcpd.h | 1 +
4 files changed, 65 insertions(+), 23 deletions(-)
diff --git a/README b/README
index f9cbb11..0af5c75 100644
--- a/README
+++ b/README
@@ -107,11 +107,13 @@ dns_service bool 1
Announce the address of interface as DNS service
if the
list of dns is empty
domain list Search
domains to announce
-leasetime string 12h DHCPv4 address leasetime
+leasetime string 12h DHCPv4 address leasetime. If
absolute_lifetime is
+ set the
value can be given as a date, e.g. "10 Jan 2020 00:00:00".
start integer 100 DHCPv4 pool start
limit integer 150 DHCPv4 pool size
preferred_lifetime string 12h Value for the preferred
lifetime
- for a prefix
+ for a
prefix. If absolute_lifetime is set the value can
+ be given
as a date, e.g. "10 Jan 2020 00:00:00".
ra_default integer 0 Override default route
0: default, 1: ignore no public address,
2: ignore all
ra_flags list other-config List of RA
flags to be
@@ -145,6 +147,8 @@ ndproxy_slave bool 0
NDProxy external slave
prefix_filter string ::/0 Only
advertise on-link prefixes within
[IPv6 prefix] the
provided IPv6 prefix; others are
filtered out.
+absolute_lifetime bool 0 Interpret configured
lifetime as
+ absolute timestamps. The format has to be "10 Jan 2020 00:00:00".
Sections of type host (static leases)
diff --git a/src/config.c b/src/config.c
index 78b5855..42f73a1 100644
--- a/src/config.c
+++ b/src/config.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -83,6 +84,7 @@ enum {
IFACE_ATTR_NDPROXY_SLAVE,
IFACE_ATTR_PREFIX_FILTER,
IFACE_ATTR_PREFERRED_LIFETIME,
+ IFACE_ATTR_ABSOLUTE_LIFETIME,
IFACE_ATTR_MAX
};
@@ -132,6 +134,7 @@ static const struct blobmsg_policy
iface_attrs[IFACE_ATTR_MAX] = {
[IFACE_ATTR_NDPROXY_SLAVE] = { .name = "ndproxy_slave",
.type = BLOBMSG_TYPE_BOOL },
[IFACE_ATTR_PREFIX_FILTER] = { .name = "prefix_filter",
.typ
Re: [PATCH 0/2] enable procd security features by default
Daniel Golle [2020-11-07 14:17:12]: Hi, > Please report back FYI just noticed following on imx6q latest master: user.notice firewall: Reloading firewall due to ifup of wan (eth0) user.err : jail: failed to clone/fork: Invalid argument user.err : jail: failed to clone/fork: Invalid argument user.err : jail: failed to clone/fork: Invalid argument user.err : jail: failed to clone/fork: Invalid argument user.err : jail: failed to clone/fork: Invalid argument user.err : jail: failed to clone/fork: Invalid argument daemon.info procd: Instance sysntpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash user.err : jail: failed to clone/fork: Invalid argument daemon.info procd: Instance dnsmasq::cfg01411c s in a crash loop 6 crashes, 0 seconds since last crash daemon.err modprobe: no module folders for kernel version 5.4.96+ found daemon.info procd: Instance odhcpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
