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

[Adrian Chadd]

Hi!

ok, thanks! I've seen some .. annoying rate control related firmware
crashes if you aren't using 11ac / 11n rates (ie you're /really/
legacy, so I wondered if something similar is going on here.

Thanks!


-a


On 13 December 2016 at 22:06, Alexis Green  wrote:
> Hi Adrian,
>
> I have not done much testing of ath10k and ath9k devices in a single
> encrypted mesh recently, but I have a memory of only having this issue
> when communicating between ath10k devices.
>
> Alexis
>
> On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd  wrote:
>> Hi!
>>
>> Hm! So is there a firmware bug if there are 11n only capable nodes in
>> an 11s mesh?
>>
>>
>>
>> -adrian

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

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

[Alexis Green via Lede-dev]

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 ---
Hi Adrian,

I have not done much testing of ath10k and ath9k devices in a single
encrypted mesh recently, but I have a memory of only having this issue
when communicating between ath10k devices.

Alexis

On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd  wrote:
> Hi!
>
> Hm! So is there a firmware bug if there are 11n only capable nodes in
> an 11s mesh?
>
>
>
> -adrian

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

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

[Adrian Chadd]

Hi!

Hm! So is there a firmware bug if there are 11n only capable nodes in
an 11s mesh?



-adrian

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

[LEDE-DEV] [PATCH] libubox: Fix cppcheck warnings

[Rosen Penev]

Two formats and a memory leak.

Signed-off by: Rosen Penev 
---
 ulog.c  | 2 +-
 usock.c | 2 +-
 utils.c | 3 +++
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/ulog.c b/ulog.c
index 985d366..e7fb081 100644
--- a/ulog.c
+++ b/ulog.c
@@ -91,7 +91,7 @@ static void ulog_kmsg(int priority, const char *fmt, va_list 
ap)
FILE *kmsg;
 
if ((kmsg = fopen("/dev/kmsg", "r+")) != NULL) {
-   fprintf(kmsg, "<%u>", priority);
+   fprintf(kmsg, "<%d>", priority);
 
if (_ulog_ident)
fprintf(kmsg, "%s: ", _ulog_ident);
diff --git a/usock.c b/usock.c
index 0ce5390..0983806 100644
--- a/usock.c
+++ b/usock.c
@@ -247,7 +247,7 @@ const char *usock_port(int port)
if (port < 0 || port > 65535)
return NULL;
 
-   snprintf(buffer, sizeof(buffer), "%u", port);
+   snprintf(buffer, sizeof(buffer), "%d", port);
 
return buffer;
 }
diff --git a/utils.c b/utils.c
index 91dd71e..a8bc5c5 100644
--- a/utils.c
+++ b/utils.c
@@ -44,7 +44,10 @@ void *__calloc_a(size_t len, ...)
 
ptr = calloc(1, alloc_len);
if (!ptr)
+   {
+   va_end(ap);
return NULL;
+   }
alloc_len = 0;
foreach_arg(ap, cur_addr, cur_len, , len) {
*cur_addr = [alloc_len];
-- 
2.8.3


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

[LEDE-DEV] [PATCH] libubox: replace strtok with strsep

[Rosen Penev]

strsep is re-entrant whereas strtok not necessarily so.

Signed-off by: Rosen Penev 
---
 ulog.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ulog.c b/ulog.c
index 296605d..985d366 100644
--- a/ulog.c
+++ b/ulog.c
@@ -39,8 +39,8 @@ static const char *ulog_default_ident(void)
if ((self = fopen("/proc/self/status", "r")) != NULL) {
while (fgets(line, sizeof(line), self)) {
if (!strncmp(line, "Name:", 5)) {
-   strtok(line, "\t\n");
-   p = strtok(NULL, "\t\n");
+   strsep(, "\t\n");
+   p = strsep(, "\t\n");
break;
}
}
-- 
2.8.3


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

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

[Alexis Green via Lede-dev]

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 ---
Thank you for your help Rajkumar,

We've traced the problem down to a peering issue. Looks like there was
a missing compile flag that caused some kind of incongruence. My best
guest is that beacons are generated by firmware and advertise support
for AC mode, whereas wpa_supplicant, when not compiled with
CONFIG_IEEE80211AC=y, sends mesh peering messages and creates peers
without AC support, causing firmware to get confused. After
recompiling supplicant with the correct flag, no more crashes were
observed in casual testing. I submitted a pull request to LEDE to,
hopefully, fix it in upstream.

Best regards,

Alexis

On Tue, Dec 13, 2016 at 3:51 PM, Manoharan, Rajkumar
 wrote:
>> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
>> encryption and it still crashes. I suspect this means wpa_supplicant is 
>> setting up
>> the interface incorrectly and/or transmitting a malformed packet that is 
>> causing
>> the driver to crash.
>>
> Ben,
>
> IIRC mesh support was validated in qca988x in VHT mode while ago.  Either it 
> could
> be regression in driver/fw or lede mac80211 package.
>
> 1) Could you please try plain backports in lede w/o applying ath10k patches.
>  I do see 160MHz support in LEDE.
> 2) There are some peer stats dump from your earlier log. Disable peer stats
>  by "peer_stats" debugfs.
> 3) Please confirm the behavior with older firmware revisions.
> 4) use iw to bring up open mesh to rule out wpa_s config
>
> -Rajkumar
>

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

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

[Manoharan, Rajkumar]

> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
> encryption and it still crashes. I suspect this means wpa_supplicant is 
> setting up
> the interface incorrectly and/or transmitting a malformed packet that is 
> causing
> the driver to crash.
> 
Ben,

IIRC mesh support was validated in qca988x in VHT mode while ago.  Either it 
could
be regression in driver/fw or lede mac80211 package.

1) Could you please try plain backports in lede w/o applying ath10k patches.
 I do see 160MHz support in LEDE.
2) There are some peer stats dump from your earlier log. Disable peer stats 
 by "peer_stats" debugfs.
3) Please confirm the behavior with older firmware revisions.
4) use iw to bring up open mesh to rule out wpa_s config

-Rajkumar

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

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

[Benjamin Morgan via Lede-dev]

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 ---
Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT 
encryption and it still crashes. I suspect this means wpa_supplicant is 
setting up the interface incorrectly and/or transmitting a malformed 
packet that is causing the driver to crash.


[  162.010206] ath10k_pci :01:00.0: firmware crashed! (uuid 
d30144f6-a8fb-4c0d-bcdf-6ff3b2c37243)
[  162.019322] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub :
[  162.028687] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 1
[  162.041764] ath10k_pci :01:00.0: firmware ver 10.2.4.70.59-2 api 
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[  162.053908] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[  162.061332] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1

[  162.072975] ath10k_pci :01:00.0: firmware register dump:
[  162.078732] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 
0x009A45AF 0x00955B31
[  162.086771] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130 
0x0001 0x4000
[  162.094804] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[  162.102849] ath10k_pci :01:00.0: [12]: 0x0009 0x 
0x009A3550 0x009A355E
[  162.110892] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D 
0x 0x
[  162.118935] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4 
0x0040AC60 0x0040AC09
[  162.126978] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24 
0x 0xC09A45AF
[  162.135011] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84 
0x0044110C 0x00442074
[  162.143056] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4 
0x0044110C 0x00407120
[  162.151099] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
0x0040AC10 0x1580
[  162.159142] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04 
0x009C6458 0x004436CC
[  162.167185] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64 
0x004208FC 0x00439E4C
[  162.175225] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84 
0x004208FC 0x004265C4
[  162.183253] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4 
0x00424FE8 0x0002
[  162.191298] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14 
0x0004 0x004039D0

[  162.297229] ieee80211 phy0: Hardware restart was requested
[  162.302880] ath10k_pci :01:00.0: wmi disable pktlog

~Benjamin


On 12/13/2016 10:42 AM, Benjamin Morgan wrote:
Just tested the latest 10.2.4.70.59-2 firmware and it still crashes 
with wpa_supplicant encrypted mesh =(


[   85.201440] ath10k_pci :01:00.0: firmware crashed! (uuid 
b7f44483-0488-46af-8dff-db88f4b56327)
[   85.210573] ath10k_pci :01:00.0: qca988x hw2.0 target 
0x4100016c chip_id 0x043202ff sub :
[   85.219940] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 1
[   85.233034] ath10k_pci :01:00.0: firmware ver 10.2.4.70.59-2 
api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[   85.245177] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[   85.252592] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1

[   85.264235] ath10k_pci :01:00.0: firmware register dump:
[   85.269992] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 
0x009A45AF 0x00955B31
[   85.278031] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130 
0x0002 0x00439E98
[   85.286078] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[   85.294107] ath10k_pci :01:00.0: [12]: 0x0009 0x 
0x009A3550 0x009A355E
[   85.302152] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D 
0x 0x
[   85.310195] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4 
0x0040AC60 0x0040AC09
[   85.318239] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24 
0x0040 0xC09A45AF
[   85.326282] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84 
0x0044110C 0x00442074
[   85.334314] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4 
0x0044110C 0x00407120
[   85.342350] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
0x0040AC14 0x1580
[   85.350393] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04 
0x009C6458 0x004436CC
[   85.358437] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64 
0x004208FC 0x00439E4C
[   85.366479] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84 
0x004208FC 0x00425AAC
[   85.374512] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4 
0x00424FE8 0x0002
[   85.382548] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14 
0x0004 0x004039D0

[   85.487067] ieee80211 phy0: Hardware restart was 

[LEDE-DEV] [PATCH] map: Have cmake find libubus.h

[Florian Fainelli]

Update CMakeList.txt to look for libubus.h since we depend on it.

Signed-off-by: Florian Fainelli 
---
 package/network/ipv6/map/src/CMakeLists.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/network/ipv6/map/src/CMakeLists.txt 
b/package/network/ipv6/map/src/CMakeLists.txt
index 2cbeb2c261be..a839373022fc 100644
--- a/package/network/ipv6/map/src/CMakeLists.txt
+++ b/package/network/ipv6/map/src/CMakeLists.txt
@@ -5,6 +5,9 @@ project(mapcalc C)
 set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g -std=c99")
 
+FIND_PATH(ubus_include_dir libubus.h)
+INCLUDE_DIRECTORIES(${ubus_include_dir})
+
 add_definitions(-D_GNU_SOURCE -Wall -Wno-gnu -Wextra)
 
 add_executable(mapcalc mapcalc.c)
-- 
2.10.2


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

[LEDE-DEV] [PATCH mdns] cmake: Search for libjson-c

[Florian Fainelli]

Since we use libblobmsg_json which uses libjson-c internally, make sure
we find this library.

Signed-off-by: Florian Fainelli 
---
 CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f191fa5c1716..4052bcdb80ad 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -7,7 +7,7 @@ SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
 
 SET(SOURCES main.c dns.c announce.c cache.c service.c util.c ubus.c 
interface.c)
 
-SET(LIBS ubox ubus resolv blobmsg_json)
+SET(LIBS ubox ubus resolv blobmsg_json json-c)
 
 IF(DEBUG)
   ADD_DEFINITIONS(-DDEBUG -g3)
-- 
2.10.2


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

Re: [LEDE-DEV] [PATCH] hostapd: update to version 2016-12-12

[Felix Fietkau]

On 2016-12-13 18:04, Koen Vandeputte wrote:
> Update to latest upstream HEAD:
> 
> - Refreshed all
> - Delete patches and parts which made it upstream
> - Add new patch 480 which fixes a build error in the Mini config due to
> missing macro's
> 
> Compile tested Full & Mini configs
> Run-tested Mini config
> 
> Signed-off-by: Koen Vandeputte 
A few questions:
- Does patch 480 fix an upstream bug or a bug in another patch
- What's with the chunk you dropped from the ubus patch?

- Felix

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

[LEDE-DEV] DMARC related mass bounces / disabled subscriptions

[Jo-Philipp Wich]

Hi list,

a recent mailing list post from a DMARC enabled domain caused a large
flood of bounces from various mail providers, causing an automatic
disabling of about 190 subscriptions [1].

I re-enabled those subscriptions manually so there is no need for
further action on your side.

In order to mitigate this problem in the future, I configured this list
to wrap mails from DMARC enabled domains into an outer mail using the
mailing list itself as sender [2].

Please excuse the inconvenience caused by this issue.


Regards,
Jo

1:
http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html
2:
https://wiki.list.org/DOC/Mailman%202.1%20List%20Administrators%20Manual#line-544



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Benjamin Morgan]

Just tested the latest 10.2.4.70.59-2 firmware and it still crashes with 
wpa_supplicant encrypted mesh =(


[   85.201440] ath10k_pci :01:00.0: firmware crashed! (uuid 
b7f44483-0488-46af-8dff-db88f4b56327)
[   85.210573] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub :
[   85.219940] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 1
[   85.233034] ath10k_pci :01:00.0: firmware ver 10.2.4.70.59-2 api 
5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
[   85.245177] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[   85.252592] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1

[   85.264235] ath10k_pci :01:00.0: firmware register dump:
[   85.269992] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 
0x009A45AF 0x00955B31
[   85.278031] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130 
0x0002 0x00439E98
[   85.286078] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[   85.294107] ath10k_pci :01:00.0: [12]: 0x0009 0x 
0x009A3550 0x009A355E
[   85.302152] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D 
0x 0x
[   85.310195] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4 
0x0040AC60 0x0040AC09
[   85.318239] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24 
0x0040 0xC09A45AF
[   85.326282] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84 
0x0044110C 0x00442074
[   85.334314] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4 
0x0044110C 0x00407120
[   85.342350] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
0x0040AC14 0x1580
[   85.350393] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04 
0x009C6458 0x004436CC
[   85.358437] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64 
0x004208FC 0x00439E4C
[   85.366479] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84 
0x004208FC 0x00425AAC
[   85.374512] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4 
0x00424FE8 0x0002
[   85.382548] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14 
0x0004 0x004039D0

[   85.487067] ieee80211 phy0: Hardware restart was requested
[   85.492701] ath10k_pci :01:00.0: wmi disable pktlog

Any new leads on tracking down this issue?

~Benjamin


On 12/06/2016 01:32 PM, Benjamin Morgan wrote:
1. Yes, this appears to happens every time a unicast packet with 
wpa_supplicant encryption in VHT80 mode is received. I haven't seen a 
successful ping-pong pair.

2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
3. We ran our experiment again with extra debugging turned on.
Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
The ping command we used was run on Node A was 'ping -s 1500 -i 
0.1 10.230.5.42'

Here is the dmesg log from Node B.

[ 5413.478170] ath10k_pci :01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5413.503954] ath10k_pci :01:00.0: scan event bss channel type 4 
reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
[ 5413.503985] ath10k_pci :01:00.0: chan info err_code 0 freq 5825 
cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count 312271423
[ 5413.504029] ath10k_pci :01:00.0: scan event completed type 2 
reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
[ 5413.525868] ath10k_pci :01:00.0: wmi vdev install key idx 1 
cipher 4 len 16
[ 5413.526014] ath10k_pci :01:00.0: wmi vdev id 0x0 set param 31 
value 1

[ 5413.526193] ath10k_pci :01:00.0: mac vdev 0 set keyidx 1
[ 5413.526216] ath10k_pci :01:00.0: wmi vdev id 0x0 set param 31 
value 1
[ 5413.526532] ath10k_pci :01:00.0: mac chanctx add freq 5180 
width 3 ptr 86db29b0
[ 5413.526556] ath10k_pci :01:00.0: mac monitor recalc started? 0 
needed? 0 allowed? 1
[ 5413.526574] ath10k_pci :01:00.0: mac chanctx assign ptr 
86db29b0 vdev_id 0
[ 5413.526592] ath10k_pci :01:00.0: mac vdev 0 start center_freq 
5180 phymode 11ac-vht80
[ 5413.526616] ath10k_pci :01:00.0: wmi vdev start id 0x0 flags: 
0x0, freq 5180, mode 10, ch_flags: 0xA00, max_power: 46

[ 5413.533099] ath10k_pci :01:00.0: WMI_VDEV_START_RESP_EVENTID
[ 5413.533148] ath10k_pci :01:00.0: mac vdev_id 0 txpower 23
[ 5413.533163] ath10k_pci :01:00.0: mac txpower 23
[ 5413.533180] ath10k_pci :01:00.0: wmi pdev set param 3 value 46
[ 5413.533247] ath10k_pci :01:00.0: wmi pdev set param 4 value 46
[ 5413.533295] ath10k_pci :01:00.0: mac chanctx change freq 5180 
width 3 ptr 86db29b0 changed 10
[ 5413.533318] ath10k_pci :01:00.0: mac chanctx change freq 5180 
width 3 ptr 86db29b0 changed 2
[ 5413.57] ath10k_pci :01:00.0: mac monitor recalc started? 0 
needed? 1 allowed? 1
[ 5413.533357] ath10k_pci :01:00.0: WMI vdev create: id 1 type 4 
subtype 0 macaddr 18:a6:f7:26:0f:21

[ 5413.533412] ath10k_pci :01:00.0: mac monitor vdev 1 created
[ 

[LEDE-DEV] [PATCH] mac80211: backport "cfg80211: limit scan results cache size"

[Christian Lamparter]

The patch commit states:
"It's possible to make scanning consume almost arbitrary amounts
of memory, e.g. by sending beacon frames with random BSSIDs at
high rates while somebody is scanning.

Limit the number of BSS table entries we're willing to cache to
1000, limiting maximum memory usage to maybe 4-5MB, but lower
in practice - that would be the case for having both full-sized
beacon and probe response frames for each entry; this seems not
possible in practice, so a limit of 1000 entries will likely be
closer to 0.5 MB."

Signed-off-by: Johannes Berg "

This patch was added in 4.4.36. But because LEDE backports
cfg80211, mac80211 and the wifi drivers separately, it needs
to be added manually for now. It can be dropped later as it
will be part of the next mac80211 refresh.

Signed-off-by: Christian Lamparter 
---
 ...06-cfg80211-limit-scan-results-cache-size.patch | 161 +
 1 file changed, 161 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch

diff --git 
a/package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch
 
b/package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch
new file mode 100644
index 00..eb26fd9241
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch
@@ -0,0 +1,161 @@
+From 9853a55ef1bb66d7411136046060bbfb69c714fa Mon Sep 17 00:00:00 2001
+From: Johannes Berg 
+Date: Tue, 15 Nov 2016 12:05:11 +0100
+Subject: [PATCH] cfg80211: limit scan results cache size
+
+It's possible to make scanning consume almost arbitrary amounts
+of memory, e.g. by sending beacon frames with random BSSIDs at
+high rates while somebody is scanning.
+
+Limit the number of BSS table entries we're willing to cache to
+1000, limiting maximum memory usage to maybe 4-5MB, but lower
+in practice - that would be the case for having both full-sized
+beacon and probe response frames for each entry; this seems not
+possible in practice, so a limit of 1000 entries will likely be
+closer to 0.5 MB.
+
+Cc: sta...@vger.kernel.org
+Signed-off-by: Johannes Berg 
+---
+ net/wireless/core.h |  1 +
+ net/wireless/scan.c | 69 +
+ 2 files changed, 70 insertions(+)
+
+diff --git a/net/wireless/core.h b/net/wireless/core.h
+index 08d2e948c9ad..f0c0c8a48c92 100644
+--- a/net/wireless/core.h
 b/net/wireless/core.h
+@@ -71,6 +71,7 @@ struct cfg80211_registered_device {
+   struct list_head bss_list;
+   struct rb_root bss_tree;
+   u32 bss_generation;
++  u32 bss_entries;
+   struct cfg80211_scan_request *scan_req; /* protected by RTNL */
+   struct sk_buff *scan_msg;
+   struct cfg80211_sched_scan_request __rcu *sched_scan_req;
+diff --git a/net/wireless/scan.c b/net/wireless/scan.c
+index b5bd58d0f731..35ad69fd0838 100644
+--- a/net/wireless/scan.c
 b/net/wireless/scan.c
+@@ -57,6 +57,19 @@
+  * also linked into the probe response struct.
+  */
+ 
++/*
++ * Limit the number of BSS entries stored in mac80211. Each one is
++ * a bit over 4k at most, so this limits to roughly 4-5M of memory.
++ * If somebody wants to really attack this though, they'd likely
++ * use small beacons, and only one type of frame, limiting each of
++ * the entries to a much smaller size (in order to generate more
++ * entries in total, so overhead is bigger.)
++ */
++static int bss_entries_limit = 1000;
++module_param(bss_entries_limit, int, 0644);
++MODULE_PARM_DESC(bss_entries_limit,
++ "limit to number of scan BSS entries (per wiphy, default 
1000)");
++
+ #define IEEE80211_SCAN_RESULT_EXPIRE  (30 * HZ)
+ 
+ static void bss_free(struct cfg80211_internal_bss *bss)
+@@ -137,6 +150,10 @@ static bool __cfg80211_unlink_bss(struct 
cfg80211_registered_device *rdev,
+ 
+   list_del_init(>list);
+   rb_erase(>rbn, >bss_tree);
++  rdev->bss_entries--;
++  WARN_ONCE((rdev->bss_entries == 0) ^ list_empty(>bss_list),
++"rdev bss entries[%d]/list[empty:%d] corruption\n",
++rdev->bss_entries, list_empty(>bss_list));
+   bss_ref_put(rdev, bss);
+   return true;
+ }
+@@ -163,6 +180,40 @@ static void __cfg80211_bss_expire(struct 
cfg80211_registered_device *rdev,
+   rdev->bss_generation++;
+ }
+ 
++static bool cfg80211_bss_expire_oldest(struct cfg80211_registered_device 
*rdev)
++{
++  struct cfg80211_internal_bss *bss, *oldest = NULL;
++  bool ret;
++
++  lockdep_assert_held(>bss_lock);
++
++  list_for_each_entry(bss, >bss_list, list) {
++  if (atomic_read(>hold))
++  continue;
++
++  if (!list_empty(>hidden_list) &&
++  !bss->pub.hidden_beacon_bss)
++  continue;
++
++  if (oldest && time_before(oldest->ts, 

[LEDE-DEV] [PATCH] hostapd: update to version 2016-12-12

[Koen Vandeputte]

Update to latest upstream HEAD:

- Refreshed all
- Delete patches and parts which made it upstream
- Add new patch 480 which fixes a build error in the Mini config due to
missing macro's

Compile tested Full & Mini configs
Run-tested Mini config

Signed-off-by: Koen Vandeputte 
---
 package/network/services/hostapd/Makefile  |  4 +-
 ...ix-reconnecting-client-on-connection-lost.patch |  8 ++--
 .../hostapd/patches/100-daemonize_fix.patch|  4 +-
 .../hostapd/patches/110-no_eapol_fix.patch |  2 +-
 ...211-Remove-duplicated-check-in-nl80211_se.patch | 39 -
 .../services/hostapd/patches/200-multicall.patch   | 50 --
 .../services/hostapd/patches/300-noscan.patch  |  4 +-
 .../hostapd/patches/310-rescan_immediately.patch   |  2 +-
 .../hostapd/patches/320-optional_rfkill.patch  |  8 ++--
 .../hostapd/patches/330-nl80211_fix_set_freq.patch |  2 +-
 .../patches/350-nl80211_del_beacon_bss.patch   | 12 +++---
 .../hostapd/patches/360-ctrl_iface_reload.patch|  4 +-
 .../hostapd/patches/370-ap_sta_support.patch   |  8 ++--
 .../patches/380-disable_ctrl_iface_mib.patch   | 36 
 .../patches/390-wpa_ie_cap_workaround.patch|  4 +-
 .../hostapd/patches/430-hostapd_cli_ifdef.patch|  8 ++--
 ...ant-add-new-config-params-to-be-used-with.patch | 14 +++---
 ...80211-use-new-parameters-during-ibss-join.patch |  4 +-
 .../patches/462-wpa_s-support-htmode-param.patch   | 12 +++---
 .../hostapd/patches/480-Fix-Mini-BuildError.patch  | 41 ++
 .../hostapd/patches/600-ubus_support.patch | 50 +++---
 21 files changed, 151 insertions(+), 165 deletions(-)
 delete mode 100644 
package/network/services/hostapd/patches/130-Revert-nl80211-Remove-duplicated-check-in-nl80211_se.patch
 create mode 100644 
package/network/services/hostapd/patches/480-Fix-Mini-BuildError.patch

diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index 9570b2a..1171c03 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,9 +7,9 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=hostapd
-PKG_VERSION:=2016-09-05
+PKG_VERSION:=2016-12-12
 PKG_RELEASE:=1
-PKG_REV:=fcd85d9a3f2d9d63d0fa57e93446ad467db75b23
+PKG_REV:=fb748ae8582221076252207550b64f8048c948ad
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://w1.fi/hostap.git
diff --git 
a/package/network/services/hostapd/patches/001-4addr-fix-reconnecting-client-on-connection-lost.patch
 
b/package/network/services/hostapd/patches/001-4addr-fix-reconnecting-client-on-connection-lost.patch
index 5c8b662..2a748a0 100644
--- 
a/package/network/services/hostapd/patches/001-4addr-fix-reconnecting-client-on-connection-lost.patch
+++ 
b/package/network/services/hostapd/patches/001-4addr-fix-reconnecting-client-on-connection-lost.patch
@@ -15,11 +15,11 @@ Signed-off-by: Matthias May 
 
 --- a/src/ap/ieee802_11.c
 +++ b/src/ap/ieee802_11.c
-@@ -2826,6 +2826,7 @@ static void handle_assoc_cb(struct hosta
+@@ -3210,6 +3210,7 @@ static void handle_assoc_cb(struct hosta
new_assoc = 0;
sta->flags |= WLAN_STA_ASSOC;
sta->flags &= ~WLAN_STA_WNM_SLEEP_MODE;
 +  sta->flags &= ~WLAN_STA_WDS;
-   if ((!hapd->conf->ieee802_1x && !hapd->conf->wpa && !hapd->conf->osen) 
||
-   sta->auth_alg == WLAN_AUTH_FT) {
-   /*
+   if ((!hapd->conf->ieee802_1x && !hapd->conf->wpa &&
+!hapd->conf->osen) ||
+   sta->auth_alg == WLAN_AUTH_FILS_SK ||
diff --git a/package/network/services/hostapd/patches/100-daemonize_fix.patch 
b/package/network/services/hostapd/patches/100-daemonize_fix.patch
index 0389406..fad8466 100644
--- a/package/network/services/hostapd/patches/100-daemonize_fix.patch
+++ b/package/network/services/hostapd/patches/100-daemonize_fix.patch
@@ -60,13 +60,13 @@
 +  if (chdir("/") < 0)
return -1;
 -  }
- 
+-
 -  return 0;
 -}
 -#else /* __APPLE__ */
 -#define os_daemon daemon
 -#endif /* __APPLE__ */
--
+ 
 -
 -int os_daemonize(const char *pid_file)
 -{
diff --git a/package/network/services/hostapd/patches/110-no_eapol_fix.patch 
b/package/network/services/hostapd/patches/110-no_eapol_fix.patch
index 5aee3d0..5181721 100644
--- a/package/network/services/hostapd/patches/110-no_eapol_fix.patch
+++ b/package/network/services/hostapd/patches/110-no_eapol_fix.patch
@@ -1,6 +1,6 @@
 --- a/wpa_supplicant/wpa_supplicant.c
 +++ b/wpa_supplicant/wpa_supplicant.c
-@@ -257,9 +257,10 @@ void wpa_supplicant_cancel_auth_timeout(
+@@ -259,9 +259,10 @@ void wpa_supplicant_cancel_auth_timeout(
   */
  void wpa_supplicant_initiate_eapol(struct wpa_supplicant *wpa_s)
  {
diff --git 
a/package/network/services/hostapd/patches/130-Revert-nl80211-Remove-duplicated-check-in-nl80211_se.patch
 

[LEDE-DEV] [PATCH] libubox: allow reading out the pid of uloop process in lua

[Florian Eckert]

Add Lua methode to get the forked pid of a uloop process

Signed-off-by: Florian Eckert 
---
 lua/uloop.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/lua/uloop.c b/lua/uloop.c
index a78c2dc..1b0389f 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -288,8 +288,21 @@ static int ul_process_free(lua_State *L)
return 1;
 }
 
+static int ul_process_pid(lua_State *L)
+{
+   struct lua_uloop_process *proc = lua_touserdata(L, 1);
+
+   if (proc->p.pid) {
+   lua_pushnumber(L, proc->p.pid);
+   return 1;
+   }
+
+   return 0;
+}
+
 static const luaL_Reg process_m[] = {
{ "delete", ul_process_free },
+   { "pid", ul_process_pid },
{ NULL, NULL }
 };
 
-- 
2.1.4


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

Re: [LEDE-DEV] Help on porting new device (DCS-933L)

[John Crispin]

On 13/12/2016 09:43, John Crispin wrote:
> 
> 
> On 13/12/2016 09:17, Luiz Angelo Daros de Luca wrote:
>> Hello,
>>
>> I'm trying to port LEDE to a new device DCS-933L. It's a dlink ip
>> camera with 8MB Flash and 64 MB RAM. Currently my branch is published
>> on https://github.com/luizluca/source/tree/add_dcs933lb1
>>
>> It seems to be going well (as it is my first port) but I cannot see
>> the webcam. I guess its camera and audio device are connected via USB.
>>
>> This is the factory bootlog:
>> https://wiki.openwrt.org/toh/d-link/dcs-930l#factory_bootlog_dcs-933l
>> and this is my current bootlog: http://pastebin.com/pJjPB90E
>>
>> I'm not an DTS expert and all I did was trial'n'error. Maybe it is
>> just a simple mistake.
>> Maybe it is related to this message "ralink-usb-phy usbphy: invalid 
>> resource".
> 
> 
> that error is unrelated. newer phys need a more complete init. the error
> is a side effect of that init not being required.
> 
> if you look at lines 117/118 you will see that the phy loads just fine
> and that a few lines further down the ports are being detected.
> 
> my guess would be that the power to the webcam is controlled via a gpio.
> 
>   John
> 

do you have the A1 or A2 version ? i want to download the GPL source
from d-link and see if i can find any info regarding a gpio inside it.
but there are 2 versions of the HW

John



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

[LEDE-DEV] Help on porting new device (DCS-933L)

[Luiz Angelo Daros de Luca]

Hello,

I'm trying to port LEDE to a new device DCS-933L. It's a dlink ip
camera with 8MB Flash and 64 MB RAM. Currently my branch is published
on https://github.com/luizluca/source/tree/add_dcs933lb1

It seems to be going well (as it is my first port) but I cannot see
the webcam. I guess its camera and audio device are connected via USB.

This is the factory bootlog:
https://wiki.openwrt.org/toh/d-link/dcs-930l#factory_bootlog_dcs-933l
and this is my current bootlog: http://pastebin.com/pJjPB90E

I'm not an DTS expert and all I did was trial'n'error. Maybe it is
just a simple mistake.
Maybe it is related to this message "ralink-usb-phy usbphy: invalid resource".

Can someone help me?

Regards,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com

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

Re: [LEDE-DEV] [PATCH] libubus: initialize list member for ubus_auto_conn's timer

[Alexandru Ardelean]

On Tue, Dec 13, 2016 at 9:52 AM, Felix Fietkau  wrote:
> On 2016-12-13 08:41, Alexandru Ardelean wrote:
>> Every once in a while, we'll get stacktrace:
>> ```
>> (gdb) bt
>> \#0  0xb7bc4668 in _list_del (entry=0x10015688 ) at 
>> /home/sandu/work/Wrt/openwrt/build_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/libubox-2015-06-29/list.h:83
>> \#1  list_del (entry=0x10015688 ) at 
>> /home/sandu/work/Wrt/openwrt/build_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/libubox-2015-06-29/list.h:90
>> \#2  uloop_timeout_cancel (timeout=timeout@entry=0x10015688 ) at 
>> /home/sandu/work/Wrt/openwrt/build_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/libubox-2015-06-29/uloop.c:474
>> \#3  0x10003794 in ubus_auto_shutdown (conn=0x10015614 ) at 
>> /home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/usr/include/libubus.h:249
>> \#4  module_ubus_fini () at ubus.c:64
>> \#5  0x100013fc in main (argc=, argv=) at 
>> module.c:128
>> ```
>>
>> In our code, `ubus_auto_connect()` is called, then due to some logic,
>> the module has to quickly stop, calling ubus_auto_shutdown().
>>
>> It seems that there is case in where the `timer` timeout, is not yet
>> registered with the internal list of timeouts from uloop, which
>> ends up trying to delete an invalid list.
>>
>> So, one solution is to init the list element of the `timer` of
>> the `ubus_auto_conn` struct.
>>
>> Signed-off-by: Alexandru Ardelean 
> I think this patch is a workaround that simply hides the real issue.
> uloop_timeout_cancel will only call list_del if the timer 'pending' flag
> is set.
>
> It seems to me that you might be using ubus_auto_connect on
> uninitialized memory. If that's the case, you might run into issues in
> other places as well, and you should just add a memset to your application.
>
> - Felix

Hmmm, you're right.
It is only one module I'm seeing this in.
Maybe it's some weird memory corruption, or race ; since that
ubus_auto_conn struct is init-ed to 0 [since it's static].

Will dig deeper into that.

Sorry for the noise.

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