Re: [LEDE-DEV] regulatory domain information

2016-11-18 Thread Charles 
on 2016-10-19 Charles wrote:

Sorry to bother you again with this, but it looks like there's only 1
out of 3 questions answered so far.  Here are some updates on my
observations:

> on a TP-Link WDR3600 v1 (dual-band wifi, ath9k, wireless settings are
> attached below, most notably wireless.radioX.country=DE), the output
> of command 'iw reg get' is
> 
> with OpenWrt 15.05.1:
> 
> country DE: DFS-ETSI
>   (2400 - 2483 @ 40), (N/A, 20), (N/A)
>   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
>   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
>   (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
>   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> 
> and with current LEDE:
> 
> global
> country DE: DFS-ETSI
>   (2400 - 2483 @ 40), (N/A, 20), (N/A)
>   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
>   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
>   (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
>   (5725 - 5875 @ 80), (N/A, 14), (N/A)
>   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> 
> phy#1
> country US: DFS-FCC
>   (2402 - 2472 @ 40), (N/A, 30), (N/A)
>   (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
>   (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
>   (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
>   (5735 - 5835 @ 80), (N/A, 30), (N/A)
>   (57240 - 63720 @ 2160), (N/A, 40), (N/A)
> 
> phy#0
> country US: DFS-FCC
>   (2402 - 2472 @ 40), (N/A, 30), (N/A)
>   (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
>   (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
>   (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
>   (5735 - 5835 @ 80), (N/A, 30), (N/A)
>   (57240 - 63720 @ 2160), (N/A, 40), (N/A)
> 
> global
> country DE: DFS-ETSI
>   (2400 - 2483 @ 40), (N/A, 20), (N/A)
>   (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
>   (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
>   (5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
>   (5725 - 5875 @ 80), (N/A, 14), (N/A)
>   (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> 
> Questions:
> 
> 1. Why does LEDE show four regulatory domain blocks while OpenWrt shows
>only one?

The last 'global' section is not shown by 'iw reg get' with yesterday's
LEDE snapshot anymore, but that's still two more 'FCC' sections than in
OpenWrt 15.05.1. Are these changes related to LEDE or upstream?


> 2. What does the "country US: DFS-FCC" blocks tell me when radio is set
>to an ETSI region country (DE) according to uci?
> 
> 3. What does AUTO-BW mean?
> 
> tnx, Charles
> 
> 
> $uci export wireless
> 
> config wifi-device 'radio0'
>   option type 'mac80211'
>   option channel '11'
>   option hwmode '11g'
>   option path 'platform/ar934x_wmac'
>   option htmode 'HT20'
>   option country 'DE'
> 
> config wifi-iface
>   option device 'radio0'
>   option network 'lan'
>   option mode 'ap'
>   option ssid 'OpenWrt'
>   option encryption 'none'
> 
> config wifi-device 'radio1'
>   option type 'mac80211'
>   option hwmode '11a'
>   option path 'pci:00/:00:00.0'
>   option htmode 'HT20'
>   option country 'DE'
>   option channel '36'
> 
> config wifi-iface
>   option device 'radio1'
>   option network 'lan'
>   option mode 'ap'
>   option ssid 'OpenWrt'
>   option encryption 'none'




___
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-11-18 Thread Adrian Chadd 
hiya!

Can you file a kernel.org bug mentioning this?

thanks!


-a


On 18 November 2016 at 01:30, Timo Sigurdsson
 wrote:
> Hi again,
>
> in the meantime, I have some more information to add to the issue mentioned in
> my email quoted further down below.
>
> Ben Greear approached me off-list and suggested to try the Candela Tech ath10k
> driver and firmware and see if the issue occurs with that as well. So, for the
> last 3 weeks I've been testing the CT driver and firmware and I can happily
> report that the issue with the driver crashing after a while when a Nexus 5X
> device is connected is not occuring with the current BETA 18
> firmware-2-ct-full-community.bin. So, this really seems like a regression in
> the official API level 5 ath10k firmware blobs.
>
> The CT firmware is not perfect either, since it seems to suffer from a 
> different
> bug that has been resolved in the official firmwares, and that is that after a
> reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only after a
> hard reset or "cold boot" it will come up. That's an issue I had with older
> official firmwares as well, but it has been resolved with the recent API level
> 5 firmwares.
>
> Nevertheless, for the time being, I will stick to the CT firmware because I 
> can
> work around the reboot issue and having the 5GHz wifi working for my Nexus 5X
> clients is more important.
>
> Over the next weeks, I will test different combinations of ath10k(-ct) driver
> and firmware to see if there's a combination that resolves all issues. This
> morning I flashed a LEDE build with the official ath10k driver and the CT
> firmware binary.
>
> But of course, if someone has more suggestions on what I could try or what
> information I could collect to help resolve the issue related to the Nexus 5X
> clients in the official firmware binaries, I think that would be beneficial
> for a larger audience.
>
> Regards,
>
> Timo
>
> P.S.: Please include my email address in any reply, since I'm not subscribed
> to the mailing list. Thank you.
>
>
> Timo Sigurdsson schrieb am 29.10.2016 22:19:
>
>> Hi everybody,
>>
>> I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE (r1952,
>> Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for the
>> fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel or
>> ath10k driver will crash after a while. 5Ghz wifi will be dead after that
>> until I reboot the system.
>>
>> This issue has been reported before [1] and it also has been declared as
>> solved with newer firmwares [2] (but reopened by other users). However, even
>> with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository the
>> issue is far from resolved. I have tried many different firmware revisions
>> over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can could
>> only find that the issue sometimes takes longer to trigger with some 
>> firmwares
>> (which might just be random), but it would always occur at some point with 
>> API
>> level 5 firmwares. With API level 2 firmwares (which I testesd when I was
>> still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had
>> other connectivity issues with these older firmwares that made this
>> combination no fun to use either. But this shows that the firmware itself
>> makes the difference here.
>>
>> I actually have two Nexus 5X on my network (my wife's and my own). I can
>> trigger the crash with either one of them. And if both Nexus 5X are connected
>> to the 5Ghz radio, then the issue triggers much faster (can be as low as 15
>> minutes). My workaround is to let the Nexus 5X devices only connect to the
>> 2.4GHz radio. This way, the device can runs for weeks without any issue or
>> crash, but of course I would prefer the actual bug being fixed rather than to
>> circumvent it.
>>
>> I'm appending a syslog from my access point with a crash happening while one
>> Nexus 5X was connected to the 5GHz radio starting from the time the system
>> booted. I randomized the MAC addresses. but left the first two characters
>> unique so different clients can be distinguished.
>>
>> If there is more info I could collect to help identify the cause of this
>> issue, please let me know (and possibly how to do that as well).
>>
>> Thank you and regards,
>>
>> Timo
>>
>> [1] http://lists.infradead.org/pipermail/ath10k/2015-November/006413.html
>> [2] https://dev.openwrt.org/ticket/20854
>>
>> And here's the log:
>> Fri Oct 28 02:01:35 2016 kern.notice kernel: [0.00] Linux version
>> 4.4.26 (user@buildsystem) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1952) ) #0 Fri
>> Oct 21 15:52:28 2016
>> [...]
>> Fri Oct 28 02:01:35 2016 kern.info kernel: [9.468751] Loading modules
>> backported from Linux version wt-2016-10-03-1-g6fcb1a6
>> Fri Oct 28 02:01:35 2016 kern.info kernel: [9.476481] Backport generated 
>> by
>> backports.git backports-20160324-9-g0e38f5c
>> Fri Oct 28 02:01:35

Re: [LEDE-DEV] netifd: proto_add_host_dependency()

2016-11-18 Thread Hans Dedecker 
On Friday, 18 November 2016 12:33:25 CET Dan Lüdtke wrote:
> Hi everyone,
> 
> I have a weird situation where proto_add_host_dependency() does not like
> IPv6 addresses. The WAN/WAN6 interface don't have global unicast addresses
> assigned, but my protocol script calls
> 
>  proto_add_host_dependency "${config}" "${ip}"
> 
> with $ip containing a global unicast address. Interface setup fails. If I
> use IPv4 instead, interface setup succeeds.
> 
> I a bit puzzled, because I think I have seen this working before.
> Testing on latest (OpenWRT) snapshot. Has netifd diverged in LEDE already?
OpenWRT uses an older netifd version then Lede but afaik there has been no 
changes in the hostdependency logic

In the setups I use with IPv6 and proto_add_host_dependency I don't experience 
any issues.
Check the IPv6 routes present in netifd as the proto_add_host_dependcy 
requires the IPv6 address specified as argument being reachable by an IPv6 
route

Hans
> 
> Source:
> https://github.com/openwrt/packages/blob/d1c890896c0cae4516a222a0adcf01d91f
> 8d0503/net/wireguard/files/wireguard.sh#L87
> 
> Any ideas?
> 
> Dan
> ___
> 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] regulatory domain information

2016-11-18 Thread Charles 
on 2016-10-20 Charles wrote:
> on 2016-10-19 Charles wrote:
> 
> > Questions:  
> 
> A similar observation: With OpenWrt 15.05.1, after booting, dmesg
> output contains driver messages related to regulatory domain
> changes and final (I hope) settings:
> 
> > [   10.85] cfg80211: Calling CRDA to update world regulatory
> > domain [   10.88] cfg80211: World regulatory domain updated:
> > [   10.88] cfg80211:  DFS Master region: unset
> > [   10.89] cfg80211:   (start_freq - end_freq @ bandwidth),
> > (max_antenna_gain, max_eirp), (dfs_cac_time) [   10.90]
> > cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000
> > mBm), (N/A) [   10.91] cfg80211:   (2457000 KHz - 2482000 KHz @
> > 2 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A) [   10.92]
> > cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000
> > mBm), (N/A) [   10.92] cfg80211:   (517 KHz - 525 KHz @
> > 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (N/A) [   10.93]
> > cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz
> > AUTO), (N/A, 2000 mBm), (0 s) [   10.94] cfg80211:   (549
> > KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s)
> > [   10.95] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz),
> > (N/A, 2000 mBm), (N/A) [   10.96] cfg80211:   (5724 KHz -
> > 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) ... [   11.14]
> > cfg80211: Calling CRDA for country: US [   11.14] cfg80211:
> > Regulatory domain changed to country: US [   11.15] cfg80211:
> > DFS Master region: FCC [   11.15] cfg80211:   (start_freq -
> > end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> > [   11.16] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz),
> > (N/A, 3000 mBm), (N/A) [   11.17] cfg80211:   (517 KHz -
> > 525 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2300 mBm), (N/A)
> > [   11.18] cfg80211:   (525 KHz - 533 KHz @ 8 KHz,
> > 16 KHz AUTO), (N/A, 2300 mBm), (0 s) [   11.19] cfg80211:
> > (549 KHz - 573 KHz @ 16 KHz), (N/A, 2300 mBm), (0 s)
> > [   11.20] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz),
> > (N/A, 3000 mBm), (N/A) [   11.21] cfg80211:   (5724 KHz -
> > 6372 KHz @ 216 KHz), (N/A, 4000 mBm), (N/A) ...
> > [   19.92] cfg80211: Calling CRDA for country: DE
> > [   19.94] cfg80211: Regulatory domain changed to country: DE
> > [   19.95] cfg80211:  DFS Master region: ETSI [   19.95]
> > cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> > max_eirp), (dfs_cac_time) [   19.96] cfg80211:   (240 KHz -
> > 2483000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [   19.97]
> > cfg80211:   (515 KHz - 525 KHz @ 8 KHz, 20 KHz
> > AUTO), (N/A, 2000 mBm), (N/A) [   19.98] cfg80211:   (525
> > KHz - 535 KHz @ 8 KHz, 20 KHz AUTO), (N/A, 2000 mBm),
> > (0 s) [   19.99] cfg80211:   (547 KHz - 5725000 KHz @
> > 16 KHz), (N/A, 2700 mBm), (0 s) [   20.00] cfg80211:
> > (5700 KHz - 6600 KHz @ 216 KHz), (N/A, 4000 mBm),
> > (N/A)  
> 
> One can easily see region changing from 'unset' over 'FCC' to 'ETSI'.
> 
> With current LEDE, however, these messages are completely missing,
> making it harder to trust radio obeying regulatory rules.  I mean,
> what is the rationale for this change (as well as that subject of the
> other mail)?

With yesterday's LEDE snapshot, it looks like regulatory messages are
back. Not quite the same, but similar:

> [8.960274] ath: EEPROM regdomain: 0x0
> [8.960293] ath: EEPROM indicates default country code should be used
> [8.960303] ath: doing EEPROM country->regdmn map search
> [8.960325] ath: country maps to regdmn code: 0x3a
> [8.960336] ath: Country alpha2 being used: US
> [8.960346] ath: Regpair used: 0x3a
> [8.972638] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [8.977433] ieee80211 phy0: Atheros AR9340 Rev:2 mem=0xb810, irq=47
> [8.984380] PCI: Enabling device :00:00.0 ( -> 0002)
> [8.995580] ath: EEPROM regdomain: 0x0
> [8.995597] ath: EEPROM indicates default country code should be used
> [8.995608] ath: doing EEPROM country->regdmn map search
> [8.995629] ath: country maps to regdmn code: 0x3a
> [8.995640] ath: Country alpha2 being used: US
> [8.995650] ath: Regpair used: 0x3a
> [9.005211] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
> [9.010033] ieee80211 phy1: Atheros AR9300 Rev:4 mem=0xb000, irq=40
>   [...]
> [   16.942415] ath: EEPROM regdomain: 0x8114
> [   16.946491] ath: EEPROM indicates we should expect a country code
> [   16.952718] ath: doing EEPROM country->regdmn map search
> [   16.958107] ath: country maps to regdmn code: 0x37
> [   16.962977] ath: Country alpha2 being used: DE
> [   16.967487] ath: Regpair used: 0x37
> [   16.971028] ath: regdomain 0x8114 dynamically updated by user
>

[LEDE-DEV] [LEDE-DEV, v2] ar71xx: Fix switch config on Mikrotik RB450/G

2016-11-18 Thread João Chaínho 
This patch fixes the ethernet switch initial config for Mikrotik RB450 and 
RB450G.
The previous version wrongly changed the RouterStation Pro config. This one 
creates a specific config for the RB450G and leaves the RouterStation Pro 
unchanged.

Signed-off-by: João Chaínho 
---
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index df87c96..a2e02d5 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -343,9 +343,13 @@ ar71xx_setup_interfaces()
rb-450)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \
-   "0:lan" "1:lan" "2:lan" "3:lan" "5@eth1"
+   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "5@eth1"
+   ;;
+   rb-450g)
+   ucidef_set_interfaces_lan_wan "eth1" "eth0"
+   ucidef_add_switch "switch0" \
+   "0@eth1" "1:lan:1" "2:lan:4" "3:lan:3" "4:lan:2"
;;
-   rb-450g|\
routerstation-pro)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \

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

[LEDE-DEV] netifd: proto_add_host_dependency()

2016-11-18 Thread Dan Lüdtke 
Hi everyone,

I have a weird situation where proto_add_host_dependency() does not like IPv6 
addresses. The WAN/WAN6 interface don't have global unicast addresses assigned, 
but my protocol script calls

 proto_add_host_dependency "${config}" "${ip}"

with $ip containing a global unicast address. Interface setup fails. If I use 
IPv4 instead, interface setup succeeds.

I a bit puzzled, because I think I have seen this working before.
Testing on latest (OpenWRT) snapshot. Has netifd diverged in LEDE already?

Source: 
https://github.com/openwrt/packages/blob/d1c890896c0cae4516a222a0adcf01d91f8d0503/net/wireguard/files/wireguard.sh#L87

Any ideas?

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

[LEDE-DEV] [PATCH v3] mt7621: add support for WeVO W2914NS v2

2016-11-18 Thread perillamint 
Signed-off-by: Yong-hyu Ban 
---

Changelog
v1: Initial attempt to add support for WeVO W2974NS v2
v2: Fix incorrect DTS
v3: Fix incorrect DTS, Remove SDHCI, Add 256M variant support (11AC NAS Router)

 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   6 ++
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/11ACNAS.dts|  12 +++
 target/linux/ramips/dts/W2914NSV2.dts  |  12 +++
 target/linux/ramips/dts/W2914NSV2.dtsi | 117 +
 target/linux/ramips/image/mt7621.mk|  16 +++
 8 files changed, 168 insertions(+)
 create mode 100644 target/linux/ramips/dts/11ACNAS.dts
 create mode 100644 target/linux/ramips/dts/W2914NSV2.dts
 create mode 100644 target/linux/ramips/dts/W2914NSV2.dtsi

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 0f1ad57..e443cc7 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -299,6 +299,9 @@ vocore)
ucidef_set_led_netdev "eth" "ETH" "$board:orange:eth" "eth0"
set_wifi_led "$board:green:status"
;;
+w2914nsv2)
+   set_usb_led "$board:green:usb"
+   ;;
 w502u)
set_usb_led "$board:blue:usb"
set_wifi_led "rt2800pci-phy0::radio"
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 e2a2f94..52289a4 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -86,6 +86,7 @@ ramips_setup_interfaces()
sap-g3200u3|\
sk-wb8|\
vr500|\
+   w2914nsv2|\
wf-2881|\
witi|\
wl-wn575a3|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 2560eb7..07d5f8d 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -13,6 +13,9 @@ ramips_board_detect() {
machine=$(awk 'BEGIN{FS="[ \t]+:[ \t]"} /machine/ {print $2}' 
/proc/cpuinfo)
 
case "$machine" in
+   *"11AC NAS Router")
+   name="w2914nsv2"
+   ;;
*"3G150B")
name="3g150b"
;;
@@ -451,6 +454,9 @@ ramips_board_detect() {
*"W150M")
name="w150m"
;;
+   *"W2914NS v2")
+   name="w2914nsv2"
+   ;;
*"W306R V2.0")
name="w306r-v20"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 7f161f5..169e0ff 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -131,6 +131,7 @@ platform_check_image() {
vocore|\
vr500|\
w150m|\
+   w2914nsv2|\
w306r-v20|\
w502u|\
wf-2881|\
diff --git a/target/linux/ramips/dts/11ACNAS.dts 
b/target/linux/ramips/dts/11ACNAS.dts
new file mode 100644
index 000..55678f5
--- /dev/null
+++ b/target/linux/ramips/dts/11ACNAS.dts
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+#include "W2914NSV2.dtsi"
+
+/ {
+   model = "WeVO 11AC NAS Router";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+};
diff --git a/target/linux/ramips/dts/W2914NSV2.dts 
b/target/linux/ramips/dts/W2914NSV2.dts
new file mode 100644
index 000..37afffd
--- /dev/null
+++ b/target/linux/ramips/dts/W2914NSV2.dts
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+#include "W2914NSV2.dtsi"
+
+/ {
+   model = "WeVO W2914NS v2";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+};
diff --git a/target/linux/ramips/dts/W2914NSV2.dtsi 
b/target/linux/ramips/dts/W2914NSV2.dtsi
new file mode 100644
index 000..c842b00
--- /dev/null
+++ b/target/linux/ramips/dts/W2914NSV2.dtsi
@@ -0,0 +1,117 @@
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   gpios = < 29 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+

Re: [LEDE-DEV] [PATCH] kernel/mtd: Add support for Macronix mx25u25635f, used in Archer C2600 v1.1

2016-11-18 Thread A. Benz 

Hi Rafal,

Sent upstream: 
http://lists.infradead.org/pipermail/linux-mtd/2016-November/070360.html


Regards,
A. Benz

On 11/07/16 21:26, Rafał Miłecki wrote:

On 31 May 2016 at 10:04, A. Benz  wrote:

On 05/31/16 04:56, Rafał Miłecki wrote:


On 30 May 2016 at 11:52, Ash Benz  wrote:


Signed-off-by: Ash Benz 
---
 .../475-mtd-spi-nor-add-macronix-mx25u25635f.patch | 10
++
 1 file changed, 10 insertions(+)
 create mode 100644
target/linux/generic/patches-3.18/475-mtd-spi-nor-add-macronix-mx25u25635f.patch

diff --git
a/target/linux/generic/patches-3.18/475-mtd-spi-nor-add-macronix-mx25u25635f.patch
b/target/linux/generic/patches-3.18/475-mtd-spi-nor-add-macronix-mx25u25635f.patch
new file mode 100644
index 000..72c0832
--- /dev/null
+++
b/target/linux/generic/patches-3.18/475-mtd-spi-nor-add-macronix-mx25u25635f.patch
@@ -0,0 +1,10 @@
+--- a/drivers/mtd/spi-nor/spi-nor.c
 b/drivers/mtd/spi-nor/spi-nor.c
+@@ -532,6 +532,7 @@ static const struct spi_device_id spi_no
+   { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
+   { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
+   { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
++  { "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512, 0) },
+   { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
+   { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024,
SPI_NOR_QUAD_READ) },
+   { "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048,
SPI_NOR_QUAD_READ) },



This patch is so trivial there is no reason not to upstream it. Please
send it to the l2-mtd ML. I should've said it earlier, but I missed
it.


Hi Rafał,

Will do. Thanks.


I can't find your patch sent upstream. Did I miss is?



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

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

2016-11-18 Thread Hauke Mehrtens 
Hi Daniel,

This sounds interesting.

I have some questions regarding phase 1.

1. Do you want to have an API to switch for example a smart plug on and
off and an other call to get the temperature from a temperature sensor?

2. Should this more focus on local IoT sensors line a temperature sensor
connected via I2C or more on remote sensors like a smart plug connected
via ZigBee?

3. What would be the difference to for example IoTvity, openHAB and
other existing solutions?


It would also be nice to have better 6LoWPAN integration in LEDE /
OpenWrt to make it easy to configure 6LoWPAN on top of ZigBee or BLE and
then route the IP traffic to the local network or the Internet like a
normal network interface in LEDE. This is probably unrelated to your
proposal.

Hauke

On 11/17/2016 12:39 PM, Daniel Golle wrote:
> Hi!
> 
> I want to suggest a project to be (partially) funded by prpl's OpenWrt
> project grant.
> 
> Abstract:
> Implement a secure autotonomous IoT hub using OpenWrt/LEDE's ubus
> service and the GNUnet P2P framework.
> 
> Introduction:
> Despite the ongoing hype about the so-called Internet of Things, the
> current practise is rather chaotic and severe structural flaws of IoT
> devices became a common occurance, including easy-to-remote-exploit
> vulnerabilities and brain-dead mistakes such as a hard-coded DNS server
> address rendering thousands of IoT connected devices unusable now that
> the server is no longer being operated.
> Given the continous history of quite predictable security and
> privacy-related catastrophies in the still quite infantile IoT-sphere,
> taking a step back, a radical shift of praradigms, away from the
> patterns of Web/Cloud-based infrastrucure will help providing a much
> more secure and reliable user experience and thereby increase trust in
> future networked applications.
> 
> Recent examples of typical problems related to the missing security
> model and centralized control servers:
> http://metropolitan.fi/entry/ddos-attack-halts-heating-in-finland-amidst-winter
> 
> Or hard-coded server addresses:
> http://www.out-law.com/en/articles/2016/october/singapore-telco-visits-customers-homes-to-secure-devices-after-cyberattack/
> 
> Or missing security by default:
> http://www.bbc.com/news/technology-37750798
> 
> From a coders point of view, the lack of a vendor-neutral abstraction
> of low-bandwidth peripherals makes it hard to develop general purpose
> applications which do not depend on a specific hardware or middleware.
> 
> This projects suggest a from bottom-to-top redesign addressing the
> diversity of components and local access methods (ranging from
> in-kernel-only drivers to almost pure userland implementations),
> connectivity (NAT traversal, discovery, ...) as well as security and
> privacy-related concerns. As a first measure, a generic integration of
> low-bandwidth peripherals such as simple sensors and actors using the
> OpenWrt/LEDE core infrastructure will provide a great improvement to
> access and manage local IoT features. This may then be used by
> various higher level applications, such as data-logging/monitoring,
> WebUI or machine-to-machine communication.
> 
> As dependence on centralized services providing remote access has
> shown to be problematic in terms of security and privacy as well as
> reliability, direct connectivity or application-agnostic indirect
> routing using well-known P2P techniques can bring about more
> interoperatibility and sustainability. GNUnet provides (among with
> many other things) a modular toolkit for P2P, ranging from a
> NAT-aware multi-transport, cryptographically addressed general purpose
> overlay network to pub/sub, filesharing and real-time conversation
> services. In a second phase of the project, this core infrastructure
> is going to be used to provide secure, reliable and privacy-aware
> remote access to IoT features on typical OpenWrt/LEDE target hardware.
> Using GNUnet implies inheriting all the advantages of a secure P2P
> infrastructure which has seen  12 years of intense research and
> several iterations of architectural revolutions within that long time.
> Having a remote-access method for ubus which already provides it's
> own set tools to work in a wide range of environments (think: behind
> NAT, using low-level transports such as UDP, TCP, HTTP and proper
> HTTPS over IPv4/v6 as well as raw bluetooth and wifi injection sockets
> for local area coverage) and got it's own built-in security mechanisms
> as well as management structures (think: a distributed personal PKI)
> also seems to be a very good match, especially due to the modular
> nature of GNUnet which allows using only the parts needed on resource
> constraint hardware. Obviously this may be also very useful for any
> kind of remote-management or other sort of remote-access to ubus
> and/or rpcd.
> 
> GNUnet is extremely portable, works on a great variety UNIX-like
> systems as well as Windows and can be compiled using LLVM, thus be

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

2016-11-18 Thread Timo Sigurdsson 
Hi again,

in the meantime, I have some more information to add to the issue mentioned in
my email quoted further down below.

Ben Greear approached me off-list and suggested to try the Candela Tech ath10k
driver and firmware and see if the issue occurs with that as well. So, for the
last 3 weeks I've been testing the CT driver and firmware and I can happily
report that the issue with the driver crashing after a while when a Nexus 5X
device is connected is not occuring with the current BETA 18
firmware-2-ct-full-community.bin. So, this really seems like a regression in
the official API level 5 ath10k firmware blobs.

The CT firmware is not perfect either, since it seems to suffer from a different
bug that has been resolved in the official firmwares, and that is that after a
reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only after a 
hard reset or "cold boot" it will come up. That's an issue I had with older
official firmwares as well, but it has been resolved with the recent API level
5 firmwares.

Nevertheless, for the time being, I will stick to the CT firmware because I can
work around the reboot issue and having the 5GHz wifi working for my Nexus 5X
clients is more important.

Over the next weeks, I will test different combinations of ath10k(-ct) driver
and firmware to see if there's a combination that resolves all issues. This
morning I flashed a LEDE build with the official ath10k driver and the CT
firmware binary.

But of course, if someone has more suggestions on what I could try or what
information I could collect to help resolve the issue related to the Nexus 5X
clients in the official firmware binaries, I think that would be beneficial
for a larger audience.

Regards,

Timo

P.S.: Please include my email address in any reply, since I'm not subscribed
to the mailing list. Thank you.


Timo Sigurdsson schrieb am 29.10.2016 22:19:

> Hi everybody,
> 
> I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE (r1952, 
> Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for the
> fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel or
> ath10k driver will crash after a while. 5Ghz wifi will be dead after that
> until I reboot the system.
> 
> This issue has been reported before [1] and it also has been declared as
> solved with newer firmwares [2] (but reopened by other users). However, even
> with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository the
> issue is far from resolved. I have tried many different firmware revisions
> over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can could
> only find that the issue sometimes takes longer to trigger with some firmwares
> (which might just be random), but it would always occur at some point with API
> level 5 firmwares. With API level 2 firmwares (which I testesd when I was
> still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X had
> other connectivity issues with these older firmwares that made this
> combination no fun to use either. But this shows that the firmware itself
> makes the difference here.
> 
> I actually have two Nexus 5X on my network (my wife's and my own). I can
> trigger the crash with either one of them. And if both Nexus 5X are connected
> to the 5Ghz radio, then the issue triggers much faster (can be as low as 15
> minutes). My workaround is to let the Nexus 5X devices only connect to the
> 2.4GHz radio. This way, the device can runs for weeks without any issue or
> crash, but of course I would prefer the actual bug being fixed rather than to
> circumvent it.
> 
> I'm appending a syslog from my access point with a crash happening while one
> Nexus 5X was connected to the 5GHz radio starting from the time the system
> booted. I randomized the MAC addresses. but left the first two characters
> unique so different clients can be distinguished.
> 
> If there is more info I could collect to help identify the cause of this
> issue, please let me know (and possibly how to do that as well).
> 
> Thank you and regards,
> 
> Timo
> 
> [1] http://lists.infradead.org/pipermail/ath10k/2015-November/006413.html
> [2] https://dev.openwrt.org/ticket/20854
> 
> And here's the log:
> Fri Oct 28 02:01:35 2016 kern.notice kernel: [0.00] Linux version
> 4.4.26 (user@buildsystem) (gcc version 5.4.0 (LEDE GCC 5.4.0 r1952) ) #0 Fri
> Oct 21 15:52:28 2016
> [...]
> Fri Oct 28 02:01:35 2016 kern.info kernel: [9.468751] Loading modules
> backported from Linux version wt-2016-10-03-1-g6fcb1a6
> Fri Oct 28 02:01:35 2016 kern.info kernel: [9.476481] Backport generated 
> by
> backports.git backports-20160324-9-g0e38f5c
> Fri Oct 28 02:01:35 2016 kern.warn kernel: [9.576570] PCI: Enabling device
> :01:00.0 ( -> 0002)
> Fri Oct 28 02:01:35 2016 kern.info kernel: [9.582475] ath10k_pci
> :01:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
> Fri Oct 28 02:01:35 2016 kern.warn kernel: [