Re: USB controller enumeration on APU3 is random since the update to kernel 6.6
On 2024-07-18 18:31, Henrique de Moraes Holschuh via openwrt-devel wrote: > > OpenWRT has its hotplug via procd, which is different, but it should still be > usable for that kind of *required* functionality. What the wiki describes > for "usbmisc" hotplug does *not* look good, hopefully the wiki is incomplete. > Otherwise, procd should be improved and meanwhile, you need to deploy a > script to handle that event that does the follow-the-symlinks game in sysfs > to go from usblp to usb endpoint, and get the necessary device data from > there. usbmisc is complete from last I dived into it - I updated the wiki with my findings when working with printers (usbmisc class devices). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: USB controller enumeration on APU3 is random since the update to kernel 6.6
I can see this affecting USB network devices.
In my experience of working with p910nd, I used sysfs also. Deterministic
probing order is important if the order of discovered USB printers is to remain
the same (so that port 9100 always talks to your HP at /dev/usb/lp0, port 9101
always talks to your Brother at /dev/usb/lp1, mutatis mutandis). To prevent
soft-bricking when sending a (driver) blob, the script would only send to
devices identified using the below properties. While I could not (yet) affect
the port ordering of /dev/usb/lpX character device assignments (first detected
gets first assignment), I could ensure the right blob went to the right device.
The files below presented in sysfs help to build an unmistakable identity of
device type, in this case:
bInterfaceClass
bInterfaceSubClass
idVendor
idProduct
( /sys/bus/usb/devices/*/idVendor )
and also the following if you have multiple identical device types:
iSerialNumber
These files might allow non-deterministic ordering or presentation such that a
moved device can still be reconciled. Certain other files at this location
might provide better anchoring. Be aware that some USB devices can have
multiple connection modes, i.e. bNumConfigurations and bConfigurationValue (
e.g. press button, device mounts file-system with drivers, press button, device
then changes config to connect printer etc )
For reconciliation, store contents of several of the files found in
/sys/bus/usb/devices/*/ ) for matching, e.g. as a CSV in configuration:
{idVendor},{idProduct},{iSerialNumber},{bInterfaceClass},{bInterfaceSubClass}
Some info:
https://beyondlogic.org/usbnutshell/usb5.shtml
https://openwrt.org/docs/guide-user/base-system/hotplug
Open to suggestions if there's a 'better' way to do this, but this way I think
one can disregard a sysfs path and be certain that one has found the same
'device'.
On 2024-07-18 11:53, Florian Eckert wrote:
> Hello Felix
>
>>> Boot 1:
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:56 2-1.3:1.0 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.0
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:56 2-1.3:1.1 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.1
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:56 2-1.3:1.2 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.2
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:56 2-1.3:1.3 ->
>>> ../../../devices/pci:00/:00:13.0/usb2/2-1/2-1.3/2-1.3:1.3
>
>>> Boot 2:
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:43 1-1.3:1.0 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.0
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:43 1-1.3:1.1 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.1
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:43 1-1.3:1.2 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.2
>>> -> lrwxrwxrwx 1 root root 0 Jul 17 12:43 1-1.3:1.3 ->
>>> ../../../devices/pci:00/:00:13.0/usb1/1-1/1-1.3/1-1.3:1.3
>
>> Oh, right. The main issue here is the fact that the device ids in the
>> path contain the bus number as initial component.
>
> That is correct. The bus number is incremented with each new USB controller.
> The number assigned to the controller is allocated in the order in which it
> is probed (first come first serve).
>
>> I guess the syntax
>> could be something like: "pci:00/:00:12.0%"
>> To resolve it, it would look up the bus number from the controller
>> path and then use /sys/bus/usb/devices/- as the device path.
>
> On my APU3 I have four USB busses.
> lrwxrwxrwx 1 root root 0 Jul 18 11:10 usb1 ->
> ../../../devices/pci:00/:00:12.0/usb1
> lrwxrwxrwx 1 root root 0 Jul 18 11:10 usb2 ->
> ../../../devices/pci:00/:00:13.0/usb2
> lrwxrwxrwx 1 root root 0 Jul 18 11:17 usb3 ->
> ../../../devices/pci:00/:00:10.0/usb3
> lrwxrwxrwx 1 root root 0 Jul 18 11:17 usb4 ->
> ../../../devices/pci:00/:00:10.0/usb4
>
> usb1 an ehci on PCI :00:12.0
> usb2 an ehci on PCI :00:13.0
> usb3 an xhci on PCI :00:10.0
> usb4 an xhci on PCI :00:10.0
>
> I have an USB modem on PCI :00:13.0 that can be reached under
> either bus number 1 or bus number 2 depending on when the controller
> was proped in the boot sequence. The xhci controllers on PCI
> :00:10.0 always get the bus number 3 and bus number 4.
> The ehci is probed before xhci.
>
> I found a commit [1] in the Linux kernel that makes the USB
> controller probing asynchronous and therefore not deterministic as
> before. I have reverted the commit on my build and now nothing
> changes in the controller numbering. This is not a solution, but
> I now know what the problem is. With a new kernel, the numbering
> can be
legal question for VRX518
https://forum.openwrt.org/t/vrx518-firmware-license-change-can-it-be-included-now/202141 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 00/14] odhcpd config value clamping
Any comments? On 2024-05-10 00:30, Paul Donald wrote: > Clamp values read from config to RFC mandated sane values instead of just > complaining. We also now implement valid_lifetime for ULA prefixes. > This is useful if you need to sunset or remove one from circulation. > ( Interestingly, if you spin up dev devices frequently which spam the > network with new ULA each time, which have no expiry, interesting things > start to happen. ) > Fixed also a bug in MTU handling. > > Paul Donald (14): > config: refactor parse_leasetime() - branch amount remains same > router: Apply updated values from RFC8319 (updates RFC4861) to RA/ND > config: clamp ra_mininterval, ra_maxinterval, ra_lifetime at load time > router: refactor calc_ra_lifetime, and define ra_lifetime as uint32_t > router: redefine ra_mininterval and ra_maxinterval as uint32_t > config: implement RFC4861 AdvValidLifetime (make configurable) > config: lease times are all UINT32_MAX; drop double size handling > router: clamp prefix valid_lt to interface valid_lifetime > config: clamp ra_reachabletime to RFC maximum (instead of complaining) > config: clamp ra_hoplimit to maximum (instead of complaining) > config: clamp ra_retranstime > config: clamp ra_mtu into 1280-65535 range > config: clamp dhcpv6_hostid_len > config: clamp dhcpv6_pd_min_len > > README | 2 + > src/config.c | 162 +-- > src/odhcpd.h | 7 ++- > src/router.c | 34 +-- > src/router.h | 25 +++- > 5 files changed, 148 insertions(+), 82 deletions(-) > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/1] odhcpd uses also interafce dns_search
Any comments? On 2024-04-10 03:16, Paul Donald wrote: > From: Paul Donald > > Applies to master d8118f6e76e5519881f9a37137c3a06b3cb60fd2 > > Naïve implementation. Works well. > > Might have drawbacks: it parses interfaces, so if they happen to have the > same parameter names, ??? > > The idea seems worth implementing. > > > Paul Donald (1): > config: use network interface 'dns_search' and dhcp 'domain' > > src/config.c | 26 -- > 1 file changed, 24 insertions(+), 2 deletions(-) > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
On 2024-05-07 20:48, Christian Marangi (Ansuel) wrote: > Il giorno mar 7 mag 2024 alle ore 18:53 Enrico Mioso > ha scritto: >> >> Hello all!! >> >> is there any chance we can merge any form of this patch? >> The device it is related seems pretty popular and one of the rare devices >> supporting VDSL, 35B profile and with nice specs. >> Even tough I can understand it is not desirable to maintain this patch >> indefinitely should that be the case, I don't think leaving it out of >> OpenWrt is the right answer. >> Also due to the fact this seems, in my opinion, one of these things that can >> act as barrier to entry for a typical setup (at least when VDSL is involved). >> >> Thanks a lot to all of you for your great work. >> > > For everyone involved, I would really love if we can move here > https://github.com/openwrt/openwrt/pull/15421 and test the alternative > patch. It does have a different and more restricted approach. > ping ping PING pig :D ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] hostapd: Add support for APuP
inline
On 2024-05-10 19:48, g...@eigenlab.org wrote:
> From: Gioacchino Mazzurco
>
> Add support for hostapd Access Point Micro Peering
>
> Signed-off-by: Gioacchino Mazzurco
> ---
> .../wifi-scripts/files/lib/netifd/hostapd.sh | 16 +-
> package/network/services/hostapd/Makefile | 2 +-
> ...ment-APuP-Access-Point-Micro-Peering.patch | 426 ++
> ...us-notification-when-a-peer-comes-up.patch | 74 +++
> ...-ucode-hook-for-when-a-peer-comes-up.patch | 83
> 5 files changed, 599 insertions(+), 2 deletions(-)
> create mode 100644
> package/network/services/hostapd/patches/780-Implement-APuP-Access-Point-Micro-Peering.patch
> create mode 100644
> package/network/services/hostapd/patches/790-APuP-add-ubus-notification-when-a-peer-comes-up.patch
> create mode 100644
> package/network/services/hostapd/patches/800-APuP-add-ucode-hook-for-when-a-peer-comes-up.patch
>
> diff --git a/package/network/config/wifi-scripts/files/lib/netifd/hostapd.sh
> b/package/network/config/wifi-scripts/files/lib/netifd/hostapd.sh
> index 763702e76b..40266db065 100644
> --- a/package/network/config/wifi-scripts/files/lib/netifd/hostapd.sh
> +++ b/package/network/config/wifi-scripts/files/lib/netifd/hostapd.sh
> @@ -383,6 +383,9 @@ hostapd_common_add_bss_config() {
> config_add_string fils_dhcp
>
> config_add_int ocv
> +
> + config_add_boolean apup
> + config_add_string apup_peer_ifname_prefix
> }
>
> hostapd_set_vlan_file() {
> @@ -569,7 +572,7 @@ hostapd_set_bss_options() {
> ppsk airtime_bss_weight airtime_bss_limit airtime_sta_weight \
> multicast_to_unicast_all proxy_arp per_sta_vif \
> eap_server eap_user_file ca_cert server_cert private_key
> private_key_passwd server_id \
> - vendor_elements fils ocv
> + vendor_elements fils ocv apup
>
> set_default fils 0
> set_default isolate 0
> @@ -593,6 +596,7 @@ hostapd_set_bss_options() {
> set_default airtime_bss_weight 0
> set_default airtime_bss_limit 0
> set_default eap_server 0
> + set_default apup 0
>
> /usr/sbin/hostapd -vfils || fils=0
>
> @@ -1163,6 +1167,16 @@ hostapd_set_bss_options() {
> append bss_conf "per_sta_vif=$per_sta_vif" "$N"
> fi
>
> + if [ "$apup" -gt 0 ]; then
> + append bss_conf "apup=$apup" "$N"
> +
> + local apup_peer_ifname_prefix
> + json_get_vars apup_peer_ifname_prefix
> + if [ -n "$apup_peer_ifname_prefix" ] ; then
> + append bss_conf
> "apup_peer_ifname_prefix=$apup_peer_ifname_prefix" "$N"
> + fi
> + fi
> +
> json_get_values opts hostapd_bss_options
> for val in $opts; do
> append bss_conf "$val" "$N"
> diff --git a/package/network/services/hostapd/Makefile
> b/package/network/services/hostapd/Makefile
> index 0171bc0edc..1eaa67f992 100644
> --- a/package/network/services/hostapd/Makefile
> +++ b/package/network/services/hostapd/Makefile
> @@ -87,7 +87,7 @@ DRIVER_MAKEOPTS= \
> CONFIG_IEEE80211AC=$(HOSTAPD_IEEE80211AC) \
> CONFIG_IEEE80211AX=$(HOSTAPD_IEEE80211AX) \
> CONFIG_MBO=$(CONFIG_WPA_MBO_SUPPORT) \
> - CONFIG_UCODE=y
> + CONFIG_UCODE=y CONFIG_APUP=y
>
> ifeq ($(SSL_VARIANT),openssl)
>DRIVER_MAKEOPTS += CONFIG_TLS=openssl CONFIG_SAE=y
> diff --git
> a/package/network/services/hostapd/patches/780-Implement-APuP-Access-Point-Micro-Peering.patch
>
> b/package/network/services/hostapd/patches/780-Implement-APuP-Access-Point-Micro-Peering.patch
> new file mode 100644
> index 00..db3a05e3e6
> --- /dev/null
> +++
> b/package/network/services/hostapd/patches/780-Implement-APuP-Access-Point-Micro-Peering.patch
> @@ -0,0 +1,426 @@
> +From 99a9a4e97b4964e12749766de9c57bb7e59e740e Mon Sep 17 00:00:00 2001
> +From: Gioacchino Mazzurco
> +Date: Mon, 6 May 2024 13:53:48 +0200
> +Subject: [PATCH 1/3] Implement APuP Access Point Micro Peering
> +
> +Access Point Micro Peering is a simpler and hopefully more useful successor
> to
layers are only ever added, never removed ;)
more useful than what? With what are you comparing? And why compare when you're
superseding?
> +Ad Hoc, Wireless Distribution System, 802.11s mesh mode, Multi-AP and
> EasyMesh.
> +When enabled almost plain APs communicate between them via 4-address mode,
WAT?
> +like in WDS but all of them are AP, so they can eventually communicate also
> with
> +plain stations and more AP nodes in sight, without more trickery.
...and other AP nodes.
> +APuP has low hardware requirements, just AP mode support + 4-address mode,
> and
> +no more unnecessary complications, like hardcoded bridging or routing
> algorithm
> +in WiFi stack.
> +For each AP in sight an interface is created, and then it can be used as
> +convenient in each case, bridging, routing etc.
> +Those interfaces could be simply bridged in a trivial topology (which
Re: [PATCH v3 0/9] odhcpd patchset
Any further comments or reviews for this to go in? On 2024-04-09 05:04, Paul Donald wrote: > From: Paul Donald > > applies to odhcpd master HEAD d8118f6e76e5519881f9a37137c3a06b3cb60fd2 > > Before: > == > ICMPv6 Option (Prefix information : fd51:1c2a:8909::/64) > Type: Prefix information (3) > Length: 4 (32 bytes) > Prefix Length: 64 > Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) > Valid Lifetime: Infinity (4294967295) > Preferred Lifetime: Infinity (4294967295) > Reserved > Prefix: fd51:1c2a:8909:: > ==After:== > ICMPv6 Option (Prefix information : fd51:1c2a:8909::/64) > Type: Prefix information (3) > Length: 4 (32 bytes) > Prefix Length: 64 > Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A) > Valid Lifetime: Infinity (4294967295) > Preferred Lifetime: 420 > Reserved > Prefix: fd51:1c2a:8909:: > == > > > changes: > v1: initial patch > v2: implemented feedback for commit messages > v3: house-keeping. removed config defaults/clamping ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/4] Base support for Inteno XG6846
On 2024-04-25 22:12, Linus Walleij wrote: > These patches have been cooking for some time, let's > get them moving. > > The idea is to merge this base so we have base support > for the target and then try to work out remaining issues > such as the LED handling. > > To: > > Signed-off-by: Linus Walleij Signed-off-by: Paul Donald Reviewed-by: Paul Donald Choose as appropriate - I think you did most of the work here with input from us, and I've tested this device/platform. > --- > Changes in v2: > - Include U-Boot for BMIPS patch (2024.04) > - Separate patch to activate U-Boot with the target. > - Use a kmod for the Marvell switch to hold down the footprint > of the generic BCM6328 support. > - Link to v1: > http://lists.openwrt.org/pipermail/openwrt-devel/2023-August/041387.html > > --- > Linus Walleij (4): > bmips: bcm6328: Compile in uImage splitter > bmips: Add Inteno XG6846 target > uboot-bmips: Add U-Boot for the BMIPS target > bmips: Build U-Boot into the XG6846 target > > .github/labeler.yml| 1 + > package/boot/uboot-bmips/Makefile | 32 +++ > .../bcm6328/base-files/etc/board.d/02_network | 3 + > target/linux/bmips/bcm6328/config-6.1 | 1 + > target/linux/bmips/dts/bcm6328-inteno-xg6846.dts | 313 > + > target/linux/bmips/image/Makefile | 31 ++ > target/linux/bmips/image/bcm6328.mk| 14 + > target/linux/bmips/image/null-initrd | 1 + > target/linux/bmips/image/u-boot.bin| Bin 0 -> 289149 bytes > 9 files changed, 396 insertions(+) > --- > base-commit: 84a48ce400b2c7b0779f51e83c68de5f8ec58ffd > change-id: 20240425-xg6846-base-9853a92b11f7 > > Best regards, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
netifd compile errors
commit 33ec3d52cea628df91eb0eb1701e16172c1e - HEAD Problems. the first error was the absence of /home/user/openwrt/staging_dir/target-mips_24kc_musl/usr/include/libubox/udebug.h Had to manually download udebug.h from the libubox repo...? Next error - (c)make cannot seem to find libnl-tiny deps if I try to build master/main?: time: package/libs/toolchain/compile#0.27#0.17#0.42 make[2]: Entering directory '/home/user/openwrt/package/libs/libnl-tiny' echo "libnl-tiny" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/libnl-tiny.default.install make[2]: Leaving directory '/home/user/openwrt/package/libs/libnl-tiny' time: package/libs/libnl-tiny/compile#0.15#0.17#0.29 make[2]: Entering directory '/home/user/openwrt/package/libs/libjson-c' echo "libjson-c" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/libjson-c.default.install make[2]: Leaving directory '/home/user/openwrt/package/libs/libjson-c' time: package/libs/libjson-c/compile#0.19#0.20#0.35 make[2]: Entering directory '/home/user/openwrt/package/utils/lua' make[2]: Leaving directory '/home/user/openwrt/package/utils/lua' time: package/utils/lua/compile#0.16#0.20#0.34 make[2]: Entering directory '/home/user/openwrt/package/libs/libubox' echo "libubox" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/libubox.default.install echo "libblobmsg-json" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/libubox.default.install echo "jshn" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/libubox.default.install echo "libjson-script" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/libubox.default.install make[2]: Leaving directory '/home/user/openwrt/package/libs/libubox' time: package/libs/libubox/compile#0.20#0.22#0.39 make[2]: Entering directory '/home/user/openwrt/package/system/ubus' echo "libubus" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/ubus.default.install echo "ubus" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/ubus.default.install echo "ubusd" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/ubus.default.install make[2]: Leaving directory '/home/user/openwrt/package/system/ubus' time: package/system/ubus/compile#0.15#0.18#0.32 make[2]: Entering directory '/home/user/openwrt/package/system/uci' echo "libuci" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/uci.default.install echo "uci" >> /home/user/openwrt/staging_dir/target-mips_24kc_musl/pkginfo/uci.default.install make[2]: Leaving directory '/home/user/openwrt/package/system/uci' time: package/system/uci/compile#0.16#0.16#0.29 make[2]: Entering directory '/home/user/openwrt/package/network/config/netifd' rm -f /home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80/.built touch /home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80/.built_check MAKEFLAGS="" /home/user/openwrt/staging_dir/host/bin/ninja -j1 -C /home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80 ninja: Entering directory `/home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80' [1/2] Building C object CMakeFiles/netifd.dir/system-linux.c.o FAILED: CMakeFiles/netifd.dir/system-linux.c.o /home/user/openwrt/staging_dir/toolchain-mips_24kc_gcc-13.2.0_musl/bin/mips-openwrt-linux-musl-gcc -DDEBUG -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -fmacro-prefix-map=/home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80=netifd-2024-04-24-d4c78d80 -mips16 -minterlink-mips16 -flto=auto -fno-fat-lto-objects -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/user/openwrt/staging_dir/target-mips_24kc_musl/usr/include/libnl-tiny -I/home/user/openwrt/staging_dir/target-mips_24kc_musl/usr/include -DNDEBUG -Wall -Werror -Wextra -Werror=implicit-function-declaration -Wformat -Werror=format-security -Werror=format-nonliteral -Os --std=gnu99 -Wmissing-declarations -Wno-unused-parameter -Wno-unused-but-set-parameter -Wimplicit-fallthrough -g3 -MD -MT CMakeFiles/netifd.dir/system-linux.c.o -MF CMakeFiles/netifd.dir/system-linux.c.o.d -o CMakeFiles/netifd. dir/system-linux.c.o -c /home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80/system-linux.c /home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80/system-linux.c: In function 'create_socket': /home/user/openwrt/build_dir/target-mips_24kc_musl/netifd-2024-04-24-d4c78d80/system-linux.c:227:9: error: implicit declaration of function 'nl_socket_set_tx_debug_cb'; did you mean 'nl_socket_set_cb'? [-Werror=implicit-function-declaration] 227 | nl_socket_set_tx_debug_cb(sock, nl_udebug_cb, _nl); | ^ | nl_socket_set_cb
Re: here we are again: real name 'discussion'
On 2024-04-16 16:41, Etienne Champetier wrote: > Le mar. 16 avr. 2024 à 10:34, Paul D a écrit : >> >> On 2024-03-27 23:56, Etienne Champetier wrote: >>> >>> As this is a legal issue, should we get SFC opinion first ? >>> >>> Etienne >>> >> >> Is this happening? > > Sorry I missed your last ping > This was an open question, I don't know who to contact at SFC > > Looking at old emails, John, Jo and Hauke are our liaison with SFC So, John, Jo and Hauke, who is the current liaison to SFC? what does the SFC think? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
On 2024-03-27 23:56, Etienne Champetier wrote: > > As this is a legal issue, should we get SFC opinion first ? > > Etienne > Is this happening? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: add support for Dell SonicPoint ACe APL26-0AE
>> 6. Adjust "ipaddr" (access point) and "serverip" (TFTP server) addresses Might be an idea to explicitly document these IPs so that dedicated users can already set their gear to those IPs and just smash enter ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On 2024-04-11 10:52, Bjørn Mork wrote: > Ivan Ivanov writes: > >>> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C >> >> Are these Mediateks capable of working without any binary blobs, at >> least in theory? > > A simple question back to you: Could you please list the wifi chips you > know of which ether have > a) completely open source firmware, or > b) no firmware at all (neither loaded in ram, nor in internal flash)? > > And of those, do any of them support 802.11g? 802.11a? 802.11ac? > 802.11ax? > > No need to list more than a couple of examples of each If your lists are > very long. I'm just curious what you are asking. Or whether you are > aware what you are asking, TBH > > This seems part of a much larger debate: finding a company who would produce a spec compliant SoC which does or does not contain IP, and gives it away freely. With the right licensing it's possible, but it doesn't prevent China from copying the hell out of it. Today it's already *really* difficult to tell fake chips and components apart from real ones, which is part of the battle. This 'numbers game' means any well intentioned open source Soc initiative could drown. It's not impossible, however. In the next decade, perhaps, with new chip foundries in the EU and USA. Things like RPi and its analogues seem evidence that people want to hack and tinker. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Scripting question how to filter list of files based on globs
> It's not beautiful, but it works:
>
> xargs -a blacklist.txt -I {} sh -c 'find package \( -name "$1" -prune \) -o
> -type f -print' sh {}
>
>
I take that back - no it doesn't :/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Scripting question how to filter list of files based on globs
On 2024-04-10 16:45, Philip Prindeville wrote:
>
>
>> On Apr 9, 2024, at 6:03 PM, Paul D wrote:
>>
>> On 2024-04-09 23:30, Philip Prindeville via openwrt-devel wrote:
>>> I'm trying to modify a script generates a list of filenames one per
>>> line, but should be filtered against a blacklist of file globs.
>>>
>>> Something like:
>>>
>>> % find dir -print | grep -v -f blacklist
>>
>>
>> I got this. When I run it on the openwrt source, where package is the
>> packages directory:
>>
>> Vanilla Output
>>
>> find package -type f -print
>>
>> ===
>> ...
>> package/utils/uencrypt/src/CMakeLists.txt
>> package/utils/uencrypt/src/uencrypt-mbedtls.c
>> package/utils/uencrypt/src/uencrypt-openssl.c
>> package/utils/uencrypt/src/uencrypt.c
>> package/utils/uencrypt/src/uencrypt.h
>> package/utils/uencrypt/Makefile
>> package/utils/zyxel-bootconfig/Makefile
>> package/utils/zyxel-bootconfig/files/95_apply_bootconfig
>> package/utils/zyxel-bootconfig/src/Makefile
>> package/utils/zyxel-bootconfig/src/zyxel-bootconfig.c
>> package/utils/ucode-mod-bpf/Makefile
>> package/utils/ucode-mod-bpf/src/bpf.c
>> package/utils/firmware-utils/Makefile
>> package/utils/yafut/Makefile
>> package/utils/debugcc/Makefile
>> ===
>>
>>
>> Exclude 'Makefile's
>>
>> find package -type f -name 'Makefile' -prune -o -type f -print
>>
>> ===
>> ...
>> package/utils/util-linux/patches/001-meson-properly-handle-gettext-non-existence.patch
>> package/utils/uencrypt/src/CMakeLists.txt
>> package/utils/uencrypt/src/uencrypt-mbedtls.c
>> package/utils/uencrypt/src/uencrypt-openssl.c
>> package/utils/uencrypt/src/uencrypt.c
>> package/utils/uencrypt/src/uencrypt.h
>> package/utils/zyxel-bootconfig/files/95_apply_bootconfig
>> package/utils/zyxel-bootconfig/src/zyxel-bootconfig.c
>> package/utils/ucode-mod-bpf/src/bpf.c
>> ===
>>
>> Exclude Makefiles and c files
>>
>> find package -type f -name 'Makefile' -o -name '*.c' -prune -o -type f -print
>>
>> ===
>> ...
>> package/utils/util-linux/patches/001-meson-properly-handle-gettext-non-existence.patch
>> package/utils/uencrypt/src/CMakeLists.txt
>> package/utils/uencrypt/src/uencrypt.h
>> package/utils/zyxel-bootconfig/files/95_apply_bootconfig
>> ===
>>
>> Exclude Makefiles and c files and patch files
>>
>>
>> find package -type f -name 'Makefile' -o -name '*.c' -o -name '*.patch'
>> -prune -o -type f -print
>> ===
>> ...
>> package/utils/uencrypt/src/CMakeLists.txt
>> package/utils/uencrypt/src/uencrypt.h
>> package/utils/zyxel-bootconfig/files/95_apply_bootconfig
>> ===
>>
>> find package -type f -name 'Makefile' -o -type d -name 'utils' -prune -o
>> -type f -print
>>
>> ===
>> ...
>> ===
>>
>>
>> Set your -type accordingly.
>
>
> The issue is that the pattern of names to exclude is user-defined, so we
> don't know it in advance.
>
It's not beautiful, but it works:
xargs -a blacklist.txt -I {} sh -c 'find package \( -name "$1" -prune \) -o
-type f -print' sh {}
:)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
On 2024-03-27 23:56, Etienne Champetier wrote: > > > (On my phone, Gmail mobile only sends html emails, sorry for that) > > As this is a legal issue, should we get SFC opinion first ? > > Etienne > When can we know the result of such an opinion? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Scripting question how to filter list of files based on globs
On 2024-04-09 23:30, Philip Prindeville via openwrt-devel wrote: > I'm trying to modify a script generates a list of filenames one per > line, but should be filtered against a blacklist of file globs. > > Something like: > > % find dir -print | grep -v -f blacklist I got this. When I run it on the openwrt source, where package is the packages directory: Vanilla Output find package -type f -print === ... package/utils/uencrypt/src/CMakeLists.txt package/utils/uencrypt/src/uencrypt-mbedtls.c package/utils/uencrypt/src/uencrypt-openssl.c package/utils/uencrypt/src/uencrypt.c package/utils/uencrypt/src/uencrypt.h package/utils/uencrypt/Makefile package/utils/zyxel-bootconfig/Makefile package/utils/zyxel-bootconfig/files/95_apply_bootconfig package/utils/zyxel-bootconfig/src/Makefile package/utils/zyxel-bootconfig/src/zyxel-bootconfig.c package/utils/ucode-mod-bpf/Makefile package/utils/ucode-mod-bpf/src/bpf.c package/utils/firmware-utils/Makefile package/utils/yafut/Makefile package/utils/debugcc/Makefile === Exclude 'Makefile's find package -type f -name 'Makefile' -prune -o -type f -print === ... package/utils/util-linux/patches/001-meson-properly-handle-gettext-non-existence.patch package/utils/uencrypt/src/CMakeLists.txt package/utils/uencrypt/src/uencrypt-mbedtls.c package/utils/uencrypt/src/uencrypt-openssl.c package/utils/uencrypt/src/uencrypt.c package/utils/uencrypt/src/uencrypt.h package/utils/zyxel-bootconfig/files/95_apply_bootconfig package/utils/zyxel-bootconfig/src/zyxel-bootconfig.c package/utils/ucode-mod-bpf/src/bpf.c === Exclude Makefiles and c files find package -type f -name 'Makefile' -o -name '*.c' -prune -o -type f -print === ... package/utils/util-linux/patches/001-meson-properly-handle-gettext-non-existence.patch package/utils/uencrypt/src/CMakeLists.txt package/utils/uencrypt/src/uencrypt.h package/utils/zyxel-bootconfig/files/95_apply_bootconfig === Exclude Makefiles and c files and patch files find package -type f -name 'Makefile' -o -name '*.c' -o -name '*.patch' -prune -o -type f -print === ... package/utils/uencrypt/src/CMakeLists.txt package/utils/uencrypt/src/uencrypt.h package/utils/zyxel-bootconfig/files/95_apply_bootconfig === find package -type f -name 'Makefile' -o -type d -name 'utils' -prune -o -type f -print === ... === Set your -type accordingly. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/9] router: Apply updated values from RFC8319 (updates RFC4861) to RA/ND
On 2024-04-06 12:05, Jonas Gorski wrote: > Hi, You're right on all counts. I separated out the value clamping and config values to another patch-set. Thanks for your sharp eyes. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] odhcpd patchset
On 2024-04-05 03:34, Daniel Golle wrote:
> On Fri, Apr 05, 2024 at 02:53:03AM +0200, Paul Donald wrote:
>> From: Paul Donald
>>
>> refactor and fix limit prefix preferred_lt to valid_lt in accordance with
>> RFC4861
>
> All changes look good and I generally agree. Thank you!
>
Good. Thank you. :) At this point (after amendments) is a new patch-set
appropriate?
BTW who should one generally CC: for odhcpd?
> Please avoid duplicate commit titles ("various: refactor") as well as
> empty commit messages as that makes the project git history harder to
> read and understand.
Understood. I was at the risk of repeating myself, since the subject and 'body'
line of the short commit message would basically be the same. The openwrt main
repo has some automated checks on github that don't allow no body.
> Also, in case of automated refactoring it would be great if you can
> include the method (e.g. sed script) used for carrying them out in the
> commit message. I know they are trivial and the those scripts can
> easily be inferred by reviewers, however, having a sed-script and
> apply that locally, then compare it with your suggested patch is
> easier than reviewing the patch itself (esp. when it comes to
> accidental ommissions).
I worked through it manually - it varied across files. Although I can see your
value in automation.
Are there any you recommend?
>>
>> Tested on 23.05.0
>
> I assume the patchset is intended to be applied on the current git
> HEAD of odhcpd.git, right? Also that is something worth mentioning in
> the cover letter.
Good point. Yes. odhcpd has not changed since I wrote the patchset.
Before:
==
ICMPv6 Option (Prefix information : fd51:1c2a:8909::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
Valid Lifetime: Infinity (4294967295)
Preferred Lifetime: Infinity (4294967295)
Reserved
Prefix: fd51:1c2a:8909::
==After:==
ICMPv6 Option (Prefix information : fd51:1c2a:8909::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
Valid Lifetime: Infinity (4294967295)
Preferred Lifetime: 420
Reserved
Prefix: fd51:1c2a:8909::
==
> For the whole series:
> Reviewed-by: Daniel Golle
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek/rtl839x: Edgecore ECS4100-12PH support
On 2024-04-04 17:02, Stijn Tintel wrote: > On 4/04/2024 18:00, Paul D wrote: >> On 2024-04-04 16:28, st...@linux-ipv6.be wrote: >> >>> -netgear,gs110tpp-v1) >>> - ucidef_set_poe 130 "$(filter_port_list "$lan_list" "lan9 lan10")" >>> - ;; >> If adding a device, surely these remove lines should not be there? >> >> > Try looking closer. It's called maintaining alphabetical order. > Yep. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek/rtl839x: Edgecore ECS4100-12PH support
On 2024-04-04 16:28, st...@linux-ipv6.be wrote: > -netgear,gs110tpp-v1) > - ucidef_set_poe 130 "$(filter_port_list "$lan_list" "lan9 lan10")" > - ;; If adding a device, surely these remove lines should not be there? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On 2024-04-04 12:00, John Crispin wrote: > Hi, > > > http://mirror2.openwrt.org/OpenWrtOne_top.png Looks nice. Is that silkscreened PD1 - 5V or PD - 15V? I guess it's not critical since PD auto-negotiates, but avoiding ambiguity is good. Were the chip numbers modified in the photos after? extra clarity? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/7] lldpd: note about capabilities
On 2024-04-03 01:15, Jo-Philipp Wich wrote: > Hi, > > What's the purpose of this isolated comment? Either we're shipping version >= > v1.0.15 so this code is guaranteed to work or we don't, in which case the > code should not be there. We're not putting such comments next to all other > option handling code either. Evidence that people think in one direction only. > ~ Jo "What's the purpose of having code review at all?" Comments tell us things. They are *extremely* helpful for those cherry-picking: it is safe to drop such a commit into any older build which has at least that lldpd version. Hope you can see the value in that. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/7] lldpd: fixed interface(s) parsing
Thanks for the insight, Jo. Inline:
On 2024-04-03 01:12, Jo-Philipp Wich wrote:
> Hi,
>
>> For interface type parameters, the man page documents patterns:
>> ```
>> *,!eth*,!!eth1
>>
>> uses all interfaces, except interfaces starting with "eth",
>> but including "eth1".
>> ```
>
> at some point, uci configuration was meant to provide a somewhat sane config
> abstraction over various damon specific native configurations, now I see the
> recurring trend to expose every last native config idiosyncrasy as-is in uci.
I guess that's what people want. More power, and ease, out of the box. Adapt or
die.
It would seem you have not yet read the man page for lldpd...
>
> Is there really a need to support these weird micro formats in uci? The uci
> config for lldpd should deal with logical interface names and translate them
> into layer 2 ones as needed. People requiring complex, hand-tuned settings
> probably want to bypass uci entirly and simply start lldpd with a static
> native config file.
>
Try saying the same thing about the kernel.
With this philosophy, it's like we aim for the 50th percentile. Everybody's
needs differ, which is how openwrt has acquired endless patches and grown.
I do not see this is as an idiosyncrasy, it's standard behaviour in a number of
other systems. The cost to handle it is, as we see from the code, low, while
still retaining the original behaviour ("deal with logical interface names and
translate them into layer 2 ones as needed.").
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: reduce IPv6 ULA prefix generation to a single call
On 2024-04-02 23:00, Elliott Mitchell wrote:
> Second, appears the ${parameter:offset:length} may not be POSIX. I
> dislike this, but do not object since OpenWRT's shell is built with this
> functionality enabled.
UUOC! Ha. Yes, there are a few non POSIXy things in openwrt ash. A number of
other scripts already take advantage of them so it's OK, if it avoids several
external calls to e.g. cut or td.
How about POSIX native array IFS split?
IFS=' ' set -- $(hexdump -vn 5 -e '5/1 "%02x "' /dev/urandom)
uci -q batch <<-EOF >/dev/null
set network.globals.ula_prefix=fd$1:$2$3:$4$5::/48
commit network
EOF
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
(On my phone, Gmail mobile only sends html emails, sorry for that) As this is a legal issue, should we get SFC opinion first ? Since you deem it a legal issue, yes, get their opinion. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uci bug
When running uci from the command line, it parses files in /etc/config If other 'config' type files exist in this path, uci emits: uci: Entry not found to stderr for each non-uci type encountered. This can be confusing. Additionally, for every line printed to stderr in this process, it iteratively adds an extra linefeed. So first line has \n, second line has \n\n, third line has \n\n\n etc. How best to squelch or disambiguate this? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] scripts: gen_image_generic: allow FAT fs on kernel partition for non-GPT targets
Recommend avoiding -a and -o params.
Use instead e.g.
[ -n "$GUID" ] || [ "$KERNELPARTTYPE" = "6" ] || [ "$KERNELPARTTYPE" = "c" ]
https://www.shellcheck.net/wiki/SC2166
On 2024-03-28 18:00, Tomasz Maciej Nowak wrote:
From: Tomasz Maciej Nowak
Some old or proprietary bootloader recognize only FAT file system
variants on storage devices with MBR, unfortunately script ties
format of kernel partition to GPT partition table. So, allow kernel
partition file system to be FAT16 or FAT32 if appropriate type is set
in partition table.
Signed-off-by: Tomasz Maciej Nowak
---
scripts/gen_image_generic.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gen_image_generic.sh b/scripts/gen_image_generic.sh
index 11e40f38868f..44837fde1e12 100755
--- a/scripts/gen_image_generic.sh
+++ b/scripts/gen_image_generic.sh
@@ -49,7 +49,7 @@ dos_dircopy() {
[ -n "$PADDING" ] && dd if=/dev/zero of="$OUTPUT" bs=512 seek="$ROOTFSOFFSET"
conv=notrunc count="$ROOTFSSIZE"
dd if="$ROOTFSIMAGE" of="$OUTPUT" bs=512 seek="$ROOTFSOFFSET" conv=notrunc
-if [ -n "$GUID" ]; then
+if [ -n "$GUID" -o "$KERNELPARTTYPE" = "6" -o "$KERNELPARTTYPE" = "c" ]; then
[ -n "$PADDING" ] && dd if=/dev/zero of="$OUTPUT" bs=512 seek="$((ROOTFSOFFSET +
ROOTFSSIZE))" conv=notrunc count="$sect"
mkfs.fat --invariant -n kernel -C "$OUTPUT.kernel" -S 512 "$((KERNELSIZE /
1024))"
LC_ALL=C dos_dircopy "$KERNELDIR" /
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
lets make a vote So... what's necessary for a vote to start? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
Christian and I have read on IRC people that got offended by my profile pic People will take offence at *anything*. Thus, 'take' and not 'give'. It's a *them* problem, not a *you* problem. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
My 2 cent on the problem of permitting nick is that if we accept that, some funny guy might use nickname like "ExtraHardCockSucker" and we wouldn't have anything to say about it and have to accept it if the contribution is correct. Using Real name prevents that (on 99% of the case) Examples of the case are (quoting an italian name) "Antonio Bocchino" where bocchino means in italian blowjob... It's a funny surname but still less worse than "UltraBoobsLover" kind. Other project even use an entire google form to make user sign DCO and insert all kind of info. Even though humour is good, nobody is advocating this, nor have I seen it in the wild. Allowing nicks does not mean that all have to be allowed. Exercise judgement and common sense. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
a) It's a policy change and not a code change. Policy changes require a vote Then take a(nother) vote. https://lists.openwrt.org/pipermail/openwrt-devel/2024-January/042063.html b) Just because the kernel changed their interpretation of DCO requirements doesn't mean this automatically applies to OpenWrt contribution policy. https://openwrt.org/submitting-patches c) It's completely unclear what the new intended requirements are. For whom? Sorry, I do not understand what you're getting at here. The Kernel's "clarification" regarding this topic is *very* vague in my opinion. What does "known identity" even mean? Known to whom, and to what degree? Do not conflate vague with abstract. The thing we care about here is an email address. Can anyone know it? Yes. Can everyone know it? Yes. Can two people have an identical email address? No. ( This is distinct from two people *using* one email address ). Lavabit shut down over the FBIs pursuit of a single email address (namely Snowden). If an email address is good enough for the FBI, it's good enough for DCO. " A real name does not require a legal name, nor a birth name, nor any name that appears on an official ID (e.g. a passport). " If somebody contributes with his GitHub handle, does that already count as known? When they're backed by en email address, yes. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
here we are again: real name 'discussion'
We have quorum/consensus on this issue. Is it too much to ask that everyone now follow it, or at least have this token 'vote'? Triggered by the yggdrasil additions of recent. https://github.com/openwrt/packages/pull/23072 Paul S amended the policy (in packages[1] and openwrt[2] repos) with an open discussion in PRs for Felix to then change direction via: https://github.com/openwrt/actions-shared-workflows/commit/12d9551f2d07ec34ac813da8612c8014fb393af6 with comment: "should require a public discussion/vote" [1] https://github.com/openwrt/packages/pull/23084 [2] https://github.com/openwrt/openwrt/pull/14380 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
Judging by the recent PRs bumping platforms to 6.6, it seems 6.6 is the goal. https://github.com/openwrt/openwrt/pulls On 2024-03-19 04:27, abnoeh wrote: May I ask what was the result of this vote was? 2024-02-03 오후 9:06에 Hauke Mehrtens 이(가) 쓴 글: Hi, I track the status of the Linux kernel 6.1 migration in this github issue: https://github.com/openwrt/openwrt/issues/14546 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
procd fix
Maybe needs Rafał Miłecki approval?
===
diff --git a/package/system/procd/files/procd.sh
b/package/system/procd/files/procd.sh
index 8ee25f4f08b47..9d936bb7e9778 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -601,7 +601,7 @@ procd_add_mdns_service() {
json_add_int port "$port"
[ -n "$1" ] && {
json_add_array txt
- for txt in "$@"; do json_add_string "" "$txt"; done
+ for txt in "$@"; do [ -n "$txt" ] && json_add_string "" "$txt";
done
json_select ..
}
json_select ..
===
PR at https://github.com/openwrt/openwrt/pull/14597/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
live test system
Maybe others have raised this idea. I won't address potential security issues at the abstract phase (firewalling necessary), but... How about a node which spins up a live openwrt system with the latest luci master with the various PRs that come in? So contributors can see the effect of changes before PRs even go in. Another live system with openwrt master with various openwrt PRs that come in, integrated under some predictable URL (https://host/pr2). Some kind of capability to tweak settings live, or see the console output. ( Does owrt run well in docker as a guest? ) This is not intended as a solution to the myriad hardware platforms that require real live tests, but one for catching the lions share of problems on a generic running system. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
Elliott, You raise some important points, and also mention some *solutions* which is commendable. 1) all work is done voluntarily 2) time is limited 3) understanding is lacking 4) courage is lacking Or... success has many fathers, but failure is an orphan. Speaking from personal experience over the course of several years: I've seen patch-sets appear here and get lost like a fart in the wind. Have a look at patchwork. They require attention. See 1 and 2. Then the kernel and software has changed so many times in-between that patches become irrelevant. The exception is members who post patches here, who wrote said patches, and have commit permissions, see those go in. In view of this, I propose a maximum two week life-time/cycle. Time limits ensure things have a definite start and finish. Didn't work out? Try again. New member votes have 21 days. After this time period, it's safe to assume your patch has not garnered interest or enough understanding. What is the problem with patches here? It requires someone to do *work* to apply it and see it in context. On github, for example, just send a PR and the work is already done for you. You see the patch in context, and you can tag other reviewers immediately. Small changes are handled quickly. Big ones move at glacial pace. That said, I've yet to see a maintainer response to PRs in more obscure repos on e.g. https://github.com/openwrt/odhcpd I asked for commit permissions to at least the luci repo because I was tired of waiting for simple fixes and good ideas to land *for years* which I knew would work. I set about halving the amount of open PRs and we've seen virtually no breakage. At the same time, I'm no vet, so I defer bigger changes to the vets. This brings us to another point: patchsets should be small, unless someone can take responsibility for it from coding to commit. BUT most of this belies the understanding with GH: it uses git. A change management system. If you screw something up, you can unscrew it by ... reverting. People don't want to take responsibility, are afraid of being wrong or getting shouted at for screwing up builds. ( See 3 and 4 ). It's software. Make a new one. Reverting tells us a number of things: we learn what did not work, and we tried. * We need more trusted members who can tackle specific package areas to deal with the volume of PRs on github. Especially in the openwrt repo. On 2024-03-13 09:43, Olliver Schinagl wrote: On 13-03-2024 08:46, Felix Baumann wrote: Am 13. März 2024 05:11:23 MEZ schrieb Elliott Mitchell: I must challenge this. If patches via the mailing list were accepted, then we should see things sent to the mailing list getting into the repository. Yet many patches get no attention. Some get reviews from various people, yet then never get into the main repository. It's the same for Github, some stuff doesn't get in and remains there. There might be a difference what kind of PRs are send to the mailing list and you get attention of different committers when sending to mailing list vs sending to Github. Github patches might be accepted more easily when it's just a new device for a well established target. I feel like patches on the mailing list are ignored, when committers don't have time for review or don't feel confident enough to do it well (not their field of expertise). Or if it's written in a language they don't feel confident reviewing. *PERSONALLY* I think mailing list reviews are on their way out. People have found that there are easier and better ways. Granted, some folks still _prefer_ mailing list reviews. *I PERSONALLY* do not at all. I hate my mailbox being full with threads of stuff I have no attention for at that moment, it just adds noise for me. And ignoring it for a while just puts huge amounts of e-mails in my mailbox, that become useless after a while. Though I much rather would like to see GitLab then GitHub use :p but that's more the FOSS spirit, and avoiding anything Microsoft where possible :p Even the Linux kernel (forgive me for omitting the link, though I can find it if really needed, they are just not easy google terms) is discussing this; but there's a few technicalities holding them back for the most part (See Linus's rant against github a few years ago, but diff-range, comment on commit-message are two key points). Further more, I think it is fair to realize that very few developers that exist, as said before, prefer different ways of working. This sucks, but means we have two 'groups' of reviewers in two different locations. In the end it's up to one committer to do the merge. If Noone replies, then that doesn't happen and the patch will only collect dust. Yes, that might be stupid if there was no critical comment on a patch but that is how it currently appears to be. This is still voluntary work and people choose themselves what to spend time on. I realize this is not a
Re: rpcd / acl.d problem
On 2024-03-02 19:50, Jo-Philipp Wich wrote:
Hi.
You need a double backslash to escape the backslash itself.
"/usr/bin/find -L /dev -maxdepth 3 -type c -name lp\\[0-9\\]": ["exec"]
~ Jo
No go. Still 403.
Pretty sure I've tried all workable permutations in the js and JSON of
escaping. Restarted rpcd and cleared browser cache between every new test.
JSON:
"/usr/bin/find -L /dev -maxdepth 3 -type c -name lp\\[0-9\\]": ["exec"]
JS
fs.exec_direct('/usr/bin/find', [ '-L', '/dev', '-maxdepth', '3',
'-type', 'c', '-name', 'lp[0-9]' ])...
403
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Vote: New member proposal linusw (Linus Walleij)
No voting rights, but +1 for his contributions and help esp on XG6846 and bcm/marvell stuff. On 2024-03-02 16:01, Christian Marangi (Ansuel) wrote: From: Petr Štetiar Hi, Linus is renowned in the FOSS community primarily for his exceptional contributions to the Linux kernel, where he maintains an impressive array of subsystems, drivers, and architectures. He has been contributing to OpenWrt for about six years already and given that we have been readily embracing his contributions without further scrutiny, I believe it's time to officially invite Linus to join our team. The vote will conclude in 21 days, ending on March 18, 2024. Cheers, Petr --- This is forward also to devel mailing list in case some member missed the vote on adm mailing list. The vote started 2024-02-26. If any member wants to participate please replay to both adm and this mail to prevent any kind of problem by missing votes. The progress on this vote can be tracked here [1]. [1] https://openwrt.org/voting/2024-02-new-member-linusw#stats ___ 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 / acl.d problem
Can this be fixed or is lib micro box the limitation? See jows commit for the current apex of permission strings: https://git.openwrt.org/?p=project/rpcd.git;a=commitdiff;h=aaa08366e6384d9933a405d1218b03c1b167f9e5 In https://github.com/openwrt/luci/pull/6907 I encountered a permissions problem. The command to permit is: /usr/bin/find -L /dev -maxdepth 3 -type c -name lp[0-9] That is, the find command needs a regex of lp[0-9], to find only the following: lp0 lp1 ... lp9 The find man page says: -name pattern True if the last component of the pathname being examined matches pattern. Special shell pattern matching characters (“[”, “]”, “*”, and “?”) may be used as part of pattern. These characters may be matched explicitly by escaping them with a backslash (“\”). The acl.d file expects a filter in the /root/usr/share/rpcd/acl.d/luci-*.json JSON, but it does not understand the literal command: "/usr/bin/find -L /dev -maxdepth 3 -type c -name lp[0-9]": ["exec"] causes 403. It anticipates lp0, lp1, ... in the command. "/usr/bin/find -L /dev -maxdepth 3 -type c -name lp\[0-9\]": ["exec"] Causes also 403 but the page does not even load. My JSON parser dislikes this also. So the workaround is to use the glob: * /usr/bin/find -L /dev -maxdepth 3 -type c -name lp* where the author of the above commit says: "(do not use glob *, as) This will prevent unwanted parameter injection." ¯\_(ツ)_/¯ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubus running key status
On 2024-02-29 12:56, Ravi Paluri (QUIC) wrote:
Thanks, Paul for the reply.
Can you help us with a sample usage of "ubus subscribe" OR "ubus listen" OR "ubus
monitor", which helps us to learn, "running" flag change to false from true.
I know not whether such is even possible. Start here:
https://git.openwrt.org/project/ubus.git
We are polling the status of "running" flag as below.
ubus call service list '{"name":"test*.init","verbose":"True"}' | grep -i
\"running\"
Is * even supposed to work?
this shows the unetd instance:
ubus call service list '{"name":"unetd"}'
this does not:
ubus call service list '{"name":"unet*"}'
ubus call service list '{"name":"unetd"}' | jsonfilter -q -e
"@['unetd'].instances[*].running"
returns simply: true
This is working when script execution takes some time.
For some scripts that take very less time (for e.g, a single instruction such as "uci set
.."), we are not able to detect the transition of "running" flag to false from true
as the flag changes it's value quickly.
How about using the return code of the script?
Thanks,
Ravi
-Original Message-
From: openwrt-devel On Behalf Of Paul
D
Sent: Friday, February 23, 2024 7:35 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: ubus running key status
WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
On 2024-02-23 13:43, Ravi Paluri (QUIC) wrote:
Can you let us know, is there a way to get a notification when the "running" key value moves to
"false" from "true"?
OR is there any ubus API to which we can register a callback, which will then
be invoked when the execution is complete?
Not certain about callbacks - but there is "ubus monitor" "ubus subscribe" "ubus listen"
and "ubus wait_for"
They're blocking calls, at least.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
lldpd: FAO stintel and all committers to openwrt repo
The last PR that you merged included some fatal copy/paste errors. At least the first PR below fixes them https://github.com/openwrt/openwrt/pull/14583 https://github.com/openwrt/openwrt/pull/14584 I have some other fixes pending but those depend on these PRs. /P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firmware-utils] ptgen: fix limitation for active partition in GPT
On 2024-02-23 15:49, Thomas Richard wrote: In GPT there is no reason to limit the active partition number to 4. This limitation is only for MBR, as it corresponds to the maximum number of primary partitions. Signed-off-by: Thomas Richard Agreed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 2024-02-26 19:39, John Crispin wrote: Hi Rafał, Is there any update / schedule you could share? I have been meaning to send an update for a few days. Thanks for reminding me. I'm really looking forward to this device. yeah, me too ;) Lots of stuff has been happening. There was a short break due to the lunar new year but we are picking up pace again. *) schematics are done *) PCB is mostly routed (https://nbd.name/one-top.jpg https://nbd.name/one-bottom.png) If there is no price difference, can we have 90 degree angled pins for GND+TX+RX serial header, so the pins face away from the board as USB sockets do, and not stand up perpendicularly. This way serial consoles are workable even when device is in a case. Does anyone else have opinions on this? *) there was a small hiccup in registering the OUI block that we are currently resolving *) the trademark agreement is being worked on - I have a call with SFC tomorrow to discuss this I am expecting that the first 15 PCBA samples will be produced shortly and be shipped by end of march. as for the software side, I modified a mt7981 RFB to have dual flash, mikrobus, s.T. I could build and test dts files. I ordered the RTC used on a carrier board and was able to test it. all the u-boot patches are pretty much done. there is a pretty elaborate uboot-env with lots of commands to provide easy un-brickability. I have a local OpenWrt tree with ~10 patches that I hope to send as a RFC later this week. the PCB will probably be light blue (PANTONE 306 C) which is the light blue used inside the OpenWrt logo. we are still figuring this out with the supplier. In 20 years when these devices are old and need recycling, how recyclable are the PCBs? What substances go into it? Toxic ones? I should probably start building a page inside the wiki to provide better visibility into what is happening. shout out to pepe2k, SFC and MTK for the never ending support that they provide on this journey. And an extra big thank you to Simon, the designer/engineer from BPi that has been ultra cool in making this become a reality John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives
What tar standard are you aiming to adhere to?
On 2024-02-26 15:14, Rafał Miłecki wrote:
From: Jo-Philipp Wich
This allows building uncompressed tar archives from shell scripts (and
compressing them later if needed)
Signed-off-by: Rafał Miłecki
---
package/base-files/files/lib/upgrade/tar.sh | 84 +
1 file changed, 84 insertions(+)
create mode 100644 package/base-files/files/lib/upgrade/tar.sh
diff --git a/package/base-files/files/lib/upgrade/tar.sh
b/package/base-files/files/lib/upgrade/tar.sh
new file mode 100644
index 00..00057dd760
--- /dev/null
+++ b/package/base-files/files/lib/upgrade/tar.sh
@@ -0,0 +1,84 @@
No shebang?
+# SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+__tar_print_padding() {
+ [ $1 -eq 0 ] || dd if=/dev/zero bs=$1 count=1 2>/dev/null
+}
+
+__tar_make_member() {
+ local name="$1"
+ local content="$2"
+ local username="$3"
+ local groupname="$4"
+ local mtime="$5"
+ local mode=644
+ local uid=0
+ local gid=0
+ local size=${#content}
+ local type=0
+ local link=""
+
recommend that they're ordered here same as struct order:
struct posix_header
{ /* byte offset */
char name[100]; /* 0 */
char mode[8]; /* 100 */
char uid[8]; /* 108 */
char gid[8]; /* 116 */
char size[12];/* 124 */
char mtime[12]; /* 136 */
char chksum[8]; /* 148 */
char typeflag;/* 156 */
char linkname[100]; /* 157 */
char magic[6];/* 257 */
char version[2]; /* 263 */
char uname[32]; /* 265 */
char gname[32]; /* 297 */
char devmajor[8]; /* 329 */
char devminor[8]; /* 337 */
char prefix[155]; /* 345 */
/* 500 */
};
+ # 100 byte of padding bytes, using 0x01 since the shell does not tolate
null bytes in strings
tolerate?
+ local
pad=$'\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1'
+
maybe try:
local pad=$(printf '\1%.0s' $(seq 100))
+ # validate name
+ if [ "${name:0:1}" = "/" ]; then
+ name="${name:1}"
+ fi
One liner:
name=${name#/}
+
+ # truncate string header values to their maximum length
+ name=${name:0:100}
+ link=${link:0:100}
+ username=${username:0:32}
+ groupname=${groupname:0:32}
+
+ # construct header part before checksum field
+ local header1="${name}${pad:0:$((100 - ${#name}))}"
+ header1="${header1}$(printf '%07d\1' $mode)"
+ header1="${header1}$(printf '%07o\1' $uid)"
+ header1="${header1}$(printf '%07o\1' $gid)"
+ header1="${header1}$(printf '%011o\1' $size)"
+ header1="${header1}$(printf '%011o\1' $mtime)"
+
+ # construct header part after checksum field
+ local header2="$(printf '%d' $type)"
+ header2="${header2}${link}${pad:0:$((100 - ${#link}))}"
+ header2="${header2}ustar ${pad:0:1}"
+ header2="${header2}${username}${pad:0:$((32 - ${#username}))}"
+ header2="${header2}${groupname}${pad:0:$((32 - ${#groupname}))}"
+
+ # calculate checksum over header fields
+ local checksum=0
+ for byte in $(printf '%s%8s%s' "$header1" "" "$header2" | tr '\1' '\0' | hexdump
-ve '1/1 "%u "'); do
+ checksum=$((checksum + byte))
+ done
+
+ # print member header, padded to 512 byte
+ printf '%s%06o\0 %s' "$header1" $checksum "$header2" | tr '\1' '\0'
+ __tar_print_padding 183
+
+ # print content data, padded to multiple of 512 byte
+ printf "%s" "$content"
+ __tar_print_padding $((512 - (size % 512)))
+}
+
+tar_make_member_from_file() {
+ local name="$1"
+ local username="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 3)"
+ local groupname="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 4)"
+
+ __tar_make_member "$name" "$(cat $name)" "$username" "$groupname" "$(date +%s -r
"$1")"
+}
+
+tar_make_member_inline() {
+ local name="$1"
+ local content="$2"
+ local username="${3:-root}"
+ local groupname="${4:-root}"
+ local mtime="${5:-$(date +%s)}"
+
+ __tar_make_member "$name" "$content" "$username" "$groupname" "$mtime"
+}
+
+tar_close() {
+ __tar_print_padding 1024
+}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubus running key status
On 2024-02-23 13:43, Ravi Paluri (QUIC) wrote: Can you let us know, is there a way to get a notification when the "running" key value moves to "false" from "true"? OR is there any ubus API to which we can register a callback, which will then be invoked when the execution is complete? Not certain about callbacks - but there is "ubus monitor" "ubus subscribe" "ubus listen" and "ubus wait_for" They're blocking calls, at least. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: procd, possible hotplug issue?
On 2024-02-17 22:55, e9hack wrote: Hi, I face a problem with hotplug calls. To execute hotplug calls, procd checks given environment variables. If a variable is empty, it is simply not set by procd. If such a variable is already set by the shell, the called hotplug script gets a wrong value. This occurs with dhcp hotplug scripts. On some dhcp changes, dnsmasq executes its dhcp script. This sets the variable HOSTNAME. Sometimes this value is empty. This results in calling the hotplug script with HOSTNAME set to the router name, because the variable is already set. I think, procd must clear or delete such environment variables. Regards, Hartmut Could you show an example of this? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: sysupgrade: include uci-defaults script disabling services
On 2024-02-15 15:42, Rafał Miłecki wrote: On 14.02.2024 21:50, Paul D wrote: Would services not do better to be tracked within uci and its config files in /etc/config? Well, it's a part of a mess we have in our init/config code. It was only last week that Jo was discussing it with Ansuel. In short we have: 1. Packages with no UCI config option for enabling/disabling 2. Packages with "enable" 3. Packages with "enabled" 4. Packages with "disable" 5. Packages with "disabled" I'm pretty sure most users are used to enabling/disabling services using UCI config option but not all of them have such possibility. That is the case my change is meant to deal with. An alternative would be to make sure every package uses "enabled" (or "disabled") UCI option. Should we do that? Is 'on' or 'off' in the config perhaps simpler? I think it avoids the linguistic differences of past participle vs present simple. (Sometimes this distinction is important to have.) Otherwise 'en/disabled' is a good paradigm to encourage in configs. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: some github runner failers
I recommend avoiding Docker (hub) entirely if possible. GHCR has been great in my experience. Integrates nicely with GH actions. On 2024-02-15 13:37, Paul Spooren wrote: On Feb 15, 2024, at 00:12, Paul D wrote: https://github.com/openwrt/packages/actions/runs/7908507874/job/21587828762?pr=23415 for various platforms errors: #4 [internal] load metadata for docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05 #4 ERROR: no match for platform in manifest sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not found -- [internal] load metadata for docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05: -- Dockerfile:2 1 | ARG ARCH=x86-64 2 | >>> FROM openwrt/rootfs:$ARCH 3 | 4 | ADD entrypoint.sh /entrypoint.sh ERROR: failed to solve: openwrt/rootfs:i386_pentium-mmx-openwrt-23.05: no match for platform in manifest sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not found Error: Process completed with exit code 1. Maybe bad timing where a container is updated in the middle of a pull? I’ve seen some hiccups for Docker hub recently so we may want to switch to ghcr.io <http://ghcr.io/> since we’re using their runners anyway? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
some github runner failers
https://github.com/openwrt/packages/actions/runs/7908507874/job/21587828762?pr=23415 for various platforms errors: #4 [internal] load metadata for docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05 #4 ERROR: no match for platform in manifest sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not found -- > [internal] load metadata for docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05: -- Dockerfile:2 1 | ARG ARCH=x86-64 2 | >>> FROM openwrt/rootfs:$ARCH 3 | 4 | ADD entrypoint.sh /entrypoint.sh ERROR: failed to solve: openwrt/rootfs:i386_pentium-mmx-openwrt-23.05: no match for platform in manifest sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not found Error: Process completed with exit code 1. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: sysupgrade: include uci-defaults script disabling services
(Not directly commenting on this change set)
Would services not do better to be tracked within uci and its config
files in /etc/config?
Or do changes to those files there risk triggering other procd actions
to the services they dictate?
On 2024-02-14 16:05, Rafał Miłecki wrote:
From: Rafał Miłecki
Disabled services should be kept disabled after sysupgrade. This can be
easily handled using a proper uci-defaults script.
Extend sysupgrade to check for disabled services, generate uci-defaults
script disabling them and include it in backup.
Cc: Christian Marangi
Cc: Jo-Philipp Wich
Cc: Jonas Gorski
Signed-off-by: Rafał Miłecki
---
package/base-files/files/sbin/sysupgrade | 10 ++
1 file changed, 10 insertions(+)
diff --git a/package/base-files/files/sbin/sysupgrade
b/package/base-files/files/sbin/sysupgrade
index 1e09f65e07..b1ada062ed 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -273,6 +273,16 @@ create_backup_archive() {
\) | sed -e 's,.*/,,;s/\.control /\t/' >
"$dir/${INSTALLED_PACKAGES}"
fi
+ mkdir -p $dir/etc/uci-defaults/
+ touch $dir/etc/uci-defaults/10_disable_services
+ for service in /etc/init.d/*; do
+ if ! $service enabled; then
+ echo "$service disable" >>
$dir/etc/uci-defaults/10_disable_services
+ fi
+ done
+ echo "exit 0" >> $dir/etc/uci-defaults/10_disable_services
+ echo "/etc/uci-defaults/10_disable_services" >> "$CONFFILES"
+
v "Saving config files..."
sed -i 's/^\///' "$CONFFILES" # Drop leading slashes
[ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: procd error messages
On 2024-02-13 00:23, Hartmut Birr wrote:
Hi,
I let /etc/init.d/network log some more things by changing:
--- network.rom 2024-02-12 20:46:51.0 +0100
+++ network 2024-02-12 23:18:07.0 +0100
@@ -16,8 +16,10 @@ start_service() {
init_switch
procd_open_instance
- procd_set_param command /sbin/netifd
+ procd_set_param command /sbin/netifd -l 5 -d 15
procd_set_param respawn
+ procd_set_param stdout 1
+ procd_set_param stderr 1
procd_set_param watch network.interface
[ -e /proc/sys/kernel/core_pattern ] && {
procd_set_param limits core="unlimited"
It reports some errors by using logread -e netifd:
Mon Feb 12 23:30:27 2024 daemon.err netifd[29247]: device_claim(694):
Claim Network device pppoe-wan, new active count: 2
Mon Feb 12 23:30:27 2024 daemon.err netifd[29247]:
proto_shell_handler(231): run setup for interface 'wan_6'
Mon Feb 12 23:30:27 2024 daemon.err netifd[29247]:
__device_add_user(1037): Add user for device 'pppoe-wan', refcount=2
Mon Feb 12 23:30:27 2024 daemon.debug pppd[24514]: Script
/lib/netifd/ppp6-up finished (pid 24752), status = 0x0
Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]: sh: missing ]
Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]: device_claim(694):
Claim Network alias pppoe-wan, new active count: 2
Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]:
interface_add_dns_server(1435): Add IPv6 DNS server: 2003:180:2:::
Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]:
interface_add_dns_server(1435): Add IPv6 DNS server: 2003:180:2:::
Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]:
interface_queue_event(124): Queue hotplug handler for interface 'wan_6',
event 'ifup'
Mon Feb 12 23:30:45 2024 daemon.notice netifd: Interface 'wan_6' is now up
Mon Feb 12 23:30:50 2024 daemon.err netifd[29247]: task_complete(109):
Complete hotplug handler for interface 'wan'
Mon Feb 12 23:30:50 2024 daemon.err netifd[29247]: call_hotplug(100):
Call hotplug handler for interface 'wan', event 'ifupdate' (pppoe-wan)
Call exits netifd.
Does it go to ppp.sh?
It could be that some ' -a ' condition is breaking down...?
[ blah -a blah2 ]
?
https://git.openwrt.org/?p=project/netifd.git;a=blob;f=examples/proto/ppp.sh;hb=f01345ec13b9b27ffd314d8689fb2d3f9c81a47d
https://git.openwrt.org/?p=project/netifd.git;a=blob;f=scripts/netifd-proto.sh;h=87d337df07e9aa94b80ea53d050eadde791739d9;hb=refs/heads/master
Mon Feb 12 23:31:05 2024 daemon.err netifd[29247]: sh: missing ]
Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: sh: out of range
Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: task_complete(109):
Complete hotplug handler for interface 'wan'
Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: call_hotplug(100):
Call hotplug handler for interface 'wan_6', event 'ifup' (pppoe-wan)
Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: /sbin/uci: Invalid
argument
Mon Feb 12 23:31:16 2024 daemon.err netifd[29247]: sh: missing ]
Is it possible to let print netifd more informations related to errors
from executed commands like:
Mon Feb 12 23:31:05 2024 daemon.err netifd[29247]: sh: missing ]
Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: sh: out of range
Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: /sbin/uci: Invalid
argument
I'm not able to identify the executed scripts.
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
procd.sh: mdns addition
FAO Rafał A great to have mdns addition within procd.sh: https://github.com/openwrt/openwrt/pull/10715 A necessary bug fix: https://github.com/openwrt/openwrt/pull/14597 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
luci-base: ui.js: avoid polling in a tight loop on confirm/rollback
https://github.com/openwrt/luci/pull/6347 approved? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
On 2024-02-03 13:06, Hauke Mehrtens wrote: Hi, I track the status of the Linux kernel 6.1 migration in this github issue: https://github.com/openwrt/openwrt/issues/14546 There are still many targets on kernel 5.15 without testing support for kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to get everything to 6.1 and more or less stable. Kernel 6.1 support is also missing for some important targets like lantiq, realtek and ramips. Which kernel should we use for the next major OpenWrt release? We have two options and I would like to get some feedback on these: 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or most of the targets are on kernel 6.1 by default. 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or most of the targets are on kernel 6.6 by default. Do not do any stable OpenWrt release which supports kernel 6.1. Doing a OpenWrt release with multiple kernels cases too much maintenance effort from my point of view based on previews experience. I think with kernel 6.1 we can branch off at around May 2024. With kernel 6.6 we could probably branch off around September 2024. The final release will be out about 2 to 4 months later. Do a release using 6.6 - although from past experience this means no OpenWrt 24. 6.6 likely means carrying fewer patches also. Does this give rise to the potential that some older devices get dropped? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
odhcpd github repo
Who reviews what goes on in this repo? https://github.com/openwrt/odhcpd It needs some reviewer love. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] New member proposal: Robimarko (Robert Marko)
+1 On 2024-01-30 19:15, Christian Marangi (Ansuel) wrote: Robert is active in OpenWrt since 2017 and with some recent stats, he has more than 310 commits merged in OpenWrt. He also have uncounted Reviewed-by tag on various PR and merged commits and generally helps in everything related to IPQ (ipq806x, ipq40xx and ipq807x) and some mvebu targets. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] modules: Add kernel module for MV88E6xxx DSA switch
Is this what we tested on 6846? Or this is what you've been cooking? :) I'm almost certain it's the latter. On 2024-01-30 23:33, Linus Walleij wrote: This adds a kernel module package for the Marvell MV88E6XXX DSA switch and a separate module package for the DSA tagger since it can in theory be used by multiple DSA switches. Enable both DSA and EDSA tags in the tagger. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mtdsplit_uimage: Split also after offsetted uImage
The simple past tense of offset is... offset :)
Suggested: Split also after offset uImage
BTW: was this what I tested in your factory and sysimages for the XG6846?
If so can you roll a fresh one with this patch? Then I can give you a
more recent Tested-By:
On 2024-01-23 23:17, Linus Walleij wrote:
The uImage splitter recognizes a rootfs either:
1. Right after the uImage if it comes first in the
partition or
2. Before the uImage if it is located at an offset
inside the partition.
Add a third case:
3. After the uImage also at an offset inside the
partition, if and only if 1 and 2 fails.
The reason why this is needed is because on the
BCM6328-based Inteno XG6846 we need to put a small
U-Boot binary first in the partition, then the uImage,
then the rootfs.
Suggest rewording to:
This is necessary because the BCM6328-based Inteno XG6846 won't boot an
image without a small U-Boot binary first in the partition followed by
the uImage, then the rootfs.
Then it doesn't depend on our needs :)
The U-Boot binary that comes first cannot be split off
into its own partition in this case because it needs
to be part of the bigger "firmware" partition. Which
we use for installation and upgrades.
Signed-off-by: Linus Walleij
---
.../files/drivers/mtd/mtdsplit/mtdsplit_uimage.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
index a3e55fb1fe38..de043fb9f702 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
+++ b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
@@ -217,11 +217,22 @@ static int __mtdsplit_parse_uimage(struct mtd_info
*master,
if (ret) {
pr_debug("no rootfs before uImage in \"%s\"\n",
master->name);
- goto err_free_buf;
- }
- rootfs_offset = 0;
- rootfs_size = uimage_offset;
+ /* Try after the uImage */
+ ret = mtd_find_rootfs_from(master, uimage_offset +
uimage_size,
+ master->size, _offset,
);
+ if (ret) {
+ pr_debug("no rootfs after uImage either in
\"%s\"\n",
+master->name);
+ goto err_free_buf;
+ }
+
+ rootfs_size = master->size - rootfs_offset;
+ uimage_size = rootfs_offset - uimage_offset;
+ } else {
+ rootfs_offset = 0;
+ rootfs_size = uimage_offset;
+ }
}
if (rootfs_size == 0) {
---
base-commit: 1b7e62b20b1735fcdc498a35e005afcd775abcf4
change-id: 20240123-offsetted-uimage-splitter-f5b65f0df2ed
Best regards,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
p910nd
Trying to add the almost mandatory +kmod-usb-printer to p910nd package Since just about every known configuration still mandates that the user install kmod-usb-printer. https://github.com/openwrt/packages/pull/23094 Is there a smarter way to add this depends? I don't yet understand how it behaves: +USB_SUPPORT:kmod-usb-printer "If USB_SUPPORT is on, just throw this module in, instead of just blindly depending on the mod"? I wasn't sure whether the suggester intended: DEPENDS:=@USB_SUPPORT If you're happy with just the following, approve the PR: DEPENDS:=+kmod-usb-printer ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] package: add new poe-common package
So, the power budget is a global option. Do we ever envisage that parts
of this budget can be concretely assigned to specific ports or more
abstract ?
e.g.
config port
option name 'lan8'
option id '1'
option enable '1'
option budget '15'
On 2024-01-25 14:00, Sander Vanheule wrote:
Create a new package to generate configuration files for devices capable
of delivering power via PoE. The configuration file at /etc/config/poe
can be used by PoE daemons to configure the hardware in an implementation
specific way.
This is part of the core packages because it needs to be in sync with
the format of board.json, from which the config file is generated. The
config file structure is based on the current config file of the
realtek-poe package, but should be (and remain) implementation
independent. With a common basis, a common (LuCI) configuration
interface also becomes possible in the future.
For a device with a power budget of 130W and ports lan1-lan8 mapping to
PSE outputs 8-1, /etc/config/poe could look like (lan1-lan6 omitted):
config global
option budget '130'
config port
option name 'lan8'
option id '1'
option enable '1'
config port
option name 'lan7'
option id '2'
option enable '1'
[...]
Signed-off-by: Sander Vanheule
---
package/network/config/poe-common/Makefile| 37
.../poe-common/files/etc/uci-defaults/30_poe | 42 +++
2 files changed, 79 insertions(+)
create mode 100644 package/network/config/poe-common/Makefile
create mode 100755
package/network/config/poe-common/files/etc/uci-defaults/30_poe
diff --git a/package/network/config/poe-common/Makefile
b/package/network/config/poe-common/Makefile
new file mode 100644
index ..a7970b4b5b15
--- /dev/null
+++ b/package/network/config/poe-common/Makefile
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=poe-common
+PGK_VERSION:=1
+PKG_RELEASE:=1
+
+PKG_MAINTAINER:=Sander Vanheule
+PKG_LICENSE:=GPL-2.0-or-later
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/poe-common
+ SECTION:=net
+ CATEGORY:=Network
+ TITLE:=Common base files for PoE
+ DEPENDS:=+libubox +libuci
+endef
+
+define Package/poe-common/conffiles
+/etc/config/poe
+endef
+
+define Package/poe-common/description
+ Common base files for PoE configuration and control
+endef
+
+define Package/poe-common/install
+ $(INSTALL_DIR) $(1)/etc/uci-defaults/
+ $(INSTALL_CONF) ./files/etc/uci-defaults/30_poe $(1)/etc/uci-defaults/
+endef
+
+define Build/Compile
+endef
+
+$(eval $(call BuildPackage,poe-common))
diff --git a/package/network/config/poe-common/files/etc/uci-defaults/30_poe
b/package/network/config/poe-common/files/etc/uci-defaults/30_poe
new file mode 100755
index ..3a429402c59b
--- /dev/null
+++ b/package/network/config/poe-common/files/etc/uci-defaults/30_poe
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+[ -e /etc/config/poe ] && exit 0
+
+. /lib/functions.sh
+. /usr/share/libubox/jshn.sh
+
+CFG=/etc/board.json
+
+json_init
+json_load_file "${CFG}"
+
+json_is_a poe object || exit 0
+
+umask 055
+touch /etc/config/poe
+
+json_select poe
+ json_get_vars budget
+
+ uci add poe global
+ uci set poe.@global[-1].budget="$budget"
+
+ if json_is_a ports array; then
+ json_get_values ports ports
+ id='1'
+
+ for port in $ports; do
+ uci -q batch <<-EOF
+ add poe port
+ set poe.@port[-1].name='$port'
+ set poe.@port[-1].id='$id'
+ set poe.@port[-1].enable='1'
+ EOF
+ let id=id+1
+ done
+ fi
+json_select ..
+
+uci commit
+
+exit 0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
A kickstarter is a good way to forecast demand. You've captured the imagination of the geek community. Not aware of peripheral issues or complexities in doing a kickstarter, though I agree with forecasting demand. "Geeks" are good at commenting on stuff, and intellectualizing a new board: let's see how many put their money where their mouth is. I, for one, think the new board's a great idea, although I'm still happy with my Archer. I do feel that an upgrade in the next 12mo may become necessary, however. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenSSH dropping DSA
https://lists.mindrot.org/pipermail/openssh-unix-announce/2024-January/000156.html OpenSSH dropping DSA 2024/06 disabled 2025/01 code removal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
odhcpd PRs
Please take a look at the PRs here: https://github.com/openwrt/odhcpd/pulls They need some attention :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: PKG_MAINTAINER_HANDLE
On 2024-01-08 16:03, Paul Spooren wrote: Hi Paul, PKG_MAINTAINER:=Joe Bloggs PKG_MAINTAINER_HANDLE:=github: @joe; https://forum.openwrt.org/u/joe/ Plan B co-opt existing PKG_MAINTAINER field, but perhaps it's possible? e.g: PKG_MAINTAINER:=Joe Bloggs , github: @Joe I think for that you could use a Codeowners file. Best, Paul In this case, what takes priority? If both Codeowners and Makefile PKG_MAINTAINER exist, which is preferred? Do we only expect handles in Codeowners and PKG_MAINTAINER email in Makefile? Codeowners lives side-by-side with Makefile or repo root? I dislike information spread across several different places: it further behoves the hunt to track down relevant information. Today to make a PR, I already have to spend five minutes chasing this info down if I want things to stand a chance of going smoothly, initially. This is friction for newcomers and for low-hanging-fruit fixes. If all of the information is in one place, it's easy (easier). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
6GHz seems a starting point nowadays, although I get by with 5GHz. If the BPi can be extended with add-on cards for exactly this area, that's a great starting point also. Ideally sub $100 for any product. * Packages with cases+PSU are a must for broader acceptance, and to prevent fatigue from having to buy several parts to get a working system that can be wall/ceiling-mounted. This is an implicit advantage to buying OTS routers: everything needed is there. An expensive ecosystem becomes a limiting factor for adoption. * Having a few H/W variants available provides demand metrics: which variant is more in demand and popular speaks to what people want. * CPU which manages line-speed WireGuard is very important nowadays: with governments monitoring people, users demand privacy afforded by VPNs. Wi-Fi is still inherently limited by the closed-source nature of the Wi-Fi blobs: will those ever be open sourced? It'd be brave, but the right way. ( Lots of IP ) On 2024-01-09 11:49, John Crispin wrote: tl;dr In 2024 the OpenWrt project turns 20 years! Let's celebrate this anniversary by launching our own first and fully upstream supported hardware design. If the community likes the idea outlined below in greater details, we would like to start a vote. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
PKG_MAINTAINER_HANDLE
Plan A Proposal for e.g. PKG_MAINTAINER_HANDLE which uniquely identifies the user's github @ handle (or forum?) to ease identifying and tagging the user (for review purposes) on github, given the general trend to discuss changes in these locations. Such variable to go into Makefiles: PKG_MAINTAINER:=Joe Bloggs PKG_MAINTAINER_HANDLE:=github: @joe; https://forum.openwrt.org/u/joe/ Plan B co-opt existing PKG_MAINTAINER field, but perhaps it's possible? e.g: PKG_MAINTAINER:=Joe Bloggs , github: @joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
dnsmasq PRs which need some reviewer love
Could I get some reviews please? https://github.com/openwrt/openwrt/pull/14269 https://github.com/openwrt/openwrt/pull/14179 There are some other PRs for dnsmasq which are interesting (around ~20), but they seem to need some more work. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openvpn issue
Anything useful here which could go in a PR or two on github? I've added multihome to luci: a5ed5976f4cf70a36863e69da8c055f855545f87 The --local param seems to be in there already. On 2023-12-18 17:30, e9hack wrote: Am 18.12.2023 um 16:22 schrieb Paul D: How does pppoe-wan get its IP? It is retrieved by odhcp6c. You may not be able to do much about that, but you can hint which IPv6 an interface gets using the assignment length, hint and prefix settings. I don't use openvpn, but perhaps it has something like this? I guess it would try to pick a source IP with the 'lowest' IPv6 from an available /64? It isn't the lowest address. In my case it is all the time the ipv6 address from br-guest1, even if I exchange the ip6hint value between the three local interfaces. I could solve the problem. First I did modify /etc/init.d/openvpn by adding an interface trigger which does restart openvpn with parameter '--local '. Second, I did use the simple way by adding 'option multihome 1' to the openvpn config file. Regards, Hartmut On 2023-12-15 11:08, e9hack wrote: > Hi, > > I've trouble with openvpn over ipv6. It isn't possible to connect to my router from outside via ipv6, because openvpn uses the wrong ipv6 address as source. I get from my provider two prefixes (a 56 and 64 bit). The wan interface gets assigned a random address from the 64 bit prefix. I'm using 3 local interfaces that have been assigned a 64-bit prefix derived from the 56-bit prefix. This are the ipv6 global addresses on my interfaces: > > pppoe-wan Link encap:Point-to-Point Protocol > inet6 addr: 2003::ddff:1242::::/64 Scope:Global > > br-lan Link encap:Ethernet HWaddr 50:xx:xx:xx:xx:xx > inet6 addr: 2003::dd12:27ac::1/64 Scope:Global > > br-guest1 Link encap:Ethernet HWaddr 56:xx:xx:xx:xx:xx > inet6 addr: 2003::dd12:27e1::1/64 Scope:Global > > br-guest2 Link encap:Ethernet HWaddr 5A:xx:xx:xx:xx:xx > inet6 addr: 2003::dd12:27e2::1/64 Scope:Global > > openvpn uses all the time the address from br-guest1 as source address. I did monitor this with tcpdump: > > root@OpenWRT:~# tcpdump -n -i pppoe-wan ip6 and port 1194 > tcpdump: verbose output suppressed, use -v[v]... for full protocol decode > listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes > 09:20:06.656182 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 > 09:20:06.657636 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 > 09:20:21.294559 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 > 09:20:21.296070 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 > 09:20:50.938655 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 > 09:20:50.939972 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 > > What can I change, that openvpn uses the ipv6 address from the wan interface? > > 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openvpn issue
How does pppoe-wan get its IP? You may not be able to do much about that, but you can hint which IPv6 an interface gets using the assignment length, hint and prefix settings. I don't use openvpn, but perhaps it has something like this? I guess it would try to pick a source IP with the 'lowest' IPv6 from an available /64? On 2023-12-15 11:08, e9hack wrote: > Hi, > > I've trouble with openvpn over ipv6. It isn't possible to connect to my router from outside via ipv6, because openvpn uses the wrong ipv6 address as source. I get from my provider two prefixes (a 56 and 64 bit). The wan interface gets assigned a random address from the 64 bit prefix. I'm using 3 local interfaces that have been assigned a 64-bit prefix derived from the 56-bit prefix. This are the ipv6 global addresses on my interfaces: > > pppoe-wan Link encap:Point-to-Point Protocol >inet6 addr: 2003::ddff:1242::::/64 Scope:Global > > br-lanLink encap:Ethernet HWaddr 50:xx:xx:xx:xx:xx >inet6 addr: 2003::dd12:27ac::1/64 Scope:Global > > br-guest1 Link encap:Ethernet HWaddr 56:xx:xx:xx:xx:xx >inet6 addr: 2003::dd12:27e1::1/64 Scope:Global > > br-guest2 Link encap:Ethernet HWaddr 5A:xx:xx:xx:xx:xx >inet6 addr: 2003::dd12:27e2::1/64 Scope:Global > > openvpn uses all the time the address from br-guest1 as source address. I did monitor this with tcpdump: > > root@OpenWRT:~# tcpdump -n -i pppoe-wan ip6 and port 1194 > tcpdump: verbose output suppressed, use -v[v]... for full protocol decode > listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes > 09:20:06.656182 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 > 09:20:06.657636 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 > 09:20:21.294559 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 > 09:20:21.296070 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 > 09:20:50.938655 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 > 09:20:50.939972 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 > > What can I change, that openvpn uses the ipv6 address from the wan interface? > > 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
Re: openvpn issue
How does pppoe-wan get its IP? You may not be able to do much about that, but you can hint which IPv6 an interface gets using the assignment length, hint and prefix settings. I don't use openvpn, but perhaps it has something like this? I guess it would try to pick a source IP with the 'lowest' IPv6 from an available /64? On 2023-12-15 11:08, e9hack wrote: Hi, I've trouble with openvpn over ipv6. It isn't possible to connect to my router from outside via ipv6, because openvpn uses the wrong ipv6 address as source. I get from my provider two prefixes (a 56 and 64 bit). The wan interface gets assigned a random address from the 64 bit prefix. I'm using 3 local interfaces that have been assigned a 64-bit prefix derived from the 56-bit prefix. This are the ipv6 global addresses on my interfaces: pppoe-wan Link encap:Point-to-Point Protocol inet6 addr: 2003::ddff:1242::::/64 Scope:Global br-lan Link encap:Ethernet HWaddr 50:xx:xx:xx:xx:xx inet6 addr: 2003::dd12:27ac::1/64 Scope:Global br-guest1 Link encap:Ethernet HWaddr 56:xx:xx:xx:xx:xx inet6 addr: 2003::dd12:27e1::1/64 Scope:Global br-guest2 Link encap:Ethernet HWaddr 5A:xx:xx:xx:xx:xx inet6 addr: 2003::dd12:27e2::1/64 Scope:Global openvpn uses all the time the address from br-guest1 as source address. I did monitor this with tcpdump: root@OpenWRT:~# tcpdump -n -i pppoe-wan ip6 and port 1194 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 09:20:06.656182 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 09:20:06.657636 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 09:20:21.294559 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 09:20:21.296070 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 09:20:50.938655 IP6 2a01:::56b6::::.62668 > 2003::ddff:1242::::.1194: UDP, length 86 09:20:50.939972 IP6 2003::dd12:27e1::1.1194 > 2a01:::56b6::::.62668: UDP, length 98 What can I change, that openvpn uses the ipv6 address from the wan interface? 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
Re: Migrating ISC to Kea DHCP blocked on related PR's
On 2023-12-09 23:47, Philip Prindeville wrote: Hi all, I'm working on a drop-in for Kea that will parse existing ISC-DHCP configurations in UCI and crank out the derivative JSON config files for Kea, but I have a couple of PR's that are necessary to making this happen that have been pending for several weeks: https://github.com/openwrt/openwrt/pull/13765 https://github.com/openwrt/libubox/pull/6 For those who don't know: Kea DHCP is ISC's replacement for its own ISC DHCP daemon. ISC DHCP reached end of life 2022. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
LogoFAIL
Worth mentioning this new UEFI bootloader vuln which was unembargo'd today. https://binarly.io/posts/The_Far_Reaching_Consequences_of_LogoFAIL/ Might affect a few devices out there, upon which OpenWRT runs. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Best practices for shell libraries (specifically error-checking)
On 2023-11-18 20:42, Philip Prindeville wrote:
Hi all,
I'm trying to figure out what best practices are for shell libraries, as I'm
working on changes to a pretty significant library which I envision being
leveraged in a lot of places.
My questions are these:
* should a good library do error-checking for the caller, or expect the caller
to have done his own validation? Given that most exploits are the result in
insufficient input validation (more than 60% according to a study by the SEI),
it seems that the library should do it. Also, it's one-and-done, rather than
duplicating error-checking in all the places that the library might be used.
And if a missing check is uncovered later? I'd rather have one place to patch
it than many.
Error checking is best done in a single location, where it is relevant
to do so. Always check input.
* in my case, the library has both predicate tests that do validation and their
only output is a true/false return value, as well as functions that perform a
calculation on their inputs and echo an output to stdout. So there's a mix of:
if ! is_validity_check "$myarg"; then
# do some stuff
fi
as well as:
var="$(compute_something "$n" "$m")"
and it's this later that is a little more thorny. The issue is that we're
capturing itss output, but if it's also performing error-checking, then this
will happen in a sub shell and the only way to indicate failure is either to
generate no output, or to check the exit value of the sub shell. So we can do:
var="$(compute_something "$n" "$m")"
if [ -z "$var" ]; then
# handle the error
fi
or else:
var="$(compute_something "$n" "$m")" || { # handle the error ; }
And I'm inclined to go with the later, it's less wordy and the handling can
often be something like a function that takes an argument which it then echos
to stderr, and then exits non-zero. Easy-peasy and simple to read and
understand.
The hard part is when this function that writes its result to standard output
is being used in a different, uncommon way that things get complicate. Like:
( compute_something "$n" "$m" >> something.conf ) || { # handle the error
; }
where they aren't invoking the function via a sub shell unless they do so
explicitly (and they might not have read the functions or accompanying comments
and be aware of how to use them safely).
* so then there's a third option. Always return a true/false status code,
don't emit anything to standard output, and just set some unlikely global
variables like __compute_something_ret_val1, etc. Ugly, but potentially less
disastrous if not invoked properly... but the flip-side is that the user might
not check return values and continue on his bliss, perilous way. It also
avoids fork/exec pairs and everything runs in a single process, so that's nice
(as an aside, an enhancement to shell might have been to have $(...) run in a
separate thread if it only used built-ins, and you could still use a pipe to
capture its output).
Yeah, shell is a 40+ year old language that we're asking to do more than it was
ever intended to do. It would have been nice if in the last 20 years someone
had come up with a way to add new built-in functions via .so plugins that
provided language extensions. But they didn't and that's not on option.
What is the collective wisdom? Coming from a security coding background, I
prefer to make things blow up on invalid input unless the user (caller) takes
steps to recover meaningfully from that failure.
Blow up: This flags that an error potentially exists and should be
fixed. Users describe this as a 'bug', even if it's better to fail
closed than fail open. We typically do this in code with assert. The
thing I dislike about this is that dependent processes may hang or crash
and the user is none the wiser.
I would much prefer, however, that a meaningful, and helpful error
message is emitted so that a user could manually recover from such an
error or present a coherent bug report.
If possible, use (unique) return codes, and not just true/false. That's
what libraries do.
If one cannot use unique return codes, until it's true, it's always
false. Or in other words, lack of yes or no is still a no (fail closed).
Multiple return paths can ensure the caller depends on (okay, coupling,
bad) specific values instead of simply true or false.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
packages repos: libpcre
Hi, maybe some housekeeping process is nececssary, but I got this immediately after I did the usually recommended checkout procedures, and have been even after a git pull, every time I run make. Do these packages need bumping to another libpcre version? === WARNING: Makefile 'package/feeds/packages/fdm/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/freeradius3/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/telephony/freeswitch/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/haproxy/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/haproxy/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/telephony/kamailio/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/telephony/kamailio/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/telephony/kamailio/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/libndpi/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/nmap/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/nmap/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/nmap/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/postfix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/privoxy/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/telephony/rtpengine/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/telephony/rtpengine/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/telephony/sipgrep/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/snort/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/snort3/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/tvheadend/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libpcre', which does not exist ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
reporting kernel bugs
What is the proven way forward here? I've found some delicious kernel panics while running 6.1 on broadcom H/W. But IIRC, kernel isn't interested in bugs unless you've tested on the latest versions which are not readily available to owrt. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH master,23.05] ramips: fix ZyXEL NR7101 bricking typo
While I second the urgency of this, I venture the question of how one
might otherwise catch these things, but for sharp eyes. There is an
attention deficit with respect to the volume of patches and PRs that
come in.
On 2023-10-15 19:41, Bjørn Mork wrote:
A typo snuck in with the addition of Cudy M1800, changing
"nr7101" to "nt7101". The result is a default network config
for NR7101 without the only ethernet interface on the NR7101,
thereby soft bricking it.
Fixes: f6d394e9f2fd ("ramips: add support for Cudy M1800")
Signed-off-by: Bjørn Mork
---
Ref
https://forum.openwrt.org/t/zyxel-nr7101-not-responding-after-flashing-initramfs/174409
and https://github.com/openwrt/openwrt/pull/13699
This needs to be applied to 23.05 and master ASAP. It is already
bricking devices.
And it would be great if we could have some automated check
to help us spot these kinds of unrelated and unexpected
changes. I don't think the regular review process will ever
be able to catch this, as that is mostly focues on the newly
added device.
Bjørn
target/linux/ramips/mt7621/base-files/etc/board.d/02_network | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
index 67fe45f63360..b4c2c6dd68a8 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
@@ -95,7 +95,7 @@ ramips_setup_interfaces()
;;
cudy,m1800|\
yuncore,ax820|\
- zyxel,nt7101)
+ zyxel,nr7101)
ucidef_set_interfaces_lan_wan "lan" "wan"
;;
gnubee,gb-pc1)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Packaging ZFS
Pretty sure not. I'm receptive to ZFS and have used it in a few projects. Openwrt tends to focus on (devices with) smaller flash drives. Other FS better suited to such env. No ZFS is in available software packages today, in any case. On 2023-08-06 00:53, Philip Prindeville wrote: > Has anyone tried to package ZFS (more correctly, OpenZFS) for OpenWRT? Is there any interest in doing so? > > https://github.com/openzfs/zfs > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Towards a unified /etc/config/dhcp
Given that they both cover similar ground, I think this is a good idea. I am a user of both, on various platforms/OSes, although on owrt, I use dnsmasq almost exclusively for its broader functionality which also covers DHCP. On 2023-07-27 00:26, Philip Prindeville wrote: I'm the maintainer of ISC-DHCP which will be sunsetting soon. I'd like to take the UCI wrappers that I wrote to handle quite a few configuration options and port those to Kea since this makes the most sense as a migration path for people wishing to retain their configurations. That said, it strikes me that this is a broader "under-the-covers" implementation issue that we should shield users from. Would it make sense to try to coordinate with the dnsmasq folks on implementing as much common functionality as possible? Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ubox: logread add option to filter priority (log level)
For those executing this at the command line, how does one 'repeat'?
-v 1 -v 2, or -v1 -v2 or -v123 or -v 1,2,3?
I had to think for a bit since it wasn't immediately obvious.
Perhaps a hint string with "(repeatable eg -v 1 -v 2)"?
On 2023-07-22 14:40, Legale Legale wrote:
From 071cfc2853dd7a4f9fb59a1650de8d5c874ce4f2 Mon Sep 17 00:00:00 2001
From:
Date: Sat, 22 Jul 2023 01:28:05 +0300
Subject: [PATCH] logread: add option to filter priority (log level)
This adds an ability to filter log messages priority:
-v handle only messages with given log
level (0-7), repeatable
-V ignore messages with given log level
(0-7), repeatable
Signed-off-by: Isaev Ruslan
---
log/logread.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/log/logread.c b/log/logread.c
index f48dd4b..91aae00 100644
--- a/log/logread.c
+++ b/log/logread.c
@@ -66,6 +66,8 @@ static int log_type = LOG_STDOUT;
static int log_size, log_udp, log_follow, log_trailer_null = 0;
static int log_timestamp;
static int logd_conn_tries = LOGD_CONNECT_RETRY;
+static int loglevel_include;
+static int loglevel_exclude;
static int facility_include;
static int facility_exclude;
@@ -79,6 +81,16 @@ static int check_facility_filter(int f)
return 1;
}
+/* check for loglevel filter; return 0 if message shall be dropped */
+static int check_loglevel_filter(int f)
+{
+ if (loglevel_include)
+ return !!(loglevel_include & (1 << f));
+ if (loglevel_exclude)
+ return !(loglevel_exclude & (1 << f));
+ return 1;
+}
+
static const char* getcodetext(int value, CODE *codetable) {
CODE *i;
@@ -155,6 +167,9 @@ static int log_notify(struct blob_attr *msg)
if (!check_facility_filter(LOG_FAC(p)))
return 0;
+
+ if (!check_loglevel_filter(LOG_PRI(p)))
+return 0;
m = blobmsg_get_string(tb[LOG_MSG]);
if (regexp_pattern &&
@@ -233,6 +248,8 @@ static int usage(const char *prog)
"-p PID file\n"
"-h Add hostname to the message\n"
"-P Prefix custom text to streamed
messages\n"
+ "-v handle only messages with
given log level (0-7), repeatable\n"
+ "-V ignore messages with given log
level (0-7), repeatable\n"
"-z handle only messages with
given facility (0-23), repeatable\n"
"-Z ignore messages with given
facility (0-23), repeatable\n"
"-f Follow log messages\n"
@@ -313,7 +330,7 @@ int main(int argc, char **argv)
signal(SIGPIPE, SIG_IGN);
- while ((ch = getopt(argc, argv, "u0fcs:l:z:Z:r:F:p:S:P:h:e:t")) != -1) {
+ while ((ch = getopt(argc, argv,
"u0fcs:l:v:V:z:Z:r:F:p:S:P:h:e:t")) != -1) {
switch (ch) {
case 'u':
log_udp = 1;
@@ -343,6 +360,14 @@ int main(int argc, char **argv)
case 'l':
lines = atoi(optarg);
break;
+ case 'v':
+ id = strtoul(optarg, NULL, 0) & 0x1f;
+ loglevel_include |= (1 << id);
+ break;
+ case 'V':
+ id = strtoul(optarg, NULL, 0) & 0x1f;
+ loglevel_exclude |= (1 << id);
+ break;
case 'z':
id = strtoul(optarg, NULL, 0) & 0x1f;
facility_include |= (1 << id);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] vlynq: fix typos in Kconfig
On 2023-07-22 07:43, Randy Dunlap wrote:
Fix grammar and punctuation in the vlynq Kconfig file.
Fixes: 55e331cf7ebe ("drivers: add support for the TI VLYNQ bus")
Signed-off-by: Randy Dunlap
Cc: Florian Fainelli
Cc: openwrt-devel@lists.openwrt.org
Cc: Andrew Morton
---
drivers/vlynq/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -- a/drivers/vlynq/Kconfig b/drivers/vlynq/Kconfig
--- a/drivers/vlynq/Kconfig
+++ b/drivers/vlynq/Kconfig
@@ -7,10 +7,10 @@ config VLYNQ
help
Support for Texas Instruments(R) VLYNQ bus.
The VLYNQ bus is a high-speed, serial and packetized
- data bus which allows external peripherals of a SoC
+ data bus which allows external peripherals of an SoC
Nitpick:
Usually debatable. But SoC starts with S
In native English, "an" never precedes a consonant, which appears in
both SoC and System (on a Chip).
to appear into the system's main memory.
- If unsure, say N
+ If unsure, say N.
config VLYNQ_DEBUG
bool "VLYNQ bus debug"
___
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] ath79: increase the rfkill debounce interval for TP-Link Archer C7 v2
Please review/merge
On 2023-07-14 21:51, Rosen Penev wrote:
On Fri, Jul 14, 2023 at 8:12 AM Shiji Yang wrote:
From: Shiji Yang
Due to circuit issue or silicon defect, sometimes the WiFi switch button
of the Archer C7 v2 can be accidentally triggered multiple times in one
second. This will cause WiFi to be unexpectedly shut down and trigger
'irq 23: nobody cared'[1] warning. Increasing the key debounce interval
to 1000 ms can fix this issue. This patch also add the missing rfkill
key label.
Crazy. I was wondering why 2.4ghz went away. For 5ghz I understand,
ath10k is gartbo, but 2.4ghz I didn't.
[1] Warning Log:
```
[87765.218511] irq 23: nobody cared (try booting with the "irqpoll" option)
[87765.225331] CPU: 0 PID: 317 Comm: irq/23-keys Not tainted 5.15.118 #0
...
[87765.486246] handlers:
[87765.488543] [<85257547>] 0x800c29a0 threaded [<5c6328a2>] 0x80ffe0b8
[gpio_button_hotplug@4cf73d00+0x1a00]
[87765.498364] Disabling IRQ #23
```
Fixes: https://github.com/openwrt/openwrt/issues/13010
Fixes: https://github.com/openwrt/openwrt/issues/12167
Fixes: https://github.com/openwrt/openwrt/issues/11191
Fixes: https://github.com/openwrt/openwrt/issues/7835
Tested-by: Hans Hasert
Signed-off-by: Shiji Yang
---
target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
index b7ac902003..1b860dbf2d 100644
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
@@ -13,10 +13,11 @@
{
rfkill {
+ label = "rfkill";
gpios = < 23 GPIO_ACTIVE_LOW>;
linux,code = ;
linux,input-type = ;
- debounce-interval = <60>;
+ debounce-interval = <1000>;
};
};
--
2.30.2
___
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: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
On 2023-04-25 16:12, Jan Hoffmann wrote: On 2023-01-30 at 23:40, Jan Hoffmann wrote: Some VRX518 modems fail to initialize properly with the error message "dc_ep_clk_on failed". As a result, the DSL data path doesn't work. This hack, which is based on code from the FRITZ!Box 7530 GPL archive, fixes the issue. It changes the PCIe vendor/device ID to values matching a Lantiq SoC. It also appears to emulate a Lantiq CPU ID register for connected PCIe devices, by remapping the matching address area to a specially crafted buffer using the address translation unit. The hack is only active if the "avm,host_magic" property is specified in the device tree, so this shouldn't affect any devices other than FRITZ!Box 7530/7520. Signed-off-by: Jan Hoffmann Is there any chance for this patch to get accepted? I'm aware that this hack is not a particularly nice solution. And the additional maintenance burden of adding another kernel patch is also an obvious downside. However, we don't know any better fix, and the modem just won't work without it on some devices. As there is no way to distinguish the affected devices externally, users will only find out if the modem on their device actually works after they installed OpenWrt on it. Recently, another user with this issue turned up on the forum [0]. Thanks, Jan [0] https://forum.openwrt.org/t/fritzbox-7520-wan-dsl0-7-device-is-missing/156424 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Sometimes fixing silicon bugs is analogous to hacks. Seems like making the datapath work is... desirable. /P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
On 2023-02-08 11:44, Robert Marko wrote: On Sun, 5 Feb 2023 at 01:10, Jan Hoffmann wrote: Am 02.02.23 um 11:54 schrieb Robert Marko: On Tue, 31 Jan 2023 at 23:52, Jan Hoffmann wrote: Hi Robert, On 2023-01-30 at 00:08, Robert Marko wrote: Shouldn't it be possible for the modem driver itself to be fixed instead of faking the PCI details? This hack is definitely far from ideal, but I'm not sure if there is a better way to fix this. Here are a few more details about the issue: On the affected devices (so far, three users reported it on the VRX518 thread in the forum [0]), the function call to turn on the "EMA" hardware unit in the vrx518_tc driver [1] fails with the error mentioned in the commit message. I don't have any details about it, but this EMA unit is part of the data path (it is also referenced in the ltq-atm and ltq-ptm data path drivers for older Lantiq modems). If the EMA unit is not running, then at least the transmit data path doesn't work, and any packets the driver writes to the TX ring are not actually sent out by the device. This is also reproducible on non-affected devices by calling tc_clkoff instead of tc_clkon in the vrx518_tc driver (i.e. disabling the hardware unit). The same issue also occurs on affected devices running vendor firmware, if the "magic" in the PCIe driver is disabled in the device tree. So this is not just a bug in the data path driver. I get the issue, however, I am failing to see how faking the PCI ID for the root adaptor is magically solving that? If that works, why can't you just patch the driver to stop looking for the ancient Lantiq ID? As far as I can see, the magic values don't appear anywhere in the DSL drivers. So it doesn't seem like there is an easy fix like that. To me this looks like whatever access to these values is being done, seems to happen in hardware (or firmware). Maybe there are some revisions or variants of the modem that don't like to cooperate with non-Lantiq SoCs. But in the end, I don't know with certainty what exactly is happening here, as about the only public information on these modems are the open-source drivers (including the magic hack in the PCIe driver which in its original form contains comments like "do some magic" without really explaining what it actually does). Ok, I am now getting the issue, it's probably in the damn firmware. I still really dont like the hack that we are gonna need to carry forever. I would like for somebody else to chime in as well. If the OEM does it, unless we can find another way, we should carry the hack, if that's what it takes to better support a chipset. DSL will still be with us for a while to come. There was a huge amount of work and guesswork to even get these chipsets usable. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] fw4: add a range of icmpv6 types
Signed-off-by: Paul Dee
---
root/usr/share/ucode/fw4.uc | 64 -
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/root/usr/share/ucode/fw4.uc b/root/usr/share/ucode/fw4.uc
index 5dce90d..96f2780 100644
--- a/root/usr/share/ucode/fw4.uc
+++ b/root/usr/share/ucode/fw4.uc
@@ -67,6 +67,7 @@ const ipv4_icmptypes = {
};
const ipv6_icmptypes = {
+ /* "name": [ type-code, code-min, code-max ] */
"destination-unreachable": [ 1, 0, 0xFF ],
"no-route": [ 1, 0, 0 ],
"communication-prohibited": [ 1, 1, 1 ],
@@ -91,6 +92,11 @@ const ipv6_icmptypes = {
"echo-reply": [ 129, 0, 0xFF ],
"pong": [ 129, 0, 0xFF ], /* Alias */
+ /* only code zero (0) */
+ "multicast-listener-query": [ 130, 0, 0xFF ],
+ "multicast-listener-report": [ 131, 0, 0xFF ],
+ "multicast-listener-done": [ 132, 0, 0xFF ],
+
"router-solicitation": [ 133, 0, 0xFF ],
"router-advertisement": [ 134, 0, 0xFF ],
@@ -101,7 +107,63 @@ const ipv6_icmptypes = {
"neighbour-advertisement": [ 136, 0, 0xFF ],
"neighbor-advertisement": [ 136, 0, 0xFF ], /* Alias */
- "redirect": [ 137, 0, 0xFF ]
+ "redirect": [ 137, 0, 0xFF ],
+
+ /* codes 0, 1, 255 */
+ "router-renumbering": [ 138, 0, 0xFF ],
+
+ /* codes 0, 1, 2 */
+ "node-info-query": [ 139, 0, 0xFF ],
+ /* codes 0, 1, 2 */
+ "node-info-response": [ 140, 0, 0xFF ],
+
+ "inverse-neighbour-discovery-solicitation-message": [ 141, 0, 0xFF ],
+ "inverse-neighbor-discovery-solicitation-message": [ 141, 0, 0xFF ],
/* Alias */
+
+ "inverse-neighbour-discovery-advertisement-message": [ 142, 0, 0xFF ],
+ "inverse-neighbor-discovery-advertisement-message": [ 142, 0, 0xFF ],
/* Alias */
+
+ "v2-multicast-listener-report": [ 143, 0, 0xFF ],
+
+ "home-agent-address-discovery-request-message": [ 144, 0, 0xFF ],
+ "home-agent-address-discovery-reply-message": [ 145, 0, 0xFF ],
+
+ "mobile-prefix-solicitation": [ 146, 0, 0xFF ],
+ "mobile-prefix-advertisement": [ 147, 0, 0xFF ],
+
+ /* SEND */
+ "certification-path-solicitation-message": [ 148, 0, 0xFF ],
+ "certification-path-advertisement-message": [ 149, 0, 0xFF ],
+
+ "seamoby-protocol-message": [ 150, 0, 0xFF ],
+
+ /* IPv6 multicast: FF02:0:0:0:0:0:0:6A, no code fields */
+ "multicast-router-advertisement": [ 151, 0, 0xFF ],
+ "multicast-router-solicitation": [ 152, 0, 0xFF ],
+ "multicast-router-termination": [ 153, 0, 0xFF ],
+
+ /* codes 0-5, 6-255 */
+ "fmipv6-message": [ 154, 0, 0xFF ],
+
+ "rpl-control-message": [ 155, 0, 0xFF ],
+
+ "ilnpv6-locator-update-message": [ 156, 0, 0xFF ],
+
+ /* codes 0-4, 5-15 */
+ "duplicate-address-request": [ 157, 0, 0xFF ],
+ /* codes 0-4, 5-15 */
+ "duplicate-address-confirmation" [ 158, 0, 0xFF ],
+
+ /* Multicast Protocol for Low-Power */
+ "mpl-control-message": [ 159, 0, 0xFF ],
+
+ /* codes 0, 1-255 */
+ "extended-echo-request" [ 160, 0, 0xFF ],
+ "extended-ping" [ 160, 0, 0xFF ], /* Alias */
+
+ /* codes 0-4, 5-255 */
+ "extended-echo-reply" [ 161, 0, 0xFF ],
+ "extended-pong" [ 161, 0, 0xFF ] /* Alias */
};
const dscp_classes = {
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] fw4: fix ipset comment field from bool to string
Any takers?
ping jo wich?
On 2023-01-07 17:00, Paul D wrote:
comment is documented as a string in the man page.
Ref: https://github.com/openwrt/luci/pull/6187#issuecomment-1374506633
Signed-off-by: Paul Dee
---
root/usr/share/ucode/fw4.uc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/root/usr/share/ucode/fw4.uc b/root/usr/share/ucode/fw4.uc
index 5dce90d..0393508 100644
--- a/root/usr/share/ucode/fw4.uc
+++ b/root/usr/share/ucode/fw4.uc
@@ -3191,7 +3191,7 @@ return {
enabled: [ "bool", "1" ],
reload_set: [ "bool" ],
counters: [ "bool" ],
- comment: [ "bool" ],
+ comment: [ "string" ],
name: [ "string", null, REQUIRED ],
family: [ "family", "4" ],
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] fw4: fix ipset comment field from bool to string
comment is documented as a string in the man page.
Ref: https://github.com/openwrt/luci/pull/6187#issuecomment-1374506633
Signed-off-by: Paul Dee
---
root/usr/share/ucode/fw4.uc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/root/usr/share/ucode/fw4.uc b/root/usr/share/ucode/fw4.uc
index 5dce90d..0393508 100644
--- a/root/usr/share/ucode/fw4.uc
+++ b/root/usr/share/ucode/fw4.uc
@@ -3191,7 +3191,7 @@ return {
enabled: [ "bool", "1" ],
reload_set: [ "bool" ],
counters: [ "bool" ],
- comment: [ "bool" ],
+ comment: [ "string" ],
name: [ "string", null, REQUIRED ],
family: [ "family", "4" ],
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Automatic LAN Subnet Reassignment
On 2022-02-21 22:38, Rich Brown wrote: There is a new RFC on the OpenWrt forum proposing "Automatic LAN Subnet Reassignment" https://forum.openwrt.org/t/rfc-automatic-lan-subnet-reassignment-upon-conflict-with-wan/120938 The RFC responds to the advice given at last week's OpenWrt-Adm meeting (https://etherpad.wikimedia.org/p/ZlZiTcud3wufcSX9-1jD) The intent of the proposal is for the default configuration to assign a LAN subnet that avoids a conflict with the WAN subnet, and provide a mDNS name such at OpenWrt.lan for connections. I have two requests: 1) Please make comments on the technical merits of the proposal on the OpenWrt forum at the link above. 2) If the proposal seems to make sense, please consider the process by which we would incorporate this into the main release (likely, not for 22.0x, but perhaps the next release?) I think this regards only IPv4. I propose that the RFC1918 nets on either side be in the same block, to avoid NAT, and try to retain routing: performance. A NAT choice might present security advantages, however. Ideally one would consider configured (static) routes such that any chosen (sub)net does not collide with one further up/downstream. No preference either way for .home.arpa. or .lan: both are sane, but one more to type than the other, although both available is good. 4.3 and 4.4 have importance, however: https://www.rfc-editor.org/rfc/rfc8375#section-4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reduced throughput with mt7621 and DSA
Sounds like the intended efforts for DSA bringup for 21.x and beyond have been fruitful. :) On 2021-12-22 08:45, Kristian Evensen wrote: Hi, On Tue, Dec 21, 2021 at 6:34 PM Kristian Evensen wrote: Since the only change between my sets of tests is the software, something has clearly improved in either the kernel or OpenWrt (as would be expected :)). Are there any particular commits/patches that would be worthwhile trying to backport to 21.02/5.4, or is the difference to master/5.10 so big that there is no point and the best is to wait for the next release? I guess one thing that hopefully shouldn't be too hard is be to combine 21.02 userspace with the 5.10 kernel. That will be on the top of my todo-list for tomorrow. Backporting 5.10 to 21.02 was straight forward and restored performance to 19.07-levels. Since I anyway compile and run my own images, backporting 5.10 works for me and performance issue is resolved :) Thanks for all the hard work. Kristian ___ 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: Reduced throughput with mt7621 and DSA
I generalize, but this is a problem which affects a few devices in the DSA bring-up. Some platforms require some tinkering and tweaking, and perhaps input from the chip-set manufacturer (or information from a datasheet of the chip-set) if things are to improve. DSA brings advantages and is the future: everyone is already committed. OEMs have been laying low tho and just used older 2.x kernels which the mfrs provided with the chip-sets originally to avoid this maintenance themselves if at all possible. You can have a look at PRs for other platforms and their protracted DSA bring-ups on github. e.g. for the qca8k switch chip, some of the lads have been moving mountains: https://github.com/openwrt/openwrt/pull/4036 https://github.com/openwrt/openwrt/pull/4622 https://github.com/openwrt/openwrt/pull/4828 This will give you an idea of the amount of work which may be necessary to return performance to 19.x swconfig levels. I don't dabble in mt7621, so cannot be of help there as to whether there is something ongoing for those. On 2021-12-19 12:29, Kristian Evensen wrote: Hello, I am currently performing some performance measurements, comparing the (wired) routing throughput (WAN <-> LAN) of 19.07, 21.02 and master on mt7621 (ZBT WG-3526). I have connected one client to my LAN and one to the WAN, and use iperf3 to measure. I create parallel flows (in order to take advantage of the multiple CPU cores), use TCP and let iperf3 run for 30 sec. per test. Based on my measurements, the throughput is reduced by ~50% going from 19.07 and to 21.02/master (~450Mbit/s vs. ~900Mbit/s). I do not have a particular commit I can point to, but I believe the regressions is caused by the introduction of DSA. Restoring the old swconfig driver, brings my 21.02/master throughput up to roughly the same level as 19.07. I am able to alleviate the reduction in throughput by enabling flow offloading, but there are several cases where flow offloading does not have an effect. When performing a similar measurement to the one above over a Wireguard-tunnel, I see a similar reduction in performance (and no help from flow offloading). Does anyone know what could be the reason and if there is anything that can be done to improve the performance when using DSA? Are there for example any out of tree/not yet accepted patches that I should try? Thanks in advance for any help, Kristian ___ 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: 802.11v: hostapd: time_zone
Never mind - they appear to be more sporadic, and perhaps also require a network restart. Time_Zone appears in Probe Response frames only. On 2021-12-07 04:06, Paul D wrote: I tried enabling the wifi settings for 2.4 and 5Ghz.: == time_advertisement == Result: OK. Time appears in beacon frames. e.g. Tag: Time Advertisement Tag Number: Time Advertisement (69) Tag length: 17 Timing capabilities: UTC time at which the TSF timer is 0 (2) Time Value: e5070c07022b2400: current time=2021-12-07 02:44:10 Time Error: 00 Time Update Counter: 0 == time_zone == (set as CET-1CEST,M3.5.0,M10.5.0/3) Result: NOK. Time Zone never appears in beacon frames. Has there been a regression in hostapd, or... was time_zone functionality ever implemented there? Can anyone else confirm? Documentation says it should be there and working. 21.02.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 802.11v: hostapd: bss_load_update_period
Sorry - seems like it's already there :) On 2021-12-07 16:29, Paul D wrote: Could this also be picked to 21.02 branch, please? https://github.com/openwrt/openwrt/commit/85ce590705072be78c3ef7dc6b64e3b1facc892b ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
802.11v: hostapd: bss_load_update_period
Could this also be picked to 21.02 branch, please? https://github.com/openwrt/openwrt/commit/85ce590705072be78c3ef7dc6b64e3b1facc892b ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
802.11v: hostapd: time_zone
I tried enabling the wifi settings for 2.4 and 5Ghz.: == time_advertisement == Result: OK. Time appears in beacon frames. e.g. Tag: Time Advertisement Tag Number: Time Advertisement (69) Tag length: 17 Timing capabilities: UTC time at which the TSF timer is 0 (2) Time Value: e5070c07022b2400: current time=2021-12-07 02:44:10 Time Error: 00 Time Update Counter: 0 == time_zone == (set as CET-1CEST,M3.5.0,M10.5.0/3) Result: NOK. Time Zone never appears in beacon frames. Has there been a regression in hostapd, or... was time_zone functionality ever implemented there? Can anyone else confirm? Documentation says it should be there and working. 21.02.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
hostapd: proxy ARP (802.11v)
Could this be picked to 21.02 branch, please? https://github.com/openwrt/openwrt/commit/e309b57619b9c073b9b8857858d9456183f27d7d ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: coreutils
On 2021-12-06 14:33, Paul Spooren wrote: On 6. Dec 2021, at 13:37, Paul D wrote: Could coreutils in rust be interesting for this project? (memory safety, at least at a later date) I think long term rust routers would be of interest, did you already do some rather research? From a first looks it seem to miss a shell which is included in busybox (ash). Did you check the binary size? They use MIT license, however. It's still young and many components are not yet done. Just the idea seems interesting, however. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: coreutils
They use MIT license, however. https://github.com/uutils/coreutils ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
coreutils
Could coreutils in rust be interesting for this project? (memory safety, at least at a later date) They use MIT license, however. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mac address issue of tp-link wdr3600 and archer c7-v2
C7v2 here. 21.02
eth0: 73
eth1: 72 (br-lan)
wlan0: 71 (11n+ac, 5GHz)
wlan1: 72 (11bgn, 2.4GHz)
Works fine as is.
On 2021-11-15 21:04, e9hack wrote:
Hi,
I'm using two tp-link routers. Both are using the same mac address for
one eth and one wlan interface:
archer c7-v2:
uboot 60:xx:xx:xx:xx:E6
eth0 60:xx:xx:xx:xx:E7
eth1 60:xx:xx:xx:xx:E6
wlan0 60:xx:xx:xx:xx:E4 5G
wlan1 60:xx:xx:xx:xx:E6 2.4G
wdr3600:
uboot C0:xx:xx:xx:xx:60
eth0 C0:xx:xx:xx:xx:60
wlan0 C0:xx:xx:xx:xx:5F 2.4G
wlan1 C0:xx:xx:xx:xx:60 5G
It looks like if an address decrement is missing for one wlan interface.
I don't know if this can trigger a problem.
With a small patch, I did fix it for both of my routers:
--- a/target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi
+++ b/target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi
@@ -82,6 +82,7 @@
{
nvmem-cells = <_uboot_1fc00>;
nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-2)>;
};
{
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
@@ -64,6 +64,7 @@
nvmem-cells = <_uboot_1fc00>;
nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-1)>;
};
{
Now I get:
archer c7-v2:
eth0 60:xx:xx:xx:xx:E7
eth1 60:xx:xx:xx:xx:E6
wlan0 60:xx:xx:xx:xx:E4 5G
wlan1 60:xx:xx:xx:xx:E5 2.4G
wdr3600:
eth0 C0:xx:xx:xx:xx:60
wlan0 C0:xx:xx:xx:xx:5F 2.4G
wlan1 C0:xx:xx:xx:xx:5E 5G
I don't know, if exist some rule whether decrement by -1/-2 shall refer
to the interface number or to the frequency.
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
