Re: GitHub Actions usage on OpenWRT/LEDE main/master
Il giorno lun 26 giu 2023 alle ore 19:10 Stefan Kalscheuer via openwrt-devel ha scritto: > > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. > > > -- Forwarded message -- > From: Stefan Kalscheuer > To: openwrt-devel@lists.openwrt.org > Cc: > Bcc: > Date: Mon, 26 Jun 2023 19:07:25 +0200 > Subject: GitHub Actions usage on OpenWRT/LEDE main/master > Hi all, > > I don't know if that topic ever came up yet, but I stumbled across it > recently. > > TL;DR: > > Is there really a point in running GH actions 4 times on both main and > master branch and both OpenWRT and LEDE org repositories or should we > consider being little more economic with the resources, e.g. by > disabling the actions on the mirror and/or the master branch? > > > Little more background: > > The default branch was renamed from "master" to "main" with a sync to > "master" for backwards compatibility. The git repo is mirrored to GitHub > in the OpenWRT org ( https://github.com/openwrt/openwrt ) and also to > the LEDE org ( https://github.com/lede-project/source ). > > Then we have quite elaborate CI workflows using GitHub Actions which can > trigger up to ~450 jobs (~200 build jobs plus setup/caching stuff) which > take around 2 hours to complete (e.g. on current top commit 539cb53). > That's totally reasonable considering the impact of the changes made. > There are smaller changes that might just trigger 10 and run 5min. > > Every aspect of this probably fine for itself, but when it all comes > together... > The GH actions are triggered in all repos named on all branches, so we > trigger all this at least 4 times (actually just ~3 times, as most > pipelines are failing on the LEDE mirror) > master is already excluded and ignored. Totally unaware LEDE mirror has actions enabled... For me that should be just disabled and the entire thing is archived. But I don't have access to that. > I don't see a real benefit running all this stuff 4 times. Beside the > eco aspect, that simply utilizes quite a few runners, so a new/updated > PR sometimes takes an hour before the tasks get picked up and start running. > Can we list the 4 times? - Currently it's on openwrt one per pr and when a push is done. - Also in LEDE mirror, it's again one So it's 2 that should be reduced to 1. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: typo in module config
Il giorno ven 23 giu 2023 alle ore 15:58 Koen Vandeputte ha scritto: > > Hi Yousong, > > By reading some mk files I noticed your commit: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4f443c885dede3331b969e6265a41a0ff1e3059a > > within netfilter.mk: > > +define KernelPackage/nf-socket > .. > + KCONFIG:= $(KCOFNIG_NF_SOCKET) > > +define KernelPackage/nf-tproxy > .. > + KCONFIG:= $(KCOFNIG_NF_TPROXY) > > > Looks like it contains 2 typos? :) --> KCOFNIG > I can quickly fix them... Do you know by chance if also 23.05 is also affected? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Intention on moving board-2 blob to a separate repo
Hi, there is an idea of moving board-2 blob to a separate repo. It seems ath10k chance of getting board-2 blob merged upstream is becoming almost impossible. Result is that the board-2 blob number is growing and some are complaining that these are bloating openwrt repo. As said in the intro, there is this idea of moving each board-2 blob to a separate repo and providing them by downloading the board file directly from the separate repo. Anyone against this? Things still needs to be defined but would be good to have some feedback. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Internal Server Error on subscribing to mailing list
Hi, I got some report that user can't subscribe to the devel mailing list and the page return Internal Server Error I confirmed that with a secondary email. Can someone check it? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC] CI: add tag on failed tests
I wonder if it would be a good idea to introduce tag like 'Formal-Error', 'Broken-ath79' that gets applied on test failing by our github actions test. Would be good to quickly identify problems without checking what is actually failing. Also would be good for the user as he can quickly identify the problem. What do you think about this idea? We have already an intention of writing comments for the AUTORELEASE deprecation generated by the tests so it could be a nice idea to use a similar implementation to add tags. (or even text for formal errors) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Add SoB tag to hack patches on generic target
Hi, we are trying to improve the situation about the hack patch for the generic target. Currently it's a mess... no header, extra old patch not needed, patch with no sob tag. Some user [1] are trying to improve the situation and checked all the changes done to a specific patch and added the related SoB tag. I have some concern about adding arbitrary SoB tag without clear permission of the developer. So I'm asking here for some feedback/ideas on how to solve this and eventually for permission for adding the SoB tag. Can we assume that the one that made the change also take responsibility for the patch? (following this rule, we should be able to add the SoB and merge the proposed changes) For reference there is also this issue to track hack patch [2] and this pr that also tried to fix other hack patch about the topic. [3] [1] https://github.com/openwrt/openwrt/pull/10769 [2] https://github.com/openwrt/openwrt/issues/10272 [3] https://github.com/openwrt/openwrt/pull/10264 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Question about ancient TARGET_CFLAGS in rules.mk?
Hi, some background about this. I'm trying to improve our CI system more and more by finally adding support for real EXTERNAL_TOOLCHAIN_SUPPORT... I'm running (and abusing) the github CI to make sure everything works and all compiles correctly... While testing it I notice a specific target fails to compile ubox package. While still to investigate why this is only present on that target, i found out why this happen with EXTERNAL_TOOLCHAIN and doesn't fail on a normal build. The error is this kmodloader.c: In function 'main_loader': 1339kmodloader.c:1027:41: error: ignoring return value of 'asprintf' declared with attribute 'warn_unused_result' [-Werror=unused-result] 1340make[1]: *** [package/Makefile:116: package/system/ubox/compile] Error 1 1341 1027 | asprintf(&m->opts, "%s %s", prev, opts); 1342 | ^~~ 1343cc1: all warnings being treated as errors The package is compiled with -Wall so it does make sense that the error is printed... Fact is that the error(warning) is actually correct but I couldn't understand why it was not flagged on normal build and here the reason... In rules.mk we have TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result and this is only applied if EXTERNAL_TOOLCHAIN is not selected... Now the question... WHY? Considering even the linux kernel started to use Wall by default, should we also start enforcing correct code and fix every package that present such error? Fixing these kind of error is trivial enough and IMHO we should drop these warning disable. I will create a PR in the next few days but wonder if anyone wants to give some feedback about why these extra flags are set. To me it seems they are just leftover from older times? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Moving ipq-wifi to a dedicated repo
As the title said, it was suggested to move the ipq-wifi package board file to a separate repo. The problem is that we currently ship many board file with the openwrt git repo and we always download them. These won't change that much (or probably forever) and so shipping them and downloading them by default seems to be wasted space for other target that don't use it. I wonder if a better approach would be move these special board file to a dedicated repo and make the ipq-wifi Makefile to just clone the repo. I'm asking for feedback if this would make sense or it not worth it and would result in added complexity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Testing network / NAT performance
Il giorno ven 17 giu 2022 alle ore 13:51 Hauke Mehrtens
ha scritto:
>
> Hi Rafal,
>
> Thank you for your detailed analyses and also for the detailed report.
> This is very helpful when I ran into this problem.
>
> Can we somehow automate it so that we get notified a day after a bad
> change was committed about performance regression and not one year after?
>
> On 6/14/22 15:16, Rafał Miłecki wrote:
> > On 12.06.2022 21:58, Rafał Miłecki wrote:
> >> 5. 7125323b81d7 ("bcm53xx: switch to kernel 5.4")
> >>
> >> Improved network speed by 25% (256 Mb/s → 320 Mb/s).
> >>
> >> I didn't have time to bisect this *improvement* to a single kernel
> >> commit. I tried profiling but it isn't obvious to me what caused that
> >> improvement.
> >>
> >> Kernel 4.19:
> >> 11.94% ksoftirqd/0 [kernel.kallsyms] [k]
> >> v7_dma_inv_range
> >> 7.06% ksoftirqd/0 [kernel.kallsyms] [k]
> >> l2c210_inv_range
> >> 3.37% ksoftirqd/0 [kernel.kallsyms] [k]
> >> v7_dma_clean_range
> >> 2.80% ksoftirqd/0 [kernel.kallsyms] [k]
> >> l2c210_clean_range
> >> 2.67% ksoftirqd/0 [kernel.kallsyms] [k] bgmac_poll
> >> 2.63% ksoftirqd/0 [kernel.kallsyms] [k]
> >> __dev_queue_xmit
> >> 2.43% ksoftirqd/0 [kernel.kallsyms] [k]
> >> __netif_receive_skb_core
> >> 2.13% ksoftirqd/0 [kernel.kallsyms] [k]
> >> bgmac_start_xmit
> >> 1.82% ksoftirqd/0 [kernel.kallsyms] [k] nf_hook_slow
> >> 1.54% ksoftirqd/0 [kernel.kallsyms] [k] ip_forward
> >> 1.50% ksoftirqd/0 [kernel.kallsyms] [k]
> >> dma_cache_maint_page
> >>
> >> Kernel 5.4:
> >> 14.53% ksoftirqd/0 [kernel.kallsyms] [k]
> >> v7_dma_inv_range
> >> 8.02% ksoftirqd/0 [kernel.kallsyms] [k]
> >> l2c210_inv_range
> >> 3.32% ksoftirqd/0 [kernel.kallsyms] [k] bgmac_poll
> >> 3.28% ksoftirqd/0 [kernel.kallsyms] [k]
> >> v7_dma_clean_range
> >> 3.12% ksoftirqd/0 [kernel.kallsyms] [k]
> >> __netif_receive_skb_core
> >> 2.70% ksoftirqd/0 [kernel.kallsyms] [k]
> >> l2c210_clean_range
> >> 2.46% ksoftirqd/0 [kernel.kallsyms] [k]
> >> __dev_queue_xmit
> >> 2.26% ksoftirqd/0 [kernel.kallsyms] [k]
> >> bgmac_start_xmit
> >> 1.73% ksoftirqd/0 [kernel.kallsyms] [k]
> >> __dma_page_dev_to_cpu
> >> 1.72% ksoftirqd/0 [kernel.kallsyms] [k] nf_hook_slow
> >
> > Riddle solved. Change to bless/blame: 4e0c54bc5bc8 ("kernel: add support
> > for kernel 5.4").
> >
> > First of all bcm53xx uses
> > CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> >
> >
> > OpenWrt's kernel Makefile in kernel 4.19:
> >
> > ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> > KBUILD_CFLAGS+= -Os $(EXTRA_OPTIMIZATION)
> > else
> > KBUILD_CFLAGS += -O2 -fno-reorder-blocks -fno-tree-ch
> > $(EXTRA_OPTIMIZATION)
> > endif
> >
> >
> > OpenWrt's kernel Makefile in 5.4:
> >
> > ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
> > KBUILD_CFLAGS += -O2 $(EXTRA_OPTIMIZATION)
> > else ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3
> > KBUILD_CFLAGS += -O3 $(EXTRA_OPTIMIZATION)
> > else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> > KBUILD_CFLAGS += -Os -fno-reorder-blocks -fno-tree-ch $(EXTRA_OPTIMIZATION)
> > endif
> >
> >
> > As you can see 4e0c54bc5bc8 has accidentally moved -fno-reorder-blocks
> > from !CONFIG_CC_OPTIMIZE_FOR_SIZE to CONFIG_CC_OPTIMIZE_FOR_SIZE.
>
> This looks like an accident to me.
> All targets except mediatek/mt7629 are setting
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE in master. In Openwrt 21.02 the
> ARCHS38 target set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, but now it is
> also to normal performance.
>
> We should probably switch mediatek/mt7629 to
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE, does anyone have such a device and
> could test a patch?
>
> > I've noticed problem with -fno-reorder-blocks long time ago, see:
> > [PATCH RFC] kernel: drop -fno-reorder-blocks
> > https://patchwork.ozlabs.org/project/openwrt/patch/20190409093046.13401-1-zaj...@gmail.com/
> >
> >
> > It should really get sorted out...
>
> I would suggest to remove the -fno-reorder-blocks -fno-tree-ch options
> as they are not used.
>
>
> The next step could be Profile-guided optimization:
> https://lwn.net/Articles/830300/
> If the toolchain works properly I expect there big improvements as
> routing, forwarding and NAT is completely in the kernel and we use
> devices with small caches. Profile-guided optimization should be able to
> avoid many cache misses by better packaging the binary.
>
PGO would be a dream to accomplish but it's a nightmare to actually use it.
The kernel size grow a lot and it needs to be done correctly...
Also AFAIK it's not that easy to add support for it and it's
problematic for some
device to generate the profile data.
> Hauke
>
> ___
> openwrt-devel mailing list
> openwrt
Enforce Signed-off-by for pr from Github web interface
Github introduced a new option to enforce user that submit pr from the Github web interface to include a Signed-off-by tag. While probably 99% a pr generated from the Github web interface is wrong and will require additional changes, at least alert the user that he is not doing something right and to recheck. Hoping this will prevent such a case, I have enabled the option. This is the article [1] on how it does work. [1] https://github.blog/changelog/2022-06-08-admins-can-require-sign-off-on-web-based-commits/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Wrong hash for firewall package?
I notice that firewall hash is different for firewall package The one we have is 307baf09c61ce727b4edb4283144b0d8128ebba34b858cc6389571421f829a24 but the correct one is ce9e8ac1bcf22afbb0a80c3da1a8e8e887851299681097e3dfbfc347f2c4c80f Did someone force pushed something to the firewall git or the hash was just wrong? Looks strange to me. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[rpcd PATCH] iwinfo: fix compilation error with GCC 12
From: Christian 'Ansuel' Marangi Fix compilation error with GCC 12. In file included from /home/ansuel/openwrt/staging_dir/target-aarch64_cortex-a53_musl/usr/include/libubus.h:23, from iwinfo.c:21: In function 'blobmsg_close_array', inlined from 'rpc_iwinfo_assoclist' at iwinfo.c:643:3: /home/ansuel/openwrt/staging_dir/target-aarch64_cortex-a53_musl/usr/include/libubox/blobmsg.h:250:9: error: 'c' may be used uninitialized [-Werror=maybe-uninitialized] 250 | blob_nest_end(buf, cookie); | ^~ iwinfo.c: In function 'rpc_iwinfo_assoclist': iwinfo.c:564:15: note: 'c' was declared here 564 | void *c, *d, *e; | ^ cc1: all warnings being treated as errors ninja: build stopped: subcommand failed. Signed-off-by: Christian 'Ansuel' Marangi --- iwinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/iwinfo.c b/iwinfo.c index 6c0319e..38484c8 100644 --- a/iwinfo.c +++ b/iwinfo.c @@ -561,7 +561,7 @@ rpc_iwinfo_assoclist(struct ubus_context *ctx, struct ubus_object *obj, char res[IWINFO_BUFSIZE]; struct iwinfo_assoclist_entry *a; struct ether_addr *macaddr = NULL; - void *c, *d, *e; + void *c = NULL, *d, *e; struct blob_attr *tb[__RPC_A_MAX]; bool found = false; -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC/RFT] ath10k: use xmit encapsulation offloading
Il giorno gio 19 mag 2022 alle ore 01:17 Edward Matijevic ha scritto: > > Reporting an issue running these patches with the ath10k-ct driver > from OpenWrt 22.03-rc1 crashing repeatedly on my IPQ8064+QCA9980 > router > The patches only require an edit to the file locations to the > directory ath10k-5.15/ and the offsets apply without issue > Below is a log from the hardware crashing repeatedly, only lines > removed included MACs > > ieee80211 phy0: Hardware restart was requested > ath10k_pci :01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 > ath10k_pci :01:00.0: msdu-desc: 2500 skid: 32 > ath10k_pci :01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 > msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' > ath10k_pci :01:00.0: wmi print 'free: 31080 iram: 23028 sram: 9596' > ath10k_pci :01:00.0: rts threshold -1 > ath10k_pci :01:00.0: Firmware lacks feature flag indicating a > retry limit of > 2 is OK, requested limit: 4 > ath10k_pci :01:00.0: device successfully recovered > ath10k_pci :01:00.0: firmware crashed! (guid > dacbb411-7d89-4a0b-b4a8-1e25f10d9838) > ath10k_pci :01:00.0: qca99x0 hw2.0 target 0x0100 chip_id > 0x003b01ff sub 168c:0002 > ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0 > ath10k_pci :01:00.0: firmware ver 10.4b-ct-9980-fW-13-5ae337bb1 > api 5 features > mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT > crc32 b36a12bf > ath10k_pci :01:00.0: board_file api 2 bmi_id 1:1 crc32 e4a0f655 > ath10k_pci :01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal > pre-cal-nvmem max-sta 32 raw 0 hwcrypto 1 > ath10k_pci :01:00.0: firmware register dump: > ath10k_pci :01:00.0: [00]: 0x0009 0x 0x0098C64F 0x > ath10k_pci :01:00.0: [04]: 0x 0x00060124 0x 0x > ath10k_pci :01:00.0: [08]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [12]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [16]: 0x009BFE03 0x009C0489 0x0097F8C6 0x0098C64F > ath10k_pci :01:00.0: [20]: 0x 0x00401C20 0x 0x > ath10k_pci :01:00.0: [24]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [28]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [32]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [36]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [40]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [44]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [48]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [52]: 0x 0x 0x 0x > ath10k_pci :01:00.0: [56]: 0x 0x 0x 0x > ath10k_pci :01:00.0: Copy Engine register dump: > ath10k_pci :01:00.0: [00]: 0x0004a000 0 0 3 3 > ath10k_pci :01:00.0: [01]: 0x0004a400 3 3 73 74 > ath10k_pci :01:00.0: [02]: 0x0004a800 51 51 50 51 > ath10k_pci :01:00.0: [03]: 0x0004ac00 29 29 1 29 > ath10k_pci :01:00.0: [04]: 0x0004b000 23 23 52 14 > ath10k_pci :01:00.0: [05]: 0x0004b400 22 22 53 54 > ath10k_pci :01:00.0: [06]: 0x0004b800 8 8 8 8 > ath10k_pci :01:00.0: [07]: 0x0004bc00 1 1 1 1 > ath10k_pci :01:00.0: [08]: 0x0004c000 0 0 127 0 > ath10k_pci :01:00.0: [09]: 0x0004c400 1 1 1 1 > ath10k_pci :01:00.0: [10]: 0x0004c800 0 0 0 0 > ath10k_pci :01:00.0: [11]: 0x0004cc00 0 0 0 0 > ath10k_pci :01:00.0: debug log header, dbuf: 0x4197f8 dropped: 0 > ath10k_pci :01:00.0: [0] next: 0x4197e0 buf: 0x4158b0 sz: 1500 > len: 0 count: 0 free: 0 > ath10k_pci :01:00.0: [1] next: 0x4197f8 buf: 0x4152c0 sz: 1500 > len: 0 count: 0 free: 0 > There should be a beta firmware with the crash fixed... But anyway the ct firmware doesn't work with offload and this is the main reason i never actually put effort in getting this merged. Openwrt use ath10k-ct and offload doesn't work, the dev didn't bother to fix it so rip any use of this since the original ath10k is not usable for some user. > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] generic: 5.15: fix panic on tcp_no_window_check set with interface up
The current reworked version cause kernel panic when the value is changes and
an interface is up. Following the tcp_be_liberal impelementation,
reimplement this to permit a safe change of this value without any
panic.
This has been tested with a QSDK package where tcp_no_window_check is used.
Fixes: 92fb51bc9881 ("generic: 5.15: standardize tcp_no_window_check pending
patch")
Signed-off-by: Christian 'Ansuel' Marangi
---
...-netfilter_optional_tcp_window_check.patch | 82 ++-
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git
a/target/linux/generic/pending-5.15/613-netfilter_optional_tcp_window_check.patch
b/target/linux/generic/pending-5.15/613-netfilter_optional_tcp_window_check.patch
index b9919ae4..1ddfc8e0 100644
---
a/target/linux/generic/pending-5.15/613-netfilter_optional_tcp_window_check.patch
+++
b/target/linux/generic/pending-5.15/613-netfilter_optional_tcp_window_check.patch
@@ -2,6 +2,7 @@ From: Felix Fietkau
Subject: netfilter: optional tcp window check
Signed-off-by: Felix Fietkau
+Signed-off-by: Christian 'Ansuel' Marangi
---
net/netfilter/nf_conntrack_proto_tcp.c | 13 +
1 file changed, 13 insertions(+)
@@ -12,68 +13,71 @@ Signed-off-by: Felix Fietkau
s32 receiver_offset;
bool res, in_recv_win;
-+ if (net->ct.sysctl_no_window_check)
++ if (tn->tcp_no_window_check)
+ return true;
+
/*
* Get the required data from the packet.
*/
-@@ -1160,7 +1163,7 @@ int nf_conntrack_tcp_packet(struct nf_co
+@@ -1151,7 +1154,7 @@ int nf_conntrack_tcp_packet(struct nf_co
IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
timeout = timeouts[TCP_CONNTRACK_UNACK];
- else if (ct->proto.tcp.last_win == 0 &&
-+ else if (!net->ct.sysctl_no_window_check && ct->proto.tcp.last_win == 0
&&
++ else if (!tn->tcp_no_window_check && ct->proto.tcp.last_win == 0 &&
timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
timeout = timeouts[TCP_CONNTRACK_RETRANS];
else
+@@ -1451,6 +1454,9 @@ int nf_conntrack_tcp_packet(struct nf_co
+* If it's non-zero, we mark only out of window RST segments as INVALID.
+*/
+ tn->tcp_be_liberal = 0;
++
++ /* Skip Windows Check */
++ tn->tcp_no_window_check = 0;
+
+ /* If it's non-zero, we turn off RST sequence number check */
+ tn->tcp_ignore_invalid_rst = 0;
--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -671,6 +671,7 @@ enum nf_ct_sysctl_index {
- NF_SYSCTL_CT_LWTUNNEL,
#endif
-
+ NF_SYSCTL_CT_PROTO_TCP_LOOSE,
+ NF_SYSCTL_CT_PROTO_TCP_LIBERAL,
+ NF_SYSCTL_CT_PROTO_TCP_NO_WINDOW_CHECK,
- __NF_SYSCTL_CT_LAST_SYSCTL,
- };
-
-@@ -1026,6 +1027,13 @@ static struct ctl_table nf_ct_sysctl_tab
- .proc_handler = nf_hooks_lwtunnel_sysctl_handler,
+ NF_SYSCTL_CT_PROTO_TCP_IGNORE_INVALID_RST,
+ NF_SYSCTL_CT_PROTO_TCP_MAX_RETRANS,
+ NF_SYSCTL_CT_PROTO_TIMEOUT_UDP,
+@@ -800,6 +800,14 @@ static struct ctl_table nf_ct_sysctl_tab
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
},
- #endif
+ [NF_SYSCTL_CT_PROTO_TCP_NO_WINDOW_CHECK] = {
+ .procname = "nf_conntrack_tcp_no_window_check",
-+ .data = &init_net.ct.sysctl_no_window_check,
-+ .maxlen = sizeof(unsigned int),
++ .maxlen = sizeof(u8),
+ .mode = 0644,
-+ .proc_handler = proc_dointvec,
++ .proc_handler = proc_dou8vec_minmax,
++ .extra1 = SYSCTL_ZERO,
++ .extra2 = SYSCTL_ONE,
+ },
- {}
- };
+ [NF_SYSCTL_CT_PROTO_TCP_IGNORE_INVALID_RST] = {
+ .procname = "nf_conntrack_tcp_ignore_invalid_rst",
+ .maxlen = sizeof(u8),
+@@ -900,6 +900,7 @@ static int nf_conntrack_standalone_init_
-@@ -1153,6 +1161,7 @@ static int nf_conntrack_standalone_init_
- #ifdef CONFIG_NF_CONNTRACK_EVENTS
- table[NF_SYSCTL_CT_EVENTS].data = &net->ct.sysctl_events;
- #endif
-+ table[NF_SYSCTL_CT_PROTO_TCP_NO_WINDOW_CHECK].data =
&net->ct.sysctl_no_window_check;
- #ifdef CONFIG_NF_CONNTRACK_TIMESTAMP
- table[NF_SYSCTL_CT_TIMESTAMP].data = &net->ct.sysctl_tstamp;
- #endif
-@@ -1222,6 +1231,7 @@ static int nf_conntrack_pernet_init(stru
- int ret;
-
- net->ct.sysctl_checksum = 1;
-+ net->ct.sysctl_no_window_check = 1;
-
- ret = nf_conntrack_standalone_init_sysctl(net);
- if (ret < 0)
+ XASSIGN(LOOSE, &tn->tcp_loose);
+ XASSIGN(LIBERAL, &tn->tcp_be_liberal);
++ XASSIGN(NO_WINDOW_CHECK, &tn->tcp_no_window_check);
+ XASSIGN(MAX_RETRANS, &tn->tcp_max_retrans);
+ XASSIGN(IGNORE_INVALID_RST, &
Clarification about board.json and sysinfo
I'm checking files that are created on a clean system with initramfs and I'm a bit confused about 2 files I notice that for preinit we create board.json in /tmp but we have the same file in /etc/board.json... Considering that /tmp/board.json comes from 10_indicate_preinit and the file is used just to get an ip and send the packet with Openwrt alerting the preinit state and considering this is called before mount_root. Can't we generate / ship the board.json directly in /etc and load it from rom instead of /tmp? Or is it mandatory to run on a loaded system? Looking at the files from board.d most of them are static and the only relevant part needed from a loaded system is the 99-default_network with the eth1 check. To me it looks like this can be handled differently considering it's all done before rootfs is mounted so we already know the state of the system and it is always the same. The other concern is the sysinfo file... I assume sysinfo was created before board.json. Thing is they contain the same value. sysinfo create from 02_sysinfo a directory in /tmp and puts the model and the device id in some files... Values that are already present in board.json... (and that they are static so I can't understand why they are created in the first place... Can't we use a function in functions.sh to get the data directly?) So I wonder if anyone have some info about these 2 thing and if they are used by other package. To me it looks like they are leftover from an old implementation that is now deprecated. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] libnetfilter-conntrack: backport patch fixing compilation with 5.15
Il giorno mer 2 mar 2022 alle ore 15:43 Robert Marko ha scritto: > > On Wed, 2 Mar 2022 at 15:40, Ansuel Smith wrote: > > > > Backport patch fixing compilation with 5.15 and musl provided by Robert > > Marko > > I would prefer just bumping the package version using GIT hash since > its already upstreamed. > > Regards > > Don't know we use versioning with every netfilter package. I think for this kind of package we use patches and we drop them on the version bump. The patch is from the upstream netfilter git. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] libnetfilter-conntrack: backport patch fixing compilation with 5.15
Backport patch fixing compilation with 5.15 and musl provided by Robert Marko
Signed-off-by: Ansuel Smith
---
package/libs/libnetfilter-conntrack/Makefile | 2 +-
...-fix-build-with-kernel-5_15-and-musl.patch | 56 +++
2 files changed, 57 insertions(+), 1 deletion(-)
create mode 100644
package/libs/libnetfilter-conntrack/patches/0001-conntrack-fix-build-with-kernel-5_15-and-musl.patch
diff --git a/package/libs/libnetfilter-conntrack/Makefile
b/package/libs/libnetfilter-conntrack/Makefile
index 0cfb19f1..50432e9c 100644
--- a/package/libs/libnetfilter-conntrack/Makefile
+++ b/package/libs/libnetfilter-conntrack/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=libnetfilter_conntrack
PKG_VERSION:=1.0.9
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=https://www.netfilter.org/projects/libnetfilter_conntrack/files
diff --git
a/package/libs/libnetfilter-conntrack/patches/0001-conntrack-fix-build-with-kernel-5_15-and-musl.patch
b/package/libs/libnetfilter-conntrack/patches/0001-conntrack-fix-build-with-kernel-5_15-and-musl.patch
new file mode 100644
index ..e21d5da5
--- /dev/null
+++
b/package/libs/libnetfilter-conntrack/patches/0001-conntrack-fix-build-with-kernel-5_15-and-musl.patch
@@ -0,0 +1,56 @@
+From 21ee35dde73aec5eba35290587d479218c6dd824 Mon Sep 17 00:00:00 2001
+From: Robert Marko
+Date: Thu, 24 Feb 2022 15:01:11 +0100
+Subject: conntrack: fix build with kernel 5.15 and musl
+
+Currently, with kernel 5.15 headers and musl building is failing with
+redefinition errors due to a conflict between the kernel and musl headers.
+
+Musl is able to suppres the conflicting kernel header definitions if they
+are included after the standard libc ones, however since ICMP definitions
+were moved into a separate internal header to avoid duplication this has
+stopped working and is breaking the builds.
+
+It seems that the issue is that which contains the UAPI
+suppression defines is included in the internal.h header and not in the
+proto.h which actually includes the kernel ICMP headers and thus UAPI
+supression defines are not present.
+
+Solve this by moving the include before the ICMP kernel
+includes in the proto.h
+
+Fixes: bc1cb4b11403 ("conntrack: Move icmp request>reply type mapping to
common file")
+Signed-off-by: Robert Marko
+Signed-off-by: Florian Westphal
+---
+ include/internal/internal.h | 1 -
+ include/internal/proto.h| 1 +
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/internal/internal.h b/include/internal/internal.h
+index 2ef8a90..7cd7c44 100644
+--- a/include/internal/internal.h
b/include/internal/internal.h
+@@ -14,7 +14,6 @@
+ #include
+ #include
+ #include
+-#include
+
+ #include
+ #include
+diff --git a/include/internal/proto.h b/include/internal/proto.h
+index 40e7bfe..60a5f4e 100644
+--- a/include/internal/proto.h
b/include/internal/proto.h
+@@ -2,6 +2,7 @@
+ #define _NFCT_PROTO_H_
+
+ #include
++#include
+ #include
+ #include
+
+--
+cgit v1.2.3
+
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/6] tools/dwarves: add host package
> > On 27/02/2022 17:20, Ansuel Smith wrote: > > > > >> From: Tony Ambardar > >> > >> dwarves is a set of tools that use the debugging information inserted in > >> ELF binaries by compilers such as GCC. Utilities in the dwarves suite > >> include pahole, which can be used to find alignment holes in structs and > >> classes, and also extracts other information such as CPU cacheline > >> alignment, helping pack those structures to achieve more cache hits. > >> > >> These tools are also used to encode and read the BTF type information > >> format used with the bpf syscall, making this a Linux build dependency > >> when using kernel BTF information. > > BTW this fails to build if libdw-dev is not installed with > > > > -- Checking availability of DWARF and ELF development libraries > > -- Could NOT find dwarf include dir > > -- Could NOT find libdw include dir > > -- Could NOT find libdw library > > CMake Error at cmake/modules/FindDWARF.cmake:93 (message): > > Could NOT find some ELF and DWARF libraries, please install the missing > > packages > > Call Stack (most recent call first): > > CMakeLists.txt:60 (find_package) > > > > ERROR: tools/dwarves failed to build. > > > > Should we add it to the build prereq? > > Please try this instead: > > diff --git a/tools/dwarves/Makefile b/tools/dwarves/Makefile > index b02a2398a1..e5a55706be 100644 > --- a/tools/dwarves/Makefile > +++ b/tools/dwarves/Makefile > @@ -12,14 +12,12 @@PKG_LICENSE:=GPL-2.0-only > PKG_LICENSE_FILES:=COPYING > > HOST_BUILD_PARALLEL:=1 > +PKG_BUILD_DEPENDS:=elfutils/host > > include $(INCLUDE_DIR)/host-build.mk > include $(INCLUDE_DIR)/cmake.mk > > CMAKE_HOST_OPTIONS += \ > - -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=BOTH \ > - -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=BOTH \ > - -DCMAKE_BUILD_TYPE=Release \ >-D__LIB=lib \ >-DCMAKE_INSTALL_RPATH="$(STAGING_DIR_HOST)/lib" \ >-DCMAKE_SKIP_RPATH=FALSE > > Thanks, > Stijn > No luck... still make[3]: Leaving directory '/home/ansuel/openwrt/tools/missing-macros' time: tools/missing-macros/compile#0.09#0.06#0.12 -- The C compiler identification is GNU 11.2.0 -- Detecting C compiler ABI info make[3]: Leaving directory '/home/ansuel/openwrt/tools/automake' time: tools/automake/compile#0.14#0.44#0.51 make[3]: Entering directory '/home/ansuel/openwrt/tools/libtool' make[3]: Entering directory '/home/ansuel/openwrt/tools/dosfstools' make[3]: Leaving directory '/home/ansuel/openwrt/tools/dosfstools' time: tools/dosfstools/compile#0.13#0.17#0.25 -- Detecting C compiler ABI info - done -- Check for working C compiler: /home/ansuel/openwrt/staging_dir/host/bin/gcc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Setting BUILD_SHARED_LIBS = ON make[3]: Leaving directory '/home/ansuel/openwrt/tools/libtool' -- Checking availability of DWARF and ELF development libraries time: tools/libtool/compile#0.15#0.27#0.34 -- Could NOT find dwarf include dir -- Could NOT find libdw include dir -- Could NOT find libdw library -- Could NOT find libelf library CMake Error at cmake/modules/FindDWARF.cmake:93 (message): Could NOT find some ELF and DWARF libraries, please install the missing packages Call Stack (most recent call first): CMakeLists.txt:60 (find_package) -- Configuring incomplete, errors occurred! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/6] tools/dwarves: add host package
>
> From: Tony Ambardar
>
> dwarves is a set of tools that use the debugging information inserted in
> ELF binaries by compilers such as GCC. Utilities in the dwarves suite
> include pahole, which can be used to find alignment holes in structs and
> classes, and also extracts other information such as CPU cacheline
> alignment, helping pack those structures to achieve more cache hits.
>
> These tools are also used to encode and read the BTF type information
> format used with the bpf syscall, making this a Linux build dependency
> when using kernel BTF information.
BTW this fails to build if libdw-dev is not installed with
-- Checking availability of DWARF and ELF development libraries
-- Could NOT find dwarf include dir
-- Could NOT find libdw include dir
-- Could NOT find libdw library
CMake Error at cmake/modules/FindDWARF.cmake:93 (message):
Could NOT find some ELF and DWARF libraries, please install the missing
packages
Call Stack (most recent call first):
CMakeLists.txt:60 (find_package)
ERROR: tools/dwarves failed to build.
Should we add it to the build prereq?
>
> Signed-off-by: Tony Ambardar
> Signed-off-by: Felix Fietkau
> [bump to 1.23]
> Signed-off-by: Stijn Tintel
> ---
> toolchain/Config.in| 8
> tools/Makefile | 1 +
> tools/dwarves/Makefile | 38 ++
> 3 files changed, 47 insertions(+)
> create mode 100644 tools/dwarves/Makefile
>
> diff --git a/toolchain/Config.in b/toolchain/Config.in
> index 366f5c8b48..fb14006055 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -247,6 +247,14 @@ comment "Binary tools"
>
> source "toolchain/binutils/Config.in"
>
> +config DWARVES
> + bool
> + prompt "Build pahole" if TOOLCHAINOPTS
> + depends on !HOST_OS_MACOS
> + default n
> + help
> + Enable if you want to build pahole and the dwarves tools.
> +
> comment "Compiler"
> depends on TOOLCHAINOPTS
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 681344a014..9eefcaf393 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -36,6 +36,7 @@ tools-$(CONFIG_TARGET_tegra) += cbootimage
> cbootimage-configs
> tools-$(CONFIG_USES_MINOR) += kernel2minor
> tools-$(CONFIG_USE_SPARSE) += sparse
> tools-$(CONFIG_USE_LLVM_BUILD) += llvm-bpf
> +tools-$(CONFIG_DWARVES) += dwarves
>
> # builddir dependencies
> $(curdir)/autoconf/compile := $(curdir)/m4/compile
> diff --git a/tools/dwarves/Makefile b/tools/dwarves/Makefile
> new file mode 100644
> index 00..b02a2398a1
> --- /dev/null
> +++ b/tools/dwarves/Makefile
> @@ -0,0 +1,38 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=dwarves
> +
> +PKG_SOURCE_VERSION:=v1.23
> +PKG_SOURCE_PROTO:=git
> +PKG_SOURCE_URL:=https://git.kernel.org/pub/scm/devel/pahole/pahole.git
> +PKG_MIRROR_HASH:=6ab1bb1dbdf6c73ffcf485d909229dc1da1a3d24efd213e92c56489b58d6a4bd
> +PKG_LICENSE:=GPL-2.0-only
> +PKG_LICENSE_FILES:=COPYING
> +
> +HOST_BUILD_PARALLEL:=1
> +
> +include $(INCLUDE_DIR)/host-build.mk
> +include $(INCLUDE_DIR)/cmake.mk
> +
> +CMAKE_HOST_OPTIONS += \
> + -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=BOTH \
> + -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=BOTH \
> + -DCMAKE_BUILD_TYPE=Release \
> + -D__LIB=lib \
> + -DCMAKE_INSTALL_RPATH="$(STAGING_DIR_HOST)/lib" \
> + -DCMAKE_SKIP_RPATH=FALSE
> +
> +define Host/Clean
> + rm -f
> $(STAGING_DIR_HOST)/bin/{codiff,ctracer,dtagnames,pahole,pdwtags}
> + rm -f $(STAGING_DIR_HOST)/bin/{pfunct,pglobal,prefcnt,scncopy,syscse}
> + rm -f $(STAGING_DIR_HOST)/bin/{ostra-cg,btfdiff,fullcircle}
> + rm -f $(STAGING_DIR_HOST)/lib/libdwarves*.so*
> + rm -f $(STAGING_DIR_HOST)/share/man/man1/pahole.1
> + rm -rf $(STAGING_DIR_HOST)/include/dwarves
> + rm -rf $(STAGING_DIR_HOST)/share/dwarves
> + $(call Host/Clean/Default)
> +endef
> +
> +$(eval $(call HostBuild))
> --
> 2.34.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] firewall3: remove unnecessary fw3_has_table
> > > > > Hi, guys, > > > > On Fri, 11 Feb 2022 at 19:12, Wenli Looi wrote: > > > > > > Sorry, forgot to reply all > > > > > > On Fri, Feb 11, 2022 at 11:09 AM Wenli Looi wrote: > > > > > > > > Hi Rui, > > > > > > > > Yes, I believe it still works. Every place where fw3_has_table is > > > > called, we check immediately after if fw3_ipt_open succeeds, which > > > > makes fw3_has_table superfluous? > > > > > > > > I added a few print statements to fw3_ipt_open to check the case you > > > > mentioned: > > > > > > > > root@OpenWrt:~# fw3 restart 2>/dev/null > > > > fw3_ipt_open SUCCESS for v4 filter > > > > fw3_ipt_open SUCCESS for v4 nat > > > > fw3_ipt_open SUCCESS for v4 mangle > > > > fw3_ipt_open FAILED for v4 raw > > > > fw3_ipt_open FAILED for v6 filter > > > > fw3_ipt_open FAILED for v6 nat > > > > fw3_ipt_open FAILED for v6 mangle > > > > fw3_ipt_open FAILED for v6 raw > > > > fw3_ipt_open SUCCESS for v4 filter > > > > fw3_ipt_open SUCCESS for v4 nat > > > > fw3_ipt_open SUCCESS for v4 mangle > > > > fw3_ipt_open FAILED for v4 raw > > > > fw3_ipt_open FAILED for v6 filter > > > > fw3_ipt_open FAILED for v6 nat > > > > fw3_ipt_open FAILED for v6 mangle > > > > fw3_ipt_open FAILED for v6 raw > > > > root@OpenWrt:~# opkg install kmod-ipt-raw > > > > Installing kmod-ipt-raw (5.10.96-1) to root... > > > > Downloading > > > > https://downloads.openwrt.org/snapshots/targets/x86/64/kmods/5.10.96-1-d70ff298d8114a0df4de3fc8fa861191/kmod-ipt-raw_5.10.96-1_x86_64.ipk > > > > Configuring kmod-ipt-raw. > > > > root@OpenWrt:~# fw3 restart 2>/dev/null > > > > fw3_ipt_open SUCCESS for v4 filter > > > > fw3_ipt_open SUCCESS for v4 nat > > > > fw3_ipt_open SUCCESS for v4 mangle > > > > fw3_ipt_open SUCCESS for v4 raw > > > > fw3_ipt_open FAILED for v6 filter > > > > fw3_ipt_open FAILED for v6 nat > > > > fw3_ipt_open FAILED for v6 mangle > > > > fw3_ipt_open FAILED for v6 raw > > > > fw3_ipt_open SUCCESS for v4 filter > > > > fw3_ipt_open SUCCESS for v4 nat > > > > fw3_ipt_open SUCCESS for v4 mangle > > > > fw3_ipt_open SUCCESS for v4 raw > > > > fw3_ipt_open FAILED for v6 filter > > > > fw3_ipt_open FAILED for v6 nat > > > > fw3_ipt_open FAILED for v6 mangle > > > > fw3_ipt_open FAILED for v6 raw > > > > Ansuel, mind giving Wenli's fw3 patch [1] a spin on your 5.15 setup? > > I've reverted your fix [2], tested it on 5.10 and had no regressions. > > If it also works fine on 5.15, it's definitely a more elegant > > solution. > > Sure I will test this today and give a response ASAP. > Hi, sorry for the delay... I reverted my patch and applied this and I can confirm that this works correctly on linux 5.15. > > > > [1] > > https://patchwork.ozlabs.org/project/openwrt/patch/20210610045106.285820-1-wl...@ucalgary.ca/ > > [2] > > https://git.openwrt.org/?p=project/firewall3.git;a=commit;h=3624c3786601699b6e7f9d18209fad0d7c6fe4e9 > > > > Thanks in advance, > > Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] iproute2: add support for cpu set
>
> On Thu, Feb 03, 2022 at 01:44:12AM +0100, Ansuel Smith wrote:
> > Add support for cpu set useful to set CPU port for dsa devices.
>
> Please also document the newly added 'cpu' parameter in the command-
> line output -- the manpage isn't even installed/available for OpenWrt
> users.
>
Should I wait for other review or should I send v3?
> >
> > Signed-off-by: Ansuel Smith
> > ---
> > ...101-iplink_allow_to_change_cpu_value.patch | 81 +++
> > 1 file changed, 81 insertions(+)
> > create mode 100644
> > package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> >
> > diff --git
> > a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> >
> > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > new file mode 100644
> > index ..1bb2bb1f
> > --- /dev/null
> > +++
> > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > @@ -0,0 +1,81 @@
> > +From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
> > +From: Ansuel Smith
> > +Date: Sun, 23 Jan 2022 00:31:49 +0100
> > +Subject: [PATCH] iplink: allow to change cpu of dsa device
> > +
> > +Allow to change the cpu port linked to a given dsa interface.
> > +This is useful in the case of multi-CPU port DSA to assign the correct
> > +port to the different user ports.
> > +
> > +Signed-off-by: Ansuel Smith
> > +---
> > + include/uapi/linux/if_link.h | 1 +
> > + ip/iplink.c | 7 +++
> > + man/man8/ip-link.8.in| 7 +++
> > + 3 files changed, 15 insertions(+)
> > +
> > +diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> > +index 41708e26..901b5544 100644
> > +--- a/include/uapi/linux/if_link.h
> > b/include/uapi/linux/if_link.h
> > +@@ -341,6 +341,7 @@ enum {
> > + IFLA_ALT_IFNAME, /* Alternative ifname */
> > + IFLA_PERM_ADDRESS,
> > + IFLA_PROTO_DOWN_REASON,
> > ++IFLA_CPU,
> > +
> > + /* device (sysfs) name as parent, used instead
> > + * of IFLA_LINK where there's no parent netdev
> > +diff --git a/ip/iplink.c b/ip/iplink.c
> > +index a3ea775d..254c35c5 100644
> > +--- a/ip/iplink.c
> > b/ip/iplink.c
> > +@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct
> > iplink_req *req, char **type)
> > + int index = 0;
> > + int group = -1;
> > + int addr_len = 0;
> > ++int cpu = -1;
> > + int err;
> > +
> > + ret = argc;
> > +@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct
> > iplink_req *req, char **type)
> > + } else if (matches(*argv, "link") == 0) {
> > + NEXT_ARG();
> > + link = *argv;
> > ++} else if (matches(*argv, "cpu") == 0) {
> > ++NEXT_ARG();
> > ++cpu = ll_name_to_index(*argv);
> > ++if (!cpu)
> > ++return nodev(*argv);
> > ++addattr32(&req->n, sizeof(*req), IFLA_CPU, cpu);
> > + } else if (matches(*argv, "address") == 0) {
> > + NEXT_ARG();
> > + addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
> > +diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> > +index 19a0c9ca..406db8ad 100644
> > +--- a/man/man8/ip-link.8.in
> > b/man/man8/ip-link.8.in
> > +@@ -152,6 +152,9 @@ ip-link \- network device configuration
> > + .br
> > + .RB "[ " nomaster " ]"
> > + .br
> > ++.RB "[ " cpu
> > ++.IR DEVICE " ]"
> > ++.br
> > + .RB "[ " vrf
> > + .IR NAME " ]"
> > + .br
> > +@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
> > + .BI nomaster
> > + unset master device of the device (release device).
> > +
> > ++.TP
> > ++.BI cpu " DEVICE"
> > ++set cpu device of the dsa device.
> > ++
> > + .TP
> > + .BI addrgenmode " eui64|none|stable_secret|random"
> > + set the IPv6 address generation mode
> > +--
> > +2.33.1
> > +
> > --
> > 2.34.1
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] firewall3: remove unnecessary fw3_has_table
> > Hi, guys, > > On Fri, 11 Feb 2022 at 19:12, Wenli Looi wrote: > > > > Sorry, forgot to reply all > > > > On Fri, Feb 11, 2022 at 11:09 AM Wenli Looi wrote: > > > > > > Hi Rui, > > > > > > Yes, I believe it still works. Every place where fw3_has_table is > > > called, we check immediately after if fw3_ipt_open succeeds, which > > > makes fw3_has_table superfluous? > > > > > > I added a few print statements to fw3_ipt_open to check the case you > > > mentioned: > > > > > > root@OpenWrt:~# fw3 restart 2>/dev/null > > > fw3_ipt_open SUCCESS for v4 filter > > > fw3_ipt_open SUCCESS for v4 nat > > > fw3_ipt_open SUCCESS for v4 mangle > > > fw3_ipt_open FAILED for v4 raw > > > fw3_ipt_open FAILED for v6 filter > > > fw3_ipt_open FAILED for v6 nat > > > fw3_ipt_open FAILED for v6 mangle > > > fw3_ipt_open FAILED for v6 raw > > > fw3_ipt_open SUCCESS for v4 filter > > > fw3_ipt_open SUCCESS for v4 nat > > > fw3_ipt_open SUCCESS for v4 mangle > > > fw3_ipt_open FAILED for v4 raw > > > fw3_ipt_open FAILED for v6 filter > > > fw3_ipt_open FAILED for v6 nat > > > fw3_ipt_open FAILED for v6 mangle > > > fw3_ipt_open FAILED for v6 raw > > > root@OpenWrt:~# opkg install kmod-ipt-raw > > > Installing kmod-ipt-raw (5.10.96-1) to root... > > > Downloading > > > https://downloads.openwrt.org/snapshots/targets/x86/64/kmods/5.10.96-1-d70ff298d8114a0df4de3fc8fa861191/kmod-ipt-raw_5.10.96-1_x86_64.ipk > > > Configuring kmod-ipt-raw. > > > root@OpenWrt:~# fw3 restart 2>/dev/null > > > fw3_ipt_open SUCCESS for v4 filter > > > fw3_ipt_open SUCCESS for v4 nat > > > fw3_ipt_open SUCCESS for v4 mangle > > > fw3_ipt_open SUCCESS for v4 raw > > > fw3_ipt_open FAILED for v6 filter > > > fw3_ipt_open FAILED for v6 nat > > > fw3_ipt_open FAILED for v6 mangle > > > fw3_ipt_open FAILED for v6 raw > > > fw3_ipt_open SUCCESS for v4 filter > > > fw3_ipt_open SUCCESS for v4 nat > > > fw3_ipt_open SUCCESS for v4 mangle > > > fw3_ipt_open SUCCESS for v4 raw > > > fw3_ipt_open FAILED for v6 filter > > > fw3_ipt_open FAILED for v6 nat > > > fw3_ipt_open FAILED for v6 mangle > > > fw3_ipt_open FAILED for v6 raw > > Ansuel, mind giving Wenli's fw3 patch [1] a spin on your 5.15 setup? > I've reverted your fix [2], tested it on 5.10 and had no regressions. > If it also works fine on 5.15, it's definitely a more elegant > solution. Sure I will test this today and give a response ASAP. > > [1] > https://patchwork.ozlabs.org/project/openwrt/patch/20210610045106.285820-1-wl...@ucalgary.ca/ > [2] > https://git.openwrt.org/?p=project/firewall3.git;a=commit;h=3624c3786601699b6e7f9d18209fad0d7c6fe4e9 > > Thanks in advance, > Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Clarification about issue on github
Hi, I have a question for the issue on github. They are only for bugs and issues on openwrt or can also be used for asking the community for some testing? I notice some user are present only on github and not on the forum so I wonder if a use like that is acceptable. (this comes from the fact that i'm pushing some clk changes upstream and I would like to tag some user to test the changes on the SoC. And since they are wip I don't want to create trash pr for them) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 2/2] iproute2: add support for cpu set
Add support for cpu set useful to set CPU port for dsa devices.
Signed-off-by: Ansuel Smith
---
...101-iplink_allow_to_change_cpu_value.patch | 81 +++
1 file changed, 81 insertions(+)
create mode 100644
package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
diff --git
a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
new file mode 100644
index ..1bb2bb1f
--- /dev/null
+++
b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
@@ -0,0 +1,81 @@
+From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
+From: Ansuel Smith
+Date: Sun, 23 Jan 2022 00:31:49 +0100
+Subject: [PATCH] iplink: allow to change cpu of dsa device
+
+Allow to change the cpu port linked to a given dsa interface.
+This is useful in the case of multi-CPU port DSA to assign the correct
+port to the different user ports.
+
+Signed-off-by: Ansuel Smith
+---
+ include/uapi/linux/if_link.h | 1 +
+ ip/iplink.c | 7 +++
+ man/man8/ip-link.8.in| 7 +++
+ 3 files changed, 15 insertions(+)
+
+diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
+index 41708e26..901b5544 100644
+--- a/include/uapi/linux/if_link.h
b/include/uapi/linux/if_link.h
+@@ -341,6 +341,7 @@ enum {
+ IFLA_ALT_IFNAME, /* Alternative ifname */
+ IFLA_PERM_ADDRESS,
+ IFLA_PROTO_DOWN_REASON,
++ IFLA_CPU,
+
+ /* device (sysfs) name as parent, used instead
+* of IFLA_LINK where there's no parent netdev
+diff --git a/ip/iplink.c b/ip/iplink.c
+index a3ea775d..254c35c5 100644
+--- a/ip/iplink.c
b/ip/iplink.c
+@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct iplink_req
*req, char **type)
+ int index = 0;
+ int group = -1;
+ int addr_len = 0;
++ int cpu = -1;
+ int err;
+
+ ret = argc;
+@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct iplink_req
*req, char **type)
+ } else if (matches(*argv, "link") == 0) {
+ NEXT_ARG();
+ link = *argv;
++ } else if (matches(*argv, "cpu") == 0) {
++ NEXT_ARG();
++ cpu = ll_name_to_index(*argv);
++ if (!cpu)
++ return nodev(*argv);
++ addattr32(&req->n, sizeof(*req), IFLA_CPU, cpu);
+ } else if (matches(*argv, "address") == 0) {
+ NEXT_ARG();
+ addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
+diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
+index 19a0c9ca..406db8ad 100644
+--- a/man/man8/ip-link.8.in
b/man/man8/ip-link.8.in
+@@ -152,6 +152,9 @@ ip-link \- network device configuration
+ .br
+ .RB "[ " nomaster " ]"
+ .br
++.RB "[ " cpu
++.IR DEVICE " ]"
++.br
+ .RB "[ " vrf
+ .IR NAME " ]"
+ .br
+@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
+ .BI nomaster
+ unset master device of the device (release device).
+
++.TP
++.BI cpu " DEVICE"
++set cpu device of the dsa device.
++
+ .TP
+ .BI addrgenmode " eui64|none|stable_secret|random"
+ set the IPv6 address generation mode
+--
+2.33.1
+
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 0/2] Add DSA MultiCPU port support
This adds the hack patches for DSA multicpu support. I still have to clean patch 1, 3, 4 but considering this is still a bit WIP I decided to clean and provide a correct patches for the final version. This version won't change the logic by DSA that assing every port to the first cpu port. A init script is required to change the cpu port at runtime. This change was done for the only reason that a round-robin way can't be trusted and is too random. Some cpu port in some switch (brcm) for example doesn't behave the same way and randomly assigning the cpu port would cause problems/malfunctions. v3: - Move IFLA_CPU at the end of enum for ABI compatibility - Remove junk from patches - Fix commit description v2: - Rework iproute logic to not pollute link - Rework the round-robin cpu port assign logic Ansuel Smith (2): linux: introduce multi-cpu dsa patch iproute2: add support for cpu set ...101-iplink_allow_to_change_cpu_value.patch | 81 + ...net-dsa-allow-for-multiple-CPU-ports.patch | 97 +++ ...add-ndo-for-setting-the-cpu-proprety.patch | 113 ++ ...t-ndo_set_cpu-for-changing-DSA-port-.patch | 100 ...clude-net-add-dsa_cpu_ports-function.patch | 39 ++ 5 files changed, 430 insertions(+) create mode 100644 package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch create mode 100644 target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch create mode 100644 target/linux/generic/hack-5.10/780-2-net-add-ndo-for-setting-the-cpu-proprety.patch create mode 100644 target/linux/generic/hack-5.10/780-3-net-dsa-implement-ndo_set_cpu-for-changing-DSA-port-.patch create mode 100644 target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 1/2] linux: introduce multi-cpu dsa patch
Add support for multi-cpu dsa. This is a reworked version of the RFC patch
proposed some time ago.
By default every dsa port is connected to the first cpu port and the command
'ip link set PORT cpu CPU_PORT' can be used to change the used cpu port at
runtime.
A specific function port_change_cpu_port is required to correctly setup the
port on cpu change request.
Signed-off-by: Ansuel Smith
---
...net-dsa-allow-for-multiple-CPU-ports.patch | 97 +++
...add-ndo-for-setting-the-cpu-proprety.patch | 113 ++
...t-ndo_set_cpu-for-changing-DSA-port-.patch | 100
...clude-net-add-dsa_cpu_ports-function.patch | 39 ++
4 files changed, 349 insertions(+)
create mode 100644
target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
create mode 100644
target/linux/generic/hack-5.10/780-2-net-add-ndo-for-setting-the-cpu-proprety.patch
create mode 100644
target/linux/generic/hack-5.10/780-3-net-dsa-implement-ndo_set_cpu-for-changing-DSA-port-.patch
create mode 100644
target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch
diff --git
a/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
b/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
new file mode 100644
index ..9b4a57c6
--- /dev/null
+++
b/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
@@ -0,0 +1,97 @@
+From 48d1e9543273c7670ebef15a4d27b13023895a28 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?=
+Date: Sat, 24 Aug 2019 04:42:48 +0200
+Subject: [PATCH 1/4] net: dsa: allow for multiple CPU ports
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Allow for multiple CPU ports in a DSA switch tree. The default assing
+logic is still used where the first defined CPU port is selected for all
+the user ports. The CPU port has to be changed at runtime.
+
+Signed-off-by: Marek Behún
+---
+ net/dsa/dsa2.c | 22 ++
+ 1 file changed, 14 insertions(+), 8 deletions(-)
+
+diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
+index 183003e45762..4a8de5e2f0f5 100644
+--- a/net/dsa/dsa2.c
b/net/dsa/dsa2.c
+@@ -240,7 +240,7 @@ static int dsa_tree_setup_default_cpu(struct
dsa_switch_tree *dst)
+ return 0;
+ }
+
+-static void dsa_tree_teardown_default_cpu(struct dsa_switch_tree *dst)
++static void dsa_tree_teardown_default_cpus(struct dsa_switch_tree *dst)
+ {
+ struct dsa_port *dp;
+
+@@ -553,7 +553,7 @@ static void dsa_tree_teardown_switches(struct
dsa_switch_tree *dst)
+ dsa_switch_teardown(dp->ds);
+ }
+
+-static int dsa_tree_setup_master(struct dsa_switch_tree *dst)
++static int dsa_tree_setup_masters(struct dsa_switch_tree *dst)
+ {
+ struct dsa_port *dp;
+ int err;
+@@ -562,14 +562,20 @@ static int dsa_tree_setup_master(struct dsa_switch_tree
*dst)
+ if (dsa_port_is_cpu(dp)) {
+ err = dsa_master_setup(dp->master, dp);
+ if (err)
+- return err;
++ goto teardown;
+ }
+ }
+
+ return 0;
++teardown:
++ list_for_each_entry(dp, &dst->ports, list)
++ if (dsa_port_is_cpu(dp))
++ dsa_master_teardown(dp->master);
++
++ return err;
+ }
+
+-static void dsa_tree_teardown_master(struct dsa_switch_tree *dst)
++static void dsa_tree_teardown_masters(struct dsa_switch_tree *dst)
+ {
+ struct dsa_port *dp;
+
+@@ -601,7 +607,7 @@ static int dsa_tree_setup(struct dsa_switch_tree *dst)
+ if (err)
+ goto teardown_default_cpu;
+
+- err = dsa_tree_setup_master(dst);
++ err = dsa_tree_setup_masters(dst);
+ if (err)
+ goto teardown_switches;
+
+@@ -614,7 +620,7 @@ static int dsa_tree_setup(struct dsa_switch_tree *dst)
+ teardown_switches:
+ dsa_tree_teardown_switches(dst);
+ teardown_default_cpu:
+- dsa_tree_teardown_default_cpu(dst);
++ dsa_tree_teardown_default_cpus(dst);
+
+ return err;
+ }
+@@ -626,11 +632,11 @@ static void dsa_tree_teardown(struct dsa_switch_tree
*dst)
+ if (!dst->setup)
+ return;
+
+- dsa_tree_teardown_master(dst);
++ dsa_tree_teardown_masters(dst);
+
+ dsa_tree_teardown_switches(dst);
+
+- dsa_tree_teardown_default_cpu(dst);
++ dsa_tree_teardown_default_cpus(dst);
+
+ list_for_each_entry_safe(dl, next, &dst->rtable, list) {
+ list_del(&dl->list);
+--
+2.34.1
+
diff --git
a/target/linux/generic/hack-5.10/780-2-net-add-ndo-for-setting-the-cpu-proprety.patch
b/target/linux/generic/hack-5.10/780-2-net-add-ndo-for-setting-the-cpu-proprety.patch
new file mode 100644
index ..d9441feb
--- /dev/null
+++
b/target/linux/generic/hack-5.10/780-2-net-add-ndo-for-setting-the
Re: [RFC PATCH v2 0/2] Add DSA MultiCPU port support
Il giorno dom 23 gen 2022 alle ore 02:39 Ansuel Smith ha scritto: > > Il giorno dom 23 gen 2022 alle ore 02:29 Daniel Golle > ha scritto: > > > > On Sun, Jan 23, 2022 at 01:35:24AM +0100, Ansuel Smith wrote: > > > This adds the hack patches for DSA multicpu support. > > > I still have to clean patch 1, 3, 4 but considering this is still a bit > > > WIP > > > I decided to clean and provide a correct patches for the final version. > > > > > > This version won't change the logic by DSA that assing every port to the > > > first > > > cpu port. A init script is required to change the cpu port at runtime. > > > > Imho we should also add patch > > > > From: LGA1150 > > Date: Mon, 17 May 2021 10:34:58 +0200 > > Subject: [PATCH] net: dsa: add dts-property default_cpu > > > > so this can be done in device-tree rather than using an init-script. > > > > Don't know if you check the pr but the additional binding was rejected > upstream. > We need to understand if we can accept this kind of patch or not. > IMHO considering it should be a small patch, we can totally accept > that but we have > to be conscious that it won't ever be merged and it will stay in hack forever. > > > > This change was done for the only reason that a round-robin way can't be > > > trusted > > > and is too random. Some cpu port in some switch (brcm) for example doesn't > > > behave the same way and randomly assigning the cpu port would cause > > > problems/malfunctions. > > > > I agree that round-robin is not such a good idea, the commit message of > > the patch itself will also have to be updated to reflect that change. > > > > Sure as I said, I still have to rework this and produce clear patches. > (I assume many changes are still needed for this) > I will send v3 in the next few days. Any other comments? > > > > > > v2: > > > - Rework iproute logic to not pollute link > > > - Rework the round-robin cpu port assign logic > > > > > > Ansuel Smith (2): > > > linux: introduce multi-cpu dsa patch > > > iproute2: add support for cpu set > > > > > > ...101-iplink_allow_to_change_cpu_value.patch | 81 ++ > > > ...net-dsa-allow_for_multiple_CPU_ports.patch | 151 ++ > > > ...add_ndo_for_setting_the_cpu_property.patch | 113 + > > > ..._set_cpu_for_changing_ports_CPU_port.patch | 89 +++ > > > ...clude-net-add-dsa_cpu_ports-function.patch | 34 > > > 5 files changed, 468 insertions(+) > > > create mode 100644 > > > package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch > > > create mode 100644 > > > target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch > > > create mode 100644 > > > target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_cpu_property.patch > > > create mode 100644 > > > target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_cpu_for_changing_ports_CPU_port.patch > > > create mode 100644 > > > target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch > > > > > > -- > > > 2.33.1 > > > > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/2] Add DSA MultiCPU port support
Il giorno dom 23 gen 2022 alle ore 02:29 Daniel Golle ha scritto: > > On Sun, Jan 23, 2022 at 01:35:24AM +0100, Ansuel Smith wrote: > > This adds the hack patches for DSA multicpu support. > > I still have to clean patch 1, 3, 4 but considering this is still a bit WIP > > I decided to clean and provide a correct patches for the final version. > > > > This version won't change the logic by DSA that assing every port to the > > first > > cpu port. A init script is required to change the cpu port at runtime. > > Imho we should also add patch > > From: LGA1150 > Date: Mon, 17 May 2021 10:34:58 +0200 > Subject: [PATCH] net: dsa: add dts-property default_cpu > > so this can be done in device-tree rather than using an init-script. > Don't know if you check the pr but the additional binding was rejected upstream. We need to understand if we can accept this kind of patch or not. IMHO considering it should be a small patch, we can totally accept that but we have to be conscious that it won't ever be merged and it will stay in hack forever. > > This change was done for the only reason that a round-robin way can't be > > trusted > > and is too random. Some cpu port in some switch (brcm) for example doesn't > > behave the same way and randomly assigning the cpu port would cause > > problems/malfunctions. > > I agree that round-robin is not such a good idea, the commit message of > the patch itself will also have to be updated to reflect that change. > Sure as I said, I still have to rework this and produce clear patches. (I assume many changes are still needed for this) > > > > v2: > > - Rework iproute logic to not pollute link > > - Rework the round-robin cpu port assign logic > > > > Ansuel Smith (2): > > linux: introduce multi-cpu dsa patch > > iproute2: add support for cpu set > > > > ...101-iplink_allow_to_change_cpu_value.patch | 81 ++ > > ...net-dsa-allow_for_multiple_CPU_ports.patch | 151 ++ > > ...add_ndo_for_setting_the_cpu_property.patch | 113 + > > ..._set_cpu_for_changing_ports_CPU_port.patch | 89 +++ > > ...clude-net-add-dsa_cpu_ports-function.patch | 34 > > 5 files changed, 468 insertions(+) > > create mode 100644 > > package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch > > create mode 100644 > > target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch > > create mode 100644 > > target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_cpu_property.patch > > create mode 100644 > > target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_cpu_for_changing_ports_CPU_port.patch > > create mode 100644 > > target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch > > > > -- > > 2.33.1 > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH v2 1/2] linux: introduce multi-cpu dsa patch
Add support for multi-cpu dsa. This is a reworked version of the RFC patch proposed some time ago. By default every dsa port is connected to the first cpu port and the command 'ip link set PORT cpu CPU_PORT' can be used to change the used cpu port at runtime. A specific function port_change_cpu_port is required to correctly setup the port on cpu change request. Signed-off-by: Ansuel Smith --- ...net-dsa-allow_for_multiple_CPU_ports.patch | 151 ++ ...add_ndo_for_setting_the_cpu_property.patch | 113 + ..._set_cpu_for_changing_ports_CPU_port.patch | 89 +++ ...clude-net-add-dsa_cpu_ports-function.patch | 34 4 files changed, 387 insertions(+) create mode 100644 target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch create mode 100644 target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_cpu_property.patch create mode 100644 target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_cpu_for_changing_ports_CPU_port.patch create mode 100644 target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch diff --git a/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch new file mode 100644 index ..7f2f349a --- /dev/null +++ b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch @@ -0,0 +1,151 @@ +From mboxrd@z Thu Jan 1 00:00:00 1970 +Return-Path: +X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on + aws-us-west-2-korg-lkml-1.web.codeaurora.org +X-Spam-Level: +X-Spam-Status: No, score=-9.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, + DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, + SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham + autolearn_force=no version=3.4.0 +Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) + by smtp.lore.kernel.org (Postfix) with ESMTP id 98EBDC3A5A2 + for ; Sat, 24 Aug 2019 02:43:07 + (UTC) +Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) + by mail.kernel.org (Postfix) with ESMTP id 6168A2173B + for ; Sat, 24 Aug 2019 02:43:07 + (UTC) +Authentication-Results: mail.kernel.org; + dkim=pass (1024-bit key) header.d=nic.cz header.i=@nic.cz header.b="Kl8qU9Mx" +Received: (majord...@vger.kernel.org) by vger.kernel.org via listexpand +id S1726888AbfHXCnF (ORCPT ); +Fri, 23 Aug 2019 22:43:05 -0400 +Received: from mail.nic.cz ([217.31.204.67]:37268 "EHLO mail.nic.cz" +rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP +id S1725807AbfHXCnD (ORCPT ); +Fri, 23 Aug 2019 22:43:03 -0400 +Received: from dellmb.labs.office.nic.cz (unknown [IPv6:2001:1488:fffe:6:cac7:3539:7f1f:463]) +by mail.nic.cz (Postfix) with ESMTP id 94D1E140D1E; +Sat, 24 Aug 2019 04:42:59 +0200 (CEST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; +t=1566614579; bh=jPa21EsnWy9WksW68HSx/O+la2qm4ImIACY+K2cEnLY=; +h=From:To:Date; +b=Kl8qU9MxZdC3EQnTetDA7VbGXYIuwCO2zS6HinOo7XykIKQDlvB7jIUcH0FQLgG6T + BNf/aIsDASIL1PBSAlNynoTMSDf8m6I2Xo8auxQr4L6sslF683w8hY9PN7f+pYyL2R + FQs93FIJYSp5I2NCSktTxGFNumTvYPxA8lEqBaZo= +From: =?UTF-8?q?Marek=20Beh=C3=BAn?= +To: net...@vger.kernel.org +Cc: Andrew Lunn , +Vivien Didelot , +Florian Fainelli , +David Ahern , +Stephen Hemminger , +=?UTF-8?q?Marek=20Beh=C3=BAn?= +Subject: [PATCH RFC net-next 1/3] net: dsa: allow for multiple CPU ports +Date: Sat, 24 Aug 2019 04:42:48 +0200 +Message-Id: <20190824024251.4542-2-marek.be...@nic.cz> +X-Mailer: git-send-email 2.21.0 +In-Reply-To: <20190824024251.4542-1-marek.be...@nic.cz> +References: <20190824024251.4542-1-marek.be...@nic.cz> +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit +X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz +X-Virus-Status: Clean +Sender: netdev-ow...@vger.kernel.org +Precedence: bulk +List-ID: +X-Mailing-List: net...@vger.kernel.org +Archived-At: <https://lore.kernel.org/netdev/20190824024251.4542-2-marek.be...@nic.cz/> +List-Archive: <https://lore.kernel.org/netdev/> +List-Post: <mailto:net...@vger.kernel.org> + +Allow for multiple CPU ports in a DSA switch tree. By default assign the +CPU ports to user ports in a round robin way, ie. if there are two CPU +ports connected to eth0 and eth1, and five user ports (lan1..lan5), +assign them as: + lan1 <-> eth0 + lan2 <-> eth1 + lan3 <-> eth0 + lan4 <-> eth1 + lan5 <-> eth0 + +Signed-off-by: Marek Behún +--- + include/net/dsa.h | 5 +-- + net/dsa/dsa2.c| 84 +++ + 2 files changed, 58 insertions(+)
[RFC PATCH v2 0/2] Add DSA MultiCPU port support
This adds the hack patches for DSA multicpu support. I still have to clean patch 1, 3, 4 but considering this is still a bit WIP I decided to clean and provide a correct patches for the final version. This version won't change the logic by DSA that assing every port to the first cpu port. A init script is required to change the cpu port at runtime. This change was done for the only reason that a round-robin way can't be trusted and is too random. Some cpu port in some switch (brcm) for example doesn't behave the same way and randomly assigning the cpu port would cause problems/malfunctions. v2: - Rework iproute logic to not pollute link - Rework the round-robin cpu port assign logic Ansuel Smith (2): linux: introduce multi-cpu dsa patch iproute2: add support for cpu set ...101-iplink_allow_to_change_cpu_value.patch | 81 ++ ...net-dsa-allow_for_multiple_CPU_ports.patch | 151 ++ ...add_ndo_for_setting_the_cpu_property.patch | 113 + ..._set_cpu_for_changing_ports_CPU_port.patch | 89 +++ ...clude-net-add-dsa_cpu_ports-function.patch | 34 5 files changed, 468 insertions(+) create mode 100644 package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch create mode 100644 target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch create mode 100644 target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_cpu_property.patch create mode 100644 target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_cpu_for_changing_ports_CPU_port.patch create mode 100644 target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH v2 2/2] iproute2: add support for cpu set
Add support for cpu set useful to set CPU port for dsa devices.
Signed-off-by: Ansuel Smith
---
...101-iplink_allow_to_change_cpu_value.patch | 81 +++
1 file changed, 81 insertions(+)
create mode 100644
package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
diff --git
a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
new file mode 100644
index ..1bb2bb1f
--- /dev/null
+++
b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
@@ -0,0 +1,81 @@
+From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
+From: Ansuel Smith
+Date: Sun, 23 Jan 2022 00:31:49 +0100
+Subject: [PATCH] iplink: allow to change cpu of dsa device
+
+Allow to change the cpu port linked to a given dsa interface.
+This is useful in the case of multi-CPU port DSA to assign the correct
+port to the different user ports.
+
+Signed-off-by: Ansuel Smith
+---
+ include/uapi/linux/if_link.h | 1 +
+ ip/iplink.c | 7 +++
+ man/man8/ip-link.8.in| 7 +++
+ 3 files changed, 15 insertions(+)
+
+diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
+index 41708e26..901b5544 100644
+--- a/include/uapi/linux/if_link.h
b/include/uapi/linux/if_link.h
+@@ -279,6 +279,7 @@ enum {
+ IFLA_BROADCAST,
+ IFLA_IFNAME,
+ IFLA_MTU,
++ IFLA_CPU,
+ IFLA_LINK,
+ IFLA_QDISC,
+ IFLA_STATS,
+diff --git a/ip/iplink.c b/ip/iplink.c
+index a3ea775d..254c35c5 100644
+--- a/ip/iplink.c
b/ip/iplink.c
+@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct iplink_req
*req, char **type)
+ int index = 0;
+ int group = -1;
+ int addr_len = 0;
++ int cpu = -1;
+ int err;
+
+ ret = argc;
+@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct iplink_req
*req, char **type)
+ } else if (matches(*argv, "link") == 0) {
+ NEXT_ARG();
+ link = *argv;
++ } else if (matches(*argv, "cpu") == 0) {
++ NEXT_ARG();
++ cpu = ll_name_to_index(*argv);
++ if (!cpu)
++ return nodev(*argv);
++ addattr32(&req->n, sizeof(*req), IFLA_CPU, cpu);
+ } else if (matches(*argv, "address") == 0) {
+ NEXT_ARG();
+ addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
+diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
+index 19a0c9ca..406db8ad 100644
+--- a/man/man8/ip-link.8.in
b/man/man8/ip-link.8.in
+@@ -152,6 +152,9 @@ ip-link \- network device configuration
+ .br
+ .RB "[ " nomaster " ]"
+ .br
++.RB "[ " cpu
++.IR DEVICE " ]"
++.br
+ .RB "[ " vrf
+ .IR NAME " ]"
+ .br
+@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
+ .BI nomaster
+ unset master device of the device (release device).
+
++.TP
++.BI cpu " DEVICE"
++set cpu device of the dsa device.
++
+ .TP
+ .BI addrgenmode " eui64|none|stable_secret|random"
+ set the IPv6 address generation mode
+--
+2.33.1
+
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: bpf-headers: fix build error when testing kernel is used
Now that we have separate files for each kernel version, only the version/hash for the target kernel are available. This cause a missing hash error (and wrong kernel version) for bpf-headers when a testing kernel version is used for the current target. Fix this error by manually including the kernel version/hash file for the specific kernel version requested. Signed-off-by: Ansuel Smith --- package/kernel/bpf-headers/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/package/kernel/bpf-headers/Makefile b/package/kernel/bpf-headers/Makefile index f3c0584007..b3f1c0c7f3 100644 --- a/package/kernel/bpf-headers/Makefile +++ b/package/kernel/bpf-headers/Makefile @@ -14,6 +14,9 @@ include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=linux PKG_PATCHVER:=5.10 +# Manually include kernel version/hash from kernel details file +include $(INCLUDE_DIR)/kernel-$(PKG_PATCHVER) + PKG_VERSION:=$(PKG_PATCHVER)$(strip $(LINUX_VERSION-$(PKG_PATCHVER))) PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=$(LINUX_SITE) -- 2.30.2.windows.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] iproute2: add support for link set
> > On Fri, Jan 21, 2022 at 09:14:50PM +, Rui Salvaterra wrote: > > On Fri, 21 Jan 2022 at 21:11, Ansuel Smith wrote: > > > > > > Should we follow the suggestion and add a specific attribute just for DSA? > > I believe that would be the right thing to do, but I'd like to know > > what Daniel and Marek think about it too. > > While adding a new attribute for the DSA CPU port linked means more > added complexity, I still believe it's the right thing to do if that's > what would be acceptable upstream and hence significantly reduce the > burden of having to maintain and forward-port the patch locally in the > long run. > Personally I perceive the use of the existing 'set link' attribute to > be sound and aligned with it's use in other contexts, but that's most > certainly a matter of taste. So.. how should we proceed with this? From what I understand the idea is to merge this ASAP. Think we have to change this with the DSA specific attribute. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] iproute2: add support for link set
> > Hi, Ansuel, > > After reading the patch more carefully, I have to say I'm really not fond of > it in its current form, especially considering that the original feedback > from Stephen Hemminger and Vladimir Oltean [1] hasn't been addressed. To be > honest, overloading the IFLA_LINK attribute for this purpose also doesn't > feel right to me. > Should we follow the suggestion and add a specific attribute just for DSA? > Cc'ing the original author of the patch. Marek? > > [1] https://lore.kernel.org/netdev/20210411170939.cxmva5vdcpqu4bmi@skbuf/ > > Cheers, > Rui > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[iwinfo v2 PATCH 1/2] iwinfo: add support for indoor only chan restriction
Some countries permit a specific channel to be used only indoors.
Introduce a new restriction_flags entry to declare different restrition
of a specific channel.
Signed-off-by: Ansuel Smith
---
v2:
- Fix spelling mistake
- Fix wrong define
include/iwinfo.h | 4
iwinfo_nl80211.c | 14 ++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 8469ee7..9832803 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -61,6 +61,9 @@
#define IWINFO_FREQ_NO_160MHZ (1 << 5)
#define IWINFO_FREQ_NO_2160MHZ (1 << 6)
+#define IWINFO_FREQ_NO_IR (1 << 0)
+#define IWINFO_FREQ_NO_OUTDOOR (1 << 1)
+
extern const char *IWINFO_CIPHER_NAMES[IWINFO_CIPHER_COUNT];
extern const char *IWINFO_KMGMT_NAMES[IWINFO_KMGMT_COUNT];
extern const char *IWINFO_AUTH_NAMES[IWINFO_AUTH_COUNT];
@@ -168,6 +171,7 @@ struct iwinfo_freqlist_entry {
uint8_t channel;
uint32_t mhz;
uint8_t restricted;
+ uint32_t restricted_flags;
uint32_t flags;
};
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index c4b0ee2..57f820a 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -2911,10 +2911,16 @@ static int nl80211_get_freqlist_cb(struct nl_msg *msg,
void *arg)
e->mhz =
nla_get_u32(freqs[NL80211_FREQUENCY_ATTR_FREQ]);
e->channel =
nl80211_freq2channel(e->mhz);
- e->restricted = (
-
freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
-
!freqs[NL80211_FREQUENCY_ATTR_RADAR]
- ) ? 1 : 0;
+ e->restricted =
(freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
+
!freqs[NL80211_FREQUENCY_ATTR_RADAR]) ||
+
freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY];
+
+ if (freqs[NL80211_FREQUENCY_ATTR_NO_IR]
&&
+
!freqs[NL80211_FREQUENCY_ATTR_RADAR])
+ e->restricted_flags |=
IWINFO_FREQ_NO_IR;
+
+ if
(freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY])
+ e->restricted_flags |=
IWINFO_FREQ_NO_OUTDOOR;
if
(freqs[NL80211_FREQUENCY_ATTR_NO_HT40_MINUS])
e->flags |=
IWINFO_FREQ_NO_HT40MINUS;
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[rpcd v2 PATCH 2/2] rpcd: iwinfo: export no_outdoor restriction
A channel can declare restriction where it should be used only indoors. Export this restriction in the channel data. Signed-off-by: Ansuel Smith --- iwinfo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/iwinfo.c b/iwinfo.c index ba4fc1e..85860e6 100644 --- a/iwinfo.c +++ b/iwinfo.c @@ -723,6 +723,9 @@ rpc_iwinfo_freqlist(struct ubus_context *ctx, struct ubus_object *obj, blobmsg_add_u32(&buf, "mhz", f->mhz); blobmsg_add_u8(&buf, "restricted", f->restricted); + blobmsg_add_bool(&buf, "no_outdoor", f->restricted_flags & +IWINFO_FREQ_NO_OUTDOOR); + if (ch > -1) blobmsg_add_u8(&buf, "active", f->channel == ch); -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] iproute2: add support for link set
Add support for link set useful to set CPU port for dsa drivers.
Signed-off-by: Ansuel Smith
---
...-iplink_allow_to_change_iplink_value.patch | 94 +++
1 file changed, 94 insertions(+)
create mode 100644
package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
diff --git
a/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
b/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
new file mode 100644
index 00..1a8bad9119
--- /dev/null
+++
b/package/network/utils/iproute2/patches/191-iplink_allow_to_change_iplink_value.patch
@@ -0,0 +1,94 @@
+From: Marek Behún
+Subject: [PATCH RFC iproute2-next] iplink: allow to change iplink value
+Date: Sat, 24 Aug 2019 04:42:51 +0200
+
+Allow to change the interface to which a given interface is linked to.
+This is useful in the case of multi-CPU port DSA, for changing the CPU
+port of a given user port.
+
+Signed-off-by: Marek Behún
+Cc: David Ahern
+Cc: Stephen Hemminger
+Signed-off-by: Ansuel Smith
+---
+ ip/iplink.c | 16 +---
+ man/man8/ip-link.8.in | 7 +++
+ 2 files changed, 12 insertions(+), 11 deletions(-)
+
+diff --git a/ip/iplink.c b/ip/iplink.c
+index 212a0885..d52c0aaf 100644
+--- a/ip/iplink.c
b/ip/iplink.c
+@@ -579,7 +579,6 @@ int iplink_parse(int argc, char **argv, struct iplink_req
*req, char **type)
+ {
+ char *name = NULL;
+ char *dev = NULL;
+- char *link = NULL;
+ int ret, len;
+ char abuf[32];
+ int qlen = -1;
+@@ -590,6 +589,7 @@ int iplink_parse(int argc, char **argv, struct iplink_req
*req, char **type)
+ int numrxqueues = -1;
+ int link_netnsid = -1;
+ int index = 0;
++ int link = -1;
+ int group = -1;
+ int addr_len = 0;
+
+@@ -620,7 +620,10 @@ int iplink_parse(int argc, char **argv, struct iplink_req
*req, char **type)
+ invarg("Invalid \"index\" value", *argv);
+ } else if (matches(*argv, "link") == 0) {
+ NEXT_ARG();
+- link = *argv;
++ link = ll_name_to_index(*argv);
++ if (!link)
++ return nodev(*argv);
++ addattr32(&req->n, sizeof(*req), IFLA_LINK, link);
+ } else if (matches(*argv, "address") == 0) {
+ NEXT_ARG();
+ addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
+@@ -1004,15 +1007,6 @@ int iplink_parse(int argc, char **argv, struct
iplink_req *req, char **type)
+ exit(-1);
+ }
+
+- if (link) {
+- int ifindex;
+-
+- ifindex = ll_name_to_index(link);
+- if (!ifindex)
+- return nodev(link);
+- addattr32(&req->n, sizeof(*req), IFLA_LINK, ifindex);
+- }
+-
+ req->i.ifi_index = index;
+ }
+
+diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
+index a8ae72d2..800aed05 100644
+--- a/man/man8/ip-link.8.in
b/man/man8/ip-link.8.in
+@@ -149,6 +149,9 @@ ip-link \- network device configuration
+ .br
+ .RB "[ " nomaster " ]"
+ .br
++.RB "[ " link
++.IR DEVICE " ]"
++.br
+ .RB "[ " vrf
+ .IR NAME " ]"
+ .br
+@@ -2131,6 +2134,10 @@ set master device of the device (enslave device).
+ .BI nomaster
+ unset master device of the device (release device).
+
++.TP
++.BI link " DEVICE"
++set device to which this device is linked to.
++
+ .TP
+ .BI addrgenmode " eui64|none|stable_secret|random"
+ set the IPv6 address generation mode
+--
+2.21.0
+
+
--
2.30.2.windows.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] linux: introduce multi-cpu dsa patch
Add support for multi-cpu dsa. This is a reworked version of the RFC patch
proposed some time ago. By default the cpus are selected in a round-robin
way and the command 'ip link set PORT link CPU_PORT' can be used to change
the used cpu port at runtime.
A specific function port_change_cpu_port to correctly setup the port on
cpu change request.
Signed-off-by: Ansuel Smith
---
...net-dsa-allow_for_multiple_CPU_ports.patch | 159 ++
..._ndo_for_setting_the_iflink_property.patch | 88 ++
..._netlink_for_changing_ports_CPU_port.patch | 89 ++
...clude-net-add-dsa_cpu_ports-function.patch | 34
4 files changed, 370 insertions(+)
create mode 100644
target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
create mode 100644
target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_iflink_property.patch
create mode 100644
target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_netlink_for_changing_ports_CPU_port.patch
create mode 100644
target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch
diff --git
a/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
new file mode 100644
index 00..9c3a9e77e2
--- /dev/null
+++
b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
@@ -0,0 +1,159 @@
+From: Marek Behún
+Subject: [PATCH RFC net-next 1/3] net: dsa: allow for multiple CPU ports
+Date: Sat, 24 Aug 2019 04:42:48 +0200
+
+Allow for multiple CPU ports in a DSA switch tree. By default assign the
+CPU ports to user ports in a round robin way, ie. if there are two CPU
+ports connected to eth0 and eth1, and five user ports (lan1..lan5),
+assign them as:
+ lan1 <-> eth0
+ lan2 <-> eth1
+ lan3 <-> eth0
+ lan4 <-> eth1
+ lan5 <-> eth0
+
+Signed-off-by: Marek Behún
+Signed-off-by: Ansuel Smith
+---
+ include/net/dsa.h | 5 +--
+ net/dsa/dsa2.c| 84 +++
+ 2 files changed, 58 insertions(+), 31 deletions(-)
+
+--- a/net/dsa/dsa2.c
b/net/dsa/dsa2.c
+@@ -211,36 +211,46 @@ static bool dsa_tree_setup_routing_table
+ return complete;
+ }
+
+-static struct dsa_port *dsa_tree_find_first_cpu(struct dsa_switch_tree *dst)
++static int dsa_tree_setup_default_cpus(struct dsa_switch_tree *dst)
+ {
+- struct dsa_port *dp;
+-
++ struct dsa_port *cpu_dp, *dp, *first_cpu_dp = NULL, *last_cpu_dp = NULL;
++
++ /* Find first and last CPU port */
+ list_for_each_entry(dp, &dst->ports, list)
+- if (dsa_port_is_cpu(dp))
+- return dp;
+-
+- return NULL;
+-}
++ if (dsa_port_is_cpu(dp)) {
++ if (first_cpu_dp == NULL)
++ first_cpu_dp = dp;
+
+-static int dsa_tree_setup_default_cpu(struct dsa_switch_tree *dst)
+-{
+- struct dsa_port *cpu_dp, *dp;
++ last_cpu_dp = dp;
++ }
+
+- cpu_dp = dsa_tree_find_first_cpu(dst);
+- if (!cpu_dp) {
++ if (first_cpu_dp == NULL) {
+ pr_err("DSA: tree %d has no CPU port\n", dst->index);
+ return -EINVAL;
+ }
+
+- /* Assign the default CPU port to all ports of the fabric */
++ cpu_dp = first_cpu_dp;
++
++ /* Assign the CPU ports in round-robbin way to all ports of the fabric
*/
+ list_for_each_entry(dp, &dst->ports, list)
+- if (dsa_port_is_user(dp) || dsa_port_is_dsa(dp))
++ if (dsa_port_is_user(dp) || dsa_port_is_dsa(dp)) {
+ dp->cpu_dp = cpu_dp;
+
++ if (cpu_dp == last_cpu_dp)
++ cpu_dp = first_cpu_dp;
++ else
++ while((cpu_dp = list_next_entry(cpu_dp, list))
!= 0)
++ if (dsa_port_is_cpu(cpu_dp))
++ break;
++
++ if (dp->ds->ops->port_change_cpu_port)
++ dp->ds->ops->port_change_cpu_port(dp->ds,
dp->index, dp->cpu_dp);
++ }
++
+ return 0;
+ }
+
+-static void dsa_tree_teardown_default_cpu(struct dsa_switch_tree *dst)
++static void dsa_tree_teardown_default_cpus(struct dsa_switch_tree *dst)
+ {
+ struct dsa_port *dp;
+
+@@ -572,7 +582,7 @@ static void dsa_tree_teardown_switches(s
+ dsa_switch_teardown(dp->ds);
+ }
+
+-static int dsa_tree_setup_master(struct dsa_switch_tree *dst)
++static int dsa_tree_setup_masters(struct dsa_switch_tree *dst)
+ {
+ struct dsa_port *dp;
+ int err;
+@@ -581,14 +591,20 @@ static int dsa_tree_setup_master(struct
+ if (dsa_port_is_cpu(dp)) {
+ err = dsa_maste
[maintainer-tools PATCH] update_kernel.sh: update it to new kernel hash/version file way
Openwrt changed how the hash/version of the various kernel are declared
and saved.
They are now placed in dedicated files. Fix the update_kernel.sh script
to update the kernel version/hash to the correct file.
Signed-off-by: Ansuel Smith
---
update_kernel.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/update_kernel.sh b/update_kernel.sh
index 0cbdb1d..2c4bb09 100755
--- a/update_kernel.sh
+++ b/update_kernel.sh
@@ -155,7 +155,7 @@ if [ "$UPDATE" -eq 1 ]; then
CHECKSUM=$(./staging_dir/host/bin/mkhash sha256
dl/linux-$PATCHVER.tar.xz)
fi
- $CMD ./staging_dir/host/bin/sed -i include/kernel-version.mk \
+ $CMD ./staging_dir/host/bin/sed -i include/kernel-${KERNEL} \
-e "s|LINUX_VERSION-${KERNEL} =.*|LINUX_VERSION-${KERNEL} =
${NEWVER}|" \
-e
"s|LINUX_KERNEL_HASH-${KERNEL}.*|LINUX_KERNEL_HASH-${PATCHVER} = ${CHECKSUM}|"
fi
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
> > Hi all, > > Back at the Hamburg meeting in 2019 and a succeeding vote we decided to > migrate over to a self-hosted GitLab instance. Some years passed and nothing > really happened so I’d like to give this another go. > > None of the OpenWrt project members is willing to setup and maintain a GitLab > instance and there were multiple vetos again gitlab.com. > > Our current bug tracker at bugs.openwrt.org is used by a minority of users > (and devs), all community repositories (LuCI, packages, …) use GitHub for > issue tracking. Instead of maintaining flyspray and the server, I’d like to > export all flyspray issues, migrate them to GitHub and open GitHub issues for > openwrt/openwrt to the public. A static or read-only version of flyspray > could be hosted for the near future. > > Secondly I’d like to give the CI of the main repository another go. Our CI to > build Docker images is currently on gitlab.com, I’d migrate that over to > GitHub. Also I’d suggest to add similar CI checks as added to the packages > (and routing and video and LuCI) repository. We could compile targets and > tooling, check checksums etc, even build snapshots to lower the resource > usage of our Buildbot infrastructure. > > During a recent _poll_ in #openwrt-adm multiple members liked the idea, > however before doing or voting on anything, I’d like to ask for more comments. > > Thanks for all feedback, > Paul +1 for github. The complain about ethical gnu stuff seems a bit wrong and IMHO doesn't really makes sense. The only complaint about github is that it has some limitations for CI and that it is run by ""evil"" MS. Aside from that if used correctly Github is very powerful. Just check some project like vscode or terminal where you can set bot to quickly handle wrongly formatted issues or pr. (I notice we have many) Currently the system for reporting bug is problematic and most of the time users don't even know it's a thing. Also the priority and the tracking system is a bit wrong. On top of that, moving importance to github would also makes devs care more about pr on Github instead of only checking the mailing list. Using the mailing list is good for devs that mainly focus on kernel and stuff but it's a nightmare for WIP or very big project like kernel transition or platform change. Another good tools that would benefit openwrt by using github is all the project system or also the basic milestone thing. Would be good to start creating an Issue that would summarize the target for a specific release. That would massively increase the tracking of it and make it clear where to focus. In short, my idea is to try in every way possible to unify stuff and start using more tools/feature to make it clear the current development state. There was a proposal of dropping the opkg upgrade stuff and move to a "quicker" release phase (aka publish more version). It's a little OT but I still think it's related to this kind of change. Using the project/milestone feature would remove all the hassle of creating a changelog/wiki entry/forum post for free as these minor releases will be on github with a linked issue/milestone. One small complaint I have is that I notice in the last few months a bit of confusion of the main target for the next release. We have the wiki page but we have no way to check the status. Example: - fw4 transition, we have a github issue but we were in a limbo for at least a month and current situation is to set it by default to force packages dev to update their package - 5.10 transition, email on mailing list and issue on a dev github page that got lost - dsa transition, many wip pr no tracking - ujail no idea but massive work under the hood by some packages? I'm an active openwrt user and many times I find some difficulties tracking the development state. Most of the time I check the git page and watch feature magically appear but it would be good to have a better tracking system and know what is the current direction of the team. In short, I'm very positive about a github migration but I really advise to put some effort and make it the right way by giving user/external devs more info about the current development state. (and also introduce some bots to autoclose/auto alert user of bad pr/issue to prevent any junk) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[firewall3 PATCH] firewall3: support async table init in 5.15+ kernel
With 5.15+ tables are init in an async way. Firewall3 use the proc entry
ip_tables_names to check if a table exist. With this new implemenation,
the proc entry can contain wrong data in the case where a table is
present but never used/init and firewall3 would uncorrectly think that
the table is not available. This cause some connection problem as from a
normal boot the proc entry contains only the "filter" table and
lacks "raw","mangle" and "nat".
To fix this "poke" the tables to init them by simply open and closing
them without doing any operation. This simple operation is sufficient to
make the missing tables appear in the proc entry.
Signed-off-by: Ansuel Smith
---
main.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/main.c b/main.c
index 7ad00b4..796ae80 100644
--- a/main.c
+++ b/main.c
@@ -266,6 +266,21 @@ start(void)
continue;
}
+ /* From 5.15+ tables are created async as soon as the first rule
+* is created or any operation is requested. This cause the
+* *_tables_names to report wrong data / missing tables.
+* Poke ipt to init the tables so fw3_has_table correctly
detects
+* them with the proc entires.
+*/
+ for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; table++)
+ {
+
+ if (!(handle = fw3_ipt_open(family, table)))
+ continue;
+
+ fw3_ipt_close(handle);
+ }
+
for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; table++)
{
if (!fw3_has_table(family == FW3_FAMILY_V6,
fw3_flag_names[table]))
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH 1/2] iwinfo: add support for indoor only chan restriction
> > Hi Ansuel, > > below are a few comments from someone (me) who is not very familiar > with the whole topic. So please keep this in mind. > > On Thu, Nov 18, 2021 at 5:42 PM Ansuel Smith wrote: > > > > Some country permit a specific channel to be used only indoor. > country -> countries > indoor -> indoors > > > Introduce a new restriction_flags entry to declare different restrition > restrition -> restrictions > > [...] > > + if > > (freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY]) > > + e->restricted_flags |= > > IWINFO_FREQ_NO_OUTDOOR; > Is there a reason why _INDOOR_ONLY has to be translated to _NO_OUTDOOR? > Or in other words: why not simply IWINFO_FREQ_INDOOR_ONLY > It seems more descriptive to declare and i think in a normal freq list it is declared as no outdoor instead of indoor only. > > Best regards, > Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH 1/2] iwinfo: add support for indoor only chan restriction
>
>
> Ansuel Smith wrote:
> > Some country permit a specific channel to be used only indoor.
> > Introduce a new restriction_flags entry to declare different
> > restrition of a specific channel.
> >
> > Signed-off-by: Ansuel Smith
> > ---
> > include/iwinfo.h | 4
> > iwinfo_nl80211.c | 14 ++
> > 2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/iwinfo.h b/include/iwinfo.h
> > index 8469ee7..3543b91 100644
> > --- a/include/iwinfo.h
> > +++ b/include/iwinfo.h
> > @@ -61,6 +61,9 @@
> > #define IWINFO_FREQ_NO_160MHZ(1 << 5)
> > #define IWINFO_FREQ_NO_2160MHZ (1 << 6)
> >
> > +#define IWINFO_FREQ_NO_IR(1 << 0)
> > +#define IWINFO_FREQ_NO_OUTDOOR (2 << 0)
>
> That's a pretty non-standard way of defining bits? Did you really
> mean (1<<0) and (1<<1) ?
>
Yes sorry... Copy paste error and then a microstroke in my brain LOL.
Will fix in v2 with other changes if needed.
> Sincerely,
> Karl Palsson
>
> > +
> > extern const char *IWINFO_CIPHER_NAMES[IWINFO_CIPHER_COUNT];
> > extern const char *IWINFO_KMGMT_NAMES[IWINFO_KMGMT_COUNT];
> > extern const char *IWINFO_AUTH_NAMES[IWINFO_AUTH_COUNT];
> > @@ -168,6 +171,7 @@ struct iwinfo_freqlist_entry {
> > uint8_t channel;
> > uint32_t mhz;
> > uint8_t restricted;
> > + uint32_t restricted_flags;
> > uint32_t flags;
> > };
> >
> > diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> > index c4b0ee2..57f820a 100644
> > --- a/iwinfo_nl80211.c
> > +++ b/iwinfo_nl80211.c
> > @@ -2911,10 +2911,16 @@ static int nl80211_get_freqlist_cb(struct nl_msg
> > *msg, void *arg)
> > e->mhz =
> > nla_get_u32(freqs[NL80211_FREQUENCY_ATTR_FREQ]);
> > e->channel =
> > nl80211_freq2channel(e->mhz);
> >
> > - e->restricted = (
> > -
> > freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
> > -
> > !freqs[NL80211_FREQUENCY_ATTR_RADAR]
> > - ) ? 1 : 0;
> > + e->restricted =
> > (freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
> > +
> > !freqs[NL80211_FREQUENCY_ATTR_RADAR]) ||
> > +
> > freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY];
> > +
> > + if
> > (freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
> > +
> > !freqs[NL80211_FREQUENCY_ATTR_RADAR])
> > + e->restricted_flags |=
> > IWINFO_FREQ_NO_IR;
> > +
> > + if
> > (freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY])
> > + e->restricted_flags |=
> > IWINFO_FREQ_NO_OUTDOOR;
> >
> > if
> > (freqs[NL80211_FREQUENCY_ATTR_NO_HT40_MINUS])
> > e->flags |=
> > IWINFO_FREQ_NO_HT40MINUS;
> > --
> > 2.32.0
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[rpcd PATCH 2/2] rpcd: iwinfo: export no_outdoor restriction
A channel can declare restriction where it should be used only indoor. Export this restriction in the channel data. Signed-off-by: Ansuel Smith --- iwinfo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/iwinfo.c b/iwinfo.c index ba4fc1e..85860e6 100644 --- a/iwinfo.c +++ b/iwinfo.c @@ -723,6 +723,9 @@ rpc_iwinfo_freqlist(struct ubus_context *ctx, struct ubus_object *obj, blobmsg_add_u32(&buf, "mhz", f->mhz); blobmsg_add_u8(&buf, "restricted", f->restricted); + blobmsg_add_bool(&buf, "no_outdoor", f->restricted_flags & +IWINFO_FREQ_NO_OUTDOOR); + if (ch > -1) blobmsg_add_u8(&buf, "active", f->channel == ch); -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[iwinfo PATCH 1/2] iwinfo: add support for indoor only chan restriction
Some country permit a specific channel to be used only indoor.
Introduce a new restriction_flags entry to declare different restrition
of a specific channel.
Signed-off-by: Ansuel Smith
---
include/iwinfo.h | 4
iwinfo_nl80211.c | 14 ++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 8469ee7..3543b91 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -61,6 +61,9 @@
#define IWINFO_FREQ_NO_160MHZ (1 << 5)
#define IWINFO_FREQ_NO_2160MHZ (1 << 6)
+#define IWINFO_FREQ_NO_IR (1 << 0)
+#define IWINFO_FREQ_NO_OUTDOOR (2 << 0)
+
extern const char *IWINFO_CIPHER_NAMES[IWINFO_CIPHER_COUNT];
extern const char *IWINFO_KMGMT_NAMES[IWINFO_KMGMT_COUNT];
extern const char *IWINFO_AUTH_NAMES[IWINFO_AUTH_COUNT];
@@ -168,6 +171,7 @@ struct iwinfo_freqlist_entry {
uint8_t channel;
uint32_t mhz;
uint8_t restricted;
+ uint32_t restricted_flags;
uint32_t flags;
};
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index c4b0ee2..57f820a 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -2911,10 +2911,16 @@ static int nl80211_get_freqlist_cb(struct nl_msg *msg,
void *arg)
e->mhz =
nla_get_u32(freqs[NL80211_FREQUENCY_ATTR_FREQ]);
e->channel =
nl80211_freq2channel(e->mhz);
- e->restricted = (
-
freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
-
!freqs[NL80211_FREQUENCY_ATTR_RADAR]
- ) ? 1 : 0;
+ e->restricted =
(freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
+
!freqs[NL80211_FREQUENCY_ATTR_RADAR]) ||
+
freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY];
+
+ if (freqs[NL80211_FREQUENCY_ATTR_NO_IR]
&&
+
!freqs[NL80211_FREQUENCY_ATTR_RADAR])
+ e->restricted_flags |=
IWINFO_FREQ_NO_IR;
+
+ if
(freqs[NL80211_FREQUENCY_ATTR_INDOOR_ONLY])
+ e->restricted_flags |=
IWINFO_FREQ_NO_OUTDOOR;
if
(freqs[NL80211_FREQUENCY_ATTR_NO_HT40_MINUS])
e->flags |=
IWINFO_FREQ_NO_HT40MINUS;
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: warning about which deprecated
Il giorno dom 7 nov 2021 alle ore 19:18 Bjørn Mork ha scritto: > > Ansuel Smith writes: > > > Updating to latest ubuntu devel this now comes up > > /home/ansuel/openwrt/staging_dir/host/bin/which: this version of > > `which' is deprecated; use `command -v' in scripts instead. > > > > I think we have to update something? > > See https://lwn.net/SubscriberLink/874049/b563dc08d4eb5829/ for the full > story. > > > Bjørn Should we consider building it as a toolchain tool or should we migrate to command -v ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
warning about which deprecated
Updating to latest ubuntu devel this now comes up /home/ansuel/openwrt/staging_dir/host/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead. I think we have to update something? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Il giorno sab 2 ott 2021 alle ore 01:35 Rosen Penev ha scritto: > > On Fri, Oct 1, 2021 at 3:05 PM Hauke Mehrtens wrote: > > > > On 9/30/21 10:40 PM, Paul Spooren wrote: > > > > > > On 9/30/21 10:01, Nick wrote: > > >> > > >> On 9/30/21 21:43, Daniel Golle wrote: > > >>> On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote: > > On 30/09/2021 01:19, Nick wrote: > > > On 9/29/21 22:28, Hauke Mehrtens wrote: > > > > > >> kernel 5.10: > > >> We should get all targets to kernel 5.10. All targets which are not > > >> on kernel 5.10 when we branch off should get removed. > > > Kernel 5.15 could be also a LTS Kernel that should be released in the > > > end of October? Why not aiming for it if we plan to release in 2022? > > This would undoubtedly delay the next release, as we've seen in the > > past. We don't even have all targets on 5.10, which was released > > roughly > > 9 months ago. You do the math. If we target 5.15, I doubt we'll even > > see > > a release in 2022. > > >>> I also believe we should do the next release based on Linux 5.10 and > > >>> try branching still this year (which I believe is realistic to make all > > >>> targets build with 5.10 till then), so we can target April 2022 as time > > >>> of release. > > > > I agree with you Daniel and think this timeline is reasonable. > > > > >> Sounds good, so we can go on with 5.15 when it is released? > > > > > > Some targets already moved to 5.10 as default, feel free to add 5.15 as > > > the new TESTING kernel there. > > > > I am against adding support for kernel 5.15 now, we should better wait > > till after we branched the relase off. > > > > > > > >> I think the most problematic thing is if we want to have DSA support > > >> for all targets as requirement. Not sure if this is possible. > > > > > > It seems fine found a okay'ish middle ground between DSA and non-DSA, so > > > I'd not make DSA blocking for the next release but continue to integrate > > > it where ever possible (and stable). > > > > I think we will never convert all swconfig drivers to DSA. I do not > > think anyone will invest the time to write a DSA driver for the ADM6996L > > chip for example. It could be that we just remove support for the last > > boards which still use swconfig in some years. > Not that many look like they can get DSA treatment. With realtek > switches, only RTL8366RB seems supported upstream. ar8216 can be Wait. Ar8216 can't be supported for qca8k (extensive rework of the entire driver. He has an entirely different scheme. qca8k = ar8326 8337 Do you have a list of the ar8216 devices? > replaced by qca8k currently but lots of testing is needed. I have no > idea about mediatek and why it has an swconfig driver when there's a > DSA one upstream. > > > > Hauke > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uci: unnecessary write accesses
>
>
> 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.
AFAIK tmp config are written in /tmp...
> 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'?
That is the tmp file (in theory)
the idea is uci set creates the tmp file
uci commit apply the tmp file to the /etc/config directory
>
>
> To do this without my script on the console, the following command can
> be used on the shell:
> inotifywait --quiet --monitor -e
> "create,delete,modify,close_write,attrib" /etc/config
>
> Then you will get the following output if you change an option with uci:
> /etc/config/ CREATE .system.uci-lOlFid
> /etc/config/ MODIFY .system.uci-lOlFid
> /etc/config/ MODIFY .system.uci-lOlFid
> /etc/config/ CLOSE_WRITE,CLOSE .system.uci-lOlFid
> /etc/config/ CLOSE_WRITE,CLOSE system
> /etc/config/ ATTRIB .system.uci-lOlFid
>
> ---
> Florian
>
> [1]
> https://github.com/openwrt/packages/blob/master/utils/inotify-tools/Makefile
> [2] https://www.man7.org/linux/man-pages/man1/inotifywait.1.html
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Build issues gcc10
> > > -Original Message- > > From: Ansuel Smith [mailto:ansuels...@gmail.com] > > Sent: Sonntag, 12. September 2021 19:18 > > To: Rui Salvaterra > > Cc: Adrian Schmutzler ; OpenWrt Development > > List > > Subject: Re: Build issues gcc10 > > > > Il giorno dom 12 set 2021 alle ore 19:16 Rui Salvaterra > > ha scritto: > > > > > > Hi, Adrian, > > > > > > On Sun, 12 Sept 2021 at 15:15, Adrian Schmutzler > > > wrote: > > > > > > > > I'm having build issues with master and (default) gcc10 on ipq targets. > > > > > > I don't know about ipq, but I jumped straight to GCC 11.2. Does it > > > make sense to bother with 10? That said… > > > > > > > xgcc: fatal error: cannot execute 'cc1plus': execvp: No such file or > > > > directory > > > > > > … you seem to be missing the C++ compiler. > > > > A missing dependency for the prereq? Could be that they changed the > > default package for debian 10 and 11 and nobody notice that? > > That was my first suspicion as well, but I didn't really have a good idea > what's missing ... > > Did you try reinstalling build-essential ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Build issues gcc10
Il giorno dom 12 set 2021 alle ore 19:16 Rui Salvaterra ha scritto: > > Hi, Adrian, > > On Sun, 12 Sept 2021 at 15:15, Adrian Schmutzler > wrote: > > > > I'm having build issues with master and (default) gcc10 on ipq targets. > > I don't know about ipq, but I jumped straight to GCC 11.2. Does it > make sense to bother with 10? That said… > > > xgcc: fatal error: cannot execute 'cc1plus': execvp: No such file or > > directory > > … you seem to be missing the C++ compiler. A missing dependency for the prereq? Could be that they changed the default package for debian 10 and 11 and nobody notice that? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
> > > Is there any situation where the user would need to decide whether DSA or > > swconfig should be used, assuming both are working? A kmod may be > > Just a side note on this: > Having a user choice between drivers should not be a development goal by any > means here. > If it happens "by accident" due to other changes, there is nothing to say > against it. > But experience tells it's hard enough to properly support one configuration, > so we definitely should not invest work in providing a choice here just for > its own sake (always referring to different drivers on a single device, of > course). > > Best > > Adrian > > I see your point. Anyway with some early test it looks like having both the qca8k driver and the swconfig driver cause some slowdown as the swconfig driver is init unconditionally (no compatible check) and try to probe and wait for a timeout in scanning the switch. So with the introduction of qca8k for a target we will have to drop the swconfig driver totally or slowdown (that looks like stall) will occur. Anyway the basepatch pr is having positive effects and we tested that on a ath79 device with positive results (only one problem with vlan that was caused by a bad configuration) > > justified for devices having issues supporting the DSA driver. Another > option > > is to have DSA/non-DSA subtargets but there seems to be pushback against > > this. > > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Ramfs (and img build) compilation error
Hi, i'm having some compilation error where it seems the buildroot is using my host bin to compress the ramfs or img image. How can I backtrack this error? I currently get this error if I change the compression algo. Could there be a problem in detecting missing tools and building them? I'm 100% the buildroot is trying to use my host bin since it does complain about "Not found" and if I install the missing tool, it then complain for illegal option. Is this intended? Coincidentally now i'm building another target (from ipq806x to ath79) and this time it started to build the lzma tools. Any hint about this? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
Il giorno gio 9 set 2021 alle ore 22:20 Ansuel Smith ha scritto: > > Il giorno gio 9 set 2021 alle ore 22:19 Rafał Miłecki > ha scritto: > > > > wt., 7 wrz 2021 o 18:53 Ansuel Smith napisał(a): > > > I currently have a pr open [1] to migrate ipq806x to > > > dsa driver > > > > Can you paste a missing link, please? > > > > -- > > Rafał > > Yes sorry i was referring to this. > https://github.com/openwrt/openwrt/pull/4036 Anyway we have now https://github.com/openwrt/openwrt/pull/4528 with the qca8k patches in generic. Think merging/reviewing that is the first step for all of this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
Il giorno gio 9 set 2021 alle ore 22:19 Rafał Miłecki ha scritto: > > wt., 7 wrz 2021 o 18:53 Ansuel Smith napisał(a): > > I currently have a pr open [1] to migrate ipq806x to > > dsa driver > > Can you paste a missing link, please? > > -- > Rafał Yes sorry i was referring to this. https://github.com/openwrt/openwrt/pull/4036 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
> > > On 09/09/2021 01:04, Stefan Lippers-Hollmann wrote: > > > I'm not really in a position to give advice, but -imho- unless those > > other targets have at least proof-of-concept code for using qca8k on > > their devices /working/ and an intention to migrate to DSA for these > > devices within reasonable time frame, I personally wouldn't overthink > > this (yet). > > > > There is no problem with adding these patches for ipq806x first, and then > > moving the patches from ipq806x to generic later, when there is something > > tangible for ath79 or bcm53xx (as part of their PRs/ patch series to > > migrate from swconfig to qca8k). > > In fact we are at this stage with the bcm53xx Meraki MX65[1] which is > just about ready to go, but requires part of Ansuel's series which is > currently destined for ipq806x only in his PR[2]. This may be held up > while more devices are tested so my suggestion is to get the series > into generic/backports so the MX65 can use it while testing continues > on other platforms. Moving it later would mean having some duplication > in the bcm53xx/ipq806x platform directories until then. Perhaps that is > acceptable if it will only be temporary? > > The other, perhaps main question is whether reintroducing dsa.mk is the > correct approach. Adding the kmod to the relevant platform's modules.mk > or kernel/linux/modules/netdevices.mk are alternatives. > > I am happy to submit a patch for whichever option is preferred, though > whether this should be done within my PR, as a new PR or on the mailing > list I'm not sure. I also don't wish to interfere with Ansuel's work so > would prefer to have the idea accepted by him first before doing > anything. > > [1] https://github.com/openwrt/openwrt/pull/3996 > [2] https://github.com/openwrt/openwrt/pull/4036 > > Matthew As long as we make a decision on what to do, everything is ok for me. It seems redundant to merge qca8k for ipq806x and then do a pr to move the patch to generic. At this point I would suggest to change the current pr, move the qca8k patch to generic and create a specific pr later to improve support for other targets. Having the patch merged will reduce the review process as reviewers won't have to check 20+ patches but instead only the related one to the target. In short my suggestion would be: 1. split qca8k patch from the current ipq806x pr 2. make a separate pr to add qca8k patch to generic (only for 5.10+ kernel) 3. review and try to quickly merge the generic pr 4. make separate pr to test qca8k on the specific target That way we can selectively work on the changes required for the specific target starting from a base patch instead of referring to a pr and ask if that change can be included in the big pr. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] ipq806x: backport cpufreq changes to 5.4
Il giorno mer 8 set 2021 alle ore 02:11 Shane Synan ha scritto: > > On 8/24/21 7:21 PM, Shane Synan wrote: > > The fix hasn't been found, but progress has been made! > > > > After further testing, I think I've found a way to recreate this issue > > with just the router itself, no external USB HDD, no Déjà Dup backup > > over SFTP, and possibly no extra changes beyond a stock NBG6817 > > OpenWRT build (not confirmed as this router runs my home network, > > including SQM QoS, VLANs with another WiFi AP, etc). > > So far, I've attempted all three suggested fixes, but I had trouble > implementing one and I'm unsure if I tried the other two correctly. > Additionally, pinning to "performance" for 1.75 GHz does not solve > the issue either - more on that near the end. > > I've put all of my commits into one branch for easier reference: > https://github.com/openwrt/openwrt/compare/master...digitalcircuit:ft-fix-ipq8065-reset > > And I've used my simplified automatic QA script for verification: > https://github.com/digitalcircuit/openwrt-ipq806x-qa-cpu-reset#readme > > (In theory, anyone should be able to reproduce the issue with this > script on a stock OpenWRT build. I'll still do testing with the > Déjà Dup SFTP backup workload.) > > > Suggestions and results in order of attempt: > (Ignore "ipq8065: force CPUs to share DVFS scaling", wrong method.) > > > 1. Raising clock latency (commits with "clock latency" in subject) > > I've tried raising the clock-latency-ns in the ipq8065 DTS by 100 > nanoseconds, a deliberately excessive value in the hopes of it being > enough to notice any issues. > > I've tried this for... > > * 1.4 GHz and 1.75 GHz > (ipq8065: raise 1.4 & 1.75 GHz clock latency) > * All CPU frequencies > (previous + ipq8065: raise all clock latency) > * All CPU frequencies and L2 cache latency > (previous + ipq8065: raise L2 cache, CPU core clock latency) > > Unfortunately, as noted in the revert commit, this seemed to have no > impact on the results from the QA script. > > I don't know if I've correctly implemented this suggestion. > > QA script log on b1870c2 (.tar.xz due to 12.2 MiB uncompressed size): > https://zorro.casa/sync/Hosting/Utilities/Development/OpenWRT/mailing-list/ipq806x_%20backport%20cpufreq%20changes%20to%205.4/debug-cpufreq%20-%20clock%20default%20test%20case1%20-%202021-08-30%2022-37-50%20-%20r17395-b1870c2530-branch-ft-fix-ipq8065-reset%20-%20date%20segfault%2C%20reboot%20-%20public.tar.xz > > > 2. Run both cores at the same frequency (most promising?) > > I tried to do this (ipq806x: Force CPU cores to share frequency), but > I think I didn't modify the cpufreq driver in the correct way. > > As noted in the revert commit, this didn't appear to force CPUs to > share frequency, whether manually using the performance governor or > periodically observing the ondemand governor - the CPU cores were at > different frequencies. > > I'll need help figuring out how to implement this in the cpufreq > driver correctly. It seems promising given that in the past, > dual-core bursty workloads didn't seem to trigger the crash. > > NOTE: Before diving into implementing this, read the conclusion below > as I've noticed reboots happen without changing CPU frequency as well. > > I'm also not sure how to debug the cpufreq driver in general. With > dynamic debugging, I can turn on messages about the cpufreq governor, > but I'm not sure of the right way to add dynamic debugging print > messages to the cpufreq driver. > > Example of dynamic debugging: > echo "file drivers/cpufreq/* =p" > /sys/kernel/debug/dynamic_debug/control > > QA script log on 1fdabd9 (.tar.xz due to 4.4 MiB uncompressed size): > https://zorro.casa/sync/Hosting/Utilities/Development/OpenWRT/mailing-list/ipq806x_%20backport%20cpufreq%20changes%20to%205.4/debug-cpufreq%20-%20clock%20default%20test%20case1%20-%202021-08-31%2020-38-04%20-%20r17397-1fdabd95db-branch-ft-fix-ipq8065-reset%20-%20date%20segfault%2C%20reboot%20-%20public.tar.xz > > > 3. Add forced frequency transitions between 1.0 GHz and 1.75 GHz > > I'm not sure if I implemented this correctly. I made a first attempt > (ipq806x: Add transitions to 1.0 <> 1.4 <> 1.75 GHz), but if the > frequency transitions happen, they're too fast to observe. And as > noted above, I'm not yet sure of the right way to add dynamic > debugging messages. > > Running the QA script in "case1" (toggle 800 MHz to 1.75 GHz) still > crashes. > > QA script log on 52f4f77 (.tar.xz due to 471.8 KiB uncompressed size): > https://zorro.casa/sync/Hosting/Utilities/Development/OpenWRT/mailing-list/ipq806x_%20backport%20cpufreq%20changes%20to%205.4/debug-cpufreq%20-%20clock%20default%20test%20case1%20-%202021-09-07%2019-58-07%20-%20r17399-52f4f77518-branch-ft-fix-ipq8065-reset%20-%20reboot%20-%20public.tar.xz > > Separately, I updated the QA script to add a "ramp1" case which > smoothly ramps the CPU core frequency up/down from 600 MHz to > 1.75 GHz, stopping at every frequency in between
Question about qca8k dsa driver and path to follow
I am writing this to ask for some help/direction on what path we should follow for the qca8k driver. I currently have a pr open [1] to migrate ipq806x to dsa driver (qca8k) but some other devs reported that the same switch is also used by other targets. (ath79, bcm53xx) It was suggested to move the entire patchset for qca8k to generic patch dir and start and adding the required patch to make qca8k work on the other target. Problem is that excluding ipq806x, not every device uses the qca8k switch and including that by default seems wrong. It was suggested to compile that as a module (with optionally the dsa subsistem as a kmod) so the driver (and dsa) can be installed only on the required devices. So the idea is to reintroduce the dsa.mk kernel modules makefile used some time ago for the mvebu target. In short the main concerns are: 1. Is it right to move qca8k patch to generic? 2. Should we move it to a kmod with the dsa subsystem or compile the driver built-in ? Also another concern would be: 1. Can we consider moving the ar8227 swconfig driver to kmod? That would make the transition easier since we will be able to include both the required nodes in the dts and make the user decide what to use. (by removing/installing the required kmod). Thanks in advice for any response to this and I hope we finally find a path to follow since the pr is currently stuck (well tested for ipq806x but waiting to be tested and adapted to work with other target) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Compilation problem with initramfs lzo compression
On build termination I have the current error. The error comes from the building of an initramfs with lzo compression selected The build env is ubuntu with devel package selected. make[5]: Entering directory '/home/ansuel/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.10.60' SYNCinclude/config/auto.conf.cmd net/sched/Kconfig:45: warning: menuconfig statement without prompt CALLscripts/atomic/check-atomics.sh CALLscripts/checksyscalls.sh GEN usr/initramfs_data.cpio CHK include/generated/compile.h CC lib/decompress.o CC lib/lz4/lz4_decompress.o AR lib/lz4/built-in.a AR lib/lib.a AR lib/built-in.a LZ4 usr/initramfs_inc_data Illegal option -l make[6]: *** [usr/Makefile:87: usr/initramfs_inc_data] Error 2 make[6]: *** Deleting file 'usr/initramfs_inc_data' make[5]: *** [Makefile:1822: usr] Error 2 make[5]: Leaving directory '/home/ansuel/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.10.60' make[4]: *** [Makefile:49: /home/ansuel/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.10.60/.image] Error 2 make[4]: Leaving directory '/home/ansuel/openwrt/target/linux/ipq806x' make[3]: *** [Makefile:11: install] Error 2 make[3]: Leaving directory '/home/ansuel/openwrt/target/linux' time: target/linux/install#26.76#6.39#15.29 ERROR: target/linux failed to build. make[2]: *** [target/Makefile:25: target/linux/install] Error 1 make[2]: Leaving directory '/home/ansuel/openwrt' make[1]: *** [target/Makefile:19: /home/ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/stamp/.target_install] Error 2 make[1]: Leaving directory '/home/ansuel/openwrt' make: *** [/home/ansuel/openwrt/include/toplevel.mk:230: world] Error 2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: convert mtd-mac-address to nvmem implementation
Il giorno mar 20 lug 2021 alle ore 21:03 Adrian Schmutzler ha scritto: > > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Ansuel Smith > > Sent: Montag, 19. Juli 2021 16:25 > > To: e9hack; ynezz > > Cc: openwrt-devel > > Subject: convert mtd-mac-address to nvmem implementation > > > > hi, > > some dtsi still use the old implementation as they have to be manually > > I thought we should not delay updating the majority of devices with this > problem. > > I will take care of the remaining ones as soon as I can, and try to work out > a sensible setup for the DTSI/DTS rearrangements. > > Best > > Adrian Hi, can you consider give some feedback on the closed pr [1] We currently have get_mac_label_dt that is currently broken. I'm putting some ideas on how to fix that. [1] https://github.com/openwrt/openwrt/pull/4041 > > > migrated. Does it cause any problem ? > > > > > Hi, it looks like, that qca9558_tplink_archer-c.dtsi is missing in > > > commit abc17bf (ath79: convert mtd-mac-address to nvmem > > > implementation). Regards, Hartmut > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
convert mtd-mac-address to nvmem implementation
The dts has been migrated with a script and we decided to remove the dtsi that caused some compilation problem. We still need to take a decision for the device that have dtsi that declare mtd-mac-address using partition tag declared in user dts (dtsi use partition declared in the dts) > I don't see a problem. I did check the dtsi files of the two routers which > I'm using. One is migrated and the other one was still missing. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
convert mtd-mac-address to nvmem implementation
hi, some dtsi still use the old implementation as they have to be manually migrated. Does it cause any problem ? > Hi, it looks like, that qca9558_tplink_archer-c.dtsi is missing in commit > abc17bf (ath79: convert mtd-mac-address to nvmem implementation). Regards, > Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 6in4 tunnel creation sometimes goes into infinite loop on kernel 5.10
> > For details see FS#3690, created months ago but no progress has been made. > I hope it can be fixed ASAP. > > Regards, > Qingfang > Can confirm the bug... I also asked for support on the forum, didn't know it was present also on other users. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] ipq806x: backport cpufreq changes to 5.4
Il giorno dom 27 giu 2021 alle ore 23:41 Baptiste Jonglez ha scritto: > > Hi, > > On 20-06-21, Shane Synan wrote: > > In the time since submitting this, I've continued testing this > > change on my ZyXEL NBG6817. I'm reasonably confident this fixes my > > issue (11/11 successes), and if there's any further testing that > > would help, let me know! > > Thanks for the patch and testing, I'd like to merge it in the next few > days (before 21.02.0 final). I'll update the commit message. > > Ansuel, do you have any feedback on this backport? It seems to help things. > > Thanks, > Baptiste It's good but consider that also the dts changes are required and also there is a pending pr that has to be merged or ipq8065 device will run at lower speed. The new cpufreq have changed the node definition This is the pr I'm talking about. https://github.com/openwrt/openwrt/pull/4192 So in short this backport lacks the dts changes and the pr4192 is mandatory or we will introduce perf regression in 21 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mac80211: split ath patch in dedicated subdir
The ath patch number is already large and adding other patch for ath11k
will add more confusion with the patch numbering.
Since the support of ath11k based device is imminent, prepare the mac80211
ath patch dir and split it in the dedicated ath5k, ath9k, ath10k and ath11k
(empty for now).
Signed-off-by: Ansuel Smith
---
package/kernel/mac80211/Makefile | 8
.../{ath => ath10k}/080-ath10k_thermal_config.patch | 0
...0k-add-CCMP-PN-replay-protection-for-fragmented-.patch | 0
...ath10k-drop-fragments-with-multicast-DA-for-PCIe.patch | 0
...ath10k-drop-fragments-with-multicast-DA-for-SDIO.patch | 0
...0k-drop-MPDU-which-has-discard-flag-set-by-firmw.patch | 0
...th10k-Fix-TKIP-Michael-MIC-verification-for-PCIe.patch | 0
...0k-Validate-first-subframe-of-A-MSDU-before-proc.patch | 0
.../921-ath10k_init_devices_synchronously.patch | 0
.../922-ath10k-increase-rx-buffer-size-to-2048.patch | 0
.../{ath => ath10k}/930-ath10k_add_tpt_led_trigger.patch | 0
...nd-GPIO-controlling-support-for-various-chipsets.patch | 0
.../975-ath10k-use-tpt-trigger-by-default.patch | 0
.../980-ath10k-fix-max-antenna-gain-unit.patch| 0
...0k-adjust-tx-power-reduction-for-US-regulatory-d.patch | 0
.../{ath => ath5k}/201-ath5k-WAR-for-AR71xx-PCI-bug.patch | 0
.../{ath => ath5k}/411-ath5k_allow_adhoc_and_ap.patch | 0
.../{ath => ath5k}/420-ath5k_disable_fast_cc.patch| 0
.../patches/{ath => ath5k}/430-add_ath5k_platform.patch | 0
.../patches/{ath => ath5k}/432-ath5k_add_pciids.patch | 0
.../{ath => ath5k}/440-ath5k_channel_bw_debugfs.patch | 0
.../350-ath9k_hw-reset-AHB-WMAC-interface-on-AR91xx.patch | 0
.../351-ath9k_hw-issue-external-reset-for-QCA955x.patch | 0
.../354-ath9k-force-rx_clear-when-disabling-rx.patch | 0
...rt-ath9k-interpret-requested-txpower-in-EIRP-dom.patch | 0
...k-adjust-tx-power-reduction-for-US-regulatory-do.patch | 0
.../patches/{ath => ath9k}/401-ath9k_blink_default.patch | 0
.../{ath => ath9k}/410-ath9k_allow_adhoc_and_ap.patch | 0
...450-ath9k-enabled-MFP-capability-unconditionally.patch | 0
.../patches/{ath => ath9k}/500-ath9k_eeprom_debugfs.patch | 0
.../patches/{ath => ath9k}/501-ath9k_ahb_init.patch | 0
.../{ath => ath9k}/510-ath9k_intr_mitigation_tweak.patch | 0
.../patches/{ath => ath9k}/511-ath9k_reduce_rxbuf.patch | 0
.../{ath => ath9k}/512-ath9k_channelbw_debugfs.patch | 0
.../patches/{ath => ath9k}/513-ath9k_add_pci_ids.patch| 0
.../patches/{ath => ath9k}/530-ath9k_extra_leds.patch | 0
.../{ath => ath9k}/531-ath9k_extra_platform_leds.patch| 0
.../{ath => ath9k}/540-ath9k_reduce_ani_interval.patch| 0
.../patches/{ath => ath9k}/542-ath9k_debugfs_diag.patch | 0
.../{ath => ath9k}/543-ath9k_entropy_from_adc.patch | 0
.../544-ath9k-ar933x-usb-hang-workaround.patch| 0
.../patches/{ath => ath9k}/545-ath9k_ani_ws_detect.patch | 0
.../{ath => ath9k}/547-ath9k_led_defstate_fix.patch | 0
.../{ath => ath9k}/548-ath9k_enable_gpio_chip.patch | 0
.../{ath => ath9k}/549-ath9k_enable_gpio_buttons.patch| 0
.../{ath => ath9k}/550-ath9k-disable-bands-via-dt.patch | 0
.../{ath => ath9k}/551-ath9k_ubnt_uap_plus_hsr.patch | 0
.../552-ahb_of.patch => ath9k/552-ath9k-ahb_of.patch} | 0
.../patches/{ath => ath9k}/553-ath9k_of_gpio_mask.patch | 0
49 files changed, 8 insertions(+)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/080-ath10k_thermal_config.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/300-ath10k-add-CCMP-PN-replay-protection-for-fragmented-.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/301-ath10k-drop-fragments-with-multicast-DA-for-PCIe.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/302-ath10k-drop-fragments-with-multicast-DA-for-SDIO.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/303-ath10k-drop-MPDU-which-has-discard-flag-set-by-firmw.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/304-ath10k-Fix-TKIP-Michael-MIC-verification-for-PCIe.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/305-ath10k-Validate-first-subframe-of-A-MSDU-before-proc.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/921-ath10k_init_devices_synchronously.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/922-ath10k-increase-rx-buffer-size-to-2048.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/930-ath10k_add_tpt_led_trigger.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
(100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/975-ath10k-use-tpt-trigger-by-default.patch (100%)
Mac80211 ath patch split proposal
Hi, since we are starting to add support for ath11k i was thinking... To have things organized and remove some confusion, I was thinking if it wouldn't be better to split the ath patch dir to 3 (or 4) sub directory and introduce patch for ath9k, patch for ath10k and patch for ath11k with a 4th optional dir that apply to ath general directory? What do you think about this change? The mac80211 makefile already have a way to handle patch split in multiple dir so adding extra dir is not really harmful. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq806x: dwmac: fix GMACs connected via SGMII fixed-link
> fa731838c524 cleared the forced speed in the QSGMII PCS_ALL_CH_CTL
> register during probe, but this is only correct for GMACs that are not
> configured with fixed-link. This prevented GMACs configured with both
> phy-mode = "sgmii" and fixed-link from working properly, as discussed at
> https://github.com/openwrt/openwrt/pull/3954#issuecomment-834625090 and
> the comments that follow. Notably, this prevented all communication
> between gmac2 and the switch on the Netgear R7800.
>
> The correct behavior is to set the QSGMII PCS_ALL_CH_CTL register by
> considering the gmac's fixed-link child, setting the speed as directed by
> fixed-link if present, and otherwise clearing it as was done previously.
>
> Fixes: fa731838c524 ("ipq806x: dwmac: clear forced speed during probe")
> Signed-off-by: Mark Mentovai
> Tested-by: Hannu Nyman
> Run-tested: ipq806x/ubnt,unifi-ac-hd, ipq806x/netgear,r7800
> Cc: Petr Štetiar
> Cc: Ansuel Smith
> ---
> ...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 62 +++++++++--
> 1 file changed, 56 insertions(+), 6 deletions(-)
>
Tested-by: Ansuel Smith
I also tested this with the qca8k driver on 5.10. Also can you include
this with kernel 5.10
The patch applies without changes also for that kernel.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] Revert "dbus: update to 1.13.18"
> > This reverts commit 0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92. > > root@finn:/# /etc/init.d/dbus start > dbus[2537]: Failed to start message bus: Failed to open > "/dbus-1/system.conf": No such file or directory > The avahi package is also affected by this breakage and crash loop in the current master. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu: armada 370: dts: fix the crypto engine
> > Hi Hauke, > > El lun, 5 abr 2021 a las 14:55, Hauke Mehrtens () escribió: > > > > On 4/4/21 11:06 PM, Daniel González Cabanelas wrote: > > > The crypto engine in Armada 370 SoCs is currently broken. It can be > > > checked installing the required packages for testing openssl with hw > > > acceleration: > > > > > >opkg install openssl-util > > >opkg install kmod-cryptodev > > >opkg install libopenssl-devcrypto > > > > > > After configuring /etc/ssl/openssl.cnf to let openssl use the crypto > > > engine for digest operations, and performing some checksums.. > > > > > >md5sum 10M-file.bin > > >openssl md5 10M-file.bin > > > > > > ...we can see they don't match. > > > > > > There might be an alignment or size constraint issue caused by the > > > idle-sram area. > > > > > > Use the whole crypto sram and disable the idle-sram area to fix it. Also > > > disable the idle support by adding the broken-idle property to prevent > > > accessing the disabled idle-sram. > > > > > > We don't care about disabling the idle support since it is already broken > > > in Armada 370 causing a huge performance loss because it disables > > > permanently the L2 cache. This was reported in the Openwrt forum and > > > elsewhere by Debian users with different board models. > > > > Is the L2 cache disabled without or with this patch? > > The L2 Aurora cache is always disabled without the patch. > > With this patch it is enabled, therefore it fixes the crypto engine > and also the L2 cache issue. The side effect is a disabled idle > support which can be considered broken anyway. > Consider the fact that cpu-idle is disabled on mvebu by default so no regression. (there is a big warning about broken cpu-idle in the bootlog) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch mtd-mac-address to nvmem implementation
> > With a quick search, there are LOTS of dts that use these special bindings > > and it would take a lot of time to convert all the dts. (think the best > > approach > > would be to convert the dts one target at time) > > I think, that if you're willing to do that tedious hardwork, it's better to > tackle all this at once. Prepare the changes, ask for testing and once we've > few Tested-by: across popular targets it should be ready to merge. > > Thanks! > > Cheers, > > Petr I posted on github a pr about this. (think it's would be easier to review the changes there since 99% of the changes are just sed command to change the old binding) If anyone wants to check and give some opinion about the changes, feel free to add any comments. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Switch mtd-mac-address to nvmem implementation
The pending nvmem patches have been applied to mtd/next. Some time ago I also sent a patch with the mtd-mac-address-increment-byte upstream but it got rejected since dts should not contain this kind of binding. The patch directly implements the increment and increment-byte binding to the of_get_mac_address. So now the question, to clean things and follow a more standard framework, wouldn't be better to replace the patch generic pending/681 with a more generic implementation and convert all the dts to the standard mac-address binding and nvmem implementation? With a quick search, there are LOTS of dts that use these special bindings and it would take a lot of time to convert all the dts. (think the best approach would be to convert the dts one target at time) To improve this, I would propose to modify the 681 patch to only add the mtd-mac-address binding and the reading of the mac address from mtd and take my patch that implement the increment and increment-byte function to the general of_get_mac_address. This way the hard part of defining the nvmem cell can be postponed and the mtd-mac-address-increment-byte and mtd-mac-address-increment can simply be renamed to the new more generic mac-address-increment-byte and mac-address-increment binding with no regression since they implement the same thing in the same way. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Dsa multi-cpu port problem
> > On Wed, Mar 10, 2021 at 4:19 PM Ansuel Smith wrote: > > > > I'm working on the conversion of ipq806x to dsa. > > It's been 2 years and still dsa doesn't support multi-cpu port. > > Online there are many patches that add support for this but they were > > never accepted upstream since there isn't a solution that would work > > for all the switches. Fact is that openwrt is different and have some > > flexibility about this kind problem. > > There is actually a patchset (rejected) that adds multi-cpu support > > defined in the dts that can be used and doesn't look that bad. > > > > So here is the question: > > Considering the fact that at least 3 target have disabled port (mtk, > > mvebu and upcoming ipq806x) why not use the proposed patch > > while upstream a final solution is found for this problem? > > Turris already use a variant of that patch and also mediatek use > > it. > I closed https://github.com/openwrt/openwrt/pull/3655 since 21.02 was > branched. I would use that patchset as the Turris people are working > on upstreaming a bunch of stuff. Didn't know there was already a port of the variant. So in your opinion the round-robin should be the right solution. Turris and mediatek from what i found online used the original implementation with the cpu port hardcoded in the dts. I can only find rfc of the round-robin patch online, do you have more discussion about that? Curious to know if upstream they finally take a decision instead of keep staying in the limbo. > > > > The idea would be to place the patch as a hack in the generic > > target dir and targets can add patches to modify the dsa driver > > accordingly (if needed). > > > > (the multi-cpu variant i'm talking about it the one that statically > > link a port to a dedicated cpu port in the dts) > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Dsa multi-cpu port problem
I'm working on the conversion of ipq806x to dsa. It's been 2 years and still dsa doesn't support multi-cpu port. Online there are many patches that add support for this but they were never accepted upstream since there isn't a solution that would work for all the switches. Fact is that openwrt is different and have some flexibility about this kind problem. There is actually a patchset (rejected) that adds multi-cpu support defined in the dts that can be used and doesn't look that bad. So here is the question: Considering the fact that at least 3 target have disabled port (mtk, mvebu and upcoming ipq806x) why not use the proposed patch while upstream a final solution is found for this problem? Turris already use a variant of that patch and also mediatek use it. The idea would be to place the patch as a hack in the generic target dir and targets can add patches to modify the dsa driver accordingly (if needed). (the multi-cpu variant i'm talking about it the one that statically link a port to a dedicated cpu port in the dts) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Clarification about dsa and ipq806x
Hello, I just pushed a fist pr to the openwrt github repo for ipq806x port to kernel 5.10. The idea is to switch this target to dsa but there is a problem... Since kernel 5.10 is a testing kernel how should I change the base files to apply different network config? Kernel 5.4 would still use the old swconfig driver and the dsa driver still lacks vlan support in kernel 5.4. Do we have some way in openwrt to know if the system use dsa driver or swconfig driver? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
kernel 5.10: Wireguard wants some love
The compat module is no longer required and complains about wireguard included in kernel from version 5.6. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct iw missing rx stats
> > On 2021-02-14 18:28, Ansuel Smith wrote: > > With recent mac80211 bump I notice that rx stats > > are no longer displayed. > > I ported the atk10-ct patches to the version 5.10 > > and I noticed this. It's only me? > > Also this is only to report that ath10k-ct patches can > > be ported with minimal changes and works normally > > (except this problem with ubus not reporting rx stats) > It was an upstream regression. I backported the fix for it and it should > work now. > > - Felix Can confirm it does work now... Why not switch ath10k-ct to version 5.10 directly? That way we can drop the 300 patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Installation error for libncursesw6
> Collected errors: > * pkg_hash_fetch_best_installation_candidate: Packages for > libreadline8 found, but incompatible with the architectures configured > * opkg_install_cmd: Cannot install package libreadline8. > * satisfy_dependencies_for: Cannot satisfy the following dependencies > for softethervpn5-libs: > * libncursesw6 > * opkg_install_cmd: Cannot install package softethervpn5-libs. > make[2]: *** [package/Makefile:69: package/install] Error 255 > > Multiple packages complain about this... This is from a clean custom build. > Think this is caused by the abi changes to buildroot reverting c92165038217e49075098479704da58a2a3a89bd fix the problem ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Installation error for libncursesw6
Collected errors: * pkg_hash_fetch_best_installation_candidate: Packages for libreadline8 found, but incompatible with the architectures configured * opkg_install_cmd: Cannot install package libreadline8. * satisfy_dependencies_for: Cannot satisfy the following dependencies for softethervpn5-libs: * libncursesw6 * opkg_install_cmd: Cannot install package softethervpn5-libs. make[2]: *** [package/Makefile:69: package/install] Error 255 Multiple packages complain about this... This is from a clean custom build. Think this is caused by the abi changes to buildroot ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ath10k-ct iw missing rx stats
With recent mac80211 bump I notice that rx stats are no longer displayed. I ported the atk10-ct patches to the version 5.10 and I noticed this. It's only me? Also this is only to report that ath10k-ct patches can be ported with minimal changes and works normally (except this problem with ubus not reporting rx stats) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RPCD PATCH] iwinfo: include ht_operation data only if available
Check if ht_operation data are present and add them accordingly.
Signed-off-by: Ansuel Smith
---
iwinfo.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/iwinfo.c b/iwinfo.c
index 7c9a656..63ff2a1 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -455,11 +455,13 @@ rpc_iwinfo_scan(struct ubus_context *ctx, struct
ubus_object *obj,
blobmsg_add_u32(&buf, "quality", e->quality);
blobmsg_add_u32(&buf, "quality_max", e->quality_max);
- t = blobmsg_open_table(&buf, "ht_operation");
- blobmsg_add_u32(&buf, "primary_channel",
e->ht_chan_info.primary_chan);
- blobmsg_add_string(&buf, "secondary_channel_offset",
ht_secondary_offset[e->ht_chan_info.secondary_chan_off]);
- blobmsg_add_u32(&buf, "channel_width",
ht_chan_width[e->ht_chan_info.chan_width]);
- blobmsg_close_table(&buf, t);
+ if (e->ht_chan_info.primary_chan) {
+ t = blobmsg_open_table(&buf, "ht_operation");
+ blobmsg_add_u32(&buf, "primary_channel",
e->ht_chan_info.primary_chan);
+ blobmsg_add_string(&buf,
"secondary_channel_offset",
ht_secondary_offset[e->ht_chan_info.secondary_chan_off]);
+ blobmsg_add_u32(&buf, "channel_width",
ht_chan_width[e->ht_chan_info.chan_width]);
+ blobmsg_close_table(&buf, t);
+ }
if (e->vht_chan_info.center_chan_1) {
t = blobmsg_open_table(&buf, "vht_operation");
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[IWINFO PATCH] iwinfo: set center chan unsupported for not-nl80211 driver
Declare get_center_chan1 and get_center_chan2 not supported for not
nl80211 driver.
Signed-off-by: Ansuel Smith
---
iwinfo_madwifi.c | 14 ++
iwinfo_wext.c| 14 ++
iwinfo_wl.c | 14 ++
3 files changed, 42 insertions(+)
diff --git a/iwinfo_madwifi.c b/iwinfo_madwifi.c
index f28bca1..d27e6c9 100644
--- a/iwinfo_madwifi.c
+++ b/iwinfo_madwifi.c
@@ -394,6 +394,18 @@ static int madwifi_get_channel(const char *ifname, int
*buf)
return -1;
}
+static int madwifi_get_center_chan1(const char *ifname, int *buf)
+{
+ /* Not Supported */
+ return -1;
+}
+
+static int madwifi_get_center_chan2(const char *ifname, int *buf)
+{
+ /* Not Supported */
+ return -1;
+}
+
static int madwifi_get_frequency(const char *ifname, int *buf)
{
struct iwreq wrq;
@@ -,6 +1123,8 @@ const struct iwinfo_ops madwifi_ops = {
.name = "madwifi",
.probe= madwifi_probe,
.channel = madwifi_get_channel,
+ .center_chan1 = madwifi_get_center_chan1,
+ .center_chan2 = madwifi_get_center_chan2,
.frequency= madwifi_get_frequency,
.frequency_offset = madwifi_get_frequency_offset,
.txpower = madwifi_get_txpower,
diff --git a/iwinfo_wext.c b/iwinfo_wext.c
index ee02f3a..b68d230 100644
--- a/iwinfo_wext.c
+++ b/iwinfo_wext.c
@@ -185,6 +185,18 @@ static int wext_get_channel(const char *ifname, int *buf)
return -1;
}
+static int wext_get_center_chan1(const char *ifname, int *buf)
+{
+ /* Not Supported */
+ return -1;
+}
+
+static int wext_get_center_chan2(const char *ifname, int *buf)
+{
+ /* Not Supported */
+ return -1;
+}
+
static int wext_get_frequency(const char *ifname, int *buf)
{
struct iwreq wrq;
@@ -534,6 +546,8 @@ const struct iwinfo_ops wext_ops = {
.name = "wext",
.probe= wext_probe,
.channel = wext_get_channel,
+ .center_chan1 = wext_get_center_chan1,
+ .center_chan2 = wext_get_center_chan2,
.frequency= wext_get_frequency,
.frequency_offset = wext_get_frequency_offset,
.txpower = wext_get_txpower,
diff --git a/iwinfo_wl.c b/iwinfo_wl.c
index 80d3d7e..9ec78cd 100644
--- a/iwinfo_wl.c
+++ b/iwinfo_wl.c
@@ -144,6 +144,18 @@ static int wl_get_channel(const char *ifname, int *buf)
return wl_ioctl(ifname, WLC_GET_CHANNEL, buf, sizeof(buf));
}
+static int wl_get_center_chan1(const char *ifname, int *buf)
+{
+ /* Not Supported */
+ return -1;
+}
+
+static int wl_get_center_chan2(const char *ifname, int *buf)
+{
+ /* Not Supported */
+ return -1;
+}
+
static int wl_get_frequency(const char *ifname, int *buf)
{
return wext_ops.frequency(ifname, buf);
@@ -734,6 +746,8 @@ const struct iwinfo_ops wl_ops = {
.name = "wl",
.probe= wl_probe,
.channel = wl_get_channel,
+ .center_chan1 = wl_get_center_chan1,
+ .center_chan2 = wl_get_center_chan2,
.frequency= wl_get_frequency,
.frequency_offset = wl_get_frequency_offset,
.txpower = wl_get_txpower,
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[IWINFO PATCH] iwinfo: improve center channel handling
- Improve iwinfo center channel struct position
- Prevent read beyond buffer on malformed data
Signed-off-by: Ansuel Smith
---
include/iwinfo.h | 4 ++--
iwinfo_nl80211.c | 22 +-
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 5799c02..40ef3a7 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -255,6 +255,8 @@ struct iwinfo_ops {
int (*probe)(const char *ifname);
int (*mode)(const char *, int *);
int (*channel)(const char *, int *);
+ int (*center_chan1)(const char *, int *);
+ int (*center_chan2)(const char *, int *);
int (*frequency)(const char *, int *);
int (*frequency_offset)(const char *, int *);
int (*txpower)(const char *, int *);
@@ -283,8 +285,6 @@ struct iwinfo_ops {
int (*survey)(const char *, char *, int *);
int (*lookup_phy)(const char *, char *);
void (*close)(void);
- int (*center_chan1)(const char *, int *);
- int (*center_chan2)(const char *, int *);
};
const char * iwinfo_type(const char *ifname);
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 5ca5c03..ba5bddb 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -2380,14 +2380,18 @@ static void nl80211_get_scanlist_ie(struct nlattr **bss,
IWINFO_CIPHER_TKIP,
IWINFO_KMGMT_PSK);
break;
case 61: /* HT oeration */
- e->ht_chan_info.primary_chan = ie[2];
- e->ht_chan_info.secondary_chan_off = ie[3] & 0x3;
- e->ht_chan_info.chan_width = (ie[4] & 0x4)>>2;
+ if (ie[1] >= 3) {
+ e->ht_chan_info.primary_chan = ie[2];
+ e->ht_chan_info.secondary_chan_off = ie[3] &
0x3;
+ e->ht_chan_info.chan_width = (ie[4] & 0x4)>>2;
+ }
break;
case 192: /* VHT operation */
- e->vht_chan_info.chan_width = ie[2];
- e->vht_chan_info.center_chan_1 = ie[3];
- e->vht_chan_info.center_chan_2 = ie[4];
+ if (ie[1] >= 3) {
+ e->vht_chan_info.chan_width = ie[2];
+ e->vht_chan_info.center_chan_1 = ie[3];
+ e->vht_chan_info.center_chan_2 = ie[4];
+ }
break;
}
@@ -3317,6 +3321,8 @@ const struct iwinfo_ops nl80211_ops = {
.name = "nl80211",
.probe= nl80211_probe,
.channel = nl80211_get_channel,
+ .center_chan1 = nl80211_get_center_chan1,
+ .center_chan2 = nl80211_get_center_chan2,
.frequency= nl80211_get_frequency,
.frequency_offset = nl80211_get_frequency_offset,
.txpower = nl80211_get_txpower,
@@ -3345,7 +3351,5 @@ const struct iwinfo_ops nl80211_ops = {
.countrylist = nl80211_get_countrylist,
.survey = nl80211_get_survey,
.lookup_phy = nl80211_lookup_phyname,
- .close= nl80211_close,
- .center_chan1 = nl80211_get_center_chan1,
- .center_chan2 = nl80211_get_center_chan2
+ .close= nl80211_close
};
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2 iwinfo] iwinfo: add support for GCMP cipher
> > Extend support for WPA ciphers by GCMP which is required for 802.11ad. > Breaks ABI as ciphers now needs to be a field of 16 bits instead of 8. > If this gets accepted and we are changing the ABI, can we also add my changes for the wifi channel analysis feature? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools: zlib: fix broken compile with ccache enabled
If ccache is enabled with an empty buildroot the compilation fails. Fix this by using the NOCACHE compiler as it's done by other tools package. Signed-off-by: Ansuel Smith --- tools/zlib/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/zlib/Makefile b/tools/zlib/Makefile index 279851f..5dc311d 100644 --- a/tools/zlib/Makefile +++ b/tools/zlib/Makefile @@ -22,6 +22,7 @@ PKG_CPE_ID:=cpe:/a:gnu:zlib include $(INCLUDE_DIR)/host-build.mk include $(INCLUDE_DIR)/cmake.mk +CMAKE_HOST_C_COMPILER:=$(HOSTCC_NOCACHE) HOST_CFLAGS +=-fPIC define Host/Install -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Compilation error for host zilb from cmake
> > On Thu, Dec 17, 2020 at 1:57 PM Ansuel Smith wrote: > > > > Hello I can't currently compile openwrt on my system. > > The error is this > > https://gist.github.com/Ansuel/b5a6574ea912d56e8697984154d0ba42 > > > > Any idea why ? I have a very recent system with latest package (ubuntu > > devel branch) > Because you're using ccache. Temporarily disable and run make > tools/zlib/compile > > IMHO that's a problem that the build fails if someone selects ccache before compiling the host tools. I can confirm that disabling ccache works but can't this be fixed? > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Compilation error for host zilb from cmake
Hello I can't currently compile openwrt on my system. The error is this https://gist.github.com/Ansuel/b5a6574ea912d56e8697984154d0ba42 Any idea why ? I have a very recent system with latest package (ubuntu devel branch) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[IWINFO PATCH v4 2/4] iwinfo: export center_chan info for local wifi
Iwinfo already export the htmode but there is no way to know where the
channel expan in case a 40Mhz+ channel width is used. Export the center
channels used by the driver to better know the channel utilizzation of
the wifi.
Signed-off-by: Ansuel Smith
---
include/iwinfo.h | 2 ++
iwinfo_cli.c | 23 +++
iwinfo_nl80211.c | 76 +++-
3 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 676db91..680f384 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -282,6 +282,8 @@ struct iwinfo_ops {
int (*survey)(const char *, char *, int *);
int (*lookup_phy)(const char *, char *);
void (*close)(void);
+ int (*center_chan1)(const char *, int *);
+ int (*center_chan2)(const char *, int *);
};
const char * iwinfo_type(const char *ifname);
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index 6bfe0ab..cc5d298 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -445,6 +445,24 @@ static char * print_channel(const struct iwinfo_ops *iw,
const char *ifname)
return format_channel(ch);
}
+static char * print_center_chan1(const struct iwinfo_ops *iw, const char
*ifname)
+{
+ int ch;
+ if (iw->center_chan1(ifname, &ch))
+ ch = -1;
+
+ return format_channel(ch);
+}
+
+static char * print_center_chan2(const struct iwinfo_ops *iw, const char
*ifname)
+{
+ int ch;
+ if (iw->center_chan2(ifname, &ch))
+ ch = -1;
+
+ return format_channel(ch);
+}
+
static char * print_frequency(const struct iwinfo_ops *iw, const char *ifname)
{
int freq;
@@ -566,6 +584,11 @@ static void print_info(const struct iwinfo_ops *iw, const
char *ifname)
print_mode(iw, ifname),
print_channel(iw, ifname),
print_frequency(iw, ifname));
+ if (iw->center_chan1 != NULL) {
+ printf(" Center Channel 1: %s",
+ print_center_chan1(iw, ifname));
+ printf(" 2: %s\n", print_center_chan2(iw, ifname));
+ }
printf(" Tx-Power: %s Link Quality: %s/%s\n",
print_txpower(iw, ifname),
print_quality(iw, ifname),
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 5917e3a..1bcc5ea 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -1262,6 +1262,56 @@ static int nl80211_get_frequency(const char *ifname, int
*buf)
return (*buf == 0) ? -1 : 0;
}
+static int nl80211_get_center_freq1_cb(struct nl_msg *msg, void *arg)
+{
+ int *freq = arg;
+ struct nlattr **tb = nl80211_parse(msg);
+
+ if (tb[NL80211_ATTR_CENTER_FREQ1])
+ *freq = nla_get_u32(tb[NL80211_ATTR_CENTER_FREQ1]);
+
+ return NL_SKIP;
+}
+
+static int nl80211_get_center_freq1(const char *ifname, int *buf)
+{
+ char *res;
+
+ /* try to find frequency from interface info */
+ res = nl80211_phy2ifname(ifname);
+ *buf = 0;
+
+ nl80211_request(res ? res : ifname, NL80211_CMD_GET_INTERFACE, 0,
+ nl80211_get_center_freq1_cb, buf);
+
+ return (*buf == 0) ? -1 : 0;
+}
+
+static int nl80211_get_center_freq2_cb(struct nl_msg *msg, void *arg)
+{
+ int *freq = arg;
+ struct nlattr **tb = nl80211_parse(msg);
+
+ if (tb[NL80211_ATTR_CENTER_FREQ2])
+ *freq = nla_get_u32(tb[NL80211_ATTR_CENTER_FREQ2]);
+
+ return NL_SKIP;
+}
+
+static int nl80211_get_center_freq2(const char *ifname, int *buf)
+{
+ char *res;
+
+ /* try to find frequency from interface info */
+ res = nl80211_phy2ifname(ifname);
+ *buf = 0;
+
+ nl80211_request(res ? res : ifname, NL80211_CMD_GET_INTERFACE, 0,
+ nl80211_get_center_freq2_cb, buf);
+
+ return (*buf == 0) ? -1 : 0;
+}
+
static int nl80211_get_channel(const char *ifname, int *buf)
{
if (!nl80211_get_frequency(ifname, buf))
@@ -1273,6 +1323,28 @@ static int nl80211_get_channel(const char *ifname, int
*buf)
return -1;
}
+static int nl80211_get_center_chan1(const char *ifname, int *buf)
+{
+ if (!nl80211_get_center_freq1(ifname, buf))
+ {
+ *buf = nl80211_freq2channel(*buf);
+ return 0;
+ }
+
+ return -1;
+}
+
+static int nl80211_get_center_chan2(const char *ifname, int *buf)
+{
+ if (!nl80211_get_center_freq2(ifname, buf))
+ {
+ *buf = nl80211_freq2channel(*buf);
+ return 0;
+ }
+
+ return -1;
+}
+
static int nl80211_get_txpower_cb(struct nl_msg *msg, void *arg)
{
int *buf = arg;
@@ -3242,5 +3314,7 @@ const struct iwinfo_ops nl80211_ops = {
.countrylist = nl80211_get_countrylist,
.survey = nl80211_get_survey,
.lookup_phy = nl80211_lookup_phyname,
- .close= nl80211_
[IWINFO PATCH v4 1/4] iwinfo: export ht and vht operation in scan results
Export ht and vht operation data in scan results. These additional data
can be usefull to check wifi channel utilizzation by neraby stations.
Signed-off-by: Ansuel Smith
---
include/iwinfo.h | 34 ++
iwinfo_cli.c | 35 ++-
iwinfo_nl80211.c | 10 ++
3 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 5e64294..676db91 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -170,6 +170,38 @@ struct iwinfo_crypto_entry {
uint8_t auth_algs;
};
+struct iwinfo_scanlist_ht_chan_entry {
+ uint8_t primary_chan;
+ uint8_t secondary_chan_off;
+ uint8_t chan_width;
+};
+
+struct iwinfo_scanlist_vht_chan_entry {
+ uint8_t chan_width;
+ uint8_t center_chan_1;
+ uint8_t center_chan_2;
+};
+
+static const char *ht_secondary_offset[4] = {
+ "no secondary",
+ "above",
+ "[reserved!]",
+ "below",
+};
+
+
+static uint16_t ht_chan_width[2] = {
+ 20, /* 20 MHz */
+ 2040, /* 40 MHz or higher (refer to vht if supported) */
+};
+
+static uint16_t vht_chan_width[] = {
+ [0] = 40, /* 40 MHz or lower (refer to ht to a more precise width) */
+ [1] = 80, /* 80 MHz */
+ [3] = 8080, /* 80+80 MHz */
+ [2] = 160, /* 160 MHz */
+};
+
struct iwinfo_scanlist_entry {
uint8_t mac[6];
char ssid[IWINFO_ESSID_MAX_SIZE+1];
@@ -179,6 +211,8 @@ struct iwinfo_scanlist_entry {
uint8_t quality;
uint8_t quality_max;
struct iwinfo_crypto_entry crypto;
+ struct iwinfo_scanlist_ht_chan_entry ht_chan_info;
+ struct iwinfo_scanlist_vht_chan_entry vht_chan_info;
};
struct iwinfo_country_entry {
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index 0332bc2..6bfe0ab 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -323,6 +323,20 @@ static char * format_assocrate(struct iwinfo_rate_entry *r)
return buf;
}
+static const char* format_chan_width(uint16_t width)
+{
+ switch (width) {
+ case 20: return "20 MHz";
+ case 2040: return "40 MHz and upper or 20 MHz with intolerant
bit";
+ case 40: return "40 MHz or lower";
+ case 80: return "80 MHz";
+ case 8080: return "80+80 MHz";
+ case 160: return "160 MHz";
+ }
+
+ return "unknown";
+}
+
static const char * print_type(const struct iwinfo_ops *iw, const char *ifname)
{
@@ -612,8 +626,27 @@ static void print_scanlist(const struct iwinfo_ops *iw,
const char *ifname)
format_signal(e->signal - 0x100),
format_quality(e->quality),
format_quality_max(e->quality_max));
- printf(" Encryption: %s\n\n",
+ printf(" Encryption: %s\n",
format_encryption(&e->crypto));
+ printf(" HT Operation:\n");
+ printf("Primary Channel: %d\n",
+ e->ht_chan_info.primary_chan);
+ printf("Secondary Channel Offset: %s\n",
+ ht_secondary_offset[e->ht_chan_info.secondary_chan_off]);
+ printf("Channel Width: %s\n",
+
format_chan_width(ht_chan_width[e->ht_chan_info.chan_width]));
+
+ if (e->vht_chan_info.center_chan_1) {
+ printf(" VHT Operation:\n");
+ printf("Channel Width: %s\n",
+
format_chan_width(vht_chan_width[e->vht_chan_info.chan_width]));
+ printf("Center Frequency 1: %d\n",
+e->vht_chan_info.center_chan_1);
+ printf("Center Frequency 2: %d\n",
+e->vht_chan_info.center_chan_2);
+ }
+
+ printf("\n");
}
}
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 2b2a043..5917e3a 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -2306,6 +2306,16 @@ static void nl80211_get_scanlist_ie(struct nlattr **bss,
iwinfo_parse_rsn(&e->crypto, ie + 6, ie[1] - 4,
IWINFO_CIPHER_TKIP,
IWINFO_KMGMT_PSK);
break;
+ case 61: /* HT oeration */
+ e->ht_chan_info.primary_chan = ie[2];
+ e->ht_chan_info.secondary_chan_off = ie[3] & 0x3;
+ e->ht_chan_info.chan_width = (ie[4] & 0x4)>>2;
+
[RPCD PATCH v4 4/4] iwinfo: export center channel for info ubus call
Iwinfo export the center channel sued by the wifi. Include this data in
the ubus info call to better know the channel utilizzation of the wifi.
Signed-off-by: Ansuel Smith
---
iwinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/iwinfo.c b/iwinfo.c
index 45ca784..94fa822 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -364,6 +364,8 @@ rpc_iwinfo_info(struct ubus_context *ctx, struct
ubus_object *obj,
rpc_iwinfo_call_int("mode", iw->mode, IWINFO_OPMODE_NAMES);
rpc_iwinfo_call_int("channel", iw->channel, NULL);
+ rpc_iwinfo_call_int("center_chan1", iw->center_chan1, NULL);
+ rpc_iwinfo_call_int("center_chan2", iw->center_chan2, NULL);
rpc_iwinfo_call_int("frequency", iw->frequency, NULL);
rpc_iwinfo_call_int("frequency_offset", iw->frequency_offset, NULL);
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 0/4] Add support channel with to iwinfo
This series modify 2 different repo. Iwinfo and Rpcd The 2 iwinfo patch add support to iwinfo to display and export channel width and center_channel info for both wifi scan and wifi info related to the local wifi. The other 2 rpcd patch export the iwinfo data to ubus to make them usable by the webui. v4: - Fix error in iwinfo_cli v3: - Add check for center_chan support in iwinfo_cli - Use uinit to represent chan width and add function format_chant_width v2: - Put the static char array to the iwinfo include. (the rpcd plugin use the same include) - Add additional patch to export center_chanl for local wifi. -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RPCD PATCH v4 3/4] iwinfo: add ht and vht operation info to wifi scan
Iwinfo exports ht and vht operation info useful to get channel info of
nearby stations. Add these new info to ubus output.
Signed-off-by: Ansuel Smith
---
iwinfo.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/iwinfo.c b/iwinfo.c
index 7780e69..45ca784 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -403,7 +403,7 @@ rpc_iwinfo_scan(struct ubus_context *ctx, struct
ubus_object *obj,
struct blob_attr *msg)
{
int i, rv, len;
- void *c, *d;
+ void *c, *d, *t;
char mac[18];
char res[IWINFO_BUFSIZE];
struct iwinfo_scanlist_entry *e;
@@ -441,6 +441,20 @@ rpc_iwinfo_scan(struct ubus_context *ctx, struct
ubus_object *obj,
blobmsg_add_u32(&buf, "quality", e->quality);
blobmsg_add_u32(&buf, "quality_max", e->quality_max);
+ t = blobmsg_open_table(&buf, "ht_operation");
+ blobmsg_add_u32(&buf, "primary_channel",
e->ht_chan_info.primary_chan);
+ blobmsg_add_string(&buf, "secondary_channel_offset",
ht_secondary_offset[e->ht_chan_info.secondary_chan_off]);
+ blobmsg_add_u32(&buf, "channel_width",
ht_chan_width[e->ht_chan_info.chan_width]);
+ blobmsg_close_table(&buf, t);
+
+ if (e->vht_chan_info.center_chan_1) {
+ t = blobmsg_open_table(&buf, "vht_operation");
+ blobmsg_add_u32(&buf, "channel_width",
vht_chan_width[e->vht_chan_info.chan_width]);
+ blobmsg_add_u32(&buf, "center_freq_1",
e->vht_chan_info.center_chan_1);
+ blobmsg_add_u32(&buf, "center_freq_2",
e->vht_chan_info.center_chan_2);
+ blobmsg_close_table(&buf, t);
+ }
+
rpc_iwinfo_add_encryption("encryption", &e->crypto);
blobmsg_close_table(&buf, d);
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[IWINFO PATCH v3 1/4] iwinfo: export ht and vht operation in scan results
Export ht and vht operation data in scan results. These additional data
can be usefull to check wifi channel utilizzation by neraby stations.
Signed-off-by: Ansuel Smith
---
include/iwinfo.h | 34 ++
iwinfo_cli.c | 35 ++-
iwinfo_nl80211.c | 10 ++
3 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 5e64294..676db91 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -170,6 +170,38 @@ struct iwinfo_crypto_entry {
uint8_t auth_algs;
};
+struct iwinfo_scanlist_ht_chan_entry {
+ uint8_t primary_chan;
+ uint8_t secondary_chan_off;
+ uint8_t chan_width;
+};
+
+struct iwinfo_scanlist_vht_chan_entry {
+ uint8_t chan_width;
+ uint8_t center_chan_1;
+ uint8_t center_chan_2;
+};
+
+static const char *ht_secondary_offset[4] = {
+ "no secondary",
+ "above",
+ "[reserved!]",
+ "below",
+};
+
+
+static uint16_t ht_chan_width[2] = {
+ 20, /* 20 MHz */
+ 2040, /* 40 MHz or higher (refer to vht if supported) */
+};
+
+static uint16_t vht_chan_width[] = {
+ [0] = 40, /* 40 MHz or lower (refer to ht to a more precise width) */
+ [1] = 80, /* 80 MHz */
+ [3] = 8080, /* 80+80 MHz */
+ [2] = 160, /* 160 MHz */
+};
+
struct iwinfo_scanlist_entry {
uint8_t mac[6];
char ssid[IWINFO_ESSID_MAX_SIZE+1];
@@ -179,6 +211,8 @@ struct iwinfo_scanlist_entry {
uint8_t quality;
uint8_t quality_max;
struct iwinfo_crypto_entry crypto;
+ struct iwinfo_scanlist_ht_chan_entry ht_chan_info;
+ struct iwinfo_scanlist_vht_chan_entry vht_chan_info;
};
struct iwinfo_country_entry {
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index 0332bc2..6bfe0ab 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -323,6 +323,20 @@ static char * format_assocrate(struct iwinfo_rate_entry *r)
return buf;
}
+static const char* format_chan_width(uint16_t width)
+{
+ switch (width) {
+ case 20: return "20 MHz";
+ case 2040: return "40 MHz and upper or 20 MHz with intolerant
bit";
+ case 40: return "40 MHz or lower";
+ case 80: return "80 MHz";
+ case 8080: return "80+80 MHz";
+ case 160: return "160 MHz";
+ }
+
+ return "unknown";
+}
+
static const char * print_type(const struct iwinfo_ops *iw, const char *ifname)
{
@@ -612,8 +626,27 @@ static void print_scanlist(const struct iwinfo_ops *iw,
const char *ifname)
format_signal(e->signal - 0x100),
format_quality(e->quality),
format_quality_max(e->quality_max));
- printf(" Encryption: %s\n\n",
+ printf(" Encryption: %s\n",
format_encryption(&e->crypto));
+ printf(" HT Operation:\n");
+ printf("Primary Channel: %d\n",
+ e->ht_chan_info.primary_chan);
+ printf("Secondary Channel Offset: %s\n",
+ ht_secondary_offset[e->ht_chan_info.secondary_chan_off]);
+ printf("Channel Width: %s\n",
+ format_chan_width(e->ht_chan_info.chan_width));
+
+ if (e->vht_chan_info.center_chan_1) {
+ printf(" VHT Operation:\n");
+ printf("Channel Width: %s\n",
+format_chan_width(e->vht_chan_info.chan_width));
+ printf("Center Frequency 1: %d\n",
+e->vht_chan_info.center_chan_1);
+ printf("Center Frequency 2: %d\n",
+e->vht_chan_info.center_chan_2);
+ }
+
+ printf("\n");
}
}
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 2b2a043..5917e3a 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -2306,6 +2306,16 @@ static void nl80211_get_scanlist_ie(struct nlattr **bss,
iwinfo_parse_rsn(&e->crypto, ie + 6, ie[1] - 4,
IWINFO_CIPHER_TKIP,
IWINFO_KMGMT_PSK);
break;
+ case 61: /* HT oeration */
+ e->ht_chan_info.primary_chan = ie[2];
+ e->ht_chan_info.secondary_chan_off = ie[3] & 0x3;
+ e->ht_chan_info.chan_width = (ie[4] & 0x4)>>2;
+ break;
+ case 192: /* VHT operation */
[IWINFO PATCH v3 2/4] iwinfo: export center_chan info for local wifi
Iwinfo already export the htmode but there is no way to know where the
channel expan in case a 40Mhz+ channel width is used. Export the center
channels used by the driver to better know the channel utilizzation of
the wifi.
Signed-off-by: Ansuel Smith
---
include/iwinfo.h | 2 ++
iwinfo_cli.c | 23 +++
iwinfo_nl80211.c | 76 +++-
3 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 676db91..680f384 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -282,6 +282,8 @@ struct iwinfo_ops {
int (*survey)(const char *, char *, int *);
int (*lookup_phy)(const char *, char *);
void (*close)(void);
+ int (*center_chan1)(const char *, int *);
+ int (*center_chan2)(const char *, int *);
};
const char * iwinfo_type(const char *ifname);
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index 6bfe0ab..cc5d298 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -445,6 +445,24 @@ static char * print_channel(const struct iwinfo_ops *iw,
const char *ifname)
return format_channel(ch);
}
+static char * print_center_chan1(const struct iwinfo_ops *iw, const char
*ifname)
+{
+ int ch;
+ if (iw->center_chan1(ifname, &ch))
+ ch = -1;
+
+ return format_channel(ch);
+}
+
+static char * print_center_chan2(const struct iwinfo_ops *iw, const char
*ifname)
+{
+ int ch;
+ if (iw->center_chan2(ifname, &ch))
+ ch = -1;
+
+ return format_channel(ch);
+}
+
static char * print_frequency(const struct iwinfo_ops *iw, const char *ifname)
{
int freq;
@@ -566,6 +584,11 @@ static void print_info(const struct iwinfo_ops *iw, const
char *ifname)
print_mode(iw, ifname),
print_channel(iw, ifname),
print_frequency(iw, ifname));
+ if (iw->center_chan1 != NULL) {
+ printf(" Center Channel 1: %s",
+ print_center_chan1(iw, ifname));
+ printf(" 2: %s\n", print_center_chan2(iw, ifname));
+ }
printf(" Tx-Power: %s Link Quality: %s/%s\n",
print_txpower(iw, ifname),
print_quality(iw, ifname),
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index 5917e3a..1bcc5ea 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -1262,6 +1262,56 @@ static int nl80211_get_frequency(const char *ifname, int
*buf)
return (*buf == 0) ? -1 : 0;
}
+static int nl80211_get_center_freq1_cb(struct nl_msg *msg, void *arg)
+{
+ int *freq = arg;
+ struct nlattr **tb = nl80211_parse(msg);
+
+ if (tb[NL80211_ATTR_CENTER_FREQ1])
+ *freq = nla_get_u32(tb[NL80211_ATTR_CENTER_FREQ1]);
+
+ return NL_SKIP;
+}
+
+static int nl80211_get_center_freq1(const char *ifname, int *buf)
+{
+ char *res;
+
+ /* try to find frequency from interface info */
+ res = nl80211_phy2ifname(ifname);
+ *buf = 0;
+
+ nl80211_request(res ? res : ifname, NL80211_CMD_GET_INTERFACE, 0,
+ nl80211_get_center_freq1_cb, buf);
+
+ return (*buf == 0) ? -1 : 0;
+}
+
+static int nl80211_get_center_freq2_cb(struct nl_msg *msg, void *arg)
+{
+ int *freq = arg;
+ struct nlattr **tb = nl80211_parse(msg);
+
+ if (tb[NL80211_ATTR_CENTER_FREQ2])
+ *freq = nla_get_u32(tb[NL80211_ATTR_CENTER_FREQ2]);
+
+ return NL_SKIP;
+}
+
+static int nl80211_get_center_freq2(const char *ifname, int *buf)
+{
+ char *res;
+
+ /* try to find frequency from interface info */
+ res = nl80211_phy2ifname(ifname);
+ *buf = 0;
+
+ nl80211_request(res ? res : ifname, NL80211_CMD_GET_INTERFACE, 0,
+ nl80211_get_center_freq2_cb, buf);
+
+ return (*buf == 0) ? -1 : 0;
+}
+
static int nl80211_get_channel(const char *ifname, int *buf)
{
if (!nl80211_get_frequency(ifname, buf))
@@ -1273,6 +1323,28 @@ static int nl80211_get_channel(const char *ifname, int
*buf)
return -1;
}
+static int nl80211_get_center_chan1(const char *ifname, int *buf)
+{
+ if (!nl80211_get_center_freq1(ifname, buf))
+ {
+ *buf = nl80211_freq2channel(*buf);
+ return 0;
+ }
+
+ return -1;
+}
+
+static int nl80211_get_center_chan2(const char *ifname, int *buf)
+{
+ if (!nl80211_get_center_freq2(ifname, buf))
+ {
+ *buf = nl80211_freq2channel(*buf);
+ return 0;
+ }
+
+ return -1;
+}
+
static int nl80211_get_txpower_cb(struct nl_msg *msg, void *arg)
{
int *buf = arg;
@@ -3242,5 +3314,7 @@ const struct iwinfo_ops nl80211_ops = {
.countrylist = nl80211_get_countrylist,
.survey = nl80211_get_survey,
.lookup_phy = nl80211_lookup_phyname,
- .close= nl80211_
[RPCD PATCH v3 3/4] iwinfo: add ht and vht operation info to wifi scan
Iwinfo exports ht and vht operation info useful to get channel info of
nearby stations. Add these new info to ubus output.
Signed-off-by: Ansuel Smith
---
iwinfo.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/iwinfo.c b/iwinfo.c
index 7780e69..45ca784 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -403,7 +403,7 @@ rpc_iwinfo_scan(struct ubus_context *ctx, struct
ubus_object *obj,
struct blob_attr *msg)
{
int i, rv, len;
- void *c, *d;
+ void *c, *d, *t;
char mac[18];
char res[IWINFO_BUFSIZE];
struct iwinfo_scanlist_entry *e;
@@ -441,6 +441,20 @@ rpc_iwinfo_scan(struct ubus_context *ctx, struct
ubus_object *obj,
blobmsg_add_u32(&buf, "quality", e->quality);
blobmsg_add_u32(&buf, "quality_max", e->quality_max);
+ t = blobmsg_open_table(&buf, "ht_operation");
+ blobmsg_add_u32(&buf, "primary_channel",
e->ht_chan_info.primary_chan);
+ blobmsg_add_string(&buf, "secondary_channel_offset",
ht_secondary_offset[e->ht_chan_info.secondary_chan_off]);
+ blobmsg_add_u32(&buf, "channel_width",
ht_chan_width[e->ht_chan_info.chan_width]);
+ blobmsg_close_table(&buf, t);
+
+ if (e->vht_chan_info.center_chan_1) {
+ t = blobmsg_open_table(&buf, "vht_operation");
+ blobmsg_add_u32(&buf, "channel_width",
vht_chan_width[e->vht_chan_info.chan_width]);
+ blobmsg_add_u32(&buf, "center_freq_1",
e->vht_chan_info.center_chan_1);
+ blobmsg_add_u32(&buf, "center_freq_2",
e->vht_chan_info.center_chan_2);
+ blobmsg_close_table(&buf, t);
+ }
+
rpc_iwinfo_add_encryption("encryption", &e->crypto);
blobmsg_close_table(&buf, d);
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 0/4] Add support channel with to iwinfo
This series modify 2 different repo. Iwinfo and Rpcd The 2 iwinfo patch add support to iwinfo to display and export channel width and center_channel info for both wifi scan and wifi info related to the local wifi. The other 2 rpcd patch export the iwinfo data to ubus to make them usable by the webui. v3: - Add check for center_chan support in iwinfo_cli - Use uinit to represent chan width and add function format_chant_width v2: - Put the static char array to the iwinfo include. (the rpcd plugin use the same include) - Add additional patch to export center_chanl for local wifi. -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RPCD PATCH v3 4/4] iwinfo: export center channel for info ubus call
Iwinfo export the center channel sued by the wifi. Include this data in
the ubus info call to better know the channel utilizzation of the wifi.
Signed-off-by: Ansuel Smith
---
iwinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/iwinfo.c b/iwinfo.c
index 45ca784..94fa822 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -364,6 +364,8 @@ rpc_iwinfo_info(struct ubus_context *ctx, struct
ubus_object *obj,
rpc_iwinfo_call_int("mode", iw->mode, IWINFO_OPMODE_NAMES);
rpc_iwinfo_call_int("channel", iw->channel, NULL);
+ rpc_iwinfo_call_int("center_chan1", iw->center_chan1, NULL);
+ rpc_iwinfo_call_int("center_chan2", iw->center_chan2, NULL);
rpc_iwinfo_call_int("frequency", iw->frequency, NULL);
rpc_iwinfo_call_int("frequency_offset", iw->frequency_offset, NULL);
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] cmake.mk, rules.mk: fix host builds using CMake and ccache
On Fri, Nov 27, 2020 at 03:47:45PM -0800, Rosen Penev wrote:
> On Fri, Nov 27, 2020 at 2:04 PM Petr Štetiar wrote:
> >
> > Commit f98878e4c17d ("cmake.mk: set C/CXX compiler for host builds as
> > well") has introduced regression as it didn't taken usage of ccache into
> > the account so fix it by handling ccache use cases as well.
> >
> > In order to get this working we need to export HOSTCXX_NOCACHE in
> > rules.mk as well.
> That's annoying. I didn't know ccache was used with host packages.
> >
Can confirm that this fix the bug.
Tested-by: Ansuel Smith
> > Fixes: f98878e4c17d ("cmake.mk: set C/CXX compiler for host builds as well")
> > Reported-by: Ansuel Smith
> Acked-by: Rosen Penev
> > Signed-off-by: Petr Štetiar
> > ---
> > include/cmake.mk | 18 --
> > rules.mk | 1 +
> > 2 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/cmake.mk b/include/cmake.mk
> > index 2cc10301aa4e..0a20530a16fe 100644
> > --- a/include/cmake.mk
> > +++ b/include/cmake.mk
> > @@ -23,12 +23,22 @@ ifeq ($(CONFIG_CCACHE),)
> > CMAKE_CXX_COMPILER:=$(call cmake_tool,$(TARGET_CXX))
> > CMAKE_C_COMPILER_ARG1:=
> > CMAKE_CXX_COMPILER_ARG1:=
> > +
> > + CMAKE_HOST_C_COMPILER:=$(HOSTCC)
> > + CMAKE_HOST_CXX_COMPILER:=$(HOSTCXX)
> > + CMAKE_HOST_C_COMPILER_ARG1:=
> > + CMAKE_HOST_CXX_COMPILER_ARG1:=
> > else
> >CCACHE:=$(STAGING_DIR_HOST)/bin/ccache
> >CMAKE_C_COMPILER:=$(CCACHE)
> >CMAKE_C_COMPILER_ARG1:=$(TARGET_CC_NOCACHE)
> >CMAKE_CXX_COMPILER:=$(CCACHE)
> >CMAKE_CXX_COMPILER_ARG1:=$(TARGET_CXX_NOCACHE)
> > +
> > + CMAKE_HOST_C_COMPILER:=$(CCACHE)
> > + CMAKE_HOST_C_COMPILER_ARG1:=$(HOSTCC_NOCACHE)
> > + CMAKE_HOST_CXX_COMPILER:=$(CCACHE)
> > + CMAKE_HOST_CXX_COMPILER_ARG1:=$(HOSTCXX_NOCACHE)
> > endif
> > CMAKE_AR:=$(call cmake_tool,$(TARGET_AR))
> > CMAKE_NM:=$(call cmake_tool,$(TARGET_NM))
> > @@ -97,8 +107,12 @@ define Host/Configure/Default
> > LDFLAGS="$(HOST_LDFLAGS)" \
> > cmake \
> > -DCMAKE_BUILD_TYPE=Release \
> > - -DCMAKE_C_COMPILER="$(HOSTCC)" \
> > - -DCMAKE_CXX_COMPILER="$(HOSTCXX)" \
> > + -DCMAKE_C_COMPILER="$(CMAKE_HOST_C_COMPILER)" \
> > +
> > -DCMAKE_C_COMPILER_ARG1="$(CMAKE_HOST_C_COMPILER_ARG1)" \
> > + -DCMAKE_CXX_COMPILER="$(CMAKE_HOST_CXX_COMPILER)" \
> > +
> > -DCMAKE_CXX_COMPILER_ARG1="$(CMAKE_HOST_CXX_COMPILER_ARG1)" \
> > + -DCMAKE_ASM_COMPILER="$(CMAKE_HOST_C_COMPILER)" \
> > +
> > -DCMAKE_ASM_COMPILER_ARG1="$(CMAKE_HOST_C_COMPILER_ARG1)" \
> > -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" \
> > -DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" \
> > -DCMAKE_EXE_LINKER_FLAGS:STRING="$(HOST_LDFLAGS)" \
> > diff --git a/rules.mk b/rules.mk
> > index adb103d81f2f..34222a3a7199 100644
> > --- a/rules.mk
> > +++ b/rules.mk
> > @@ -292,6 +292,7 @@ HOSTCXX_NOCACHE:=$(HOSTCXX)
> > export TARGET_CC_NOCACHE
> > export TARGET_CXX_NOCACHE
> > export HOSTCC_NOCACHE
> > +export HOSTCXX_NOCACHE
> >
> > ifneq ($(CONFIG_CCACHE),)
> >TARGET_CC:= ccache_cc
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Compilation error with latest master
Commit f98878e4c17d5f11e78994b4fc456e6b60b2660f cause some compilation error like (the package is random... i got this with many package that use cmake) Reverting the commit and rebuilding the related package fix the problem. make[3]: Entering directory '/home/ansuel/openwrt/tools/padjffs2' -- The C compiler identification is unknown CMake Error at CMakeLists.txt:4 (project): The CMAKE_C_COMPILER: ccache gcc is not a full path and was not found in the PATH. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. make[3]: Leaving directory '/home/ansuel/openwrt/tools/padjffs2' ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/4] Add support channel with to iwinfo
This series modify 2 different repo. Iwinfo and Rpcd The 2 iwinfo patch add support to iwinfo to display and export channel width and center_channel info for both wifi scan and wifi info related to the local wifi. The other 2 rpcd patch export the iwinfo data to ubus to make them usable by the webui. v2: - Put the static char array to the iwinfo include. (the rpcd plugin use the same include) - Add additional patch to export center_chanl for local wifi. -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RPCD PATCH v2 4/4] iwinfo: export center channel for info ubus call
Iwinfo export the center channel sued by the wifi. Include this data in
the ubus info call to better know the channel utilizzation of the wifi.
Signed-off-by: Ansuel Smith
---
iwinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/iwinfo.c b/iwinfo.c
index 45ca784..94fa822 100644
--- a/iwinfo.c
+++ b/iwinfo.c
@@ -364,6 +364,8 @@ rpc_iwinfo_info(struct ubus_context *ctx, struct
ubus_object *obj,
rpc_iwinfo_call_int("mode", iw->mode, IWINFO_OPMODE_NAMES);
rpc_iwinfo_call_int("channel", iw->channel, NULL);
+ rpc_iwinfo_call_int("center_chan1", iw->center_chan1, NULL);
+ rpc_iwinfo_call_int("center_chan2", iw->center_chan2, NULL);
rpc_iwinfo_call_int("frequency", iw->frequency, NULL);
rpc_iwinfo_call_int("frequency_offset", iw->frequency_offset, NULL);
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
