Re: OpenWrt 21.02.0 second release candidate
On 31.05.2021 23:58, Hauke Mehrtens wrote: New network configuration syntax There have been several changes to the network configuration syntax in /etc/config/network: To provide some context: that change resulted in cleaner configs and manageable UI interface (LuCI) support. Big thanks to Jo for supporting & working on that. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: simplify setting device MAC
On 28.05.2021 20:18, Evgeny K wrote:
3. Drop section name
It's not required by netifd or LuCI & it's not needed by this script
as $device contains a single device name now.
It could be convenient to have it, though. In the former scheme of
things, if one would like to know the interface behind, say, lan it
was possible to do with just 'uci -q get network.lan.ifname`. Now it
has become pretty complicated. Adding a name to the device section
would allow one to at least do it in 2 steps: `uci -q get
network.lan.device` and `uci -q get network.$device.ports`.
There was never a direct mapping between "config device" UCI section
name and its "option name" value. See this example from bcm53xx:
config device 'wan_eth0_1_dev'
option name 'eth0.1'
option macaddr '00:11:22:33:44:55'
It was actually impossible due to limitations of UCI section names (they
can't contain any characters as options can).
So yes, you need to search all "config device" looking for the one with
the proper name.
I suggest you using netifd's ubus objects.
ubus call network.device status '{ "name": "br-lan" }'
Ideally you should be able to use jsonfilter too but I don't know how to
deal with "-" in a property name. Following doesn't work for me:
ubus call network.device status '{ "name": "br-lan" }' | jsonfilter -e
"$.bridge-members"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Mac80211 ath patch split proposal
Hi, since we are starting to add support for ath11k i was thinking... To have things organized and remove some confusion, I was thinking if it wouldn't be better to split the ath patch dir to 3 (or 4) sub directory and introduce patch for ath9k, patch for ath10k and patch for ath11k with a 4th optional dir that apply to ath general directory? What do you think about this change? The mac80211 makefile already have a way to handle patch split in multiple dir so adding extra dir is not really harmful. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.0 second release candidate
Hi, The OpenWrt community is proud to announce the second release candidate of the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year. Changes between OpenWrt 21.02.0-rc1 and 21.02.0-rc2 New network configuration syntax There have been several changes to the network configuration syntax in /etc/config/network: * in config interface, option ifname has been renamed to device (since it refers to a device section) * in config device of type bridge, ifname has been renamed to ports * for new installs, the generated configuration now creates separate sections for layer 2 (config device) and layer 3 (config interface) configuration The old syntax is still supported to facilitate transition, and there is no automated migration when upgrading. However, the LuCI web interface detects old-style configuration and will propose to migrate it to the new syntax. This is necessary to be able to edit network configuration through LuCI. The new configuration style looks like this: -- config device option name 'br-lan' option type 'bridge' option macaddr '00:01:02:XX:XX:XX' list ports 'lan1' list ports 'lan2' list ports 'lan3' list ports 'lan4' config interface 'lan' option device 'br-lan' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' config device option name 'eth1' option macaddr '00:01:02:YY:YY:YY' config interface 'wan' option device 'eth1' option proto 'dhcp' config interface 'wan6' option device 'eth1' option proto 'dhcpv6' -- This example uses DSA with lanX interface names. A non-DSA device would use more classical ethX interface names. LuCI update LuCI has been updated to support the most recent network syntax (and migrate old config files if needed). In some cases migration will take 2 steps. Support for configuring devices (config device UCI sections) was added. It can be used for setting layer 2 options (like MTU and MAC address). It also supports bridge devices (including VLAN tagging). LuCI HTTPS LuCI is now available over HTTPS in addition to HTTP in the default images. After an upgrade from OpenWrt 19.07 to OpenWrt 21.02 unencrypted HTTP requests are redirected to HTTPS. On fresh OpenWrt 21.02 installations they are not redirected. Deactivate the redirect to HTTPS like this: -- uci set uhttpd.main.redirect_https=0 uci commit uhttpd service uhttpd reload -- Software updates * Linux kernel updated to version 5.4.119 (from 5.4.111 in v21.02.0-rc1) * mac80211 updated to version 5.10.34-1 (from 5.10.16-1 in v21.02.0-rc1) * mac80211 backport upstream fixes for the new FragAttacks vulnerabilities in 802.11 * mt76 updated to latest version * dnsmasq updated to version 2.85 (from 2.84 in v21.02.0-rc1) * busybox updated to version 1.33.1 (from 1.33.0 in v21.02.0-rc1) Misc changes * Linux kernel fix parsing fixed subpartitions * Linux kernel Activate FORTIFY_SOURCE for MIPS kernel 5.4 * busybox add SRV support to nslookup_lede.c patch * busybox disable PREFER_IPV4_ADDRESS * openwrt-keyring only copy sign key for 21.02 * sdk, imagebuilder unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives * uqmi fix network registration loop Device support * Lantiq DSL multiple backports for DSL statistics * New devices MikroTik SXTsq 5 ac, MikroTik hAP ac2 * Device fixes for ALFA Network devices, Youku YK1, TP-Link AD7200, TP-Link EAP-225, TP-Link TL-WR810N v1, MikroTik RB922UAGS-5HPaCD Known issues * LuCI network migration tool doesn't migrate custom bridge MAC addresses. Custom device MAC has to be set again manually. Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.0-rc2 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.0-rc2#known_issues For a detailed list of all changes since 21.02.0-rc1, refer to https://openwrt.org/releases/21.02/changelog-21.02.0-rc2 To download the 21.02.0-rc2 images, navigate to: https://downloads.openwrt.org/releases/21.02.0-rc2/ - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement
[PATCH v2] ath79: rb4xx-nand: fix 512 byte pages compatibility
MikroTik boards with 512 byte NAND pages require the old YAFFS1 OOB
layout for compatibility with the RouterBoot bootloader. The RB4xx NAND
driver supports such OOB layout, but checks a NAND page size too early
before the flash identification, what effectively preventing the old OOB
layout from being used.
To fix this issue, move the page size check and OOB layout configuration
to the chip attaching hook, which is specially intorduced for ECC and
OOB tweaking.
While at it, copy a comment from the old AR71xx driver to make it clear,
why do we need this OOB layout tweaking.
Run tested with MikroTik RB411U board.
Signed-off-by: Sergey Ryazanov
---
Changes since v1:
* rebased on top of latest master
* rephrased the comment in the hook function, thanks to Bas for
noticing this
.../files/drivers/mtd/nand/raw/nand_rb4xx.c | 25 ---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
index 22e2660b38..6778e70d34 100644
--- a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
@@ -81,6 +81,23 @@ static const struct mtd_ooblayout_ops
rb4xx_nand_ecclayout_ops = {
.free = rb4xx_ooblayout_free,
};
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+* At this point, we know the flash params and can tweak the OOB layout
+* for 512-byte page (usually this is a 64MiB flash).
+*
+* We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+* bootloader will not be able to find the kernel that we load.
+*/
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip *chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops = {
+ .attach_chip = rb4xx_nand_attach_chip,
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
-
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,9,0)
nand->chip.ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
nand->chip.ecc.algo = NAND_ECC_ALGO_HAMMING;
@@ -204,6 +222,7 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops = _nand_controller_ops;
ret = nand_scan(>chip, 1);
if (ret)
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH] kernel: fix flow offload with IPv6 policy-based routing
Sync iptables FLOWOFFLOAD target with upstream nft_flow_offload.c, which
fixes the issue.
Fixes: FS#3649
Signed-off-by: DENG Qingfang
---
Note: I am by no means an expert on Netfilter subsystem. I just kind of
copied and pasted upstream nft_flow_offload.c here, which seemed to work.
A fix for kernel 5.10 is also required.
.../650-netfilter-add-xt_OFFLOAD-target.patch | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
a/target/linux/generic/hack-5.4/650-netfilter-add-xt_OFFLOAD-target.patch
b/target/linux/generic/hack-5.4/650-netfilter-add-xt_OFFLOAD-target.patch
index d584cb5c6c..567ebe4528 100644
--- a/target/linux/generic/hack-5.4/650-netfilter-add-xt_OFFLOAD-target.patch
+++ b/target/linux/generic/hack-5.4/650-netfilter-add-xt_OFFLOAD-target.patch
@@ -98,7 +98,7 @@ Signed-off-by: Felix Fietkau
obj-$(CONFIG_NETFILTER_XT_TARGET_LED) += xt_LED.o
--- /dev/null
+++ b/net/netfilter/xt_FLOWOFFLOAD.c
-@@ -0,0 +1,427 @@
+@@ -0,0 +1,422 @@
+/*
+ * Copyright (C) 2018 Felix Fietkau
+ *
@@ -315,7 +315,6 @@ Signed-off-by: Felix Fietkau
+ fl.u.ip4.flowi4_oif = ifindex;
+ break;
+ case NFPROTO_IPV6:
-+ fl.u.ip6.saddr = ct->tuplehash[dir].tuple.dst.u3.in6;
+ fl.u.ip6.daddr = ct->tuplehash[dir].tuple.src.u3.in6;
+ fl.u.ip6.flowi6_oif = ifindex;
+ break;
@@ -333,13 +332,13 @@ Signed-off-by: Felix Fietkau
+{
+ struct dst_entry *this_dst, *other_dst;
+
-+ this_dst = xt_flowoffload_dst(ct, !dir, par, xt_out(par)->ifindex);
++ this_dst = skb_dst(skb);
+ other_dst = xt_flowoffload_dst(ct, dir, par, xt_in(par)->ifindex);
+
+ route->tuple[dir].dst = this_dst;
+ route->tuple[!dir].dst = other_dst;
+
-+ if (!this_dst || !other_dst)
++ if (!other_dst)
+ return -ENOENT;
+
+ if (dst_xfrm(this_dst) || dst_xfrm(other_dst))
@@ -390,9 +389,6 @@ Signed-off-by: Felix Fietkau
+ if (!nf_ct_is_confirmed(ct))
+ return XT_CONTINUE;
+
-+ if (!xt_in(par) || !xt_out(par))
-+ return XT_CONTINUE;
-+
+ if (test_and_set_bit(IPS_OFFLOAD_BIT, >status))
+ return XT_CONTINUE;
+
@@ -401,7 +397,6 @@ Signed-off-by: Felix Fietkau
+ if (xt_flowoffload_route(skb, ct, par, , dir) == 0)
+ flow = flow_offload_alloc(ct, );
+
-+ dst_release(route.tuple[dir].dst);
+ dst_release(route.tuple[!dir].dst);
+
+ if (!flow)
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Interface names when putting 802.1q VLAN on top of bonding configuration
One more question, now I'm trying to put a bridge on top of each of these vlan* interfaces so that I can map those to a few physical interfaces. I also need several vlans to map to one of the interfaces (tagged).. not sure how to do that yet either. Any suggestions with this config? When I apply it, I lose network access. It looks wrong that after applying the below config, that br-bv10 is now a master for vlan10@bonding-lanxge 69: vlan10@bonding-lanxge: mtu 1500 qdisc noqueue master br-bv10 state UP group default qlen 1000 Also, is there any way to not need 'option ipaddr 127.0.0.2' in the lanxge interface? config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdb9:bf48:0362::/48' config interface lanxge option proto 'bonding' option auto '1' option bonding_policy '802.3ad' option link_monitoring 'mii' option slaves 'eth4 eth5' option lacp_rate 'fast' option miimon '100' option use_carrier 1 option xmit_hash_policy 'layer3+4' option force_link '1' option ipaddr 127.0.0.2 config device option type 8021q option ifname bonding-lanxge option vid 10 option name vlan10 config interface vlan10 option ifname vlan10 option proto static option ipaddr 172.20.32.250 option netmask 255.255.255.0 config device option type 8021q option ifname bonding-lanxge option vid 20 option name vlan20 config interface vlan20 option ifname vlan20 option proto static option ipaddr 172.20.34.2 option netmask 255.255.255.128 config device option type 8021q option ifname bonding-lanxge option vid 21 option name vlan21 config interface vlan21 option ifname vlan21 option proto static option ipaddr 172.20.35.3 option netmask 255.255.255.240 config device option type 8021q option ifname bonding-lanxge option vid 30 option name vlan30 config interface vlan30 option ifname vlan30 option proto static option ipaddr 172.20.34.130 option netmask 255.255.255.128 config interface 'wan' option ifname 'eth0.0' option proto 'dhcp' config interface bv10 option type 'bridge' option ifname vlan10 option auto '1' option force_link '1' config interface bv20 option type 'bridge' option ifname vlan20 option auto '1' option force_link '1' config interface bv21 option type 'bridge' option ifname vlan21 option auto '1' option force_link '1' config interface bv30 option type 'bridge' option ifname vlan30 option auto '1' option force_link '1' > On 2021/05/28, at 10:52:25 CDT (-05:00), Mike Bernardo wrote: > > Ah thanks! This worked great. I swear I tried something nearly identical > before that broke everything. > > Mike > >> On 2021/05/28, at 02:34:44 CDT (-05:00), Jo-Philipp Wich >> wrote: >> >> Hi, >> >> the following should do what you want. >> >> config device >> option type 8021q >> option ifname bonding-lan >> option vid 20 >> option name vlan20 >> >> config interface vlan20 >> option ifname vlan20 >> option proto static >> option ipaddr 172.20.34.2 >> option netmask 255.255.255.128 >> >> >> ~ Jo >> >> ___ >> 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: Luci->Network->Interfaces is broken
Hi, > This is the reason. Long time ago, I did select the option 'Remove ipkg/opkg > status data files in final images' to reduce the image size. Since such an > option can be selected, LuCI cannot assume, that the file netifd.control > exists. fixed. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Luci->Network->Interfaces is broken
Am 31.05.2021 um 16:36 schrieb e9hack: LuCI commit 17af33e luci-mod-network: migrate network config depending on netifd version does introduce to read the file /usr/lib/opkg/info/netifd.control. I don't have this file on my router. Can that be the reason for the error 'Resource not found'? This is the reason. Long time ago, I did select the option 'Remove ipkg/opkg status data files in final images' to reduce the image size. Since such an option can be selected, LuCI cannot assume, that the file netifd.control exists. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Luci->Network->Interfaces is broken
Am 31.05.2021 um 15:52 schrieb e9hack:
Am 31.05.2021 um 07:18 schrieb Rafał Miłecki:
On 30.05.2021 18:02, e9hack wrote:
Am 30.05.2021 um 15:41 schrieb e9hack:
Am 30.05.2021 um 09:59 schrieb Rafał Miłecki:
On 29.05.2021 23:28, e9hack wrote:
I'm using a TP-Link Archer C7 v2 router. For every build, I do update my
sandbox with the current OpenWrt repository and the feeds. The first not
working build from 27.05. shows in Luci:
OpenWrt SNAPSHOT r16834-53b9cc442f / LuCI Master git-21.147.31971-74be304
Related to the changes to bridge configuration, I'm using some bridge
interfaces without a configured network device, because it's for a single WiFi
device only. For such interfaces, the configuration was not changed. I did
generate a device section without ports options manually. But it didn't help.
I broken my crystal ball, please post your network config.
74be304 is known to introduce a bug, see e7c9c63c6579 ("luci-mod-network: split
config migration into 2 steps")
If your network config already got migrated into broken version you may need to
fix it up manually.
This is my network config. I did change the option ifname to device for
interface lan manually.
I'm trying the same with a TP-Link WDR3600 router. The same does occur. I did
do a factory reset. Nothing did change. I get the same error page. Build is
OpenWrt SNAPSHOT r16844-296aa0781b / LuCI Master git-21.148.48881-79947af.
Please try the standard LuCI interface and let us know if that one works
correctly.
What do you see in web browser's console on that page?
Independently which LuCI theme is used, the error occurs and the following
message is shown in the web browser's console:
Warnings:
This page uses the non standard property “zoom”. Consider using calc() in the
relevant property values, or using “transform” along with “transform-origin: 0
0”. network
Errors:
Uncaught (in promise) NotFoundError: Resource not found
luci.js:1:1004
handleRpcReply
https://my-router.lan/luci-static/resources/fs.js?v=git-21.124.24916-0faf9a4:1
Debug:
NotFoundError: Resource not found luci.js:163:9
handleRpcReply
https://my-router.lan/luci-static/resources/fs.js?v=git-21.124.24916-0faf9a4:1
LuCI commit 17af33e
luci-mod-network: migrate network config depending on netifd version
does introduce to read the file /usr/lib/opkg/info/netifd.control. I don't have
this file on my router. Can that be the reason for the error 'Resource not
found'?
Regards,
Hartmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Luci->Network->Interfaces is broken
Am 31.05.2021 um 07:18 schrieb Rafał Miłecki:
On 30.05.2021 18:02, e9hack wrote:
Am 30.05.2021 um 15:41 schrieb e9hack:
Am 30.05.2021 um 09:59 schrieb Rafał Miłecki:
On 29.05.2021 23:28, e9hack wrote:
I'm using a TP-Link Archer C7 v2 router. For every build, I do update my
sandbox with the current OpenWrt repository and the feeds. The first not
working build from 27.05. shows in Luci:
OpenWrt SNAPSHOT r16834-53b9cc442f / LuCI Master git-21.147.31971-74be304
Related to the changes to bridge configuration, I'm using some bridge
interfaces without a configured network device, because it's for a single WiFi
device only. For such interfaces, the configuration was not changed. I did
generate a device section without ports options manually. But it didn't help.
I broken my crystal ball, please post your network config.
74be304 is known to introduce a bug, see e7c9c63c6579 ("luci-mod-network: split
config migration into 2 steps")
If your network config already got migrated into broken version you may need to
fix it up manually.
This is my network config. I did change the option ifname to device for
interface lan manually.
I'm trying the same with a TP-Link WDR3600 router. The same does occur. I did
do a factory reset. Nothing did change. I get the same error page. Build is
OpenWrt SNAPSHOT r16844-296aa0781b / LuCI Master git-21.148.48881-79947af.
Please try the standard LuCI interface and let us know if that one works
correctly.
What do you see in web browser's console on that page?
Independently which LuCI theme is used, the error occurs and the following
message is shown in the web browser's console:
Warnings:
This page uses the non standard property “zoom”. Consider using calc() in the
relevant property values, or using “transform” along with “transform-origin: 0
0”. network
Errors:
Uncaught (in promise) NotFoundError: Resource not found
luci.js:1:1004
handleRpcReply
https://my-router.lan/luci-static/resources/fs.js?v=git-21.124.24916-0faf9a4:1
Debug:
NotFoundError: Resource not found
luci.js:163:9
handleRpcReply
https://my-router.lan/luci-static/resources/fs.js?v=git-21.124.24916-0faf9a4:1
Regards,
Hartmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH luci] luci-mod-network: migrate macaddr during bridge migration
From: Rafał Miłecki
Link: https://forum.openwrt.org/t/network-migration-21-02-0-rc2/97934
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/view/network/interfaces.js | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
index 5d7f237bb6..07627c4aff 100644
---
a/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
+++
b/modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
@@ -326,12 +326,14 @@ return view.extend({
tasks.push(uci.callAdd('network', 'device', null, {
'name': device_name,
'type': 'bridge',
- 'ports': L.toArray(ns.ifname)
+ 'ports': L.toArray(ns.ifname),
+ 'macaddr': ns.macaddr
}));
tasks.push(uci.callSet('network', ns['.name'], {
'type': '',
'ifname': '',
+ 'macaddr': '',
'device': device_name
}));
});
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
