Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Hi, >>> I would like to avoid adding generating padded images by default. >> >> To just save some space? We're gzipping the images by default, which makes >> image padded to 256M just 2.7M big. I find 256M overkill for testing, so >> that's why I've suggested 32M by default for QEMU padded images. > Not building padded images saves build time, because the system doesn't > have to waste so many cycles compressing empty data. There's so many inefficiencies in the overall build process that gzip compressing a 256MB file is neglectible. >>> I just came up with this simple script, which takes an existing image and >>> pads it to full size: http://nbd.name/pad-image.pl With this, shipping >>> padded images should be unnecessary. >> >> Ok, if that is preferred, it's fine with me. But we should probably add some >> note somewhere, that in order to test this images in QEMU (x86, armvirt, >> malta), the images should be padded with this script in order to provide >> usable images. Most other targets ship image artifacts which are usable ootb, requiring one extra step to pad the combined images is a waste of user resources every single time. It also causes recurring confusion among users wanting to use x86 builds since the need for padding is neither documented, nor obvious while a combined.img.gz makes it obvious that it is an image file which requires decompression. I really don't see the huge problem with conservatively padding the combined image artifacts to something like 32 or 48MB, it must not even be 256M or more. ~ 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: [OpenWrt-Devel] [PATCH v3 4/7] uboot-tegra: add U-Boot for tegra boards
Hi Tomasz, > BTW Is there somewhere a list of packages installed on buildbots and is the > list consistent across all of them? we're slowly converging towards this: apt-get install -y \ pwgen \ locales \ buildbot-slave \ build-essential \ git-core \ subversion \ libncurses5-dev \ gawk \ unzip \ wget \ curl \ ccache \ rsync on top of a Debian 9 base image. The effective resulting package list is attached to this mail. The packages installed are not yet consistent among all slaves but the list attached to this mail should be the common subset. ~ Jo root@1be523fcdeb0:/# dpkg --get-selections adduser install apt install base-files install base-passwd install bashinstall binutilsinstall bsdutilsinstall build-essential install buildbot-slave install bzip2 install ca-certificates install ccache install coreutils install cpp install cpp-6 install curlinstall dashinstall debconf install debian-archive-keyring install debianutils install diffutils install dirmngr install dpkginstall dpkg-devinstall e2fslibs:amd64 install e2fsprogs install fakerootinstall fileinstall findutils install g++ install g++-6 install gawkinstall gcc install gcc-6 install gcc-6-base:amd64install git install git-coreinstall git-man install gnupg install gnupg-agent install gnupg-l10n install gosuinstall gpgvinstall grepinstall gzipinstall hostnameinstall init-system-helpers install iproute2install iputils-pinginstall krb5-localesinstall lessinstall libacl1:amd64 install libalgorithm-diff-perl install libalgorithm-diff-xs-perl install libalgorithm-merge-perl install libapr1:amd64 install libaprutil1:amd64 install libapt-pkg5.0:amd64 install libasan3:amd64 install libassuan0:amd64install libatomic1:amd64install libattr1:amd64 install libaudit-common install libaudit1:amd64 install libblkid1:amd64 install libbsd0:amd64 install libbz2-1.0:amd64install libc-bininstall libc-dev-bininstall libc-l10n install libc6:amd64 install libc6-dev:amd64 install libcap-ng0:amd64install libcap2:amd64 install libcc1-0:amd64 install libcilkrts5:amd64 install libcomerr2:amd64
Re: [OpenWrt-Devel] [PATCH] base-files/hotplug: add "dialout" user group and use it for ttyXYZ devices
Hi Michael, > well, it seems that the second commit did not survive (at least in master > branch)... indeed, it was broken by an improperly rebased commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5209cfa534293cb6d27574b51d03bd69a5defb0c I'd be fine with a v2 which reintroduces the lost hunk and renames tty to dialout at the same time. ~ 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: [OpenWrt-Devel] [PATCH] base-files/hotplug: add "dialout" user group and use it for ttyXYZ devices
Hi, the "tty" group has been introduced exactly for this purpose some time ago (1)(2). Any reason why we need "dialout" as well? ~ Jo 1: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5523ee3459a2d346ad068ce359cdb60dcda1239d 2: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=124ab1dc0a6235007f60953a796bf29122dfa242 signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libfstools: Output error in case of loop blkdev failure
Hi Petr,
I suggest to rephrase the subject to something like "print error in
case". I kept reading "output error" and wondered what went wrong with
the output.
> It took me quite some time today(while fixing squashfs+overlay on
> armvirt) to find out, that I was missing support for loop block device
> in kernel, so I'm adding error message which might be helpful for
> someone else in the future as well.
>
> Signed-off-by: Petr Štetiar
> ---
> libfstools/rootdisk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libfstools/rootdisk.c b/libfstools/rootdisk.c
> index dd00c1b..68a6296 100644
> --- a/libfstools/rootdisk.c
> +++ b/libfstools/rootdisk.c
> @@ -258,8 +258,10 @@ static int rootdisk_volume_init(struct volume *v)
> char str[128];
> int ret = 0;
>
> - if (!p->loop_name[0] && rootdisk_create_loop(p) != 0)
> + if (!p->loop_name[0] && rootdisk_create_loop(p) != 0) {
> + ULOG_ERR("unable to create loop device\n");
Do we have a valid errno value here? Would be useful to append the
strerror(3) description as well to see whether its ENOSYS, EINVAL etc.
> return -1;
> + }
>
> v->type = BLOCKDEV;
> v->blk = p->loop_name;
>
~ 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: [OpenWrt-Devel] [PATCH] wireguard: do not add host-dependencies if fwmark is set
HI,
I too think that making host route installation dependent on the fwmark
option is not intuitive.
> So maybe we can add an explicit option 'nohostroute' instead of making
> it depend on 'fwmark'?
A "nohostroute" (I'd prefer "peerroute" with default "1") would make
sense imho. It should also be protocol agnostic because other tunnel
protocols (e.g. 6in4) could benefit from it as well.
I'd propose a generic "option peerroute 0" which inhibits the host route
side-effect of "proto_add_host_dependency".
The term "peerroute" was chosen because it falls in line with other
options in the same group ("peeraddr", "peerdns").
~ 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: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi, > Is there any kind of "official" roadmap/checklist available what "needs" > to be done? not that I am aware of, but from the top of my head: - make sure all targets are ported properly to 4.14 - disable all devices which cannot cannot handle the increased kernel size anymore - drop all targets which are not ported to 4.14 - fix important open issues in the tracker ~ 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: [OpenWrt-Devel] RFC: procd patch to run as container/lxd
Hi, > procd causes trouble when running in a LXD container, however would be > nice to use OpenWrt as small VMs. > > There are patches [0] "fixing" the issue, but they're not really > upstream ready (for obvious reasons). > > Would it be possible to add a detection to procd if it's running in an > "unprivileged" container and behave accordingly? Ideally a fix would be added that allows normal operation in both container and non-container setups. For the cases where there is really a need to behave differently, maybe a keyword in the kernel command line (/proc/cmdline) would be acceptable to make procd behave differently. ~ 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: [OpenWrt-Devel] Meson/Ninja build system
Hi, > I think the cmake.mk-link approach would be a good idea and given > previous discussions the plan is afaik to pull in Ninja first and > once that's confirmed working via CMake add support for Meson. fine with me. > Having a look at https://www.python.org/dev/peps/pep-0537/#lifespan > it seems like a good idea to stick with 3.7? No opinion. > As for OpenWrt, there are already files with hard dependency of > python3 dating back to 2015 doing a quick grep of the source tree. > > https://github.com/openwrt/openwrt/blob/master/scripts/dl_cleanup.py > https://github.com/openwrt/openwrt/blob/master/scripts/flashing/eva_ramboot.py Both files are supplemental scripts not used as part of the actual build process. > There are also upstream projects like wireless-db that doesn't > compile/build cleanly with vanilla 2.7 > https://github.com/openwrt/openwrt/pull/1521 On the other end of the spectrum there is SCons (include/scons.mk) which apparently explicitly does not support Python 3 [1]. Having to depend on two Python versions is not ideal. Maybe it is worth sacrificing scons support for meson, depending on the number of users. ~ Jo 1: https://bitbucket.org/scons/scons/wiki/FrequentlyAskedQuestions#markdown-header-am-i-restricted-to-using-python-24-code-in-my-sconscript-files signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Meson/Ninja build system
Hi Jan, > I'm trying to add ninja and meson to packages feed. The reason for that > is described here https://github.com/openwrt/openwrt/pull/1871 and > https://github.com/openwrt/packages/issues/8315 . great to hear that! I think eventually there should be a "tools/meson/Makefile" along with an "include/meson.mk" similar to how Cmake is handled in Buildroot. I don't think it is necessary to actually add a Python 3 host build as well since the Buildroot already build-depends on a system Python, but only on 2.x while Meson requires 3. > If you want to look at that, my test repo is here > https://github.com/ja-pa/meson-turris but it's not ready for primetime > yet... Allright. Will check it out, thanks! ~ 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: [OpenWrt-Devel] Meson/Ninja build system
Hi, > A number of upstream projects are beginning to use the Meson/Ninja build > system. OpenWrt's sound/mpc and libs/libmpdclient kludge around this, > and I would like to update the glib2 package. The latest version of > glib2 uses Meson/Ninja. just what the world needed, yet another build system :) > Is there any plan to build the Meson/Ninja environment into the OpenWrt > build system? I took a quick look at "meson" but got confused after it referred to something else called "ninja". So it appears to be some high level thing producing other lowlevel things which then do stuff. I am not aware of any developer actively working on support for this, so a patch would be greatly appreciated. At least there are no plans to *not* support it. One nuisance is that it appears to mandate Python 3 while OpenWrt buildroot currently requires Python 2.7 - so in order to avoid depending on both versions, all the existing buildroot python users probably need to be ported to Python 3 first. 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: [OpenWrt-Devel] [PATCH] build: have scripts/feeds honor feed.mk of the individual feed
Hi, tbh I don't really like the approach of arbitrarily defining "feed.mk" to be a change source. Can we extend this to take all toplevel *.mk files into consideration? I think this falls more in line with what people would expect. ~ 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: [OpenWrt-Devel] Random PARTUUID on every rebuild
Hi, > Could this be a CLI parameter to make, or something that's written to > the .config? Once it is set in .config it will remain the same with every subsequent rebuild, defeating its purpose entirely. ~ 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: [OpenWrt-Devel] [PATCH] build: have scripts/feeds honor feed.mk of the individual feed
Hi, I do not understand the exact purpose of this patch. As far as I know, there is no "feed.mk" anywhere in the LuCI repo. ~ 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: [OpenWrt-Devel] Random PARTUUID on every rebuild
Hi, the random PARTUUID has been chosen to ensure that a given boot grub partition (containing grub config, kernel, sysupgrade restore tarball) boots the correct corresponding rootfs in case multiple openwrt partitions are present on the device (e.g. different versions on different block devices). Chosing a random uuid at build time was the simplest way to achieve that. The random identifier can be replaced by a stable identifier derived from the version or something like SOURCE_DATE_EPOCH combined with a checksum over the kernel config or similar. Maybe the kernel version magic value would be a suitable pseudorandom seed candidate to produce a reproducible partuuid which still distinguishes different kernel/rootfs pairs sufficiently. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt 18.06.2 service release
The OpenWrt Community is proud to announce the second service release of the stable OpenWrt 18.06 series. OpenWrt 18.06.2 incorporates a fair number of bug fixes in the network userland and the build system, as well as updates to the kernel and base packages. --- Some selected highlights of the service release are: * Linux kernel updated to versions 4.9.152/4.14.95 (from 4.9.120/4.14.63 in v18.06.1) * Security fixes for the Linux kernel, GNU patch, Glibc, BZip2, Grub, OpenSSL and MbedTLS * Build system bug fixes * IPv6 and network service fixes For a detailed list of changes since 18.06.1 refer to https://openwrt.org/releases/18.06/changelog-18.06.2 --- For latest information about the 18.06 series, refer to the wiki at: https://openwrt.org/releases/18.06/ To download the v18.06.2 images, navigate to: https://downloads.openwrt.org/releases/18.06.2/ Have fun! The OpenWrt Community signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 18.06.2 branching/builds
Hi, unfortunately the tag has already been created and builds are running are already running and uploading. We can bump mt76 with the next point release in a few weeks. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: ramips: fix D-Link DIR-615 H1 switch port mapping
Merged into my staging tree at http://git.openwrt.org/?p=openwrt/staging/jow.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] A second 'make' always rebuilds something
Hi, please share the exact steps used to trigger the issue. Running a simple "make" after an initial build here does not trigger the recompilation of uci or the kernel. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Honour NO_COLOR in include/scan.mk
Hi, > That is true. But, on the other hand, the same routine was not printing > anything if IS_TTY is not 1. I would say that this is unexpected > behaviour too. If the log file shows some error, it would be nice to see > what part was being processed. this might be, but the scope of this patch was to make the build system recognize `NO_COLOR` in order to suppress output coloring, so the implementation of this feature should do exactly that. > I do not really mind how it is fixed, so long NO_COLOR is honoured. > Otherwise, I would have to find some script that filters ANSI colour > codes and the like. Could you please send a V2 with the requested change to print $(1) without ANSII escape sequences? ~ 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: [OpenWrt-Devel] A second 'make' always rebuilds something
Hi, as far as I know, the Gluon build system is performing various rather invasive changes to the build system. Please see if you can replicate the same behavior with a vanilla OpenWrt build root. ~ 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: [OpenWrt-Devel] [PATCH] openwrt-18.06: ar71xx: Fix 5 GHz MAC address for Archer C60 v2
Hi, this patch should go through master first. It currently does not apply there. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: mbedtls: update to 2.14.1 for 18.06
Merged into openwrt-18.06 at http://git.openwrt.org/?p=openwrt/openwrt.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Honour NO_COLOR in include/scan.mk
Hi, your patch would disable the complete output if NO_COLOR is set. That does not seem to meet the expected behavior. Looks like the fallback path should still print $(1) to stderr, just without ANSI escape sequences. ~ 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: [OpenWrt-Devel] INSTALL_SUID macro
Hi Daniel, I am fine with adding a fakeroot solution. ~ 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: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices
Hi, I lean towards enabling these features by default. With the eventual switch to 4.19, most 4M boards will fall of the cliff anyway. 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: [OpenWrt-Devel] [PATCH] e2fsprogs: Update to 1.43.5
Hi, its not about symlinks, its about the paths embedded in these generated scripts. ~ 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: [OpenWrt-Devel] [PATCH 1/3] base-files: change boot & umount STOP levels -2
Hi Joseph, I've been thinking that we maybe should lower the STOP index even further, to at least 90. Apart from that the patch looks good. ~ 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: [OpenWrt-Devel] Notes on (dangerous ?) sysupgrade
Hi Reiner, > After having several unpleasant encounters using sysupgrade, I had a > quick glance at the code, after more or less successfully implementing > workarounds for incomplete sysupgrades, resulting in inconsistent systems. > My questions are: > - Is it safe, simply to kill running processes during sysupgrade ? As > there might be services, restarted automatically (by procd ?). Roughly, the sysupgrade process is as follows: 1) /sbin/sysupgrade (shell script) Parses arguments, sets default, assembles conffiles to backup, runs partials scripts in /lib/upgrade, checks the image, ends with `ubus call system sysupgrade`. All fatal exit conditions (such as invalid image) should be handled here. 2) ubus call system sysupgrade (procd ubus procedure) Invokes a procedure in procd that instructs procd to terminate itself and exec into /sbin/upgraded (which has been copied to a ramdisk at /tmp/root first), turning /tmp/root/sbin/upgraded into pid 1 and releasing the pid 1 use of /. 3) /tmp/root/sbin/upgraded (binary) Functions as pid 1 placeholder to prevent the kernel from panicking. It does two things; keep serving the watchdog to prevent spontaneous resets and executing /lib/upgrade/stage2 4) /lib/upgrade/stage2 (shell script) Assemble backup tarball, write image, append backup tarball to just written image. The exact procedure depends on the platform. So yes, it is safe to simply kill processes in the sense that there will be no procd running anymore at this point which would relaunch them. Merely killing processes instead of shutting them down through their respective init scripts is not ideal though, that eventually needs rework. Ideally sysupgrade should try to cleanly stop as many services through their respective init scripts as possible before invoking stage2, then only do the 'kill TERM; sleep 3; kill KILL' sequence on processes that somehow failed to stop initially (buggy init scripts, timeouts, ...). > - What about a killed process, simply taking some time to shut down ? > (example: squid closing lot of open files on block-device; having > internal shutdown timer 30s by default) Such services are not gracefully handled atm, see above. > - What about open swap file on block-device ? From a cursory look, it does not appear that sysupgrade currently performs any swapoff at all, adding a `swapoff -a` after the process termination would certainly make sense. > - What about mounted block-device for mass storage ? Same as swap, there is no umount handling either as far as I can see. I think this should be added as well along with the swapoff. Since the sysupgrade runs off a pivot_root'ed /tmp/root at this point, all fses should be free to umount. (Might still need two or three cycles due to layered mounts). > - What about (slow) wwan connection, managed by pppd. When killed by > sysupgrade, will netifd restart pppd ? It should not happen. Theoretically it could be that pppd is killed first while netifd is still running, netifd will then try to restart pppd shortly before netifd itself will get killed, but the second KILL loop three seconds later should catch this rare circumstance. However, as discussed above a graceful service shutdown would be better. > As a workaround, before calling sysupgrade I > - explicitly use /etc/init.d/most_services stop > - explicitly kill squid and wait for termination > - explicitly disable swap > - explicitly dismount mounted block-device > - ifdown wwan That certainly makes a lot sense and most of this should probably go into sysupgrade (stage1 aka /sbin/sysupgrade) directly. A slight difficulty is see is how to identify "most_services" but I guess a hardcoded whitelist for things like "dropbear", "openssh" or "telnetd" will do. As for awaiting squid termination - I think if its not already the case, the squid init script should be reworked so that /etc/init.d/squid stop does not return (successfully) before squid is actually stopped. > Before I had several cases, that > sysupgrade -n -v -f /tmp/newfiles.tar.gz /tmp/new_fw.bin > updated all files from /tmp/newfiles.tar.gz, but did not do the flash of > new_fw.bin This is quite strange as appending the /tmp/newfiles.tar.gz archive will only happen after /tmp/new_fw.bin has been written. I could only imagine that the image write procedure itself somehow failed, but appending the archive still worked. How exactly this could fail depends on the platform. Can you provide some more details about the device this issue occurred on? ~ 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: [OpenWrt-Devel] [PATCH] e2fsprogs: Update to 1.43.5
Hi, > Remove patch 000-relocatable.patch as it seems to be no longer needed. did you verify that the generated compile_et and make_cmds scripts are installed without absolute paths in the host staging directory? If not, then removing this path will result in very hard to debug SDK build failures for packages relying on libcom_err or libss. ~ 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: [OpenWrt-Devel] [PATCH] mdadm: add new init features; documentation; bug fixes
Hi,
comments inline.
> [...]
> + # partition - stateless, mdadm --assemble --scan
> --config=partition; see mdadm(8)
> + # uci - stateful, dynamically generated mdadm.conf via uci
> array values (below),
> + # stored in /var/etc/mdadm.conf
> + #- stateful, manually generated mdadm.conf file(s),
> + # must be preceded by a / and may be a readable
> filename
These file tags look wrong.
> [...]
> +#
> +# The mdadm 'array' section(s) are for stateful, manual configurations.
> Experts only. Use with caution.
> +#
> +#
> +# The use of multiple 'array' sections is supported by /etc/init.d/mdadm.
> +# They must all be named 'array'.
> +#
> +# As of this writing unnamed 'mdadm' sections are still allowed, but
> deprecated. Do not use.
> +#
Config "array" sections were used before as well? I do not understand
the deprecation remark.
> +
> +#config array
> + #
> + # example 'array' options may be a valid mix of:
> + #
> + # bitmap
> + # container
> + # device
> + # devices
> + # member
> + # name
> + # spare_group
> + # spares
> + # super_minor
> + # uuid
> + #
> # option bitmap /bitmap.md
> # option container :::
> + # option device /dev/md0
> + # -and/or a devices list-
> + # list devices /dev/hd* # mdadm allows glob, see glob(7)
> + # list devices /dev/sd*
> + # list devices /dev/sda1
> + # list devices /dev/sdb1
> + # list devices containers
> + # list devices partitions
> # option member 1
> + # option name raid:0
> + # option spare_group spares
> + # option spares 0
> + # option super_minor 0
> + # use uuid from block info (preferred), or mdadm --misc --detail
> /dev/md0
> + # option uuid 2084de11-70c4-4521-8f95-6113e75f1fe9
> + #
> + # These options directly translate to mdadm -- options, see man mdadm(8)
Consider linking to https://linux.die.net/man/8/mdadm, "man" is rarely
available on OpenWrt.
> diff --git a/package/utils/mdadm/files/mdadm.init
> b/package/utils/mdadm/files/mdadm.init
> index 64a50b3..5453f7d 100644
> --- a/package/utils/mdadm/files/mdadm.init
> +++ b/package/utils/mdadm/files/mdadm.init
> @@ -1,13 +1,21 @@
> #!/bin/sh /etc/rc.common
>
> -START=13
> -STOP=98
> +# 20190106, joseph.tingi...@gmail.com, significant revision; new features,
> +# safer error handling, code formatting,
> +# & multiple bug fixes
Please drop this comment, changes are recorded in Git & commit message.
> +
> +START=12
> +STOP=X99 # X99? seems to work; passed service enable/disable tests & boot
> tests
Please stick to plain 99, will change the umount prio in a separate commit.
>
> USE_PROCD=1
> PROG=/sbin/mdadm
> NAME=mdadm
>
> -CONF="/var/etc/mdadm.conf"
> +VERBOSE=0 # off
> +
> +TMP_FILE="/var/etc/mdadm.conf" # /var/etc is on /tmp; used for temporary
> state, to enable stateful only mdadm features
Please remove this comment.
> +
> +[ ! -x "$PROG" ] && exit 1
>
> append_list_item() {
> append "$2" "$1" "$3"
> @@ -30,30 +38,165 @@ append_option() {
> [ -n "$str" ] && append "$var" $(printf "%s=%s" "${name:-${opt//_/-}}"
> "$str")
> }
>
> -mdadm_common() {
> - local cfg="$1"
> - local email devices
> +verbose() {
> + local msg="$1"
> + local level="$2"
>
> - if [ -x /usr/sbin/sendmail ]; then
> - config_get email "$cfg" email
> - [ -n "$email" ] && printf "MAILADDR %s\n" "$email" >> $CONF
> + [ -z "$level" ] && level="INFO"
> +
> + if [ "$VERBOSE" == "1" ]; then
> + if [ ${#SSH_TTY} -gt 0 ]; then
> + printf "$NAME: init %7s - %b\n" "$level" "$msg"
> + else
> + # no SSH_TTY goes to logger
> + printf "$NAME: init %7s - %b\n" "$level" "$msg" |
> logger -t mdadm
> + fi
> fi
User sessions may not always happen via SSH, could be telnet, uart,
screen. Stick to either variant, independently of $SSH_TTY.
> +}
>
> - config_list_foreach "$cfg" devices append_list_item devices " "
> - [ -n "$devices" ] && printf "DEVICE %s\n" "$devices" >> $CONF
> +mdadm_conf_auto() {
> + local mdadm_conf="$1"
> +
> + if [ ! -w "$mdadm_conf" ]; then
> + if [ -z "$mdadm_conf" ]; then
> + verbose "mdadm_conf value is empty" ERROR
> + else
> + verbose "'$mdadm_conf' file not found writable" ERROR
> + fi
> + return 1
> + fi
> +
> + local block_md block_uuid mdadm_md mdadm_md_rc mdadm_uuid
> +
> + # Check block info for active linux_raid_members, if necessary then
> compare with mdadm, & dynamically update $mdadm_conf
> +
> + block_md=0 # counter
> + for block_uuid in $(block info 2> /dev/null | grep
Re: [OpenWrt-Devel] Do all devs follow GitHub or is list still the preferred discussion location?
Hi, personally I rarely visit Github PRs these days, any discussions going on there (in issues or PRs) will likely get overlooked by most devs. ~ 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: [OpenWrt-Devel] Firewall settings must be manually changed for 6to4
Hi, > I recently set up an OpenWrt 18.06.1 router at a place where the ISP > does not provide native IPv6, but does provide their own 6to4 > tunnelling server. I installed 6to4 and ip-full on the router and > configured WAN6, but was puzzled as to why IPv6 wasn't working until I > discovered that the default firewall settings block forwarded traffic. > Changing "Forward" from "reject" to "accept" under "General Settings" > resolved the problem. This is a huge security issue, you should not do that, ever. You likely need both an ingress rule allowing protocol 41 traffic and join the wan6 interface to the existing wan zone. ~ 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: [OpenWrt-Devel] Removed target staging dir in SDK
Hi, > Why did you remove this dir? To save space on the download servers. > If we want to build custom binaries using SDK, should we use something else? Use the feeds mechanism within the SDK to build your required libaries first, e.g.: ./scripts/feeds update ./scripts/feeds install libpcap make package/libpcap/compile V=s [then build custom software using libpcap]. 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: [OpenWrt-Devel] New CT firmware images
Hi, pushed as https://git.openwrt.org/c0248183a49a9830a4a2458e54e83fa8a3c646c9 after some smoke testing on a QCA9882 (Netgear R6100) ~ 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: [OpenWrt-Devel] [PATCH firewall3 2/2] utils: Free args in __fw3_command_pipe()
Hi, > Signed-off-by: Hauke Mehrtens Acked-by: Jo-Philipp Wich ~ 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: [OpenWrt-Devel] [PATCH firewall3 1/2] options.c, redirects.c: Fix possible buffer overflows
Hi, > Signed-off-by: Hauke Mehrtens Acked-by: Jo-Philipp Wich ~ 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: [OpenWrt-Devel] [PATCH] dropbear: fix dropbear startup issue
Hi Hans,
> [...]
> +boot()
> +{
> + BOOT=1
> + start "@"
Typo here, should likely be "$@".
Otherwise Acked-by.
~ 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: [OpenWrt-Devel] Missing GPG signatures
Hi, > It seems only Robert Call of the LibreCMC fork is consistently signing > releases > with the same key. But how is he verifying upstream...? probably by trusting https://openwrt.org/docs/guide-user/security/signatures I cross-signed the 18.06 key with the 17.01 one now and signed both using my personal key. ~ 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: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi, I'm against rejecting such submissions if they're self-contained enough (e.g. for DTS based targets as mentioned by Piotr). I'd favor accepting the basic board support for such boards but disabling the image generation (commented out). ~ 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: [OpenWrt-Devel] 18.06-snapshots?
Hi, > Just wondering if there are snapshots built for the backports etc > done onto the 18.06 tree (e.g. in preparation for 18.06.2), or after > release are there only adhoc builds for release candidates for the > point release? http://downloads.openwrt.org/releases/18.06-SNAPSHOT/ > If there are snapshots could the link be added to > https://downloads.openwrt.org so that interested parties could use > them (and link to them e.g. on wiki if applicable). I'd rather not. The folder is intentionally hidden to not confuse people looking for fixed release builds. 18.06-SNAPSHOT is not intended for production use, among other things it offers no long term kmod availability. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: remove /dev filter on uevents
Hi, I had a brief discussion with John on this matter and was being told that the reason for this filter was to optimize boot time. When we remove the /dev filter, boot time will increase considerably on lower end devices due to the resulting hotplug-call overhead of the huge volume of additional uevents. A better approach here would be to selectively whitelist uevents based on subsystem or similar attributes, e.g. `DEVTYPE=usb_device`. ~ 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: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi, > At least for me that's the but another reason was to enable guest > network (and BTW why Luci just don't have a single button for this?). Because it has not been implemented yet. Adding the code for it would probably consume another 5-10KB uncompressed. > [...] > Let's take for example Luci as most big part of software. > > First of all it turned out that there is luci-mod-admin-mini package and > it's supports only basic configuration which actually covers all my needs. This package is marked broken and hasn't been maintained in years. > But the luci-mod-admin-mini was not ever mentioned in wiki and seems > like not used at all. > > Even standard Luci can be easily and significantly reduced in twice just > by removing images and icons. As I already pointed out in my other reply, this is a rather optimistic assumption. At best you can expect a single digit percentage improvement by dropping icons. I know that people love to point at the ui and complain about single kilobyte size increases there while kernel and user land updates easily throw away dozens to hundreds of KB due to new transient dependencies, larger vmlinux images or additional feature code footprint. All I can say is that I've been extremely conservative with LuCI changes, always trying to not increase the storage footprint at all and avoiding dependencies or code bloat whenever possible. > Luci uses a lot of images but they are not in some optional theme > package but in sources themselves (i.e. in > modules/luci-base/htdocs/luci-static/resources/icons). See my other reply. 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: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi, > Even standard Luci can be easily and significantly reduced in twice just > by removing images and icons. I don't think this is true. The few icons bundled with LuCI at are approx 19KB overall while a recent mips 24kc snapshot build of luci-base is 126KB in size. So the images account for less than 10% of the luci-base size. > Luci uses a lot of images but they are not in some optional theme > package but in sources themselves (i.e. in > modules/luci-base/htdocs/luci-static/resources/icons). Note that we're talking about 23 icons with a size of roughly 14KB here. This is not the silver bullet which will magically make 4MB flash devices viable again. > So just by simple remodularization and moving the icons to theme we can > change tiny-theme without icons and full theme with icons. Saving about 20KB before compression, this is less than OpenWrt master consumes in size increase during a few months due to mere package updates. > I see that javascripts are already minimized (previously the wasn't) but > css files aren't yet. Saving about 4KB after squashfs compression. > Even more: we can gzip the files and serve them by Accept-Encoding: > deflate (or brotli) so they will be uncompressed by the browser itself. > I saw a patch for uhttpd that allows this. Note that squashfs performs optimized LZMA compression - shipping precompressed artifacts in rootfs would actually increase the image size due to double compression overhead. > With the ability to serve precompressed static content we can switch > icons from png to svg and this can save up to 10% of space. I doubt that. So far my LZMA compression tests have shown that precompressing content will not really result in an effective size decrease after squashfs/lzma. > All this allows us to decrease luci size at least twice. Not really, at most in a single digit percent range - if at all. > We can go further and rewrite Luci itself i.e. complete the Luci2 > project: get rid off Lua dependency and use JSON-RPC over ubus. Patches for this are very welcome. From what I learned so far, the space required to store all the modern day web framework dependencies will easily outweigh the ~70KB liblua + ~5KB lua runtime footprint. I've seen CSS scaffholdings and JS polyfills requiring more space than the entire Lua runtime. > But even this may be not needed: For Tp-Link recently was released a > mobile app Tether to control a router https://www.tp-link.com/us/tether/ This would imply both tying OpenWrt to a proprietary app and limiting its configuration to whatever settings that happen to be exposed by it - this hardly sounds like a viable solution to me. > We can try to reverse engineer the protocol of the mobile app and > implement it. Given that users can remove Luci and use the app to > configure the router. I don't think that attempting to accommodate proprietary vendor configuration protocols is going to help in significantly reducing the storage footprint in future OpenWrt versions. > So what I trying to say: sometimes the lack of space may mean that > architecture can be improved. Then it's better to fix that or wait until > it will be eventually fixed. LuCI master was recently further modularized to allow installing only the components wanted/needed to support certain functions, this could already help to reduce the footprint in some scenarios. > Smaller software is usually works faster so that's a good property to > keep even for larger devices. I'm with you here, but building small software and actively avoiding all the libraries/bloat floating around takes effort and dedication, which is scarce, especially for the rather uncommon use-cases targeted by OpenWrt. ~ 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: [OpenWrt-Devel] [PATCH firewall3] redirects: properly handle src_dport in SNAT rules
Hi, On 12/6/18 6:03 PM, Hans Dedecker wrote: > In case of SNAT rules the src_dport parameter is used both as a rewrite > parameter as well as a matching parameter which is not the expected > behavior. > The latter is caused by port_redir being set to src_dport in case dest_port > parameter is not. > As this logic is in place to mimic the old shell script based firewall > behavior for DNAT only set port_redir in case the redirect rule is > a DNAT rule. > > Signed-off-by: Hans Dedecker Acked-by: Jo-Philipp Wich > --- > redirects.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/redirects.c b/redirects.c > index 6cd09f1..ab95395 100644 > --- a/redirects.c > +++ b/redirects.c > @@ -350,7 +350,7 @@ check_redirect(struct fw3_state *state, struct > fw3_redirect *redir, struct uci_e > if (!valid) > return false; > > - if (!redir->port_redir.set) > + if (redir->target == FW3_FLAG_DNAT && !redir->port_redir.set) > redir->port_redir = redir->port_dest; > > return true; > signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: simplify code in procd_inittab_run
Hi,
> This is a trial to make it more obvious what the historically
> grown code is actually doing.
when we already refactor the code...
> Signed-off-by: Michael Heimpold
> ---
> inittab.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/inittab.c b/inittab.c
> index 4b9..41816b7 100644
> --- a/inittab.c
> +++ b/inittab.c
> @@ -259,12 +259,11 @@ void procd_inittab_run(const char *handler)
>
> list_for_each_entry(a, , list)
> if (!strcmp(a->handler->name, handler)) {
> - if (a->handler->multi) {
> - a->handler->cb(a);
> - continue;
> - }
> a->handler->cb(a);
> - break;
> + if (a->handler->multi)
> + continue;
> + else
> + break;
... why not just change this to:
if (!a->handler->multi)
break;
> }
> }
>
>
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: [OpenWrt-Devel] Enable security labels on ext4?
Hi, what is the size increase in kmod-ext4 due to this? ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] build: re-enable parallelism for mksquashfs
Hi, > I'm not sure what you mean by the images being reproducible. It means that different mksquashfs runs with different amounts of CPUs on different hosts should yield bit-identical images having the same checksum given the same input. ~ 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: [OpenWrt-Devel] Why does perl get compiled even if it not selected by any package?
Hi Hannu, yes - without any dependency tweaking (e.g. by introducing conditionals like you suggested) a given source package build-depends on the union of all dependencies of all binary packages declared by the source package. The only way to mitigate that is using conditional dependencies in the form DEPENDS:=+PACKAGE_foo-with-bar:libbar ~ 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: [OpenWrt-Devel] Add "Stale" plugin to packages feed
Hi Etienne, I would like that. The auto-close message should be mentioned that this closure marks not a rejection and that a user is free to reopen a rebased PR if he still wants it to go in. 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: [OpenWrt-Devel] ar71xx snapshots stuck at October 9
Hi, because they don't build since that date anymore. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] treewide: use wpad-basic for not small flash targets
Hi, > From: Mathias Kresin > > Add out of the box support for 802.11r and 802.11w to all targets not > suffering from small flash. > > Signed-off-by: Mathias Kresin > Signed-off-by: Kevin Darbyshire-Bryant Acked-by: Jo-Philipp Wich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] hostapd: add basic variant
Hi, > Add a basic variant which provides WPA-PSK only, 802.11r and 802.11w. > > Signed-off-by: Kevin Darbyshire-Bryant Acked-by: Jo-Philipp Wich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sign OpenWRT 18.06 PGP key with LEDE 17.01 PGP key
And how did you came to trust the LEDE 17 key in the first place? ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart
Hi Kristian, does the same happen without "bind-dynamic" ? My hunch is that dnsmasq fails to "resubscribe" to the socket after the ifindex of br-lan changed due to the network restart (which will destroy and recreate br-lan). Maybe netlink congestion or something related to privilege dropping? Can you manage to capture an strace log of the running dnsmasq instance while the network is getting restarted? ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart
Hi, whats the complete dnsmasq cmdline? ~ 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: [OpenWrt-Devel] [PATCH] netifd: proto-dhcp: handle alias interfaces
Hi, the functionality seems arbitrary and overly specific to your use case, also the option name "alias" does not really explain the effects of setting this option. IMHO you rather should write/ship a custom /etc/hotplug.d/iface/ script which deals with downing the fallback alias interface when the main one successfully sets up. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: Add cpu string to board detection
Hi,
> diff --git a/system.c b/system.c
> index 151f613..87ce2da 100644
> --- a/system.c
> +++ b/system.c
> @@ -65,6 +65,7 @@ static int system_board(struct ubus_context *ctx, struct
> ubus_object *obj,
>
> if (!strcasecmp(key, "system type") ||
> !strcasecmp(key, "processor") ||
> + !strcasecmp(key, "cpu") ||
Tabs vs. spaces
> !strcasecmp(key, "model name"))
> {
> strtoul(val + 2, , 0);
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Move rrdns to rpcd?
Hi, > why is the rrdns located under luci? because its a rpcd plugin provided by LuCI, hosted in the LuCI repo and used by LuCI. > Can we make it consistent place rrdns somewhere else? Should be doable. > Furthermore we should change the Makefile of rpcd and the cmakefile that > rrdns ist listed automatically as rpcd plugin. That makes no sense as the rrdns plugin sources are not part of the rpcd repo. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: grub2: Fix CVE-2015-8370
Merged into master at http://git.openwrt.org/?p=openwrt/openwrt.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: bzip2: Fix CVE-2016-3189
Merged into master at http://git.openwrt.org/?p=openwrt/openwrt.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage
Hi, > RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed s/^r//))C0" make that RAS_VERSION := "V1.99(OWRT.$(patsubst r%,%,$(REVISION)))C0" to avoid spawning a shell + sed process. ~ 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: [OpenWrt-Devel] [PATCH] uhttpd: add support for mutual authentication (mTLS)
Hi,
comments inline.
> From: Nuno Morais
>
> Optional mutual authentication (mTLS)
> by providing a CA certificate through a new new flag "-M"
> in order to verify client's identity.
>
> For B2B applications.
>
> This patch depends on patch
> "[OpenWrt-Devel] [PATCH] ustream-ssl: add optional mutual authentication
> (mTLS)"
> ---
> main.c | 19 +++
> tls.c | 38 ++
> tls.h | 6 ++
> 3 files changed, 59 insertions(+), 4 deletions(-)
>
> diff --git a/main.c b/main.c
> index fb27665..178d710 100644
> --- a/main.c
> +++ b/main.c
> @@ -134,6 +134,7 @@ static int usage(const char *name)
> " -s [addr:]port Like -p but provide HTTPS on this
> port\n"
> " -C file ASN.1 server certificate file\n"
> " -K file ASN.1 server private key file\n"
> + " -M file ASN.1 certificate authority certificate
> file\n"
> " -q Redirect all HTTP requests to HTTPS\n"
> #endif
> " -h directorySpecify the document root, default is
> '.'\n"
> @@ -223,7 +224,8 @@ int main(int argc, char **argv)
> int bound = 0;
> #ifdef HAVE_TLS
> int n_tls = 0;
> - const char *tls_key = NULL, *tls_crt = NULL;
> + int n_mtls = 0;
> + const char *tls_key = NULL, *tls_crt = NULL, *ca_crt = NULL;
> #endif
>
> BUILD_BUG_ON(sizeof(uh_buf) < PATH_MAX);
> @@ -232,7 +234,7 @@ int main(int argc, char **argv)
> init_defaults_pre();
> signal(SIGPIPE, SIG_IGN);
>
> - while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> + while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:M:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> switch(ch) {
> #ifdef HAVE_TLS
> case 'C':
> @@ -242,6 +244,11 @@ int main(int argc, char **argv)
> case 'K':
> tls_key = optarg;
> break;
> +
> +case 'M':
> +ca_crt = optarg;
> +n_mtls++;
> +break;
>
> case 'q':
> conf.tls_redirect = 1;
> @@ -477,8 +484,12 @@ int main(int argc, char **argv)
> return 1;
> }
>
> - if (uh_tls_init(tls_key, tls_crt))
> - return 1;
> + if (n_mtls){
> +if (uh_mtls_init(tls_key, tls_crt, ca_crt))
> +return 1;
> +} else if (uh_tls_init(tls_key, tls_crt))
> +return 1;
Tabs. vs. space
> +
> }
> #endif
>
> diff --git a/tls.c b/tls.c
> index d969b82..bc1a19d 100644
> --- a/tls.c
> +++ b/tls.c
> @@ -66,6 +66,44 @@ int uh_tls_init(const char *key, const char *crt)
> return 0;
> }
>
> +int uh_mtls_init(const char *key, const char *crt, const char *ca_crt)
> +{
Is the duplication of the TLS init code really required? Can't you
simply make the 3rd parameter optional and decide based on it whether to
enable the mutual TLS stuff or not?
> + static bool _init = false;
> +
> + if (_init)
> + return 0;
> +
> + _init = true;
> + dlh = dlopen("libustream-ssl." LIB_EXT, RTLD_LAZY | RTLD_LOCAL);
> + if (!dlh) {
> + fprintf(stderr, "Failed to load ustream-ssl library: %s\n",
> dlerror());
> + return -ENOENT;
> + }
> +
> + ops = dlsym(dlh, "ustream_ssl_ops");
> + if (!ops) {
> + fprintf(stderr, "Could not find required symbol
> 'ustream_ssl_ops' in ustream-ssl library\n");
> + return -ENOENT;
> + }
> +
> + ctx = ops->context_new(true);
> +
> + if (!ctx) {
> + fprintf(stderr, "Failed to initialize ustream-ssl\n");
> + return -EINVAL;
> + }
> +
> + if (ops->context_set_crt_file(ctx, crt) ||
> + ops->context_set_key_file(ctx, key) ||
> +ops->context_add_ca_crt_file(ctx, ca_crt) ||
> +ops->context_set_mutual_auth(ctx, 1)) {
Tabs vs. space
> + fprintf(stderr, "Failed to load certificates/key files\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static void tls_ustream_read_cb(struct ustream *s, int bytes)
> {
> struct client *cl = container_of(s, struct client, ssl.stream);
> diff --git a/tls.h b/tls.h
> index 9be74ba..620ba8f 100644
> --- a/tls.h
> +++ b/tls.h
> @@ -22,12 +22,18 @@
>
> #ifdef HAVE_TLS
>
> +int uh_mtls_init(const char *key, const char *crt, const char *ca_crt);
> int uh_tls_init(const char *key, const char *crt);
> void uh_tls_client_attach(struct client *cl);
> void uh_tls_client_detach(struct client *cl);
>
> #else
>
> +static inline int uh_mtls_init(const char *key, const char *crt, const char
> *ca_crt)
> +{
> + return -1;
> +}
> +
> static inline int uh_tls_init(const char *key, const char *crt)
> {
> return
[OpenWrt-Devel] OpenWrt 18.06.1 service release
The OpenWrt Community is proud to announce the first service release of stable OpenWrt 18.06 series, which marks the first major version after the remerger of the LEDE and OpenWrt projects. OpenWrt 18.06.1 incorporates a number of mostly security oriented fixes backported from the development branch during the last two weeks. --- Some selected highlights of the service release are: * Linux kernel updated to versions 4.9.120/4.14.63 (from 4.9.111/4.14.52 in v18.06.0) * Security fixes for Curl, Mbedtls, OpenSSL and the Linux kernel * Binary builds for the at91 and ath25 targets * Updated mwlwifi driver * Improved input validation for rpcd uci ubus calls * Crash fixes in libuci * Assorted bug fixes in netifd For a detailed list of changes since 18.06.0 refer to https://openwrt.org/releases/18.06/changelog-18.06.1 --- For latest information about the 18.06 series, refer to the wiki at: https://openwrt.org/releases/18.06/ To download the v18.06.1 images, navigate to: https://downloads.openwrt.org/releases/18.06.1/ Have fun! The OpenWrt Community ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload
Hi, personally I'm opposed to the entire code load thing. First of all I was unable to reproduce the tarballs offered by Github. Github seems to use an extended tar (pax) format while we pack our SCM clones using the more traditional ustar format, however even using `tar -cp -H pax --numeric-owner --owner=0 --group=0 --sort=name --mtime ...` seems to yield a different tar stream compared to whatever is offered by Github; - The order of the entries in the archive also seems to deviate from that of `tar --sort=name`, it looks as if Github archives are sorted using the "C" collate while GNU tar uses something else. - The PAX header format seems to be different, Github uses a global PAX header while GNU tar produces per-member headers - There seem to be proprietary tags inside Github tar (comment=) which are not present in the GNU equivalent Furthermore I dislike the idea of tailoring download mechanisms around a specific proprietary service. If the allegations about hash changes for unknown reasons are correct, then this raises a huge red flag for me and I see no reason to not assume that codeload tarballs will eventually change as well, become rate limited, redirected, discontinued or changed in other arbitrary ways. So TLDR; I prefer a locally reproducible, cached tarball of a given SCM clone over an opaque Github offer. My 2cents, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: Change the sigb buffer to be the same size as thefread
Merged into project/ucert.git, branch master at http://git.openwrt.org/?p=project/ucert.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH firewall3] defaults: use a generic check_kmod() function
Hi, applied in https://git.openwrt.org/06fa692c80fb2beb69d23d0a2c5cf667aa12f4ad ~ 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: [OpenWrt-Devel] Drop unused kernel versions
Ack! ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: make wifi report unknown command
Hi, > respectfully, the behaviour of the "wifi" command is one of the most > obtuse parts of openwrt's tooling. It does "something" with no > command output, and responds ~instantly.This is expected > behaviour for very few people. even "wifi asdfasdfa" returns > ~instantly, with no warning that it is an unknown command. Does the > command perhaps not take arguments? What would they be? The (implicit) default command could be explicitly spelled out as "wifi apply" or similar, mentioned in the usage and called when no argument is provided. Is that what you were thinking? ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: uclient-http: Close ustream file handle only if allocated
Merged into project/uclient.git, branch master at http://git.openwrt.org/?p=project/uclient.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt 18.06.0 final
Hi, The OpenWrt community is proud to announce the first release of the OpenWrt 18.06 stable version series. It incorporates over 4000 commits since branching the previous LEDE 17.01 release and has been under development for well over a year. With this release, the re-merged OpenWrt project attempts to define a baseline for future development based on the technological modernization and refined release processes done by the former LEDE project. --- Some selected highlights of this release since the previous LEDE 17.01 and OpenWrt Chaos Calmer 15.05 versions are: * Linux kernel updated to version either 4.9.111 or 4.14.52, depending on the architecture * Updated toolchain: * musl libc 1.1.19 * uClibc-ng 1.0.30 * glibc 2.26+ * gcc 7.3.0 * binutils 2.29.1 * Updated Linux kernel: * Kernel 4.9.111 for ar7, ar71xx, arc770, at91, brcm2708, brcm63xx, ixp4xx, lantiq, layerscape, mpc85xx, orion, rb532 and uml * Kernel 4.14.52 for apm821xx, archs38, armvirt, ath25, bcm53xx, brcm47xx, cns3xxx, gemini, imx6, ipq40xx, ipq806x, kirkwood, malta, mediatek, mvebu, mxs, octeon, octeontx, omap, oxnas, pistachio, ramips, sunxi and x86 * Backported network flow offloading support for targets using the 4.14 Linux kernel * Network userland: * IPv6 related fixes in DHCPv6 client and servers * Support for user DHCPv6 client options in sent packets * DHCP forced renew support (RFC6704) in odhcpd * Firewall support for conntrack helper setup and better ipset integration * Introduced support for configuring GRE, GRE-TAP, VETH, VTI, VXLAN * CAKE v20180716 includes tc filter classification making ingress prioritisation easier * Cake & sqm-scripts updated representing state of the art mitigations for bufferbloat * Wireguard VPN v20180625 with MIPS optimisations and flow-offload compatibility * System userland: * Improvements in system upgrade procedure * Bugfixes in the process manager, system message bus, embedded webserver and the configuration management library * Platform and Driver Support * Dropped adm5120, adm8668, au1000, mcs814x, omap24xx, ppc40x, ppc44x, xburst and zynq targets * Added Spectre and Meltdown mitigations as well as microcode loading support to x86 * Rebased oxnas target on top of upstream Kernel 4.14 support * Updates and new device support across all targets * Web interface: * New auto-rollback functionality to revert configuration changes when access to the router is lost * Better support for displaying virtual interfaces and low level configuration errors * Security improvements For a detailed list of changes since 18.06.0-rc2, see https://openwrt.org/releases/18.06/changelog-18.06.0-final For a complete list of changes since branching the previous old stable LEDE 17.01 release refer to https://lede-project.org/releases/18.06/changelog-18.06.0 --- Known issues: * Support for a hardware-bug workaround needed for devices having an AT8032 ethernet phy accidentally got dropped. Hence devices with that ethernet chip may experience connectivity issues. At least ubnt-loco-m-xw and most likely other single-port ubnt devices are affected. [fix merged, queued for 18.06.1] * Using ip4ip6 tunnel interface as a fallback interface accepting ip4-in-ip6 tunneled packets from any remote address doesn't work. [fix merged, queued for 18.06.1] * Support for PCIe on ox820 is broken, results in missing USB3 support on Shuttle KD20 [driver needs more work] * Images for some device became too big to support a persistent overlay, causing such models to lose configuration after a reboot. If you experience this problem, please report the affected device and consider downgrading to LEDE 17.01.5 or using the Image Builder to pack a smaller custom image. * Some devices, such as the Netgear R6100, may lack 5GHz wireless AC support. Investigation is ongoing and a fix is expected for 18.06.1. Affected users shall downgrade to LEDE 17.01.5 for the time being and wait for the first service release. * Devices using the mt76 wireless driver may experience stability issues on 2.4GHz * The legacy at91 and legacy ath25 (formerly “atheros”) targets failed to build due to image size constraints and are not part of the release. * A GUI bug prevents selecting and scrolling text in the system and kernel log pages. To solve, either upgrade “luci-theme-bootstrap” using opkg or switch to another theme. [fix merged, queued for 18.06.1] * Any outstanding issues reported at https://bugs.lede-project.org/ --- For latest information about the 18.06 series, refer to the wiki at: https://openwrt.org/releases/18.06/ To download the v18.06.0 images, navigate to: https://downloads.openwrt.org/releases/18.06.0/ --- With the release of OpenWrt 18.06, the old
Re: [OpenWrt-Devel] Multi build failures using today's master
Hi Koen,
> In function 'ath10k_dfs_radar_report':
> /mnt/ramdisk/koen/firmware/builds/generic_glmifi/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/ath10k-ct-2018-05-30-127f9818/ath10k-4.13/wmi.c:3993:7:
> error: too few arguments to function 'ar->dfs_detector->add_pulse'
> if (!ar->dfs_detector->add_pulse(ar->dfs_detector, )) {
> ^~
3083962dd4 ("ath10k-ct: fix build with current mac80211 package")
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3083962dd409360059199753bb465427c667daf5
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Disclaimer for user documentation?
Hi, maybe it would make sense to copy one of the standard boilerplate liability remarks from one of the OSS licenses and put that as generic statement into the wiki footer. Example from Apache 2.0: "Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied." or MIT (sorry for the all-caps, I lazily copy-pasted): "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE." or GPL 3: "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES." My personal approach would be picking one of these, swapping "software" with "documentation" and put that in fine print into the wiki footer, somewhere next to the license remark. Having this is yellow warning banner on top of every documentation article seems like overkill to me and would like detract users from the actual content of the documentation. My 2cents, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 'fw3' failed to connect to ubus
Hi, see https://bugs.openwrt.org/index.php?do=details_id=1693 - fixed with https://git.openwrt.org/3ee2c76ae0 (https://git.openwrt.org/aa8846bb10) Regards, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lede-imagebuilder-17.01.5-ar71xx-generic.Linux-x86_64 fails to build image
Hi again, As a workaround, run the following command once within the IB/SDK directory: sed -i -e 's,/\(usr\|lib\|etc\)/,/###/,g' ./staging_dir/host/lib/libc.so.6 This will prevent the bundled glibc from trying to dlopen() libraries on the host system which is the root cause of the assertion. ~ 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: [OpenWrt-Devel] lede-imagebuilder-17.01.5-ar71xx-generic.Linux-x86_64 fails to build image
Hi, works for me on Debian 9 und Ubuntu 18. I've got reports that it is broken on Arch which I am currently trying to install but it seems to be a pain ~ 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: [OpenWrt-Devel] [PATCH 2/2] add channel information for scan results
Hi,
comments inline.
~ Jo
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index c3c25ff..b1b39a1 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -145,6 +145,24 @@ struct iwinfo_crypto_entry {
> uint8_t auth_suites;
> uint8_t auth_algs;
> };
> +struct iwinfo_channel_info_entry {
> + /**
> + * sec_channel_offset - Secondary channel offset for HT40
> + *
> + * 0 = HT40 disabled,
> + * -1 = HT40 enabled, secondary channel below primary,
> + * 1 = HT40 enabled, secondary channel above primary
> + */
> + int sec_channel_offset;
> + /**
> + * Center channel for VHT80
> + */
> + int center_idx0;
> + /**
> + * Center channel for VHT160
> + */
> + int center_idx1;
> +};
Do we really need three ints? I think the sec_channel_offset could be an
u8 and the channel indexes u8 or u16 values.
>
> struct iwinfo_scanlist_entry {
> uint8_t mac[6];
> @@ -154,8 +172,9 @@ struct iwinfo_scanlist_entry {
> uint8_t signal;
> uint8_t quality;
> uint8_t quality_max;
> -int htmodelist;
> + int htmodelist;
Please use an u8 here.
> struct iwinfo_crypto_entry crypto;
> + struct iwinfo_channel_info_entry channel_info;
> };
>
> struct iwinfo_country_entry {
> diff --git a/iwinfo_cli.c b/iwinfo_cli.c
> index 2d58020..0d899e0 100644
> --- a/iwinfo_cli.c
> +++ b/iwinfo_cli.c
> @@ -612,6 +612,16 @@ static void print_scanlist(const struct iwinfo_ops *iw,
> const char *ifname)
> if (e->htmodelist & (1 << h))
> printf("%s ", IWINFO_HTMODE_NAMES[h]);
> printf ("\n");
> + if (e->channel_info.sec_channel_offset)
> + printf (" HT secondary channel is
> %s\n",
> +
> e->channel_info.sec_channel_offset < 0 ? "below" :
> + "above");
> + if (e->channel_info.center_idx0)
> + printf (" VHT Center IDX0: %d\n",
> + e->channel_info.center_idx0);
> + if (e->channel_info.center_idx1)
> + printf (" VHT Center IDX1: %d\n",
> + e->channel_info.center_idx1);
> }
> printf ("\n");
> }
> diff --git a/iwinfo_lua.c b/iwinfo_lua.c
> index 01581a3..bd7f0d3 100644
> --- a/iwinfo_lua.c
> +++ b/iwinfo_lua.c
> @@ -446,6 +446,17 @@ static int iwinfo_L_scanlist(lua_State *L, int
> (*func)(const char *, char *, int
> lua_pushnil(L);
> lua_setfield(L, -2, "htmodelist");
>
> + lua_pushinteger(L, e->channel_info.sec_channel_offset);
> + lua_setfield(L, -2, "sec_channel_offset");
> + if (e->channel_info.center_idx0) {
> + lua_pushinteger(L, e->channel_info.center_idx0);
> + lua_setfield(L, -2, "center_idx0");
> + }
> + if (e->channel_info.center_idx1) {
> + lua_pushinteger(L, e->channel_info.center_idx1);
> + lua_setfield(L, -2, "center_idx1");
> + }
> +
> lua_rawseti(L, -2, x);
> }
> }
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index 542ac7d..fb137b2 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -1996,6 +1996,27 @@ static void nl80211_parse_ht_capa(struct
> iwinfo_scanlist_entry *e,
> e->htmodelist |= IWINFO_HTMODE_VHT40;
> }
> }
> +static void nl80211_parse_ht_oper(struct iwinfo_scanlist_entry *e,
> + unsigned char
> *ie,
> + int len)
> +{
> + uint8_t oper_info;
> +
> + if (len < 6)
> + return;
> + oper_info = ie[1];
> + switch (oper_info & 3) {
> + case 0:
> + e->channel_info.sec_channel_offset = 0;
> + break;
> + case 1:
> + e->channel_info.sec_channel_offset = 1;
> + break;
> + case 3:
> + e->channel_info.sec_channel_offset = -1;
> + break;
> + }
> +}
> static void nl80211_parse_vht_capa(struct iwinfo_scanlist_entry *e,
> unsigned
> char *ie,
> int len)
> @@ -2024,7 +2045,7 @@ static void nl80211_parse_vht_oper(struct
> iwinfo_scanlist_entry *e,
> int len)
> {
> int chanwidth;
> - if (len < 1)
> + if (len < 3)
>
Re: [OpenWrt-Devel] [PATCH 1/2] add htmodelist for scan results
Hi,
comments inline.
On 07/13/2018 10:57 AM, Yury Shvedov wrote:
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index 929f697..c3c25ff 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -154,6 +154,7 @@ struct iwinfo_scanlist_entry {
> uint8_t signal;
> uint8_t quality;
> uint8_t quality_max;
> +int htmodelist;
Do we really need a full int here? I think an u8 or u16 should suffice.
> struct iwinfo_crypto_entry crypto;
> };
>
> diff --git a/iwinfo_cli.c b/iwinfo_cli.c
> index 49c9035..2d58020 100644
> --- a/iwinfo_cli.c
> +++ b/iwinfo_cli.c
> @@ -572,7 +572,7 @@ static void print_info(const struct iwinfo_ops *iw, const
> char *ifname)
>
> static void print_scanlist(const struct iwinfo_ops *iw, const char *ifname)
> {
> - int i, x, len;
> + int i, h, x, len;
> char buf[IWINFO_BUFSIZE];
> struct iwinfo_scanlist_entry *e;
>
> @@ -603,8 +603,17 @@ static void print_scanlist(const struct iwinfo_ops *iw,
> const char *ifname)
> format_signal(e->signal - 0x100),
> format_quality(e->quality),
> format_quality_max(e->quality_max));
> - printf(" Encryption: %s\n\n",
> + printf(" Encryption: %s\n",
> format_encryption(>crypto));
> + if (e->htmodelist)
> + {
> + printf(" HT Capabilities: ");
> + for (h = 0; h < ARRAY_SIZE(IWINFO_HTMODE_NAMES); h++)
> + if (e->htmodelist & (1 << h))
> + printf("%s ", IWINFO_HTMODE_NAMES[h]);
> + printf ("\n");
> + }
> + printf ("\n");
Please adhere to the coding style and remove the space between "printf"
and the opening paren.
> }
> }
>
> diff --git a/iwinfo_lua.c b/iwinfo_lua.c
> index eebab8e..01581a3 100644
> --- a/iwinfo_lua.c
> +++ b/iwinfo_lua.c
> @@ -378,7 +378,7 @@ static int iwinfo_L_txpwrlist(lua_State *L, int
> (*func)(const char *, char *, in
> /* Wrapper for scan list */
> static int iwinfo_L_scanlist(lua_State *L, int (*func)(const char *, char *,
> int *))
> {
> - int i, x, len = 0;
> + int i, x, h, len = 0;
> char rv[IWINFO_BUFSIZE];
> char macstr[18];
> const char *ifname = luaL_checkstring(L, 1);
> @@ -432,6 +432,20 @@ static int iwinfo_L_scanlist(lua_State *L, int
> (*func)(const char *, char *, int
> iwinfo_L_cryptotable(L, >crypto);
> lua_setfield(L, -2, "encryption");
>
> + /* HT Modes */
> + if (e->htmodelist)
> + {
> + lua_newtable(L);
> + for (h = 0; h <
> ARRAY_SIZE(IWINFO_HTMODE_NAMES); h++)
> + {
> + lua_pushboolean(L, e->htmodelist & (1
> << h));
> + lua_setfield(L, -2,
> IWINFO_HTMODE_NAMES[h]);
> + }
> + }
> + else
> + lua_pushnil(L);
> + lua_setfield(L, -2, "htmodelist");
Please move the lua_setfield() into the if-condition and drop the else case.
> +
> lua_rawseti(L, -2, x);
> }
> }
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index ecd2d6a..542ac7d 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -1980,6 +1980,71 @@ struct nl80211_scanlist {
> int len;
> };
>
> +static void nl80211_parse_ht_capa(struct iwinfo_scanlist_entry *e,
> + unsigned char
> *ie,
> + int len)
> +{
> + int capa;
> + if (len < 2)
> + return;
> + e->htmodelist |= IWINFO_HTMODE_HT20;
> + capa = ie[0] | (ie[8] << 8);
> + if (capa & (1 << 1))
> + {
> + e->htmodelist |= IWINFO_HTMODE_HT40;
> + if (e->htmodelist & IWINFO_HTMODE_VHT20)
> + e->htmodelist |= IWINFO_HTMODE_VHT40;
> + }
> +}
> +static void nl80211_parse_vht_capa(struct iwinfo_scanlist_entry *e,
> +unsigned
> char *ie,
> +int len)
> +{
> + int capa;
> + if (len < 4)
> + return;
> + capa = ie[0] | (ie[1] << 8) | (ie[2] << 16) | (ie[3] << 24);
> +
> + e->htmodelist |= IWINFO_HTMODE_VHT20;
> + if (e->htmodelist & IWINFO_HTMODE_HT40)
> + e->htmodelist |= IWINFO_HTMODE_VHT40;
> +
> + switch ((capa >> 2) & 3) {
> + /*case 0: neither 160 nor 80+80 */
> + case 1:
> + e->htmodelist |= IWINFO_HTMODE_VHT160;
> + break;
> + case 2:
> +
Re: [OpenWrt-Devel] [PATCH 0/4] Overhaul distfeeds.conf generation
> This patchset implements a way to add additional distfeeds.conf entries > (src-dummy method), makes rootfs creation independent of feed enable > status, and moves from global ADD_DISABLED and ADD_COMMENTED symbols to > per-feed configuration. Acked-by: Jo-Philipp Wich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] build: download code from github using archive API
Hi, > Looks like it's caused by the excessive python script call. This is > indeed unexpected. I just pushed a commit to disable it altogether > for now. Sorry for the inconvenience ;( is there anything preventing you from doing a change like below to wire in the github archiving script? -- 8< -- diff --git a/include/download.mk b/include/download.mk index 3634e777c9..5a9328b55d 100644 --- a/include/download.mk +++ b/include/download.mk @@ -23,13 +23,15 @@ DOWNLOAD_RDEP=$(STAMP_PREPARED) $(HOST_STAMP_PREPARED) define dl_method $(strip \ $(if $(2),$(2), \ -$(if $(filter @APACHE/% @GITHUB/% @GNOME/% @GNU/% @KERNEL/% @SF/% @SAVANNAH/% ftp://% http://% https://% file://%,$(1)),default, \ - $(if $(filter git://%,$(1)),git, \ -$(if $(filter svn://%,$(1)),svn, \ - $(if $(filter cvs://%,$(1)),cvs, \ -$(if $(filter hg://%,$(1)),hg, \ - $(if $(filter sftp://%,$(1)),bzr, \ -unknown \ +$(if $(filter git://github.com/% https://github.com/%,$(1)),github-tarball, \ + $(if $(filter @APACHE/% @GITHUB/% @GNOME/% @GNU/% @KERNEL/% @SF/% @SAVANNAH/% ftp://% http://% https://% file://%,$(1)),default, \ +$(if $(filter git://%,$(1)),git, \ + $(if $(filter svn://%,$(1)),svn, \ +$(if $(filter cvs://%,$(1)),cvs, \ + $(if $(filter hg://%,$(1)),hg, \ +$(if $(filter sftp://%,$(1)),bzr, \ + unknown \ +) \ ) \ ) \ ) \ -- >8 -- ~ 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: [OpenWrt-Devel] [PATCH v2] build: download code from github using archive API
Hi, > It seems to be like that script does things even if the tarballs are > already existing locally. the main problem I see is that you moved the download method detection from inline make code into the external Python script ... this will cause a lot of overhead as during the metadata scanning, your script is getting executed once for every Makefile which can easily be several thousand times with feeds installed. ~ 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: [OpenWrt-Devel] [PATCH v2] build: download code from github using archive API
Hi Yousong, this change seems to introduce serious runtime regressions, see https://bugs.openwrt.org/index.php?do=details_id=1621 It seems to be like that script does things even if the tarballs are already existing locally. On a slightly related note, I find the name to be too generic. It implies that it handles all kinds of download tasks but in the end it is only a Github archive wrapper. Maybe you should rename it to github.py or similar. ~ 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: [OpenWrt-Devel] [PATCH] iwinfo: add channel survey
Hi, yes I'd prefer to see Lua bindings implemented for that. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iwinfo: add channel survey
Hi,
please find code comments inline below.
Do you plan to extend the Lua binding as well?
Also I wonder what the intended use case of this change is...
(lib)iwinfo was once meant to provide a common uniform subset of
wireless information across different driver backends such as
proprietary wl, madwifi, wext and nl80211.
Since the survey info here is only implemented for nl80211 and only
exposed in the C library interface (and the iwinfo cli) whats the
advantage compared to just using "iw" and native netlink?
Do you have some program depending on the libiwinfo C library?
Regards,
Jo
> Signed-off-by: Nick Hainke
> ---
> include/iwinfo.h | 11 +++
> iwinfo_cli.c | 31 -
> iwinfo_nl80211.c | 59
> +++-
> 3 files changed, 99 insertions(+), 2 deletions(-)
>
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index 929f697..004896e 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -157,6 +157,16 @@ struct iwinfo_scanlist_entry {
> struct iwinfo_crypto_entry crypto;
> };
>
> +struct iwinfo_survey_entry {
> + uint32_t frequency;
> + int8_t noise;
> + uint64_t channel_time;
> + uint64_t channel_time_busy;
> + uint64_t channel_time_ext_busy;
> + uint64_t channel_time_rx;
> + uint64_t channel_time_tx;
> +};
> +
> struct iwinfo_country_entry {
> uint16_t iso3166;
> char ccode[4];
> @@ -203,6 +213,7 @@ struct iwinfo_ops {
> int (*bitrate)(const char *, int *);
> int (*signal)(const char *, int *);
> int (*noise)(const char *, int *);
> + int (*survey)(const char *ifname, struct iwinfo_survey_entry *entry);
Please remove the parameter names from the function prototype.
> int (*quality)(const char *, int *);
> int (*quality_max)(const char *, int *);
> int (*mbssid_support)(const char *, int *);
> diff --git a/iwinfo_cli.c b/iwinfo_cli.c
> index 49c9035..3d8b82c 100644
> --- a/iwinfo_cli.c
> +++ b/iwinfo_cli.c
> @@ -116,6 +116,18 @@ static char * format_signal(int sig)
> return buf;
> }
>
> +static char * format_channel_time(uint64_t time)
> +{
> + static char buf[30];
> +
> + if (!time)
> + snprintf(buf, sizeof(buf), "unknown");
> + else
> + snprintf(buf, sizeof(buf), "%llu ms", time);
> +
> + return buf;
> +}
> +
> static char * format_noise(int noise)
> {
> static char buf[10];
> @@ -531,6 +543,19 @@ static char * print_phyname(const struct iwinfo_ops *iw,
> const char *ifname)
> return "?";
> }
>
> +static void print_survey(const struct iwinfo_ops *iw, const char *ifname)
> +{
> + struct iwinfo_survey_entry entry;
> + iw->survey(ifname, );
You need to check iw->survey != NULL, otherwise iwinfo will segfault
with non-nl80211 driver backends.
> + printf("%s\tESSID:\t\t\t\t%s\n", ifname, print_ssid(iw, ifname));
> + printf("\tChannel:\t\t\t%s (%s)\n", print_channel(iw, ifname),
> format_frequency(entry.frequency));
> + printf("\tNoise:\t\t\t\t%s\n", format_noise(entry.noise));
> + printf("\tchannel Active Time:\t\t%s\n",
> format_channel_time(entry.channel_time));
> + printf("\tChannel Busy
> Time:\t\t%s\n",format_channel_time(entry.channel_time_busy));
> + printf("\tExtension Channel Busy
> Time:\t%s\n",format_channel_time(entry.channel_time_ext_busy));
> + printf("\tChannel Receive
> Time:\t\t%s\n",format_channel_time(entry.channel_time_rx));
> + printf("\tChannel Transmit
> Time:\t\t%s\n",format_channel_time(entry.channel_time_tx));
> +}
>
> static void print_info(const struct iwinfo_ops *iw, const char *ifname)
> {
> @@ -805,6 +830,7 @@ int main(int argc, char **argv)
> "Usage:\n"
> " iwinfo info\n"
> " iwinfo scan\n"
> + " iwinfo survey\n"
> " iwinfo txpowerlist\n"
> " iwinfo freqlist\n"
> " iwinfo assoclist\n"
> @@ -883,7 +909,10 @@ int main(int argc, char **argv)
> break;
>
> case 's':
> - print_scanlist(iw, argv[1]);
> + if(argv[i][1] == 'c')
> + print_scanlist(iw, argv[1]);
> + else
> + print_survey(iw, argv[1]);
> break;
>
> case 't':
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index ecd2d6a..2c741a3 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -1357,6 +1357,63 @@ static int nl80211_get_signal(const char *ifname, int
> *buf)
> return -1;
> }
>
> +static int nl80211_get_channel_survey_cb(struct nl_msg *msg, void *arg)
> +{
> +
Re: [OpenWrt-Devel] SHA256 password
Hi Lev, the patch was added to save space. Dropping it will increase the libc size by a few kilobytes. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050
Hi, > This does not make sense, is the alternative to write off openwrt? > Because if ADSL + PPPoA do not work, then it is useless. Indeed, if OpenWrt does not work for your device then you should look for alternatives or try to dig into the issue yourself. > As a minimum I would expect a developer to look at the commits > between r6080 and r7050 to see what has changed and roll-back. Lets see... that is a range of 970 commits, with an estimated average of 2 minutes to review each commit that'd be 1940 minutes worth of work. Given roughly 3 hours daily spare time (weekends excluded) one can devote to OpenWrt it'd about 2 weeks worth of development time to track down this sole bug. That is quite a lot you expect as a minimum. It also not even clear if any of these commits can be clearly attributed to your problem at hand. Regards, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] FS#1567 reported: making openrwrt unusable (BT Home Hub 5) since between r6080 and r7050
Hi, > Is anyone looking into it? I doubt it, unfortunately the info in the ticket is too vague to work with. Personally I don't have any hardware to debug this. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC PATCH ustream-ssl] openssl: support OpenSSL 1.1.x API
This commit changes ustream-ssl to support OpenSSL 1.1x as backend.
OpenSSL 1.1.x made the BIO and BIO_METHOD structures opaque and
introduced new getter/setter APIs to deal with them, therfore define
forward-compat stubs for older OpenSSL versions and change the code in
ustream-io-openssl.c to only use the new API.
The new OpenSSL version also deprecated the use of TLSv1_2_server_method()
in favor to versionless method names, therefor use TLS_server_method() for
version 1.1.0 and later.
Finally, even the library initialization is not compatible anymore as
version 1.1.0 deprecated SSL_library_init() and SSL_load_error_string() in
favor to calling OPENSSL_init_ssl() instead, so adjust the ustream
initalization to use either variant, depending on the OpenSSL version.
Signed-off-by: Jo-Philipp Wich <j...@mein.io>
---
ustream-io-openssl.c | 73 +++-
ustream-openssl.c| 10 +--
2 files changed, 58 insertions(+), 25 deletions(-)
diff --git a/ustream-io-openssl.c b/ustream-io-openssl.c
index 6711055..0e45e5f 100644
--- a/ustream-io-openssl.c
+++ b/ustream-io-openssl.c
@@ -23,13 +23,37 @@
#include "ustream-ssl.h"
#include "ustream-internal.h"
+#if OPENSSL_VERSION_NUMBER < 0x1010L
+# define BIO_get_data(b) (b->ptr)
+# define BIO_set_init(b, v) (b->init = v)
+# define BIO_set_data(b, v) (b->ptr = v)
+# define BIO_meth_set_write(m, f) (m->bwrite = f)
+# define BIO_meth_set_read(m, f) (m->bread = f)
+# define BIO_meth_set_puts(m, f) (m->bputs = f)
+# define BIO_meth_set_gets(m, f) (m->bgets = f)
+# define BIO_meth_set_ctrl(m, f) (m->ctrl = f)
+# define BIO_meth_set_create(m, f) (m->create = f)
+# define BIO_meth_set_destroy(m, f) (m->destroy = f)
+
+static BIO_METHOD *BIO_meth_new(int type, const char *name)
+{
+ BIO_METHOD *bm;
+
+ bm = calloc(1, sizeof(*bm));
+
+ if (bm) {
+ bm->type = type;
+ bm->name = name;
+ }
+
+ return bm;
+}
+#endif
+
static int
s_ustream_new(BIO *b)
{
- b->init = 1;
- b->num = 0;
- b->ptr = NULL;
- b->flags = 0;
+ BIO_set_init(b, 1);
return 1;
}
@@ -39,9 +63,8 @@ s_ustream_free(BIO *b)
if (!b)
return 0;
- b->ptr = NULL;
- b->init = 0;
- b->flags = 0;
+ BIO_set_init(b, 0);
+ BIO_set_data(b, NULL);
return 1;
}
@@ -55,7 +78,7 @@ s_ustream_read(BIO *b, char *buf, int len)
if (!buf || len <= 0)
return 0;
- s = (struct ustream *)b->ptr;
+ s = (struct ustream *)BIO_get_data(b);
if (!s)
return 0;
@@ -84,7 +107,7 @@ s_ustream_write(BIO *b, const char *buf, int len)
if (!buf || len <= 0)
return 0;
- s = (struct ustream *)b->ptr;
+ s = (struct ustream *)BIO_get_data(b);
if (!s)
return 0;
@@ -116,25 +139,29 @@ static long s_ustream_ctrl(BIO *b, int cmd, long num,
void *ptr)
};
}
-static BIO_METHOD methods_ustream = {
- 100 | BIO_TYPE_SOURCE_SINK,
- "ustream",
- s_ustream_write,
- s_ustream_read,
- s_ustream_puts,
- s_ustream_gets,
- s_ustream_ctrl,
- s_ustream_new,
- s_ustream_free,
- NULL,
-};
+static BIO_METHOD *methods_ustream;
static BIO *ustream_bio_new(struct ustream *s)
{
BIO *bio;
- bio = BIO_new(_ustream);
- bio->ptr = s;
+ if (!methods_ustream) {
+ methods_ustream = BIO_meth_new(100 | BIO_TYPE_SOURCE_SINK,
"ustream");
+
+ if (!methods_ustream)
+ return NULL;
+
+ BIO_meth_set_write(methods_ustream, s_ustream_write);
+ BIO_meth_set_read(methods_ustream, s_ustream_read);
+ BIO_meth_set_puts(methods_ustream, s_ustream_puts);
+ BIO_meth_set_gets(methods_ustream, s_ustream_gets);
+ BIO_meth_set_ctrl(methods_ustream, s_ustream_ctrl);
+ BIO_meth_set_create(methods_ustream, s_ustream_new);
+ BIO_meth_set_destroy(methods_ustream, s_ustream_free);
+ }
+
+ bio = BIO_new(methods_ustream);
+ BIO_set_data(bio, s);
return bio;
}
diff --git a/ustream-openssl.c b/ustream-openssl.c
index eb03dab..6ea6429 100644
--- a/ustream-openssl.c
+++ b/ustream-openssl.c
@@ -30,16 +30,22 @@ __ustream_ssl_context_new(bool server)
SSL_CTX *c;
if (!_init) {
+#if OPENSSL_VERSION_NUMBER < 0x1010L
SSL_load_error_strings();
SSL_library_init();
+#else
+ OPENSSL_init_ssl(0, NULL);
+#endif
_init = true;
}
if (server)
-#ifdef CYASSL_OPENSSL_H_
+#if defined(CYASSL_OPENSSL_H_)
m = SSLv23_server_method();
-#else
+#elif OPENSSL_VERSION_NUMBER < 0x1010L
Re: [OpenWrt-Devel] OpenWRT mtd tooling vs mtd-utils
Hello David, this was actually my fault. I didn't pay close attention and assumed the code to be related to the kernel MTD subsystem. Only now after your mail I realized that it affects the OpenWrt specific formatting utility. I am very sorry for the confusion caused. Kind regards, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [RFC] Relocate OpenWrt mailing lists to infradead
Hi, the mailing lists should be moved now; lede-...@lists.infradead.org became openwrt-devel@lists.openwrt.org lede-...@lists.infradead.org became openwrt-...@lists.openwrt.org those who've been subscribed to the LEDE lists should still be subscribed as the subscription list has been kept through the rename. Subscribers of the old, defunct OpenWrt Development list unfortunately need to subscribe again. Regards, Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: x86: fix bios mkimage during efi image generation
Merged into my staging tree at http://git.openwrt.org/?p=openwrt/staging/jow.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Enable DCO check on Github OpenWrt organisation
Hi, ACK from me as well. > ACK to enable it for packages, not sure if it makes sense for core as we > enforce this in the project git repo already, and Github is just a mirror. It does make sense to provide immediate feedback on Github pull requests I assume. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] patchwork
Hi John, Alex, I have no problem with closing / autorejecting open tickets in patchwork as long as they somehow remain available for future reference. > To add here. Would it be possible/desire-able to add an auto-timeout > to patchwork & github PRs, issues to close after X time ? Maybe make > it official as part of the submission process. I would very much like that and have been thinking about this various times, maybe it is time to finally implement it. I could think of an idle timeout ranging somewhere between 3 to 6 months. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 00/15] Metadata generator refactoring, cleanup and PROVIDES improvements
Hi Weedy, can you provide some more context lines to see which package those broken depends belong to? Thanks, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 13/15] metadata: always resolve dependencies through provides list
Hi,
[...]
> diff --git a/scripts/package-metadata.pl b/scripts/package-metadata.pl
> index 980ad24dc0..41e7108322 100755
> --- a/scripts/package-metadata.pl
> +++ b/scripts/package-metadata.pl
> @@ -101,14 +101,16 @@ my %dep_check;
> sub __find_package_dep($$) {
> my $pkg = shift;
> my $name = shift;
> - my $deps = ($pkg->{vdepends} or $pkg->{depends});
> + my $deps = $pkg->{depends};
>
> return 0 unless defined $deps;
> - foreach my $dep (@{$deps}) {
> - next if $dep_check{$dep};
> - $dep_check{$dep} = 1;
> - return 1 if $dep eq $name;
> - return 1 if ($package{$dep} and
> (__find_package_dep($package{$dep},$name) == 1));
> + foreach my $vpkg (@{$deps}) {
> + foreach my $dep (@{$vpackage{$vpkg}}) {
> + next if $dep_check{$dep->{name}};
> + $dep_check{$dep->{name}} = 1;
> + return 1 if $dep->{name} eq $name;
> + return 1 if (__find_package_dep($dep, $name) == 1);
> + }
> }
> return 0;
> }
> @@ -156,7 +158,6 @@ sub mconf_depends {
> my $m = "depends on";
> my $flags = "";
> $depend =~ s/^([@\+]+)// and $flags = $1;
> - my $vdep;
> my $condition = $parent_condition;
>
> next if $condition eq $depend;
> @@ -173,23 +174,21 @@ sub mconf_depends {
> }
> $depend = $2;
> }
> - next if $package{$depend} and $package{$depend}->{buildonly};
> if ($flags =~ /\+/) {
> - if ($vdep = $package{$depend}->{vdepends}) {
> + my $vdep = $vpackage{$depend};
> + if ($vdep) {
> my @vdeps;
> - $depend = undef;
>
> foreach my $v (@$vdep) {
> - if ($package{$v} &&
> $package{$v}->{variant_default}) {
> - $depend = $v;
> + next if $v->{buildonly};
> + if ($v->{variant_default}) {
> + unshift @vdeps, $v->{name};
> } else {
> - push @vdeps, $v;
> + push @vdeps, $v->{name};
> }
> }
>
> - if (!$depend) {
> - $depend = shift @vdeps;
> - }
> + $depend = shift @vdeps;
>
> if (@vdeps > 1) {
> $condition = ($condition ? "$condition
> && " : '') . '!('.join("||", map { "PACKAGE_".$_ } @vdeps).')';
> @@ -209,7 +208,8 @@ sub mconf_depends {
>
> $flags =~ /@/ or $depend = "PACKAGE_$depend";
> } else {
> - if ($vdep = $package{$depend}->{vdepends}) {
> + my $vdep = $vpackage{$depend};
> + if ($vdep) {
> $depend = join("||", map { "PACKAGE_".$_ }
> @$vdep);
Use "PACKAGE_".$_->{name} here as "$vdep" now is a reference to an array
of package structures, not package names anymore.
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] owrt landing page
Hi, I've been preparing some draft for a future landing page at https://lede-project.org/openwrt. Note that some of the linked pages are obviously still LEDE branded and the links to IRC, lists, forum need to be expanded to point to both OpenWrt and LEDE forums. Maybe someone can pick up from here; the page should be editable by any registered wiki user. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC 1/2] downloads.mk: introduce name-agnostic PROJECT_GIT variable
Introduce a name-agnostic PROJECT_GIT variable poiting to https://git.openwrt.org/ and declare LEDE_GIT and OPENWRT_GIT as aliases to it. After some transition time we can drop this alias variables. Signed-off-by: Jo-Philipp Wich <j...@mein.io> --- include/download.mk | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/download.mk b/include/download.mk index 0a25641738..2ba8a7bdf4 100644 --- a/include/download.mk +++ b/include/download.mk @@ -6,8 +6,10 @@ # See /LICENSE for more information. # -OPENWRT_GIT = http://git.openwrt.org -LEDE_GIT = https://git.lede-project.org +PROJECT_GIT = https://git.openwrt.org + +OPENWRT_GIT = $(PROJECT_GIT) +LEDE_GIT = $(PROJECT_GIT) ifdef PKG_SOURCE_VERSION PKG_VERSION ?= $(if $(PKG_SOURCE_DATE),$(PKG_SOURCE_DATE)-)$(call version_abbrev,$(PKG_SOURCE_VERSION)) -- 2.14.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC 2/2] treewide: replace LEDE_GIT with PROJECT_GIT
Remove LEDE_GIT references in favor to the new name-agnostic PROJECT_GIT variable. Signed-off-by: Jo-Philipp Wich <j...@mein.io> --- package/libs/librpc/Makefile | 2 +- package/libs/libubox/Makefile| 2 +- package/libs/uclient/Makefile| 2 +- package/libs/ustream-ssl/Makefile| 2 +- package/network/config/firewall/Makefile | 2 +- package/network/config/netifd/Makefile | 2 +- package/network/ipv6/odhcp6c/Makefile| 2 +- package/network/services/odhcpd/Makefile | 2 +- package/network/services/relayd/Makefile | 2 +- package/network/services/uhttpd/Makefile | 2 +- package/network/services/umdns/Makefile | 2 +- package/network/utils/iwinfo/Makefile| 2 +- package/network/utils/umbim/Makefile | 2 +- package/network/utils/uqmi/Makefile | 2 +- package/system/fstools/Makefile | 2 +- package/system/lede-keyring/Makefile | 2 +- package/system/procd/Makefile| 2 +- package/system/rpcd/Makefile | 2 +- package/system/ubox/Makefile | 2 +- package/system/ubus/Makefile | 2 +- package/system/uci/Makefile | 2 +- package/system/usign/Makefile| 2 +- package/utils/jsonfilter/Makefile| 2 +- package/utils/ugps/Makefile | 2 +- package/utils/usbmode/Makefile | 2 +- 25 files changed, 25 insertions(+), 25 deletions(-) diff --git a/package/libs/librpc/Makefile b/package/libs/librpc/Makefile index 0330614c31..e8f51a23f1 100644 --- a/package/libs/librpc/Makefile +++ b/package/libs/librpc/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=librpc PKG_RELEASE=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/librpc-uclibc.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/librpc-uclibc.git PKG_SOURCE_DATE:=2015-11-04 PKG_SOURCE_VERSION:=a921e3ded051746f9f7cd5e5a312fb6771716aac PKG_MIRROR_HASH:=22c8dc55e1c4e8e31635a37708a3ce622a6ca33ebd918a4321b0be6ffce89b21 diff --git a/package/libs/libubox/Makefile b/package/libs/libubox/Makefile index b261430e2d..6121576103 100644 --- a/package/libs/libubox/Makefile +++ b/package/libs/libubox/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=libubox PKG_RELEASE=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/libubox.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/libubox.git PKG_SOURCE_DATE:=2017-10-06 PKG_SOURCE_VERSION:=729f47fd5279f902986457682f8f166c324eafb5 PKG_MIRROR_HASH:=5ca03294498f347f437236aeb1d55747264229a46a5ddba93caeb6b3fb735e10 diff --git a/package/libs/uclient/Makefile b/package/libs/uclient/Makefile index 3eefa2e012..f0c08a3233 100644 --- a/package/libs/uclient/Makefile +++ b/package/libs/uclient/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=uclient PKG_RELEASE=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/uclient.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/uclient.git PKG_SOURCE_DATE:=2017-11-02 PKG_SOURCE_VERSION:=4b87d83160fec70d50b7fcd736a8c538c28a016c PKG_MIRROR_HASH:=4bbb4d5f295ebdcd67fec87a6794168bea2176a42cb2907c47d8566fb33dafb3 diff --git a/package/libs/ustream-ssl/Makefile b/package/libs/ustream-ssl/Makefile index 7afbeeba66..b5e773ba7f 100644 --- a/package/libs/ustream-ssl/Makefile +++ b/package/libs/ustream-ssl/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=ustream-ssl PKG_RELEASE:=2 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/ustream-ssl.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/ustream-ssl.git PKG_SOURCE_DATE:=2016-07-02 PKG_SOURCE_VERSION:=ec80adaa1b47f28d426fa19c692011ce60b992d6 PKG_MIRROR_HASH:=bfbad6b4e8c1e933f0bfaab43cbdd44a536c08128c3a779e6f2395a6a886aab7 diff --git a/package/network/config/firewall/Makefile b/package/network/config/firewall/Makefile index 06e67543b9..1bc2c4d1fa 100644 --- a/package/network/config/firewall/Makefile +++ b/package/network/config/firewall/Makefile @@ -12,7 +12,7 @@ PKG_NAME:=firewall PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/firewall3.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/firewall3.git PKG_SOURCE_DATE:=2017-11-07 PKG_SOURCE_VERSION:=c4309372acc7e1bef8aa230269f7da1dec790e68 PKG_MIRROR_HASH:=1699884d8499d01e433959185f79ff9eb69704de47885b996123374b8015b422 diff --git a/package/network/config/netifd/Makefile b/package/network/config/netifd/Makefile index 4eb4737a3a..ade0061e7a 100644 --- a/package/network/config/netifd/Makefile +++ b/package/network/config/netifd/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=netifd PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/netifd.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/netifd.git PKG_SOURCE_DATE:=2018-01-04 PKG_SOURCE_VERSION:=fd5c399c01ceb1bbede3ae8b0e1daaa7652a6fa1 PKG_MIRROR_HASH:=0040f94d11d0039505328a90b2ff48968db873e9e7967307631bf40ef5679275 diff --git a/package/network/ipv6/odhcp6c/Makefile b/package/network/ipv6/odhcp6c/Makefile index 457a871efb..24cbe0b2cb 100644 --- a/package/network/ipv6/odhcp6c/Makefile +++ b/package/network/ipv6/odhcp6c/Makefile @@ -11,7 +11,7 @@ PKG_NAME:=odhcp6c PKG_RELE
[OpenWrt-Devel] OpenWrt source replaced by former LEDE tree
Hi, following the agreed OpenWrt/LEDE re-merge procedure, we've replaced the OpenWrt Git tree with the LEDE Git tree now and archived the old repository. If you're working with older branches such as Chaos Calmer or Barrier Breaker, you do have to update your remotes in order to continue to be able to fetch from the repository. You can find the archived OpenWrt repository including all previous branches and tags at https://github.com/openwrt/archive From now on, the https://github.com/openwrt/openwrt repository will host the contents of the former LEDE source tree at https://github.com/lede-project/source which already has been rebranded to OpenWrt in preparation for the tree swap. The synchronisation between https://github.com/openwrt/openwrt, https://github.com/lede-project/source and https://git.lede-project.org/?p=source.git will remain active until all infrastructure changes are fully settled. Kind regards, Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] A new developper documentation for OpenWrt/LEDE
Hi Baptiste,
first of all I think that is a great initiative!
> So, here is a RFC proposal of a new developer documentation based on
> git and Sphinx:
>
> https://files.polyno.me/openwrt/doc/index.html git clone
> git://git.polyno.me/openwrt-doc
The layout is okay and the ASCII markup looks reasonably simple to allow
for distraction-free text writing so LGTM here.
> This is really early work in progress, because it's good to have
> early feedback before I spend too much time on this :)
>
> The idea (which of course needs to be discussed) would be to keep
> this documentation in the same git repository as the main project.
> The main advantages compared with the wiki ("developer guide" [1] and
> associated pages [2,3]) would be:
That would be fine with me. There used to be some rudimentary
documentation in the past (see
http://git.lede-project.org/882f4d2d63272abce8c1966983aa10178e2e971f)
but it never got really updated.
> - ensuring the doc is reasonably up-to-date, because of fate
> sharing: whenever a patch modifies something substantial in the code
> base, it can update the documentation at the same time;
Such a policy can be introduced once the docs are reasonably complete,
before that it would likely put off contributors.
> - more focused scope: the scope is explicitly limited to developer
> documentation. This makes it easier to produce good, complete and
> consistent documentation. Also, as a contributor, searching for a
> particular topic would become easier than in the wiki;
I like that, yes.
> - allow release branches for the documentation. For instance, if a
> feature is changed in trunk, the documentation in the 17.01 branch
> would still be correct for LEDE 17.01. Likewise, when backporting a
> feature from trunk to a stable release, the associated documentation
> would be backported as well. This is exactly what Django does with
> its documentation [4].
That would be an upside as well; while I do not expect release branch
documentation to receive much maintenance it would at the very least
ensure that future documentation updates do not invalidate config that
used to be correct for a past release.
> On the downside, it would become harder to contribute to the
> documentation: this is likely a reason for the failure of the LEDE
> "web presence". But I think another important reason for this
> failure was the scope, which was too broad (both user + developer
> documentation).
That is a valid point but I would give it a try; after all I suspect
this documentation to target contributors already aware of how to use Git.
> Of course, this proposal is not meant to *replace* the existing
> documentation on the wiki, but rather to *complement* it. In my
> opinion, this new doc would serve as a detailed and up-to-date
> reference for OpenWrt internals, while the wiki would still be
> extremely useful for user-oriented documentation (which hopefully
> would become even more relevant and accurate thanks to this new
> reference documentation).
I think we can figure out a way to automatically mirror the
documentation to the wiki so that users have a common location for user
and developer documentation.
> I can commit to setting it up, and help keeping it alive over the
> next few months/years. But of course it is not possible nor
> desirable to do this alone! Help would be required in the following
> areas:
>
> 1) define the general structure of the doc: what should go in, what
> shouldn't, and how to organize the content; 2) initial effort:
> importing/refreshing relevant bits from the wiki, and writing the
> rest; 3) define some consensual rules on how to keep the doc
> up-to-date with the codebase.
You can count me in on 1) and 2). 3) should be deferred until a
reasonable base line is established. To simplify bootstrapping the
project we can also setup a scratch repo somewhere with direct push
access to documentation contributors.
> Now for the questions:
>
> - does this seem to go in the right direction?
Definitely!
> - would all developers be willing to spend a reasonable amount of
> time and effort to keep this documentation project alive and
> up-to-date over time?
I cannot speak for the others but I am personally interested in working
on the documentation. I also wrote parts of the existing uci references
and generally like working on such things. I cannot promise that I'll
have much time to write lots of text but I can certainly explain things
and help with answering questions.
> - what should be the general structure of this documentation? It
> would have been nice to brainstorm on this at the OpenWrt summit,
> but unfortunately I cannot attend.
It might make sense to set up an etherpad here to gather some structural
ideas.
Cheers,
Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
