[PATCH] kernel/modules: move act_gact into kmod-sched-core
As the name suggests, act_gact has the generic actions such as dropping and accepting packets, so move it into kmod-sched-core. Signed-off-by: DENG Qingfang --- package/kernel/linux/modules/netsupport.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 7237b65303..ae6a2f52b9 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -721,7 +721,7 @@ $(eval $(call KernelPackage,mppe)) SCHED_MODULES = $(patsubst $(LINUX_DIR)/net/sched/%.ko,%,$(wildcard $(LINUX_DIR)/net/sched/*.ko)) -SCHED_MODULES_CORE = sch_ingress sch_fq_codel sch_hfsc sch_htb sch_tbf cls_basic cls_fw cls_route cls_flow cls_tcindex cls_u32 em_u32 act_mirred act_skbedit cls_matchall +SCHED_MODULES_CORE = sch_ingress sch_fq_codel sch_hfsc sch_htb sch_tbf cls_basic cls_fw cls_route cls_flow cls_tcindex cls_u32 em_u32 act_gact act_mirred act_skbedit cls_matchall SCHED_MODULES_FILTER = $(SCHED_MODULES_CORE) act_connmark act_ctinfo sch_cake sch_netem sch_mqprio em_ipset cls_bpf cls_flower act_bpf act_vlan act_nat SCHED_MODULES_EXTRA = $(filter-out $(SCHED_MODULES_FILTER),$(SCHED_MODULES)) SCHED_FILES = $(patsubst %,$(LINUX_DIR)/net/sched/%.ko,$(filter $(SCHED_MODULES_CORE),$(SCHED_MODULES))) @@ -745,6 +745,7 @@ define KernelPackage/sched-core CONFIG_NET_CLS_ROUTE4 \ CONFIG_NET_CLS_TCINDEX \ CONFIG_NET_CLS_U32 \ + CONFIG_NET_ACT_GACT \ CONFIG_NET_ACT_MIRRED \ CONFIG_NET_ACT_SKBEDIT \ CONFIG_NET_CLS_MATCHALL \ @@ -909,7 +910,6 @@ define KernelPackage/sched CONFIG_NET_SCH_FQ \ CONFIG_NET_SCH_PIE \ CONFIG_NET_ACT_POLICE \ - CONFIG_NET_ACT_GACT \ CONFIG_NET_ACT_IPT \ CONFIG_NET_ACT_PEDIT \ CONFIG_NET_ACT_SIMP \ -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: drop the conntrack rtcache patch
On 9/04/2021 01:57, Rui Salvaterra wrote: > It's in backports-5.4, but it wasn't ever merged. Upstream followed another > approach, with flow offloading, which has much better performance. Drop this > obsolete patch and refresh the kernel patches. Acked-by: Stijn Tintel Some performance comparisons: https://gist.github.com/stintel/299684b0b9eef896acc9746c4d8be746 Let's focus on flow offloading and drop rtcache. Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: drop the conntrack rtcache patch
It's in backports-5.4, but it wasn't ever merged. Upstream followed another
approach, with flow offloading, which has much better performance. Drop this
obsolete patch and refresh the kernel patches.
Signed-off-by: Rui Salvaterra
---
.../020-backport_netfilter_rtcache.patch | 558 --
.../hack-5.4/250-netfilter_depends.patch | 4 +-
.../650-netfilter-add-xt_OFFLOAD-target.patch | 8 +-
...w_table-add-hardware-offload-support.patch | 4 +-
4 files changed, 8 insertions(+), 566 deletions(-)
delete mode 100644
target/linux/generic/backport-5.4/020-backport_netfilter_rtcache.patch
diff --git
a/target/linux/generic/backport-5.4/020-backport_netfilter_rtcache.patch
b/target/linux/generic/backport-5.4/020-backport_netfilter_rtcache.patch
deleted file mode 100644
index 7b1aab9acc..00
--- a/target/linux/generic/backport-5.4/020-backport_netfilter_rtcache.patch
+++ /dev/null
@@ -1,558 +0,0 @@
-From 1bb0c3ec899827cfa4668bb63a08713a40744d21 Mon Sep 17 00:00:00 2001
-From: Florian Westphal
-Date: Sun, 9 Jul 2017 08:58:30 +0200
-Subject: [PATCH] netfilter: conntrack: cache route for forwarded connections
-
-... to avoid per-packet FIB lookup if possible.
-
-The cached dst is re-used provided the input interface
-is the same as that of the previous packet in the same direction.
-
-If not, the cached dst is invalidated.
-
-For ipv6 we also need to store sernum, else dst_check doesn't work,
-pointed out by Eric Dumazet.
-
-This should speed up forwarding when conntrack is already in use
-anyway, especially when using reverse path filtering -- active RPF
-enforces two FIB lookups for each packet.
-
-Before the routing cache removal this didn't matter since RPF was performed
-only when route cache didn't yield a result; but without route cache it
-comes at higher price.
-
-Julian Anastasov suggested to add NETDEV_UNREGISTER handler to
-avoid holding on to dsts of 'frozen' conntracks.
-
-Signed-off-by: Florian Westphal
- include/net/netfilter/nf_conntrack_extend.h | 4 +
- include/net/netfilter/nf_conntrack_rtcache.h | 34 +++
- net/netfilter/Kconfig| 12 +
- net/netfilter/Makefile | 3 +
- net/netfilter/nf_conntrack_rtcache.c | 428 +++
- 5 files changed, 481 insertions(+)
- create mode 100644 include/net/netfilter/nf_conntrack_rtcache.h
- create mode 100644 net/netfilter/nf_conntrack_rtcache.c
-
a/include/net/netfilter/nf_conntrack_extend.h
-+++ b/include/net/netfilter/nf_conntrack_extend.h
-@@ -28,6 +28,9 @@ enum nf_ct_ext_id {
- #if IS_ENABLED(CONFIG_NETFILTER_SYNPROXY)
- NF_CT_EXT_SYNPROXY,
- #endif
-+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
-+ NF_CT_EXT_RTCACHE,
-+#endif
- NF_CT_EXT_NUM,
- };
-
-@@ -40,6 +43,7 @@ enum nf_ct_ext_id {
- #define NF_CT_EXT_TIMEOUT_TYPE struct nf_conn_timeout
- #define NF_CT_EXT_LABELS_TYPE struct nf_conn_labels
- #define NF_CT_EXT_SYNPROXY_TYPE struct nf_conn_synproxy
-+#define NF_CT_EXT_RTCACHE_TYPE struct nf_conn_rtcache
-
- /* Extensions: optional stuff which isn't permanently in struct. */
- struct nf_ct_ext {
/dev/null
-+++ b/include/net/netfilter/nf_conntrack_rtcache.h
-@@ -0,0 +1,34 @@
-+#include
-+#include
-+#include
-+
-+struct dst_entry;
-+
-+struct nf_conn_dst_cache {
-+ struct dst_entry *dst;
-+ int iif;
-+#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6)
-+ u32 cookie;
-+#endif
-+
-+};
-+
-+struct nf_conn_rtcache {
-+ struct nf_conn_dst_cache cached_dst[IP_CT_DIR_MAX];
-+};
-+
-+static inline
-+struct nf_conn_rtcache *nf_ct_rtcache_find(const struct nf_conn *ct)
-+{
-+#if IS_ENABLED(CONFIG_NF_CONNTRACK_RTCACHE)
-+ return nf_ct_ext_find(ct, NF_CT_EXT_RTCACHE);
-+#else
-+ return NULL;
-+#endif
-+}
-+
-+static inline int nf_conn_rtcache_iif_get(const struct nf_conn_rtcache *rtc,
-+enum ip_conntrack_dir dir)
-+{
-+ return rtc->cached_dst[dir].iif;
-+}
a/net/netfilter/Kconfig
-+++ b/net/netfilter/Kconfig
-@@ -136,6 +136,18 @@ config NF_CONNTRACK_EVENTS
-
- If unsure, say `N'.
-
-+config NF_CONNTRACK_RTCACHE
-+ tristate "Cache route entries in conntrack objects"
-+ depends on NETFILTER_ADVANCED
-+ depends on NF_CONNTRACK
-+ help
-+If this option is enabled, the connection tracking code will
-+cache routing information for each connection that is being
-+forwarded, at a cost of 32 bytes per conntrack object.
-+
-+To compile it as a module, choose M here. If unsure, say N.
-+The module will be called nf_conntrack_rtcache.
-+
- config NF_CONNTRACK_TIMEOUT
- bool 'Connection tracking timeout'
- depends on NETFILTER_ADVANCED
a/net/netfilter/Makefile
-+++ b/net/netfilter/Makefile
-@@ -26,6 +26,9 @@ obj-$(CONFIG_NETFILTER_NETLINK_OSF) += n
- # connection tracking
- obj-$(CONFIG_NF_CONNTRACK) += nf_conntrack.o
-
-+# optional conntrack route cache extension
[PATCH] firmware-utils: tplink-safeloader: support displaying fw info
From: Rafał Miłecki
Add "-i" option for reading & displaying firmware info. First it lists
in-firmware partitions ("fwup-ptn"). Then it checks for human
understandable partitions and prints data found in each of them.
This new feature is meant for development & debug purposes.
Signed-off-by: Rafał Miłecki
---
tools/firmware-utils/src/tplink-safeloader.c | 102 ++-
1 file changed, 98 insertions(+), 4 deletions(-)
diff --git a/tools/firmware-utils/src/tplink-safeloader.c
b/tools/firmware-utils/src/tplink-safeloader.c
index da73e1bf30..896b8b5382 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -2877,6 +2877,8 @@ static void usage(const char *argv0) {
"Options:\n"
" -h show this help\n"
"\n"
+ "Info about an image:\n"
+ " -iinput file to read from\n"
"Create a new image:\n"
" -B create image for the board specified with
\n"
" -kread kernel image from the file \n"
@@ -3141,10 +3143,96 @@ static struct flash_partition_entry *find_partition(
return entries;
}
- error(1, 0, "%s", error_msg);
+ if (error_msg) {
+ error(1, 0, "%s", error_msg);
+ }
+
return NULL;
}
+static int firmware_info(const char *input)
+{
+ struct flash_partition_entry pointers[MAX_PARTITIONS] = { };
+ struct flash_partition_entry *e;
+ FILE *fp;
+ int i;
+
+ fp = fopen(input, "r");
+
+ if (read_partition_table(fp, 0x1014, pointers, MAX_PARTITIONS, 0)) {
+ error(1, 0, "Error can not read the partition table
(fwup-ptn)");
+ }
+
+ printf("Firmware image partitions:\n");
+ printf("%-8s %-8s %s\n", "base", "size", "name");
+ for (i = 0; i < MAX_PARTITIONS; i++) {
+ e = [i];
+
+ if (!e->name && !e->base && !e->size)
+ continue;
+
+ printf("%08x %08x %s\n", e->base, e->size, e->name ? e->name :
"");
+ }
+
+ e = find_partition(pointers, MAX_PARTITIONS, "soft-version", NULL);
+ if (e) {
+ struct soft_version s;
+
+ if (fseek(fp, 0x1014 + e->base + sizeof(struct meta_header),
SEEK_SET))
+ error(1, errno, "Can not seek in the firmware");
+
+ if (fread(, sizeof(s), 1, fp) != 1)
+ error(1, errno, "Can not read fwup-ptn from the
firmware");
+
+ printf("\n[Software version]\n");
+ printf("Version: %d.%d.%d\n", s.version_major, s.version_minor,
s.version_patch);
+ printf("Date: %02x%02x-%02x-%02x\n", s.year_hi, s.year_lo,
s.month, s.day);
+ }
+
+ e = find_partition(pointers, MAX_PARTITIONS, "support-list", NULL);
+ if (e) {
+ char buf[128];
+ size_t length;
+ size_t bytes;
+
+ if (fseek(fp, 0x1014 + e->base + sizeof(struct meta_header),
SEEK_SET))
+ error(1, errno, "Can not seek in the firmware");
+
+ printf("\n[Support list]\n");
+ for (length = e->size - sizeof(struct meta_header); length;
length -= bytes) {
+ bytes = fread(buf, 1, length > sizeof(buf) ?
sizeof(buf) : length, fp);
+ if (bytes <= 0)
+ error(1, errno, "Can not read fwup-ptn from the
firmware");
+
+ puts(buf);
+ }
+ }
+
+ e = find_partition(pointers, MAX_PARTITIONS, "partition-table", NULL);
+ if (e) {
+ struct flash_partition_entry parts[MAX_PARTITIONS] = { };
+
+ if (read_partition_table(fp, 0x1014 + e->base + 4, parts,
MAX_PARTITIONS, 1)) {
+ error(1, 0, "Error can not read the partition table
(partition)");
+ }
+
+ printf("\n[Partition table]\n");
+ printf("%-8s %-8s %s\n", "base", "size", "name");
+ for (i = 0; i < MAX_PARTITIONS; i++) {
+ e = [i];
+
+ if (!e->name && !e->base && !e->size)
+ continue;
+
+ printf("%08x %08x %s\n", e->base, e->size, e->name ?
e->name : "");
+ }
+ }
+
+ fclose(fp);
+
+ return 0;
+}
+
static void write_ff(FILE *output_file, size_t size)
{
char buf[4096];
@@ -3224,7 +3312,7 @@ static void convert_firmware(const char *input, const
char *output)
}
int main(int argc, char *argv[]) {
- const char *board = NULL, *kernel_image = NULL, *rootfs_image = NULL,
*output = NULL;
+ const char *info_image = NULL, *board = NULL, *kernel_image = NULL,
*rootfs_image = NULL, *output = NULL;
const char *extract_image = NULL, *output_directory = NULL,
[PATCH] netfilter: remove no-op kconfig symbols
These have long been obsolete. For reference, here's the Linux version where each symbol has been dropped: CONFIG_IP6_NF_QUEUE - 3.5 CONFIG_IP6_NF_TARGET_LOG - 3.4 CONFIG_IP_NF_MATCH_DSCP - 2.6.19 CONFIG_NF_CONNTRACK_IPV4 - 4.19 CONFIG_NF_CONNTRACK_IPV6 - 4.19 Signed-off-by: Rui Salvaterra --- include/netfilter.mk | 5 - 1 file changed, 5 deletions(-) diff --git a/include/netfilter.mk b/include/netfilter.mk index 45e9dadf85..2b8aa7c5c8 100644 --- a/include/netfilter.mk +++ b/include/netfilter.mk @@ -66,7 +66,6 @@ $(eval $(if $(NF_KMOD),,$(call nf_add,IPT_CORE,CONFIG_NETFILTER_XT_MARK, $(P_XT) $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK, $(P_XT)nf_conntrack),)) $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK_RTCACHE, $(P_XT)nf_conntrack_rtcache),)) $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_DEFRAG_IPV4, $(P_V4)nf_defrag_ipv4),)) -$(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_CONNTRACK_IPV4, $(P_V4)nf_conntrack_ipv4),)) $(eval $(call nf_add,IPT_CONNTRACK,CONFIG_NETFILTER_XT_MATCH_STATE, $(P_XT)xt_state)) $(eval $(call nf_add,IPT_CONNTRACK,CONFIG_NETFILTER_XT_TARGET_CT, $(P_XT)xt_CT)) @@ -120,7 +119,6 @@ $(eval $(call nf_add,IPT_IPOPT,CONFIG_NETFILTER_XT_MATCH_STATISTIC, $(P_XT)xt_st $(eval $(call nf_add,IPT_IPOPT,CONFIG_NETFILTER_XT_MATCH_TCPMSS, $(P_XT)xt_tcpmss)) $(eval $(call nf_add,IPT_IPOPT,CONFIG_NETFILTER_XT_TARGET_CLASSIFY, $(P_XT)xt_CLASSIFY)) -$(eval $(call nf_add,IPT_IPOPT,CONFIG_IP_NF_MATCH_DSCP, $(P_V4)ipt_dscp)) $(eval $(call nf_add,IPT_IPOPT,CONFIG_IP_NF_TARGET_ECN, $(P_V4)ipt_ECN)) $(eval $(call nf_add,IPT_IPOPT,CONFIG_NETFILTER_XT_MATCH_ECN, $(P_XT)xt_ecn)) @@ -156,17 +154,14 @@ $(eval $(if $(NF_KMOD),$(call nf_add,NF_REJECT6,CONFIG_NF_REJECT_IPV6, $(P_V6)nf $(eval $(if $(NF_KMOD),$(call nf_add,NF_IPT6,CONFIG_IP6_NF_IPTABLES, $(P_V6)ip6_tables),)) $(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK,CONFIG_NF_DEFRAG_IPV6, $(P_V6)nf_defrag_ipv6),)) -$(eval $(if $(NF_KMOD),$(call nf_add,NF_CONNTRACK6,CONFIG_NF_CONNTRACK_IPV6, $(P_V6)nf_conntrack_ipv6),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_IPV6,CONFIG_IP6_NF_FILTER, $(P_V6)ip6table_filter),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_IPV6,CONFIG_IP6_NF_MANGLE, $(P_V6)ip6table_mangle),)) -$(eval $(if $(NF_KMOD),$(call nf_add,IPT_IPV6,CONFIG_IP6_NF_QUEUE, $(P_V6)ip6_queue),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_IPV6,CONFIG_NF_LOG_IPV6, $(P_V6)nf_log_ipv6),)) $(eval $(if $(NF_KMOD),,$(call nf_add,IPT_IPV6,CONFIG_IP6_NF_IPTABLES, ip6t_icmp6))) -$(eval $(call nf_add,IPT_IPV6,CONFIG_IP6_NF_TARGET_LOG, $(P_V6)ip6t_LOG)) $(eval $(call nf_add,IPT_IPV6,CONFIG_IP6_NF_TARGET_REJECT, $(P_V6)ip6t_REJECT)) # ipv6 extra -- 2.31.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Concernant CARTEL SYLVAIN l’affichage obligatoire 2021 change
Bonjour, je vous informe de nouvelles modifications concernant les affichages obligatoires de CARTEL SYLVAIN qui doivent être en place depuis janvier 2021. La législation a changé, votre exemplaire d’affichage obligatoire n’est peut-être plus à jour et doit être actualisé pour rester en conformité. Voici la liste des obligations d’affichage et de diffusion actualisée en 2021, à mettre en place à partir du premier salarié, pour toutes les entreprises, commerçants, artisans, associations : - Informations : Inspection du travail, Médecine du travail, Texte conventionnel applicable, règlement intérieur à partir de 20 salariés, etc. Article R2262-1 et autres - Affichage spécifique CSE (à partir de 11 salariés) Article 2311-2. - Harcèlement moral et sexuel (inclus les actions contentieuses civiles et pénales). Loi 2018-771. - Affichage des numéros d'urgence (inclus numéros : discriminations, sourds et malentendants, etc. ). Article D4711-1. - Informations Lutte contre les discriminations, Affichage numéro de téléphone Infos Service. A afficher à la porte ou se fait le recrutement. Article 225-1 et autres - Informations : Égalité professionnelle entre hommes et femmes au travail Article L3221-1 et autres - Affichage des consignes de sécurité selon le code du travail. Article R4227-1 et autres - Affichage de l’Interdiction de fumer et de la Zone fumeurs. Article R.3511-1 et autres - Information : Interdiction de Vapoter. - Affichage Ordre des départs en congés 2021. Article D3141-6. - Modalités d'accès au document d'évaluation des risques. Article R4121-1 et suivants sont édités par ailleurs les : - Nouveaux affichages Coronavirus : Affichage mesures employeurs, Mesures salariés, protocole de nettoyage, etc. Afin d’aider les entreprises dans le cadre de la prévention santé et sécurité des salariés sont offert avec le pack d’affichages obligatoires integral 2021, l’affichage des mesures à prendre par le salarié dans le cadre du Covid19, et l’affichage des mesures à prendre en cas de contamination sur le lieu de travail. Pour mettre votre établissement en conformité, commandez dès à présent l'affichage obligatoire 2021 + les affichages Covid offerts : https://www.cndtf.fr/index.php?id=36078449=132=6120 Cordialement Le service Entreprise Emma Perez Tél. : 01 85 54 00 89 -- Pour vous désinscrire cliquez ici https://www.cndtf.fr/desinscription.php?mail=openwrt-devel@lists.openwrt.org=36078449=1=6120 Conformément à l'application règlement n°2016/679 du Parlement Européen relatif à la protection des données à caractère personnel et à la loi n° 2004-801 du 6 août 2004 relative à la protection des personnes physiques à l'égard des traitements de données à caractère personnel, vous disposez d'un droit d'accès, de modification, de rectification et de suppression des données vous concernant. Informations sur notre politique en matière de vie privé, dans le menu utilisateur à la rubrique "Données personnelles" -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/1] ltq-vdsl-app: extent dsl metrics with boolean power and line states
Hi Florian,
On 06/04/2021 14:49, Florian Eckert wrote:
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit changes the following JSON output.
Instead of outputting the "line_state" and "power_state" numbers directly, the
values is now printed as boolean. This has the advantage that the
internal numbers are not shown, which can change in the future.
* current JSON output for state:
"state": "Showtime with TC-Layer sync"
* new JSON output for state:
"line_state": {
"exception": false,
"idle": false,
"silent": false,
"handshake": false,
"full-init": false,
"showtime-without-sync": false,
"showtime-with-sync": true,
"resync": false,
"not-initialized": false,
"string": "Showtime with TC-Layer sync"
},
okay with me if you require that detail, although "string" is a little
weird I think.
How about keeping the old "state" (which has the nice side effect of not
breaking backwards compability or the need to adapt luci and prometheus)
and putting the new stuff under an additional "state_detail" table? We'd
just have a bunch of bools in a table, which could be nicer for
evaluation too.
* current JSON output for power_state:
"power_state": "L0 - Synchronized"
* new JSON outpug for power_state:
"power_state": {
"NA": false,
"L0": true,
"L1": false,
"L2": false,
"L3": false,
"string": "L0 - Synchronized"
}
This could be an integer metric [0-3], with a missing metric indicating
"NA".
Similar to above reasoning, it'll be easier to keep "power_state" as is
and add "power_level" (is "L" level here?) containing [0-3].
What do you think?
Andre
Signed-off-by: Florian Eckert
---
package/network/config/ltq-vdsl-app/Makefile | 2 +-
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 32 ---
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/Makefile
b/package/network/config/ltq-vdsl-app/Makefile
index 0823a0e7e9..f5c561078d 100644
--- a/package/network/config/ltq-vdsl-app/Makefile
+++ b/package/network/config/ltq-vdsl-app/Makefile
@@ -9,7 +9,7 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=ltq-vdsl-app
PKG_VERSION:=4.17.18.6
-PKG_RELEASE:=8
+PKG_RELEASE:=9
PKG_BASE_NAME:=dsl_cpe_control
PKG_SOURCE:=$(PKG_BASE_NAME)_vrx-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=@OPENWRT
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 8eefdfe4d5..2ab35ac056 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -306,6 +306,7 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ void *c;
const char *str;
switch (out.data.nLineState) {
STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
@@ -351,8 +352,21 @@ static void line_state(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "line_state");
+ m_bool("exception", out.data.nLineState ==
DSL_LINESTATE_EXCEPTION);
+ m_bool("idle", out.data.nLineState == DSL_LINESTATE_IDLE);
+ m_bool("silent", out.data.nLineState == DSL_LINESTATE_SILENT);
+ m_bool("handshake", out.data.nLineState ==
DSL_LINESTATE_HANDSHAKE);
+ m_bool("full-init", out.data.nLineState ==
DSL_LINESTATE_FULL_INIT);
+ m_bool("showtime-without-sync", out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_NO_SYNC);
+ m_bool("showtime-with-sync", out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_TC_SYNC);
+ m_bool("resync", out.data.nLineState == DSL_LINESTATE_RESYNC);
+ m_bool("not-initialized", out.data.nLineState ==
DSL_LINESTATE_NOT_INITIALIZED);
+ m_str("string", str);
+ blobmsg_close_table(, c);
+ }
m_bool("up", out.data.nLineState == DSL_LINESTATE_SHOWTIME_TC_SYNC);
}
@@ -377,6 +391,7 @@ static void g997_line_inventory(int fd) {
static void g997_power_management_status(int fd) {
IOCTL(DSL_G997_PowerManagementStatus_t,
DSL_FIO_G997_POWER_MANAGEMENT_STATUS_GET)
+ void *c;
const char *str;
switch (out.data.nPowerManagementStatus) {
STR_CASE(DSL_G997_PMS_NA, "Power management state is not available")
@@ -388,8 +403,17 @@ static void g997_power_management_status(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("power_state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "power_state");
+ m_bool("NA",
Re: OpenWrt 21.02-rc1
On 08/04/2021 11:14, Mauro Mozzarelli wrote: 2) dsl_control [status|lucistat] was changed with dsl reporting removed https://forum.openwrt.org/t/openwrt-21-02-dsl-control/89962/22 I understand the reason behind this change. I had to write my own command line reporting and adapt batch data collection and router connectivity keepalive scripts that previously depended on dsl_control, but users who have dependencies on these removed command line features are likely to be impacted. My recommendation is that it should be documented (there is no documentation right now). I wonder why backward compatibility was not considered as it would not be difficult to reproduce "status" and "lucistat" functionality. Going by that forum post, I'm that "genius". Ignoring your misplaced tone, it's the same as with most open source projects: upstream you stuff or expect breakage if you rely on internal data. Consumers of these metrics that *are* upstream (luci and prometheus at the time) were adopted to the new ubus metrics, so there is no breakage. Sometimes things need to evolve. And if they do, there's no way to fix or even know about downstream users. If you've got something that's valuable to other users, it's in your interest to upstream it so you won't run into this again. On the other hand, I too use various patches that aren't suitable for upstream. That's on me and I need to adapt those every now and then if things change. But I don't get the right to complain if things change. Cheers, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: Fix for Mikrotik NAND bad blocks - testers needed
Hello Danijel, On Tue, Mar 23, 2021 at 3:21 PM Sergey Ryazanov wrote: > On Mon, Mar 22, 2021 at 11:54 PM Danijel wrote: >> So now I'm looking for testers (and reviewers) who could test this change on >> the affected devices (with bad blocks) and NOR Mikrotiks. > > I have a couple of RB433 boards somewhere with BB in the kernel area. > I will try to find them and test with your changes. I found mentioned boards, but they in fact were RB411U. Each of them have bad blocks in the kernel area and so they are unable to work with OpenWrt 19.07. I am stuck with running master ath79 on it. Board bootloader rejects to boot an initramfs kernel. Looks like this happened due to its size. I am beginning to switch to lzma-loader, but faced some decompression issues and need some more time to be able to test your patches. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/3] uboot-envtools: add support for GS108T v3 & GS110TPP v1
Hi, Op donderdag 8 april 2021 om 12u33 schreef Stijn Segers : The Netgear GS108T v3 and its GS110TPP v1 sibling apparently label their u-boot environment parition 'bdinfo' instead of 'u-boot-env'. I was still carrying prior to Bjorn's last rebase, but this isn't needed anymore. Both devices fully match the generic case. Will update accordingly in Patchwork. Cheers Stijn Signed-off-by: Stijn Segers --- package/boot/uboot-envtools/files/realtek | 6 ++ 1 file changed, 6 insertions(+) diff --git a/package/boot/uboot-envtools/files/realtek b/package/boot/uboot-envtools/files/realtek index 75a399208e..0ee81fe791 100644 --- a/package/boot/uboot-envtools/files/realtek +++ b/package/boot/uboot-envtools/files/realtek @@ -22,6 +22,12 @@ zyxel,gs1900-10hp) [ -n "$idx2" ] && \ ubootenv_add_uci_sys_config "/dev/mtd$idx2" "0x0" "0x1000" "0x1" ;; +netgear,gs108t-v3|\ +netgear,gs110tpp-v1) + idx="$(find_mtd_index u-boot-env)" + [ -n "$idx" ] && \ + ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x1" "0x1" + ;; *) idx="$(find_mtd_index u-boot-env)" [ -n "$idx" ] && \ -- 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
[PATCH v2 0/3] Realtek: various fixes
This is a set of assorted fixes and improvements for the realtek target. Patch #3 depends on the rtl83xx-poe package sitting in Patchwork. If we keep the realtek target for 21.02, please backport these from master. Stijn Segers (3): uboot-envtools: add support for GS108T v3 & GS110TPP v1 realtek: correct PoE power budget for GS110TPP v1 realtek: add rtl83xx-poe to GS1900-8HP & GS1900-10HP package/boot/uboot-envtools/files/realtek | 6 ++ target/linux/realtek/base-files/etc/board.d/02_network | 2 +- target/linux/realtek/image/Makefile| 5 +++-- 3 files changed, 10 insertions(+), 3 deletions(-) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 3/3] realtek: add rtl83xx-poe for GS1900-8HP & GS1900-10HP
Add the rtl83xx-poe package to the device profiles for the ZyXEL PoE switches that are currently supported: - GS1900-10HP - GS1900-8HP v1 - GS1900-8HP v2 Signed-off-by: Stijn Segers --- This patch depends on the rtl83xx-poe package sitting in Patchwork: https://patchwork.ozlabs.org/project/openwrt/list/?series=233826 --- target/linux/realtek/image/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/target/linux/realtek/image/Makefile b/target/linux/realtek/image/Makefile index 18e5fedb9b..65aeed6a5e 100644 --- a/target/linux/realtek/image/Makefile +++ b/target/linux/realtek/image/Makefile @@ -98,6 +98,7 @@ endef define Device/zyxel_gs1900-10hp $(Device/zyxel_gs1900) DEVICE_MODEL := GS1900-10HP + DEVICE_PACKAGES += rtl83xx-poe ZYXEL_VERS := AAZI endef TARGET_DEVICES += zyxel_gs1900-10hp @@ -113,8 +114,8 @@ define Device/zyxel_gs1900-8hp-v1 $(Device/zyxel_gs1900) DEVICE_MODEL := GS1900-8HP DEVICE_VARIANT := v1 + DEVICE_PACKAGES += rtl83xx-poe ZYXEL_VERS := AAHI - DEVICE_PACKAGES += lua-rs232 endef TARGET_DEVICES += zyxel_gs1900-8hp-v1 @@ -122,8 +123,8 @@ define Device/zyxel_gs1900-8hp-v2 $(Device/zyxel_gs1900) DEVICE_MODEL := GS1900-8HP DEVICE_VARIANT := v2 + DEVICE_PACKAGES += rtl83xx-poe ZYXEL_VERS := AAHI - DEVICE_PACKAGES += lua-rs232 endef TARGET_DEVICES += zyxel_gs1900-8hp-v2 -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/3] uboot-envtools: add support for GS108T v3 & GS110TPP v1
The Netgear GS108T v3 and its GS110TPP v1 sibling apparently label their u-boot environment parition 'bdinfo' instead of 'u-boot-env'. Signed-off-by: Stijn Segers --- package/boot/uboot-envtools/files/realtek | 6 ++ 1 file changed, 6 insertions(+) diff --git a/package/boot/uboot-envtools/files/realtek b/package/boot/uboot-envtools/files/realtek index 75a399208e..0ee81fe791 100644 --- a/package/boot/uboot-envtools/files/realtek +++ b/package/boot/uboot-envtools/files/realtek @@ -22,6 +22,12 @@ zyxel,gs1900-10hp) [ -n "$idx2" ] && \ ubootenv_add_uci_sys_config "/dev/mtd$idx2" "0x0" "0x1000" "0x1" ;; +netgear,gs108t-v3|\ +netgear,gs110tpp-v1) + idx="$(find_mtd_index u-boot-env)" + [ -n "$idx" ] && \ + ubootenv_add_uci_config "/dev/mtd$idx" "0x0" "0x1" "0x1" + ;; *) idx="$(find_mtd_index u-boot-env)" [ -n "$idx" ] && \ -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/3] realtek: correct PoE power budget for GS110TPP v1
According to multiple sources (Netgear web page [1], Wikidevi [2] and Biot's wiki [3] this switch has a 120W PoE power budget, not a 130W one. [1] https://www.netgear.com/business/wired/switches/smart-cloud/gs110tpp/ [2] https://wikidevi.wi-cat.ru/Netgear_GS110TPP [3] https://biot.com/switches/gs110tpp Signed-off-by: Stijn Segers --- target/linux/realtek/base-files/etc/board.d/02_network | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/realtek/base-files/etc/board.d/02_network b/target/linux/realtek/base-files/etc/board.d/02_network index 1e199db589..b27bed9a63 100644 --- a/target/linux/realtek/base-files/etc/board.d/02_network +++ b/target/linux/realtek/base-files/etc/board.d/02_network @@ -49,7 +49,7 @@ done case $board in netgear,gs110tpp-v1) - ucidef_set_poe 130 "$lan_list" + ucidef_set_poe 120 "$lan_list" ;; zyxel,gs1900-10hp) ucidef_set_poe 77 "$lan_list" -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
Hi guys, On 08. 04. 21 11:14, Mauro Mozzarelli wrote: > Hauke, > > I have been using 21.02 for the last 4 weeks and I found 2 importants issues: > > 1) OpenVPN up/down: > https://forum.openwrt.org/t/openwrt-21-02-openvpn-client-up-down-scripts-configuration-ignored/91126 > There are proposed fixes, but I have not seen these yet in the latest 21.02 > branch. > I question the value of the change introduced for openvpn hotplug, which is > un-necessary given the existing native up/down options. The change introduces > additional complexity, cost of maintenance (technical debt) and new possible > points of failure just to reproduce an existing native openvpn function. The > value added is therefore unclear. I would remove it altogether. Yesterday, maintainer of OpenVPN package created PR against OpenWrt 21.02 branch [1], where he cherry-picked commits from master, which fixes the issue, which you are mention and in the same day, it was merged. It should be in a few hours if not already present in OpenWrt 21.02. [1] https://github.com/openwrt/packages/pull/15363 Regards, Josef > > 2) dsl_control [status|lucistat] was changed with dsl reporting removed > https://forum.openwrt.org/t/openwrt-21-02-dsl-control/89962/22 > I understand the reason behind this change. I had to write my own command > line reporting and adapt batch data collection and router connectivity > keepalive scripts that previously depended on dsl_control, but users who have > dependencies on these removed command line features are likely to be > impacted. My recommendation is that it should be documented (there is no > documentation right now). > I wonder why backward compatibility was not considered as it would not be > difficult to reproduce "status" and "lucistat" functionality. > > > On 06/04/2021, 23:37, "openwrt-devel on behalf of Hauke Mehrtens" > wrote: > > Hi, > > How do we want to go forward with OpenWrt 21.02-rc1? > > * I think the base system is ok. > * The http (original wolfssl) problem reported by jow is fixed > * LuCI in the 21.02 branch still misses DSA support, this was merged > into master some time ago as far as I understood. > > Jow reported this end of March: > > I found some serious regressions in the luci device config support. > > not sure yet how long it'll take to sort out. The netifd uci config > > grew so complex that it'll take a while to try all cases > > * changing interface settings after previously enabling certain > > options results in a brick > > * wireless networks with custom ifnames are improperly bridged > > * option ipv6 for ppp based protocols is broken because it clashes > > with option ipv6 in device sections > > I would like to merge this update of iproute2 if Russel is fine with it, > but I do not see this blocking 21.02-rc1: > https://github.com/openwrt/openwrt/pull/4025 > > If there are some other bugs in the 21.02 branch which are fixed in > master, we can backport the fixed as long as they are not so big. If > there is something missing, just ask on the mainling list. > > In would like to get 21.02-rc1 soon, so more users start testing it and > we get more bug reports. > > How should we continue? > 1. Tag 21.02-rc1 and do the release in the next days with the current > state. > > 2. Merge the LuCI DSA changes from master to 21.02 branch now and do > 21.02-rc1 ~3 days to see if some big problems come up. > > 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 > them. > > 4. Wait an other 2 weeks and see how it looks them. > > > I would prefer if we merge the LuCI DSA changes from master to 21.02 > branch now and do 21.02-rc1 soon. We should list the problems as known > problems. > > It would be nice if someone else could also look into these problems and > propose fixes. > > Hauke > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
Hauke, I have been using 21.02 for the last 4 weeks and I found 2 importants issues: 1) OpenVPN up/down: https://forum.openwrt.org/t/openwrt-21-02-openvpn-client-up-down-scripts-configuration-ignored/91126 There are proposed fixes, but I have not seen these yet in the latest 21.02 branch. I question the value of the change introduced for openvpn hotplug, which is un-necessary given the existing native up/down options. The change introduces additional complexity, cost of maintenance (technical debt) and new possible points of failure just to reproduce an existing native openvpn function. The value added is therefore unclear. I would remove it altogether. 2) dsl_control [status|lucistat] was changed with dsl reporting removed https://forum.openwrt.org/t/openwrt-21-02-dsl-control/89962/22 I understand the reason behind this change. I had to write my own command line reporting and adapt batch data collection and router connectivity keepalive scripts that previously depended on dsl_control, but users who have dependencies on these removed command line features are likely to be impacted. My recommendation is that it should be documented (there is no documentation right now). I wonder why backward compatibility was not considered as it would not be difficult to reproduce "status" and "lucistat" functionality. On 06/04/2021, 23:37, "openwrt-devel on behalf of Hauke Mehrtens" wrote: Hi, How do we want to go forward with OpenWrt 21.02-rc1? * I think the base system is ok. * The http (original wolfssl) problem reported by jow is fixed * LuCI in the 21.02 branch still misses DSA support, this was merged into master some time ago as far as I understood. Jow reported this end of March: > I found some serious regressions in the luci device config support. > not sure yet how long it'll take to sort out. The netifd uci config > grew so complex that it'll take a while to try all cases > * changing interface settings after previously enabling certain > options results in a brick > * wireless networks with custom ifnames are improperly bridged > * option ipv6 for ppp based protocols is broken because it clashes > with option ipv6 in device sections I would like to merge this update of iproute2 if Russel is fine with it, but I do not see this blocking 21.02-rc1: https://github.com/openwrt/openwrt/pull/4025 If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. In would like to get 21.02-rc1 soon, so more users start testing it and we get more bug reports. How should we continue? 1. Tag 21.02-rc1 and do the release in the next days with the current state. 2. Merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 ~3 days to see if some big problems come up. 3. Wait till the problems reported by jow are fixed and do the 21.02-rc1 them. 4. Wait an other 2 weeks and see how it looks them. I would prefer if we merge the LuCI DSA changes from master to 21.02 branch now and do 21.02-rc1 soon. We should list the problems as known problems. It would be nice if someone else could also look into these problems and propose fixes. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 2021-04-07 20:07, John Crispin wrote: On 07.04.21 12:16, Bas Mevissen via openwrt-devel wrote: Will Wifi 6 support be added to the interface? We have some support for a couple of AX routers, so it would be nice if they can work without manually tweaking things. The underlying structure seems to support it already: https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533 I have a couple of patches pending that I will post the next few days that will make the primary HE features work on 21.02. I converged my home to 3xe8450 Good to hear. I've an X5000R waiting to be converted to OpenWRT. The E8450 or RT3200 would have been a better choice, but at the time I wanted to order a supported AX router, it was only the X5000R or the UniFi 6 Lite to choose from. The X5000R unfortunately cannot max out the Killer Wifi card in my notebook, but it still makes around 800Mbit/s with iperf3 though. Bas. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 - realtek and mediatek targets
Hi, Op donderdag 8 april 2021 om 8u35 schreef Bjørn Mork : Stijn Segers writes: A vote for keeping the realtek target here, I have three devices here in production. Very happy with them. The main catch I see with relegating the realtek target to master would be less uptake on the end user side (not everyone will want to run hardware that needs OpenWrt master), but I am unqualified to judge the code quality. All I can say is it runs nicely here (including PoE). I agree. The feature set of the realtek target is pretty complete, and the anticipated fast movement of the target in master has not happened yet. So please keep realtek for 21.02. There is one pending series applicable to realtek which I had hoped to get in before exposing the target to innocent users, but this might be too late by now?: https://patchwork.ozlabs.org/project/openwrt/list/?series=237587 Being able to adjust the "bootpartition" variable is crucial to support console-less installation IMHO. Which makes the target more accessible to non-developers. I see Petr just merged them into master (thanks!). I'll be sending in a few fixes that depend on them too, would be good if they could make it into 21.02 as well. Cheers Stijn Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1 - realtek and mediatek targets
Stijn Segers writes: > A vote for keeping the realtek target here, I have three devices here > in production. Very happy with them. The main catch I see with > relegating the realtek target to master would be less uptake on the > end user side (not everyone will want to run hardware that needs > OpenWrt master), but I am unqualified to judge the code quality. > > All I can say is it runs nicely here (including PoE). I agree. The feature set of the realtek target is pretty complete, and the anticipated fast movement of the target in master has not happened yet. So please keep realtek for 21.02. There is one pending series applicable to realtek which I had hoped to get in before exposing the target to innocent users, but this might be too late by now?: https://patchwork.ozlabs.org/project/openwrt/list/?series=237587 Being able to adjust the "bootpartition" variable is crucial to support console-less installation IMHO. Which makes the target more accessible to non-developers. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
