Re: OpenWrt One / project update
On 11.04.24 10:15, Ivan Ivanov wrote: SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C Are these Mediateks capable of working without any binary blobs, at least in theory? (i.e. some existent reverse-engineering research) If not, why have they been chosen in particular? IMHO the "OpenWRT One" project hardware should not be worse than LibreCMC one As far as I know, there are no Wifi-5+ chips on the market that can run without blobs. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd size issue
On 05.04.24 05:12, e9hack wrote: Hi, I face a strange issue about the size of hostapd. If I build hostapd-openssl only, the size of the hostapd binary is 1061680 bytes. If I add wpad-openssl as module in addition, the size of hostapd is 798664 bytes only. The dependencies in hostapd's Config.in were wrong. Because of that, leaving out wpad would prevent setting CONFIG_WPA_MSG_MIN_PRIORITY. That increased the bloat by leaving in all debug messages. I've pushed a fix to main. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: xz inadequate for a long term tarball reproducibility? [Was: [openwrt/openwrt] unetd: fix PKG_MIRROR_HASH]
On 03.04.24 15:41, Petr Štetiar wrote: LEDE Commits [2024-04-03 07:29:21]: Hi, thanks a lot for a great commit message, really appreciate it! :-) Just to get a complete picture, I've additional questions, sorry. nbd pushed a commit to openwrt/openwrt.git, branch main: https://git.openwrt.org/2070049c1cafa52224c946a6c334bf9fea4f549b commit 2070049c1cafa52224c946a6c334bf9fea4f549b Author: Paul Spooren AuthorDate: Wed Apr 3 13:04:36 2024 +0200 unetd: fix PKG_MIRROR_HASH Our CI on GitHub as well as my local machine generates a different PKG_MIRROR_HASH from what Felix uploaded the other day. Felix, can you provide more details about the host OS/compiler/version of the xz used for this tarball creation? I didn't use xz from my host to generate this tarball. I simply hadn't built tools/ again in my tree when I made the update, so it was missing the xz downgrade. After receiving Felix file, both have indeed different hashes, however when unpackaged via `xz -d` both have the same tarball content. Paul, can you be more specific which `xz -d` is that? From the OpenWrt tools `staging_dir/host/bin/xz` or from your host? For example: $ staging_dir/host/bin/xz --version xz (XZ Utils) 5.4.6 liblzma 5.4.6 Below the checksums to compare: a62bef497078c7b825f11fc8358c1a43f5db3e6d4b97812044f7653d60747d5b dl/unetd-2024.03.31~80645766.tar.xz fbdac59581742bf208c18995b1d69d9848c93bfce487e57ba780d959e0d62fc4 dl/unetd-2024.03.31~80645766_felix.tar.xz After unpacking: a7189cae90bc600abf3a3bff3620dc17a9143be8c27d27412de6eb66a1cf1b7d dl/unetd-2024.03.31~80645766.tar a7189cae90bc600abf3a3bff3620dc17a9143be8c27d27412de6eb66a1cf1b7d dl/unetd-2024.03.31~80645766_felix.tar The tarball with the wrong hash was accidentally generated without the xz revert to version 5.4.6 interesting, would it be possible to upload `unetd-2024.03.31~80645766_felix.tar.xz` somewhere, so anyone interested could take a look? Jonas pointed out that the tarball can be reproduced by compressing the .tar with -T 0. https://github.com/openwrt/openwrt/pull/15057#issuecomment-2034437153 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Conclusions from CVE-2024-3094 (libxz disaster)
On 31.03.24 01:07, Elliott Mitchell wrote: On Sat, Mar 30, 2024 at 03:30:49PM +, Daniel Golle wrote: unchanged. Git has a lot of security built-in, and by using tarballs as a base for our package builds we are basically throwing all that away, for the sake of saving a negligible amount of resources on the build infrastructure. I sort of agree, sort of disagree with this. Having a cryptographic hash at the center of everything provides security comparable to the security of the hash. Alas, this means replacing that hash is a bit difficult. The design is good, but SHA-1 is no longer appropriately secure. Replacing SHA-1 is a work in progress, but until that completes SHA-1 is still the core of *everything*. I've been monitoring the situation and early work started in 2017, but it still isn't usable yet. Until it is ready there is this rather oversize elephant in the room. https://git-scm.com/docs/hash-function-transition (SHA-1 collisions aren't known to have been used for anything /yet/, but it is only a matter of time; this *really* worries me) Assuming that generating SHA1 collisions become much easier to create, what attack scenarios are you worried about? On Sat, Mar 30, 2024 at 03:30:49PM +, Daniel Golle wrote: However, after reading up about the details of this backdoored release tarball, I believe that the current tendency to use tarballs rather than (reproducible!) git checkouts is also problematic to begin with. Stuff like 'make dist' seems like a weird relic nowadays, creates more problems than it could potentially solve, bandwidth is ubiquitous, and we already got our own tarball mirror of git checkouts done by the buildbots (see PKG_MIRROR_HASH). So why not **always** use that instead of potentially shady and hard to verify tarballs? I think Daniel's proposal is a very good idea. It reduces points of failure while adding very little cost in terms of dev/maintainer resources. I don't think the issue is so much that tarballs are archiac, but that *everyone* is using Git now. One proposed patch from a pull: https://github.com/openwrt/openwrt/pull/14280/commits/1b29aadbbf07cb77498a0eb92fe7c171c65dab2e I don't see a single reference to a version control system besides Git anywhere in OpenWRT at this point. Tarballs were a reasonable choice when there were >4 source code handling systems in use, yet now Git is also a common point. So if everything is in Git, how does handling tarballs help builds? Several ways: - significantly faster download compared to git clone - relying less on SHA1, since we use SHA256 for the tarballs - proper mirror support for more reliable builds - makes it easier to create a tarball of a specific OpenWrt version which does not need to download any extra files Also, if SHA1-collision based repository manipulation ever becomes practical, failure to deterministically reproduce our tarballs can make it more visible. Always using git checkouts instead of tarballs would also makes it much easier for maintainers to at least have a quick look at the changes made in an upstream project between versions (a quick scroll over 'git diff oldtag..newtag' or even just 'git log --stat oldtag..newtag' doesn't take much more time than manually validating a release tarball GPG signature in most cases, if there even is any...). I see several issues with your argument, but I mostly agree with your conclusion. Git is *everywhere*, so why use tarballs? I disagree with your approach though. Git already has two tools for handling this situation and I think one of them should be chosen. The first is `git submodule`. My understanding it is pretty similar to OpenWRT's current approach. Difference is this lets `git` handle downloading other repositories instead of doing it in a Makefile. Since Git is already designed to handle this sort of task, I suspect this will be rather more reliable than the existing system. Second is `git subtree`. This is a tool for including other projects into a repository. The end result is the other project's history becomes merged into local history. One advantage is you download everything all at *once*, rather than individually grabbing tools. Other is their full history will make upgrades easier since differences will be more obvious. These will need major changes to the build system. Here are several downsides to this approach: - significantly slower downloads - no download mirror support - if somebody uses submodules in a downstream fork, they can't easily rely on git submodule update anymore without having to pull in tons of potentially unused stuff What are the benefits we would be getting from all this rework churn? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
On 26.03.24 14:39, Paul D wrote: We have quorum/consensus on this issue. Is it too much to ask that everyone now follow it, or at least have this token 'vote'? Where did you see the quorum/consensus? I looked at the links and couldn't find it. Triggered by the yggdrasil additions of recent. https://github.com/openwrt/packages/pull/23072 Paul S amended the policy (in packages[1] and openwrt[2] repos) with an open discussion in PRs for Felix to then change direction via: https://github.com/openwrt/actions-shared-workflows/commit/12d9551f2d07ec34ac813da8612c8014fb393af6 with comment: "should require a public discussion/vote" I reverted the change because: a) It's a policy change and not a code change. Policy changes require a vote. b) Just because the kernel changed their interpretation of DCO requirements doesn't mean this automatically applies to OpenWrt contribution policy. c) It's completely unclear what the new intended requirements are. So far it has been our policy that contributions need to be signed off with the real name of the submitter. If we want to change this in order to allow contributions without a real name attached, we need to clarify what's acceptable and what isn't. The Kernel's "clarification" regarding this topic is *very* vague in my opinion. What does "known identity" even mean? Known to whom, and to what degree? If somebody contributes with his GitHub handle, does that already count as known? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
On 26.02.24 11:45, Tanjeff Moos wrote: Hi all, Qualcomm has bugs in the closed-source firmware for their WLAN and LTE hardware. The Qualcomm bulletin[1] says "Patches are being actively shared with OEMs". Were these bugfixes made available for OpenWRT? Is there an established procedure for such cases, where closed-source firmware gets bugfixes? Kind regards, Tanjeff [1] https://docs.qualcomm.com/product/publicresources/securitybulletin/december-2023-bulletin.html The fixes were not shared with OpenWrt. Qualcomm does not care about OpenWrt support for their platforms. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] New member proposal: Robimarko (Robert Marko)
On 30.01.24 19:15, Christian Marangi (Ansuel) wrote: Robert is active in OpenWrt since 2017 and with some recent stats, he has more than 310 commits merged in OpenWrt. He also have uncounted Reviewed-by tag on various PR and merged commits and generally helps in everything related to IPQ (ipq806x, ipq40xx and ipq807x) and some mvebu targets. He did the conversion of ipq40xx target to DSA and made possible the introduction of the ipq807x target by sorting all the QSDK downstream patch and pushing them upstream. With his help, also the ipq60xx is very close on getting merged and actually used permitting support of even more device for OpenWrt. Also he is almost always reachable on IRC openwrt-devel and never had a problem in coordinating and collaborating with him. I think Robert is a good addition to our team and would massively help me (Ansuel) in maintaining each IPQ target and review all the related PR on github and patchwork. I would like to add Robert to the OpenWrt committers team. The vote shall be concluded within 14 days. (13/02/2024) +1 Thanks for bringing this up. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek/rtl838x: regression in f909059b74 caused by procd segfault in libubox
On 26.01.24 20:15, Dustin Howett wrote: I am seeing this on x86/64-glibc as well. It looks like procd is falling over in udebug_entry_vprintf at the *second* vprintf after udebug_buf_alloc. This appears to occur when there are log messages longer than the minimum allocation size (128) and we trip into the second allocation pass. Thanks for reporting this. I was able to reproduce the issue on x86/64-glibc myself and made a libubox fix for it. Please try the latest version. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Future of the broadcom-wl package?
Hi, does anybody still care about the broadcom-wl package in OpenWrt? I think it would be nice if we could get rid of it, along with the code support and abstraction for different wireless drivers. It would also allow us to rewrite iwinfo in ucode with nl80211 as the only supported API, which helps keep things simple. Would anybody be opposed to declaring 23.05 to be the last release to support broadcom-wl? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Radios for LibreRouter 2
Hi, On 23.01.24 10:54, G10h4ck wrote: Hi all! At Altermundi we have been (mostly silently) advancing with LibreRouter 2 project, we have now some prototype at hand and started testing also radios, we need that the radio works good with OpenWrt and that at least have good 802.11s support in the meanwhile we develop the "promiscuous-AP" mode for hostapd, of which I have presented some preliminary work at last wireless community weekend. Nice! So far we started testing: - MediaTek 7921k - Wallys DR 7915 We don'e have conclusive results yet but we needed M.2 adapters for the first model which we would prefer to avoid, and both seems to produce too much heat to fit two of those into a router enclosure I stress again on the fact that we need them to work good on OpenWrt, the usage is mostly for medium to long range outdoor links, preferably cheap. You're not going to get decent mesh/AP mode support out of MT7921, since that chipset is primarily made for mobile devices. Please stick with MT7915 (or MT7916 if you can get it). - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd crash
On 13.01.24 16:58, e9hack wrote: Am 13.01.2024 um 16:47 schrieb Felix Fietkau: On 13.01.24 16:32, e9hack wrote: Thanks, this does fix the exception. Now I see the reale error: Sat Jan 13 15:52:30 2024 daemon.err hostapd: Could not set interface phy1-ap8 flags (UP): Resource busy Sat Jan 13 15:52:31 2024 daemon.err hostapd: Failed to add BSS (BSSID=xx:xx:xx:xx:xx:xx) Sat Jan 13 15:52:31 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap7 from bridge br-aaa: No such device Sat Jan 13 15:52:32 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap6 from bridge br-aaa: No such device Sat Jan 13 15:52:32 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap5 from bridge br-bbb: No such device Sat Jan 13 15:52:32 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap4 from bridge br-ccc: No such device Sat Jan 13 15:52:33 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap3 from bridge br-ddd: No such device Sat Jan 13 15:52:33 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap2 from bridge br-eee: No such device Sat Jan 13 15:52:34 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap1 from bridge br-aaa: No such device Sat Jan 13 15:52:34 2024 daemon.err hostapd: Interface initialization failed Is there a limition of AP's per device? Yes. The limit is hardware/driver specific. What chipset are you using? It is a TP-LINK Archer C7. 2.4G wifi is ath9k. I didn't see this issue with an Asus RT-AX53U based on mt7621. ath9k can do 8 AP interfaces, mt7915 can do 16. That explains why you didn't see the issue on RT-AX53U. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd crash
On 13.01.24 16:32, e9hack wrote: Thanks, this does fix the exception. Now I see the reale error: Sat Jan 13 15:52:30 2024 daemon.err hostapd: Could not set interface phy1-ap8 flags (UP): Resource busy Sat Jan 13 15:52:31 2024 daemon.err hostapd: Failed to add BSS (BSSID=xx:xx:xx:xx:xx:xx) Sat Jan 13 15:52:31 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap7 from bridge br-aaa: No such device Sat Jan 13 15:52:32 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap6 from bridge br-aaa: No such device Sat Jan 13 15:52:32 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap5 from bridge br-bbb: No such device Sat Jan 13 15:52:32 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap4 from bridge br-ccc: No such device Sat Jan 13 15:52:33 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap3 from bridge br-ddd: No such device Sat Jan 13 15:52:33 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap2 from bridge br-eee: No such device Sat Jan 13 15:52:34 2024 daemon.notice hostapd: nl80211: Failed to remove interface phy1-ap1 from bridge br-aaa: No such device Sat Jan 13 15:52:34 2024 daemon.err hostapd: Interface initialization failed Is there a limition of AP's per device? Yes. The limit is hardware/driver specific. What chipset are you using? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd crash
Hi,
On 13.01.24 11:28, e9hack wrote:
Hi,
I did add one more AP to my wifi config for testing. This results in hostapd
not starting for this device:
Thu Jan 11 13:59:12 2024 daemon.notice hostapd: Exception in ubus function:
left-hand side expression is null In __iface_pending_next(), file
/usr/share/hostap/hostapd.uc, line 165, byte 73: called from function
iface_pending_next (/usr/share/hostap/hostapd.uc:181:73) called from function
iface_pending_init (/usr/share/hostap/hostapd.uc:222:15) called from function
iface_restart (/usr/share/hostap/hostapd.uc:249:35) called from function
iface_set_config (/usr/share/hostap/hostapd.uc:620:52) called from function
[anonymous function] (/usr/share/hostap/hostapd.uc:827:32) called from
anonymous function (/usr/share/hostap/hostapd.uc:710:22) `
hostapd.printf(`hostapd.add_iface failed for phy ${phy}
ifname=${bss.ifname}`);` Near here
---^
Thu Jan 11 13:59:12 2024 daemon.notice netifd: radio1 (405): Command failed: ubus call hostapd config_set { "phy":
"phy1", "config":"/var/run/hostapd-phy1.conf", "prev_config":
"/var/run/hostapd-phy1.conf.prev"} (Unknown error)
The error doesn't appear when I remove a AP. It doesn't matter which one I
remove.
Is there somewhere a buffer to small?
Please try the latest version, it should work now. Sorry for the noise.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: libubox compile issue
On 28.11.23 17:00, e9hack wrote: Hi, since commit 'libubox: update to Git HEAD (2023-11-27)', I've trouble to compile libubox: [43/46] Building C object CMakeFiles/jshn.dir/jshn.c.o [44/46] Linking C executable jshn FAILED: jshn : && /data/src/LEDE/RT-AX53U-5.15.x/staging_dir/host/bin/gcc -O2 -I/data/src/LEDE/RT-AX53U-5.15.x/staging_dir/host/include -I/data/src/LEDE/RT-AX53U-5.15.x/staging_dir/hostpkg/include -I/data/src/LEDE/RT-AX53U-5.15.x/staging_dir/target-mipsel_1004kc_musl/host/include -DNDEBUG -L/data/src/LEDE/RT-AX53U-5.15.x/staging_dir/host/lib -L/data/src/LEDE/RT-AX53U-5.15.x/staging_dir/hostpkg/lib -L/data/src/LEDE/RT-AX53U-5.15.x/staging_dir/target-mipsel_1004kc_musl/host/lib -rdynamic CMakeFiles/jshn.dir/jshn.c.o -o jshn -Wl,-rpath,/data/src/LEDE/RT-AX53U-5.15.x/build_dir/hostpkg/libubox-2023-11-27-d4c3066e: libblobmsg_json.so -Wl,-Bstatic -ljson-c -Wl,-Bdynamic libubox.so && : /usr/bin/ld: libubox.so: undefined reference to `shm_unlink' /usr/bin/ld: libubox.so: undefined reference to `shm_open' collect2: error: ld returned 1 exit status [45/46] Building C object CMakeFiles/json_script.dir/json_script.c.o ninja: build stopped: subcommand failed. make[2]: *** [Makefile:117: /data/src/LEDE/RT-AX53U-5.15.x/build_dir/hostpkg/libubox-2023-11-27-d4c3066e/.built] Error 1 make[2]: Leaving directory '/data/src/LEDE/RT-AX53U-5.15.x/package/libs/libubox' Fixed now. Thanks for reporting and sorry for the noise. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On 25.11.23 03:28, Elliott Mitchell wrote: On Fri, Nov 24, 2023 at 01:53:01PM +0100, Jonas Gorski wrote: > > I'm fine with the cp -l change, but I think adding all remaining modules > > to the rootfs is not something we should do by default (maybe opt-in?) > > Perhaps. This could also be handled by the approach the series as a > whole is aiming for. If kernel module building used a separate object > directory from the kernel build, then modules selected in the device > configuration could be isolated. Maybe instead of putting them into the rootfs, we could wrap them in a special package? Then you can select it if you want to include them in your image or not. No idea what to name it, kmod-remaining? kmod-unaccounted-for? kmod-not-appearing-in-the-definitions? We could also try to wrap any unexpected .kos into autogenerated kmod packages based in their names (e.g. if we find a foo.ko, we autogenerate a kmod-foo.ipk for it), but these wouldn't be selectable then in menuconfig. Also not sure how well the build system would handle dynamic package generation. Also going the other way around, maybe the build system should warn/complain about any .ko found that isn't wrapped in a kmod-* package. All of these are plausible. I think modules selected in device configurations should get built and installed into the root filesystem. Otherwise setting a device kernel configuration option to =m is broken. Whereas forcing the explicit creation of packages for each and every kernel module forces duplication of Kconfig functionality. The duplication you wish to avoid is there for a reason. The way the kernel build system is set up, it makes it easy to build a highly customized build for one target, or make a distribution build with pretty much everything built as module. What it offers no solution for is to maintain and keep in sync kernel configurations for a wide array of different (often storage constrained) targets, while keeping a lot of extra features/drivers optionally installable. That's exactly what our packaging around kernel modules + our kernel config handling scripts were made for. Since there is no perfect solution, there are always some trade-offs involved. One of these trade-offs was our choice to not support adding kernel modules in the device kernel config by selecting them as =m there. I didn't consider that feature useful enough to justify the cost of dealing with all the corner cases. I still don't fully understand your motivation for adding this feature. Is it just because you're bothered by having to write some extra boilerplate code for adding kernel modules? Are there some cases where the existing system cannot work for what you're trying to do? Or is there some other reason why you need this? Just to be clear, I'm not opposed to the feature you're proposing in any way. What I want to avoid is adding something that works for your special case but quickly breaks in weird ways when other people start using it. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On 17.11.23 22:31, Elliott Mitchell wrote: On Fri, Nov 17, 2023 at 05:20:33PM +0100, Felix Fietkau wrote: On 11.11.23 01:21, Elliott Mitchell wrote: > This removes the requirement for to create a package for all modules. > Now devices can simply specify in-tree drivers/other to be built as > modules and they will be present in the resultant image. > > Signed-off-by: Elliott Mitchell It seems to me that this completely ignores the use case of having release builds that ship a lot of kernel modules as installable packages. Did I misread something? If not, this gets a strong NACK from me. Should be completely orthogonal, though it could have bugs. Using `cp -l` has two valuable effects: First, it reduces storage space usage. Second, it serves to mark module files as belonging to a package. My goal is previously setting a kernel option to "m" in a configuration file, but not having a package causes it to be built, then ignored. I want this to do something sensible, not simply waste electricity building a module and then tossing it in the garbage. Hmm, come to think of it, that should be $(XARGS) (fix on commit?). Thanks for the explanation, it makes more sense to me now. That said, I see a few pitfalls here: 1. If you select kernel modules that depend on other modules selected via kmod packages, you end up with non-functional modules with missing dependencies in the rootfs. 2. If the kmod package selection accidentally ends up selecting extra modules that aren't stored in the package, you end up with rootfs bloat. I'm fine with the cp -l change, but I think adding all remaining modules to the rootfs is not something we should do by default (maybe opt-in?) By the way, I still get bounces when replying to you, because your mail server is refusing my mail. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 07/20] kernel: copy all built kernel modules to root filesystem image
On 11.11.23 01:21, Elliott Mitchell wrote: This removes the requirement for to create a package for all modules. Now devices can simply specify in-tree drivers/other to be built as modules and they will be present in the resultant image. Signed-off-by: Elliott Mitchell It seems to me that this completely ignores the use case of having release builds that ship a lot of kernel modules as installable packages. Did I misread something? If not, this gets a strong NACK from me. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
On 10.11.23 15:21, e9hack wrote: Too fast. I did reboot with the old version again. The patched version does work. Fix pushed, thanks for testing! - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
On 10.11.23 13:59, Felix Fietkau wrote: On 09.11.23 22:31, Hannu Nyman wrote: e9hack kirjoitti 9.11.2023 klo 17.32: I face a strange behaviour since commit 516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition on bringing up wireless devices). After a reboot or a full restart of hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only the first of 3 5G AP's is join to the configured bridge. The two faulty AP's are up and connecting is possible, but there is no real network connection. If I change one parameter of the faulty AP's in the config file and do a 'wifi reload', than the 2 AP's are join to the bridges. ... If I change the sequence of the 5G AP's in the config file, the behaviour after reboot doesn't change. Only phy1-ap0 does join to the bridge, either to br-lan or to br-tor. The previous netifd commit 40ed7363caf2b22b6e29ed9d9948189c2bc4c8f3 (device: fix build error on 32 bit systems) doesn't have this issue. I see the same error. Some APs do not initially join the bridge, but after making a small pointless edit to the AP's config in /etc/config/wireless and reloading wifi, the AP then joins the bridge. OpenWrt SNAPSHOT, r24331-168beef1dd - root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 lan2 hn5wpa3 lan3 lan1 root@router4:~# nano /etc/config/wireless root@router4:~# wifi reload root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 hn5wpa2r lan2 hn5wpa3 lan3 lan1 I think I found the cause of this regression while looking at the code again. It seems that the hotplug-added devices are removed too early based on DEV_EVENT_REMOVE events. Please try this fix: https://nbd.name/p/2791d8d4 Sorry, the last patch was incomplete. Here is the correct version: https://nbd.name/p/8a6bc06b Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
On 09.11.23 22:31, Hannu Nyman wrote: e9hack kirjoitti 9.11.2023 klo 17.32: I face a strange behaviour since commit 516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition on bringing up wireless devices). After a reboot or a full restart of hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only the first of 3 5G AP's is join to the configured bridge. The two faulty AP's are up and connecting is possible, but there is no real network connection. If I change one parameter of the faulty AP's in the config file and do a 'wifi reload', than the 2 AP's are join to the bridges. ... If I change the sequence of the 5G AP's in the config file, the behaviour after reboot doesn't change. Only phy1-ap0 does join to the bridge, either to br-lan or to br-tor. The previous netifd commit 40ed7363caf2b22b6e29ed9d9948189c2bc4c8f3 (device: fix build error on 32 bit systems) doesn't have this issue. I see the same error. Some APs do not initially join the bridge, but after making a small pointless edit to the AP's config in /etc/config/wireless and reloading wifi, the AP then joins the bridge. OpenWrt SNAPSHOT, r24331-168beef1dd - root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 lan2 hn5wpa3 lan3 lan1 root@router4:~# nano /etc/config/wireless root@router4:~# wifi reload root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 hn5wpa2r lan2 hn5wpa3 lan3 lan1 I think I found the cause of this regression while looking at the code again. It seems that the hotplug-added devices are removed too early based on DEV_EVENT_REMOVE events. Please try this fix: https://nbd.name/p/2791d8d4 Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: wpa_supplicant and switch to ucode
On 21.09.23 20:00, André Valentin wrote:
Hi!
I just tested the current 23.05rc tree with the new hostapd patches and noticed
that 802.1x on wired interfaces does now work anymore.
Until now it was really easy to use the running wpa_supplicant with that, i
just added a config with:
ubus call wpa_supplicant config_add '{ "driver": "wired", "ctrl": "/var/run/wpa_supplicant", "bridge": "switch1",
"iface": "eth0", "config": "/etc/wpad/eth0.conf" }'
But after the switch, I only get
Command failed: Invalid argument
I took a look at the wpa_supplicant.uc but couldn't find a obvious reason.
Perhaps someone could give me a hint? Of course I would like to add support
again.
Does this help? https://nbd.name/p/8f6b9517
Thanks,
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH/RFT 23.05 4/4] netifd: update to the latest version
077e05f2b129 vlan/vlandev: pass through extra vlan information passed via hotplug 40fad91eb5be wireless: add network_vlan config attribute 1571e18e4a69 bridge: add support for configuring extra tagged vlans on member devices b719f189f243 bridge: make hotplug-added vlans default to tagged edf3aced9f9a bridge: add support for adding vlan ranges via hotplug 493e1589bc8b bridge: fix coverity false positive report 03a619947717 bridge: add support for configuring extra vlans for the bridge itself 4bea6d21a9ab wireless: fix changing reconf/serialize options in configuration 255b4d5c472e wireless: fix handling config reload with reconf=1 1ab992a74b43 wireless: fix another reconf issue e94f7a81a039 bridge: fix config reload on 32 bit systems 8c2758b4fbbb wireless: add support for replacing data blobs at runtime 0ff22a6a68ce wireless: enable dynamic reconfiguration by default 4711f74479e2 netifd: fix disabling radio via config if reconf is being used Signed-off-by: Felix Fietkau (cherry picked from commit 09fd59938b673ca10d4b3c46d32f18164bcdb21a) --- package/network/config/netifd/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/network/config/netifd/Makefile b/package/network/config/netifd/Makefile index 31fd0838a493..ceedded96c91 100644 --- a/package/network/config/netifd/Makefile +++ b/package/network/config/netifd/Makefile @@ -5,9 +5,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/project/netifd.git -PKG_SOURCE_DATE:=2023-06-04 -PKG_SOURCE_VERSION:=ec9dba72124597b7224bbfe75960386dc320f4bd -PKG_MIRROR_HASH:=baee39a3882a2b03fc83a3a6a8963c340fa8d884c7a8c9e80e7d2dddc50e24bd +PKG_SOURCE_DATE:=2023-08-17 +PKG_SOURCE_VERSION:=4711f74479e213ef86f8792b408b117d40148eb2 +PKG_MIRROR_HASH:=91c8aa8e890b0616c1ad1860618951ee73655c4e53cc31999dcbb8d00b8b456d PKG_MAINTAINER:=Felix Fietkau PKG_LICENSE:=GPL-2.0 -- 2.41.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH/RFT 23.05 1/4] ucode: update to the latest version
9986b839595d ci: unbreak failing builds by using fixed gh-actions-openwrt-ci-sdk 77c961e20eda ci: fix broken imx6-generic SDK build 86107a647cb0 ci: cancel concurrent builds ed543d8bf481 ci: update the workflows 11d5f8840002 Merge pull request #151 from ynezz/ynezz/unbreak-ci b934ce815ff2 program: fix memory leak in read_sourceinfo b0baf043e64c Merge pull request #152 from Ansuel/fix-memory-leak 740e2501fdca main: add user specified library search paths before default path 15f1a669e8e2 struct: remove state->len 29edb011caf1 ubus: add support for strings containing null bytes 2b4346bfdc67 vm: clear vm->alloc_refs in uc_gc_common b213bd120d55 Merge pull request #150 from nbd168/misc-improvements 66520ebe27ae vm: immediately release arguments on calls with invalid spreads 07cc72a77e3b README.md: fix debian dependencies d048ea88fe71 compiler: fix memory leak in uc_compiler_compile_import on early exit 7b7e22dcdf02 Merge pull request #155 from luizluca/luizluca-patch-1 d656d150905e types: implement ucv_object_sort() d72eebeb168b lib: support object ordering in `uc_sort()` ed1f0133c870 nl80211: add constants for iftypes 3ffb046c59a6 Merge pull request #156 from nbd168/nl80211-iftypes c7d84aae0969 Merge pull request #153 from jow-/lib-sort-object-support Signed-off-by: Felix Fietkau (cherry picked from commit 9419a50242f81b73bae2b1105c0e370385682ad1) --- package/utils/ucode/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/utils/ucode/Makefile b/package/utils/ucode/Makefile index e768acbae91f..e2fe4c8bad40 100644 --- a/package/utils/ucode/Makefile +++ b/package/utils/ucode/Makefile @@ -12,9 +12,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=https://github.com/jow-/ucode.git -PKG_SOURCE_DATE:=2023-04-03 -PKG_SOURCE_VERSION:=5163867269fc04fa01ec5e9f8df3384c99f2 -PKG_MIRROR_HASH:=e82922ff59d6f899d9434bf79f2e6e4add0b7b0466355755fc83d4b5a0aeebfb +PKG_SOURCE_DATE:=2023-06-06 +PKG_SOURCE_VERSION:=c7d84aae09691a99ae3db427c0b2463732ef84f4 +PKG_MIRROR_HASH:=38826ae70d886d1d7ada3fc6591ac807169aa28107f60f7f2e617520083525fb PKG_MAINTAINER:=Jo-Philipp Wich PKG_LICENSE:=ISC -- 2.41.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH/RFT 23.05 2/4] ubus: update to the latest version
f787c97b3489 libubus: add missing uloop_fd_delete call in ubus_shutdown Signed-off-by: Felix Fietkau (cherry picked from commit fdadfb633f8906478974aefbbc84fee1bf508e2f) --- package/system/ubus/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/system/ubus/Makefile b/package/system/ubus/Makefile index 5a951ac24959..82c4dc601a23 100644 --- a/package/system/ubus/Makefile +++ b/package/system/ubus/Makefile @@ -5,9 +5,9 @@ PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/project/ubus.git -PKG_SOURCE_DATE:=2022-06-15 -PKG_SOURCE_VERSION:=9913aa61de739e3efe067a2d186021c20bcd65e2 -PKG_MIRROR_HASH:=f6702e68d7c60388c11f40ca5ca8e932d0bf423325db5bee2c79404782bbcb52 +PKG_SOURCE_DATE:=2023-06-05 +PKG_SOURCE_VERSION:=f787c97b34894a38b15599886cacbca01271684f +PKG_MIRROR_HASH:=f4e898eb9207f069652f1767835f6aa9f015df2282d51e50ab57a0c3736f36e3 PKG_ABI_VERSION:=$(call abi_version_str,$(PKG_SOURCE_DATE)) CMAKE_INSTALL:=1 -- 2.41.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Hostapd won't build after rebase yesterday
On 11.08.23 17:58, Philip Prindeville wrote: I'm seeing the following breakage in hostapd: ../src/ap/ucode.c: In function 'uc_hostapd_iface_start': ../src/ap/ucode.c:337:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg0_idx'; did you mean 'vht_oper_centr_freq_seg0_idx'? 337 | conf->he_oper_centr_freq_seg0_idx = intval; | ^~~ | vht_oper_centr_freq_seg0_idx ../src/ap/ucode.c:344:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg1_idx'; did you mean 'vht_oper_centr_freq_seg1_idx'? 344 | conf->he_oper_centr_freq_seg1_idx = intval; | ^~~ | vht_oper_centr_freq_seg1_idx ../src/ap/ucode.c:352:23: error: 'struct hostapd_config' has no member named 'he_oper_chwidth'; did you mean 'vht_oper_chwidth'? 352 | conf->he_oper_chwidth = intval; | ^~~ | vht_oper_chwidth After rebasing yesterday. Anyone else seeing something similar? What's odd is that the package version didn't change in the rebasing. Is some code not properly gated by CONFIG_IEEE80211AX #ifdef's? Should already be fixed in 9c2c6d19f35708bb97462bb8902c54d2ec23001d Sorry for the noise, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: trouble with hostapd
On 06.08.23 17:29, e9hack wrote: Am 04.08.2023 um 13:01 schrieb Felix Fietkau: Can you please build hostapd with CONFIG_WPA_MSG_MIN_PRIORITY=0 in the OpenWrt .config, add -d to the hostapd command in /etc/init.d/wpad Afterwards, please show me the relevant log part with the full context of the beacon command, so that I can figure out which parameter might be going out of range. It occurs again after restarting of hostapd: Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: beacon_ies - hexdump(len=12): 7f 0a 04 00 00 00 01 00 01 40 00 40 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: proberesp_ies - hexdump(len=12): 7f 0a 04 00 00 00 01 00 01 40 00 40 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: assocresp_ies - hexdump(len=12): 7f 0a 04 00 00 00 01 00 01 40 00 40 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: he_spr_ctrl=0x3 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * freq=2462 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * eht_enabled=0 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * he_enabled=1 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * vht_enabled=0 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * ht_enabled=1 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * radar_background=0 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * sec_channel_offset=-1 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: * channel_type=2 Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: twt_responder=1 Sun Aug 6 12:46:39 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: Beacon set failed: -34 (Result not representable) Sun Aug 6 12:46:39 2023 daemon.err hostapd: Failed to set beacon parameters Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: Fetch survey data Sun Aug 6 12:46:39 2023 daemon.debug hostapd: nl80211: Freq survey dump event (freq=2462 MHz noise=0 channel_time=71621861 busy_time=7745546 tx_time=2674494 rx_time=4839616 filled=001e) I send a bigger log from the 90 sec before off-list. After trying many different things, I finally figured out that it was related to BSS color collisions, and only when using multiple interfaces on the same PHY. Fixed in latest master. Thanks for reporting this, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: trouble with hostapd
On 03.08.23 20:17, e9hack wrote: Am 03.08.2023 um 18:51 schrieb Felix Fietkau: On 03.08.23 15:34, e9hack wrote: Am 03.08.2023 um 14:35 schrieb Felix Fietkau: thanks for reporting this. Unfortunately I can't reproduce it myself based on your description. Can you please let me know what device you are using, and send me the config that reproduces this issue? I'm using an ASUS RT-AX53U. Hostapd has the radius server compiled in. Fixed in b8be20c7e81de2894df8fa2b361c39bc723e4cb5, thanks. This does fix the issue, thanks! Now I see some errors, which I've never seen before: Thu Aug 3 19:59:19 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:24 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:24 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:25 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:00:35 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:00:36 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:00:47 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:03:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Can you please build hostapd with CONFIG_WPA_MSG_MIN_PRIORITY=0 in the OpenWrt .config, add -d to the hostapd command in /etc/init.d/wpad Afterwards, please show me the relevant log part with the full context of the beacon command, so that I can figure out which parameter might be going out of range. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: trouble with hostapd
On 03.08.23 15:34, e9hack wrote: Am 03.08.2023 um 14:35 schrieb Felix Fietkau: thanks for reporting this. Unfortunately I can't reproduce it myself based on your description. Can you please let me know what device you are using, and send me the config that reproduces this issue? I'm using an ASUS RT-AX53U. Hostapd has the radius server compiled in. Fixed in b8be20c7e81de2894df8fa2b361c39bc723e4cb5, thanks. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: trouble with hostapd
Hi, On 03.08.23 11:17, e9hack wrote: I've trouble with 5GHz since the last changes related to hostapd. After boot or after a sequence 'wifi down; sleep 30; wifi' the 2GHz starts only. The 5GHz doesn't start. It looks like, that ACS isn't started. If I modify a value in the config related to 5GHz and execute 'wifi reload', sometimes 5GHz starts. If I remove ACS and set a fixed channel, 5GHz starts only, if the channel doesn't need DFS because DFS is never finished successful. If I revert mac80211.sh and hostapd.sh back to the older versions, ACS and fixed channel with DFS does work again. thanks for reporting this. Unfortunately I can't reproduce it myself based on your description. Can you please let me know what device you are using, and send me the config that reproduces this issue? Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel-headers: platform/target patches are not applied
Hi Martin, On 27.07.23 13:23, Martin Schiller wrote: When preparing the kernel sources to build the kernel headers, currently only the patches from the generic folder are applied, but not from the actual selected target. This is basically understandable if one assumes that one wants to use a toolchain for different targets with the same architecture. But if a target has a kernel patch which also changes the uapi, then this is not considered in the toolchain/kernel-headers and thus when compiling Userspace applications at the moment. This is currently already the case for the following targets: * ath79 * bcm27xx * bcm63xx * ipq40xx * lantiq * realtek I am currently working on a new target, have now stumbled across this problem and would now like to start a discussion here on how best to solve this now. I am looking forward to your ideas. Packages that depend on target specific UAPI changes can always include kernel.mk in the package Makefile, make themselves non-shared and pull include files from $(LINUX_DIR)/user_headers The default for all other packages should be to not rely on target specific UAPI changes. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [netifd PATCH] bridge: always insert new member if allocated on hotplug add
On 24.06.23 14:34, Christian Marangi wrote:
Fix Coverity Defect 1532481 reporting a Resource leak when
!bm->node.avl.key is false in bridge_hotplug_add.
While this situation is almost impossible, code can be refactored to
mute the defect and make it clear that we insert only when a new member
is allocated.
Fixes: edf3aced9f9a ("bridge: add support for adding vlan ranges via hotplug")
Signed-off-by: Christian Marangi
Applied with some changes to make it clear that this is a false positive
report.
Thanks,
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: always use mac80211 loss detection
On 23.06.23 12:29, David Bauer wrote: Hi Felix, On 6/23/23 08:55, Felix Fietkau wrote: On 18.05.23 11:19, David Bauer wrote: ath10k does not report excessive loss in case of broken block-ack sessions. The loss is communicated to the host-os, but ath10k does not trigger a low-ack events by itself. The mac80211 framework for loss detection however detects this circumstance well in case of ath10k. So use it regardless of ath10k's own loss detection mechanism. Signed-off-by: David Bauer Please make a patch for ath10k instead of turning the flag into a no-op in mac80211. The rationale for removal was in fact to avoid patching ath1xk separately, given these are the only drivers using this flag. I'm aware this is not the nicest approach, do you have any insight if there's a downside to always keeping mac80211 loss detection active? I however still respect the preferation of keeping this limited to specific drivers, I'm just interested if there's a deeper rationale / problem i did not spot :) Just to outline the issue this is trying to avoid - Intel clients started dropping their BA sessions sometimes in late 2020 without notifying the AP. The ath10k firmware keeps retransmitting exclusive to the device at the lowest rate while not indicating a low-ack situation to the host-os, avoiding station kickout. This results in very low throughput for all connected stations (aql enabled) up to DoS of the AP (aql disabled). My rationale is this: changes to the driver dropping that flag can be upstreamed, because your description implies that it fixes a real bug. A mac80211 patch turning the flag into an no-op will be rejected, since it doesn't make any sense to keep the flag around. If it turns out that all ath drivers can't use this flag because of the issue you're describing, we can remove it upstream from mac80211 entirely instead of turning it into a dummy no-op. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: always use mac80211 loss detection
On 18.05.23 11:19, David Bauer wrote: ath10k does not report excessive loss in case of broken block-ack sessions. The loss is communicated to the host-os, but ath10k does not trigger a low-ack events by itself. The mac80211 framework for loss detection however detects this circumstance well in case of ath10k. So use it regardless of ath10k's own loss detection mechanism. Signed-off-by: David Bauer Please make a patch for ath10k instead of turning the flag into a no-op in mac80211. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/9] kernel: change CONFIG_HW_RANDOM default to y
On 29.04.23 08:08, Elliott Mitchell wrote: On Fri, Apr 28, 2023 at 10:29:29AM -0600, Philip Prindeville wrote: Why isn't this migrating upwards into target/linux/generic/config-5.15 and target/linux/generic/config-5.10 in that case? And for the platforms where it was turned off, like target/linux/armvirt/32/config-5.15, why isn't that staying unchanged? I'm guessing you're unaware of a subtlety of how the .config system actually works. Take a second look, some handy examples: > On Apr 22, 2023, at 11:46 AM, Elliott Mitchell wrote: > diff --git a/target/linux/armvirt/32/config-5.10 b/target/linux/armvirt/32/config-5.10 > index 3c6443bcbf..2f7cd03b5f 100644 > --- a/target/linux/armvirt/32/config-5.10 > +++ b/target/linux/armvirt/32/config-5.10 > @@ -47,6 +47,7 @@ CONFIG_EDAC_ATOMIC_SCRUB=y > CONFIG_GENERIC_VDSO_32=y > CONFIG_HARDEN_BRANCH_PREDICTOR=y > CONFIG_HAVE_SMP=y > +CONFIG_HW_RANDOM=n > CONFIG_HZ_FIXED=0 > CONFIG_HZ_PERIODIC=y > CONFIG_MIGHT_HAVE_CACHE_L2X0=y > diff --git a/target/linux/armvirt/32/config-5.15 b/target/linux/armvirt/32/config-5.15 > index bf6e2a5cde..bb2a7a320f 100644 > --- a/target/linux/armvirt/32/config-5.15 > +++ b/target/linux/armvirt/32/config-5.15 > @@ -49,6 +49,7 @@ CONFIG_GENERIC_IRQ_MULTI_HANDLER=y > CONFIG_GENERIC_VDSO_32=y > CONFIG_HARDEN_BRANCH_PREDICTOR=y > CONFIG_HAVE_SMP=y > +CONFIG_HW_RANDOM=n > CONFIG_HZ_FIXED=0 > CONFIG_HZ_PERIODIC=y > CONFIG_MIGHT_HAVE_CACHE_L2X0=y > diff --git a/target/linux/armvirt/64/config-5.10 b/target/linux/armvirt/64/config-5.10 > index 275fe4571d..af46939ad2 100644 > --- a/target/linux/armvirt/64/config-5.10 > +++ b/target/linux/armvirt/64/config-5.10 > @@ -102,7 +102,6 @@ CONFIG_GPIO_GENERIC=y > CONFIG_GPIO_GENERIC_PLATFORM=y > CONFIG_HDMI=y > CONFIG_HOLES_IN_ZONE=y > -CONFIG_HW_RANDOM=y > CONFIG_HW_RANDOM_VIRTIO=y > CONFIG_I2C=y > CONFIG_I2C_ALGOBIT=y > diff --git a/target/linux/armvirt/64/config-5.15 b/target/linux/armvirt/64/config-5.15 > index 19ae3dc0cf..88f2f64cde 100644 > --- a/target/linux/armvirt/64/config-5.15 > +++ b/target/linux/armvirt/64/config-5.15 > @@ -103,7 +103,6 @@ CONFIG_GENERIC_FIND_FIRST_BIT=y > CONFIG_GPIO_GENERIC=y > CONFIG_GPIO_GENERIC_PLATFORM=y > CONFIG_HDMI=y > -CONFIG_HW_RANDOM=y > CONFIG_HW_RANDOM_ARM_SMCCC_TRNG=y > CONFIG_HW_RANDOM_VIRTIO=y > CONFIG_I2C=y > diff --git a/target/linux/ath25/config-5.10 b/target/linux/ath25/config-5.10 > index ef764820e4..41e65c72ad 100644 > diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 > index f6f1fb0278..853c13852d 100644 > --- a/target/linux/generic/config-5.10 > +++ b/target/linux/generic/config-5.10 > @@ -2343,7 +2343,7 @@ CONFIG_HPET_MMAP_DEFAULT=y > # CONFIG_HWSPINLOCK is not set > # CONFIG_HWSPINLOCK_OMAP is not set > CONFIG_HW_PERF_EVENTS=y > -# CONFIG_HW_RANDOM is not set > +CONFIG_HW_RANDOM=y > # CONFIG_HW_RANDOM_AMD is not set > # CONFIG_HW_RANDOM_ATMEL is not set > # CONFIG_HW_RANDOM_BA431 is not set > diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15 > index ac75a480a1..bf38732b31 100644 > --- a/target/linux/generic/config-5.15 > +++ b/target/linux/generic/config-5.15 > @@ -2444,7 +2444,7 @@ CONFIG_HPET_MMAP_DEFAULT=y > # CONFIG_HWSPINLOCK is not set > # CONFIG_HWSPINLOCK_OMAP is not set > CONFIG_HW_PERF_EVENTS=y > -# CONFIG_HW_RANDOM is not set > +CONFIG_HW_RANDOM=y > # CONFIG_HW_RANDOM_AMD is not set > # CONFIG_HW_RANDOM_ARM_SMCCC_TRNG is not set > # CONFIG_HW_RANDOM_ATMEL is not set armvirt/32 previously had it off and it is still off. armvirt/64 previously had it on and it is still on. Most similar systems would treat "# is not set" as undefined or no preference (use the default value). The Linux kernel system treats this as "no" due to the history of the system. Yet it also honors "n" as "no". I tend to prefer "n" as it hints at a value being deliberately chosen, instead of being left unset/undefined. Please use the same syntax as in the rest of the file. Occasionally kconfig.pl will be used to add entries or re-sort the file, and mis-matching the existing style will cause spurious extra changes in that case. Also, please fix your mail server, I get bounces when sending to you. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On 29.04.23 02:50, Elliott Mitchell wrote: On Thu, Apr 27, 2023 at 05:38:18AM +0200, Stefan Lippers-Hollmann wrote: On 2023-04-26, Elliott Mitchell wrote: > On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > > On 2023-04-26, Elliott Mitchell wrote: > > [...] > > > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > > due to the generic configuration. Remove the ISA and ISA DMA support > > > from the top-level configuration. Geode and Legacy though almost > > > certainly still need ISA support. > > > > You might find that while ISA went away as an addon slot quite quickly, > > it still survived rather long for low performance onboard devices (e.g. > > sensors). > > I know, I was unsure of when it 100% disappeared. Do you expect anything > besides "legacy" to be used for this type of system though? [...] Ignoring industrial PCs (where you may still encounter ISA today), you'd have to venture into the pre-LPC days (and AMD, VIA, nVidia might have gone with ISA beyond that) - which might get you into the 2005-2009 time frame (anything with an onboard floppy controller might be worth looking at - and those were still around into the LGA755/ core2 (x86_64) days - in that particular case probably LPC based though). Perhaps have "64" and "old64" (or "early64") then? Seems rather a lot of legacy disappeared between 2005 and 2010. FDC, ISA, PATA and AGP were all common in 2005, yet by 2010 they were non-existant. If you need a build for yourself with a specialized stripped down kernel config, there is an easy (and reasonably maintainable) approach to doing so. First you need to use this: https://openwrt.org/docs/guide-developer/toolchain/env Create an env for your main config. Afterwards, you can run: make kernel_menuconfig CONFIG_TARGET=env Any change you make there will be stored in env/kernel-config, which is an overlay that is applied on top of the target config. You can use it to disable any features you like without having to modify any files in the OpenWrt source directory, and it should continue to work with pretty much any source tree updates. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7622: belkin-rt3200: r22602-42eeb22450: Kernel panic: kernel stack overflow
On 21.04.23 09:11, Petr Štetiar wrote: Hi, I've just noticed, that daily CI runtime testing job on belkin-rt3200 failed[1] due to following: Insufficient stack space to handle exception! ESR: 0x9647 -- DABT (current EL) FAR: 0xffc008c47fe0 Task stack: [0xffc008c48000..0xffc008c4c000] IRQ stack: [0xffc008008000..0xffc00800c000] Overflow stack: [0xff801feb00a0..0xff801feb10a0] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G S5.15.107 #0 Hardware name: Linksys E8450 (DT) pstate: 80c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dequeue_entity+0x0/0x250 lr : dequeue_task_fair+0x98/0x290 sp : ffc008c48030 x29: ffc008c48030 x28: 0001 x27: ff801feb6380 x26: 0001 x25: ff801feb6300 x24: ff868000 x23: 0001 x22: 0009 x21: x20: ff801feb6380 x19: ff868080 x18: 17a740a6 x17: ffc008bae748 x16: ffc008bae6d8 x15: x14: x13: x12: 000f0101 x11: 0449 x10: 0127 x9 : x8 : 0125 x7 : 00116da1 x6 : 00116da1 x5 : 001165a1 x4 : ff801feb6e00 x3 : x2 : 0009 x1 : ff868080 x0 : ff801feb6380 Kernel panic - not syncing: kernel stack overflow SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 0-1 Kernel Offset: disabled CPU features: 0x3000,0802 Memory Limit: none Last working version was r22580-e11d00d44c[2], and first failing version was yesterday 1416b9bbe9, so possibly the regression was introduced in one of the following commits: 1416b9bbe9d3 tools/dwarves: update to 1.25 9931188edcbc kernel: fix up qrtr packaging after 5.15.107 bump f4989239cc91 kernel: bump 5.15 to 5.15.107 89f6ac5fd1ad tools/cmake: update to 3.26.3 ab3f151aa874 mwlwifi: update to version 10.3.9.0-20230311 5ec781c4448b bmips: pci-bcm6348: load IO resource from DT ranges 16b0cbbde057 bmips: drop unneeded ath9k fixup db4f158c0330 bmips: hg556a: switch to kmod-owl-loader 36150ff6ffb2 tools/bzip2: add `bzip2` binaries b691362d1dbe Revert "tools/bzip2: add `bzip2` binaries" f7f47b136991 mac80211: ath11k: replace 160MHz fix with upstream pending one 4ab4b9ea818d build: fix incorrect initramfs gzip compression 69bc620180d2 build: fix incorrect initramfs bzip2 compression 394d7134ec42 tools/bzip2: add `bzip2` binaries 5264296ce480 ath79: mikrotik: update kernel on NAND using Yafut 27acf2413e91 yafut: add a kernel update tool for MikroTik NAND fa4dc86e9808 kernel: backport MEMREAD ioctl e722b667c5a5 mac80211: update to v6.1.24 Since the crash happens right after snand driver initialization, I think the most likely candidate is this one: fa4dc86e9808 kernel: backport MEMREAD ioctl Maybe there are still some stack declarations of struct mtd_oob_ops left that aren't fully initialized. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.23 18:55, Arınç ÜNAL wrote: On 31.03.2023 19:45, Felix Fietkau wrote: On 31.03.23 18:40, Arınç ÜNAL wrote: I just thought of this. Why don't we just, for example, 'make mt7621_defconfig && make mod2noconfig', then compile normally with kernel module packages. This way, OpenWrt compiles a kernel with the least amount of kernel modules (or rather, it compiles the kernel like it always did), and people compiling the kernel outside of OpenWrt can choose to remove the kernel modules they don't need. Because I believe the current OpenWrt kernel config system ist vastly superior for keeping target kernel configs in sync while at the same time making it easy to keep an overview of target specific overrides as well. This is especially relevant for updating the kernel version. Hmm, well I'll take your word for it but feel free to explain more if you'd like. We do have a lot of config options that we set as default for all targets. With our current system, we keep them in a file in target/linux/generic/config- A target can override any of those with its target specific config overlay. The clever bit of our kernel config system is that this overlay is not handwritten. You can use make kernel_menuconfig or kernel_oldconfig to make changes to it, and it will automatically filter out the defaults from the generic config. When updating to a newer kernel for the first time, you can pick any target, copy the old version and run make kernel_oldconfig. Afterwards you can look through the diff and move any newly added items that should be generic over to the generic config template, so you won't be asked about it for the next target. The expectation is that target configs should share as many options as possible, so it helps that you can simply go through the target config overlays and look at each line to see if it should stay target specific or if it should be moved to the generic config instead. Also, OpenWrt commits that change settings for all targets are much easier to review compared to a set of full configs, because you don't have to manually verify if you properly applied them to all targets. It would definitely be possible to build a workflow around full configs as well to try to achieve something similar, but the problem that I see there is that the relevant information for maintaining would not be as readily available. And it would be easier for configs to accidentally drift apart, causing spurious build issues when dealing with the configurability of our module packages. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.23 18:40, Arınç ÜNAL wrote: I just thought of this. Why don't we just, for example, 'make mt7621_defconfig && make mod2noconfig', then compile normally with kernel module packages. This way, OpenWrt compiles a kernel with the least amount of kernel modules (or rather, it compiles the kernel like it always did), and people compiling the kernel outside of OpenWrt can choose to remove the kernel modules they don't need. Because I believe the current OpenWrt kernel config system ist vastly superior for keeping target kernel configs in sync while at the same time making it easy to keep an overview of target specific overrides as well. This is especially relevant for updating the kernel version. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.23 18:22, Arınç ÜNAL wrote: On 31.03.2023 19:04, Felix Fietkau wrote: On 31.03.23 14:52, Arınç ÜNAL wrote: On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Hmm, what about we enable the bare minimum of kernel options for a target, which is already how it is, then select the rest as kernel modules (like on the makefile of a target for each device) on the defconfig for each device? So, in the end, it wouldn't be any different than selecting a kernel module package from the OpenWrt SDK which, I believe, does not change the symbol offsets in the kernel stack. My reason for pushing for the use defconfigs is that anyone can build the Linux kernel for their device, without needing OpenWrt. So the work for adding support for a device would benefit far more people. There are a lot of options in the OpenWrt menuconfig (including kmod package selections) which *do* affect the kernel compilation in a major way. They can change struct sizes, enabled features, affect compiled-in code inside functions, etc. For maintenance, I strongly believe that switching from the current system to maintaining full kernel config files is a huge step backwards, because maintaining individual config files makes them so much easier to accidentally go out of sync with each other. If you want to make it easier to build per-device kernels outside of OpenWrt, I'd recommend adding a build system feature to export target defconfig files. I agree that it'd be a lot to maintain. A defconfig per (sub)target is much better. It's not so different than what we already have in OpenWrt except that it will be on mainline Linux so even people outside of the OpenWrt environment can benefit from it. I'm starting this off by making a defconfig for the ramips/mt7621 subtarget. Sure, sending such defconfig files to mainline is a good idea, as long as there is no expectation that these will be used by OpenWrt directly in any way. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On 31.03.23 14:52, Arınç ÜNAL wrote: On 31.03.2023 14:33, Daniel Golle wrote: Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: Hi all, These are the ideas I've been thinking about for the future of OpenWrt for a while. It looks complete enough to share it with all of you. I'm willing to put a great deal of effort to get as much out-of-tree patches on mainline Linux as possible. You can make a comment on Notion or discuss it here, I'm wondering if the ideas are feasible and how well it would benefit the people maintaining OpenWrt. https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. Hmm, what about we enable the bare minimum of kernel options for a target, which is already how it is, then select the rest as kernel modules (like on the makefile of a target for each device) on the defconfig for each device? So, in the end, it wouldn't be any different than selecting a kernel module package from the OpenWrt SDK which, I believe, does not change the symbol offsets in the kernel stack. My reason for pushing for the use defconfigs is that anyone can build the Linux kernel for their device, without needing OpenWrt. So the work for adding support for a device would benefit far more people. There are a lot of options in the OpenWrt menuconfig (including kmod package selections) which *do* affect the kernel compilation in a major way. They can change struct sizes, enabled features, affect compiled-in code inside functions, etc. For maintenance, I strongly believe that switching from the current system to maintaining full kernel config files is a huge step backwards, because maintaining individual config files makes them so much easier to accidentally go out of sync with each other. If you want to make it easier to build per-device kernels outside of OpenWrt, I'd recommend adding a build system feature to export target defconfig files. Either submit all out-of-tree patches on OpenWrt to Linux or get rid of them and find a better solution for what the unacceptable patch does. This would of course be great, but especially for legacy devices it may not be possible in many cases. Think of all the devices stuck on swconfig, just to name one example... Think of all the completely broken vendor bootloaders which require hacks (mangeling kernel cmdline and such) and cannot easily be replaced... Those can stay until eventually the support for them will be dropped on newer OpenWrt versions. I believe there are a lot of out-of-tree patches that are not for old devices and can be on mainline Linux. I believe that we will always need to carry some patches even for newer platforms which will never be accepted upstream, and probably have no place there. One example is the NMBM NAND mapping code on MTK platforms. It was written by MTK long after UBI had already established itself as a much better solution. And yet, we still have to deal with it because we don't want to make it a hard requirement to reflash U-Boot on every single newer NAND based MTK device. We also need to carry some hacks to Kconfig files to support our kmod selection and our out-of-tree mac80211/cfg80211 builds. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [libnl-tiny PATCH] attr: add NLA_S8
On 30.03.23 11:47, Nick wrote:
On 3/30/23 11:43, Nick wrote:
On 3/19/23 20:25, Hauke Mehrtens wrote:
On 3/15/23 14:37, Nick Hainke wrote:
NLA_S8 is used by newer hostapd versions.
Signed-off-by: Nick Hainke
---
attr.c | 1 +
include/netlink/attr.h | 35 +++
2 files changed, 36 insertions(+)
diff --git a/attr.c b/attr.c
index eae91e5..abde67f 100644
--- a/attr.c
+++ b/attr.c
@@ -437,6 +437,7 @@ static uint16_t nla_attr_minlen[NLA_TYPE_MAX+1] = {
[NLA_U32] = sizeof(uint32_t),
[NLA_U64] = sizeof(uint64_t),
[NLA_STRING] = 1,
+ [NLA_S8] = sizeof(int8_t),
};
static int validate_nla(struct nlattr *nla, int maxtype,
diff --git a/include/netlink/attr.h b/include/netlink/attr.h
index 3e3047f..3a5d53d 100644
--- a/include/netlink/attr.h
+++ b/include/netlink/attr.h
@@ -45,6 +45,7 @@ enum {
NLA_FLAG, /**< Flag */
NLA_MSECS, /**< Micro seconds (64bit) */
NLA_NESTED, /**< Nested attributes */
+ NLA_S8,
__NLA_TYPE_MAX,
};
I think this has to match the kernel definitions of the same enum.
https://elixir.bootlin.com/linux/v6.1.20/source/include/net/netlink.h#L178
So I have to add all enum types?
libnl is also not having all types:
https://github.com/thom311/libnl/blob/main/include/netlink/attr.h#L33-L51
You can leave out entries at the end you don't need, but the values must
match. So please add everything in between until you reach NLA_S8.
While you're at it, it might be a good idea to add at least the other
NLA_S* types as well.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] netifd: exclude 20-smp-packet-steering on bcm53xx
On 02.02.23 17:06, Rafał Miłecki wrote:
From: Rafał Miłecki
bcm53xx comes with custom (more optimized) packet steering. A race
between two scripts was resulting in varying network performance.
Ref: fcbd39689ebf ("bcm53xx: enable & setup packet steering")
Signed-off-by: Rafał Miłecki
---
Is this an acceptable method to handle this?
netifd can be shared between multiple targets, so such target specific
checks can break stuff. I also have some doubts about the bcm53xx
specific script - some parts look a bit weird to me. Maybe we can find a
generic way that works for bcm53xx and other targets.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. Thanks. I don't have a strong opinion one way or the other, but I think the code might be more readable without the explicit $(STAGING_DIR_HOST)/bin prefix. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
On 20.01.23 09:36, Florian Eckert wrote: During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: backport mac80211
On 12.12.22 15:24, e9hack wrote: Hi, backports-6.1-rc8 build fails for ath9k due to a missing dependency: Fixed, thanks. I added the dependency to kmod-ath9k-common instead, since that's the module that actually depends on kmod-random-core. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] dropping of $(AUTORELEASE) feature
Hi, I have another idea that might simplify the mess of dealing with PKG_RELEASE handling. 1. we use AUTORELEASE for all packages in master 2. when creating a release branch, all PKG_RELEASE lines are changed to something like 22.03-1 3. we write a script that can automatically edit a series of local commits and for each commit: - figures out affected packages - edits each affected makefile to bump PKG_RELEASE - adds a Updated-Packages: <...> tag to indicate which packages it has changed (or 'none' if no packages were affected) 4. we ask people submitting patches via email or PR to not update PKG_RELEASE themselves anymore 5. we make the server side enforce the presence of the "Updated-Packages" tag for release branches and packages, just like Signed-off-by. That way, dealing with PKG_RELEASE becomes a matter of simply running one command before doing git push. What do you think? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bridge-vlan bug? (mt7621/DSA)
On 09.08.22 15:13, Thibaut wrote: Le 6 août 2022 à 11:58, Thibaut a écrit : Le 6 août 2022 à 00:50, Mark Mentovai a écrit : Thibaut wrote: I’m experiencing a strange bug on Yuncore AX820 (mt7621/mt7905/mt7975, DSA-enabled) when using a bridge-vlan setup. This bug affects at least OpenWRT 22.03.0-rc6. I’m not sure whether this bug is related to this particular SoC or only to DSA as I was unable to test with another DSA-enabled device (I don’t have any). However this bug does not affect e.g. QCA non-DSA devices. I’m running out of ideas on how to further debug this problem, so feel free to guide me if more information is needed. Please CC-me in replies. This sounds very similar to the problem I experienced with the work-in-progress DSA patches for ipq40xx: https://github.com/openwrt/openwrt/pull/4721#issuecomment-971162067 This kernel patch explains the situation fairly well: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5f19486cee79d04c054427577ac96ed123706db But the fix isn’t operative unless the switch driver opts in via assisted_learning_on_cpu_port. There were also comments from around that time that there may still be trouble with untagged traffic. There’s a bit of discussion about this issue in the comments around there on the pull request. Hopefully you’ll find it helpful. It should at least get you oriented in the right direction, even if it’s not a fix for your untagged use case. Thanks a lot for these details. Based on your input and looking at our current 5.10 source and the current upstream, it seems this might have already been fixed upstream: https://github.com/torvalds/linux/commit/0b69c54c74bcb60e834013ccaf596caf05156a8e I’ll check if this can be backported without too much fuss. Backport submitted: http://patchwork.ozlabs.org/project/openwrt/patch/20220809125947.31775-1-ha...@slashdirt.org/ It fixes the issue and applies cleanly to 22.03: I have run tests in both master and 22.03. I will now check if I can make it work in 21.02 which is also affected. Please take a look at https://git.openwrt.org/3e0daca6447c3d5b9eb6d24ecb8e52f256f385cc The changes were backported once already and reverted due to issues. See also: https://github.com/openwrt/openwrt/issues/9420 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH netifd] interface: support "zone" config option
On 27.07.22 07:34, Rafał Miłecki wrote: From: Rafał Miłecki Many protocol handlers support "zone" option independently and they pass it in the "data". Then it's read e.g. by a firewall[34]. Add support for "zone" directly to the netifd so: 1. It works for all protocols 2. Handlers don't have to duplicate code Signed-off-by: Rafał Miłecki Good idea! I think once this is merged, we should also change the default network/firewall config to make use of this and reference zones from interfaces instead of the other way around. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: Add new target platform
Hi Daniel, On 26.07.22 08:46, Daniel Danzberger wrote: Airoha is a new ARM platform based on Cortex A7 which has recently been merged into linux-next. This support is based mostly on those linux-next commits backported for kernel 5.15. Patches: 1 - platform support = linux-next 2 - clock driver = linux-next 3 - gpio driver = linux-next 4 - linux,usable-memory-range dts support = linux-next 5 - mtd spinand driver 6 - spi driver 7 - pci driver (kconfig only, uses mediatek PCI) = linux-next Still missing: - Ethernet driver - Sysupgrade support A.t.m there exists one subtarget EN7523 with only one evaluation board. The initramfs can be run with the following commands from u-boot: - u-boot> setenv bootfile \ openwrt-airoha-en7523-airoha_en7523-evb-initramfs-kernel.bin u-boot> tftpboot u-boot> bootm 0x8180 - Signed-off-by: Daniel Danzberger On a first glance, the target looks mostly fine to me. I have some minor requests: - please drop the use of a subtarget for now, we can always add it back when we want to add a second one later. - on the same note, please fold image/en7523.mk into image/Makefile - please add source-only to FEATURES in the target makefile - i don't think we should run this target through buildbot just yet. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Optimizing kernel compilation / alignments for network performance
On 05.05.22 18:04, Andrew Lunn wrote: you'll see that most used functions are: v7_dma_inv_range __irqentry_text_end l2c210_inv_range v7_dma_clean_range bcma_host_soc_read32 __netif_receive_skb_core arch_cpu_idle l2c210_clean_range fib_table_lookup There is a lot of cache management functions here. Might sound odd, but have you tried disabling SMP? These cache functions need to operate across all CPUs, and the communication between CPUs can slow them down. If there is only one CPU, these cache functions get simpler and faster. It just depends on your workload. If you have 1 CPU loaded to 100% and the other 3 idle, you might see an improvement. If you actually need more than one CPU, it will probably be worse. I've also found that some Ethernet drivers invalidate or flush too much. If you are sending a 64 byte TCP ACK, all you need to flush is 64 bytes, not the full 1500 MTU. If you receive a TCP ACK, and then recycle the buffer, all you need to invalidate is the size of the ACK, so long as you can guarantee nothing has touched the memory above it. But you need to be careful when implementing tricks like this, or you can get subtle corruption bugs when you get it wrong. I just took a quick look at the driver. It allocates and maps rx buffers that can cover a packet size of BGMAC_RX_MAX_FRAME_SIZE = 9724. This seems rather excessive, especially since most people are going to use a MTU of 1500. My proposal would be to add support for making rx buffer size dependent on MTU, reallocating the ring on MTU changes. This should significantly reduce the time spent on flushing caches. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH/RFC] kernel-defaults.mk: get rid of BuildID
On 05.04.22 20:51, Daniel Golle wrote: On Tue, Apr 05, 2022 at 05:05:43PM +0200, Felix Fietkau wrote: On 05.04.22 03:14, Daniel Golle wrote: > When building the Linux kernel, the linker generates a hash of all > versions of tools involved in a build called BuildID in ELF header. > This breaks reproducibility accross different buildhosts eventhough > OpenWrt builds the toolchain from source -- the build-id hash ends up > to be the only thing which differs in the resulting builds. > > The cause is most likely a result of the build hosts' architectures, > OSs and standard C libraries being different. > > While in theory it is true that tools may produce a different output > depending on archtecture, OS and libc of the buildhost, in practice > this is (fortunately) hardly ever the case and hence it contradicts > ld(1) which states: > > 'The "md5" and "sha1" styles produces an identifier that is always >the same in an identical output file, but will be unique among all >nonidentical output files.' > > (the kernel is using sha1 style build-id, rebuilding the kernel on a > different buildhost results in everything being identical **except** > for the build-id) > > Hence, to achieve reproducible builds we will either have to resort to > identical containers/VMs for building or get rid of the BuildID hash > alltogether (or use a different build-id style) > > At this point, this seems to be what Debian is doing as well in order > to achieve reproducible kernel builds, see[1]. > > [1]: https://wiki.debian.org/SameKernel#How_this_works > Signed-off-by: Daniel Golle > > diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk > index 1e82f7d739..9c8d5fbe97 100644 > --- a/include/kernel-defaults.mk > +++ b/include/kernel-defaults.mk > @@ -46,6 +46,7 @@ else >if [ -d $(LINUX_DIR)/user_headers ]; then \ >rm -rf $(LINUX_DIR)/user_headers; \ >fi > + $(SED) -i $(LINUX_DIR)/Makefile -e 's/--build-id=.*/--build-id=none/g' I don't like running sed on the linux Makefile, as this interferes with creating patches for it. I think it would be better to simply override KBUILD_LDFLAGS_MODULE on the kernel/module build command line. You probably meant LDFLAGS_vmlinux because from what I understand KBUILD_LDFLAGS_MODULE only applies when building modules but not when linking vmlinux. As ld only cares about the last mentioned --build-id= parameter supplied, we can override it using KBUILD_LDFLAGS (which should apply to both, vmlinux.elf as well as modules). I haven't tried any of that yet though.Right, I overlooked that one. Either way, you likely need to patch the kernel in order to not have to override the full set of linker arguments. I still think explicit patching + variable override is preferable over sed based Makefile patching. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH/RFC] kernel-defaults.mk: get rid of BuildID
On 05.04.22 03:14, Daniel Golle wrote: When building the Linux kernel, the linker generates a hash of all versions of tools involved in a build called BuildID in ELF header. This breaks reproducibility accross different buildhosts eventhough OpenWrt builds the toolchain from source -- the build-id hash ends up to be the only thing which differs in the resulting builds. The cause is most likely a result of the build hosts' architectures, OSs and standard C libraries being different. While in theory it is true that tools may produce a different output depending on archtecture, OS and libc of the buildhost, in practice this is (fortunately) hardly ever the case and hence it contradicts ld(1) which states: 'The "md5" and "sha1" styles produces an identifier that is always the same in an identical output file, but will be unique among all nonidentical output files.' (the kernel is using sha1 style build-id, rebuilding the kernel on a different buildhost results in everything being identical **except** for the build-id) Hence, to achieve reproducible builds we will either have to resort to identical containers/VMs for building or get rid of the BuildID hash alltogether (or use a different build-id style) At this point, this seems to be what Debian is doing as well in order to achieve reproducible kernel builds, see[1]. [1]: https://wiki.debian.org/SameKernel#How_this_works Signed-off-by: Daniel Golle diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 1e82f7d739..9c8d5fbe97 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -46,6 +46,7 @@ else if [ -d $(LINUX_DIR)/user_headers ]; then \ rm -rf $(LINUX_DIR)/user_headers; \ fi + $(SED) -i $(LINUX_DIR)/Makefile -e 's/--build-id=.*/--build-id=none/g' I don't like running sed on the linux Makefile, as this interferes with creating patches for it. I think it would be better to simply override KBUILD_LDFLAGS_MODULE on the kernel/module build command line. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] image: let mksquashfs4 use all processors
On 19.02.22 16:54, Stijn Tintel wrote: Drop the -processors argument from the mksquashfs4 call, so it will use all available processors. This dramatically reduces the time to create squashfs filesystems. The times below are observed when building an image for my main router, the WatchGuard Firebox M300 (qoriq target): Before: real4m45,973s After: real0m23,497s Signed-off-by: Stijn Tintel We need to verify that this doesn't break reproducible builds... - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] kernel: 5.10: recover 88E6060 switches support
On 2021-12-17 10:13, Sergey Ryazanov wrote:
On Fri, Dec 17, 2021 at 11:52 AM Felix Fietkau wrote:
On 2021-12-16 23:29, Sergey Ryazanov wrote:
Support for mvswich driver (Marvell 88E6060 switches) build has been
missed during the initial v5.10 kernel introduction. But it is required
for AR21xx boards, e.g. Fonera 2.0. Return the missed driver building
instructions to fix boards support with the new kernel.
Compile tested only with the ath25 target.
Fixes: b10d604459 ("kernel: add linux 5.10 support")
CC: Felix Fietkau
Signed-off-by: Sergey Ryazanov
There is an upstream DSA driver for 88e6060, I think we should try to
use that one instead.
ath25 target does not utilize DTS. Without it DSA drivers are almost
useless. Almost the single still usable board that is supported by the
ath25 target is Fonera 2.0g, which is based on 88e6060. So we still
need the mvswitch driver for it.
In that case, please remove the driver from the generic kernel
files/patches and move it to ath25 instead.
Thanks,
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] kernel: 5.10: recover 88E6060 switches support
On 2021-12-16 23:29, Sergey Ryazanov wrote:
Support for mvswich driver (Marvell 88E6060 switches) build has been
missed during the initial v5.10 kernel introduction. But it is required
for AR21xx boards, e.g. Fonera 2.0. Return the missed driver building
instructions to fix boards support with the new kernel.
Compile tested only with the ath25 target.
Fixes: b10d604459 ("kernel: add linux 5.10 support")
CC: Felix Fietkau
Signed-off-by: Sergey Ryazanov
There is an upstream DSA driver for 88e6060, I think we should try to
use that one instead.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upstreaming hostapd patches 300-noscan.patch and 360-ctrl_iface_reload.patch
Hi Arnout, On 2021-12-16 18:00, Arnout Vandecappelle wrote: Since I want to use these features outside of OpenWrt, I'd like to upstream the patches 300-noscan.patch and 360-ctrl_iface_reload.patch to hostap. First of all, I'd like confirmation from you that it's OK to redistribute those patches under hostap's BSD-3-Clause license rather than OpenWrt's GPL-2.0. But also, it would help if you remember if there have been any previous upstreaming attempts. I can of course search for such discussions, but I don't want to waste time on a wild goose chase. I'm fine with upstreaming and redistributing those changes under BSD-3-Clause. I'm not aware of any previous upstreaming attempts. Thanks for working on this! - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mediatek: bmt: use generic mtd api
On 2021-12-04 15:24, Chuanhong Guo wrote:
BMT replaces nand-specific ops for erasing and writing, but the
mtk-snand driver only implements generic mtd api.
Replace erase, block_isbad, block_markbad in mtd_info for generic mtd
drivers.
Fixes: b600aee3ed ("mediatek: attach bmt to the new snand driver")
Signed-off-by: Chuanhong Guo
Tested on mt7622-rfb1 and pushed to master.
Thanks,
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: zram-swap: default to lzo instead of lzo-rle compression
On 2021-12-01 00:27, Sven Roederer wrote: Am Montag, 29. November 2021, 10:57:37 CET schrieb Rui Salvaterra: Hi, Sven, On Sun, 28 Nov 2021 at 01:40, Sven Roederer wrote: > Rui, not sure if to call it a bug. At the end there is a hardcoded default > algo in the module, that is used initially when creating the device. The > check for the valid algo is done later at device-activation. > I spend some time in this code and have a patch ready, which checks for > algos before announcing them. It's not a bug, but it's also not exactly an unsurprising behaviour. This is the real issue: https://elixir.bootlin.com/linux/v5.10.82/source/crypto/Makefile#L153 obj-$(CONFIG_CRYPTO_LZO) += lzo.o lzo-rle.o Even though they're built as separate modules, they depend on a single kconfig symbol. Moreover, lzo-rle uses most of the original lzo functions (adding just RLE on top), so they should arguably just be merged. I don't know how receptive upstream is to that idea, but it seems logical to me. Rui, during my work I also had the impression, that both files probably share a lot of common code. Based on your comment I had a closer look ... Back in 2019 (v5.1) the linux guys explicitly split the code into separate files to avoid potential data-corrution. https://github.com/torvalds/linux/commit/45ec975efb527625629d123f305 So I don't expect joining the code again will be accepted upstream. Back to the initial issue, I just send my patch of the selection-algorithm to the list for tests and comments. When it's proven to work, I'm fine with trying to push upstream. Maybe upstream would accept a simple makefile change that merges both into a single module without changing any of the source files. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] treewide: drop librt and libpthread packages
On 2021-11-18 12:58, Jo-Philipp Wich wrote: Since OpenWrt's main libc library, musl, does not provide separate shared object files for libpthread and librt, the existing binary packages for them are empty placeholders which provide no runtime functionality and frequently cause confusion among users who attempt to build software linking -lrt or -lpthread on target. To clean this situation up somewhat and to simplify binary package dependecies for all of the potential musl, glibc and uclibc cases, drop those packages and move libpthread.so as well as librt.so into the main libc package for those libc implementations that happen ship them as extra shared libraries. Signed-off-by: Jo-Philipp Wich I think this is a good idea. How about adding PROVIDES:=librt libpthread to the libc package in order to avoid breaking non-core packages that still depend on those? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: dnsmasq ubus bug
Hi, On 2021-11-10 00:16, Hartmut Birr wrote: I've trouble with this commit: dnsmasq: add support for monitoring and modifying dns lookup results via ubus I've two dnsmasq instances configured. After this commit, one instance does crash: Tue Nov 9 23:39:21 2021 daemon.crit dnsmasq[1]: UBus error: Invalid argument Tue Nov 9 23:39:21 2021 daemon.crit dnsmasq[1]: FAILED to start up Tue Nov 9 23:39:26 2021 daemon.crit dnsmasq[1]: UBus error: Invalid argument Tue Nov 9 23:39:26 2021 daemon.crit dnsmasq[1]: FAILED to start up Tue Nov 9 23:39:32 2021 daemon.crit dnsmasq[1]: UBus error: Invalid argument Tue Nov 9 23:39:32 2021 daemon.crit dnsmasq[1]: FAILED to start up Tue Nov 9 23:39:38 2021 daemon.crit dnsmasq[1]: UBus error: Invalid argument Tue Nov 9 23:39:38 2021 daemon.crit dnsmasq[1]: FAILED to start up Tue Nov 9 23:39:43 2021 daemon.crit dnsmasq[1]: UBus error: Invalid argument Tue Nov 9 23:39:43 2021 daemon.crit dnsmasq[1]: FAILED to start up Tue Nov 9 23:39:49 2021 daemon.crit dnsmasq[1]: UBus error: Invalid argument Tue Nov 9 23:39:49 2021 daemon.crit dnsmasq[1]: FAILED to start up Tue Nov 9 23:39:49 2021 daemon.info procd: Instance dnsmasq::main s in a crash loop 6 crashes, 1 seconds since last crash Tue Nov 9 23:40:09 2021 daemon.info dnsmasq[1]: exiting on receipt of SIGTERM I've pushed a fix and it now generates the object name dynamically. Thanks for reporting this - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] interface-ip: copy more info for target host route
On 2021-10-26 23:59, luizl...@gmail.com wrote:
From: Luiz Angelo Daros de Luca
interface_ip_add_target_route was adding a host route without
copying other confs like type, source, online). The result was that this:
unreachable 192.168.0.9 metric 123
was being converted to:
192.168.0.9 dev lo scope link metric 123
Signed-off-by: Luiz Angelo Daros de Luca
---
interface-ip.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/interface-ip.c b/interface-ip.c
index 648f521..7c60fec 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -301,9 +301,26 @@ interface_ip_add_target_route(union if_addr *addr, bool
v6, struct interface *if
route->mask = v6 ? 128 : 32;
memcpy(>addr, addr, addrsize);
memcpy(>nexthop, _next->nexthop, sizeof(route->nexthop));
- route->mtu = r_next->mtu;
- route->metric = r_next->metric;
- route->table = r_next->table;
+ if (r_next->flags & DEVROUTE_MTU) {
+ route->mtu = r_next->mtu;
+ route->flags |= DEVROUTE_MTU;
+ }
+ if (r_next->flags & DEVROUTE_METRIC) {
+ route->metric = r_next->metric;
+ route->flags |= DEVROUTE_METRIC;
+ }
+ if (r_next->flags & DEVROUTE_TABLE) {
+ route->table = r_next->table;
+ route->flags |= DEVROUTE_TABLE;
+ }
+ if (r_next->flags & DEVROUTE_TYPE) {
+ route->type = r_next->type;
+ route->flags |= DEVROUTE_TYPE;
+ }
+ if (r_next->flags & DEVROUTE_ONLINK)
+ route->flags |= DEVROUTE_ONLINK;
How about leaving the route->{mtu,metric,table} assignment as-is and
doing something like this:
route->flags |= r->next & (DEVROUTE_MTU | DEVROUTE_METRIC |
DEVROUTE_TYPE | DEVROUTE_ONLINK);
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: hostapd: ubus inteface crashes hostapd?
On 2021-10-21 11:31, Nick wrote: Is someone massively utilizing the ubus interface from hostapd? I'm doing this with dawn and I saw that blocktrron already fixed some infinity loop. However, currently DAWN is crashing the hostapd. I make extensive use of the get_clients, all subscriptions, disassoc_immidient calls. Of course I don't want to exclude that the error is on my side. I just wanted to ask if someone is doing something similar. It is just weird for me that dawn can crash hostapd since it is only connecting via ubus and uses iwinfo library to get signal strength and channel utilization from wifi interfaces. See: https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-948192240 Please make some coredumps and send me gdb backtrace info, so that I can look into this. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RFC: toolchain for building eBPF modules within the OpenWrt build system
On 2021-10-18 15:37, Florian Eckert wrote: I'd suggest to require a preinstalled host toolchain for the time being. How about requiring a preinstalled host toolchain by default, but building it from source on buildbot? I wouldn't make it dependent on whether openwrt compiles on the buildbot or not. I am not using this build option CONFIG_BUILDBOT on my own builds. I'm definitely planning on having a separate option for it. What I meant in what I wrote above was to enable that option by default if CONFIG_BUILDBOT is set. Either use llvm from the buildhost (distribution), or let the openwrt buildsystem build its own llvm in the tool directory as you suggest. @nbd thank you for looking at this, would have needed the ebpf before :-) You're welcome. I plan on pushing my first package using eBPF soon. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RFC: toolchain for building eBPF modules within the OpenWrt build system
On 2021-10-04 15:20, Jo-Philipp Wich wrote: Hi Felix, I'd suggest to require a preinstalled host toolchain for the time being. How about requiring a preinstalled host toolchain by default, but building it from source on buildbot? If we rely on the toolchain on the host, the builds might vary based on the installed llvm versions and would not be properly reproducible. I'm currently writing a makefile for it and putting it in tools/ instead of toolchain/ in order to avoid unnecessary rebuilds when the configured target changes. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: handling of blob_buf_free?
On 2021-10-13 11:32, Nick wrote: > Does it make a difference in terms of performance to use stack buffers? > I switched now to using stack buffers, since for me it makes the code > more readable not having to deal with several buffers and possible race > conditions. (but just my view on the topic) Not really. It's only for the case where you need a buffer only within one function and don't want to keep allocated memory around for it. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: handling of blob_buf_free?
On 2021-10-13 07:53, Nick wrote: > Since I saw there were some new patches, e.g., procd, fixing > blob_buf_free() calls. > I asked several months ago: "Should you call blob_buf_free() after > calling blob_buf_init()?" > https://forum.openwrt.org/t/should-you-call-blob-buf-free-after-calling-blob-buf-init > > I did not receive any answer. I think blob_buf_init() is freeing memory > if it is the same buf? > Any suggestions how to use blob_buf_free? If a buffer was already allocated, blob_buf_init reuses it. You can keep reusing it as many times as you want. You only need to call blob_buf_free if you explicitly want to free the buffer memory (e.g. on exit, or if the blob_buf is on stack) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RFC: toolchain for building eBPF modules within the OpenWrt build system
Hi, I recently spent some time digging into what's needed for proper eBPF build support in OpenWrt. Here's what I found so far: Most out-of-tree eBPF based projects fork some of the BPF related kernel headers from various different kernel versions and manually maintain those forks. These header files are usually very incomplete and tailored specifically for the project that uses them. To make things even worse, they typically explicitly rely on including headers from the local x86 host toolchain header files when building for the BPF target. The in-kernel build of BPF modules is weird in a different way. It explicitly includes all the header files from the arch that the kernel is being built for. And because a lot of assembly stuff in there is completely incompatible with building for the BPF target, the build system actually targets clang to the same arch that the kernel is being built for and only emits un-optimized LLVM bitcode without running any of the LLVM passes. It then passes that bitcode to the optimizer and target code generator with bpf specified as target arch. It's a weird hack, but it seems to work properly even when cross-compiling to non-x86 targets. When writing ebpf modules myself, I definitely don't want to rely on the crappy header fork mess that most out-of-tree projects use. In my tests it was simply too fragile, and I couldn't get it to work on my macOS build host either. Even if we could make it work for more use cases, it would still be a maintenance hell when comes to supporting more features and newer kernel versions. I think staying close to the way that in-tree BPF module builds work is the way to go. Unfortunately, this means that we will not be able to use GCC for BPF (which Daniel has been working on), because targeting the frontend and the rest of the compiler to different architectures is only supported by clang/LLVM. I just did a test build of LLVM with reduced features and targetting only BPF, and it takes around 42 minutes to build on my 2018 macbook. That's more than the time needed to build a typical basic OpenWrt build from scratch. The way I see it, these are our options for eBPF support: 1. Add a host dependency on a recent enough LLVM version for eBPF. 1a) disable it by default 1b) hide eBPF packages unless host support is available 2. Add llvm to tools/ to ensure that it is only built once, even when switching between targets 3. Add llvm as a host package and use build-dependencies in eBPF 4. Ship precompiled big and little endian eBPF binaries + scripts to recompile in packages, and rely on CO-RE (compile once, run everywhere) What do you think? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
On 2021-09-28 13:49, Andre Heider wrote: > On 28/09/2021 12:20, Andre Heider wrote: >> fyi brport/proxyarp was still "0" too, which probably means that the >> netidf condition "if (up && ifname != vif->ifname)" doesn't eval to true >> as that's the only spot setting "dev->wireless_proxyarp". > > That pointed me in the right direction, attached netifd patch fixes the > issue for me. lol. Your patch looks correct to me, thanks for looking into this. I've pushed it out, but extended the commit description a bit. Not only was the use of strcmp necessary, but the previous logic was inverted as well. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Wifi bug
On 2021-09-27 18:30, Hannu Nyman wrote: > Felix Fietkau kirjoitti 27.9.2021 klo 19.17: >> On 2021-09-27 17:45, Hannu Nyman wrote: >>> Felix Fietkau kirjoitti 27.9.2021 klo 13.59: >>>> On a crash, it should drop a .core file to /tmp. Please copy that to >>>> your build host and use ./scripts/remote-gdb to obtain a backtrace from >>>> it. I'd like to know, which line of code in netifd it crashes on, so I >>>> can fix it. So far the bug has not shown up in my own tests... >>>> >>>> - Felix >>> >>> This is probably what you are looking for... >>> To me it looks like it might actually be a list handling bug in libubox. > >> Can you please try this netifd patch? > > At the first glance, the impact looks ok to me: >wifi goes down with "with down", netifd stays alive and wifi remains down. > :-) > > Hannu Fix pushed, thanks for testing. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Wifi bug
On 2021-09-27 17:45, Hannu Nyman wrote:
> Felix Fietkau kirjoitti 27.9.2021 klo 13.59:
>> On a crash, it should drop a .core file to /tmp. Please copy that to
>> your build host and use ./scripts/remote-gdb to obtain a backtrace from
>> it. I'd like to know, which line of code in netifd it crashes on, so I
>> can fix it. So far the bug has not shown up in my own tests...
>>
>> - Felix
>
>
> This is probably what you are looking for...
> To me it looks like it might actually be a list handling bug in libubox.Can
> you please try this netifd patch?
Thanks,
- Felix
---
diff --git a/alias.c b/alias.c
index 951e046bb3f1..98d54100fef9 100644
--- a/alias.c
+++ b/alias.c
@@ -178,13 +178,9 @@ alias_notify_device(const char *name, struct device *dev)
{
struct alias_device *alias;
- device_lock();
-
alias = avl_find_element(, name, alias, avl);
if (alias)
alias_set_device(alias, dev);
-
- device_unlock();
}
struct device *
diff --git a/bonding.c b/bonding.c
index 0bf4f9a331ef..457fe5159899 100644
--- a/bonding.c
+++ b/bonding.c
@@ -566,8 +566,6 @@ bonding_free_port(struct bonding_port *bp)
bonding_remove_port(bp);
- device_lock();
-
device_remove_user(>dev);
/*
@@ -582,8 +580,6 @@ bonding_free_port(struct bonding_port *bp)
device_set_present(dev, true);
}
- device_unlock();
-
free(bp);
}
diff --git a/bridge.c b/bridge.c
index 2ce5c2b11b49..7e61b9df8326 100644
--- a/bridge.c
+++ b/bridge.c
@@ -512,8 +512,6 @@ restart:
goto restart;
}
- device_lock();
-
device_remove_user(>dev);
uloop_timeout_cancel(>check_timer);
@@ -529,8 +527,6 @@ restart:
device_set_present(dev, true);
}
- device_unlock();
-
free(bm);
}
diff --git a/config.c b/config.c
index d83ea9cb6b6c..9bbda39d3fb5 100644
--- a/config.c
+++ b/config.c
@@ -762,7 +762,6 @@ config_init_all(void)
vlist_update();
config_init = true;
- device_lock();
device_reset_config();
config_init_devices(true);
@@ -775,12 +774,10 @@ config_init_all(void)
config_init_wireless();
config_init = false;
- device_unlock();
device_reset_old();
device_init_pending();
vlist_flush();
- device_free_unused(NULL);
interface_refresh_assignments(false);
interface_start_pending();
wireless_start_pending();
diff --git a/device.c b/device.c
index bb39ea7f8d71..b3d0e85f8550 100644
--- a/device.c
+++ b/device.c
@@ -99,18 +99,6 @@ device_type_get(const char *tname)
return NULL;
}
-void device_lock(void)
-{
- __devlock++;
-}
-
-void device_unlock(void)
-{
- __devlock--;
- if (!__devlock)
- device_free_unused(NULL);
-}
-
static int device_vlan_len(struct kvlist *kv, const void *data)
{
return sizeof(unsigned int);
@@ -895,14 +883,27 @@ device_free(struct device *dev)
}
static void
-__device_free_unused(struct device *dev)
+__device_free_unused(struct uloop_timeout *timeout)
{
- if (!safe_list_empty(>users) ||
- !safe_list_empty(>aliases) ||
- dev->current_config || __devlock)
- return;
+ struct device *dev, *tmp;
+
+ avl_for_each_element_safe(, dev, avl, tmp) {
+ if (!safe_list_empty(>users) ||
+ !safe_list_empty(>aliases) ||
+ dev->current_config)
+ continue;
+
+ device_free(dev);
+ }
+}
+
+void device_free_unused(void)
+{
+ static struct uloop_timeout free_timer = {
+ .cb = __device_free_unused,
+ };
- device_free(dev);
+ uloop_timeout_set(_timer, 1);
}
void device_remove_user(struct device_user *dep)
@@ -919,19 +920,7 @@ void device_remove_user(struct device_user *dep)
safe_list_del(>list);
dep->dev = NULL;
D(DEVICE, "Remove user for device '%s', refcount=%d\n", dev->ifname,
device_refcount(dev));
- __device_free_unused(dev);
-}
-
-void
-device_free_unused(struct device *dev)
-{
- struct device *tmp;
-
- if (dev)
- return __device_free_unused(dev);
-
- avl_for_each_element_safe(, dev, avl, tmp)
- __device_free_unused(dev);
+ device_free_unused();
}
void
diff --git a/device.h b/device.h
index 0496e893cbc9..37f8c37c58a3 100644
--- a/device.h
+++ b/device.h
@@ -300,9 +300,6 @@ extern const struct uci_blob_param_list device_attr_list;
extern struct device_type simple_device_type;
extern struct device_type tunnel_device_type;
-void device_lock(void);
-void device_unlock(void);
-
void device_vlan_update(bool done);
void device_stp_init(void);
@@ -346,7 +343,7 @@ void device_release(struct device_user *de
Re: Wifi bug
On 2021-09-27 13:33, e9hack wrote:
> Am 27.09.2021 um 12:59 schrieb Felix Fietkau:
>>
>> Hi,
>>
>>
>> On 2021-09-26 14:48, e9hack wrote:
>>> Do you see a page fault from netifd in the log? If it does crash, it is
>>> restarted by procd. This does restart the network stack. If I start netifd
>>> with strace, I got this lines immediately before the page fault:
>>>
>>> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = -1 ENOENT (No such file
>>> or directory)
>>> open("/tmp/resolv.conf.d/resolv.conf.auto.tmp",
>>> O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 14
>>> ioctl(14, TIOCGWINSZ, 0x7f717a74) = -1 ENOTTY (Not a tty)
>>> _llseek(14, 0, [0], SEEK_SET) = 0
>>> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
>>> close(14) = 0
>>> open("/tmp/resolv.conf.d/resolv.conf.auto", O_RDONLY|O_LARGEFILE) = 14
>>> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
>>> close(14) = 0
>>> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = 0
>>> munmap(0x77d61000, 8192)= 0
>>> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x77d61038} ---
>>> +++ killed by SIGSEGV +++
>>>
>>> The part 0x77d61... does change on several starts. The offset 0x.038 is
>>> the same.
>> On a crash, it should drop a .core file to /tmp. Please copy that to
>> your build host and use ./scripts/remote-gdb to obtain a backtrace from
>> it. I'd like to know, which line of code in netifd it crashes on, so I
>> can fix it. So far the bug has not shown up in my own tests...
>>
>> - Felix
>
> It doesn't generate a core-dump. How can I activate core-dumps?
Normally it should be active by default. Is CONFIG_KERNEL_ELF_CORE set
in your .config?
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Wifi bug
Hi,
On 2021-09-26 14:48, e9hack wrote:
> Do you see a page fault from netifd in the log? If it does crash, it is
> restarted by procd. This does restart the network stack. If I start netifd
> with strace, I got this lines immediately before the page fault:
>
> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = -1 ENOENT (No such file
> or directory)
> open("/tmp/resolv.conf.d/resolv.conf.auto.tmp",
> O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 14
> ioctl(14, TIOCGWINSZ, 0x7f717a74) = -1 ENOTTY (Not a tty)
> _llseek(14, 0, [0], SEEK_SET) = 0
> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
> close(14) = 0
> open("/tmp/resolv.conf.d/resolv.conf.auto", O_RDONLY|O_LARGEFILE) = 14
> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
> close(14) = 0
> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = 0
> munmap(0x77d61000, 8192)= 0
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x77d61038} ---
> +++ killed by SIGSEGV +++
>
> The part 0x77d61... does change on several starts. The offset 0x.038 is
> the same.
On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use ./scripts/remote-gdb to obtain a backtrace from
it. I'd like to know, which line of code in netifd it crashes on, so I
can fix it. So far the bug has not shown up in my own tests...
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uci: unnecessary write accesses
On 2021-09-21 13:19, Florian Eckert wrote:
>
> I have written a small shell script, to track write access to the
> '/etc/config' directory.
> For this task I am using the inotify-tool package [1].
> I am using the inotifywait tool to add the watchers [2] with a small
> shell script and log them to the syslog.
>
> If I change a 'uci' option with the the 'uci' commands, then I get
> create and write events for a temporary file in the '/etc/config/'
> directory.
> I didn't expect it to be like this.
>
> For example, if I now change a file using the 'uci' command, a tmp file
> is created under '/etc/config'.
> Is this correct? Or do we have a problem there.
> I have always thought that for embedded systems with flashes it is
> important to make as few write accesses as possible.
>
> Shell commands to change uci config:
>
> root@st-dev-07 ~ # uci set system.led_Power.trigger=none
> root@st-dev-07 ~ # uci commit system
>
> Log output of my Script:
>
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CREATE","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":"system","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"ATTRIB","time":"09/21/21
>
> 12:50:38"}
>
> I am bothered about the file '.system.uci-fEGgbp'?
The extra temporary file in /etc/config is intentional. uci is simply
using a common pattern in order to make rewriting config files atomic
and avoid leaving behind empty or incomplete files in case of a system
crash during commit.
The new file is written under a temporary name, and after a fsync, it is
renamed to the final filename. This only works if the temporary file and
the config file are on the same filesystem, that's why the temp file is
put in /etc/config as well.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: WDS stopped working in 21.02, looking for bug in netifd
On 2021-09-20 22:56, Daniel Haid wrote: > Felix, I took the last openwrt snapshot and compiled netifd from master > with your patch applied and installed it. > > Result: > After boot wlan0.sta1 was DOWN. > After "/etc/init.d/network restart" it was UP and the connection worked! > After another "/etc/init.d/network restart" it was DOWN again. > After reboot it was UP again and working. > After "/etc/init.d/network restart" it was DOWN again. Can you please send me the config that you're using? I'd like to try to reproduce it myself. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: WDS stopped working in 21.02, looking for bug in netifd
On 2021-09-20 16:46, Daniel Haid wrote:
> I have continued investigating.
>
> After all, it seems that the interface being down is just a symptom.
>
> I summarize my current findings:
>
> With the 21.02 netifd version, there seems to be a bug concerting WDS.
> The bug has the following effect:
>
> I have openwrt 21.02 running on one system running as WDS AP and another
> one running as WDS Client. The WDS Client is running and its
> configuration never changed.
>
> After booting the WDS AP, there are two possibilities for in what state
> the system can be, I call them NON-WORKING and WORKING. The probability
> seems to be about 50% to be in one or the other state after booting.
>
> To find out in which state I am after booting, I look for the interface
> wlan0.sta1. If it is UP, then we are in state WORKING. If it is DOWN,
> then we are in state NON-WORKING.
>
> Using ping, in state WORKING, the AP can reach the Client. In state
> NON-WORKING, the AP cannot reach the Client.
>
> In state WORKING, the interface wlan0.sta1 can be set to DOWN and UP
> again, and the AP can then again ping the Client, but only after waiting
> about 4 minutes for the Client to reconnect to the AP (in my last mail,
> I wrote that it did not work, but I just did not wait long enough).
>
> In state NON-WORKING, I can set the interface wlan0.sta1 to UP, but this
> will not help. The ip command will show that the interface is UP, but
> the AP can not ping the Client, no matter how long I wait after setting
> the state to UP.
>
> If I turn off the Client, wait for the interface wlan0.sta1 to be
> removed on the AP, and then restart the Client, then the interface
> wlan0.sta1 will be created again, in state DOWN. Everything is again as
> in the state NON-WORKING.
>
> To reliably reach the state NON-WORKING, run "/etc/init.d/network restart".
>
> Changing the function wireless_interface_handle_link such that it does
> not call interface_handle_link when it is called from
> wireless_device_hotplug_event fixes the bug.
>
> But I do not understand what is happening.
>
> I am not subscribed to the list; please send Cc to me.
Please test if applying this change to netifd fixes the issue.
Thanks,
- Felix
---
--- a/wireless.c
+++ b/wireless.c
@@ -328,14 +328,14 @@ static void wireless_interface_handle_link(struct
wireless_interface *vif, const
if (!ifname)
ifname = vif->ifname;
- if (up) {
+ if (up && ifname != vif->ifname) {
struct device *dev = device_get(ifname, 2);
if (dev) {
dev->wireless_isolate = vif->isolate;
dev->wireless_proxyarp = vif->proxyarp;
dev->wireless = true;
dev->wireless_ap = vif->ap_mode;
- dev->bpdu_filter = dev->wireless_ap && ifname ==
vif->ifname;
+ dev->bpdu_filter = dev->wireless_ap;
}
}
@@ -793,6 +793,13 @@ wireless_interface_init_config(struct wireless_interface
*vif)
if ((cur = tb[VIF_ATTR_NETWORK]))
vif->network = cur;
+ cur = tb[VIF_ATTR_MODE];
+ if (cur)
+ vif->ap_mode = !strcmp(blobmsg_get_string(cur), "ap");
+
+ if (!vif->ap_mode)
+ return;
+
cur = tb[VIF_ATTR_ISOLATE];
if (cur)
vif->isolate = blobmsg_get_bool(cur);
@@ -801,9 +808,6 @@ wireless_interface_init_config(struct wireless_interface
*vif)
if (cur)
vif->proxyarp = blobmsg_get_bool(cur);
- cur = tb[VIF_ATTR_MODE];
- if (cur)
- vif->ap_mode = !strcmp(blobmsg_get_string(cur), "ap");
}
/* vlist update call for wireless interface list */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Broken ARP broadcast on master (commit 0f688797)
> On 6. Sep 2021, at 02:03, David Bauer wrote:
>
> Hi Felix,
>
> updating my Wireless APs (ath9k+ath10k / mt7603+mt7915) broke ARP broadcast
> delivery to clients
> connected to the radios with SW rate control.
>
> Bisecting this problem revealed commit 0f688797 ("mac80211: add missing
> change for encap offload
> on devices with sw rate control") introduces this problem, reverting it
> restored the desired
> functionality.
>
> Can you have a look what is going wrong here?
Hi David,
Please try the latest version, it should resolve the issue
Thanks,
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Revert "initd: fix off-by-one error in mkdev.c"
On 2021-08-31 10:25, vinc...@systemli.org wrote: > From: Nick Hainke > > This reverts commit 8eb1d783cca6e0d501dd3a2f94262ffc36ae6482. > > This line reads a symbolic link into the string buffer "buf". > len = readlink(buf2, buf, sizeof(buf)); > The commit replaced now > buf[len] = 0; > with > buf[sizeof(buf) - 1] = '\0'; > > However, that does not work since readlink does not null-terminate > the string written into "buf" and "buf[len] = 0" was used for that. > > What happens if the buffer is to small? > "If the buf argument is not large enough to contain the link content, > the first bufsize bytes shall be placed in buf." > (Source: > https://pubs.opengroup.org/onlinepubs/009695399/functions/readlink.htm) That revert adds back the original off-by-one error, since len will be sizeof(buf) in case of an undersized buffer. I agree that 'buf[len] = 0' is correct, but only if you also use sizeof(buf)-1 as size argument in the readlink() call. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uhttpd: add config option for json_script
On 2021-08-20 15:11, Stijn Tintel wrote: > Add a config option for json_script instead of unconditionally including > all json files in /etc/uhttpd in every uhttpd instance. This makes it > possible to configure a single instance with an unconditional redirect, > which is currently not possible as it would render all other uhttpd > instances unusable. > > Signed-off-by: Stijn Tintel Acked-by: Felix Fietkau ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] Revert "netifd: update to the latest version"
On 2021-07-26 17:09, Petr Štetiar wrote: > Petr Štetiar [2021-07-26 17:01:32]: > >> This reverts commit 089efd61e9a6cdc0ea39c184d37bc8ebbe03175c as it >> breaks LAN network on at least mvebu/turris-omnia device. >> >> Confirmed-by: Josef Schlehofer >> Signed-off-by: Petr Štetiar >> --- >> >> I've discovered this today in the morning in my testbed where I perform daily >> runtime tests of initramfs images on several devices, where images/tests for >> snapshot and 21.02-SNAPSHOT failed on turris-omnia device. > > Sorry, forgot to provide more detials. The problem is with initialization of > LAN network, where the interface readiness is tested by following command: > > ifstatus lan | jsonfilter -qe "@.up" > > then the LAN network availability is tested with simple `ping -c1 192.168.1.2` > command which timeouts. This is pristine image with no config changes, so the > device has 192.168.1.1/24 network config and the other end 192.168.1.2/24. > > Console logs are available: > > snapshot > https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/1451323563/artifacts/file/console_turris-omnia-initramfs.txt > 21.02 > https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/jobs/1451222403/artifacts/file/console_turris-omnia-initramfs.txt Fixed the regression in master and 21.02, sorry about the mess. For some reason, it did not trigger in my configurations... - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 2021-07-17 17:45, Hauke Mehrtens wrote: > Hi, > > In general the 21.02-rc3 looks good, but we still have some problems. > > Currently we still have these problem: > > - IPv6 broken with flow offloading (according to reports, potentially > related to hw flow offloading) > - PPPoE allegedly broken (according to reports, not fully reproducible, > likely related to hw flow offloading too) >- https://bugs.openwrt.org/index.php?do=details_id=3909 >- https://bugs.openwrt.org/index.php?do=details_id=3835 >- > https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 > - DHCPv6 broken if lease times < 12h chosen >- > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 >- > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 > - WDS with bridge-vlan broken (missing backport from master) I added a netifd backport in fe498dd3f108 (with a fix in f3f70fb9567d) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ubus: add a private field to event handlers
On 2021-07-13 13:57, louis_hamp...@sercomm.com wrote: > > This is particularly useful in multithreaded non-C FFI, where > additional context from where the event handler was registered may be > critical to ensuring the output of the event is sent to the right > location. > > Signed-off-by: Louis Hampton In order to get the additional context, the normal solution is to embed struct ubus_event_handler into another data structure, which contains the extra context and can be accessed via container_of. Is there a reason why this can't be done in your code as well? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: wrong activation of internal radius server
Hi Hartmut,
On 2021-06-04 15:22, e9hack wrote:
> OpenWrt has been supporting hostapd's internal radius server for a few days.
> For several years there has been a line in the init-script that activates the
> internal radius server too. I think this is wrong (from hostapd.sh):
>
> [ -n "$wps_possible" -a -n "$config_methods" ] && {
> set_default ext_registrar 0
> set_default wps_device_type "6-0050F204-1"
> set_default wps_device_name "OpenWrt AP"
> set_default wps_manufacturer "www.openwrt.org"
> set_default wps_independent 1
>
> wps_state=2
> [ -n "$wps_not_configured" ] && wps_state=1
>
> [ "$ext_registrar" -gt 0 -a -n "$network_bridge" ] && append
> bss_conf "upnp_iface=$network_bridge" "$N"
>
> ===> append bss_conf "eap_server=1" "$N"
I just checked the hostapd WPS README file, and it seems that the
eap_server=1 line is actually required:
https://w1.fi/cgit/hostap/tree/hostapd/README-WPS#n94
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 netifd] interface: rename "ifname" attribute to "device"
On 2021-05-24 15:35, Rafał Miłecki wrote: > From: Rafał Miłecki > > Interfaces need to be assigned to devices. For that purpose a "device" > option should be more accurate than "ifname" one. > > For backward compatibility add a temporary config translation. > > Config example: > > config device > option name 'br-lan' > option type 'bridge' > list ports 'lan1' > list ports 'lan2' > > config interface 'lan' > option device 'br-lan' > option proto 'static' > > Signed-off-by: Rafał Miłecki I think the code for backwards compatibility would be a lot simpler if you add both IFACE_ATTR_DEVICE and IFACE_ATTR_IFNAME and initialize tb[IFACE_ATTR_DEVICE] to tb[IFACE_ATTR_IFNAME] if it's NULL. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH netifd] interface: rename "ifname" attribute to "device"
On 2021-05-17 16:49, Rafał Miłecki wrote: > From: Rafał Miłecki > > Interfaces need to be assigned to devices. For that purpose a "device" > option should be more accurate than "ifname" one. > > For backward compatibility add a temporary config translation. > > Config example: > > config device > option name 'lan' > option type 'bridge' > list ports 'lan1' > list ports 'lan2' > > config interface 'home' > option device 'lan' > option proto 'static' > > Signed-off-by: Rafał Miłecki While I agree that the 'device' name would fit better than 'ifname', the fallback config translation is not enough in this case. netifd supports adding dynamic interfaces via ubus, where the config data is provided as blobmsg. You could update the in-tree users of that, but I don't know if there are any out-of-tree downstream users of this functionality that you would be breaking with this change. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd: redesigning UCI config & interfaces
Hi Rafał, Thanks for the proposal On 2021-05-13 15:58, Rafał Miłecki wrote: > Current /etc/config/network design and netifd implementation are quite a > bit messy: > 1. There is no clear layer 2 vs. layer 3 distinction I think aside from a few legacy compatibility hacks (e.g. the infamous interface option type bridge, which we really should phase out at some point), there actually is a clear distinction. The device refers to the underlying layer 2 linux device The interface refers to a logical layer 3 configuration on top of that, which may or may not have its own layer 3 netdev. It may not seem as clear when viewing the whole thing through the lens of just looking at the individual linux netdevs, but that's because it's different data model. > 2. UCI sections are inconsistent > 3. For some setups there are few ways of defining them > 4. A lot of netifd states are implicit (magic behaviour) > 5. It's really hard to handle all above with a simple & clear UI I think this strongly depends on your definition of 'simple' and the level of abstraction. If your definition of a simple UI is simply a fancier display of netdev stats and individual linux netdev configurations, then your statement makes some sense to me. For something more high level than that, I don't think it makes things any easier. > I'm working on network & netifd cleanup and wanted to describe my plans. > Please review my following ideas. > > > *** ubus objects *** > > Linux uses interfaces (e.g. eth0, br-lan) for laver 2 devices as well as > layer 3 interfaces. Tools like ifconfig, brctl, ip work on top of such > interfaces. > > OpenWrt tools ifup & ifdown are expected to work on Linux interfaces > just like ifconfig. They call ubus objects methods "up" & "down". > > That's why we need network.interface. ubus object for every used > Linux interface. No matter if that Linux interface is layer 2 or layer > 3. Even if Linux interface "lan" is a bridge (layer 2) we still need a > way to bring it up & down (so network.interface.lan is required). > > Adding a new set of ubus objects (like network.device.lan) would result > in duplication. We don't want that. E.g. both commands would do the same > 1. ubus call network.device.lan up > 1. ubus call network.interface.lan up In my opinion, forcing the interface to have the same name as the explicitly specified l3 device is a big step back in usability. In the current default config, interface sections are named after their logical function, e.g. lan or wan. Users can use ifup/ifdown wan having to worry about whether their wan device is a DSA port called wan, a pppoe interface called pppoe-wan, or a switch VLAN like switch0.1, eth0.1 or a named VLAN device like sw0-wan. It also makes it easy to bring up/down individual logical configurations on top of the same device. Your proposal wouldn't just affect what users need to write in the network config. We also have other services that refer to the logical configurations (and then look up the actual linux device later). Here's a simple example of how your proposed change would make things a lot more difficult for users and/or the UI: Let's assume a more modern target already using 'wan' as netdev for the WAN port via DSA. Let's also assume that it is currently configured to use DHCP on WAN and has a few services running that refer to the wan interface. Now the user has moved the device somewhere else and wants to use PPPoE for WAN. This means that the user doesn't just have to add an extra device section and change the 'device' option for the ifname, they also have to go through all config sections of services potentially depending on the old netdev name and rewrite those. > *** devices (layer 2) *** > > We should have designed UCI sections for layer 2 devices. Use UCI > section types instead of "option type foo". Reasons: > 1. Each device requires different handling > 2. Options have different meaning depending on device type > > While switching to new UCI sections we should also cleanup some UCI > options and behaviour. > > Example: > > config bridge > option name 'foo' > list ports 'lan1' > list ports 'lan2' > > Above you can see new UCI section for bridge device with "ports" list > instead of "ifname" string. > > Above config should result in creating "foo" bridge Linux interface and > network.interface.foo ubus object for bringing it up / down. > > Other devices would work similarly, e.g. "config vlan" for vlan. I'm not sure if this part is really worth the effort or makes things better in any meaningful way. Even if you get rid of most of the type dependent sets of accepted options, some will likely remain for tunnel devices, and interfaces will also still have varying options depending on the proto. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: FRAG Attacks (new vuln for wifi)
On 2021-05-13 11:10, Mirko Parthey wrote: > On Thu, May 13, 2021 at 05:57:01AM +0200, Felix Fietkau wrote: >> >> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need >> >> > to be patched? >> >> > Is 4.19 the oldest that owrt will consume? >> >> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update >> >> anything older than that. >> > >> > So, to summarise, the 4.19, 5.4 and 5.10 branch kernels are currently in >> > use. >> I don't see where we're using the ath10k-ct 5.4 kernel at all. It should >> be just 4.19 and 5.10. > > I am just commenting from the sideline, but I see other Kernel versions: > > OpenWrt 19.07 = Kernel 4.14 > OpenWrt 21.02 = Kernel 5.4 > OpenWrt master = mostly still Kernel 5.4, but moving towards 5.10 We're talking about the version of the kernel tree used to create the ath10k-ct source, not the kernel version used by OpenWrt. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: FRAG Attacks (new vuln for wifi)
On 2021-05-13 01:45, Nick Lowe wrote: >> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to >> > be patched? >> > Is 4.19 the oldest that owrt will consume? >> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update >> anything older than that. > > So, to summarise, the 4.19, 5.4 and 5.10 branch kernels are currently in use. I don't see where we're using the ath10k-ct 5.4 kernel at all. It should be just 4.19 and 5.10. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: FRAG Attacks (new vuln for wifi)
On 2021-05-12 19:13, Ben Greear wrote: > On 5/12/21 9:00 AM, Felix Fietkau wrote: >> >> Hi, >> >> On 2021-05-12 01:34, Paul D wrote: >>> https://www.fragattacks.com/ >>> >>> https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ >> I've merged those fixes in openwrt commit 025bd93f36c9. >> After some testing in master, we should backport them soon. >> >> ath10k-ct will need to be fixed too, and I plan on pushing an mt76 fix >> very soon. Not sure what other drivers may need fixing... >> >> - Felix >> > > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to be > patched? > Is 4.19 the oldest that owrt will consume? I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update anything older than that. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: FRAG Attacks (new vuln for wifi)
Hi, On 2021-05-12 01:34, Paul D wrote: > https://www.fragattacks.com/ > > https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ I've merged those fixes in openwrt commit 025bd93f36c9. After some testing in master, we should backport them soon. ath10k-ct will need to be fixed too, and I plan on pushing an mt76 fix very soon. Not sure what other drivers may need fixing... - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: fix regression for kernels < 5.10
On 2021-04-13 14:22, Sebastian Kemper wrote:
> This fixes a regression introduced with commit
> 5ed1e5140a80558ab47fd70410ae3242bed5becf ("build: build kernel image
> before building modules/packages").
>
> Before this commit the make target would always include "modules",
> resulting in a MODPOST and a complete Module.symvers file. Since this
> commit a MODPOST of the kernel modules is not guaranteed for kernels <
> 5.10. This results in some broken SDKs in which external packages that
> depend on exported symbols from kernel modules fail to compile.
Why is it not enough to do this in the CompileModules step?
> Adding "modules" back to the calls to the CompileImage defines fixes the
> regression. For kernels > 5.10 this is not needed, but it doesn't cause
> any harm either.
Why is >5.10 not affected? Can we backport the fix? I'd like to avoid
adding extra unnecessary build step that slow down running make
target/install.
> Tested with kernels 5.4.x and 5.10.x.
>
> Signed-off-by: Sebastian Kemper
> ---
> include/kernel-defaults.mk | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
> index 4b0b136a03..1b3b4497a2 100644
> --- a/include/kernel-defaults.mk
> +++ b/include/kernel-defaults.mk
> @@ -147,12 +147,17 @@ define Kernel/CopyImage
> }
> endef
>
> +# Always add "modules" so a proper Module.symvers file is written that
> +# also contains symbols from the kernel modules. Without these symbols
> +# external packages that depend on exported symbols from kernel modules
> +# will fail to build.
> define Kernel/CompileImage/Default
> rm -f $(TARGET_DIR)/init
> - +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> $(KERNELNAME),$(KERNELNAME),all)
> + +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> $(KERNELNAME),$(KERNELNAME),all) modules
> $(call Kernel/CopyImage)
> endef
>
> +# Here as well, always add "modules", see comment above.
> ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
> define Kernel/CompileImage/Initramfs
> $(call Kernel/Configure/Initramfs)
> @@ -173,7 +178,7 @@ endif
> # ? $(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZ4),)
> $(if
> $(CONFIG_TARGET_INITRAMFS_COMPRESSION_ZSTD),$(STAGING_DIR_HOST)/bin/zstd -T0
> -f -o $(KERNEL_BUILD_DIR)/initrd.cpio.zstd $(KERNEL_BUILD_DIR)/initrd.cpio)
> endif
> - +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> $(KERNELNAME),$(KERNELNAME),all)
> + +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> $(KERNELNAME),$(KERNELNAME),all) modules
Why do this for initramfs as well?
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: disable crypto-hw-ccp on BCM4908
On 2021-04-13 11:46, Rafał Miłecki wrote: > From: Rafał Miłecki > > CONFIG_CRYPTO_DEV_SP_CCP depends on DMA_ENGINE which depends on > DMADEVICES=y which bcm4908 doesn't need and doesn't use at this point. > > Trying to build this package on bcm4908 was causing: > ERROR: module > 'build_dir/target-aarch64_cortex-a53_musl/linux-bcm4908_generic/linux-5.4.110/drivers/crypto/ccp/ccp-crypto.ko' > is missing. > > Signed-off-by: Rafał Miłecki > --- > package/kernel/linux/modules/crypto.mk | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/package/kernel/linux/modules/crypto.mk > b/package/kernel/linux/modules/crypto.mk > index cbaa8d3ce5..0f696c3129 100644 > --- a/package/kernel/linux/modules/crypto.mk > +++ b/package/kernel/linux/modules/crypto.mk > @@ -319,7 +319,8 @@ $(eval $(call KernelPackage,crypto-hmac)) > > define KernelPackage/crypto-hw-ccp >TITLE:=AMD Cryptographic Coprocessor > - DEPENDS:=+kmod-crypto-authenc +kmod-crypto-hash +kmod-crypto-manager > +kmod-random-core +kmod-crypto-sha1 +kmod-crypto-sha256 +kmod-crypto-rsa > + DEPENDS:=@!TARGET_bcm4908 > + DEPENDS+=+kmod-crypto-authenc +kmod-crypto-hash +kmod-crypto-manager > +kmod-random-core +kmod-crypto-sha1 +kmod-crypto-sha256 +kmod-crypto-rsa Wouldn't it make a lot more sense to depend on @TARGET_x86_64 instead? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Regression in auto-mounting mtd squashfs partitions
On 2021-04-10 16:33, Daniel Golle wrote:
> On Sat, Apr 10, 2021 at 04:04:28PM +0200, Felix Fietkau wrote:
>> Hi Daniel,
>>
>> it seems to me that your commit 2809d744 ("kernel: support FIT
>> partition parser on mtdblock devices") is causing a regression in
>> mounting squashfs rootfs when CONFIG_FIT_PARTITION is enabled.
>> The following workaround fixes it, but maybe you can make a better fix,
>> since you're more familiar with the code.
>
> No, I just forgot that we are also making assumptions about the mtdblock
> device minor number in our own patches...
> The fix looks good to me and certainly won't break devices that are
> actually making of the new external-data FIT images (as ROOT_DEV is
> then set by the FIT block partition parser in a generic way and no
> 'rootfs' MTD partition exists in that case).
>
> Acked-by: Daniel Golle
Fix pushed, thanks for the fast reply.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Regression in auto-mounting mtd squashfs partitions
Hi Daniel,
it seems to me that your commit 2809d744 ("kernel: support FIT
partition parser on mtdblock devices") is causing a regression in
mounting squashfs rootfs when CONFIG_FIT_PARTITION is enabled.
The following workaround fixes it, but maybe you can make a better fix,
since you're more familiar with the code.
- Felix
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -699,9 +699,13 @@ int add_mtd_device(struct mtd_info *mtd)
if (!strcmp(mtd->name, "rootfs") &&
IS_ENABLED(CONFIG_MTD_ROOTFS_ROOT_DEV) &&
ROOT_DEV == 0) {
+ unsigned int index = mtd->index;
pr_notice("mtd: device %d (%s) set to be root filesystem\n",
mtd->index, mtd->name);
- ROOT_DEV = MKDEV(MTD_BLOCK_MAJOR, mtd->index);
+#ifdef CONFIG_FIT_PARTITION
+ index <<= 1;
+#endif
+ ROOT_DEV = MKDEV(MTD_BLOCK_MAJOR, index);
}
return 0;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: drop the conntrack rtcache patch
On 2021-04-09 00:57, Rui Salvaterra wrote: > It's in backports-5.4, but it wasn't ever merged. Upstream followed another > approach, with flow offloading, which has much better performance. Drop this > obsolete patch and refresh the kernel patches. > > Signed-off-by: Rui Salvaterra Acked-by: Felix Fietkau - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] openssl: don't rename a file with quilt
On 2021-03-26 22:39, Eneas U de Queiroz wrote: > On Fri, Mar 26, 2021 at 4:28 PM Rosen Penev wrote: >> >> On Fri, Mar 26, 2021 at 5:55 AM Eneas U de Queiroz >> wrote: >> > >> > On Fri, Mar 26, 2021 at 6:26 AM Rosen Penev wrote: >> > > +ifeq ($(QUILT),) >> > > + mv $(PKG_BUILD_DIR)/crypto/engine/eng_devcrypto.c >> > > $(PKG_BUILD_DIR)/engines/e_devcrypto.c >> > > +endif >> > >> > This will break compilation with QUILT, as the rename will never >> > happen then. You're using this strategy with other packages, so I >> > won't mention them individually, but this applies to all. >> > I would handle it at the patch level by removing the old file and >> > creating the new one. >> It doesn't break quilt as the rename happens separately. Note that the >> patches were modified to refer to the old name. > It breaks 'make package/openssl/compile QUILT=1', because the 'mv' > command will never run when QUILT is not empty. You can't run the > 'mv' line with quilt because the patches are not applied in > Build/Prepare. However, you must ensure it is run later, or the > package will not compile with QUILT=1. I can point you to > openwrt/packages#14894 to see why you can't just skip running stuff > when QUILT is defined. I fully agree with Eneas here (though I don't like his patch for this issue either). Here's a way to fix this: include/package-defaults.mk has this: define Build/Prepare/Default $(PKG_UNPACK) [ ! -d ./src/ ] || $(CP) ./src/. $(PKG_BUILD_DIR) $(Build/Patch) endef You can adjust it to define this in the package Makefile: define Build/Prepare $(PKG_UNPACK) [ ! -d ./src/ ] || $(CP) ./src/. $(PKG_BUILD_DIR) mv $(PKG_BUILD_DIR)/crypto/engine/eng_devcrypto.c $(PKG_BUILD_DIR)/engines/e_devcrypto.c $(Build/Patch) endef - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
On 2021-03-26 09:55, Martin Schiller wrote: > On 2021-03-26 09:42, Felix Fietkau wrote: >> On 2021-03-26 09:34, Martin Schiller wrote: >>> On 2020-07-24 19:13, Felix Fietkau wrote: >>>> On 2020-07-24 18:44, Jo-Philipp Wich wrote: >>>>> Hi Felix, >>>>> >>>>>> [...] >>>>>> >>>>>> For a simple default config, you could have this: >>>>>> >>>>>> # network >>>>>> config device >>>>> option type bridge # I assume this is needed as well >>>>>> option name switch0 >>>> Correct. >>>> >>>>>> config bridge-vlan >>>>>> option vlan 1 >>>>>> option ports "lan1 lan2 lan3 lan4" >>>>>> >>>>>> config interface lan >>>>>> option ifname switch0.1 >>>>>> >>>>>> >>>>>> # wireless >>>>>> >>>>>> config wifi-iface >>>>>> option network lan >>>>>> >>>>>> >>>>>> In this case, wlan0 would be added to switch0 and set to VLAN 1 >>>>>> untagged >>>>>> by default. >>>>>> >>>>>> If you want it on VLAN 10 tagged/PVID instead, you could do: >>>>>> option network-vlan "10:t*" >>>>>> >>>>>> >>>>>> What do you think? >>>>> >>>>> I did think about it some more, also in context of a LuCI >>>>> implementation and >>>>> the special role of wifi and I am convinced now that this approach >>>>> generally >>>>> makes sense. >>>>> >>>>> However for the vlan I wonder if we should simply use "option vid >>>>> 10" >>>>> since >>>>> setting anything besides an egress untagged pvid does not make sense >>>>> for wifi. >>>> I think more complex VLAN settings make sense for WDS if you want to >>>> carry multiple networks over the link. >>>> >>>>> So your second example above would become: >>>>> >>>>> config wifi-iface >>>>> option network lan >>>>> option vid 10 # instead of inheriting vid 1, use 10 as pvid >>>>> >>>>> >>>>> Also, just to clarify... assuming a: >>>>> >>>>> config interface foo >>>>> option ifname somevlanbridge0.456 >>>>> >>>>> and an wifi iface without an explicit vid override: >>>>> >>>>> config wifi-iface >>>>> option network foo >>>>> >>>>> ... we would inherit vid 456 and set as pvid, right? Or are we are >>>>> always >>>>> going to default to 1? >>>> It would inherit 456 to keep it in sync with the VLAN based network. >>>> >>> >>> Is this functionality already integrated? >>> I am testing with a xrx200 based system with the DSA mainline driver >>> and >>> a wifi interface and have the problem that the wlan0 interface is >>> added >>> to the bridge switch0 but the bridge vlan configuration for the wlan0 >>> interface is not set. >> It's handled differently now. >> >> You can set lan's ifname to switch0.1 (without option type bridge) and >> use 'option network lan' in the wifi-iface. It will detect that the lan >> ifname is a vlan on top of a vlan-filtering bridge and will add wlan0 >> to >> switch0 and make it a member of lan's vlan. >> > > Hmmm... I think that's what I've alread done. Here is my config: > > network: > - > config interface 'lan' > option proto 'static' > option ipaddr '192.168.X.Y' > option netmask '255.255.255.0' > option ifname 'switch0.1' > > config device > option type 'bridge' > option name 'switch0' > list ifname 'lan1' > list ifname 'lan2' > list ifname 'lan3' > list ifname 'lan4' > > config bridge-vlan > option device 'switch0' > option vlan '1' > list ports 'lan1:u*' > list ports 'lan2:u*' > list ports 'lan3:u*' > list ports 'lan4:u*' > > wireless: > -- > config wifi-iface 'default_radio0' > option device 'radio0' > option mode 'ap' > option encryption 'psk2' > option ssid 'TETS-AP' > option network 'lan' > option key 'xxx' > option wpa_disable_eapol_key_retries '1' > > > Did I forget anything? Looks right to me. I'll see if I can find the time to reproduce this. You're using a recent version of OpenWrt, right? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
On 2021-03-26 09:34, Martin Schiller wrote: > On 2020-07-24 19:13, Felix Fietkau wrote: >> On 2020-07-24 18:44, Jo-Philipp Wich wrote: >>> Hi Felix, >>> >>>> [...] >>>> >>>> For a simple default config, you could have this: >>>> >>>> # network >>>> config device >>> option type bridge # I assume this is needed as well >>>>option name switch0 >> Correct. >> >>>> config bridge-vlan >>>>option vlan 1 >>>>option ports "lan1 lan2 lan3 lan4" >>>> >>>> config interface lan >>>>option ifname switch0.1 >>>> >>>> >>>> # wireless >>>> >>>> config wifi-iface >>>>option network lan >>>> >>>> >>>> In this case, wlan0 would be added to switch0 and set to VLAN 1 >>>> untagged >>>> by default. >>>> >>>> If you want it on VLAN 10 tagged/PVID instead, you could do: >>>>option network-vlan "10:t*" >>>> >>>> >>>> What do you think? >>> >>> I did think about it some more, also in context of a LuCI >>> implementation and >>> the special role of wifi and I am convinced now that this approach >>> generally >>> makes sense. >>> >>> However for the vlan I wonder if we should simply use "option vid 10" >>> since >>> setting anything besides an egress untagged pvid does not make sense >>> for wifi. >> I think more complex VLAN settings make sense for WDS if you want to >> carry multiple networks over the link. >> >>> So your second example above would become: >>> >>> config wifi-iface >>> option network lan >>> option vid 10 # instead of inheriting vid 1, use 10 as pvid >>> >>> >>> Also, just to clarify... assuming a: >>> >>> config interface foo >>> option ifname somevlanbridge0.456 >>> >>> and an wifi iface without an explicit vid override: >>> >>> config wifi-iface >>> option network foo >>> >>> ... we would inherit vid 456 and set as pvid, right? Or are we are >>> always >>> going to default to 1? >> It would inherit 456 to keep it in sync with the VLAN based network. >> > > Is this functionality already integrated? > I am testing with a xrx200 based system with the DSA mainline driver and > a wifi interface and have the problem that the wlan0 interface is added > to the bridge switch0 but the bridge vlan configuration for the wlan0 > interface is not set. It's handled differently now. You can set lan's ifname to switch0.1 (without option type bridge) and use 'option network lan' in the wifi-iface. It will detect that the lan ifname is a vlan on top of a vlan-filtering bridge and will add wlan0 to switch0 and make it a member of lan's vlan. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ubusd: convert tx_queue to linked list
On 2021-03-25 21:43, Arnout Vandecappelle wrote:
>
>
> On 25/03/2021 10:48, Felix Fietkau wrote:
>>
>> On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
>>> ubusd maintains a per-client tx_queue containing references to message
>>> buffers that have not been sent yet (due to the socket blocking). This
>>> is a fixed-size, 64-element queue.
>>>
>>> When more than 64 elements are queued, subsequent elements are simply
>>> dropped. Thus, a client that is waiting for those messages will block
>>> indefinitely. In particular, this happens when more than +- 250 objects
>>> are registered on the bus and either "ubus list" or "ubus wait_for" is
>>> called. The responses to these requests consist of a message buffer per
>>> object. Since in practice, ubusd will not yield between the sends of
>>> these message buffers, the client has no time to process them and
>>> eventually the output socket blocks. After 64 more objects, the rest is
>>> dropped, including the final message that indicates termination. Thus,
>>> the client waits indefinitely for the termination message.
>>>
>>> To solve this, turn the tx_queue into a variable-sized linked list
>>> instead of a fixed-size queue.
>> In order to reduce memory allocation overhead, I would propose the
>> following:
>>
>> struct ubus_msg_backlog {
>> struct ubus_msg_backlog *next;
>> struct ubus_msg_buf *msg[UBUSD_CLIENT_BACKLOG];
>> int tail;
>> };
>
> This saves space by open-coding a single-linked list rather than using the
> normal double-linked list. This comes at the cost of iterating over the entire
> list in order to append to it.
>
> It also saves space by dropping the offset member. But for that, we don't
> need
> to go to this extra structure.
>
> Applying those to "optimisations" to struct ubus_msg_buf_list would make that
> one 8 bytes (compared to 16 now). So that's 8 bytes per queued buffer, in
> addition to the 24 bytes of struct ubus_msg_buf and the actual buffer itself,
> which you can expect to be hundreds of bytes.
>
> struct ubus_msg_backlog is 24 bytes (assuming UBUSD_CLIENT_BACKLOG is 4),
> that's 6 bytes per element. So not much gained here. Increasing
> UBUSD_CLIENT_BACKLOG will decrease the overhead for large backlog, but gives a
> much bigger overhead for smaller backlog. So not a clear win.
UBUSD_CLIENT_BACKLOG is currently 32. I'm not so much counting bytes for
the optimization, I'm more interested in reducing the number of memory
allocations. This helps reduce memory allocator overhead and fragmentation.
> Finally, the backlog should normally be empty. It's pretty unusual for a ubus
> message to take more then one write to transfer.
>
> In conclusion:
> - I think your proposal doesn't save much;
> - and it complicates things quite a bit;
> - in addition, the single-linked list potentially poses significant time
> overhead.
With a reasonable upper limit for the maximum number of messages and the
current UBUSD_CLIENT_BACKLOG of 32, the time overhead for walking the
pointers is actually insignificant. If it ever becomes significant, we
can simply add a tail pointer to struct ubus_client and still save space.
I also expect it to be less than the malloc overhead for lots of
single-message list entries.
> If you want to save a few bytes, it does make sense to move the offset back
> to
> struct ubus_client.
>
> If you *really* want to save space, and time as well, it would be better to
> optimise ubusd_handle_lookup. That currently sends a separate, relatively
> small,
> message for every object. The overhead of the struct ubus_msg_buf dwarfs the
> overhead of struct ubus_msg_buf_list by quite a lot, and in addition there's
> overhead on the wire as well. It shouldn't be too hard to change
> ubus_lookup_cb
> to handle a list rather than a single object.
>
> Maybe I should have gone down that path. I hadn't thought of it at the time.
I think that's a good idea.
>>> The txq_off variable was used to keep track of which part of the current
>>> message was already written, in case only a partial write was possible.
>>> We take this opportunity to also move that variable under the
>>> ubus_msg_buf_list structure (and rename it to "offset", and change its
>>> type to size_t). This makes it clearer that it is related to that
>>> particular queued message and not to the queue as a whole.
>>>
>>> Note that this infinite tx_queue opens the door to a DoS attack. You can
>>> open a client and a server connection, then send messages from the
>
Re: [PATCH v2] ubusd: convert tx_queue to linked list
On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
> ubusd maintains a per-client tx_queue containing references to message
> buffers that have not been sent yet (due to the socket blocking). This
> is a fixed-size, 64-element queue.
>
> When more than 64 elements are queued, subsequent elements are simply
> dropped. Thus, a client that is waiting for those messages will block
> indefinitely. In particular, this happens when more than +- 250 objects
> are registered on the bus and either "ubus list" or "ubus wait_for" is
> called. The responses to these requests consist of a message buffer per
> object. Since in practice, ubusd will not yield between the sends of
> these message buffers, the client has no time to process them and
> eventually the output socket blocks. After 64 more objects, the rest is
> dropped, including the final message that indicates termination. Thus,
> the client waits indefinitely for the termination message.
>
> To solve this, turn the tx_queue into a variable-sized linked list
> instead of a fixed-size queue.
In order to reduce memory allocation overhead, I would propose the
following:
struct ubus_msg_backlog {
struct ubus_msg_backlog *next;
struct ubus_msg_buf *msg[UBUSD_CLIENT_BACKLOG];
int tail;
};
To struct ubus_client add these:
struct ubus_msg_backlog *backlog;
int backlog_head;
After sending messages from tx_queue, you pull in messages from
cl->backlog, incrementing backlog_head.
Once cl->backlog_head == backlog->tail, you set cl->backlog to
backlog->next and free backlog.
> To maintain the linked list, an additional structure ubus_msg_buf_list
> is created. We could also have added the linked list to the ubus_msg_buf
> struct itself, but it is not relevant in the many other uses of the
> ubus_msg_buf struct so it would just complicate things.
Adding the linked list to ubus_msg_buf doesn't work, because a single
message can be queued for multiple receivers. This mistake was already
made by previous attempts at introducing a linked list for messages.
> The txq_off variable was used to keep track of which part of the current
> message was already written, in case only a partial write was possible.
> We take this opportunity to also move that variable under the
> ubus_msg_buf_list structure (and rename it to "offset", and change its
> type to size_t). This makes it clearer that it is related to that
> particular queued message and not to the queue as a whole.
>
> Note that this infinite tx_queue opens the door to a DoS attack. You can
> open a client and a server connection, then send messages from the
> client to the server without ever reading anything on the server side.
> This will eventually lead to an out-of-memory. However, such a DoS
> already existed anyway, it just requires opening multiple server
> connections and filling up the fixed-size queue on each one. To protect
> against such DoS attacks, we'd need to:
I don't fully agree with your reasoning regarding the potential for DoS
attacks. It's true that the potential for *intentional* DoS attacks
exists in the current code already. What I'm worried about with this
patch is that you're adding extra potential for *accidental* DoS attacks
(i.e. excessive ubusd memory use for hanging processes receiving events).
> - keep a global maximum queue size that applies to all rx and tx queues
> together;
> - stop reading from any connection when the maximum is reached;
> - close any connection when it hasn't become writeable after some
> timeout.
I think we should have both a local and a global maximum queue size.
Other than that, I agree with the above.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gmp: compile with -DPIC to use correct asm code
On 2021-03-12 11:34, Stijn Tintel wrote: > On 11/03/2021 23:46, Eneas U de Queiroz wrote: >> The library is always compiled with $(FPIC) (-fPIC or -fpic), even for >> the static library. >> >> There are some assembly sources that decide whether or not to enable >> PIC code by checking if PIC is defined. It counts on libtool to define >> it, but libtool does it only when producing code for the dynamic >> library, while we need it for both. >> >> Ensure it is defined by adding it to CFLAGS next to $(FPIC). >> >> It avoids linking errors with strongswan on x86_64: >> >> ld: libgmp.a(bdiv_q_1.o): relocation R_X86_64_PC32 against symbol >> `__gmp_binvert_limb_table' can not be used when making a shared object; >> recompile with -fPIC >> >> Cc: Stijn Tintel >> Signed-off-by: Eneas U de Queiroz >> --- >> >> There's an error on one architecture, and all others work fine without >> this, so I'm uneasy changing this and then breaking stuff that was >> working fine otherwise. However, it feels wrong to me to generate PIC >> code from C files, but not use it in asm sources, which is essentially >> what I am changing here. >> >> I've looked at asm sources for different chitectures, and there are >> checks for PIC in: arm64, arm, x86_64, x86, and ppc asm sources, but the >> error only appears on x86_64. >> >> For most CPUs, ifdef(`PIC'), is just used to do different definitions of >> LEA (Load Effective Address). However, both x86 and x86_64 have many >> other checks. >> >> I've looked at bdiv_q_1.asm for different CPUs, and they all do some >> form of LEA(binvert_limb_table), except for x86, where it will do it >> only when PIC is defined. That may explain why x86_64 is affected, and >> x86 is not. >> >> I have not investigated further details. >> >> Alternatively, we can define it only for x86_64, which is where we know >> there's a build failure with the linker asking to recompile with -fPIC. >> > I'm sorry, but I lack the knowledge to review this. I think the patch makes sense and -DPIC should be used along with -fPIC. I don't see any reason to make it x86_64 specific. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
