[LEDE-DEV] [PATCH] procd: Fix memory leaks found by cppcheck

2016-12-03 Thread Rosen Penev 
Signed-off by: Rosen Penev 
---
 initd/mkdev.c  | 1 +
 service/instance.c | 1 +
 trace/trace.c  | 5 -
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/initd/mkdev.c b/initd/mkdev.c
index e6d3d0c..e826707 100644
--- a/initd/mkdev.c
+++ b/initd/mkdev.c
@@ -121,5 +121,6 @@ int mkdev(const char *name, int _mode)
n_patterns = 1;
find_devs(true);
find_devs(false);
+   free(pattern);
return chdir("/");
 }
diff --git a/service/instance.c b/service/instance.c
index d75e1ab..8838049 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -263,6 +263,7 @@ instance_writepid(struct service_instance *in)
if (fprintf(_pidfile, "%d\n", in->proc.pid) < 0) {
ERROR("failed to write pidfile: %s: %d (%s)",
in->pidfile, errno, strerror(errno));
+   fclose(_pidfile);
return 2;
}
if (fclose(_pidfile)) {
diff --git a/trace/trace.c b/trace/trace.c
index b0005b8..662010e 100644
--- a/trace/trace.c
+++ b/trace/trace.c
@@ -176,7 +176,7 @@ int main(int argc, char **argv, char **envp)
if (child == 0) {
char **_argv = calloc(argc + 1, sizeof(char *));
char **_envp;
-   char preload[] = "LD_PRELOAD=/lib/libpreload-trace.so";
+   char *preload = "LD_PRELOAD=/lib/libpreload-trace.so";
int envc = 1;
int ret;
 
@@ -191,6 +191,9 @@ int main(int argc, char **argv, char **envp)
 
ret = execve(_argv[0], _argv, envp);
ERROR("failed to exec %s: %s\n", _argv[0], strerror(errno));
+
+   free(_argv);
+   free(_envp);
return ret;
}
 
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH] [kernel] fix XW ethernet

2016-12-03 Thread Joe Ayers 
> Hi Joe,
>
> Thanks for that. What images are you using for the other XW images with
> the 004dd023 PHY? It looks like we don't have device specific ones for
> those in the tree yet.
>
> - Felix

 loco-m-xw image in use and 004dd023 PHY align:
   - AirGrid M5 XW
   - NBE-M5-16 XW
   - NBE-M5-19 XW
   - NS-M5 Loco XW
   - NBE/PBE-M2-400 XW
   - NBE/PBE-M5-300 XW

rocket-m-xw image in use and 004dd072 PHY align:
  - NBE/PBE-M5-400 XW
  - NBE/PBE-M5-620 XW <- m25p80 spi0.0: found s25fl064k, expected m25p80
  - Rocket M5 XW

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH ubox] kmodloader: Fix typo in error message

2016-12-03 Thread Florian Fainelli 
Signed-off-by: Florian Fainelli 
---
 kmodloader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kmodloader.c b/kmodloader.c
index 5ba75c1aa36d..40edbf0260b0 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -610,7 +610,7 @@ static int main_insmod(int argc, char **argv)
}
 
if (init_module_folders()) {
-   fprintf(stderr, "falied to find the folder holding the 
modules\n");
+   fprintf(stderr, "Failed to find the folder holding the 
modules\n");
return -1;
}
 
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] uqmi: Add support for specifying profile index

2016-12-03 Thread Matti Laakso 
Update uqmi to latest version, which brings about support for
specifying a call profile index instead of APN. A specific index
different from 1 must be used for some service provider and modem
combinations.

Also make autoconnect optional and default it to off due to it not
working with statically configured IPv6.

Signed-off-by: Matti Laakso 
---
 package/network/utils/uqmi/Makefile|   6 +-
 .../utils/uqmi/files/lib/netifd/proto/qmi.sh   | 164 +++--
 2 files changed, 88 insertions(+), 82 deletions(-)

diff --git a/package/network/utils/uqmi/Makefile 
b/package/network/utils/uqmi/Makefile
index 06d9ac2..2b832d4 100644
--- a/package/network/utils/uqmi/Makefile
+++ b/package/network/utils/uqmi/Makefile
@@ -1,15 +1,15 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=uqmi
-PKG_VERSION:=2016-08-23
+PKG_VERSION:=2016-11-22
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=$(LEDE_GIT)/project/uqmi.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=eb1dec7d0dc283a7f61aa574a443a0ab61f8793f
+PKG_SOURCE_VERSION:=d682e966615fc652da6e4e26b57aa3adfebeb2fe
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
-PKG_MIRROR_MD5SUM:=e6273e6aee6fce419e13f84439c240d48c32020fce7f07b2dc123ae32742382c
+PKG_MIRROR_MD5SUM:=a82c4682d07870d1bdf63e475afe1c1fffabf0954a49e0e67058dae0d4f6f71c
 PKG_MAINTAINER:=Matti Laakso 
 
 PKG_LICENSE:=GPL-2.0
diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index 1235698..ed25ea7 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -15,27 +15,27 @@ proto_qmi_init_config() {
proto_config_add_string username
proto_config_add_string password
proto_config_add_string pincode
-   proto_config_add_string delay
+   proto_config_add_int delay
proto_config_add_string modes
-   proto_config_add_boolean ipv6
-   proto_config_add_boolean dhcp
+   proto_config_add_string pdptype
+   proto_config_add_int profile
+   proto_config_add_boolean dhcpv6
+   proto_config_add_boolean autoconnect
proto_config_add_defaults
 }
 
 proto_qmi_setup() {
local interface="$1"
 
-   local device apn auth username password pincode delay modes ipv6 dhcp 
$PROTO_DEFAULT_OPTIONS
-   local cid_4 pdh_4 cid_6 pdh_6 ipv4
-   local ip subnet gateway dns1 dns2 ip_6 ip_prefix_length gateway_6 
dns1_6 dns2_6
-   json_get_vars device apn auth username password pincode delay modes 
ipv6 dhcp $PROTO_DEFAULT_OPTIONS
-
-   ipv4=1
-
-   [ "$ipv6" = 1 ] || ipv6=""
+   local device apn auth username password pincode delay modes pdptype 
profile dhcpv6 autoconnect $PROTO_DEFAULT_OPTIONS
+   local cid_4 pdh_4 cid_6 pdh_6
+   local ip_6 ip_prefix_length gateway_6 dns1_6 dns2_6
+   json_get_vars device apn auth username password pincode delay modes 
pdptype profile dhcpv6 autoconnect $PROTO_DEFAULT_OPTIONS
 
[ "$metric" = "" ] && metric="0"
 
+   [ "$autoconnect" = 1 ] || autoconnect=""
+
[ -n "$ctl_device" ] && device=$ctl_device
 
[ -n "$device" ] || {
@@ -76,18 +76,6 @@ proto_qmi_setup() {
}
}
 
-   [ -n "$apn" ] || {
-   echo "No APN specified"
-   proto_notify_error "$interface" NO_APN
-   return 1
-   }
-
-   # try to clear previous autoconnect state
-   # do not reuse previous wds client id to prevent hangs caused by stale 
data
-   uqmi -s -d "$device" \
-   --stop-network 0x \
-   --autoconnect > /dev/null
-
uqmi -s -d "$device" --set-data-format 802.3
uqmi -s -d "$device" --wda-set-data-format 802.3
 
@@ -98,68 +86,89 @@ proto_qmi_setup() {
 
[ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes "$modes"
 
-   echo "Starting network $apn"
+   echo "Starting network $interface"
 
-   cid_4=`uqmi -s -d "$device" --get-client-id wds`
-   [ $? -ne 0 ] && {
-   echo "Unable to obtain client ID"
-   proto_notify_error "$interface" NO_CID
-   return 1
-   }
+   pdptype=`echo "$pdptype" | awk '{print tolower($0)}'`
+   [ "$pdptype" = "ip" -o "$pdptype" = "ipv6" -o "$pdptype" = "ipv4v6" ] 
|| pdptype="ip"
+
+   [ "$pdptype" = "ip" -o "$pdptype" = "ipv4v6" ] && {
+   cid_4=`uqmi -s -d "$device" --get-client-id wds`
+   [ $? -ne 0 ] && {
+   echo "Unable to obtain client ID"
+   proto_notify_error "$interface" NO_CID
+   return 1
+   }
 
-   pdh_4=`uqmi -s -d "$device" --set-client-id wds,"$cid_4" \
-   --start-network "$apn" \
-   ${auth:+--auth-type $auth} \
-

Re: [LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

2016-12-03 Thread Thomas Endt 
> An idea would be, to provide some small hint for the googlebot, to
> switch to the new content via some "#REDIRECT" wiki command ...

googlebot will notice. He's a frequent visitor, afaics.

Thomas


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

2016-12-03 Thread Hartmut Knaack 
Rob Landley schrieb am 03.12.2016 um 20:38:
> On 12/03/2016 09:30 AM, Felix Fietkau wrote:
>> Hi Denys,
>> Here's the thing: OpenWrt/LEDE is starting services via procd.
>> This is a rather essential piece of how we're dealing with system-wide
>> reloading of configuration and automatically restarting/reloading only
>> services which are affected by configuration changes.
>> In comparison, dealing with logging is rather trivial.
>>
>> Because of that, I think switching to runit is not a good trade-off.
>>
>> - Felix
> 
> Any idea why the fourth google hit
> https://www.lede-project.org/docs/procd.html was recently deleted?
> (Google has summary text, but the site says there's no article.)
> 
> Rob

It has probably just moved:

https://www.lede-project.org/docs/guide-developer/procd

> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

2016-12-03 Thread Tino Reichardt 
* Rob Landley  wrote:
> On 12/03/2016 09:30 AM, Felix Fietkau wrote:
> > Hi Denys,
> > Here's the thing: OpenWrt/LEDE is starting services via procd.
> > This is a rather essential piece of how we're dealing with system-wide
> > reloading of configuration and automatically restarting/reloading only
> > services which are affected by configuration changes.
> > In comparison, dealing with logging is rather trivial.
> > 
> > Because of that, I think switching to runit is not a good trade-off.

It's not deleted. The main site is another site (wiki) now... thats the
reason.

An idea would be, to provide some small hint for the googlebot, to
switch to the new content via some "#REDIRECT" wiki command ...


-- 
Best regards, Tino

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

2016-12-03 Thread Rob Landley 
On 12/03/2016 09:30 AM, Felix Fietkau wrote:
> Hi Denys,
> Here's the thing: OpenWrt/LEDE is starting services via procd.
> This is a rather essential piece of how we're dealing with system-wide
> reloading of configuration and automatically restarting/reloading only
> services which are affected by configuration changes.
> In comparison, dealing with logging is rather trivial.
> 
> Because of that, I think switching to runit is not a good trade-off.
> 
> - Felix

Any idea why the fourth google hit
https://www.lede-project.org/docs/procd.html was recently deleted?
(Google has summary text, but the site says there's no article.)

Rob

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH uclient] Fix unused results warnings

2016-12-03 Thread Florian Fainelli 
Fixes:

uclient-http.c:385:8: error: ignoring return value of 'fread', declared with 
attribute warn_unused_result [-Werror=unused-result]
   fread(, sizeof(val), 1, f);
^

uclient-fetch.c: In function 'main':
uclient-fetch.c:664:12: error: ignoring return value of 'asprintf', declared 
with attribute warn_unused_result [-Werror=unused-result]
asprintf(_str, "%s:%s", username, password);
^
uclient-fetch.c: In function 'read_data_cb':
uclient-fetch.c:269:9: error: ignoring return value of 'write', declared with 
attribute warn_unused_result [-Werror=unused-result]
write(output_fd, buf, len);

Signed-off-by: Florian Fainelli 
---
 uclient-fetch.c | 16 +++-
 uclient-http.c  |  5 -
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 4c603fbc1945..db13e81bf8d0 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -254,6 +254,7 @@ static void header_done_cb(struct uclient *cl)
 static void read_data_cb(struct uclient *cl)
 {
char buf[256];
+   size_t n;
int len;
 
if (!no_output && output_fd < 0)
@@ -265,8 +266,11 @@ static void read_data_cb(struct uclient *cl)
return;
 
out_bytes += len;
-   if (!no_output)
-   write(output_fd, buf, len);
+   if (!no_output) {
+   n = write(output_fd, buf, len);
+   if (n < len)
+   return;
+   }
}
 }
 
@@ -660,9 +664,11 @@ int main(int argc, char **argv)
uloop_init();
 
if (username) {
-   if (password)
-   asprintf(_str, "%s:%s", username, password);
-   else
+   if (password) {
+   rc = asprintf(_str, "%s:%s", username, password);
+   if (rc < 0)
+   return rc;
+   } else
auth_str = username;
}
 
diff --git a/uclient-http.c b/uclient-http.c
index 8d26bd4884be..80f40d0e40e3 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -379,11 +379,14 @@ get_cnonce(char *dest)
 {
uint32_t val = 0;
FILE *f;
+   size_t n;
 
f = fopen("/dev/urandom", "r");
if (f) {
-   fread(, sizeof(val), 1, f);
+   n = fread(, sizeof(val), 1, f);
fclose(f);
+   if (n != sizeof(val))
+   return;
}
 
bin_to_hex(dest, , sizeof(val));
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] odhcpd: Update to 2016-12-01 snapshot

2016-12-03 Thread Florian Fainelli 
Signed-off-by: Florian Fainelli 
---
 package/network/services/odhcpd/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/network/services/odhcpd/Makefile 
b/package/network/services/odhcpd/Makefile
index f6ce26c150ef..f8a74b93c911 100644
--- a/package/network/services/odhcpd/Makefile
+++ b/package/network/services/odhcpd/Makefile
@@ -8,15 +8,15 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=odhcpd
-PKG_VERSION:=2016-11-21
+PKG_VERSION:=2016-12-01
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_URL:=git://git.lede-project.org/project/odhcpd.git
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_VERSION:=5f425ed1e5f92397e27ec4f44820b6ef677b8134
-PKG_MIRROR_MD5SUM:=64ef09adbb88e1a419a689985dbc784c94003b247216d6e188e81b7f2807b032
+PKG_SOURCE_VERSION:=41b52688403016017eca812315a7206b6d27c097
+PKG_MIRROR_MD5SUM:=14b2ddb5a48d5af81e36594e7c526c2e2019c2d4b112af41f9004660bb84a230
 
 PKG_MAINTAINER:=Steven Barth 
 PKG_LICENSE:=GPL-2.0
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH rpcd 1/2] cmake: Find libubox/blobmsg_json.h

2016-12-03 Thread Florian Fainelli 
Add a CMake FIND_PATH and INCLUDE_DIRECTORIES searching for blobmsg_json.h.
Some external toolchains which do not include standard locations would fail to
find the header otherwise.

Signed-off-by: Florian Fainelli 
---
 CMakeLists.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 49aa4176fbc7..ceb472e94162 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -31,6 +31,9 @@ ENDIF()
 FIND_PATH(ubus_include_dir libubus.h)
 INCLUDE_DIRECTORIES(${ubus_include_dir})
 
+FIND_PATH(ubox_include_dir libubox/blobmsg_json.h)
+INCLUDE_DIRECTORIES(${ubox_include_dir})
+
 ADD_EXECUTABLE(rpcd main.c exec.c session.c uci.c plugin.c)
 TARGET_LINK_LIBRARIES(rpcd ubox ubus uci dl blobmsg_json ${json} ${crypt})
 
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] It seems I didn't see most list activity due to list issues

2016-12-03 Thread Daniel Dickinson 
Hi,

It seems my impression that there wasn't much getting discussed
was because there was some sort of list issue that prevented me
from getting incoming mails; I had whitelisted the LEDE lists
with my email provider, so there was definitely something funky
with that.

It looks like there has in fact been a good amount if
discussion and activity that I didn't realize had been
occurring.

So, I retract my previous sentiment about the lack of
interaction, and apparent lack of progress.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [source] procd: update to the latest version, fixes killing jailed processes

2016-12-03 Thread Felix Fietkau 
On 2016-12-02 20:18, Etienne Champetier wrote:
> Hi Felix,
> 
> 2016-12-02 6:32 GMT-08:00 Felix Fietkau :
>>
>> Hi Etienne,
>>
>> what value would you suggest as a default? I should probably make it
>> configurable on the command line as well.
> 
> For service handling data we might loose data, so maybe no default at
> all unless it's configured.
> I would also change the debug message to a warning or error so this
> end up in system log for easier debugging
Okay, I'll take care of this

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

2016-12-03 Thread Felix Fietkau 
Hi Denys,

On 2016-12-03 14:05, Denys Vlasenko wrote:
> Hi Felix, guys,
> 
> I noticed that ntpd is running on my 15.05.1,
> but its output goes to /dev/null!
> 
> I noticed this because ntpd lost sync,
> but it was not possible to see it because its output
> (which contains this information) is discarded.
> I could only see it by stracing the running process.
> 
> Well, we certainly can fix the ntpd start scritps,
> but this is a generic problem, right? We'd want ANY
> daemons to be run "properly", with their output logged.
> With log size and location controlled. With log rotation.
> Etc. etc etc.
> 
> I propose to use runit tools for this.
> It is a daemontools clone.
> If you never heard about any of this stuff, please read
> the entire email (there is a README at the end).
> 
> For openwrt, this can be particularly easy, since runit
> is ported to busybox already many years ago. It only needs
> to be enabled at build time, and started at boot.
> 
> Thee is no need to migrate all daemons en mass to be run under runit.
> We can try it with, say, ntpd first. If it goes well, we'd use it
> for more and more things. If it goes badly, we drom it.
> 
> Thoughts?
Here's the thing: OpenWrt/LEDE is starting services via procd.
This is a rather essential piece of how we're dealing with system-wide
reloading of configuration and automatically restarting/reloading only
services which are affected by configuration changes.
In comparison, dealing with logging is rather trivial.

Because of that, I think switching to runit is not a good trade-off.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v2] brcm63xx: Add Observa VH4032N support

2016-12-03 Thread Daniel Gonzalez Cabanelas 
Add support for the Observa Telecom VH4032N router.

This is another BCM6368 router, 128 MB RAM, 32MB flash and 3 USB
host ports. It has an onboard USB hub that needs to be pulled out of
reset via GPIO27. 

The 4 LAN switch LEDs should be controlled via hardware but they don't 
work as with all BCM6368 based boards (known bug, GPIO LAN-LED mux 
is lost at boot time). There is an ongoing patch to fix it in a different 
commit.

The wifi chip is an onboard Broadcom BCM43222.
---
change in v2:
shift order in LAN ports, and rename them to match exactly what
this board has
---
Signed-off-by: Daniel Gonzalez Cabanelas 
diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network 
b/target/linux/brcm63xx/base-files/etc/board.d/02_network
index c20caf9..c83aa62 100755
--- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
+++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
@@ -98,6 +98,11 @@ vr-3026e)
"0:lan:1" "1:lan:2" "2:lan:3" "3:lan:4" "8t@eth0"
;;
 
+vh4032n)
+   ucidef_add_switch "switch0" \
+   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "8t@eth0"
+   ;;
+
 bcm96368mvwg)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "4:lan" "5:lan" "8t@eth0"
diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh 
b/target/linux/brcm63xx/base-files/etc/diag.sh
index 852a701..3a858e4 100644
--- a/target/linux/brcm63xx/base-files/etc/diag.sh
+++ b/target/linux/brcm63xx/base-files/etc/diag.sh
@@ -33,6 +33,9 @@ set_state() {
spw303v)
status_led="spw303v:green:power+adsl"
;;
+   vh4032n)
+   status_led="VH4032N:red:power"
+   ;;
vr-3025un)
status_led="VR-3025un:green:power"
;;
diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc 
b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
index 1201168..650db9d 100644
--- a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
+++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
@@ -31,6 +31,7 @@ case "$(brcm63xx_board_name)" in
spw303v |\
v2110 |\
v2500v_bb |\
+   vh4032n |\
vr-3025u |\
vr-3025un |\
vr-3026e |\
diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh 
b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
index 9cc0b2b..3dce282 100755
--- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
+++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
@@ -189,6 +189,9 @@ brcm63xx_dt_detect() {
"NuCom R5010UN v2")
board_name="r5010un_v2"
;;
+   "Observa VH4032N")
+   board_name="vh4032n"
+   ;;
"Pirelli A226G")
board_name="a226g"
;;
diff --git a/target/linux/brcm63xx/dts/vh4032n.dts 
b/target/linux/brcm63xx/dts/vh4032n.dts
new file mode 100644
index 000..d75c636
--- /dev/null
+++ b/target/linux/brcm63xx/dts/vh4032n.dts
@@ -0,0 +1,93 @@
+/dts-v1/;
+
+#include "bcm6368.dtsi"
+
+#include 
+
+/ {
+   model = "Observa VH4032N";
+   compatible = "observa,vh4032n", "brcm,bcm6368";
+
+   chosen {
+   bootargs = "root=/dev/mtdblock2 rootfstype=squashfs,jffs2 
noinitrd console=ttyS0,115200";
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+   debounce-interval = <60>;
+
+   reset {
+   label = "reset";
+   gpios = < 2 1>;
+   linux,code = ;
+   };
+   wps {
+   label = "wps";
+   gpios = < 3 1>;
+   linux,code = ;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   dsl_blue {
+   label = "VH4032N:blue:dsl";
+   gpios = < 2 1>;
+   };
+   dsl_red {
+   label = "VH4032N:red:dsl";
+   gpios = < 5 1>;
+   };
+   hspa_blue {
+   label = "VH4032N:blue:hspa";
+   gpios = < 11 1>;
+   };
+   hspa_red {
+   label = "VH4032N:red:hspa";
+   gpios = < 12 1>;
+   };
+   power_blue {
+   label = "VH4032N:blue:power";
+   gpios = < 22 0>;
+   };
+   power_red {
+   label = "VH4032N:red:power";
+   gpios = < 24 0>;
+   default-state = "on";
+   };
+   voice_blue {
+   label = "VH4032N:blue:voice";
+   gpios = < 25 1>;
+   };
+

Re: [LEDE-DEV] [OpenWrt-Devel] [OpenWrt] Project proposal: The GNUnet of autonomous Things

2016-12-03 Thread Daniel Golle 
Hi Arturo,

On Sat, Dec 03, 2016 at 03:58:17AM +0100, Arturo Rinaldi wrote:
> Hello folks,
> 
> as Kathy mentioned as first answer to Daniel, a proper setup running GNUnet
> on our boards could give us a boost in the IoT world. During the last years

I'm pretty sure we are practically at this point already. Try

opkg install gnunet-gns-flat

(and maybe some more transports, such as gnunet-transport-wlan or
gnunet-transport-http_client)

Once you got that, you can easily use it to tunnel access to
conventional TCP/IP services via GNUnet using gnunet-exit and
gnunet-vpn, which are already well-integrated with the OpenWrt
packaging I created to have GNUnet participate in BattleMesh during
the past years.


> we have developed a new approach to the arduino "bridge" interaction with
> CIAO :
> 
> http://www.arduino.org/learning/tutorials/advanced-guides/ciao

Interesting and indeed similar to the lower layers of the GNUnet stack.
I'll definitely have a deeper look at it.

> 
> this is of course requires the use of Python as high level language since
> it is designed around it but transparent to any kind of connectors. If I
> understand well from this first email exchange, since *ubus* will be the
> running engine of the new it is a completely native approach being it an
> underlying running service of OpenWRT. Am I wrong or didn't John show

Yes, and combined with Felix' SCAL project it will allow atomic ACLs
and integrate with different middle-ware models. The exact machanics
of remote access are *not* part of this unified stack, this is where
freedom to use netconf, TR-069 or any other kind of remote management
stack on top comes in -- I personally imagine something less
centralized than current Web technologies as e.g. local machine to
machine communication shouldn't ever depend on the availability of an
external entitity of connectivity (ie. I still want to be able to
locally control my heating system and have different systems of a
smart home interact even in case of failing internet connectivity).
This is why I see GNUnet in that place, because it comes with both,
local area and wide area transports.

> something similar that night at C-base in Berlin as first attempt of
> creating a sort of new approach to the bridge itself ?

I reckon this was related to Mediatek's LinkIT approach, but I do not
remember the details. John?

> 
> This leads me to think about the possibility to use this solution in
> combination with *lininoIO*, our new approach for exposing the MCU gpio(s)
> as filesystem devices and using them to interact with sensors, actuators
> and so on (it was one of the topics of my talk in Berlin). Would this be a
> reasonable approach for you ? Please let us know what you think about it
> and in case we'll discuss it in the scheduled call.

I imagine this to be a possible backend in the ubus/scal approach I'm
envisioning. I'll have a deeper look at lininoIO so we can talk about
that in more detail soon.


Cheers


Daniel

> 
> Best Regards
> 
> Arturo
> 
> 2016-12-01 16:51 GMT+01:00 Felix Fietkau :
> 
> > On 2016-12-01 16:38, Daniel Golle wrote:
> > > Hi Felix,
> > >
> > > On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
> > >> On 2016-12-01 16:05, Daniel Golle wrote:
> > >> > I was following your posts and do believe there is quite some overlap.
> > >> > It would thus be feasible to generalize the common parts (ubus call
> > >> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a
> > shared
> > >> > interface the actual implementations shall use. In that way, people
> > >> > can choose whether they want WebSockets, TR-069 or a suitable P2P
> > >> > framework depending on their specific needs.
> > >> > Has anything of your current approach at IOPSYS been made available
> > >> > publicly (eg. on github?)
> > >> >
> > >> > From what I can tell there is also some overlap with Felix' proposed
> > >> > System Configuration Abstraction Layer, just that my envisioned use
> > >> > exceeds system configuration as it includes sensors, events and actors
> > >> > rather than just access to a configuration model.
> > >> If it makes sense, I'd be open to extending my abstraction layer to make
> > >> it suitable for your use case as well.
> > >> Feel free to propose changes to it if you like.
> > >
> > > Having a first deeper look at scal I believe that access to sensors
> > > and actors could be implemented inside scal similar to the existing
> > > shell and system backends. That would be nice, as then scal would
> > > make things available on ubus and provide the ACL mechanics.
> > Nice. Maybe we can reinterpret the acronym as "System Communication
> > Abstraction Layer". I'd be fine with renaming it to something else as
> > well, I just didn't find a better name for it yet.
> >
> > I think a good approach would be to add a dlopen plugin API to the json
> > plugin itself, so you can use json files to parameterize access to
> > sensors and other devices.
> >
> >

Re: [LEDE-DEV] ath10k firmware crashes in mesh mode on QCA9880

2016-12-03 Thread Mohammed Shafi Shajakhan 
https://patchwork.kernel.org/patch/9437519/
(sorry missed this in the previous thread)

On Sat, Dec 03, 2016 at 06:13:58PM +0530, Mohammed Shafi Shajakhan wrote:
> Hi Benjamin,
> 
> On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:
> > Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:
> > 
> > [  131.568989] ath10k_pci :01:00.0: firmware crashed! (uuid
> > 1838347e-9380-4a26-ac9d-2963ee95968b)
> > [  131.578124] ath10k_pci :01:00.0: qca988x hw2.0 target
> > 0x4100016c chip_id 0x043202ff sub :
> > [  131.587491] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> > tracing 0 dfs 1 testmode 1
> > [  131.600521] ath10k_pci :01:00.0: firmware ver 10.2.4.70.58
> > api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
> > [  131.610899] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> > crc32 bebc7c08
> > [  131.618325] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> > 2 cal file max-sta 128 raw 0 hwcrypto 1
> > [  131.629965] ath10k_pci :01:00.0: firmware register dump:
> > [  131.635728] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
> > 0x009A45AF 0x00955B31
> > [  131.643761] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130
> > 0x0002 0x00439E98
> > [  131.651806] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074
> > 0x00407120 0x004436CC
> > [  131.659852] ath10k_pci :01:00.0: [12]: 0x0009 0x
> > 0x009A3550 0x009A355E
> > [  131.667892] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A31D6
> > 0x 0x
> > [  131.675936] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4
> > 0x0040AC60 0x0040AC09
> > [  131.683968] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24
> > 0x0040 0xC09A45AF
> > [  131.692013] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84
> > 0x0044110C 0x00442074
> > [  131.700056] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4
> > 0x0044110C 0x00407120
> > [  131.708100] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> > 0x0040AC14 0x1580
> > [  131.716143] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04
> > 0x009C6458 0x004436CC
> > [  131.724175] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64
> > 0x004208FC 0x00439E4C
> > [  131.732220] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84
> > 0x004208FC 0x00425874
> > [  131.740263] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4
> > 0x00424FE8 0x0002
> > [  131.748306] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14
> > 0x0004 0x004039D0
> > [  131.857076] ieee80211 phy0: Hardware restart was requested
> > [  131.862705] ath10k_pci :01:00.0: failed to synchronize
> > monitor vdev 1 stop: -143
> > [  131.870594] ath10k_pci :01:00.0: failed to stop monitor vdev: -143
> 
> [shafi] request to try with the latest backports and ath.git
> Also worth trying this fix in ath10k (once the next firmware version)
> is available. I will keep you posted. thank you !
> 
> > 
> > ~Benjamin
> > 
> > On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
> > >Hi,
> > >
> > >On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> > >>When we try to transmit traffic (ping) between two meshed ath10k
> > >>devices running latest lede we keep experiencing ath10k firmware
> > >>crashes. This seems to only happen when running in 802.11n/ac mode
> > >>but not in 802.11a/g mode. Also, from the station dumps it appears
> > >>that management traffic is flowing between the devices, however when
> > >>we try to send unicast data traffic the firmware crashes
> > >>immediately.
> > >[shafi] Did you get a chance to try with the below firmware as well
> > >https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
> > >
> > >>Platform: Archer C7 AC1750 v2
> > >>Software Image: LEDE (HEAD, r2299) Commit: 
> > >>https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
> > >>
> > >>Crypto: wpa_supplicant
> > >>wpa_supplicant-wlan0.conf
> > >>network={
> > >>ssid="bmorgan_lede_mesh"
> > >>key_mgmt=SAE
> > >>mode=5
> > >>frequency=5180
> > >>psk="meshpassword"
> > >>}
> > >>
> > >>Backports Verstion:
> > >>[9.818007] Loading modules backported from Linux version
> > >>wt-2016-10-03-1-g6fcb1a6
> > >>[9.825736] Backport generated by backports.git
> > >>backports-20160324-9-g0e38f5c
> > >>
> > >>​​Ath10k Initialization on Station A (dmesg)
> > >>[9.896715] PCI: Enabling device :01:00.0 ( -> 0002)
> > >>[9.902622] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode
> > >>1 irq_mode 0 reset_mode 0
> > >>[   10.123734] ath10k_pci :01:00.0: Direct firmware load for
> > >>ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
> > >>[   10.134620] ath10k_pci :01:00.0: Falling back to user helper
> > >>[   10.287680] firmware ath10k!pre-cal-pci-:01:00.0.bin:
> > >>firmware_loading_store: map pages failed
> > >>[   10.622789] ath10k_pci :01:00.0: qca988x hw2.0 target
> >

Re: [LEDE-DEV] ath10k firmware crashes in mesh mode on QCA9880

2016-12-03 Thread Mohammed Shafi Shajakhan 
Hi Benjamin,

On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:
> Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:
> 
> [  131.568989] ath10k_pci :01:00.0: firmware crashed! (uuid
> 1838347e-9380-4a26-ac9d-2963ee95968b)
> [  131.578124] ath10k_pci :01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub :
> [  131.587491] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [  131.600521] ath10k_pci :01:00.0: firmware ver 10.2.4.70.58
> api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
> [  131.610899] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [  131.618325] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> 2 cal file max-sta 128 raw 0 hwcrypto 1
> [  131.629965] ath10k_pci :01:00.0: firmware register dump:
> [  131.635728] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
> 0x009A45AF 0x00955B31
> [  131.643761] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130
> 0x0002 0x00439E98
> [  131.651806] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [  131.659852] ath10k_pci :01:00.0: [12]: 0x0009 0x
> 0x009A3550 0x009A355E
> [  131.667892] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A31D6
> 0x 0x
> [  131.675936] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [  131.683968] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24
> 0x0040 0xC09A45AF
> [  131.692013] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84
> 0x0044110C 0x00442074
> [  131.700056] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4
> 0x0044110C 0x00407120
> [  131.708100] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4
> 0x0040AC14 0x1580
> [  131.716143] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04
> 0x009C6458 0x004436CC
> [  131.724175] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64
> 0x004208FC 0x00439E4C
> [  131.732220] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84
> 0x004208FC 0x00425874
> [  131.740263] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4
> 0x00424FE8 0x0002
> [  131.748306] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x0004 0x004039D0
> [  131.857076] ieee80211 phy0: Hardware restart was requested
> [  131.862705] ath10k_pci :01:00.0: failed to synchronize
> monitor vdev 1 stop: -143
> [  131.870594] ath10k_pci :01:00.0: failed to stop monitor vdev: -143

[shafi] request to try with the latest backports and ath.git
Also worth trying this fix in ath10k (once the next firmware version)
is available. I will keep you posted. thank you !

> 
> ~Benjamin
> 
> On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:
> >Hi,
> >
> >On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> >>When we try to transmit traffic (ping) between two meshed ath10k
> >>devices running latest lede we keep experiencing ath10k firmware
> >>crashes. This seems to only happen when running in 802.11n/ac mode
> >>but not in 802.11a/g mode. Also, from the station dumps it appears
> >>that management traffic is flowing between the devices, however when
> >>we try to send unicast data traffic the firmware crashes
> >>immediately.
> >[shafi] Did you get a chance to try with the below firmware as well
> >https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
> >
> >>Platform: Archer C7 AC1750 v2
> >>Software Image: LEDE (HEAD, r2299) Commit: 
> >>https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
> >>
> >>Crypto: wpa_supplicant
> >>wpa_supplicant-wlan0.conf
> >>network={
> >>ssid="bmorgan_lede_mesh"
> >>key_mgmt=SAE
> >>mode=5
> >>frequency=5180
> >>psk="meshpassword"
> >>}
> >>
> >>Backports Verstion:
> >>[9.818007] Loading modules backported from Linux version
> >>wt-2016-10-03-1-g6fcb1a6
> >>[9.825736] Backport generated by backports.git
> >>backports-20160324-9-g0e38f5c
> >>
> >>​​Ath10k Initialization on Station A (dmesg)
> >>[9.896715] PCI: Enabling device :01:00.0 ( -> 0002)
> >>[9.902622] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode
> >>1 irq_mode 0 reset_mode 0
> >>[   10.123734] ath10k_pci :01:00.0: Direct firmware load for
> >>ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
> >>[   10.134620] ath10k_pci :01:00.0: Falling back to user helper
> >>[   10.287680] firmware ath10k!pre-cal-pci-:01:00.0.bin:
> >>firmware_loading_store: map pages failed
> >>[   10.622789] ath10k_pci :01:00.0: qca988x hw2.0 target
> >>0x4100016c chip_id 0x043202ff sub :
> >>[   10.632184] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
> >>tracing 0 dfs 1 testmode 1
> >>[   10.645231] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54
> >>api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> >>[   10.655660] ath10k_pci :01:00.0: Direct firmware load for
> >>ath10k/QCA988X/hw2.0/board-2.bin

[LEDE-DEV] [PATCH v3] mt7621: Fix LAN port order of WeVO W2914NS v2

2016-12-03 Thread perillamint 
From: "Yong-hyu, Ban" 

Signed-off-by: Yong-hyu, Ban 
---

Changelog:
v2: Real-name signed-off message
v3: Add missing WAN port number.

 target/linux/ramips/base-files/etc/board.d/02_network | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index e3e6550..aac321d 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -87,7 +87,6 @@ ramips_setup_interfaces()
sap-g3200u3|\
sk-wb8|\
vr500|\
-   w2914nsv2|\
wf-2881|\
witi|\
wl-wn575a3|\
@@ -242,6 +241,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
;;
+   w2914nsv2)
+   ucidef_add_switch "switch0" \
+   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
+   ;;
wcr-150gn)
ucidef_add_switch "switch0" \
"0:lan" "6t@eth0"
-- 
2.10.2


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients

2016-12-03 Thread Timo Sigurdsson 
Hi Mohammed,

so, I provoked the crash again on a newer build with debugging enabled
(LEDE r2321, Linux 4.4.32, ath10k firmware 10.2.4.70.54).

The relevant dmesg output is pasted below (with mac addresses
pseudo-anonymized). I hope this includes the information you were
looking for. If not, please let me know what other useful information I
can provide. I haven't rebooted the access point yet.

Regards,

Timo

[283232.075393] ath10k_pci :01:00.0: failed to delete peer 
78:f8:82:00:00:00 for vdev 0: -145
[283232.084140] ath10k_pci :01:00.0: found sta peer 78:f8:82:00:00:00 (ptr 
86df2800 id 62) entry on vdev 0 after it was supposedly removed
[283232.096976] [ cut here ]
[283232.101904] WARNING: CPU: 0 PID: 1841 at 
compat-wireless-2016-10-08/net/mac80211/sta_info.c:964 
sta_set_sinfo+0x92c/0x9e0 [mac80211]()
[283232.114279] Modules linked in: pppoe ppp_async iptable_nat ath9k pppox 
ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT 
ipt_MASQUERADE ax88179_178a ath9k_common xt_time xt_tcpudp xt_tcpmss 
xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit 
xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark 
xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP 
xt_CT xt_CLASSIFY usbnet slhc nf_reject_ipv4 nf_nat_redirect 
nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 
nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter 
ipt_ECN ip_tables crc_ccitt ath9k_hw em_nbyte sch_tbf sch_pie sch_gred sch_htb 
sch_teql cls_basic act_ipt sch_red sch_prio em_meta em_text sch_codel sch_sfq 
act_police sch_dsmark em_cmp sch_fq act_skbedit act_mirred em_u32 cls_u32 
cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress ath10k_pci 
ath10k_core ath mac80211 cfg80211 compat ledt
 rig_usbport ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw 
ip6table_mangle ip6table_filter ip6_tables x_tables ifb ehci_platform ehci_hcd 
gpio_button_hotplug usbcore nls_base usb_common mii
[283232.221696] CPU: 0 PID: 1841 Comm: hostapd Not tainted 4.4.32 #0
[283232.227884] Stack : 803c74e4  0001 8042 87d65b80 8040ed83 
803a8bac 0731
[283232.227884]   8048379c 8740e800  7782fe94  800a7238 
803ae218 8041
[283232.227884]   0003 8740e800 803ac624 86e1db2c  800a51b4 
01afb952 
[283232.227884]   0001 801f3200     
 
[283232.227884]         
 
[283232.227884]   ...
[283232.264341] Call Trace:
[283232.266934] [<80071b80>] show_stack+0x50/0x84
[283232.271445] [<80081900>] warn_slowpath_common+0xa0/0xd0
[283232.276847] [<800819b8>] warn_slowpath_null+0x18/0x24
[283232.282164] [<875870a4>] sta_set_sinfo+0x92c/0x9e0 [mac80211]
[283232.288224] [<87587188>] __sta_info_destroy+0x30/0x48 [mac80211]
[283232.294519] [<87587238>] sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
[283232.301475] [<874cc144>] cfg80211_check_station_change+0xed8/0x1390 
[cfg80211]
[283232.308942] 
[283232.310543] ---[ end trace 1e173b5175dabd85 ]---
[283547.702654] ath10k_pci :01:00.0: failed to install key for vdev 0 peer 
a0:02:dc:00:00:00: -145
[283547.711846] wlan0: failed to remove key (0, a0:02:dc:00:00:00) from 
hardware (-145)
[283547.720952] ath10k_pci :01:00.0: cipher 0 is not supported
[283547.727006] ath10k_pci :01:00.0: failed to remove peer wep key 0: -122
[283547.734106] ath10k_pci :01:00.0: failed to clear all peer wep keys for 
vdev 0: -122
[283547.742313] ath10k_pci :01:00.0: failed to disassociate station: 
a0:02:dc:00:00:00 vdev 0: -122
[283547.751590] [ cut here ]
[283547.756521] WARNING: CPU: 0 PID: 1841 at 
compat-wireless-2016-10-08/net/mac80211/sta_info.c:956 
sta_set_sinfo+0x8d8/0x9e0 [mac80211]()
[283547.768872] Modules linked in: pppoe ppp_async iptable_nat ath9k pppox 
ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT 
ipt_MASQUERADE ax88179_178a ath9k_common xt_time xt_tcpudp xt_tcpmss 
xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit 
xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark 
xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP 
xt_CT xt_CLASSIFY usbnet slhc nf_reject_ipv4 nf_nat_redirect 
nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 
nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter 
ipt_ECN ip_tables crc_ccitt ath9k_hw em_nbyte sch_tbf sch_pie sch_gred sch_htb 
sch_teql cls_basic act_ipt sch_red sch_prio em_meta em_text sch_codel sch_sfq 
act_police sch_dsmark em_cmp sch_fq act_skbedit act_mirred em_u32 cls_u32 
cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress ath10k_pci 
ath10k_core ath mac80211 cfg80211 compat ledt
 rig_usbport ip6t_REJECT