Re: [LEDE-DEV] [PATCH odhcpd 3/5] ubus: Fix displayed valid paramater for both DHCPv4 and DHCPv6 lease

[Hans Dedecker]

On Thu, Nov 17, 2016 at 11:15 PM, Karl Palsson  wrote:
>
> Hans Dedecker  wrote:
>> Fix ubus valid parameter being displayed as a negative number;
>> also display infinite lifetime as INT32_MAX
>
> Really? Why not 0 or -1? You dont' specify an infinite lease as
> INT32_MAX, why would I want to receive an infinite lease as some
> magic number that only programmer nerds would even recognize?
Fine most important for me was that the displayed value was not
decreasing; I prefer to display -1 then as 0 indicates a lease is
expired
>
> Sincerely,
> Karl Palsson

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

Re: [LEDE-DEV] [PATCH odhcpd 1/5] config: Support infinite as DHCP pool leasetime value

[Hans Dedecker]

On Thu, Nov 17, 2016 at 11:13 PM, Karl Palsson  wrote:
>
> Hans Dedecker  wrote:
>> Add support for infinite leasetime value; this can be done by
>> specifying "infinite" as leasetime value which is similar to
>> dnsmasq infinite leasetime support. Specifying "infinite" as
>> leasetime is valid for both the host and dhcp uci sections. A
>> DHCPv4/DHCPv6 assignment is now considered infinite if
>> valid_unil holds the value 0.
>
> Can you specify "0" in uci too? that's a really common way of
> saying never, I've not ever seen a config file that needed the
> word "infinite" before
As I explained in the commit message the keyword "infinite" is used by
dnsmasq to configure infinite leasetime; the value 0 is not is not
interpreted by dnsmasq as infinite as it considers this as an invalid
leasetime as it converts all leasetime values smaller than 120 seconds
to 120 seconds; see handling of --dhcp-range in option.c. Similar to
dnsmasq the odhcpd daemon considers leasetime 0 as invalid as it
converts all leasetime smaller 60 seconds to 60 seconds
>
> Sincerely,
> Karl Palsson

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

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

[João Chaínho]

Hi Mathias,
Sorry about the malformed patch.
You’re right about the RouterStation Pro. I was wrongly changing it too. It has 
a different switch config from RB450G.
I will split them and leave the RouterStation Pro unchanged. Please let me test 
it first before resubmit the patch.
> On 17 Nov 2016, at 21:13, Mathias Kresin  wrote:
> 
> Hey João,
> 
> both patches you have send are whitespace mangled by your mail program and do 
> not apply:
> 
> $ git am LEDE-DEV-ar71xx-enable-serial-console-on-mikrotik-devices.patch
> 
> Applying: ar71xx: enable serial console on mikrotik devices
> error: patch failed: 
> target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch:1
> error: 
> target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch:
>  patch does not apply
> Patch failed at 0001 ar71xx: enable serial console on mikrotik devices
> 
> Please consider using 'git send-email' to prevent such issues. You can find 
> your broken patches in out patchwork at 
> https://patchwork.ozlabs.org/project/lede/list/?submitter=70405=* to 
> test it by yourself.
> 
> 16.11.2016 18:17, João Chaínho:
>> This patch fixes switch initial config on Mikrotik RB450/G
>> 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..daf9495 100755
>> --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
>> +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
>> @@ -343,13 +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|\
>>routerstation-pro)
>>ucidef_set_interfaces_lan_wan "eth1" "eth0"
>>ucidef_add_switch "switch0" \
>> -   "0@eth1" "2:lan:3" "3:lan:2" "4:lan:1"
>> +   "0@eth1" "1:lan:1" "2:lan:4" "3:lan:3" "4:lan:2"
> 
> You are changing the default switch config for the routerstation-pro as well. 
> Is this tested? It seams to me you're fixing one board and breaking another.
> 
> Mathias


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

Re: [LEDE-DEV] [PATCH odhcpd 3/5] ubus: Fix displayed valid paramater for both DHCPv4 and DHCPv6 lease

[Karl Palsson]

Hans Dedecker  wrote:
> Fix ubus valid parameter being displayed as a negative number;
> also display infinite lifetime as INT32_MAX

Really? Why not 0 or -1? You dont' specify an infinite lease as
INT32_MAX, why would I want to receive an infinite lease as some
magic number that only programmer nerds would even recognize?

Sincerely,
Karl Palsson

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] [PATCH odhcpd 1/5] config: Support infinite as DHCP pool leasetime value

[Karl Palsson]

Hans Dedecker  wrote:
> Add support for infinite leasetime value; this can be done by
> specifying "infinite" as leasetime value which is similar to
> dnsmasq infinite leasetime support. Specifying "infinite" as
> leasetime is valid for both the host and dhcp uci sections. A
> DHCPv4/DHCPv6 assignment is now considered infinite if
> valid_unil holds the value 0.

Can you specify "0" in uci too? that's a really common way of
saying never, I've not ever seen a config file that needed the
word "infinite" before

Sincerely,
Karl Palsson

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

[LEDE-DEV] [LEDE-DEV, v2] ar71xx: enable serial console on mikrotik devices

[João Chaínho]

Sorry about the malformed patch. Hope it applies now. 
This patch enables the serial console on some Mikrotik devices (RB450, RB450G, 
RB493G, RB750UP).
Signed-off-by: João Chaínho 
---
diff --git 
a/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
 
b/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
index 8dee006..77bf38c 100644
--- 
a/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
+++ 
b/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
@@ -1,11 +1,14 @@
 --- a/arch/mips/ath79/prom.c
 +++ b/arch/mips/ath79/prom.c
-@@ -136,6 +136,13 @@ void __init prom_init(void)
+@@ -136,6 +136,16 @@ void __init prom_init(void)
initrd_end = initrd_start + fw_getenvl("initrd_size");
}
  #endif
 +
 +  if (strstr(arcs_cmdline, "board=750Gr3") ||
++  strstr(arcs_cmdline, "board=750i") ||
++  strstr(arcs_cmdline, "board=450") ||
++  strstr(arcs_cmdline, "board=493") ||
 +  strstr(arcs_cmdline, "board=951G") ||
 +  strstr(arcs_cmdline, "board=2011L") ||
 +  strstr(arcs_cmdline, "board=711Gr100") ||

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

Re: [LEDE-DEV] Some Broadcom wifi chipset datasheets released by Cypress

[Rafał Miłecki]

On 17 November 2016 at 21:41, Alberto Bursi  wrote:
> Some broadcom wifi chipsets datasheets are being released free of NDA by
> a company called Cypress that acquired the IoT division of Broadcom.
>
> (...)
>
> datasheets here
> http://www.cypress.com/search/all?f[0]=meta_type%3Atechnical_documents[1]=resource_meta_type%3A575[2]=field_related_products%3A110101

Discussed few times, but nice to have it at ML, so we can point to archives.

I check some datasheets, they contain pinouts, electrical/timing
characteristics, but nothing important for drivers development. There
aren't datasheets to MACs/PHYs/radios, no programming guides. So what
was released so far won't help us.

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

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

[Mathias Kresin]

Hey João,

both patches you have send are whitespace mangled by your mail program 
and do not apply:


$ git am LEDE-DEV-ar71xx-enable-serial-console-on-mikrotik-devices.patch

Applying: ar71xx: enable serial console on mikrotik devices
error: patch failed: 
target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch:1
error: 
target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch: 
patch does not apply

Patch failed at 0001 ar71xx: enable serial console on mikrotik devices

Please consider using 'git send-email' to prevent such issues. You can 
find your broken patches in out patchwork at 
https://patchwork.ozlabs.org/project/lede/list/?submitter=70405=* 
to test it by yourself.


16.11.2016 18:17, João Chaínho:

This patch fixes switch initial config on Mikrotik RB450/G
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..daf9495 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -343,13 +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|\
routerstation-pro)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \
-   "0@eth1" "2:lan:3" "3:lan:2" "4:lan:1"
+   "0@eth1" "1:lan:1" "2:lan:4" "3:lan:3" "4:lan:2"


You are changing the default switch config for the routerstation-pro as 
well. Is this tested? It seams to me you're fixing one board and 
breaking another.


Mathias

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

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

[Mathias Kresin]

17.11.2016 14:50, perillamint:

Signed-off-by: Yong-hyu Ban 


Hi,

I will set this patch to "changes requested" in patchwork. As you 
already noticed by yourself, not all changes that I've requested for v1 
are addressed properly.


Please use the --annotate option of git send mail and edit the "Subject" 
header of the mails. It should point out which version of the patch you 
are sending. Means this patch should have been [PATCH v2]. The next 
version should be [PATCH v3].



---


Please include a changelog below this (---) line, so that one can easily 
see what has changed in comparison to previous versions.



 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   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/W2914NSV2.dts  | 124 +
 target/linux/ramips/image/mt7621.mk|   8 ++
 6 files changed, 140 insertions(+)
 create mode 100644 target/linux/ramips/dts/W2914NSV2.dts

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..594b945 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -451,6 +451,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/W2914NSV2.dts 
b/target/linux/ramips/dts/W2914NSV2.dts
new file mode 100644
index 000..b2dad55
--- /dev/null
+++ b/target/linux/ramips/dts/W2914NSV2.dts
@@ -0,0 +1,124 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "WeVO W2914NS v2";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   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";
+
+   usb {
+   label = "w2914nsv2:green:usb";
+   gpios = < 27 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+ 

[LEDE-DEV] Some Broadcom wifi chipset datasheets released by Cypress

[Alberto Bursi]

Some broadcom wifi chipsets datasheets are being released free of NDA by 
a company called Cypress that acquired the IoT division of Broadcom.

original article from here 
http://www.phoronix.com/scan.php?page=news_item=Cypress-Publishing-Broadcom

datasheets here 
http://www.cypress.com/search/all?f[0]=meta_type%3Atechnical_documents[1]=resource_meta_type%3A575[2]=field_related_products%3A110101

"data-sheets on the BCM88335 802.11ac, BCM89359 802.11ac, BCM43143 
802.11 b/g/n, CYW20736 Bluetooth, BCM43362, BCM4334, and much more. The 
specifications appear to be fairly thorough and for some of the chips 
include over 100 pages of information. All of this public information 
will hopefully be useful in improving some of the Broadcom wireless 
Linux drivers.

Cypress acquired Broadcom's IoT business this summer for $550 million USD."

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

Re: [LEDE-DEV] [PATCH 0/2] include: Switch git clone to git DownloadMethod

[Florian Fainelli]

On 11/09/2016 09:34 AM, Florian Fainelli wrote:
> This switches the semi manual git clone process for the kernel to use the git
> Download method which packs the sources at the end, and therefore avoids
> repeated clones on the same git tree if iterating through make
> target/linux/{clean,prepare} etc.

Any comments on this?

> 
> Florian Fainelli (2):
>   include/download.mk: Allow specify DownloadMethod specific options
>   include/kernel: Switch to git download method
> 
>  include/download.mk|  3 ++-
>  include/kernel-build.mk| 19 +++
>  include/kernel-defaults.mk | 11 +--
>  3 files changed, 22 insertions(+), 11 deletions(-)
> 


-- 
Florian

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

[LEDE-DEV] [PATCH] openvpn: update to 2.3.13

[Magnus Kroken]

Changelog: 
https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3.13

Signed-off-by: Magnus Kroken 
---
No patches need refreshing. Compile-tested on mips/ar71xx.

 package/network/services/openvpn/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/openvpn/Makefile 
b/package/network/services/openvpn/Makefile
index c88fcbd..05f56ad 100644
--- a/package/network/services/openvpn/Makefile
+++ b/package/network/services/openvpn/Makefile
@@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=openvpn
 
-PKG_VERSION:=2.3.12
+PKG_VERSION:=2.3.13
 PKG_RELEASE:=1
 
 PKG_SOURCE_URL:=http://swupdate.openvpn.net/community/releases
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
-PKG_MD5SUM:=e3d6cdf2fb58b7569bd628ddb3d76352aa7e85b9
+PKG_MD5SUM:=9cde0c8000fd32d5275adb55f8bb1d8ba429ff3de35f60a36e81f3859b7537e0
 
 
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
 
-- 
2.1.4


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

Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]

[Dave Taht]

The linked document below is the same document we attacked, I thought
successfully, last year,

http://www.computerworld.com/article/2993112/security/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html

with the ultimate response from the fcc being

https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates

Merely being asked to describe how the regdb works is all I see as the
current FCC requirement. More than one manufacturer has got through
this process since. Also, the context of that whole original debate
was a dispute with tp-link, which only came out after the legal dust
had settled.

http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/

On Wed, Nov 16, 2016 at 2:15 PM, Simon Wunderlich
 wrote:
> Hi David,
>
> On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote:
>> > Well, we are. We can't change the fact that the devices need to be locked
>> > to be sold in the US. But if you google a little, you will find a lot of
>> > patches for various Open Source projects signed by @open-mesh.com mail
>> > addresses (LEDE, Linux, hostapd, etc) ... Feel free to compare that with
>> > other WiFi vendors. I don't think we are doing that bad. :)
>>
>> except that they don't need to be locked down to be sold in the US.
>>
>> The FCC posted a proposed rule that would require such a lockdown, but then
>> have repeatedly made public statements that they do not intend to prevent
>> different firmware from being loaded on the devices and the proposed rule
>> that would have required lockdowns have basically been stopped.
>>
>> However, multiple vendors are imposing restriction and claiming that the FCC
>> is requiring them, even after the FCC says that it's not.
>
> You are right, the FCC doesn't explicitly requires to prevent third-party
> firmware loading anymore. However, they still require to explain how a vendor
> makes sure that US RF limits are not violated [1]. Since a third-party 
> firmware
> can be anything including a firmware with a patched ath9k where DFS is 
> disabled
> etc, we (as Open-Mesh) can't really prevent that those RF limits are violated.
> Thus we can not give a convincing explanation there, and the situation stays
> the same.
>
> If you have any constructive idea, I would love to propose it internally.
>
> Thanks,
>  Simon
>
> [1] From https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g
> %3D%3D=594280%20D02%20U-NII%20Device%20Security
> %20v01r03_number=39498
>
> "Describe, if the device permits third-party software or firmware 
> installation,
> what mechanisms are provided by the manufacturer to permit integration of
> such functions while ensuring that the RF parameters of the device cannot be
> operated outside its authorization for operation in the U.S .  In the
> description include what controls and/or agreements are in place with
> providers of third-party functionality to ensure  the devices’ underlying RF
> parameters are unchanged and how the manufacturer verifies the functionality. 
> "
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

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

[LEDE-DEV] [PATCH odhcpd 4/5] dhcpv6-ia: Display infinite lifetime as INT32_MAX in state file

[Hans Dedecker]

Signed-off-by: Hans Dedecker 
---
 src/dhcpv6-ia.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
index 597bc74..852af97 100644
--- a/src/dhcpv6-ia.c
+++ b/src/dhcpv6-ia.c
@@ -247,7 +247,8 @@ void dhcpv6_write_statefile(void)
iface->ifname, duidbuf, 
ntohl(c->iaid),
(c->hostname ? 
c->hostname : "-"),

(unsigned)(c->valid_until > now ?
-   
(c->valid_until - now + wall_time) : 0),
+   
(c->valid_until - now + wall_time) :
+   
(INFINITE_VALID(c->valid_until) ? INT32_MAX: 0)),
c->assigned, 
(unsigned)c->length);
 
struct in6_addr addr;
@@ -309,7 +310,8 @@ void dhcpv6_write_statefile(void)
iface->ifname, duidbuf,
(c->hostname ? 
c->hostname : "-"),

(unsigned)(c->valid_until > now ?
-   
(c->valid_until - now + wall_time) : 0),
+   
(c->valid_until - now + wall_time) :
+   
(INFINITE_VALID(c->valid_until) ? INT32_MAX: 0)),
c->addr);
 
struct in_addr addr = {htonl(c->addr)};
-- 
1.9.1


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

[LEDE-DEV] [PATCH odhcpd 5/5] dhcpv4: Adding DHCP client leasetime request support

[Hans Dedecker]

Add support for DHCPv4 clients proposing a leasetime;
proposed leasetime will be accepted if it does not
exceed either the pool or configured lease leastime.
Further rework the duplicated leasetime logic which
was in place.

Signed-off-by: Hans Dedecker 
---
 src/dhcpv4.c | 34 --
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/src/dhcpv4.c b/src/dhcpv4.c
index 618475f..5220edf 100644
--- a/src/dhcpv4.c
+++ b/src/dhcpv4.c
@@ -37,7 +37,7 @@ static void handle_dhcpv4(void *addr, void *data, size_t len,
struct interface *iface, void *dest_addr);
 static struct dhcpv4_assignment* dhcpv4_lease(struct interface *iface,
enum dhcpv4_msg msg, const uint8_t *mac, struct in_addr reqaddr,
-   const char *hostname);
+   uint32_t *leasetime, const char *hostname);
 
 // Create socket and register events
 int init_dhcpv4(void)
@@ -312,6 +312,7 @@ static void handle_dhcpv4(void *addr, void *data, size_t 
len,
uint8_t msg = DHCPV4_MSG_ACK;
 
struct in_addr reqaddr = {INADDR_ANY};
+   uint32_t leasetime = 0;
char hostname[256];
hostname[0] = 0;
 
@@ -336,7 +337,8 @@ static void handle_dhcpv4(void *addr, void *data, size_t 
len,
if (*c == elen && !memcmp([1], 
iface->filter_class, elen))
return; // Ignore from homenet
}
-   }
+   } else if (opt->type == DHCPV4_OPT_LEASETIME && opt->len == 4)
+   memcpy(, opt->data, 4);
}
 
if (reqmsg != DHCPV4_MSG_DISCOVER && reqmsg != DHCPV4_MSG_REQUEST &&
@@ -346,7 +348,7 @@ static void handle_dhcpv4(void *addr, void *data, size_t 
len,
 
struct dhcpv4_assignment *lease = NULL;
if (reqmsg != DHCPV4_MSG_INFORM)
-   lease = dhcpv4_lease(iface, reqmsg, req->chaddr, reqaddr, 
hostname);
+   lease = dhcpv4_lease(iface, reqmsg, req->chaddr, reqaddr, 
, hostname);
 
if (!lease) {
if (reqmsg == DHCPV4_MSG_REQUEST)
@@ -382,16 +384,9 @@ static void handle_dhcpv4(void *addr, void *data, size_t 
len,
dhcpv4_put(, , DHCPV4_OPT_SERVERID, 4, _addr);
 
if (lease) {
-   reply.yiaddr.s_addr = htonl(lease->addr);
-
uint32_t val;
-   uint32_t leasetime;
 
-   if (lease->leasetime >= 60) {
-   leasetime = lease->leasetime;
-   } else {
-   leasetime = iface->dhcpv4_leasetime;
-   }
+   reply.yiaddr.s_addr = htonl(lease->addr);
 
val = htonl(leasetime);
dhcpv4_put(, , DHCPV4_OPT_LEASETIME, 4, );
@@ -588,7 +583,7 @@ static bool dhcpv4_assign(struct interface *iface,
 
 static struct dhcpv4_assignment* dhcpv4_lease(struct interface *iface,
enum dhcpv4_msg msg, const uint8_t *mac, struct in_addr reqaddr,
-   const char *hostname)
+   uint32_t *leasetime, const char *hostname)
 {
struct dhcpv4_assignment *lease = NULL;
uint32_t raddr = ntohl(reqaddr.s_addr);
@@ -609,6 +604,7 @@ static struct dhcpv4_assignment* dhcpv4_lease(struct 
interface *iface,
if (msg == DHCPV4_MSG_DISCOVER || msg == DHCPV4_MSG_REQUEST) {
bool assigned = !!a;
size_t hostlen = strlen(hostname) + 1;
+   uint32_t my_leasetime;
 
if (!a && !iface->no_dynamic_dhcp) { // Create new binding
a = calloc(1, sizeof(*a) + hostlen);
@@ -637,18 +633,20 @@ static struct dhcpv4_assignment* dhcpv4_lease(struct 
interface *iface,
a->head.prev->next = >head;
}
 
-   uint32_t leasetime;
-   if (a->leasetime) {
-   leasetime = a->leasetime;
+   if (a->leasetime >= 60) {
+   my_leasetime = a->leasetime;
} else {
-   leasetime = iface->dhcpv4_leasetime;
+   my_leasetime = iface->dhcpv4_leasetime;
}
 
+   if ((*leasetime == 0) || (my_leasetime < *leasetime))
+   *leasetime = my_leasetime;
+
if (assigned) {
if (!INFINITE_VALID(a->valid_until))
// Was only a discover; mark binding for removal
-   a->valid_until = ((msg == DHCPV4_MSG_DISCOVER) 
? now : ((leasetime == UINT32_MAX) ?
-   0 : (time_t)(now + 
leasetime)));
+   a->valid_until = ((msg == DHCPV4_MSG_DISCOVER) 
? now : ((*leasetime == UINT32_MAX) ?
+   0 : (time_t)(now + 
*leasetime)));
} else if (!assigned && a) { // Cleanup failed assignment
   

[LEDE-DEV] [PATCH odhcpd 3/5] ubus: Fix displayed valid paramater for both DHCPv4 and DHCPv6 lease

[Hans Dedecker]

Fix ubus valid parameter being displayed as a negative number;
also display infinite lifetime as INT32_MAX

Signed-off-by: Hans Dedecker 
---
 src/ubus.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/ubus.c b/src/ubus.c
index 14d0a5f..425abe4 100644
--- a/src/ubus.c
+++ b/src/ubus.c
@@ -34,7 +34,7 @@ static int handle_dhcpv4_leases(struct ubus_context *ctx, 
_unused struct ubus_ob
 
struct dhcpv4_assignment *lease;
list_for_each_entry(lease, >dhcpv4_assignments, head) {
-   if (lease->valid_until < now)
+   if (!INFINITE_VALID(lease->valid_until) && 
lease->valid_until < now)
continue;
 
void *l = blobmsg_open_table(, NULL);
@@ -50,7 +50,8 @@ static int handle_dhcpv4_leases(struct ubus_context *ctx, 
_unused struct ubus_ob
inet_ntop(AF_INET, , buf, INET_ADDRSTRLEN);
blobmsg_add_string_buffer();
 
-   blobmsg_add_u32(, "valid", now - lease->valid_until);
+   blobmsg_add_u32(, "valid", 
INFINITE_VALID(lease->valid_until) ?
+   INT32_MAX : 
(uint32_t)(lease->valid_until - now));
 
blobmsg_close_table(, l);
}
@@ -83,7 +84,7 @@ static int handle_dhcpv6_leases(_unused struct ubus_context 
*ctx, _unused struct
 
struct dhcpv6_assignment *lease;
list_for_each_entry(lease, >ia_assignments, head) {
-   if (lease->valid_until < now)
+   if (!INFINITE_VALID(lease->valid_until) && 
lease->valid_until < now)
continue;
 
void *l = blobmsg_open_table(, NULL);
@@ -115,7 +116,8 @@ static int handle_dhcpv6_leases(_unused struct ubus_context 
*ctx, _unused struct
}
blobmsg_close_table(, m);
 
-   blobmsg_add_u32(, "valid", now - lease->valid_until);
+   blobmsg_add_u32(, "valid", 
INFINITE_VALID(lease->valid_until) ?
+   INT32_MAX : 
(uint32_t)(lease->valid_until - now));
 
blobmsg_close_table(, l);
}
-- 
1.9.1


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

[LEDE-DEV] [PATCH odhcpd 2/5] dhcpv4: Keep DHCPv4 assignment lifetime value in sync with assigned leasetime

[Hans Dedecker]

Keep the valid_until assignment parameter in sync with the
leasetime assigned to the DHCP client when handling DHCP
request message.
This guarantees the contents of the ubus dhcp ipv4leases valid
parameter is in sync with the client leasetime

Signed-off-by: Hans Dedecker 
---
 src/dhcpv4.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/dhcpv4.c b/src/dhcpv4.c
index 8469038..618475f 100644
--- a/src/dhcpv4.c
+++ b/src/dhcpv4.c
@@ -618,6 +618,8 @@ static struct dhcpv4_assignment* dhcpv4_lease(struct 
interface *iface,
}
memcpy(a->hwaddr, mac, sizeof(a->hwaddr));
memcpy(a->hostname, hostname, hostlen);
+   // Don't consider new assignment as infinite
+   a->valid_until = now;
 
assigned = dhcpv4_assign(iface, a, raddr);
}
@@ -642,10 +644,11 @@ static struct dhcpv4_assignment* dhcpv4_lease(struct 
interface *iface,
leasetime = iface->dhcpv4_leasetime;
}
 
-   // Was only a discover; mark binding for removal
-   if (assigned && a->valid_until < now) {
-   a->valid_until = ((msg == DHCPV4_MSG_DISCOVER) ? now : 
((leasetime == UINT32_MAX) ?
-   0 : (time_t)(now + leasetime)));
+   if (assigned) {
+   if (!INFINITE_VALID(a->valid_until))
+   // Was only a discover; mark binding for removal
+   a->valid_until = ((msg == DHCPV4_MSG_DISCOVER) 
? now : ((leasetime == UINT32_MAX) ?
+   0 : (time_t)(now + 
leasetime)));
} else if (!assigned && a) { // Cleanup failed assignment
free(a);
a = NULL;
-- 
1.9.1


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

[LEDE-DEV] [PATCH odhcpd 1/5] config: Support infinite as DHCP pool leasetime value

[Hans Dedecker]

Add support for infinite leasetime value; this can be done by
specifying "infinite" as leasetime value which is similar to
dnsmasq infinite leasetime support.
Specifying "infinite" as leasetime is valid for both the host
and dhcp uci sections.
A DHCPv4/DHCPv6 assignment is now considered infinite if valid_unil
holds the value 0.

Signed-off-by: Hans Dedecker 
---

This fixes broken IPv6 connectivity in case infinite is specified as
a leasetime value for a dhcp pool as odhcpd was considering this as
an invalid value and deleted the interface. This particular problem
can pop up if dnsmasq is used as DHCPv4 server with one of the pools
using infinite leasetime.

 src/config.c|  7 ---
 src/dhcpv4.c| 30 --
 src/dhcpv6-ia.c | 20 +++-
 src/odhcpd.h|  2 ++
 4 files changed, 33 insertions(+), 26 deletions(-)

diff --git a/src/config.c b/src/config.c
index ef51112..44b049d 100644
--- a/src/config.c
+++ b/src/config.c
@@ -218,9 +218,10 @@ static void set_config(struct uci_section *s)
 }
 
 static double parse_leasetime(struct blob_attr *c) {
-   char *val = blobmsg_get_string(c), *endptr;
-   double time = strtod(val, );
-   if (time && endptr[0]) {
+   char *val = blobmsg_get_string(c), *endptr = NULL;
+   double time = strcmp(val, "infinite") ? strtod(val, ) : 
UINT32_MAX;
+
+   if (time && endptr && endptr[0]) {
if (endptr[0] == 's')
time *= 1;
else if (endptr[0] == 'm')
diff --git a/src/dhcpv4.c b/src/dhcpv4.c
index f277a67..8469038 100644
--- a/src/dhcpv4.c
+++ b/src/dhcpv4.c
@@ -181,7 +181,8 @@ int setup_dhcpv4_interface(struct interface *iface, bool 
enable)
a->addr = ntohl(lease->ipaddr.s_addr);
memcpy(a->hwaddr, lease->mac.ether_addr_octet, 
sizeof(a->hwaddr));
memcpy(a->hostname, lease->hostname, hostlen);
-   a->valid_until = LONG_MAX;
+   /* Infinite valid */
+   a->valid_until = 0;
 
// Assign to all interfaces
struct dhcpv4_assignment *c;
@@ -246,8 +247,7 @@ static void dhcpv4_put(struct dhcpv4_message *msg, uint8_t 
**cookie,
*cookie = c + len;
 }
 
-
-// Simple DHCPv6-server for information requests
+// Handler for DHCPv4 messages
 static void handle_dhcpv4(void *addr, void *data, size_t len,
struct interface *iface, _unused void *dest_addr)
 {
@@ -396,11 +396,13 @@ static void handle_dhcpv4(void *addr, void *data, size_t 
len,
val = htonl(leasetime);
dhcpv4_put(, , DHCPV4_OPT_LEASETIME, 4, );
 
-   val = htonl(500 * leasetime / 1000);
-   dhcpv4_put(, , DHCPV4_OPT_RENEW, 4, );
+   if (leasetime != UINT32_MAX) {
+   val = htonl(500 * leasetime / 1000);
+   dhcpv4_put(, , DHCPV4_OPT_RENEW, 4, );
 
-   val = htonl(875 * leasetime / 1000);
-   dhcpv4_put(, , DHCPV4_OPT_REBIND, 4, );
+   val = htonl(875 * leasetime / 1000);
+   dhcpv4_put(, , DHCPV4_OPT_REBIND, 4, );
+   }
 
dhcpv4_put(, , DHCPV4_OPT_NETMASK, 4, 
_addr);
 
@@ -598,7 +600,7 @@ static struct dhcpv4_assignment* dhcpv4_lease(struct 
interface *iface,
a = c;
if (c->addr == raddr)
break;
-   } else if (c->valid_until < now) {
+   } else if (!INFINITE_VALID(c->valid_until) && c->valid_until < 
now) {
list_del(>head);
free(c);
}
@@ -640,10 +642,10 @@ static struct dhcpv4_assignment* dhcpv4_lease(struct 
interface *iface,
leasetime = iface->dhcpv4_leasetime;
}
 
-   // Was only a solicitation: mark binding for removal
+   // Was only a discover; mark binding for removal
if (assigned && a->valid_until < now) {
-   a->valid_until = (msg == DHCPV4_MSG_DISCOVER) ? 0 :
-   (now + leasetime);
+   a->valid_until = ((msg == DHCPV4_MSG_DISCOVER) ? now : 
((leasetime == UINT32_MAX) ?
+   0 : (time_t)(now + leasetime)));
} else if (!assigned && a) { // Cleanup failed assignment
free(a);
a = NULL;
@@ -652,9 +654,9 @@ static struct dhcpv4_assignment* dhcpv4_lease(struct 
interface *iface,
if (assigned && a)
lease = a;
} else if (msg == DHCPV4_MSG_RELEASE) {
-   if (a && a->valid_until != LONG_MAX)
-   a->valid_until = 0;
-   } else if (msg == DHCPV4_MSG_DECLINE && a && a->valid_until != 
LONG_MAX) {

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

[Daniel Golle]

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
turned into a in-browser JavaScript-monster using enscriptem, see
https://gnunet.io/ for an early example of an in-browser version of
GNUnet's anonymous filesharing service.

In the past 2 years I ported to OpenWrt/LEDE, contributed fixes as well
as features back upstream and became a member of the GNUnet e.V.
association, mainly having applications like the above in mind. In a
third phase, a set of services utilizing that infrastructure such as a
plugin for collectd (data logging), a programmable monitor/alarm
service polling properties and emmit events and action triggers listing
for events and controlling actors is going to be built.


Project schedule

(I)
As a first step towards better integration of typical IoT USE-cases
into OpenWrt/LEDE, a ubus service allowing access to low-bandwidth
peripherals shall be created. It's modular design shall allow for
plugins providing access to various different APIs and low-level
busses. Plugins may expose read and 

Re: [LEDE-DEV] [PATCH] scripts/getver.sh: use --count for git rev-list to count commits

[Rafał Miłecki]

On 17 November 2016 at 10:56, Jonas Gorski  wrote:
> On 17 November 2016 at 10:10, Rafał Miłecki  wrote:
>> On 17 November 2016 at 10:05, Rafał Miłecki  wrote:
>>> On 17 November 2016 at 09:57, Jo-Philipp Wich  wrote:
 do you happen to know whether rev-list --count is available in all Git
 versions?
>>>
>>> I found it mentioned in various posts from 2012 so it should be well 
>>> settled.
>>
>> More reliable source: it's first documented in 1.8.0:
>> https://git-scm.com/docs/git-rev-list/1.8.0
>> which was released in 2012.
>
> We currently only require 1.7[1], and some of the buildbots still use
> that. --count was actually used in the first version, and removed
> because it broke the build on some buildbots / LTS distributions [2].

OK, thanks for catching this.

I guess it's not that important for LEDE with its small commits:
> time git rev-list HEAD~3..HEAD | wc -l
3

real0m0.352s
user0m0.325s
sys 0m0.052s

-- 
Rafał

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

Re: [LEDE-DEV] FCC killing open platforms and inovations

[Simon Wunderlich]

Hi Petr,

On Thursday, November 17, 2016 11:07:17 AM CET Petr Štetiar wrote:
> Simon Wunderlich  [2016-11-17 10:49:01]:
> 
> Hi Simon,
> 
> > No, firmware (at least in ath10k) doesn't solve the problem. You can still
> > set a country code, DFS pattern matching is still done in the host-side
> > driver part (and not in the firmware), and you can still disable radar
> > detection.
> please correct me if I'm mistaken, but you should be able to get ath10k
> firmware sources under NDA, at least Candela Technologies was able[1] to
> obtain it. Then you can just prepare locked down version of the firmware for
> US market, so you're not able to change country code, fiddle with DFS
> pattern matching or disable radar detection from host-side driver.
> 
> I know, this is not robust solution either, someone can then swap the
> firmware blobs and have unlocked version again. But you can do this with
> U-Boot also, swap the locked down version with unlocked version if you
> really want to do this.
> 
> To make it robust solution, WiFi chipsets would need to support uploading of
> signed images only.

As you pointed out, the firmware blob is stored in the flash part. It is 
trivial 
to update it or replace it with the upstream (unrestricted) version. Even if 
we were to modify the firmware to do all the regulatory stuff inside (which is 
non-trivial), we can not argue that it can not be circumvented easily (by just 
using the mainstream firmware, or replace the whole firmware).

On the other hand, swapping the u-boot is not so trivial, at least without 
opening/soldering/modifying the flash from outside, which is considered a 
reasonable hurdle.

> 
> > In my personal opinion, binary blob firmware (at least as its used today)
> > just creates more problems regarding open-ness that it could possibly
> > solve.
> Well it's sad state of the things, but we're slowly getting used to have
> binary blobs in GSM modems, WiFi chipsets and in GPUs for example. But for
> me it's still far better to have one binary blob in the system(in WiFi for
> example), then completely crippled and locked down devices like we're
> seeing now with OpenMesh products.

I completely agree.

Cheers,
 Simon

signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] FCC killing open platforms and inovations

[Petr Štetiar]

Simon Wunderlich  [2016-11-17 10:49:01]:

Hi Simon,

> No, firmware (at least in ath10k) doesn't solve the problem. You can still 
> set 
> a country code, DFS pattern matching is still done in the host-side driver 
> part (and not in the firmware), and you can still disable radar detection.

please correct me if I'm mistaken, but you should be able to get ath10k
firmware sources under NDA, at least Candela Technologies was able[1] to
obtain it. Then you can just prepare locked down version of the firmware for
US market, so you're not able to change country code, fiddle with DFS pattern
matching or disable radar detection from host-side driver.

I know, this is not robust solution either, someone can then swap the firmware
blobs and have unlocked version again. But you can do this with U-Boot also,
swap the locked down version with unlocked version if you really want to do
this.

To make it robust solution, WiFi chipsets would need to support uploading of
signed images only.

> In my personal opinion, binary blob firmware (at least as its used today) 
> just 
> creates more problems regarding open-ness that it could possibly solve.

Well it's sad state of the things, but we're slowly getting used to have
binary blobs in GSM modems, WiFi chipsets and in GPUs for example. But for me
it's still far better to have one binary blob in the system(in WiFi for
example), then completely crippled and locked down devices like we're seeing
now with OpenMesh products.

1. http://www.candelatech.com/ath10k.php

-- ynezz

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

Re: [LEDE-DEV] [PATCH] scripts/getver.sh: use --count for git rev-list to count commits

[Jonas Gorski]

Hi,

On 17 November 2016 at 10:10, Rafał Miłecki  wrote:
> On 17 November 2016 at 10:05, Rafał Miłecki  wrote:
>> On 17 November 2016 at 09:57, Jo-Philipp Wich  wrote:
>>> do you happen to know whether rev-list --count is available in all Git
>>> versions?
>>
>> I found it mentioned in various posts from 2012 so it should be well settled.
>
> More reliable source: it's first documented in 1.8.0:
> https://git-scm.com/docs/git-rev-list/1.8.0
> which was released in 2012.

We currently only require 1.7[1], and some of the buildbots still use
that. --count was actually used in the first version, and removed
because it broke the build on some buildbots / LTS distributions [2].

Regards
Jonas

[1] 
https://github.com/lede-project/source/blob/master/include/prereq-build.mk#L161
[2] https://git.lede-project.org/f1765277bacbea47a45ed913ca8fa043e9f71393

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

Re: [LEDE-DEV] FCC killing open platforms and inovations

[Simon Wunderlich]

Hi Russell,

On Thursday, November 17, 2016 1:32:23 AM CET Russell Senior wrote:
> > "Simon" == Simon Wunderlich  writes:
> Simon> You are right, the FCC doesn't explicitly requires to prevent
> Simon> third-party firmware loading anymore. However, they still require
> Simon> to explain how a vendor makes sure that US RF limits are not
> Simon> violated [1]. Since a third-party firmware can be anything
> Simon> including a firmware with a patched ath9k where DFS is disabled
> Simon> etc, we (as Open-Mesh) can't really prevent that those RF limits
> Simon> are violated.  Thus we can not give a convincing explanation
> Simon> there, and the situation stays the same.
> 
> Simon> If you have any constructive idea, I would love to propose it
> Simon> internally.
> 
> Am I correct that since all 802.11ac radios (such as those supported by
> ath10k, etc) require firmware blobs, that solves the FCC problem?
> 
> It is only the 100 million existing already-sold devices that will still
> be able to interfere with the radars? ;-)

No, firmware (at least in ath10k) doesn't solve the problem. You can still set 
a country code, DFS pattern matching is still done in the host-side driver 
part (and not in the firmware), and you can still disable radar detection.

In my personal opinion, binary blob firmware (at least as its used today) just 
creates more problems regarding open-ness that it could possibly solve.

Cheers, 
  Simon

signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] FCC killing open platforms and inovations

[Russell Senior]

> "Simon" == Simon Wunderlich  writes:

Simon> You are right, the FCC doesn't explicitly requires to prevent
Simon> third-party firmware loading anymore. However, they still require
Simon> to explain how a vendor makes sure that US RF limits are not
Simon> violated [1]. Since a third-party firmware can be anything
Simon> including a firmware with a patched ath9k where DFS is disabled
Simon> etc, we (as Open-Mesh) can't really prevent that those RF limits
Simon> are violated.  Thus we can not give a convincing explanation
Simon> there, and the situation stays the same.

Simon> If you have any constructive idea, I would love to propose it
Simon> internally.

Am I correct that since all 802.11ac radios (such as those supported by
ath10k, etc) require firmware blobs, that solves the FCC problem?  

It is only the 100 million existing already-sold devices that will still
be able to interfere with the radars? ;-)


-- 
Russell Senior, President
russ...@personaltelco.net

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

Re: [LEDE-DEV] [PATCH] scripts/getver.sh: use --count for git rev-list to count commits

[Rafał Miłecki]

On 17 November 2016 at 10:05, Rafał Miłecki  wrote:
> On 17 November 2016 at 09:57, Jo-Philipp Wich  wrote:
>> do you happen to know whether rev-list --count is available in all Git
>> versions?
>
> I found it mentioned in various posts from 2012 so it should be well settled.

More reliable source: it's first documented in 1.8.0:
https://git-scm.com/docs/git-rev-list/1.8.0
which was released in 2012.

-- 
Rafał

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

Re: [LEDE-DEV] [PATCH] scripts/getver.sh: use --count for git rev-list to count commits

[Rafał Miłecki]

On 17 November 2016 at 09:57, Jo-Philipp Wich  wrote:
> do you happen to know whether rev-list --count is available in all Git
> versions?

I found it mentioned in various posts from 2012 so it should be well settled.

-- 
Rafał

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

Re: [LEDE-DEV] [PATCH] scripts/getver.sh: use --count for git rev-list to count commits

[Jo-Philipp Wich]

Hi Rafal,

do you happen to know whether rev-list --count is available in all Git
versions?

~ Jo



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] [PATCH] mt7621: add support for WeVO W2914NS v2

[Mathias Kresin]

17.11.2016 03:11, perillamint:

Hi, Mathias Kresin.

It seems its Ethernet LEDs are directly hooked into switch chip. It
flashes without defining them in DTB. I dunno about where WLAN LEDs are
hooked. I failed to drive them with sysfs gpio driver.


It might be that they are driven directly by the wireless chips. In that 
case I would expect them to just work. But in contrast to the ethernet 
leds you didn't wrote that they work...




I tried LED blinker script in

https://wiki.openwrt.org/doc/hardware/port.gpio

and it only blinked USB LED. So, I added that LED only.

Is there any way to discover how to turn on that two WiFi LEDs?


You are aware that the mtk7621 has three gpio banks (gpio0, gpio1 & 
gpio2), each having 33 gpio pins?


I'm not sure how they are shown in /sys/class/gpio/. In case they are 
shown as individual gpio controllers, the script tests only the gpio 
lines of the first gpio controller:


 cat /sys/class/gpio/gpiochip*/base | head -n1
  

Would you please test again with the following script: 
https://gist.github.com/mkresin/061ad551aa5391668ab20eb8c8abf01e


If it works for you, feel free to add/replace the script to the openwrt 
wiki article.


Mathias

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