from:"Nick"

Re: expat update broke build on ubuntu 22.04 server

2024-02-13 Thread nick


Can you try building from a clean build, e.g. use make distclean?

On 2/13/24 11:56, Koen Vandeputte wrote:

Hi Nick,

Regarding commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4a3f430d726e0713f4936844f26ccaf5077ef881


I'm seeing this when building:
Any idea how to fix it?



checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std=c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with +std=c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -h std=c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std:c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std=c++0x... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with +std=c++0x... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -h std=c++0x... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std:c++0x... no
configure: error: *** A compiler with support for C++11 language
features is required.
make[3]: *** [Makefile:34:
/home/koen/firmware/builds/generic_dr40x9/build_dir/host/expat-2.6.0/.configured]
Error 1
make[3]: Leaving directory
'/home/koen/firmware/builds/generic_dr40x9/tools/expat'
time: tools/expat/compile#0.94#0.25#1.17
 ERROR: tools/expat failed to build.
make[2]: *** [tools/Makefile:228: tools/expat/compile] Error 1
make[2]: Leaving directory '/home/koen/firmware/builds/generic_dr40x9'
make[1]: *** [tools/Makefile:224:
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/stamp/.tools_compile_nyyynyynnnnynyyynyyynnynyynnynnyynyyynynnyyy]
Error 2
make[1]: Leaving directory '/home/koen/firmware/builds/generic_dr40x9'
make: *** [/home/koen/firmware/builds/generic_dr40x9/include/toplevel.mk:232:
world] Error 2


koen@roemer:~/firmware/builds/generic_dr40x9$ uname -a
Linux roemer 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux


koen@roemer:~/firmware/builds/generic_dr40x9$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Koen

___
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: [VOTE] New member proposal: Robimarko (Robert Marko)

2024-01-31 Thread nick


+1

Best
Nick

On 1/30/24 19:15, Christian Marangi (Ansuel) wrote:

Robert is active in OpenWrt since 2017 and with some recent stats, he
has more than 310 commits merged in OpenWrt.
He also have uncounted Reviewed-by tag on various PR and merged commits
and generally helps in everything related to IPQ (ipq806x, ipq40xx and
ipq807x) and some mvebu targets.

He did the conversion of ipq40xx target to DSA and made possible the
introduction of the ipq807x target by sorting all the QSDK downstream
patch and pushing them upstream.

With his help, also the ipq60xx is very close on getting merged and
actually used permitting support of even more device for OpenWrt.

Also he is almost always reachable on IRC openwrt-devel and never had
a problem in coordinating and collaborating with him.

I think Robert is a good addition to our team and would massively help
me (Ansuel) in maintaining each IPQ target and review all the related
PR on github and patchwork.
I would like to add Robert to the OpenWrt committers team.

The vote shall be concluded within 14 days. (13/02/2024)

___
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: [VOTE] commit access for PolynomialDivision (Nick Hainke)

2023-05-16 Thread Nick


Thanks a lot! I am very happy. :)

However, I just discussed with Paul that "until 16" indicates that you 
may still vote on the 16th of May. I recommend waiting until those last 
hours have passed in order to ensure fairness for people who may still 
wish to vote.


Best
Nick

On 5/16/23 08:40, Paul Spooren wrote:

Hi all,

I’m happy to announce that this vote passed and Nick Hainke aka 
PolynomialDivision is now a member of the OpenWrt committer team! 
Congratulations Nick!

Please find the voting results here: https://openwrt.org/voting/2023-04-25

Since I started the vote, I’ll guide him through the onboarding.

Best,
Paul


On 25. Apr 2023, at 19:59, Paul Spooren  wrote:

Hi all,

After talking to Nick directly and asking during the last developer meeting a 
few minutes ago, I’d like to start a vote on granting Nick commit access.

With more than 300 commits in openwrt.git alone plus being a maintainer for 
packages in both packages.git and routing.git, he’s a super nice (and 
important) addition to the OpenWrt community. He’s taking care of core package 
maintenance as well as adding new devices and doing plenty of testing. 
Additionally all interactions I had with him over email and IRC were very 
friendly and I enjoyed the collaboration very much, a view other committers 
share as well.

I think Nick is a good addition to our team. I would like to add Nick to the 
OpenWrt committers team.

Voting is open until 16th of May 2023.

Paul



___
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: Mark lantiq and omap as source only

2023-05-04 Thread Nick



On 5/4/23 17:51, Stijn Segers wrote:

Hi,

Robert Marko  schreef op 3 mei 2023 11:21:32 CEST:

On Wed, 3 May 2023 at 11:08, Nick  wrote:

I would also love to see a release. It is now already delayed more than
a month [0] (actual branching should be happening end of march).
However, I don't have a strong opinion on this. It's sad that lantiq
targets could be dropped. I will also try to fetch me some lantiq device
from somewhere to support fixing the fdb issues and re-adding it back to
23.X or fixing it before the branch.

I would also really like a new release to branch off sooner rather than later,
there has been plenty of time for all targets to stabilize on 5.15.

I fully agree. Seems source-only is the jolt that omap and lantiq need (I know 
the latter is a popular target).

Lots of people pining for 6.1 support in main etc, so let's branch that baby so 
we can move on.

Stijn


I wanted to do some cleanup (removing 5.10 completely) so we can soon 
release:

https://github.com/openwrt/openwrt/pull/12531

However, if we still keep omap and ath25 around without bumping them to 
5.15, build will give warnings in the form of:


/home/nick/openwrt/include/kernel-version.mk:11: *** Missing kernel 
version/hash file for 5.10. Please create 
/home/nick/openwrt/include/kernel-5.10.  Stop.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Mark lantiq and omap as source only

2023-05-03 Thread Nick



On 5/3/23 19:23, Aleksander Bajkowski wrote:


W dniu 03.05.2023 o 19:11, Nick pisze:

On 5/3/23 11:07, Nick wrote:

I will also try to fetch me some lantiq device from somewhere to 
support fixing the fdb issues and re-adding it back to 23.X or 
fixing it before the branch. 
I organized myself now a **FRITZ!Box 7320** and **TP Link TD-W8970**. 
So if anyone wants me to test anything just write me. Meanwhile I 
will also have a look at this issue.



This issue only affects the xrx200 target (gswip driver). AVM 7320 is 
supported by the xway subtarget and has built-in tantos switch.

The TP Link TD-W8970 is a xrx200 target. :)
So we just could have disabled the xrx200 target instead of setting the 
whole target to source only?


I made a mistake, I have a 7330. However, I have also some network 
issues with this device (no connectity to device but a link).


Bests
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Mark lantiq and omap as source only

2023-05-03 Thread Nick


On 5/3/23 11:07, Nick wrote:

I will also try to fetch me some lantiq device from somewhere to 
support fixing the fdb issues and re-adding it back to 23.X or fixing 
it before the branch. 
I organized myself now a **FRITZ!Box 7320** and **TP Link TD-W8970**. So 
if anyone wants me to test anything just write me. Meanwhile I will also 
have a look at this issue.


Bests
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Mark lantiq and omap as source only

2023-05-03 Thread Nick

I would also love to see a release. It is now already delayed more than 
a month [0] (actual branching should be happening end of march). 
However, I don't have a strong opinion on this. It's sad that lantiq 
targets could be dropped. I will also try to fetch me some lantiq device 
from somewhere to support fixing the fdb issues and re-adding it back to 
23.X or fixing it before the branch.


If you branch soon, you could probably also give a talk about the new 
OpenWrt release at Battlemesh v15. ;)


Bests
Nick

[0] - https://openwrt.org/meetings/20230124

On 5/1/23 18:01, Paul Spooren wrote:

Hi all,

I haven’t seen much progress happening regarding bringing the targets lantiq or 
omap to Kernel 5.15. That fact is currently the last blocker for branching 
another release.

Instead of postponing another release I’d like to mark both targets as 
source-only and do the 23.05 branch, starting with a RC0. If either of the two 
targets are fixed within the RC phase, they should be re-added, as discussed 
during the last meeting.

I’d value your feedback.

Sunshine,
Paul
___
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: Mark lantiq and omap as source only

2023-05-03 Thread Nick


On 5/3/23 02:53, Alexander 'lynxis' Couzens wrote:


what are the problems with lantiq 5.15?

There are some issues with the fdb entries:
lantiq_gswip driver (e.g.: gswip 1e108000.switch: port 4 failed to add 
vid 1 to fdb: -22)

Ansuel describes here why this is so bad:
https://github.com/openwrt/openwrt/pull/12515#issuecomment-1531686673

Bests
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] attr: add NLA_S* definitions

2023-03-30 Thread Nick Hainke

NLA_S8 is used by newer hostapd versions. Directly add all NLA_S*
definitions.

Signed-off-by: Nick Hainke 
---
 attr.c |   4 ++
 include/netlink/attr.h | 122 +
 2 files changed, 126 insertions(+)

diff --git a/attr.c b/attr.c
index eae91e5..fd10b25 100644
--- a/attr.c
+++ b/attr.c
@@ -437,6 +437,10 @@ static uint16_t nla_attr_minlen[NLA_TYPE_MAX+1] = {
[NLA_U32]   = sizeof(uint32_t),
[NLA_U64]   = sizeof(uint64_t),
[NLA_STRING]= 1,
+   [NLA_S8]= sizeof(int8_t),
+   [NLA_S16]   = sizeof(int16_t),
+   [NLA_S32]   = sizeof(int32_t),
+   [NLA_S64]   = sizeof(int64_t),
 };
 
 static int validate_nla(struct nlattr *nla, int maxtype,
diff --git a/include/netlink/attr.h b/include/netlink/attr.h
index 3e3047f..28fac87 100644
--- a/include/netlink/attr.h
+++ b/include/netlink/attr.h
@@ -45,6 +45,13 @@ enum {
NLA_FLAG,   /**< Flag */
NLA_MSECS,  /**< Micro seconds (64bit) */
NLA_NESTED, /**< Nested attributes */
+   NLA_NESTED_ARRAY,
+   NLA_NUL_STRING,
+   NLA_BINARY,
+   NLA_S8,
+   NLA_S16,
+   NLA_S32,
+   NLA_S64,
__NLA_TYPE_MAX,
 };
 
@@ -248,6 +255,31 @@ static inline int nla_put_addr(struct nl_msg *msg, int 
attrtype, struct nl_addr
  * @name Integer Attributes
  */
 
+/**
+ * Add 8 bit signed integer attribute to netlink message.
+ * @arg msg Netlink message.
+ * @arg attrtypeAttribute type.
+ * @arg value   Numeric value to store as payload.
+ *
+ * @see nla_put
+ * @return 0 on success or a negative error code.
+ */
+static inline int nla_put_s8(struct nl_msg *msg, int attrtype, int8_t value)
+{
+   return nla_put(msg, attrtype, sizeof(int8_t), );
+}
+
+/**
+ * Return value of 8 bit signed integer attribute.
+ * @arg nla 8 bit integer attribute
+ *
+ * @return Payload as 8 bit integer.
+ */
+static inline int8_t nla_get_s8(struct nlattr *nla)
+{
+   return *(int8_t *) nla_data(nla);
+}
+
 /**
  * Add 8 bit integer attribute to netlink message.
  * @arg msgNetlink message.
@@ -273,6 +305,31 @@ static inline uint8_t nla_get_u8(struct nlattr *nla)
return *(uint8_t *) nla_data(nla);
 }
 
+/**
+ * Add 16 bit signed integer attribute to netlink message.
+ * @arg msg Netlink message.
+ * @arg attrtypeAttribute type.
+ * @arg value   Numeric value to store as payload.
+ *
+ * @see nla_put
+ * @return 0 on success or a negative error code.
+ */
+static inline int nla_put_s16(struct nl_msg *msg, int attrtype, int16_t value)
+{
+   return nla_put(msg, attrtype, sizeof(int16_t), );
+}
+
+/**
+ * Return payload of 16 bit signed integer attribute.
+ * @arg nla 16 bit integer attribute
+ *
+ * @return Payload as 16 bit integer.
+ */
+static inline int16_t nla_get_s16(struct nlattr *nla)
+{
+   return *(int16_t *) nla_data(nla);
+}
+
 /**
  * Add 16 bit integer attribute to netlink message.
  * @arg msgNetlink message.
@@ -348,6 +405,35 @@ static inline uint32_t nla_get_u32(struct nlattr *nla)
return *(uint32_t *) nla_data(nla);
 }
 
+/**
+ * Add 64 bit signed integer attribute to netlink message.
+ * @arg msg Netlink message.
+ * @arg attrtypeAttribute type.
+ * @arg value   Numeric value to store as payload.
+ *
+ * @see nla_put
+ * @return 0 on success or a negative error code.
+ */
+static inline int nla_put_s64(struct nl_msg *msg, int attrtype, int64_t value)
+{
+   return nla_put(msg, attrtype, sizeof(int64_t), );
+}
+
+/**
+ * Return payload of s64 attribute
+ * @arg nla s64 netlink attribute
+ *
+ * @return Payload as 64 bit integer.
+ */
+static inline int64_t nla_get_s64(struct nlattr *nla)
+{
+   int64_t tmp;
+
+   nla_memcpy(, nla, sizeof(tmp));
+
+   return tmp;
+}
+
 /**
  * Add 64 bit integer attribute to netlink message.
  * @arg msgNetlink message.
@@ -638,6 +724,24 @@ static inline size_t nla_strlcpy(char *dst, const struct 
nlattr *nla, size_t dst
NLA_PUT(msg, attrtype, sizeof(type), &__tmp); \
} while(0)
 
+/**
+ * Add 8 bit signed integer attribute to netlink message.
+ * @arg msgNetlink message.
+ * @arg attrtype   Attribute type.
+ * @arg value  Numeric value.
+ */
+#define NLA_PUT_S8(msg, attrtype, value) \
+   NLA_PUT_TYPE(msg, int8_t, attrtype, value)
+
+/**
+ * Add 8 bit signed integer attribute to netlink message.
+ * @arg msgNetlink message.
+ * @arg attrtype   Attribute type.
+ * @arg value  Numeric value.
+ */
+#define NLA_PUT_S8(msg, attrtype, value) \
+   NLA_PUT_TYPE(msg, int8_t, attrtype, value)
+
 /**
  * Add 8 bit integer attribute to netlink message.
  * @arg msgNetlink message.
@@ -647,6 +751,15 @@ static inline size_t nla_strlcpy(char *dst, const struct 
nlattr *nla, size_t

Re: [libnl-tiny PATCH] attr: add NLA_S8

2023-03-30 Thread Nick



On 3/30/23 11:43, Nick wrote:


On 3/19/23 20:25, Hauke Mehrtens wrote:

On 3/15/23 14:37, Nick Hainke wrote:

NLA_S8 is used by newer hostapd versions.

Signed-off-by: Nick Hainke 
---
  attr.c |  1 +
  include/netlink/attr.h | 35 +++
  2 files changed, 36 insertions(+)

diff --git a/attr.c b/attr.c
index eae91e5..abde67f 100644
--- a/attr.c
+++ b/attr.c
@@ -437,6 +437,7 @@ static uint16_t nla_attr_minlen[NLA_TYPE_MAX+1] = {
  [NLA_U32]    = sizeof(uint32_t),
  [NLA_U64]    = sizeof(uint64_t),
  [NLA_STRING]    = 1,
+    [NLA_S8]    = sizeof(int8_t),
  };
    static int validate_nla(struct nlattr *nla, int maxtype,
diff --git a/include/netlink/attr.h b/include/netlink/attr.h
index 3e3047f..3a5d53d 100644
--- a/include/netlink/attr.h
+++ b/include/netlink/attr.h
@@ -45,6 +45,7 @@ enum {
  NLA_FLAG,    /**< Flag */
  NLA_MSECS,    /**< Micro seconds (64bit) */
  NLA_NESTED,    /**< Nested attributes */
+    NLA_S8,
  __NLA_TYPE_MAX,
  };


I think this has to match the kernel definitions of the same enum.
https://elixir.bootlin.com/linux/v6.1.20/source/include/net/netlink.h#L178 




So I have to add all enum types?

libnl is also not having all types:
https://github.com/thom311/libnl/blob/main/include/netlink/attr.h#L33-L51

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [libnl-tiny PATCH] attr: add NLA_S8

2023-03-30 Thread Nick



On 3/19/23 20:25, Hauke Mehrtens wrote:

On 3/15/23 14:37, Nick Hainke wrote:

NLA_S8 is used by newer hostapd versions.

Signed-off-by: Nick Hainke 
---
  attr.c |  1 +
  include/netlink/attr.h | 35 +++
  2 files changed, 36 insertions(+)

diff --git a/attr.c b/attr.c
index eae91e5..abde67f 100644
--- a/attr.c
+++ b/attr.c
@@ -437,6 +437,7 @@ static uint16_t nla_attr_minlen[NLA_TYPE_MAX+1] = {
  [NLA_U32]    = sizeof(uint32_t),
  [NLA_U64]    = sizeof(uint64_t),
  [NLA_STRING]    = 1,
+    [NLA_S8]    = sizeof(int8_t),
  };
    static int validate_nla(struct nlattr *nla, int maxtype,
diff --git a/include/netlink/attr.h b/include/netlink/attr.h
index 3e3047f..3a5d53d 100644
--- a/include/netlink/attr.h
+++ b/include/netlink/attr.h
@@ -45,6 +45,7 @@ enum {
  NLA_FLAG,    /**< Flag */
  NLA_MSECS,    /**< Micro seconds (64bit) */
  NLA_NESTED,    /**< Nested attributes */
+    NLA_S8,
  __NLA_TYPE_MAX,
  };


I think this has to match the kernel definitions of the same enum.
https://elixir.bootlin.com/linux/v6.1.20/source/include/net/netlink.h#L178 




So I have to add all enum types?

Please add the other definitions added in this commit too:
https://github.com/thom311/libnl/commit/6263a11bfcd033a88583faa719d3911850f0c4f5 



I think you should also add all the nla_put_s* and nla_get_s* 
definitions for s8, s16, s32 and s64. libnl-tiny adds them to the 
header only so they do not make the binary bigger when they are not used.

I can add them.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] attr: add NLA_S8

2023-03-15 Thread Nick


On 3/15/23 07:30, Christian Marangi wrote:


On Wed, Mar 15, 2023 at 02:37:43PM +0100, Nick Hainke wrote:

NLA_S8 is used by newer hostapd versions.

Signed-off-by: Nick Hainke 

What is the target project of this patch?


libnl-tiny


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] attr: add NLA_S8

2023-03-15 Thread Nick Hainke

NLA_S8 is used by newer hostapd versions.

Signed-off-by: Nick Hainke 
---
 attr.c |  1 +
 include/netlink/attr.h | 35 +++
 2 files changed, 36 insertions(+)

diff --git a/attr.c b/attr.c
index eae91e5..abde67f 100644
--- a/attr.c
+++ b/attr.c
@@ -437,6 +437,7 @@ static uint16_t nla_attr_minlen[NLA_TYPE_MAX+1] = {
[NLA_U32]   = sizeof(uint32_t),
[NLA_U64]   = sizeof(uint64_t),
[NLA_STRING]= 1,
+   [NLA_S8]= sizeof(int8_t),
 };
 
 static int validate_nla(struct nlattr *nla, int maxtype,
diff --git a/include/netlink/attr.h b/include/netlink/attr.h
index 3e3047f..3a5d53d 100644
--- a/include/netlink/attr.h
+++ b/include/netlink/attr.h
@@ -45,6 +45,7 @@ enum {
NLA_FLAG,   /**< Flag */
NLA_MSECS,  /**< Micro seconds (64bit) */
NLA_NESTED, /**< Nested attributes */
+   NLA_S8,
__NLA_TYPE_MAX,
 };
 
@@ -248,6 +249,31 @@ static inline int nla_put_addr(struct nl_msg *msg, int 
attrtype, struct nl_addr
  * @name Integer Attributes
  */
 
+/**
+ * Add 8 bit signed integer attribute to netlink message.
+ * @arg msg Netlink message.
+ * @arg attrtypeAttribute type.
+ * @arg value   Numeric value to store as payload.
+ *
+ * @see nla_put
+ * @return 0 on success or a negative error code.
+ */
+static inline int nla_put_s8(struct nl_msg *msg, int attrtype, int8_t value)
+{
+   return nla_put(msg, attrtype, sizeof(int8_t), );
+}
+
+/**
+ * Return value of 8 bit signed integer attribute.
+ * @arg nla 8 bit integer attribute
+ *
+ * @return Payload as 8 bit integer.
+ */
+static inline int8_t nla_get_s8(const struct nlattr *nla)
+{
+   return *(const int8_t *) nla_data(nla);
+}
+
 /**
  * Add 8 bit integer attribute to netlink message.
  * @arg msgNetlink message.
@@ -638,6 +664,15 @@ static inline size_t nla_strlcpy(char *dst, const struct 
nlattr *nla, size_t dst
NLA_PUT(msg, attrtype, sizeof(type), &__tmp); \
} while(0)
 
+/**
+ * Add 8 bit signed integer attribute to netlink message.
+ * @arg msgNetlink message.
+ * @arg attrtype   Attribute type.
+ * @arg value  Numeric value.
+ */
+#define NLA_PUT_S8(msg, attrtype, value) \
+   NLA_PUT_TYPE(msg, int8_t, attrtype, value)
+
 /**
  * Add 8 bit integer attribute to netlink message.
  * @arg msgNetlink message.
-- 
2.40.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release Goals 23.x?

2023-02-05 Thread Nick


Maybe we could also add rust support to the release:
https://github.com/openwrt/packages/pull/19863

Bests
Nick

On 2/5/23 18:13, Hauke Mehrtens wrote:

On 1/24/23 20:48, Nick wrote:

Hey,
We have testing-support for 5.15 in almost all targets, so we may be 
able to release it shortly [0]? WIP 6.1 support is already underway 
in OpenWrt [1]. We are using GCC 12 as our default compiler 
version[2]. Binutils has been updated to version 2.40. Could we fill 
out the Release Goals page [3]?

It would be great to see a new release.


Hi Nick,

I think nobody wrote down a release goal page yet.
It was discussed here too:
https://openwrt.org/meetings/20221130#next_release_23xx
https://openwrt.org/meetings/20230124#next_release_23xx


There are still some open topic for the next release, but it looks 
good for me.

* make remaining targets use kernel 5.15 by default:
** rampis: Fix problems
** lantoq: Fix DSA driver
** Fix some other problems with other targets.
* Add OpenSSL 3.0
* Merge risc-v support

I assume that we will be ready in about 2 months with these tasks and 
can create the release branch.


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: Release Goals 23.x?

2023-01-24 Thread Nick

As far as I know, device support can be backported from master into the 
release branch. So you are able to add the device support if a release 
already happened.


Bests
Nick

On 1/24/23 20:56, Peter Naulls wrote:

On 1/24/23 14:48, Nick wrote:

Hey,
We have testing-support for 5.15 in almost all targets, so we may be 
able to release it shortly [0]? WIP 6.1 support is already underway 
in OpenWrt [1]. We are using GCC 12 as our default compiler 
version[2]. Binutils has been updated to version 2.40. Could we fill 
out the Release Goals page [3]?

It would be great to see a new release.



I guess an actual release here is a few months off, and I don't know
anything about the state of 23.x, but I have 2 mt7621 platforms that I 
should
try and get included sooner rather than later, and probably a 3rd in a 
few

months.







___
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

Release Goals 23.x?

2023-01-24 Thread Nick


Hey,
We have testing-support for 5.15 in almost all targets, so we may be 
able to release it shortly [0]? WIP 6.1 support is already underway in 
OpenWrt [1]. We are using GCC 12 as our default compiler version[2]. 
Binutils has been updated to version 2.40. Could we fill out the Release 
Goals page [3]?

It would be great to see a new release.

Bests
Nick

[0] - https://github.com/openwrt/openwrt/issues/10672
[1] - https://github.com/openwrt/openwrt/pull/11011
[2] - 
https://github.com/openwrt/openwrt/commit/d9de5252a44e208cecaa1e2edad3d1615b84302c

[3] - https://openwrt.org/docs/guide-developer/releases/goals/23.xx


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Upstreaming mac80211 patches?

2022-12-14 Thread Nick

Lately, I had to look at some mac80211 patches and I did not understand 
why some patches are still present or not upstreamed. What about 
upstreaming some of the mac80211 patches or removing some?
For example "120-cfg80211_allow_perm_addr_change.patch" from 2014 I did 
not find it on typical mailinglist 
(https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/subsys/120-cfg80211_allow_perm_addr_change.patch)?
For ath9k we have 28 patches. Some of them are only for changing 
"channel bandwidth to 5/10" (so not 20 or 40 bw included). I guess that 
is legacy? 
https://github.com/openwrt/openwrt/commit/9f38d4402bede0c35bb8f4814e577dc0b0a2f184
And some were rejected upstream 
(https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath9k/354-ath9k-force-rx_clear-when-disabling-rx.patch):

https://patchwork.kernel.org/project/linux-wireless/patch/20180723160300.58024-3-...@nbd.name/

These are just some examples. However, I think it would be beneficial to 
get closer to upstream mac80211 again?


Bests
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] netifd: add accept_ra support

2022-10-09 Thread Nick Hainke

Make the "Accept Router Advertisements" configurable. This is needed if
you do not want to use odhcp6c and let the kernel handle the RAs. This
can save some diskspace.

Possible values are:
  0: Do not accept RA
  1: Accept RA if forwarding is disabled
  2: Accept RA even if forwarding is enabled

Signed-off-by: Nick Hainke 
---
 device.c   |  9 +
 device.h   |  3 +++
 system-linux.c | 20 
 3 files changed, 32 insertions(+)

diff --git a/device.c b/device.c
index b3d0e85..88a192f 100644
--- a/device.c
+++ b/device.c
@@ -63,6 +63,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_AUTH] = { .name = "auth", .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_SPEED] = { .name = "speed", .type = BLOBMSG_TYPE_INT32 },
[DEV_ATTR_DUPLEX] = { .name = "duplex", .type = BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_ACCEPT_RA] = { .name = "accept_ra", .type = 
BLOBMSG_TYPE_INT32 },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -280,6 +281,7 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
n->auth = s->flags & DEV_OPT_AUTH ? s->auth : os->auth;
n->speed = s->flags & DEV_OPT_SPEED ? s->speed : os->speed;
n->duplex = s->flags & DEV_OPT_DUPLEX ? s->duplex : os->duplex;
+   n->accept_ra = s->flags & DEV_OPT_ACCEPT_RA ? s->accept_ra : 
os->accept_ra;
n->flags = s->flags | os->flags | os->valid_flags;
 }
 
@@ -464,6 +466,11 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s->flags |= DEV_OPT_DUPLEX;
}
 
+   if ((cur = tb[DEV_ATTR_ACCEPT_RA])) {
+   s->accept_ra = blobmsg_get_u32(cur);
+   s->flags |= DEV_OPT_ACCEPT_RA;
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -1210,6 +1217,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u8(b, "arp_accept", st.arp_accept);
if (st.flags & DEV_OPT_AUTH)
blobmsg_add_u8(b, "auth", st.auth);
+   if (st.flags & DEV_OPT_ACCEPT_RA)
+   blobmsg_add_u32(b, "accept_ra", st.accept_ra);
}
 
s = blobmsg_open_table(b, "statistics");
diff --git a/device.h b/device.h
index 37f8c37..dc0d57b 100644
--- a/device.h
+++ b/device.h
@@ -62,6 +62,7 @@ enum {
DEV_ATTR_AUTH,
DEV_ATTR_SPEED,
DEV_ATTR_DUPLEX,
+   DEV_ATTR_ACCEPT_RA,
__DEV_ATTR_MAX,
 };
 
@@ -126,6 +127,7 @@ enum {
DEV_OPT_ARP_ACCEPT  = (1ULL << 29),
DEV_OPT_SPEED   = (1ULL << 30),
DEV_OPT_DUPLEX  = (1ULL << 31),
+   DEV_OPT_ACCEPT_RA   = (1ULL << 32),
 };
 
 /* events broadcasted to all users of a device */
@@ -203,6 +205,7 @@ struct device_settings {
bool auth;
unsigned int speed;
bool duplex;
+   unsigned int accept_ra;
 };
 
 /*
diff --git a/system-linux.c b/system-linux.c
index 0f13a99..1697f1f 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -390,6 +390,11 @@ static void system_set_acceptlocal(struct device *dev, 
const char *val)
system_set_dev_sysctl("ipv4/conf", "accept_local", dev->ifname, val);
 }
 
+static void system_set_accept_ra(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl("ipv6/conf", "accept_ra", dev->ifname, val);
+}
+
 static void system_set_igmpversion(struct device *dev, const char *val)
 {
system_set_dev_sysctl("ipv4/conf", "force_igmp_version", dev->ifname, 
val);
@@ -621,6 +626,12 @@ static int system_get_arp_accept(struct device *dev, char 
*buf, const size_t buf
dev->ifname, buf, buf_sz);
 }
 
+static int system_get_accept_ra(struct device *dev, char *buf, const size_t 
buf_sz)
+{
+   return system_get_dev_sysctl("ipv6/conf", "accept_ra",
+dev->ifname, buf, buf_sz);
+}
+
 /* Evaluate netlink messages */
 static int cb_rtnl_event(struct nl_msg *msg, void *arg)
 {
@@ -1795,6 +1806,11 @@ system_if_get_settings(struct device *dev, struct 
device_settings *s)
s->arp_accept = strtoul(buf, NULL, 0);
s->flags |= DEV_OPT_ARP_ACCEPT;
}
+
+   if (!system_get_accept_ra(dev, buf, sizeof(buf))) {
+   s->accept_ra = strtoul(buf, NULL, 0);
+   s->flags |= DEV_OPT_ACCEPT_RA;
+   }
 }
 
 void
@@ -1881,6 +1897,10 @@ system_if_apply_settings(struct device *dev, struct 
device_settings *s, uint64_t
!s->multicast ? IFF_MULTICAST : 0) < 0)
s->flags &= ~DEV_OPT_MULTICAST

Re: iperf3/libiperf3 build issue

2022-09-14 Thread Nick


Sorry, I did a typo when creating the PR. Fixed with:
https://github.com/openwrt/packages/pull/19368

Bests
Nick

On 9/14/22 17:12, e9hack wrote:

Hi,

commit "ae48be8e2157bc7c352b3b6d30c026fafdae4867 / iperf3: add shared 
libiperf library and link iperf3 dynamically" is wrong. The install 
rule for libiperf3 overrides the rule for iperf3. Iperf3 itself will 
not be installed.


diff --git a/net/iperf3/Makefile b/net/iperf3/Makefile
index db3b6e432..a5f465f99 100644
--- a/net/iperf3/Makefile
+++ b/net/iperf3/Makefile
@@ -97,7 +97,7 @@ define Package/iperf3-ssl/install
 $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/iperf3 $(1)/usr/bin/
 endef

-define Package/iperf3/install
+define Package/libiperf3/install
 $(INSTALL_DIR) $(1)/usr/lib
 $(CP) $(PKG_INSTALL_DIR)/usr/lib/libiperf.so.* $(1)/usr/lib
 endef

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

[RFC] Copy Upstream-Status from openembedded

2022-09-02 Thread Nick

As written on openembedded.org: "In order to keep track of patches and 
ultimately reduce the number of patches that are required to be 
maintained, we need to track the status of the patches that are 
created." They do this by introducing Upstream-Status: [STATUS] [WHERE]. 
Here is an example:


  grub2: Fix CVE-2015-8370

  Back to 28; Grub2 Authentication

  Two functions suffer from integer underflow fault; the 
grub_username_get() and grub_password_get()located in
  grub-core/normal/auth.c and lib/crypto.c respectively. This can be 
exploited to obtain a Grub rescue shell.


  Upstream-Status: Accepted 
[http://git.savannah.gnu.org/cgit/grub.git/commit/?id=451d80e52d851432e109771bb8febafca7a5f1f2]

  CVE: CVE-2015-8370
  Signed-off-by: Joe Developer 

The wiki describes this very detailed:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status

We already have some kind of upstream status, by looking at the patch 
number 
(https://openwrt.org/docs/guide-developer/toolchain/use-patches-with-buildsystem#naming_patches):

  0xx - upstream backports
  1xx - code awaiting upstream merge

However, I see there a huge benefit having the upstream status with a 
link to a mailinglist in the patch header.

What do you think?

Bests
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] tplink-safeloader: add optional extra header for support-list

2022-08-17 Thread Nick French

Some TP-Link OEM firmwares add an extra len 0x18 header immediately
after the normal 0x8 byte parition header to support encrypted
partitions.

This extra header only applies to a subset of partitions.
For our purposes it only applies to the support-list partition.

The first 0x8 bytes are a flag to indicate if the contents are
encrypted or not, and the following 0x10 bytes form part of the
encryption key (used if flag is non-zero). Therefore an un-encrypted
parititon will have a zero-filled extra 0x18 bytes of header.

Add support to write this extra header for support-list partitions.

Note: currently only seen in the TP-Link Deco S4R v2, whose support
for factory images is only theoretical since all known OEM firmwares
require vendor-signed firmware updates, but that should not stop us
from generting valid factory images.

Signed-off-by: Nick French 
---
 src/tplink-safeloader.c | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index 7f9081d..babdea6 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -87,6 +87,7 @@ struct device_info {
const char *id;
const char *vendor;
const char *support_list;
+   uint32_t support_list_extra_header_len;
enum partition_trail_value part_trail;
struct {
enum soft_ver_type type;
@@ -1595,6 +1596,7 @@ static struct device_info boards[] = {

"{product_name:S4,product_ver:2.0.0,special_id:4A50}\n"

"{product_name:S4,product_ver:2.0.0,special_id:4155}\n"

"{product_name:S4,product_ver:2.0.0,special_id:4B52}\n",
+   .support_list_extra_header_len = 0x18,
.part_trail = 0x00,
.soft_ver = SOFT_VER_DEFAULT,
 
@@ -3029,11 +3031,11 @@ static inline bool meta_partition_should_pad(enum 
partition_trail_value pv)
  * If the `data` pointer is NULL, then the required space is only allocated,
  * otherwise `data_len` bytes will be copied from `data` into the partition
  * entry. */
-static struct image_partition_entry init_meta_partition_entry(
+static struct image_partition_entry 
init_meta_partition_entry_with_extra_header(
const char *name, const void *data, uint32_t data_len,
-   enum partition_trail_value pad_value)
+   enum partition_trail_value pad_value, uint32_t extra_header_len)
 {
-   uint32_t total_len = sizeof(struct meta_header) + data_len;
+   uint32_t total_len = sizeof(struct meta_header) + extra_header_len + 
data_len;
if (meta_partition_should_pad(pad_value))
total_len += 1;
 
@@ -3049,8 +3051,10 @@ static struct image_partition_entry 
init_meta_partition_entry(
header->length = htonl(data_len);
header->zero = 0;
 
-   if (data)
-   memcpy(entry.data+sizeof(*header), data, data_len);
+   if (data) {
+   memset(entry.data+sizeof(*header),0,extra_header_len);
+   memcpy(entry.data+sizeof(*header)+extra_header_len, data, 
data_len);
+   }
 
if (meta_partition_should_pad(pad_value))
entry.data[total_len - 1] = (uint8_t) pad_value;
@@ -3058,6 +3062,14 @@ static struct image_partition_entry 
init_meta_partition_entry(
return entry;
 }
 
+static struct image_partition_entry init_meta_partition_entry(
+const char *name, const void *data, uint32_t data_len,
+enum partition_trail_value pad_value)
+{
+   static const uint32_t NO_EXTRA_HEADER = 0;
+   return init_meta_partition_entry_with_extra_header(name, data, 
data_len, pad_value, NO_EXTRA_HEADER);
+}
+
 /** Allocates a new image partition */
 static struct image_partition_entry alloc_image_partition(const char *name, 
size_t len) {
struct image_partition_entry entry = {name, len, malloc(len)};
@@ -3191,8 +3203,9 @@ static struct image_partition_entry make_support_list(
const struct device_info *info)
 {
uint32_t len = strlen(info->support_list);
-   return init_meta_partition_entry(info->partition_names.support_list, 
info->support_list,
-   len, info->part_trail);
+
+   return 
init_meta_partition_entry_with_extra_header(info->partition_names.support_list, 
info->support_list,
+   len, info->part_trail, info->support_list_extra_header_len);
 }
 
 /** Partition with extra-para data */
-- 
2.37.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] tplink-safeloader: add TP-Link Deco S4 v2 support

2022-08-14 Thread Nick French

On Sun, Aug 14, 2022 at 08:04:01AM +0200, Sander Vanheule wrote:
> Hi,
> 
> On Sat, 2022-08-13 at 13:51 -0500, Nick French wrote:
> > Support creating images for TP-Link Deco S4R v2.
> > 
> > Original partition layout from OEM image:
> >  partition fs-uboot base 0x0 size 0x8
> >  partition product-info base 0x8 size 0x05000
> >  partition default-mac base 0x85000 size 0x01000
> >  partition device-id base 0x86000 size 0x01000
> >  partition support-list base 0x87000 size 0x1
> >  partition user-config base 0xa7000 size 0x1
> >  partition device-config base 0xb7000 size 0x1
> >  partition group-info base 0xc7000 size 0x1
> >  partition partition-table base 0xd7000 size 0x02000
> >  partition soft-version base 0xd9000 size 0x1
> >  partition profile base 0xe9000 size 0x1
> >  partition default-config base 0xf9000 size 0x1
> >  partition url-sig base 0x1e size 0x1
> >  partition radio base 0x1f size 0x1
> >  partition os-image base 0x20 size 0x20
> >  partition file-system base 0x40 size 0xc0
> > 
> > The 'os-image' and 'file-system' partitions were merged into 'firmware'
> > to make use of the automatic mtd split.
> > 
> > Signed-off-by: Nick French 
> > ---
> >  src/tplink-safeloader.c | 43 +
> >  1 file changed, 43 insertions(+)
> > 
> > diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
> > index 7a31ac2..7f9081d 100644
> > --- a/src/tplink-safeloader.c
> > +++ b/src/tplink-safeloader.c
> > @@ -1577,6 +1577,49 @@ static struct device_info boards[] = {
> > .last_sysupgrade_partition = "file-system",
> > },
> >  
> > +   /** Firmware layout for the Deco S4 v2 */
> > +   {
> > +   .id = "DECO-S4-V2",
> > +   .vendor = "",
> > +   .support_list =
> > +   "SupportList:\n"
> > +   
> > "{product_name:S4,product_ver:1.0.0,special_id:5553000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:1.0.0,special_id:4555000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:1.0.0,special_id:4341000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:1.0.0,special_id:4A5
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:1.0.0,special_id:4155000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:1.0.0,special_id:4B52000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:2.0.0,special_id:5553000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:2.0.0,special_id:4555000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:2.0.0,special_id:4341000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:2.0.0,special_id:4A5
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:2.0.0,special_id:4155000
> > 0}\n"
> > +   
> > "{product_name:S4,product_ver:2.0.0,special_id:4B52000
> > 0}\n",
> 
> Looking at the FW images that can be downloaded from TP-Link's website, the
> support-list partition appears to be a binary blob instead of a plaintext 
> table.
> Any idea what's going on here?
> 
> Best,
> Sander
> 

Yes, the firmware implements an encryption scheme for several
of the config partitions.

Decryption was reverse engineered and a tool was submitted separately
via github: https://github.com/openwrt/openwrt/pull/10445
(tools: deco-decrypt: add package to decrypt Deco S4 config)

As an example use of the tool, you can run it on the firmware file
directly such as:

$ deco_decrypt S4_1.5.1.bin $((0x1014 + 0x1000)) $((0x2d1))
SupportList:
{product_name:S4,product_ver:1.0.0,special_id:5553}
{product_name:S4,product_ver:1.0.0,special_id:4555}
{product_name:S4,product_ver:1.0.0,special_id:4341}
{product_name:S4,product_ver:1.0.0,special_id:4A50}
{product_name:S4,product_ver:1.0.0,special_id:4155}
{product_name:S4,product_ver:1.0.0,special_id:4B52}
{product_name:S4,product_ver:2.0.0,special_id:5553}
{product_name:S4,product_ver:2.0.0,special_id:4555}
{product_name:S4,product_ver:2.0.0,special_id:4341}
{product_name:S4,product_ver:2.0.0,special_id:4A50}
{product_name:S4,

[PATCH] tplink-safeloader: add TP-Link Deco S4 v2 support

2022-08-13 Thread Nick French

Support creating images for TP-Link Deco S4R v2.

Original partition layout from OEM image:
 partition fs-uboot base 0x0 size 0x8
 partition product-info base 0x8 size 0x05000
 partition default-mac base 0x85000 size 0x01000
 partition device-id base 0x86000 size 0x01000
 partition support-list base 0x87000 size 0x1
 partition user-config base 0xa7000 size 0x1
 partition device-config base 0xb7000 size 0x1
 partition group-info base 0xc7000 size 0x1
 partition partition-table base 0xd7000 size 0x02000
 partition soft-version base 0xd9000 size 0x1
 partition profile base 0xe9000 size 0x1
 partition default-config base 0xf9000 size 0x1
 partition url-sig base 0x1e size 0x1
 partition radio base 0x1f size 0x1
 partition os-image base 0x20 size 0x20
 partition file-system base 0x40 size 0xc0

The 'os-image' and 'file-system' partitions were merged into 'firmware'
to make use of the automatic mtd split.

Signed-off-by: Nick French 
---
 src/tplink-safeloader.c | 43 +
 1 file changed, 43 insertions(+)

diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index 7a31ac2..7f9081d 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -1577,6 +1577,49 @@ static struct device_info boards[] = {
.last_sysupgrade_partition = "file-system",
},
 
+   /** Firmware layout for the Deco S4 v2 */
+   {
+   .id = "DECO-S4-V2",
+   .vendor = "",
+   .support_list =
+   "SupportList:\n"
+   
"{product_name:S4,product_ver:1.0.0,special_id:5553}\n"
+   
"{product_name:S4,product_ver:1.0.0,special_id:4555}\n"
+   
"{product_name:S4,product_ver:1.0.0,special_id:4341}\n"
+   
"{product_name:S4,product_ver:1.0.0,special_id:4A50}\n"
+   
"{product_name:S4,product_ver:1.0.0,special_id:4155}\n"
+   
"{product_name:S4,product_ver:1.0.0,special_id:4B52}\n"
+   
"{product_name:S4,product_ver:2.0.0,special_id:5553}\n"
+   
"{product_name:S4,product_ver:2.0.0,special_id:4555}\n"
+   
"{product_name:S4,product_ver:2.0.0,special_id:4341}\n"
+   
"{product_name:S4,product_ver:2.0.0,special_id:4A50}\n"
+   
"{product_name:S4,product_ver:2.0.0,special_id:4155}\n"
+   
"{product_name:S4,product_ver:2.0.0,special_id:4B52}\n",
+   .part_trail = 0x00,
+   .soft_ver = SOFT_VER_DEFAULT,
+
+   .partitions = {
+   {"fs-uboot", 0x0, 0x8},
+   {"product-info", 0x8, 0x05000},
+   {"default-mac", 0x85000, 0x01000},
+   {"device-id", 0x86000, 0x01000},
+   {"support-list", 0x87000, 0x1},
+   {"user-config", 0xa7000, 0x1},
+   {"device-config", 0xb7000, 0x1},
+   {"group-info", 0xc7000, 0x1},
+   {"partition-table", 0xd7000, 0x02000},
+   {"soft-version", 0xd9000, 0x1},
+   {"profile", 0xe9000, 0x1},
+   {"default-config", 0xf9000, 0x1},
+   {"url-sig", 0x1e, 0x1},
+   {"radio", 0x1f, 0x1},
+   {"firmware", 0x20, 0xe0},
+   {NULL, 0, 0}
+   },
+   .first_sysupgrade_partition = "os-image",
+   .last_sysupgrade_partition = "file-system",
+   },
+
/** Firmware layout for the EAP120 */
{
.id = "EAP120",
-- 
2.37.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] hostapd: fix segfault sending bss transition mgmt response on ubus

2022-07-31 Thread Nick


It was not cherry-picked to 21.02:
https://github.com/openwrt/openwrt/pull/10363

Bests
Nick

On 7/31/22 19:35, Hauke Mehrtens wrote:

On 7/24/22 15:28, Sakura Industries wrote:
In the ubus support patch for bss transition management responses, 
the target_bssid variable is left uninitialized if the client refuses 
to transition for any reason.  This leads to random segfaults in 
hostapd when it marshals the ubus message, because it de-references 
this uninitialized pointer to build the message.


There is no target_bssid for any response other than accept, so the 
patch just sets the variable to NULL.  The ubus code properly handles 
that case.  This issue is only noticable if one is using a band 
steering agent like dawn.


Signed-off-by: Steven Johnson 

---

diff --git 
a/package/network/services/hostapd/patches/600-ubus_support.patch 
b/package/network/services/hostapd/patches/600-ubus_support.patch

index 4abb6887f6..737fa2ff61 100644
--- a/package/network/services/hostapd/patches/600-ubus_support.patch
+++ b/package/network/services/hostapd/patches/600-ubus_support.patch
@@ -552,8 +552,9 @@
 sta->agreed_to_steer = 1;
eloop_cancel_timeout(ap_sta_reset_steer_flag_timer, hapd, sta);
 eloop_register_timeout(2, 0, 
ap_sta_reset_steer_flag_timer,

-@@ -530,6 +532,10 @@ static void ieee802_11_rx_bss_trans_mgmt
+@@ -530,6 +532,11 @@ static void ieee802_11_rx_bss_trans_mgmt
 MAC2STR(addr), status_code, 
bss_termination_delay);

++  target_bssid = NULL;
 }

  +  hostapd_ubus_notify_bss_transition_response(hapd, sta->addr, 
dialog_token,


The problem was already fixed some months ago here:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=9b880f09f394049e0629e3c9d4061f431a6b19a8 



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: [PATCH] netifd: fix WPA3 enterprise ciphers

2022-06-26 Thread Nick Lowe

Hi Joerg,

Where is this stated?

If I check the following Cisco link, this is not constrained in this
way on their products:

https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9100ax-access-points/wpa3-dep-guide-og.html

If I check the Wi-Fi alliance spec at
https://www.wi-fi.org/file/wpa3-specification , this states the
following, and a requirement for GCMP does not appear to be mentioned:

3
WPA3-Enterprise
WPA3-Enterprise applies to enterprise network settings.

3.1
Modes of operation
WPA3-Enterprise modes are defined as follows:
• WPA3-Enterprise only mode
• WPA3-Enterprise transition mode
• WPA3-Enterprise 192-bit mode

3.2
WPA3-Enterprise only mode
When operating in WPA3-Enterprise only mode:
• An AP shall enable at least AKM suite selector 00-0F-AC:5 (IEEE
802.1X with SHA-256) in the BSS
• A STA shall allow at least AKM suite selector 00-0F-AC:5 to be
selected for an association
• An AP shall not enable AKM suite selector: 00-0F-AC:1 (IEEE 802.1X with SHA-1)
• A STA shall not allow AKM suite selector 00-0F-AC:1 to be selected
for an association
• An AP shall set MFPC to 1, MFPR to 1
• A STA shall set MFPC to 1, MFPR to 1
• A STA shall not enable WEP and TKIP

3.3
WPA3-Enterprise transition mode
When operating in WPA3-Enterprise transition mode:
• An AP shall enable at least AKM suite selectors 00-0F-AC:1 (IEEE
802.1X with SHA-1) and 00-0F-AC:5 (IEEE 802.1X with SHA-256) in the
BSS
• A STA shall allow at least AKM suite selectors 00-0F-AC:1 and
00-0F-AC:5 to be selected for an association
• An AP shall set MFPC to 1, MFPR to 0
• A STA shall set MFPC to 1, MFPR to 0

3.4
Additional Requirements on WPA3-Enterprise modes
The following additional requirements apply to all WPA3-Enterprise modes:
1. An AP shall not enable WPA version 1 on the same BSS with WPA3-Enterprise
2. An AP shall not enable WEP and TKIP on the same BSS as WPA3-Enterprise

3.5
WPA3-Enterprise 192-bit mode
WPA3-Enterprise 192-bit mode is well suited for deployments in
sensitive enterprise environments to further protect Wi- Fi® networks
with higher security requirements such as government, defense, and
industrial.
When operating in WPA3-Enterprise 192-bit mode:
1. When WPA3-Enterprise 192-bit mode is used by an AP, PMF shall be
set to required (MFPR bit in the RSN Capabilities field shall be set
to 1 in the RSNE transmitted by the AP).
2. When WPA3-Enterprise 192-bit mode is used by a STA, PMF shall be
set to required (MFPR bit in the RSN Capabilities field shall be set
to 1 in the RSNE transmitted by the STA).
3. Permitted EAP cipher suites for use with WPA3-Enterprise 192-bit mode are:
▪ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- ECDHE and ECDSA using the 384-bit prime modulus curve P-384
▪ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- ECDHE using the 384-bit prime modulus curve P-384
- RSA ≥ 3072-bit modulus
▪ TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- RSA ≥ 3072-bit modulus - DHE ≥ 3072-bit modulus

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 22.0X release plan (22.03)

2022-03-19 Thread Nick

I don't want to spam the mailing list by repeating issues, but there is 
still a serious issue with the ath79 ubnt-xm devices, that they will not 
allow sysupgrade anymore due to OOM-Killer killing sysupgrade.


https://github.com/openwrt/openwrt/pull/4879

Bests,
Nick

On 3/19/22 12:07, Hauke Mehrtens wrote:

On 2/20/22 23:57, Hauke Mehrtens wrote:

Hi,

All the major new features for the next OpenWrt major release are 
mostly merged into master. The kernel 5.10 upgrade for the bcm63xx 
target is still missing.


Paul created a issue to track the remaining tasks:
https://github.com/openwrt/openwrt/issues/9248
This will be extended with new problems.

We plan to do a feature freeze of the master branch on 1. March 2022. 
This means we will not add any big changes any more by that date. 
Minor changes like adding support for new boards or adding a new 
package are still ok, big changes like activating SELinux by default 
would not be oḱ.


Around 20. March 2022 we plan to branch off the next major release 
and would prepare for a first release candidate about 1 week later.


Hauke


Hi,

We would like to branch off OpenWrt 22.03 as openwrt-21.03 tomorrow.
We would also like to create branches on the default feeds too.

Petr will set up the new build bot instance together with Paul and we 
would like to do an 22.03.0-rc1 soon when the build bot infrastructure 
is working fine.


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: [PATCH 19.07] feeds.conf.default: remove freifunk feed

2022-02-28 Thread Nick


On 2/28/22 10:04, Paul Spooren wrote:


Anyway, if the Freifunk community itself finds it to be useless, let’s drop it.
I don't think it's useless to combine Freifunk and OpenWrt. I don't know 
why people pulled for example the freifunk luci mod out of OpenWrt Luci 
Feed. Now we don't benefit anymore from tree-wide changes. I had a hard 
time converting the mod to 19.07 and then 21.02 (thanks a lot to jow who 
supported me). From my side of view, we lack maintainer power, to allow 
us to follow each tree-wide change and apply them. However, I think 
OpenWrt especially benefits from all Freifunk-Communities, since we do 
maintenance, testing, and development. For example I am part of Freifunk 
Berlin (however, we have 3(?) different "firmwares" right now).
Freifunk communities often rely on the "openwrt routing feed". In my 
view, it consists only of two real active maintenance (mwarning and me 
and maybe some more). Now thankfully BKPepe and neheb help to maintain 
the feed and get it into a good-looking shape. There is a lot of power 
in the community package repository. Somehow more and more stuff is 
maintained from my side I never planned to do so. For example, I 
currently maintain OLSR. I would be very happy if we could upstream 
again more wireless community mesh-specific packages to OpenWrt and get 
more help with maintenance. So that in the end, more resources are free 
to develop and test more.
Some people in Berlin switched to an "ansiblification" of the most 
important backbone places in our network, that completely builds on 
normal OpenWrt [0] utilizing the image builders. So at least some 
Freifunk don't use their own make system modification. I always argue to 
make things more generalized so all people using OpenWrt can benefit 
from it, and we don't have to write the same code (or even maintain the 
same packages) multiple times, e.g. tunneldigger.


Overall, instead of maintaining a separate feed for Freifunk where we 
also have to maintain the CIs and so on, I would argue for more packages 
in openwrt/packages and openwrt/luci. It is not about all the "uci 
config defaults" that are in the Freifunk repository. In my view, we 
need to just generate default configs differently, like we already do in 
ansible and feed them into the imagebuilder. It is about packages that 
have some more functionality, like showing mesh routing protocols on the 
front page, building WireGuard tunnels, etc. ... So remove the Freifunk 
Repository, but let's work/maintain together.


Bests
Nick

[0] - https://github.com/freifunk-berlin/bbb-configs

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 22.0X release plan

2022-02-27 Thread Nick


Sysupgrade is broken on ath79 ubnt-xm, due to oom-killer killing sysupgrade.

We have two options:
1) Finding more processes to kill before doing sysupgrade
2) Move ath79 ubnt-xm to tiny like I did in the PR: 
https://github.com/openwrt/openwrt/pull/4879


Bests
Nick

On 2/20/22 23:57, Hauke Mehrtens wrote:

Hi,

All the major new features for the next OpenWrt major release are 
mostly merged into master. The kernel 5.10 upgrade for the bcm63xx 
target is still missing.


Paul created a issue to track the remaining tasks:
https://github.com/openwrt/openwrt/issues/9248
This will be extended with new problems.

We plan to do a feature freeze of the master branch on 1. March 2022. 
This means we will not add any big changes any more by that date. 
Minor changes like adding support for new boards or adding a new 
package are still ok, big changes like activating SELinux by default 
would not be oḱ.


Around 20. March 2022 we plan to branch off the next major release and 
would prepare for a first release candidate about 1 week later.


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: Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-27 Thread Nick

Is fixed by:
https://github.com/openwrt/openwrt/pull/4882

On 12/25/21 22:02, Nick wrote:

Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.

On 12/25/21 19:46, David Bauer wrote:

Hi Nick,

On 12/25/21 16:49, Nick wrote:
The flash-chip mx25l6405d that is contained in the Ubiquity
Nanostation M5 (XM) is not able to write to the flash with kernel
5.10. Probably, caused by invalid block protection clearing. For
example the logread contains a lot of those messages:

jffs2: Newly-erased block contained word 0x19852003 at offset
0x0025

Can you try to modify "spi_nor_get_sr_tb_mask" to always return 0?

Having a quick look at the code, there is no check if TB and BP3 bit
conflict. Furthermore, the MXIC chip does not seem to have a TB bit
at all.

I could imagine this either writes the wrong value to the register or
does not unlock at all, as it interprets the range of the lock
incorrectly.

Just a assumption, did not have a closer look.

Best
David

I added a patch with the help of blocktrron for the 5.4er kernel
[0]. This patch is not applied in the 5.10er since a lot of rewrites
happened upstream. However, the underlying issue is the missing 4th
block protection bit that was not cleared. In upstream Linux you
typically set SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_B for that kind of
flash chips in drivers/mtd/spi-nor/macronix.c [1]. I added this for
the mx25l6405d, but it did not help. I also tried to backport the
("mtd: spi-nor: keep lock bits if they are non-volatile") fix and
setting "CONFIG_MTD_SPI_NOR_SWP_DISABLE", but it also did not help.
Did I miss something?

[0] -
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b

[1] -
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e

[2] -
https://gist.github.com/PolynomialDivision/0c420c6bfcfd681cffa7aac9f346d262
[3] -
https://github.com/PolynomialDivision/openwrt/blob/984f1c84e8d087a9fa0117d5502b8e19a2a35b98/target/linux/generic/backport-5.10/409-v5.11-mtd-spi-nor-keep-lock-bits-if-they-are-non-volatile.patch

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-26 Thread Nick

I think I fixed it accidentally by this PR:
https://github.com/openwrt/openwrt/pull/4879

The flash memory is not enough anymore using 5.10. I would be happy if
it could be merged, soon. Otherwise ubnt-xm targets are broken in master.

Bests
Nick

On 12/25/21 22:02, Nick wrote:

Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.

On 12/25/21 19:46, David Bauer wrote:

Hi Nick,

jffs2: Newly-erased block contained word 0x19852003 at offset
0x0025

Can you try to modify "spi_nor_get_sr_tb_mask" to always return 0?

Having a quick look at the code, there is no check if TB and BP3 bit
conflict. Furthermore, the MXIC chip does not seem to have a TB bit
at all.

I could imagine this either writes the wrong value to the register or
does not unlock at all, as it interprets the range of the lock
incorrectly.

Just a assumption, did not have a closer look.

Best
David

[0] -
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b

[1] -
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-25 Thread Nick

Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.

On 12/25/21 19:46, David Bauer wrote:

Hi Nick,

jffs2: Newly-erased block contained word 0x19852003 at offset
0x0025

Can you try to modify "spi_nor_get_sr_tb_mask" to always return 0?

Having a quick look at the code, there is no check if TB and BP3 bit
conflict. Furthermore, the MXIC chip does not seem to have a TB bit at
all.

I could imagine this either writes the wrong value to the register or
does not unlock at all, as it interprets the range of the lock
incorrectly.

Just a assumption, did not have a closer look.

Best
David

I added a patch with the help of blocktrron for the 5.4er kernel [0].
This patch is not applied in the 5.10er since a lot of rewrites
happened upstream. However, the underlying issue is the missing 4th
block protection bit that was not cleared. In upstream Linux you
typically set SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_B for that kind of
flash chips in drivers/mtd/spi-nor/macronix.c [1]. I added this for
the mx25l6405d, but it did not help. I also tried to backport the
("mtd: spi-nor: keep lock bits if they are non-volatile") fix and
setting "CONFIG_MTD_SPI_NOR_SWP_DISABLE", but it also did not help.
Did I miss something?

[0] -
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b

[1] -
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Macronix Flash-Chip Block Protection Clearing 5.10er

2021-12-25 Thread Nick

The flash-chip mx25l6405d that is contained in the Ubiquity Nanostation 
M5 (XM) is not able to write to the flash with kernel 5.10. Probably, 
caused by invalid block protection clearing. For example the logread 
contains a lot of those messages:


    jffs2: Newly-erased block contained word 0x19852003 at offset 
0x0025


I added a patch with the help of blocktrron for the 5.4er kernel [0]. 
This patch is not applied in the 5.10er since a lot of rewrites happened 
upstream. However, the underlying issue is the missing 4th block 
protection bit that was not cleared. In upstream Linux you typically set 
SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_B for that kind of flash chips in 
drivers/mtd/spi-nor/macronix.c [1]. I added this for the mx25l6405d, but 
it did not help. I also tried to backport the ("mtd: spi-nor: keep lock 
bits if they are non-volatile") fix and setting 
"CONFIG_MTD_SPI_NOR_SWP_DISABLE", but it also did not help. Did I miss 
something?


[0] - 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b
[1] - 
https://github.com/torvalds/linux/commit/7ea40b54e83baed17d85567cfae56175def39a55#diff-f749d5111926f3afbd8d869c577cb314fb690186ba42a2538a87e5ea7725929e
[2] - 
https://gist.github.com/PolynomialDivision/0c420c6bfcfd681cffa7aac9f346d262
[3] - 
https://github.com/PolynomialDivision/openwrt/blob/984f1c84e8d087a9fa0117d5502b8e19a2a35b98/target/linux/generic/backport-5.10/409-v5.11-mtd-spi-nor-keep-lock-bits-if-they-are-non-volatile.patch



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: hostapd: ubus inteface crashes hostapd?

2021-10-23 Thread Nick


Thanks a lot. However, a user still report that hostapd is crashing:
https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-949558177

Bests
Nick

On 10/21/21 17:13, David Bauer wrote:

Hi Nick,

On 10/21/21 11:31, Nick wrote:
Is someone massively utilizing the ubus interface from hostapd? I'm 
doing this with dawn and I saw that blocktrron already fixed some 
infinity loop. However, currently DAWN is crashing the hostapd. I 
make extensive use of the get_clients, all subscriptions, 
disassoc_immidient calls.


This is most likely caused by my transition-report patch some days ago.

Please check out the latest master. It should be resolved.

Best
David



Of course I don't want to exclude that the error is on my side. I 
just wanted to ask if someone is doing something similar. It is just 
weird for me that dawn can crash hostapd since it is only connecting 
via ubus and uses iwinfo library to get signal strength and channel 
utilization from wifi interfaces.


See:
https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-948192240 



Bests
Nick

___
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

hostapd: ubus inteface crashes hostapd?

2021-10-21 Thread Nick

Is someone massively utilizing the ubus interface from hostapd? I'm 
doing this with dawn and I saw that blocktrron already fixed some 
infinity loop. However, currently DAWN is crashing the hostapd. I make 
extensive use of the get_clients, all subscriptions, disassoc_immidient 
calls.


Of course I don't want to exclude that the error is on my side. I just 
wanted to ask if someone is doing something similar. It is just weird 
for me that dawn can crash hostapd since it is only connecting via ubus 
and uses iwinfo library to get signal strength and channel utilization 
from wifi interfaces.


See:
https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-948192240

Bests
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: handling of blob_buf_free?

2021-10-13 Thread Nick


Does it make a difference in terms of performance to use stack buffers?
I switched now to using stack buffers, since for me it makes the code 
more readable not having to deal with several buffers and possible race 
conditions. (but just my view on the topic)


Thanks a lot for your answer. I will also update the forum post with the 
information! :)


Bests
Nick

On 10/13/21 10:51, Felix Fietkau wrote:

On 2021-10-13 07:53, Nick wrote:

Since I saw there were some new patches, e.g., procd, fixing
blob_buf_free() calls.
I asked several months ago: "Should you call blob_buf_free() after
calling blob_buf_init()?"
https://forum.openwrt.org/t/should-you-call-blob-buf-free-after-calling-blob-buf-init

I did not receive any answer. I think blob_buf_init() is freeing memory
if it is the same buf?
Any suggestions how to use blob_buf_free?

If a buffer was already allocated, blob_buf_init reuses it. You can keep
reusing it as many times as you want. You only need to call
blob_buf_free if you explicitly want to free the buffer memory (e.g. on
exit, or if the blob_buf is on stack)

- Felix


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: handling of blob_buf_free?

2021-10-13 Thread Nick


As rule of thumb I would say:
- use struct blob_buf b = {0}; in the function as local variable
- free after using it
- use "struct ubus_context *ctx_local" in callback functions to 
differentiate between global ctx pointer and local callback variables


In the examples it is also freed. However, I would move the global 
definitions to local ones?

https://git.openwrt.org/?p=project/libubox.git;a=blob;f=examples/json_script-example.c;h=6d93059a412e3c829c29df1b41c9dece8852499d;hb=HEAD#l10

Bests
Nick

On 10/13/21 07:53, Nick wrote:
Since I saw there were some new patches, e.g., procd, fixing 
blob_buf_free() calls.
I asked several months ago: "Should you call blob_buf_free() after 
calling blob_buf_init()?"
https://forum.openwrt.org/t/should-you-call-blob-buf-free-after-calling-blob-buf-init 



I did not receive any answer. I think blob_buf_init() is freeing 
memory if it is the same buf?

Any suggestions how to use blob_buf_free?

Bests
Nick


___
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

handling of blob_buf_free?

2021-10-13 Thread Nick

Since I saw there were some new patches, e.g., procd, fixing 
blob_buf_free() calls.
I asked several months ago: "Should you call blob_buf_free() after 
calling blob_buf_init()?"

https://forum.openwrt.org/t/should-you-call-blob-buf-free-after-calling-blob-buf-init

I did not receive any answer. I think blob_buf_init() is freeing memory 
if it is the same buf?

Any suggestions how to use blob_buf_free?

Bests
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Edit Own Bug Reports?

2021-10-07 Thread Nick

Why am I now allowed to edit my own bug reports on 
https://bugs.openwrt.org/? (Polynomdivision)
Can someone give me the permission to do so? Why is it not default 
permission for everyone?


Bests
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

2021-09-30 Thread Nick




On 9/30/21 21:43, Daniel Golle wrote:

On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:

On 30/09/2021 01:19, Nick wrote:

On 9/29/21 22:28, Hauke Mehrtens wrote:


kernel 5.10:
We should get all targets to kernel 5.10. All targets which are not
on kernel 5.10 when we branch off should get removed.

Kernel 5.15 could be also a LTS Kernel that should be released in the
end of October? Why not aiming for it if we plan to release in 2022?

This would undoubtedly delay the next release, as we've seen in the
past. We don't even have all targets on 5.10, which was released roughly
9 months ago. You do the math. If we target 5.15, I doubt we'll even see
a release in 2022.

I also believe we should do the next release based on Linux 5.10 and
try branching still this year (which I believe is realistic to make all
targets build with 5.10 till then), so we can target April 2022 as time
of release.

Sounds good, so we can go on with 5.15 when it is released?
I think the most problematic thing is if we want to have DSA support for 
all targets as requirement. Not sure if this is possible.


Bests
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

2021-09-29 Thread Nick


On 9/29/21 22:28, Hauke Mehrtens wrote:


kernel 5.10:
We should get all targets to kernel 5.10. All targets which are not on 
kernel 5.10 when we branch off should get removed.
Kernel 5.15 could be also a LTS Kernel that should be released in the 
end of October? Why not aiming for it if we plan to release in 2022?


Bests
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Help with WiFi Streaming (ie noack) mode.

2021-09-11 Thread Nick Dennis

("WiFi Streaming" is just a more descriptive name for the desired wifi 
behaviour.

The wifi keeps streaming packets without waiting for ACKS/Block ACKs.)

I'm working with ath10k-ct, the boot announceent shows:

[   17.250943] ath10k_pci :00:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043222ff sub :
[   17.260370] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 
tracing 0 dfs 1 testmode 0
[   23.753344] ath10k_pci :00:00.0: firmware ver 
10.1-ct-8x-__fH-022-ecad3248 api 2 features 
wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT 
crc32 1b2a161c


In noack mode, rate control algorithms won't know whether a packet 
transmission was successful or not, so a fixed rate has to be set, 
normally with only 1 try.


So far, I've patched mac80211 and ath10k-ct so that

root@Openwrt:/#iw dev wlan0 set bitrates ht-mcs-5 vht-mcs-5 1:9 2:9 sgi-5

sets a single rate bit in the ath10k_vif bitrate_mask.control[ band 
].vht_mcs[ 0 ]

and

root@Openwrt:/#iw wlan0 set noack_map 0x00ff

sets the ieee80211_tx_info flag IEEE80211_TX_CTL_NO_ACK for data packets.

Also needed a patch to ath10k function ath10k_htt_tx_32 for the fixed 
rate to show in the gui association list

- detect info->flags & IEEE80211_TX_CTL_NO_ACK and
- set the variables pream_type, nss, mcs and num_retries from ath10k_vif
- which then set up txbuf->cmd_tx.peerid.

While running iperf across a link:
- setting the fixed rate causes the throughput to change accordingly
- but setting the noack_map causes
-- the rate shown on the gui to drop from 400 to 173 Mbps
-- packets stop being aggregated.
so the throughput drops from about 200 Mbps to about 80 Mbps

What am i missing?


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

test

2021-09-11 Thread Nick Dennis





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] Revert "initd: fix off-by-one error in mkdev.c"

2021-08-31 Thread Nick

Yep. Thanks. Just added another patch that is fixing the issue. I went 
to some internet sources and code to see how other people handle the 
issue and seems like everyone is just subtracting 1. Now you also wrote 
the same. :)


Bests,
Nick

On 8/31/21 10:59 AM, Felix Fietkau wrote:

On 2021-08-31 10:25, vinc...@systemli.org wrote:

From: Nick Hainke 

This reverts commit 8eb1d783cca6e0d501dd3a2f94262ffc36ae6482.

This line reads a symbolic link into the string buffer "buf".
len = readlink(buf2, buf, sizeof(buf));
The commit replaced now
buf[len] = 0;
with
buf[sizeof(buf) - 1] = '\0';

However, that does not work since readlink does not null-terminate
the string written into "buf" and  "buf[len] = 0" was used for that.

What happens if the buffer is to small?
"If the buf argument is not large enough to contain the link content,
the first bufsize bytes shall be placed in buf."
(Source: https://pubs.opengroup.org/onlinepubs/009695399/functions/readlink.htm)

That revert adds back the original off-by-one error, since len will be
sizeof(buf) in case of an undersized buffer.
I agree that 'buf[len] = 0' is correct, but only if you also use
sizeof(buf)-1 as size argument in the readlink() call.

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02 status

2021-08-29 Thread Nick

+1 for finally releasing. Our wireless mesh community is testing OpenWrt 
21.02-snapshot now for months.

Only some trouble with ipq40xx soc, but we have workarounds for it.

On 8/29/21 12:53 PM, Adrian Schmutzler wrote:

Hi,


-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Hauke Mehrtens
Sent: Sonntag, 29. August 2021 11:54
To: OpenWrt Development List
Cc: John Crispin; Jo-Philipp Wich; Kevin 'ldir' Darbyshire-Bryant
Subject: Re: OpenWrt 21.02 status

Hi,

We did the 21.02-rc4, but there is still a problem with flow offloading as this
was not fixed. The other problems should be fixed now.

On 7/17/21 5:45 PM, Hauke Mehrtens wrote:

Currently we still have these problem:

- IPv6 broken with flow offloading (according to reports, potentially
related to hw flow offloading)
- PPPoE allegedly broken (according to reports, not fully
reproducible, likely related to hw flow offloading too)
- https://bugs.openwrt.org/index.php?do=details_id=3909
- https://bugs.openwrt.org/index.php?do=details_id=3835


Some more information can be found here:
https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-
timeouts/74588
https://bugs.openwrt.org/index.php?do=details_id=3373
https://bugs.openwrt.org/index.php?do=details_id=3759

It could be that this change causes the problems:
https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-
3-pa...@netfilter.org/

I do not know how much time and interest I have in debugging and fixing this
problem. If someone wants to have a closer look into this problem it would
be really nice. even when you can make it easier to reproduce it in a test
environment it would be nice.

Should we just release with this as a known problem?

Although my opinion should not be given much weight in this context, I'd also prefer a 
"quick" release, for about the same reasons as Hannu has given in his e-mail.

As I understand it, disabling offloading will give you a working device, so 
it's fair enough.

Best

Adrian


Other than this problem I am not aware of any other critical problem.

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: On a newer kernel, only the first port of a bridge is brought up

2021-07-26 Thread Nick

Also on mt7621 Xiaomi Mi 3G v2.

On 7/26/21 8:42 PM, Chad Monroe wrote:

On Mon, Jul 26, 2021 at 10:14 AM Klaus Kudielka
 wrote:

  > I tried to run OpenWrt with a bleeding-edge net-next kernel (commit

0e804326759d), then noticed that only the first port of a bridge is
brought up automatically, the rest are down and not members of the
bridge.
i.e. with the following settings
network.@device  
[0]=device

  > network.@device  
[0].ports='lan1' 'lan2' 
'lan3' 'lan4'
  > network.@device  
[0].type='bridge'
  > network.@device  
[0].name='br-lan'

Only lan1 is in br-lan, and I have to manually configure the rest:

Exactly the same happens to me on Turris Omnia with master, either 5.4
OpenWrt kernel or 5.10 OpenWrt kernel.

I bisected this to "2801fe6132c4e2e364e2d5a304594185351b501b netifd:
update to the latest version".

And, I believe, Petr has noticed the same thing with 21.02.

Regards, Klaus

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

I ran into this on our mt7622 (mediatek) target as well.

It appears to be related to this netifd commit specifically:
https://git.openwrt.org/?p=project/netifd.git;a=commit;h=85f01c44a950be8518ce5a7d251b5bba219348cf

I’m not sure exactly where the issue is just yet but will take a look
and see if it’s something I can identify.

Thanks,
 -Chad

___
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

[21.02] umdns: does not start because of missing seccomp features

2021-07-16 Thread Nick


To reproduce:
1) Build 21.02 image with imagebuiler
2) opkg update && opkg install umnds
3) umdns will not start

The seccomp file is existing ( /etc/seccomp/umdns.json ), and so the line:
https://github.com/openwrt/openwrt/blob/openwrt-21.02/package/network/services/umdns/files/umdns.init#L36

However, the packages are missing:
- procd-ujail
- procd-seccomp

Installing procd-seccomp is fixing the issue. I would do a PR, but I'm 
unsure what is the correct way of solving this issue.


Bests,
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v6 1/3] dnsmasq: distinct Ubus names for multiple instances

2021-07-04 Thread Nick Lowe

Hi all,

Is this expected to contain thekelleys.org.uk?

+   [ $dbus -gt 0 ] && xappend
"--enable-dbus=uk.org.thekelleys.$instance_name"

Best,

Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 19.07 0/4] ubus fixes backports

2021-07-02 Thread Nick


Hi,
the described backports also help if I compare rc2 to rc3. However, the 
backport from the ubus update broke it again. :)


We insert our own feed, so maybe we generate this issue:

21.02 SNAPSHOT:
https://gist.github.com/PolynomialDivision/a490bbe773ef3b29167f78912d1b6080

21.02-RC3:
https://gist.github.com/PolynomialDivision/443e53d4dc08994a9affe3174a792d75

You can also reproduce by using our repro:
https://github.com/Freifunk-Spalter/bbb-configs

And then
ansible-playbook play.yml --tags image --limit schreiner-core

Bests,
Nick

On 7/2/21 10:48 AM, Petr Štetiar wrote:

Nick  [2021-07-02 09:57:57]:

Hi,


There was a update of libubus: 
https://github.com/openwrt/openwrt/commit/3c574750854488ff463b2069a5d23d9c44f2a3dc

thats handled via `ubus: update to version 2021-07-01` backport.


However this still "broke" 21.02-rc3 and SNAPSHOT (imagebuilder)?
Why does it break "21.02-rc3"? Packages are not recompiled?

That should be handled via `treewide: mark selected packages nonshared` which
is in 21.02-rc3 via commit ea308e2f383c ("treewide: mark selected packages
nonshared") and in snapshot via commit 72cc44958ef4 ("treewide: mark
selected packages nonshared").

So I'm wondering what's broken, do you've any reproducer, link to the issue
details?

-- ynezz


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 19.07 0/4] ubus fixes backports

2021-07-02 Thread Nick

There was a update of libubus: 
https://github.com/openwrt/openwrt/commit/3c574750854488ff463b2069a5d23d9c44f2a3dc


However this still "broke" 21.02-rc3 and SNAPSHOT (imagebuilder)?
Why does it break "21.02-rc3"? Packages are not recompiled?

On 7/1/21 3:09 PM, Petr Štetiar wrote:

Hi,

this patch series backports various ubus related fixes and additionally marks
various default packages as nonshared in order to avoid further ABI issues[1].

1. https://github.com/openwrt/openwrt/pull/4233

-- ynezz

Hannu Nyman (1):
   treewide: mark selected packages nonshared

Petr Štetiar (3):
   ubus: backport SOVERSION support
   ubus: update to version 2021-06-03
   ubus: update to version 2021-07-01

  package/libs/libjson-c/Makefile  |  3 ++-
  package/libs/libnl-tiny/Makefile |  4 +++-
  package/libs/libubox/Makefile|  4 +++-
  package/system/ubus/Makefile | 17 ++---
  package/system/uci/Makefile  |  3 ++-
  package/utils/lua/Makefile   |  3 ++-
  6 files changed, 22 insertions(+), 12 deletions(-)


___
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

Move QOS-Scripts to packages feed?

2021-06-25 Thread Nick


Can we move qos-scripts to packages feed?
https://github.com/openwrt/openwrt/tree/master/package/network/config/qos-scripts

Bests,
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC PATCH] ath10k-ct: backport upstream fixes for FragAttacks

2021-05-27 Thread Nick Lowe

Hi Hauke,

I wonder if it is worth also opening an issue for this over at
https://github.com/greearb/ath10k-ct/issues ?

Best,

Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Rename opkg-lede to opkg

2021-05-19 Thread Nick


I also made a PR updating some parts of the Makefile:

https://github.com/openwrt/openwrt/pull/4187/files

On 5/19/21 10:03 PM, Nick wrote:
Why is the git repro of opkg still 
https://git.openwrt.org/project/opkg-lede.git ?

Can we change it back to https://git.openwrt.org/project/opkg ?

There was already some commit to change the source url, but not the 
repo name:
https://github.com/openwrt/openwrt/commit/da95c9aa17814d691a7fed6e8297fb29c5600c27#diff-8d00b3da40f45f370892fc2ffea1aa5ac6d4637e38e17766819993cd9a265c6e 



Bests
Nick


___
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

Rename opkg-lede to opkg

2021-05-19 Thread Nick

Why is the git repro of opkg still 
https://git.openwrt.org/project/opkg-lede.git ?

Can we change it back to https://git.openwrt.org/project/opkg ?

There was already some commit to change the source url, but not the repo 
name:

https://github.com/openwrt/openwrt/commit/da95c9aa17814d691a7fed6e8297fb29c5600c27#diff-8d00b3da40f45f370892fc2ffea1aa5ac6d4637e38e17766819993cd9a265c6e

Bests
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: libgpg-err build error

2021-05-13 Thread Nick


There is a PR for the package:
https://github.com/openwrt/packages/pull/15615

On 5/13/21 9:00 AM, e9hack wrote:

Hi,

I've trouble to build libgpg-err since the update from 1.39 to 1.42. 
Compilation does fail because the auto generated file gpg-error.h 
contains wrong syntax in macro GPGRT_LOCK_INITIALIZER:


#define GPGRT_LOCK_INITIALIZER {1,{{\c
0\c
,\0c
0\c
,\0c


The sequence is generated by gen-lock-obj.sh. I patched out the wrong 
generation of macros ECHO_C and ECHO_N:


--- a/src/gen-lock-obj.sh   2021-03-04 11:05:29.0 +0100
+++ b/src/gen-lock-obj.sh   2021-05-13 08:14:52.675832305 +0200
@@ -39,8 +39,8 @@
 #

 if test -n `echo -n`; then
-    ECHO_C='\c'
-    ECHO_N=''
+    ECHO_C=''
+    ECHO_N='-n'
 else
 ECHO_C=''
 ECHO_N='-n'

Any idea why this does fail? My build system is openSuse Leap 15.2, 
running in Oracle VirtualBox on Windows.


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: FRAG Attacks (new vuln for wifi)

2021-05-12 Thread Nick Lowe

> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to 
> > be patched?
> > Is 4.19 the oldest that owrt will consume?
> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update
> anything older than that.

So, to summarise, the 4.19, 5.4 and 5.10 branch kernels are currently in use.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: umdns bug

2021-04-10 Thread Nick


Nice thanks for the fast reply! :)

Bests,
Nick

On 4/10/21 6:39 PM, Daniel Golle wrote:

Hi Nick,

On Sat, Apr 10, 2021 at 01:31:21PM +0200, Nick wrote:

There is an error in the current umds project: "UMDNS: does not start on
master with seccomp"
https://bugs.openwrt.org/index.php?do=details_id=3355

It is affecting several other projects that make use of umdns.
Is someone working on it?

Thank you for bringing this to my attention.
I have (hopefully) fixed the issue with
commit 00a85a1634 ("umdns: add missing syscalls to seccomp filter"),
at least on my Aarch64 test boards it works now.
More/other syscalls may be needed on different architectures, see
the commit description of the fix mentioned above for instructions on
how to find them.


Cheers


Daniel



Bests,
Nick


___
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

umdns bug

2021-04-10 Thread Nick

There is an error in the current umds project: "UMDNS: does not start on 
master with seccomp"

https://bugs.openwrt.org/index.php?do=details_id=3355

It is affecting several other projects that make use of umdns.
Is someone working on it?

Bests,
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] mpc85xx-p1010: add Kernel 5.10 support

2021-02-17 Thread Nick


Also interesting:
https://github.com/openwrt/openwrt/pull/1773#issuecomment-459230119

On 2/17/21 11:02 AM, David Bauer wrote:

Hi,

On 2/17/21 9:20 AM, Perry wrote:

Hello,

I thought the kernel size issue was resolved by 
1e41de2f48e284c9d6658f9403365651178f6826

Also, the linked PR #1773 has a happy ending.

Is the simpleImage no longer a viable solution? Could you explain why not?

the issue was resolved for v5.4 with using a different PPC bootwrapper. However,
as the kernel grew again with v5.10, this was already back then set to break 
again in
the future, as the bootwrapper only enables a more efficient compression but 
does not by
itself read from the flash.

Best wishes
David


Greetings
Perry

On February 17, 2021 5:59:28 AM GMT+01:00, David Bauer  
wrote:

Hi Daniel,

On 2/17/21 4:21 AM, Daniel Golle wrote:

On Tue, Feb 16, 2021 at 11:48:04PM +0100, David Bauer wrote:

Tested on: Sophos RED 15W

The TP-Link WL-WDR4900 needs to be disabled when 5.10 becomes the
default kernel.

That's sad. Why?

See the next sentence ;) as well as this GitHub issue:
https://github.com/openwrt/openwrt/pull/1773

Best
David

___
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


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02 planning

2021-02-12 Thread Nick


On 2/11/21 11:57 PM, Hauke Mehrtens wrote:

Any objections to this plan? 

Can we please get

- SXTsq5ac (https://github.com/openwrt/openwrt/pull/3108) depends on 
(MikroTik hAP ac2 )

- MikroTik hAP ac2 (https://github.com/openwrt/openwrt/pull/3037)

into this release?
It seems like both devices need only minor changes.

Bests,
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] odhcpd: add option to use absolute timestamps

2021-02-09 Thread Nick

Maybe I will just inject via ubus a prefix, that is not reflected by the 
config, like the

"UBUS_METHOD("add_prefix", handle_add_prefix, prefix_attrs)"

At the end that gives me the flexibility I need without the need to 
insert absolute timestamps.


Best,
Nick

On 2/6/21 9:33 PM, Nick wrote:
I see that more as setting a preferred lifetime with a relative 
time-span.
E.g. I will get a a preferred_lft of 120 from now, and I would set it 
like:


  date '+%d %b %Y %T' --date="@$(($(date +%s)+120))"

So it does not need to be synced, since I'm only interested in the 
timespan from now + 120s.
Setting this as abs time-span will prevent a reload or restart of the 
daemon setting the value again to now + 120.


Bests,
Nick

On 2/6/21 9:14 PM, Hans Dedecker wrote:



On Sat, Jan 30, 2021 at 5:33 PM Nick Hainke <mailto:vinc...@systemli.org>> wrote:


    Until now it is not possible to give absolute timestamps in odhcpd.
    This means that on every new RA or request, the timestamp is 
renewed.
    Further, the valid and preferred lifetimes are not synced between 
all

    devices.

    There are several usecases when it is needed to have absolute
    timestamp
    that needed to be synced across all devices, e.g. your ISP delegates
    you a prefix for some certain time, or you want to change to another
    prefix.

    The purpose of having this as a absolute timestamp is to make it
    easier
    to track. An example configuration is

      option absolute_lifetime '1'
      option valid_lifetime '05 Jan 2021 23:00:00'
      option preferred_lifetime '05 Jan 2021 23:00:00'

    If the valid_lifetime is in the past, the preferred lifetime and 
valid

    lifetime are set to 1 minute.

I have my reservations about the patch as it requires knowledge of 
absolute time on devices.
This is a problem as not all devices have a RTC; or the time needs to 
be synchronized with a wan NTP server.
This is also the reason why netifd does not to support absolute 
lifetimes for configured prefixes


Hans


    Signed-off-by: Nick Hainke mailto:vinc...@systemli.org>>
    ---
     README          |  8 --
     src/config.c    | 69
    ++---
     src/dhcpv6-ia.c | 10 +++
     src/odhcpd.h    |  1 +
     4 files changed, 65 insertions(+), 23 deletions(-)

    diff --git a/README b/README
    index f9cbb11..0af5c75 100644
    --- a/README
    +++ b/README
    @@ -107,11 +107,13 @@ dns_service               bool    1
               Announce the address of interface as DNS service
                                                            if the
    list of dns is empty
     domain                 list      Search
    domains to announce

    -leasetime              string  12h  DHCPv4 address leasetime
    +leasetime              string  12h  DHCPv4 address leasetime. If
    absolute_lifetime is
    +                                                       set the
    value can be given as a date, e.g. "10 Jan 2020 00:00:00".
     start                  integer 100  DHCPv4 pool start
     limit                  integer 150  DHCPv4 pool size
     preferred_lifetime     string  12h  Value for the preferred 
lifetime

    -                                                       for a prefix
    +                                                       for a
    prefix. If absolute_lifetime is set the value can
    +                                                       be given
    as a date, e.g. "10 Jan 2020 00:00:00".
     ra_default             integer 0  Override default route
                            0: default, 1: ignore no public address,
    2: ignore all
     ra_flags               list    other-config            List of RA
    flags to be
    @@ -145,6 +147,8 @@ ndproxy_slave               bool    0
               NDProxy external slave
     prefix_filter          string  ::/0                    Only
    advertise on-link prefixes within
                            [IPv6 prefix]                   the
    provided IPv6 prefix; others are
    filtered out.
    +absolute_lifetime              bool    0    Interpret configured
    lifetime as
    +  absolute timestamps. The format has to be "10 Jan 2020 00:00:00".


     Sections of type host (static leases)
    diff --git a/src/config.c b/src/config.c
    index 78b5855..42f73a1 100644
    --- a/src/config.c
    +++ b/src/config.c
    @@ -8,6 +8,7 @@
     #include 
     #include 
     #include 
    +#include 

     #include 
     #include 
    @@ -83,6 +84,7 @@ enum {
            IFACE_ATTR_NDPROXY_SLAVE,
            IFACE_ATTR_PREFIX_FILTER,
            IFACE_ATTR_PREFERRED_LIFETIME,
    +       IFACE_ATTR_ABSOLUTE_LIFETIME,
            IFACE_ATTR_MAX
     };

    @@ -132,6 +134,7 @@ static const struct blobmsg_policy
    iface_attrs[IFACE_ATTR_MAX] = {
            [IFACE_ATTR_NDPROXY_SLAVE] = { .name = "ndproxy_slave",
    .type = B

Re: [PATCH] odhcpd: add option to use absolute timestamps

2021-02-06 Thread Nick


I see that more as setting a preferred lifetime with a relative time-span.
E.g. I will get a a preferred_lft of 120 from now, and I would set it like:

  date '+%d %b %Y %T' --date="@$(($(date +%s)+120))"

So it does not need to be synced, since I'm only interested in the 
timespan from now + 120s.
Setting this as abs time-span will prevent a reload or restart of the 
daemon setting the value again to now + 120.


Bests,
Nick

On 2/6/21 9:14 PM, Hans Dedecker wrote:



On Sat, Jan 30, 2021 at 5:33 PM Nick Hainke <mailto:vinc...@systemli.org>> wrote:


Until now it is not possible to give absolute timestamps in odhcpd.
This means that on every new RA or request, the timestamp is renewed.
Further, the valid and preferred lifetimes are not synced between all
devices.

There are several usecases when it is needed to have absolute
timestamp
that needed to be synced across all devices, e.g. your ISP delegates
you a prefix for some certain time, or you want to change to another
prefix.

The purpose of having this as a absolute timestamp is to make it
easier
to track. An example configuration is

  option absolute_lifetime '1'
  option valid_lifetime '05 Jan 2021 23:00:00'
  option preferred_lifetime '05 Jan 2021 23:00:00'

If the valid_lifetime is in the past, the preferred lifetime and valid
lifetime are set to 1 minute.

I have my reservations about the patch as it requires knowledge of 
absolute time on devices.
This is a problem as not all devices have a RTC; or the time needs to 
be synchronized with a wan NTP server.
This is also the reason why netifd does not to support absolute 
lifetimes for configured prefixes


Hans


Signed-off-by: Nick Hainke mailto:vinc...@systemli.org>>
---
 README          |  8 --
 src/config.c    | 69
++---
 src/dhcpv6-ia.c | 10 +++
 src/odhcpd.h    |  1 +
 4 files changed, 65 insertions(+), 23 deletions(-)

diff --git a/README b/README
index f9cbb11..0af5c75 100644
--- a/README
+++ b/README
@@ -107,11 +107,13 @@ dns_service               bool    1        
           Announce the address of interface as DNS service
                                                        if the
list of dns is empty
 domain                 list      Search
domains to announce

-leasetime              string  12h  DHCPv4 address leasetime
+leasetime              string  12h  DHCPv4 address leasetime. If
absolute_lifetime is
+                                                       set the
value can be given as a date, e.g. "10 Jan 2020 00:00:00".
 start                  integer 100  DHCPv4 pool start
 limit                  integer 150  DHCPv4 pool size
 preferred_lifetime     string  12h  Value for the preferred lifetime
-                                                       for a prefix
+                                                       for a
prefix. If absolute_lifetime is set the value can
+                                                       be given
as a date, e.g. "10 Jan 2020 00:00:00".
 ra_default             integer 0  Override default route
                        0: default, 1: ignore no public address,
2: ignore all
 ra_flags               list    other-config            List of RA
flags to be
@@ -145,6 +147,8 @@ ndproxy_slave               bool    0        
           NDProxy external slave
 prefix_filter          string  ::/0                    Only
advertise on-link prefixes within
                        [IPv6 prefix]                   the
provided IPv6 prefix; others are
filtered out.
+absolute_lifetime              bool    0    Interpret configured
lifetime as
+  absolute timestamps. The format has to be "10 Jan 2020 00:00:00".


 Sections of type host (static leases)
diff --git a/src/config.c b/src/config.c
index 78b5855..42f73a1 100644
--- a/src/config.c
+++ b/src/config.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -83,6 +84,7 @@ enum {
        IFACE_ATTR_NDPROXY_SLAVE,
        IFACE_ATTR_PREFIX_FILTER,
        IFACE_ATTR_PREFERRED_LIFETIME,
+       IFACE_ATTR_ABSOLUTE_LIFETIME,
        IFACE_ATTR_MAX
 };

@@ -132,6 +134,7 @@ static const struct blobmsg_policy
iface_attrs[IFACE_ATTR_MAX] = {
        [IFACE_ATTR_NDPROXY_SLAVE] = { .name = "ndproxy_slave",
.type = BLOBMSG_TYPE_BOOL },
        [IFACE_ATTR_PREFIX_FILTER] = { .name = "prefix_filter",
.type = BLOBMSG_TYPE_STRING },
        [IFACE_ATTR_PREFERRED_LIFETIME] = { .name =
"preferred_lifetime", .type = BLOBMSG_TYPE_STRING },
+       [IFACE_ATTR_ABSOLUTE_LIFETIME] = { .name =

[PATCH] odhcpd: add option to use absolute timestamps

2021-01-30 Thread Nick Hainke

Until now it is not possible to give absolute timestamps in odhcpd.
This means that on every new RA or request, the timestamp is renewed.
Further, the valid and preferred lifetimes are not synced between all
devices.

There are several usecases when it is needed to have absolute timestamp
that needed to be synced across all devices, e.g. your ISP delegates
you a prefix for some certain time, or you want to change to another
prefix.

The purpose of having this as a absolute timestamp is to make it easier
to track. An example configuration is

  option absolute_lifetime '1'
  option valid_lifetime '05 Jan 2021 23:00:00'
  option preferred_lifetime '05 Jan 2021 23:00:00'

If the valid_lifetime is in the past, the preferred lifetime and valid
lifetime are set to 1 minute.

Signed-off-by: Nick Hainke 
---
 README  |  8 --
 src/config.c| 69 ++---
 src/dhcpv6-ia.c | 10 +++
 src/odhcpd.h|  1 +
 4 files changed, 65 insertions(+), 23 deletions(-)

diff --git a/README b/README
index f9cbb11..0af5c75 100644
--- a/README
+++ b/README
@@ -107,11 +107,13 @@ dns_service   bool1   
Announce the address of interface as DNS service
if the list of dns is 
empty
 domain list   Search domains to 
announce
 
-leasetime  string  12h DHCPv4 address leasetime
+leasetime  string  12h DHCPv4 address 
leasetime. If absolute_lifetime is
+   set the value can be 
given as a date, e.g. "10 Jan 2020 00:00:00".
 start  integer 100 DHCPv4 pool start
 limit  integer 150 DHCPv4 pool size
 preferred_lifetime string  12h Value for the preferred 
lifetime
-   for a prefix
+   for a prefix. If 
absolute_lifetime is set the value can
+   be given as a date, 
e.g. "10 Jan 2020 00:00:00".
 ra_default integer 0   Override default route
0: default, 1: ignore no public address, 2: ignore all
 ra_flags   listother-configList of RA flags to be
@@ -145,6 +147,8 @@ ndproxy_slave   bool0   
NDProxy external slave
 prefix_filter  string  ::/0Only advertise on-link 
prefixes within
[IPv6 prefix]   the provided IPv6 
prefix; others are
filtered out.
+absolute_lifetime  bool0   Interpret 
configured lifetime as
+   absolute timestamps. 
The format has to be "10 Jan 2020 00:00:00".
 
 
 Sections of type host (static leases)
diff --git a/src/config.c b/src/config.c
index 78b5855..42f73a1 100644
--- a/src/config.c
+++ b/src/config.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -83,6 +84,7 @@ enum {
IFACE_ATTR_NDPROXY_SLAVE,
IFACE_ATTR_PREFIX_FILTER,
IFACE_ATTR_PREFERRED_LIFETIME,
+   IFACE_ATTR_ABSOLUTE_LIFETIME,
IFACE_ATTR_MAX
 };
 
@@ -132,6 +134,7 @@ static const struct blobmsg_policy 
iface_attrs[IFACE_ATTR_MAX] = {
[IFACE_ATTR_NDPROXY_SLAVE] = { .name = "ndproxy_slave", .type = 
BLOBMSG_TYPE_BOOL },
[IFACE_ATTR_PREFIX_FILTER] = { .name = "prefix_filter", .type = 
BLOBMSG_TYPE_STRING },
[IFACE_ATTR_PREFERRED_LIFETIME] = { .name = "preferred_lifetime", .type 
= BLOBMSG_TYPE_STRING },
+   [IFACE_ATTR_ABSOLUTE_LIFETIME] = { .name = "absolute_lifetime", .type = 
BLOBMSG_TYPE_BOOL },
 };
 
 static const struct uci_blob_param_info iface_attr_info[IFACE_ATTR_MAX] = {
@@ -212,6 +215,7 @@ static void set_interface_defaults(struct interface *iface)
iface->ra_mininterval = iface->ra_maxinterval/3;
iface->ra_lifetime = -1;
iface->ra_dns = true;
+   iface->absolute_lifetime = false;
 }
 
 static void clean_interface(struct interface *iface)
@@ -321,29 +325,48 @@ static void set_config(struct uci_section *s)
}
 }
 
-static double parse_leasetime(struct blob_attr *c) {
+static double parse_leasetime(struct blob_attr *c, bool absolute) {
char *val = blobmsg_get_string(c), *endptr = NULL;
-   double time = strcmp(val, "infinite") ? strtod(val, ) : 
UINT32_MAX;
-
-   if (time && endptr && endptr[0]) {
-   if (endptr[0] == 's')
-   time *= 1;
-   else if (endptr[0] == 'm')
-   ti

Re: [PATCH 1/2] owipcalc: remove package

2021-01-22 Thread Nick


Ah okay. I see no problem anymore. :)
But jow is the maintainer and author of owipcalc. I would even say that 
this tool could also be useful on other paltforms and not only OpenWrt. 
I would take care of that if jow is fine with it.


Bests,
Nick

On 1/22/21 1:43 PM, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Nick
Sent: Freitag, 22. Januar 2021 12:50
To: openwrt-devel@lists.openwrt.org
Subject: Re: [PATCH 1/2] owipcalc: remove package

Is it okay to push c-code into packages feed, if it is not patch related? (never
saw this)

I grepped for "stdlib.h" in packages and found e.g. this one here:

https://github.com/openwrt/packages/blob/014e02ab075333bccd6ac5f3c8eaceba6ab41157/utils/sockread/Makefile

Apart from that, I don't see a reason why we would not accept C-code in 
packages?

Best

Adrian


On 1/22/21 10:51 AM, Adrian Schmutzler wrote:

This is a helpful utility, but it does not have any dependencies in
this repository. Move it to packages feed.

Cc: Jo-Philipp Wich 
Cc: Nick Hainke 
Signed-off-by: Adrian Schmutzler 
---
   package/network/utils/owipcalc/Makefile   |  44 -
   package/network/utils/owipcalc/src/owipcalc.c | 950 --
   2 files changed, 994 deletions(-)
   delete mode 100644 package/network/utils/owipcalc/Makefile
   delete mode 100644 package/network/utils/owipcalc/src/owipcalc.c

diff --git a/package/network/utils/owipcalc/Makefile
b/package/network/utils/owipcalc/Makefile
deleted file mode 100644
index dc68a0346b..00
--- a/package/network/utils/owipcalc/Makefile
+++ /dev/null
@@ -1,44 +0,0 @@
-#
-# Copyright (C) 2012 Jo-Philipp Wich  -# -# This is free
software, licensed under the Apache 2 license.
-#
-
-include $(TOPDIR)/rules.mk
-
-PKG_NAME:=owipcalc
-PKG_RELEASE:=5
-PKG_LICENSE:=Apache-2.0
-
-include $(INCLUDE_DIR)/package.mk
-
-
-define Package/owipcalc
-  SECTION:=utils
-  CATEGORY:=Utilities
-  TITLE:=Simple IPv4/IPv6 address calculator
-  MAINTAINER:=Jo-Philipp Wich  -endef
-
-define Package/owipcalc/description
-  The owipcalc utility supports a number of calculations and tests to
work
-  with ip-address ranges, this is useful for scripts that e.g. need
to
-  partition ipv6-prefixes into small subnets or to calculate address
ranges
-  for dhcp pools.
-endef
-
-define Build/Configure
-endef
-
-define Build/Compile
-   $(TARGET_CC) $(TARGET_CFLAGS) \
-   -o $(PKG_BUILD_DIR)/owipcalc

$(PKG_BUILD_DIR)/owipcalc.c

-endef
-
-
-define Package/owipcalc/install
-   $(INSTALL_DIR) $(1)/usr/bin
-   $(INSTALL_BIN) $(PKG_BUILD_DIR)/owipcalc $(1)/usr/bin/owipcalc
-endef
-
-$(eval $(call BuildPackage,owipcalc)) diff --git
a/package/network/utils/owipcalc/src/owipcalc.c
b/package/network/utils/owipcalc/src/owipcalc.c
deleted file mode 100644
index 5ed609f158..00
--- a/package/network/utils/owipcalc/src/owipcalc.c
+++ /dev/null
@@ -1,950 +0,0 @@
-/*
- * owipcalc - OpenWrt IP Calculator
- *
- *   Copyright (C) 2012 Jo-Philipp Wich 
- *
- *  Licensed under the Apache License, Version 2.0 (the "License");
- *  you may not use this file except in compliance with the License.
- *  You may obtain a copy of the License at
- *
- *  http://www.apache.org/licenses/LICENSE-2.0
- *
- *  Unless required by applicable law or agreed to in writing,
software
- *  distributed under the License is distributed on an "AS IS" BASIS,
- *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express

or implied.

- *  See the License for the specific language governing permissions
and
- *  limitations under the License.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-
-
-struct cidr {
-   uint8_t family;
-   uint32_t prefix;
-   union {
-   struct in_addr v4;
-   struct in6_addr v6;
-   } addr;
-   union {
-   char v4[sizeof("255.255.255.255/255.255.255.255 ")];
-   char

v6[sizeof("::::::255.255.255.255/128 ")];

-   } buf;
-   struct cidr *next;
-};
-
-struct op {
-   const char *name;
-   const char *desc;
-   struct {
-   bool (*a1)(struct cidr *a);
-   bool (*a2)(struct cidr *a, struct cidr *b);
-   } f4;
-   struct {
-   bool (*a1)(struct cidr *a);
-   bool (*a2)(struct cidr *a, struct cidr *b);
-   } f6;
-};
-
-
-static bool quiet = false;
-static bool printed = false;
-
-static struct cidr *stack = NULL;
-
-#define qprintf(...) \
-   do { \
-   if (!quiet) printf(__VA_ARGS__); \
-   printed = true; \
-   } while(0)
-
-static void cidr_push(struct cidr *a) -{
-   if (a)
-   {
-   a->next = stack;
-   stack = a;
-   }
-}
-
-static bool cidr_pop(struct cidr *a)
-{
-   struct cidr *old = stack;
-
-   i

Re: [PATCH 1/2] owipcalc: remove package

2021-01-22 Thread Nick

Is it okay to push c-code into packages feed, if it is not patch 
related? (never saw this)


On 1/22/21 10:51 AM, Adrian Schmutzler wrote:

This is a helpful utility, but it does not have any dependencies
in this repository. Move it to packages feed.

Cc: Jo-Philipp Wich 
Cc: Nick Hainke 
Signed-off-by: Adrian Schmutzler 
---
  package/network/utils/owipcalc/Makefile   |  44 -
  package/network/utils/owipcalc/src/owipcalc.c | 950 --
  2 files changed, 994 deletions(-)
  delete mode 100644 package/network/utils/owipcalc/Makefile
  delete mode 100644 package/network/utils/owipcalc/src/owipcalc.c

diff --git a/package/network/utils/owipcalc/Makefile 
b/package/network/utils/owipcalc/Makefile
deleted file mode 100644
index dc68a0346b..00
--- a/package/network/utils/owipcalc/Makefile
+++ /dev/null
@@ -1,44 +0,0 @@
-#
-# Copyright (C) 2012 Jo-Philipp Wich 
-#
-# This is free software, licensed under the Apache 2 license.
-#
-
-include $(TOPDIR)/rules.mk
-
-PKG_NAME:=owipcalc
-PKG_RELEASE:=5
-PKG_LICENSE:=Apache-2.0
-
-include $(INCLUDE_DIR)/package.mk
-
-
-define Package/owipcalc
-  SECTION:=utils
-  CATEGORY:=Utilities
-  TITLE:=Simple IPv4/IPv6 address calculator
-  MAINTAINER:=Jo-Philipp Wich 
-endef
-
-define Package/owipcalc/description
-  The owipcalc utility supports a number of calculations and tests to work
-  with ip-address ranges, this is useful for scripts that e.g. need to
-  partition ipv6-prefixes into small subnets or to calculate address ranges
-  for dhcp pools.
-endef
-
-define Build/Configure
-endef
-
-define Build/Compile
-   $(TARGET_CC) $(TARGET_CFLAGS) \
-   -o $(PKG_BUILD_DIR)/owipcalc $(PKG_BUILD_DIR)/owipcalc.c
-endef
-
-
-define Package/owipcalc/install
-   $(INSTALL_DIR) $(1)/usr/bin
-   $(INSTALL_BIN) $(PKG_BUILD_DIR)/owipcalc $(1)/usr/bin/owipcalc
-endef
-
-$(eval $(call BuildPackage,owipcalc))
diff --git a/package/network/utils/owipcalc/src/owipcalc.c 
b/package/network/utils/owipcalc/src/owipcalc.c
deleted file mode 100644
index 5ed609f158..00
--- a/package/network/utils/owipcalc/src/owipcalc.c
+++ /dev/null
@@ -1,950 +0,0 @@
-/*
- * owipcalc - OpenWrt IP Calculator
- *
- *   Copyright (C) 2012 Jo-Philipp Wich 
- *
- *  Licensed under the Apache License, Version 2.0 (the "License");
- *  you may not use this file except in compliance with the License.
- *  You may obtain a copy of the License at
- *
- *  http://www.apache.org/licenses/LICENSE-2.0
- *
- *  Unless required by applicable law or agreed to in writing, software
- *  distributed under the License is distributed on an "AS IS" BASIS,
- *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- *  See the License for the specific language governing permissions and
- *  limitations under the License.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-
-
-struct cidr {
-   uint8_t family;
-   uint32_t prefix;
-   union {
-   struct in_addr v4;
-   struct in6_addr v6;
-   } addr;
-   union {
-   char v4[sizeof("255.255.255.255/255.255.255.255 ")];
-   char v6[sizeof("::::::255.255.255.255/128 
")];
-   } buf;
-   struct cidr *next;
-};
-
-struct op {
-   const char *name;
-   const char *desc;
-   struct {
-   bool (*a1)(struct cidr *a);
-   bool (*a2)(struct cidr *a, struct cidr *b);
-   } f4;
-   struct {
-   bool (*a1)(struct cidr *a);
-   bool (*a2)(struct cidr *a, struct cidr *b);
-   } f6;
-};
-
-
-static bool quiet = false;
-static bool printed = false;
-
-static struct cidr *stack = NULL;
-
-#define qprintf(...) \
-   do { \
-   if (!quiet) printf(__VA_ARGS__); \
-   printed = true; \
-   } while(0)
-
-static void cidr_push(struct cidr *a)
-{
-   if (a)
-   {
-   a->next = stack;
-   stack = a;
-   }
-}
-
-static bool cidr_pop(struct cidr *a)
-{
-   struct cidr *old = stack;
-
-   if (old)
-   {
-   stack = stack->next;
-   free(old);
-
-   return true;
-   }
-
-   return false;
-}
-
-static struct cidr * cidr_clone(struct cidr *a)
-{
-   struct cidr *b = malloc(sizeof(*b));
-
-   if (!b)
-   {
-   fprintf(stderr, "out of memory\n");
-   exit(255);
-   }
-
-   memcpy(b, a, sizeof(*b));
-   cidr_push(b);
-
-   return b;
-}
-
-
-static struct cidr * cidr_parse4(const char *s)
-{
-   char *p = NULL, *r;
-   struct in_addr mask;
-   struct cidr *addr = malloc(sizeof(struct cidr));
-
-   if (!addr || (strlen(s) >= sizeof(addr->buf.v4)))
-   goto err;
-
-   snprintf(addr->buf.v4, sizeof(addr->buf.v4), "%s", s);
-
-   addr->family = AF_INET;
-

Re: [PATCH] odhcpd: add option for setting preferred lifetime

2021-01-02 Thread Nick


On 1/2/21 9:31 PM, Hans Dedecker wrote:


Do we really need an extra config option to indicate a configured
preferred lifetime needs to be used ?

Thanks for your quick review!
I made the requested changes here (untested):
https://github.com/PolynomialDivision/odhcpd/commit/a63ed3e678d292c9b10ca72f8e744343a65e2e17

I'm a bit afraid that we will break backwards compatibility. If people 
want the same behavior as now, they always now have to change the 
lease-time and preferred_lifetime. I have to think about it again. 
Further, now the preferred lifetime is only set, if "ra_useleasetime" is 
set.


I will test the changes and send them via mailing list again.

Bests,
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] netifd: add segment routing support

2020-12-12 Thread Nick


On 12/12/20 8:20 PM, Hans Dedecker wrote:


Hi,

On Wed, Dec 2, 2020 at 3:33 PM  wrote:

From: Nick Hainke 

seg6_enabled - Bool
   Accept or drop SR-enabled IPv6 packets on this interface.

More Information:
https://www.kernel.org/doc/html/latest/networking/seg6-sysctl.html

Now you can set as interface option
   option ip6segmentrouting '1'

It is not enough to turn on "seg6_enabled" on the interface. Further,
we have to enable "/all/seg6_enabled". This means that a working config
is "interface + all".

Signed-off-by: Nick Hainke 

The patch does not apply anymore on latest master; could you resend it
based on latest master ?

Thx
Hans


Just sent a new rebased version via mailinglist. :)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

proc_stripped by default?

2020-12-07 Thread Nick


Do we really have to "CONFIG_PROC_STRIPPED=y" by default?
I wrote an prometheus-node-exporter and right now a collectd plugin, to 
get ipv6 interface statistics.

For that I use "/proc/net/snmp6" and "/proc/net/dev_snmp6/...".
The above flag disables those two statistics.

I'm very interested in the IPv6 stats we will have then we introduce 
IPv6 in our community wireless network.
Currently, we build our firmware based on the pre-compiled image builder 
and that is why I would be happy if we could change that. Otherwise, I 
just build my own imagebuilder for a single node... ;)


Or, is there even a better way to get those IPv6 stats? I looked into 
the netstat code, and I think it uses she snmp6 interface, too (not sure 
anymore).



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] kernel: enable SRv6 support

2020-12-02 Thread Nick


Okay, thanks! :)
I will send a new patch, adding some kernel option there.

On 12/2/20 12:34 PM, Petr Štetiar wrote:

vinc...@systemli.org  [2020-12-02 12:25:58]:

Hi,


diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 10d14f6be5..942777b41e 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -2387,7 +2387,7 @@ CONFIG_IO_STRICT_DEVMEM=y
  # CONFIG_IPC_NS is not set
  # CONFIG_IPMB_DEVICE_INTERFACE is not set
  # CONFIG_IPMI_HANDLER is not set
-# CONFIG_IPV6 is not set
+CONFIG_IPV6=y

ipv6 is config option, now you've included it for everybody. Take a look at
config/Config-kernel.in and KERNEL_IPV6 option.

-- ynezz

___
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: IPQ40XX: Introduce Kernel Flag

2020-11-27 Thread Nick

As I understand the issue, it is the the network-hardware that is 
causing the problem.
I did not have the time to lookup that all the flags in the driver and 
what they do.


As u can see, some "NETIF_F_HW_VLAN_CTAG_TX" is disabled and I have no 
idea why. I think this drops my tx-speed when I send on a tagged port to 
5~10 MBit/s with huge erros (probably some ring buffer overflowing since 
the hardware offload is disabled). Probably, if you have nested vlan, 
the flag causes some trouble.


"NETIF_F_RXHASH" is also disabled, but I don't know if this has directly 
an impact on what we are doing.


If we do not set "if (port ==0) t |= AR40XX_PORT_VLAN1_CORE_PORT;", you 
can not receive a package and give it tagged to the cpu.


I'm just guessing by the name, what the flags are doing... So not sure 
if this is correct what I write.


Maybe I find the time to search for a datasheet and lookup the stuff 
again and write a detailed description.
For now this PR makes things just more easy to maintain for the people 
who want to use port isolation, since we can just adjust the kernel config.


We build our Freifunk-Network with ipq40xx devices. This is why it is so 
important for me.
I would like if "CONFIG_IPQ40XX_PORT_ISOLATION=y" is enabled by default, 
so we can just use the openwrt imagebuilder for our firmware, but even 
if it is disabled by default, I would benefit from it.


But if u want, I can switch to a "DT property".

On 11/27/20 10:05 PM, Andreas Oberritter wrote:

Hi Nick,

On Fri, 27 Nov 2020 09:43:58 +0100
Nick  wrote:


The current ipq40xx network stack does no longer work for a few targets:
- Zyxel
- Fritz!Box 4040
- Fritz!Box 7530
- ZyXEL NBG6617
- GL-B1300
- ...

Can we please finally add my PR? I introduced a kernel flag that is
about switching between the different options
1. Port Isolation
2. Nested VLANs
ith this I hope to satisfy both sides.

Here is the PR:
https://github.com/openwrt/openwrt/pull/3596

if this is a device specific setting, wouldn't it be better to use a DT 
property instead of adding a new compile-time switch?

Best regards,
Andreas


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

IPQ40XX: Introduce Kernel Flag

2020-11-27 Thread Nick


The current ipq40xx network stack does no longer work for a few targets:
- Zyxel
- Fritz!Box 4040
- Fritz!Box 7530
- ZyXEL NBG6617
- GL-B1300
- ...

Can we please finally add my PR? I introduced a kernel flag that is 
about switching between the different options

1. Port Isolation
2. Nested VLANs
ith this I hope to satisfy both sides.

Here is the PR:
https://github.com/openwrt/openwrt/pull/3596


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"

2020-11-20 Thread Nick


I added a kernel flag to differentiate between both driver versions.
https://github.com/openwrt/openwrt/pull/3596

I would backport this to 19.07 if it gets accepted.

On 11/20/20 3:30 PM, Baptiste Jonglez wrote:

Hi,

On 20-11-20, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Baptiste Jonglez
Sent: Freitag, 20. November 2020 11:21
To: openwrt-devel@lists.openwrt.org; John Crispin 
Cc: Baptiste Jonglez 
Subject: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double
tagging"

From: Baptiste Jonglez 

This change has been causing several issues on ipq40xx devices, including:

this seems to lack a Signed-off-by?

You're totally right, thanks for spotting this.  I've just sent a v2.

Baptiste

___
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: ath10k-ct all hash values are different?

2020-11-09 Thread Nick

Can we somehow get to the same naming convention, again?
In OpenWrt it is: QCA998X-firmware-... directly in /.
On the ct server it is QCA998X/firmware-...?

Bests,
Nick

On 11/8/20 10:55 PM, Ben Greear wrote:
> I tried to copy them all back into place...could have made mistakes since
> owrt names them differently than what is on my web server.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ath10k-ct all hash values are different?

2020-11-08 Thread Nick

I will test the new firmware files. :)

A quick workaround is to use the openwrt mirror:

diff --git a/package/firmware/ath10k-ct-firmware/Makefile
b/package/firmware/ath10k-ct-firmware/Makefile
index c298f80186..fcc49543dd 100644
--- a/package/firmware/ath10k-ct-firmware/Makefile
+++ b/package/firmware/ath10k-ct-firmware/Makefile
@@ -78,21 +78,21 @@ CT_FIRMWARE_FILE_FULL_HTT =
$(1)-$($(1)_FIRMWARE_FILE_CT_FULL_HTT)
 CT_FIRMWARE_FILE_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_HTT)
 
 define Download/ct-firmware
-  URL:=https://www.candelatech.com/downloads/$(2)
+  URL:=https://sources.openwrt.org/
   FILE:=$(call CT_FIRMWARE_FILE,$(1))
-  URL_FILE:=$($(1)_FIRMWARE_FILE_CT)
+  URL_FILE:=$(call CT_FIRMWARE_FILE,$(1))
 endef
 
 define Download/ct-firmware-full-htt
-  URL:=https://www.candelatech.com/downloads/$(2)
+  URL:=https://sources.openwrt.org/
   FILE:=$(call CT_FIRMWARE_FILE_FULL_HTT,$(1))
-  URL_FILE:=$($(1)_FIRMWARE_FILE_CT_FULL_HTT)
+  URL_FILE:=$(call CT_FIRMWARE_FILE_FULL_HTT,$(1))
 endef
 
 define Download/ct-firmware-htt
-  URL:=https://www.candelatech.com/downloads/$(2)
+  URL:=https://sources.openwrt.org/
   FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1))
-  URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
+  URL_FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1))
 endef
 
 QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019

On 11/7/20 6:54 PM, Nick wrote:
> I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573
> Not sure why the hash is suddenly different for all firmware files?
>
> ___
> 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: ath10k-ct all hash values are different?

2020-11-07 Thread Nick

It is the firmware that is broken and just contains 0s.

On 11/7/20 6:54 PM, Nick wrote:
> I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573
> Not sure why the hash is suddenly different for all firmware files?
>
> ___
> 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

ath10k-ct all hash values are different?

2020-11-07 Thread Nick

I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573
Not sure why the hash is suddenly different for all firmware files?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] hostapd: Add cell_density data rates option

2020-10-28 Thread Nick Lowe

Add a cell_density option to configure data rates for normal, high and
very high cell density wireless deployments.

The purpose of using a minimum basic/mandatory data rate that is higher
than 6 Mb/s, or 5.5 Mb/s (802.11b compatible), in high cell density
environments is to transmit broadcast/multicast data frames using less
airtime or to reduce management overheads where significant co-channel
interference (CCI) exists and cannot be avoided.

Caution: Without careful design and validation, configuration of a too
high minimum basic/mandatory data rate can sacrifice connection stability
or disrupt the ability to reliably connect and authenticate for little to
no capacity benefit. This is because this configuration affects the
ability of clients to hear and demodulate management, control and
broadcast/multicast data frames.

Deployments that have not been specifically designed and validated are
usually best suited to use 6, 12 and 24 Mb/s as basic/mandatory data
rates.

Only usually seek to configure a 12 Mb/s, or 11 Mb/s (802.11b
compatible), minimum basic/mandatory rate in high cell density
deployments that have been designed and validated for this.

For many deployments, the minimum basic/mandatory data rate should not be
configured above 12 Mb/s to 18 Mb/s, 24 Mb/s or higher. Such a
configuration is only appropriate for use in very high cell density
deployment scenarios.

A cell_density of Very High (3) should only be used where a deployment
has a valid use case and has been designed and validated specifically for
this use, nearly always with highly directional antennas - an example
would be stadium deployments. For example, with a 24 Mb/s OFDM minimum
basic/mandatory data rate, approximately a -73 dBm RSSI is required to
decode frames. Many clients will not have roamed elsewhere by the time
that they experience -73 dBm and, where they do, they frequently may not
hear and be able to demodulate beacon, control or broadcast/multicast
data frames causing connectivity issues.

There is a myth that disabling lower basic/mandatory data rates will
improve roaming and avoid sticky clients. For 802.11n, 802.11ac and
802.11ax clients this is not correct as clients will shift to and use
lower MCS rates and not to the 802.11b or 802.11g/802.11a rates that are
able to be used as basic/mandatory data rates.

There is a myth that disabling lower basic/mandatory data rates will
ensure that clients only use higher data rates and that better
performance is assured. For 802.11n, 802.11ac and 802.11ax clients this
is not correct as clients will shift around and use MCS rates and not the
802.11b or 802.11g/802.11a rates that able to be used as basic/mandatory
data rates.

Cell Density

0 - Disabled (Default)
Setting cell_density to 0 does not configure data rates. This is the
default.

1 - Normal Cell Density
Setting cell_density to 1 configures the basic/mandatory rates to 6, 12
and 24 Mb/s OFDM rates where legacy_rates is 0. Supported rates lower
than the minimum basic/mandatory rate are not offered.
Setting cell_density to 1 configures the basic/mandatory rates to the 5.5
and 11 Mb/s DSSS rates where legacy_rates is 1. Supported rates lower
than the minimum basic/mandatory rate are not offered.

2 - High Cell Density
Setting the cell_density to 2 configures the basic/mandatory rates to the
12 and 24 Mb/s OFDM rates where legacy_rates is 0. Supported rates lower
than the minimum basic/mandatory rate are not offered.
Setting the cell_density to 2 configures the basic/mandatory rates to the
11 Mb/s DSSS rate where legacy_rates is 1. Supported rates lower than the
minimum basic/mandatory rate are not offered.

3 - Very High Cell Density
Setting the cell_density to 3 configures the basic/mandatory rates to the
24 Mb/s OFDM rate where legacy_rates is 0. Supported rates lower than the
minimum basic/mandatory rate are not offered.
Setting the cell_density to 3 only has effect where legacy_rates is 0,
else this has the same effect as being configured with a cell_density of 2.

Where specified, the basic_rate and supported_rates options continue to
override both the cell_density and legacy_rates options.

Signed-off-by: Nick Lowe 
---
 .../network/services/hostapd/files/hostapd.sh | 67 +++
 1 file changed, 54 insertions(+), 13 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index b33e8e1edc..9ff10a8a32 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -98,6 +98,7 @@ hostapd_common_add_device_config() {
config_add_int local_pwr_constraint
config_add_string require_mode
config_add_boolean legacy_rates
+   config_add_int cell_density
 
config_add_string acs_chan_bias
config_add_array hostapd_options
@@ -113,7 +114,7 @@ hostapd_prepare_device_config() {
local base_cfg=
 
json_get_vars country country_ie

Re: Fate of kernel 4.19

2020-10-25 Thread Nick

blocktrron helped me to fix the jffs2 error! :)
https://github.com/openwrt/openwrt/pull/3536

I don't require 4.19 kernel for ath79 anymore.

On 10/14/20 1:31 PM, Nick wrote:
>> the last time I tried with IPQ40xx a 5.4 kernel the switch was not working 
>> correctly [1].
> There is a working solution to revert a specific commit. It has
> something to do with double tagging support.
> Meanwhile just a "revert" does not work anymore so I created a patchfile:
> https://gist.github.com/PolynomialDivision/171316523fcee8b512e70f93573b9434
>
> Currently, openwrt-devs are trying to support DSA and then the issue
> will not longer be present. ;)
>
>> There is this  jffs2 error on ubiquity devices [0] 
> I just flashed a litebeam ac gen2 with current openwrt dev and the jffs2
> error is still present.
> So the device is still broken with 5.4 kernel. Especially, this device
> is not contained in 19.07. :/
>
> On 10/10/20 4:14 PM, Nick wrote:
>> On 10/9/20 2:19 PM, Adrian Schmutzler wrote:
>>
>>> Based on the response here, one might remove 4.19 even earlier then if 
>>> nobody actually needs it anymore.
>> The 5.4 kernel breaks a lot of my devices. I still build master with
>> 4.19 kernel.
>>
>>
>> I would be happy to switch to 5.4er kernel but it makes my devices unusable.
>>
>> [0] - https://bugs.openwrt.org/index.php?do=details_id=3272
>> [1] -
>> https://forum.openwrt.org/t/ipq40xx-low-performance-when-sending-traffic/74520
>>
>>
>> ___
>> 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

[PATCH] hostapd: Add cell_density data rates option

2020-10-18 Thread Nick Lowe

Add a cell_density option to configure data rates for normal, high and
very high cell density wireless deployments.

The purpose of using a minimum basic/mandatory data rate that is higher
than 6 Mb/s, or 5.5 Mb/s (802.11b compatible), in high cell density
environments is to transmit broadcast/multicast data frames using less
airtime or to reduce management overheads where significant co-channel
interference (CCI) exists and cannot be avoided.

Caution: Without careful design and validation, configuration of a too
high minimum basic/mandatory data rate can sacrifice connection stability
or disrupt the ability to reliably connect and authenticate for little to
no capacity benefit. This is because this configuration affects the
ability of clients to hear and demodulate management, control and
broadcast/multicast data frames.

Deployments that have not been specifically designed and validated are
usually best suited to use 6, 12 and 24 Mb/s as basic/mandatory data
rates.

Only usually seek to configure a 12 Mb/s, or 11 Mb/s (802.11b
compatible), minimum basic/mandatory rate in high cell density
deployments that have been designed and validated for this.

For many deployments, the minimum basic/mandatory data rate should not be
configured above 12 Mb/s to 18 Mb/s, 24 Mb/s or higher. Such a
configuration is only appropriate for use in very high cell density
deployment scenarios.

A cell_density of Very High (3) should only be used where a deployment
has a valid use case and has been designed and validated specifically for
this use, nearly always with highly directional antennas - an example
would be stadium deployments. For example, with a 24 Mb/s OFDM minimum
basic/mandatory data rate, approximately a -73 dBm RSSI is required to
decode frames. Many clients will not have roamed elsewhere by the time
that they experience -73 dBm and, where they do, they frequently may not
hear and be able to demodulate beacon, control or broadcast/multicast
data frames causing connectivity issues.

There is a myth that disabling lower basic/mandatory data rates will
improve roaming and avoid sticky clients. For 802.11n, 802.11ac and
802.11ax clients this is not correct as clients will shift to and use
lower MCS rates and not to the 802.11b or 802.11g/802.11a rates that are
able to be used as basic/mandatory data rates.

There is a myth that disabling lower basic/mandatory data rates will
ensure that clients only use higher data rates and that better
performance is assured. For 802.11n, 802.11ac and 802.11ax clients this
is not correct as clients will shift around and use MCS rates and not the
802.11b or 802.11g/802.11a rates that able to be used as basic/mandatory
data rates.

Cell Density

0 - Disabled (Default)
Setting cell_density to 0 does not configure data rates. This is the
default.

1 - Normal Cell Density
Setting cell_density to 1 configures the basic/mandatory rates to 6, 12
and 24 Mb/s OFDM rates where legacy_rates is 0. Supported rates lower
than the minimum basic/mandatory rate are not offered.
Setting cell_density to 1 configures the basic/mandatory rates to the 5.5
and 11 Mb/s DSSS rates where legacy_rates is 1. Supported rates lower
than the minimum basic/mandatory rate are not offered.

2 - High Cell Density
Setting the cell_density to 2 configures the basic/mandatory rates to the
12 and 24 Mb/s OFDM rates where legacy_rates is 0. Supported rates lower
than the minimum basic/mandatory rate are not offered.
Setting the cell_density to 2 configures the basic/mandatory rates to the
11 Mb/s DSSS rate where legacy_rates is 1. Supported rates lower than the
minimum basic/mandatory rate are not offered.

3 - Very High Cell Density
Setting the cell_density to 3 configures the basic/mandatory rates to the
24 Mb/s OFDM rate where legacy_rates is 0. Supported rates lower than the
minimum basic/mandatory rate are not offered.
Setting the cell_density to 3 only has effect where legacy_rates is 0,
else this has the same effect as being configured with a cell_density of 2.

Where specified, the basic_rate and supported_rates options continue to
override both the cell_density and legacy_rates options.

Signed-off-by: Nick Lowe 
---
 .../network/services/hostapd/files/hostapd.sh | 70 +++
 1 file changed, 57 insertions(+), 13 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index b33e8e1edc..2bf67601c5 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -98,6 +98,7 @@ hostapd_common_add_device_config() {
config_add_int local_pwr_constraint
config_add_string require_mode
config_add_boolean legacy_rates
+   config_add_int cell_density
 
config_add_string acs_chan_bias
config_add_array hostapd_options
@@ -113,7 +114,7 @@ hostapd_prepare_device_config() {
local base_cfg=
 
json_get_vars country country_ie

Re: Fate of kernel 4.19

2020-10-14 Thread Nick

> the last time I tried with IPQ40xx a 5.4 kernel the switch was not working 
> correctly [1].
There is a working solution to revert a specific commit. It has
something to do with double tagging support.
Meanwhile just a "revert" does not work anymore so I created a patchfile:
https://gist.github.com/PolynomialDivision/171316523fcee8b512e70f93573b9434

Currently, openwrt-devs are trying to support DSA and then the issue
will not longer be present. ;)

> There is this  jffs2 error on ubiquity devices [0] 
I just flashed a litebeam ac gen2 with current openwrt dev and the jffs2
error is still present.
So the device is still broken with 5.4 kernel. Especially, this device
is not contained in 19.07. :/

On 10/10/20 4:14 PM, Nick wrote:
> On 10/9/20 2:19 PM, Adrian Schmutzler wrote:
>
>> Based on the response here, one might remove 4.19 even earlier then if 
>> nobody actually needs it anymore.
> The 5.4 kernel breaks a lot of my devices. I still build master with
> 4.19 kernel.
>
>
> I would be happy to switch to 5.4er kernel but it makes my devices unusable.
>
> [0] - https://bugs.openwrt.org/index.php?do=details_id=3272
> [1] -
> https://forum.openwrt.org/t/ipq40xx-low-performance-when-sending-traffic/74520
>
>
> ___
> 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: Fate of kernel 4.19

2020-10-10 Thread Nick

On 10/9/20 2:19 PM, Adrian Schmutzler wrote:

> Based on the response here, one might remove 4.19 even earlier then if nobody 
> actually needs it anymore.
The 5.4 kernel breaks a lot of my devices. I still build master with
4.19 kernel.
There is this  jffs2 error on ubiquity devices [0] and the last time I
tried with IPQ40xx a 5.4 kernel the switch was not working correctly [1].

I would be happy to switch to 5.4er kernel but it makes my devices unusable.

[0] - https://bugs.openwrt.org/index.php?do=details_id=3272
[1] -
https://forum.openwrt.org/t/ipq40xx-low-performance-when-sending-traffic/74520


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] hostapd: Add cell_density data rates option

2020-10-08 Thread Nick Lowe

> As briefly mentioned on IRC, I have concerns that this might interfere with
> clients using buggy wireless implementations. I've noticed 802.11g clients
> not connecting / listing networks which do not offer a 6 Mbit/s basic rate.

Yes, completely agree. This setting does have interoperability
implications with some 802.11b and 802.11g clients that have buggy
802.11 stacks.

The notable compatibility issues that I am aware of are:

1) Some 802.11g devices require the original 802.11, prior to 802.11b,
defined data rates to be offered as basic/mandatory, the 1 Mb/s and 2
Mb/s rates, despite them being 802.11g devices. Nintendo specifically
comes to mind here with their older devices.

2) Some 802.11g devices require either the 1 Mb/s and 2 Mb/s rates as
minimum basic/mandatory, or else the 6 Mb/s rate as minimum
basic/mandatory. Aged handheld scanners typically used in warehouses
and some printers specifically come to mind here.

To my knowledge, such clients are not generally encountered, common
devices in use in the present day.

> On the other hand, these kind of clients also show frequent issues when used
> with FT or (god forbid) PSK2-SAE mixed mode.
>
> Therefore I'm in favor of adding a brief notice to this option to LuCI, that
> tampering with this setting might lead to issues with some clients.

Yes, completely agreed. Both the documentation for the new
cell_density setting and the LuCI UI should highlight this.

> That said, the proposed settings and rate sets look sensible to me, given they
> are abstracted from easily explained toggles.

Thank you very much for the review. Do you think this specific patch
could be merged in its present state? If yes, please could you do so?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] hostapd: Add cell_density data rates option

2020-10-02 Thread Nick Lowe

Hi all,

Please may I request any thoughts and feedback on this proposed patch
to the hostapd config generation shell script to add a new
cell_density configuration option?

This would subsequently allow for a LuCI-exposed option to then be
added via a follow up patch for easy, less error prone configuration
of data rates for normal, high and very high density deployments.

Currently, it is both easy to misunderstand basic/mandatory and
optional rates and to misconfigure these, and the current basic_rate
and supported_rates options are not exposed in Luci and are therefore
not easily discoverable or accessible.
I feel that the basic_rate and supported_rates options are best
abstracted via a new setting for general use cases before being
exposed to LuCI.

Where specified, the basic_rate and supported_rates options would
override both the cell_density and legacy_rates options.

Cheers,

Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] hostapd: Add cell_density data rates option

2020-09-26 Thread Nick Lowe

Add a cell_density option to configure data rates for normal, high and
very high cell density wireless deployments.

The purpose of using a minimum basic/mandatory data rate that is higher
than 6 Mb/s, or 5.5 Mb/s (802.11b compatible), in high cell density
environments is to transmit broadcast/multicast data frames using less
airtime or to reduce management overheads where significant co-channel
interference (CCI) exists and cannot be avoided.

Caution: Without careful design and validation, configuration of a too
high minimum basic/mandatory data rate can sacrifice connection stability
or disrupt the ability to reliably connect and authenticate for little to
no capacity benefit. This is because this configuration affects the
ability of clients to hear and demodulate management, control and
broadcast/multicast data frames.

Deployments that have not been specifically designed and validated are
usually best suited to use 6, 12 and 24 Mb/s as basic/mandatory data
rates.

Only usually seek to configure a 12 Mb/s, or 11 Mb/s (802.11b
compatible), minimum basic/mandatory rate in high cell density
deployments that have been designed and validated for this.

For many deployments, the minimum basic/mandatory data rate should not be
configured above 12 Mb/s to 18 Mb/s, 24 Mb/s or higher. Such a
configuration is only appropriate for use in very high cell density
deployment scenarios.

A cell_density of Very High (3) should only be used where a deployment
has a valid use case and has been designed and validated specifically for
this use, nearly always with highly directional antennas - an example
would be stadium deployments. For example, with a 24 Mb/s OFDM minimum
basic/mandatory data rate, approximately a -73 dBm RSSI is required to
decode frames. Many clients will not have roamed elsewhere by the time
that they experience -73 dBm and, where they do, they frequently may not
hear and be able to demodulate beacon, control or broadcast/multicast
data frames causing connectivity issues.

There is a myth that disabling lower basic/mandatory data rates will
improve roaming and avoid sticky clients. For 802.11n, 802.11ac and
802.11ax clients this is not correct as clients will shift to and use
lower MCS rates and not to the 802.11b or 802.11g/802.11a rates that are
able to be used as basic/mandatory data rates.

There is a myth that disabling lower basic/mandatory data rates will
ensure that clients only use higher data rates and that better
performance is assured. For 802.11n, 802.11ac and 802.11ax clients this
is not correct as clients will shift around and use MCS rates and not the
802.11b or 802.11g/802.11a rates that able to be used as basic/mandatory
data rates.

Cell Density

0 - Disabled (Default)
Setting cell_density to 0 does not configure data rates. This is the
default.

1 - Normal Cell Density
Setting cell_density to 1 configures the basic/mandatory rates to 6, 12
and 24 Mb/s OFDM rates where legacy_rates is 0. Supported rates lower
than the minimum basic/mandatory rate are not offered.
Setting cell_density to 1 configures the basic/mandatory rates to the 5.5
and 11 Mb/s DSSS rates where legacy_rates is 1. Supported rates lower
than the minimum basic/mandatory rate are not offered.

2 - High Cell Density
Setting the cell_density to 2 configures the basic/mandatory rates to the
12 and 24 Mb/s OFDM rates where legacy_rates is 0. Supported rates lower
than the minimum basic/mandatory rate are not offered.
Setting the cell_density to 2 configures the basic/mandatory rates to the
11 Mb/s DSSS rate where legacy_rates is 1. Supported rates lower than the
minimum basic/mandatory rate are not offered.

3 - Very High Cell Density
Setting the cell_density to 3 configures the basic/mandatory rates to the
24 Mb/s OFDM rate where legacy_rates is 0. Supported rates lower than the
minimum basic/mandatory rate are not offered.
Setting the cell_density to 3 only has effect where legacy_rates is 0,
this has the same effect as being configured with a cell_density of 2.

Where specified, the basic_rate and supported_rates options continue to
override both the cell_density and legacy_rates options.

Signed-off-by: Nick Lowe 
---
 .../network/services/hostapd/files/hostapd.sh | 67 +++
 1 file changed, 54 insertions(+), 13 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index b33e8e1edc..d2a4ada1ad 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -98,6 +98,7 @@ hostapd_common_add_device_config() {
config_add_int local_pwr_constraint
config_add_string require_mode
config_add_boolean legacy_rates
+   config_add_int cell_density
 
config_add_string acs_chan_bias
config_add_array hostapd_options
@@ -113,7 +114,7 @@ hostapd_prepare_device_config() {
local base_cfg=
 
json_get_vars country country_ie

Re: Upcoming 19.07.4 and 18.07.9 stable releases

2020-09-03 Thread Nick Lowe

It seems there is an important ath10k patch included in the 4.4.235,
4.9.235, 4.14.196 and 4.19.143, 5.4.62 LTS kernels that is applicable
for OpenWRT users who are not using an up to date CT driver with Wave
2 QCA 802.11ac generation hardware, it is already merged for CT.

It resolves a PCIe hang seen due to the DMA burst size value meaning
different things between Wave 1 and Wave 2 hardware.

The issue resolved is that a value of 0 for the DMA burst size has a
different meaning and instruction depending on the generation.

Cheers,

Nick

On Sun, Aug 30, 2020 at 1:45 PM Baptiste Jonglez
 wrote:
>
> On 29-08-20, Baptiste Jonglez wrote:
> > On 28-08-20, Hauke Mehrtens wrote:
> > > Hi,
> > >
> > > I would like to do a 19.07.4 and a 18.06.9 release on Sunday or
> > > beginning of next week.
> >
> > Cool, looks good to me.
> >
> > > Is there something missing in the current branches which should get into
> > > this release?
> >
> > There's the ath10k-ct-firmware bump for 19.07: 
> > https://patchwork.ozlabs.org/project/openwrt/list/?q=19.07
> >
> > I plan to look at the LuCI issue mentioned here: 
> > https://openwrt.org/docs/guide-developer/releases/goals/19.07.4
>
> I backported a fix for the LuCI issue, the pull request needs to be merged
> before the 19.07.4 release: https://github.com/openwrt/luci/pull/4402
>
> Thanks,
> Baptiste
> ___
> 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

jffs2 errors with 5.4 kernel

2020-08-17 Thread Nick

At the first start after flashing, there is often a "mount_root: failed
to sync jffs2 overlay2".
This problem only occurs with the 5.4 kernel. If I build a 4.19 kernel
with master, it works.
We have tested
- FRITZ!Box 4040 (ipq40xx)
- Nanobeam AC Gen2 (ath79)
- Nanostation AC loco (ath79)

On the UBNT devices it is even worse, because the filesystem is broken
after the first flash and does not keep changes after a reboot. There
are even other problems, such as the root password being incorrect.
A typical log after a reboot log contains several: "Newly-erased block
contained word 0x0 at offset 0x0042"
More Infos and logs for ubnt devices:
https://bugs.openwrt.org/index.php?do=details_id=3272

Logs AVM Fritz!Box:
-
https://gist.github.com/PolynomialDivision/96bfd98d723f288c617fd96f8ff04c22

I think many more devices are affected. Keep an eye out for jffs2 errors.

We believe that the mx25l12835f (16-pin package) chip is causing the
problem.

OpenWrt Forum:
https://forum.openwrt.org/t/nanobeam-ac-gen-2/70640/26

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

umdns: fails to compile with gcc10

2020-07-13 Thread Nick

If u try to compile umdns with gcc10 it will fail with:

> service.c:240:10: error: 'strcpy' offset 6 from the object at 'b' is
> out of the bounds of referenced subobject 'name' with type 'uint8_t[]'
> {aka 'unsigned char[]'} at offset 6 [-Werror=array-bounds]
More detailed error:
https://github.com/berlin-open-wireless-lab/DAWN/issues/109#issuecomment-657483908

Bests,
Nick


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Nick

I would suggest doing this PR as patch like freifunk berlin is doing it:
https://github.com/freifunk-berlin/firmware/commit/93f9a026e025c7b663369f5284cec0bb91345220

Otherwise, olsrd won't compile anymore. :/ Or making a fork, because
olsrd seems not to be maintained anymore.

On 07.06.20 22:27, Nick wrote:
> Here is a PR that is fixing the issue. Why is that not merged? :/
>
> https://github.com/OLSR/olsrd/pull/79/files
>
> On 07.06.20 22:03, Rosen Penev wrote:
>>> Le 7 juin 2020 à 1:00 PM, Nick  a écrit :
>>>
>>> I can not compile olsrd daemon with gcc9.
>>>> #define isNaN(x) (x != x)
>>>> ...
>>>> if (!isNaN(gpsdata->fix.time)) {
>>> Here fix.time is a struct timespec.
>>> The call is just wrong, or? Why should I check a struct for a valid float?
>> This broke when gpsutils got updated. API change with libgps.
>>> ___
>>> 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

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Nick

Here is a PR that is fixing the issue. Why is that not merged? :/

https://github.com/OLSR/olsrd/pull/79/files

On 07.06.20 22:03, Rosen Penev wrote:
>
>> Le 7 juin 2020 à 1:00 PM, Nick  a écrit :
>>
>> I can not compile olsrd daemon with gcc9.
>>> #define isNaN(x) (x != x)
>>> ...
>>> if (!isNaN(gpsdata->fix.time)) {
>> Here fix.time is a struct timespec.
>> The call is just wrong, or? Why should I check a struct for a valid float?
> This broke when gpsutils got updated. API change with libgps.
>> ___
>> 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

[OpenWrt-Devel] olsrd: not compiling with gcc 9

2020-06-07 Thread Nick

I can not compile olsrd daemon with gcc9.
> #define isNaN(x) (x != x)
> ...
> if (!isNaN(gpsdata->fix.time)) {
Here fix.time is a struct timespec.
The call is just wrong, or? Why should I check a struct for a valid float?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Issue connecting with Quectel EM20-G modem on openwrt

2020-05-24 Thread Nick via openwrt-devel

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 ---
FWIW, I’m able to use this modem just fine on a USB3.0 M.2 slot with the 
current version of MM and libqmi.  Let me know if you need any details.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Merged: umdns: fix unused error

2020-04-05 Thread Nick

Thanks for your quick reply. :)
Should I update the umdns Makefile in the openwrt.git, too?

On 05.04.20 10:00, Kevin Darbyshire-Bryant wrote:
> Merged.
> Thank you!
>
>
> ___
> 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] [PATCH v2 1/3] kernel: package f71882fg hwmon driver

2020-03-24 Thread Nick Bowler

This driver enables hardware monitoring support using the sensors
found in many Fintek Super-IO chips.

Signed-off-by: Nick Bowler 
---
 v2: Added @TARGET_x86 dependency

 package/kernel/linux/modules/hwmon.mk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/package/kernel/linux/modules/hwmon.mk 
b/package/kernel/linux/modules/hwmon.mk
index 1f4e4558a9..2552a32a56 100644
--- a/package/kernel/linux/modules/hwmon.mk
+++ b/package/kernel/linux/modules/hwmon.mk
@@ -107,6 +107,21 @@ endef
 $(eval $(call KernelPackage,hwmon-gpiofan))
 
 
+define KernelPackage/hwmon-f71882fg
+  TITLE:=F71882FG compatible monitoring support
+  KCONFIG:=CONFIG_SENSORS_F71882FG
+  FILES:=$(LINUX_DIR)/drivers/hwmon/f71882fg.ko
+  AUTOLOAD:=$(call AutoProbe,f71882fg)
+  $(call AddDepends/hwmon,@TARGET_x86)
+endef
+
+define KernelPackage/hwmon-f71882fg/description
+ Kernel module for hardware monitoring via many Fintek Super-IO chips.
+endef
+
+$(eval $(call KernelPackage,hwmon-f71882fg))
+
+
 define KernelPackage/hwmon-ina209
   TITLE:=INA209 monitoring support
   KCONFIG:=CONFIG_SENSORS_INA209
-- 
2.24.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/3] kernel: package f71808e-wdt driver

2020-03-24 Thread Nick Bowler

This driver enables support for the watchdog timers found in many
Fintek Super-IO chips.

Signed-off-by: Nick Bowler 
---
 v2: Added @TARGET_x86 dependency

 package/kernel/linux/modules/other.mk | 16 
 1 file changed, 16 insertions(+)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index f1a70bf069..1f13cb7aa7 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -1228,3 +1228,19 @@ define KernelPackage/it87-wdt/description
 endef
 
 $(eval $(call KernelPackage,it87-wdt))
+
+
+define KernelPackage/f71808e-wdt
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Fintek F718xx/F818xx Watchdog Timer
+  DEPENDS:=@TARGET_x86
+  KCONFIG:=CONFIG_F71808E_WDT
+  FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/f71808e_wdt.ko
+  AUTOLOAD:=$(call AutoProbe,f71808e-wdt,1)
+endef
+
+define KernelPackage/f71808e-wdt/description
+  Kernel module for the watchdog timer found on many Fintek Super-IO chips.
+endef
+
+$(eval $(call KernelPackage,f71808e-wdt))
-- 
2.24.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 3/3] kernel: package gpio-f7188x driver

2020-03-24 Thread Nick Bowler

This driver enables support for the GPIO capabilities found in many
Fintek Super-IO chips.

Signed-off-by: Nick Bowler 
---
 v2: Added @TARGET_x86 dependency

 package/kernel/linux/modules/other.mk | 16 
 1 file changed, 16 insertions(+)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index 1f13cb7aa7..43709228f9 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -214,6 +214,22 @@ endef
 $(eval $(call KernelPackage,gpio-dev))
 
 
+define KernelPackage/gpio-f7188x
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Fintek F718xx/F818xx GPIO Support
+  DEPENDS:=@GPIO_SUPPORT @TARGET_x86
+  KCONFIG:=CONFIG_GPIO_F7188X
+  FILES:=$(LINUX_DIR)/drivers/gpio/gpio-f7188x.ko
+  AUTOLOAD:=$(call AutoProbe,gpio-f7188x)
+endef
+
+define KernelPackage/gpio-f7188x/description
+  Kernel module for the GPIOs found on many Fintek Super-IO chips.
+endef
+
+$(eval $(call KernelPackage,gpio-f7188x))
+
+
 define KernelPackage/gpio-mcp23s08
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Microchip MCP23xxx I/O expander
-- 
2.24.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 0/3] Add kernel support for Fintek Super-IO chips

2020-03-24 Thread Nick Bowler

This series enables packaging of the Linux hwmon, watchdog and gpio
drivers that support multiple Fintek Super-IO chips.  In particular,
the Fintek F71869A is used on the Jetway NF99FL board and the stock
OpenWRT kernels appear to completely lack drivers for this chip.

v2: Add @TARGET_x86 dependency to these drivers.

Nick Bowler (3):
  kernel: package f71882fg hwmon driver
  kernel: package f71808e-wdt driver
  kernel: package gpio-f7188x driver

 package/kernel/linux/modules/hwmon.mk | 15 +
 package/kernel/linux/modules/other.mk | 32 +++
 2 files changed, 47 insertions(+)

-- 
2.24.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/3] Add kernel support for Fintek Super-IO chips

2020-03-24 Thread Nick Bowler

On 2020-03-21, Daniel Golle  wrote:
> On Wed, Mar 18, 2020 at 11:27:09PM -0400, Nick Bowler wrote:
>> This series enables packaging of the Linux hwmon, watchdog and gpio
>> drivers that support multiple Fintek Super-IO chips.  In particular,
>> the Fintek F71869A is used on the Jetway NF99FL board and the stock
>> OpenWRT kernels appear to completely lack drivers for this chip.
>
> The driver looks ACPI/x86-specific, please add target dependency or
> move the package definition to target/linux/x86/modules.mk.

I think there shouldn't be anything _inherently_ x86 specific about
the drivers themselves although probably nobody uses Super-IO chips
like these outside of the PC-compatible world.

I do see that most (but not all) drivers for Super-IO controllers
packaged in openwrt currently have a TARGET_x86 dependency, so I
will submit v2 with the dependency added to these new packages.

Cheers,
  Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hostapd: expose beacon reports through ubus

2020-03-22 Thread Nick

The Github PR: https://github.com/openwrt/openwrt/pull/2597
If you look in the comments, another person tested the PR already.

I would appreciate, if that could be merged.

Until now, you only can send beacon request via ubus, but not receive
the actual answer from the client via ubus.
I changed that with the patch.

On 22.03.20 11:56, Nick Hainke wrote:
> Subscribe to beacon reports through ubus.
> Can be used for hearing map and client steering purposes.
>
> First enable rrm:
> ubus call hostapd.wlan0 bss_mgmt_enable '{"beacon_report":True}'
>
> Subscribe to the hostapd notifications via ubus.
>
> Request beacon report:
> ubus call hostapd.wlan0 rrm_beacon_req '{"addr":"00:xx:xx:xx:xx:xx", 
> "op_class":0, "channel":1,"duration":1,"mode":2,"bssid":"ff:ff:ff:ff:ff:ff", 
> "ssid":""}'
>
> Signed-off-by: Nick Hainke 
> ---
>  .../hostapd/patches/600-ubus_support.patch| 12 ++
>  .../services/hostapd/src/src/ap/ubus.c| 24 +++
>  .../services/hostapd/src/src/ap/ubus.h|  6 +
>  3 files changed, 42 insertions(+)
>
> diff --git a/package/network/services/hostapd/patches/600-ubus_support.patch 
> b/package/network/services/hostapd/patches/600-ubus_support.patch
> index 6842c0e63e..b2860780eb 100644
> --- a/package/network/services/hostapd/patches/600-ubus_support.patch
> +++ b/package/network/services/hostapd/patches/600-ubus_support.patch
> @@ -458,3 +458,15 @@
>   case 'o':
>   params.override_driver = optarg;
>   break;
> +--- a/src/ap/rrm.c
>  b/src/ap/rrm.c
> +@@ -89,6 +89,9 @@ static void hostapd_handle_beacon_report
> + return;
> + wpa_msg(hapd->msg_ctx, MSG_INFO, BEACON_RESP_RX MACSTR " %u %02x %s",
> + MAC2STR(addr), token, rep_mode, report);
> ++if (len < sizeof(struct rrm_measurement_beacon_report))
> ++return;
> ++hostapd_ubus_notify_beacon_report(hapd, addr, token, rep_mode, (struct 
> rrm_measurement_beacon_report*) pos, len);
> + }
> + 
> + 
> diff --git a/package/network/services/hostapd/src/src/ap/ubus.c 
> b/package/network/services/hostapd/src/src/ap/ubus.c
> index e25c3294ee..eb26c14972 100644
> --- a/package/network/services/hostapd/src/src/ap/ubus.c
> +++ b/package/network/services/hostapd/src/src/ap/ubus.c
> @@ -1269,3 +1269,27 @@ void hostapd_ubus_notify(struct hostapd_data *hapd, 
> const char *type, const u8 *
>  
>   ubus_notify(ctx, >ubus.obj, type, b.head, -1);
>  }
> +
> +void hostapd_ubus_notify_beacon_report(struct hostapd_data *hapd, const u8 
> *addr, u8 token, u8 rep_mode, struct rrm_measurement_beacon_report *rep, 
> size_t len)
> +{
> + if (!hapd->ubus.obj.has_subscribers)
> + return;
> +
> + if (!addr)
> + return;
> +
> + blob_buf_init(, 0);
> + blobmsg_add_macaddr(, "address", addr);
> + blobmsg_add_u16(, "op-class", rep->op_class);
> + blobmsg_add_u16(, "channel", rep->channel);
> + blobmsg_add_u64(, "start-time", rep->start_time);
> + blobmsg_add_u16(, "duration", rep->duration);
> + blobmsg_add_u16(, "report-info", rep->report_info);
> + blobmsg_add_u16(, "rcpi", rep->rcpi);
> + blobmsg_add_u16(, "rsni", rep->rsni);
> + blobmsg_add_macaddr(, "bssid", rep->bssid);
> + blobmsg_add_u16(, "atenna-id", rep->antenna_id);
> + blobmsg_add_u16(, "parent-tsf", rep->parent_tsf);
> +
> + ubus_notify(ctx, >ubus.obj, "beacon-report", b.head, -1);
> +}
> diff --git a/package/network/services/hostapd/src/src/ap/ubus.h 
> b/package/network/services/hostapd/src/src/ap/ubus.h
> index 27acd32659..64ff7f5787 100644
> --- a/package/network/services/hostapd/src/src/ap/ubus.h
> +++ b/package/network/services/hostapd/src/src/ap/ubus.h
> @@ -26,6 +26,7 @@ struct hostapd_ubus_request {
>  struct hostapd_iface;
>  struct hostapd_data;
>  struct hapd_interfaces;
> +struct rrm_measurement_beacon_report;
>  
>  #ifdef UBUS_SUPPORT
>  
> @@ -45,6 +46,7 @@ void hostapd_ubus_free_bss(struct hostapd_data *hapd);
>  
>  int hostapd_ubus_handle_event(struct hostapd_data *hapd, struct 
> hostapd_ubus_request *req);
>  void hostapd_ubus_notify(struct hostapd_data *hapd, const char *type, const 
> u8 *mac);
> +void hostapd_ubus_notify_beacon_report(struct hostapd_data *hapd, const u8 
> *addr, u8 token, u8 rep_mode, struct rrm_measurement_beacon_report *rep, 
> size_t len);
>  
>  vo

[OpenWrt-Devel] [PATCH] hostapd: expose beacon reports through ubus

2020-03-22 Thread Nick Hainke

Subscribe to beacon reports through ubus.
Can be used for hearing map and client steering purposes.

First enable rrm:
ubus call hostapd.wlan0 bss_mgmt_enable '{"beacon_report":True}'

Subscribe to the hostapd notifications via ubus.

Request beacon report:
ubus call hostapd.wlan0 rrm_beacon_req '{"addr":"00:xx:xx:xx:xx:xx", 
"op_class":0, "channel":1,"duration":1,"mode":2,"bssid":"ff:ff:ff:ff:ff:ff", 
"ssid":""}'

Signed-off-by: Nick Hainke 
---
 .../hostapd/patches/600-ubus_support.patch| 12 ++
 .../services/hostapd/src/src/ap/ubus.c| 24 +++
 .../services/hostapd/src/src/ap/ubus.h|  6 +
 3 files changed, 42 insertions(+)

diff --git a/package/network/services/hostapd/patches/600-ubus_support.patch 
b/package/network/services/hostapd/patches/600-ubus_support.patch
index 6842c0e63e..b2860780eb 100644
--- a/package/network/services/hostapd/patches/600-ubus_support.patch
+++ b/package/network/services/hostapd/patches/600-ubus_support.patch
@@ -458,3 +458,15 @@
case 'o':
params.override_driver = optarg;
break;
+--- a/src/ap/rrm.c
 b/src/ap/rrm.c
+@@ -89,6 +89,9 @@ static void hostapd_handle_beacon_report
+   return;
+   wpa_msg(hapd->msg_ctx, MSG_INFO, BEACON_RESP_RX MACSTR " %u %02x %s",
+   MAC2STR(addr), token, rep_mode, report);
++  if (len < sizeof(struct rrm_measurement_beacon_report))
++  return;
++  hostapd_ubus_notify_beacon_report(hapd, addr, token, rep_mode, (struct 
rrm_measurement_beacon_report*) pos, len);
+ }
+ 
+ 
diff --git a/package/network/services/hostapd/src/src/ap/ubus.c 
b/package/network/services/hostapd/src/src/ap/ubus.c
index e25c3294ee..eb26c14972 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -1269,3 +1269,27 @@ void hostapd_ubus_notify(struct hostapd_data *hapd, 
const char *type, const u8 *
 
ubus_notify(ctx, >ubus.obj, type, b.head, -1);
 }
+
+void hostapd_ubus_notify_beacon_report(struct hostapd_data *hapd, const u8 
*addr, u8 token, u8 rep_mode, struct rrm_measurement_beacon_report *rep, size_t 
len)
+{
+   if (!hapd->ubus.obj.has_subscribers)
+   return;
+
+   if (!addr)
+   return;
+
+   blob_buf_init(, 0);
+   blobmsg_add_macaddr(, "address", addr);
+   blobmsg_add_u16(, "op-class", rep->op_class);
+   blobmsg_add_u16(, "channel", rep->channel);
+   blobmsg_add_u64(, "start-time", rep->start_time);
+   blobmsg_add_u16(, "duration", rep->duration);
+   blobmsg_add_u16(, "report-info", rep->report_info);
+   blobmsg_add_u16(, "rcpi", rep->rcpi);
+   blobmsg_add_u16(, "rsni", rep->rsni);
+   blobmsg_add_macaddr(, "bssid", rep->bssid);
+   blobmsg_add_u16(, "atenna-id", rep->antenna_id);
+   blobmsg_add_u16(, "parent-tsf", rep->parent_tsf);
+
+   ubus_notify(ctx, >ubus.obj, "beacon-report", b.head, -1);
+}
diff --git a/package/network/services/hostapd/src/src/ap/ubus.h 
b/package/network/services/hostapd/src/src/ap/ubus.h
index 27acd32659..64ff7f5787 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.h
+++ b/package/network/services/hostapd/src/src/ap/ubus.h
@@ -26,6 +26,7 @@ struct hostapd_ubus_request {
 struct hostapd_iface;
 struct hostapd_data;
 struct hapd_interfaces;
+struct rrm_measurement_beacon_report;
 
 #ifdef UBUS_SUPPORT
 
@@ -45,6 +46,7 @@ void hostapd_ubus_free_bss(struct hostapd_data *hapd);
 
 int hostapd_ubus_handle_event(struct hostapd_data *hapd, struct 
hostapd_ubus_request *req);
 void hostapd_ubus_notify(struct hostapd_data *hapd, const char *type, const u8 
*mac);
+void hostapd_ubus_notify_beacon_report(struct hostapd_data *hapd, const u8 
*addr, u8 token, u8 rep_mode, struct rrm_measurement_beacon_report *rep, size_t 
len);
 
 void hostapd_ubus_add(struct hapd_interfaces *interfaces);
 void hostapd_ubus_free(struct hapd_interfaces *interfaces);
@@ -78,6 +80,10 @@ static inline void hostapd_ubus_notify(struct hostapd_data 
*hapd, const char *ty
 {
 }
 
+static inline void hostapd_ubus_notify_beacon_report(struct hostapd_data 
*hapd, const u8 *addr, u8 token, u8 rep_mode, struct 
rrm_measurement_beacon_report *rep, size_t len)
+{
+}
+
 static inline void hostapd_ubus_add(struct hapd_interfaces *interfaces)
 {
 }
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] kernel: package f71808e-wdt driver

2020-03-18 Thread Nick Bowler

This driver enables support for the watchdog timers found in many
Fintek Super-IO chips.

Signed-off-by: Nick Bowler 
---
 package/kernel/linux/modules/other.mk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index 16b438461e..75dab4c78c 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -1195,3 +1195,18 @@ define KernelPackage/it87-wdt/description
 endef
 
 $(eval $(call KernelPackage,it87-wdt))
+
+
+define KernelPackage/f71808e-wdt
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Fintek F718xx/F818xx Watchdog Timer
+  KCONFIG:=CONFIG_F71808E_WDT
+  FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/f71808e_wdt.ko
+  AUTOLOAD:=$(call AutoProbe,f71808e-wdt,1)
+endef
+
+define KernelPackage/f71808e-wdt/description
+  Kernel module for the watchdog timer found on many Fintek Super-IO chips.
+endef
+
+$(eval $(call KernelPackage,f71808e-wdt))
-- 
2.24.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/3] Add kernel support for Fintek Super-IO chips

2020-03-18 Thread Nick Bowler

This series enables packaging of the Linux hwmon, watchdog and gpio
drivers that support multiple Fintek Super-IO chips.  In particular,
the Fintek F71869A is used on the Jetway NF99FL board and the stock
OpenWRT kernels appear to completely lack drivers for this chip.

Nick Bowler (3):
  kernel: package f71882fg hwmon driver
  kernel: package f71808e-wdt driver
  kernel: package gpio-f7188x driver

 package/kernel/linux/modules/hwmon.mk | 15 +
 package/kernel/linux/modules/other.mk | 31 +++
 2 files changed, 46 insertions(+)

-- 
2.24.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

1 2 >

1 - 100 of 145 matches

Mail list logo