date:20160122

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread John Clark

I figured out the sysupgrade issue with respect to the busybox -> 
uclient-fetch update and have submitted a PR to address it:


"[PATCH] base-files: fix sysupgrade 'wget' handling for uclient-fetch"

--John

On 1/22/16 10:18 AM, Felix Fietkau wrote:

On 2016-01-22 14:21, John Clark wrote:

yes, is was dropped with r48386 + 48379
so it *should* be automatically work with wget -> uclient-fetch

I have updated to the latest trunk commit where I see your /usr/bin/wget
-> /bin/wget patch.  I have updated the feeds and symlinks to the latest
and greatest.  The packages are currently not configured to build
uclient-fetch by default, so I manually selected it.

My resulting build now has a 112,453 byte /bin/uclient-fetch binary and
I can confirm wget does work.  I guess the only thing left to do is to
have the uclient-fetch binary build by default.

Did you use any weird build options? Here's the size from my own build
(ar71xx):
nbd@nf > ls -la bin/uclient-fetch usr/lib/libuclient.so
-rwxr-xr-x  1 nbd  staff  12344 Jan 21 15:39 bin/uclient-fetch
-rw-r--r--  1 nbd  staff  16684 Jan 21 15:39 usr/lib/libuclient.so


Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
with the removal of wget from it.  Therefore, the uclient-fetch binary
swapout causes a 46,379 byte increase in size. I assume the desire to
move to uclient-fetch from busybox is for the SSL support?  If so, it
still does not support SSL without also building ustream-ssl.

ustream-ssl already ships with standard LuCI enabled builds.
Also, you can choose which TLS provider you want to use.
The way it's implemented right now, enabling SSL also does not require
recompiling uclient-fetch - it detects at run time whether SSL support
is availble.

- Felix

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

[OpenWrt-Devel] [PATCH] base-files: fix sysupgrade 'wget' handling for uclient-fetch

2016-01-22 Thread John Clark

change 48451 tried to add support for uclient-fetch by moving
/usr/bin/wget to /bin/wget, but this change kept the symbolic
link to /bin/busybox as install_bin creates links to param 1

the desired fix is to link to uclient-fetch to wget:
  install_bin /bin/uclient-fetch /bin/wget

Signed-off-by: John Clark 
---
 package/base-files/files/lib/upgrade/common.sh | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index adf290c..f894f31 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -48,13 +48,14 @@ supivot() { #  
 
 run_ramfs() { #  [...]
install_bin /bin/busybox /bin/ash /bin/sh /bin/mount /bin/umount
\
-   /sbin/pivot_root /bin/wget /sbin/reboot /bin/sync /bin/dd   
\
-   /bin/grep /bin/cp /bin/mv /bin/tar /usr/bin/md5sum "/usr/bin/[" 
\
-   /bin/dd /bin/vi /bin/ls /bin/cat /usr/bin/awk /usr/bin/hexdump  
\
+   /sbin/pivot_root /sbin/reboot /bin/sync /bin/dd /bin/grep   
\
+   /bin/cp /bin/mv /bin/tar /usr/bin/md5sum "/usr/bin/[" /bin/dd   
\
+   /bin/vi /bin/ls /bin/cat /usr/bin/awk /usr/bin/hexdump  
\
/bin/sleep /bin/zcat /usr/bin/bzcat /usr/bin/printf /usr/bin/wc 
\
/bin/cut /usr/bin/printf /bin/sync /bin/mkdir /bin/rmdir
\
/bin/rm /usr/bin/basename /bin/kill /bin/chmod
 
+   install_bin /bin/uclient-fetch /bin/wget
install_bin /sbin/mtd
install_bin /sbin/mount_root
install_bin /sbin/snapshot
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Felix Fietkau

On 2016-01-23 00:45, Arjen de Korte wrote:
> Citeren Felix Fietkau :
> 
>> On 2016-01-22 22:29, edgar.sol...@web.de wrote:
>>> On 22.01.2016 16:20, Felix Fietkau wrote:
 On 2016-01-22 16:03, edgar.sol...@web.de wrote:
> On 22.01.2016 14:32, Weedy wrote:
>>> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
>> with the removal of wget from it.  Therefore, the uclient-fetch binary
>> swapout causes a 46,379 byte increase in size. I assume the  
>> desire to move
>> to uclient-fetch from busybox is for the SSL support?  If so, it  
>> still does
>> not support SSL without also building ustream-ssl.
>
> yeah. an ssl capable wget (whatever it's called) out of the box  
> would be greatly appreciated.
>
> @Felix: is that on the table?
 It's already done. With uclient-fetch, you can simply install any
 ustream-ssl variant (along with ca-certificates if you want to have
 proper validation), and it'll immediately be SSL capable. That was my
 main motivation behind replacing wget with ustream-ssl.

 The aforementioned size increase is probably either a bug or a
 measurement error (see my other mail regarding that subject).

>>>
>>> nice! is there a possibility to create a wget wrapper? i assume not
>>> everyone is familiar with uclient-fetch, so at least a stub noting to
>>> use uclient-fetch might probably help when users are confused that wget
>>> isn't there.
>> You keep asking for things that are already there :)
>>
>> The uclient-fetch package provides a symlink to wget and it is fully
>> command line compatible as well. Users don't have to change their habits
>> and scripts that don't hardcode the path will continue to work as well.
> 
> Not entirely. It (r48456) segfaults on receiving a 301 redirect for  
> http->https:
> 
> # /bin/uclient-fetch -O- 'http://de-korte.org/robots.txt'
> Downloading 'http://de-korte.org/robots.txt'
> Connecting to 2001:470:7ad2::10:80
> Segmentation fault
That's an error handling bug - the hostname of the URL it redirects to
is invalid. I've pushed a fix to uclient.git

> It also behaves differently with the http://dyn.dns.he.net servers  
> (returning a Connection failure, despite also returning a result). See  
> below:
> 
> # /bin/uclient-fetch -O-  
> 'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'
> Downloading  
> 'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'
> Connecting to 2001:470:0:193::3000:443
> Writing to stdout
> nochg 1.2.3.4Connection error: Connection failed
> 
> I'm not too concerned about the first, but the latter is a bit  
> inconvenient. I suspect the HE servers close the connection  
> immediately after sending the result and that this is not expected.  
I'll make an account and look into that soon.

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

Re: [OpenWrt-Devel] [PATCH 4/4] ramips: HLK-RM04 - Enable GPIO14 for WPS button

2016-01-22 Thread John Clark

The top half of UARTF on the HLK-RM04 is used for GPIO.

  mode 1   mode 2
   RIN GPIO14
   DSR_N   GPIO13
   DCD_N   GPIO12
   DTR_N   GPIO11
   RXD GPIO10
   CTS_N   GPIO09
   TXD GPIO08
   RTS_N   GPIO07

This patch applies 3'b101 mode to UARTF:

   GPIO14
   GPIO13
   GPIO12
   GPIO11
   RXD
   CTS_N
   TXD
   RTS_N

Because the base rt5350.dtsi file forces 3'b000 mode, remove the pin setting 
from this file and apply it directly to the files that inherit from it 
(WIZFI630A.dts and WT1520.dtsi).  This change makes the rt5350.dtsi file 
consistent with the mt7620a.dtsi file.

Signed-off-by: John Clark 
---
  sending again to fix typo in the original patch request comment

 target/linux/ramips/dts/HLKRM04.dts   | 5 +
 target/linux/ramips/dts/WIZFI630A.dts | 2 ++
 target/linux/ramips/dts/WT1520.dtsi   | 2 ++
 target/linux/ramips/dts/rt5350.dtsi   | 3 ---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/target/linux/ramips/dts/HLKRM04.dts 
b/target/linux/ramips/dts/HLKRM04.dts
index 713b51f..3c9a93c 100644
--- a/target/linux/ramips/dts/HLKRM04.dts
+++ b/target/linux/ramips/dts/HLKRM04.dts
@@ -63,6 +63,11 @@
ralink,group = "i2c", "jtag";
ralink,function = "gpio";
};
+
+   uartf_gpio {
+   ralink,group = "uartf";
+   ralink,function = "gpio uartf";
+   };
};
};
 
diff --git a/target/linux/ramips/dts/WIZFI630A.dts 
b/target/linux/ramips/dts/WIZFI630A.dts
index 39d68c3..e2a51ec 100644
--- a/target/linux/ramips/dts/WIZFI630A.dts
+++ b/target/linux/ramips/dts/WIZFI630A.dts
@@ -59,6 +59,8 @@
interrupt-parent = <&intc>;
interrupts = <5>;
reg-shift = <2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&uartf_pins>;
status = "okay";
};
 
diff --git a/target/linux/ramips/dts/WT1520.dtsi 
b/target/linux/ramips/dts/WT1520.dtsi
index b8c4e0a..13ff268 100644
--- a/target/linux/ramips/dts/WT1520.dtsi
+++ b/target/linux/ramips/dts/WT1520.dtsi
@@ -15,6 +15,8 @@
 
palmbus@1000 {
uart@500 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uartf_pins>;
status = "okay";
};
};
diff --git a/target/linux/ramips/dts/rt5350.dtsi 
b/target/linux/ramips/dts/rt5350.dtsi
index 27f7bf6..b8712e9 100644
--- a/target/linux/ramips/dts/rt5350.dtsi
+++ b/target/linux/ramips/dts/rt5350.dtsi
@@ -94,9 +94,6 @@
 
reg-shift = <2>;
 
-   pinctrl-names = "default";
-   pinctrl-0 = <&uartf_pins>;
-
status = "disabled";
};
 
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] sysupgrade problems with uclient-fetch based wget

2016-01-22 Thread John Clark

I have the latest trunk running on a ramips architecture and I have 
compiled in Bastian Bittorf's r48451 path fix for the new wget:

https://dev.openwrt.org/changeset/48451

However, I am still having problems getting sysupgrade to work.  Is 
sysupgrade working for anyone else running the >= r48451?


I have removed the stderr redirect to see the error -- it is reporting 
"wget: applet not found"


Sending TERM to remaining processes ... ubusd logd netifd ntpd dnsmasq
Sending KILL to remaining processes ... ntpd
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...

Writing from  to firmware ...  [ ]wget: applet not found

Upgrade completed
Rebooting system...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/6] [kernel] ath9k: enable GPIO access for ar9287 and ar9285

2016-01-22 Thread Hartmut Knaack

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michal Cieslakiewicz schrieb am 21.01.2016 um 00:11:
> From: Michal Cieslakiewicz 
> 
> Patch enables GPIO access for wireless chips ar9287 and ar9285.
> Key poller driver is activated when platform buttons are 
> defined. It also makes LEDs connected honour initial
> default_state and allows platform-supplied WLAN LED name.
> 
> Signed-off-by: Michal Cieslakiewicz 
> 

Looking pretty good over all. One problem throughout the whole set
however is, that you should diff from within your openwrt directory.
But the better way would be to use git format-patch.
Also, it might be a good idea to even split up this patch into the
topics that it covers: WLAN LED name and default state, registering
the gpio_chip and GPIO buttons. So that one patch addresses one issue.
Additional thoughts are inline.

> ---
> 
> This patch exports GPIOs connected to wireless chip. In some routers
> (for example Netgear WNR2000v3 which was used by me for development)
> certain buttons and LEDs are not connected to main SoC but to
> wifi chip instead.
> 
> Patch does the following:
> 
> * when CPTCFG_MAC80211_LEDS option is set and there are LEDs and/or 
>   buttons provided by device platform, ath9k module registers GPIO
>   chip, reserves GPIO pins and starts polling on keys using
>   'gpio-keys-polled' driver
> 
> * LED default_state is now honoured
> 
> * platform-supplied name for WLAN LED is supported (instead of
>   'ath9k-phy*' default)
> 
> GPIO chip base is auto-registered (as advised by kernel developers),
> so on my router pin numbers do not directly follow SoC GPIOs (0-19)
> but occupy numbers 53-63.
> 
> Due to nature of key polling, once started, module ath9k is locked
> and cannot be unloaded.
> 
> 
>  package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch |  368 
> 
>  target/linux/generic/files/include/linux/ath9k_platform.h   |5 
>  2 files changed, 373 insertions(+)
> 
> 
> diff -pruN 
> a/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch 
> b/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch
> --- a/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch 
> 1970-01-01 01:00:00.0 +0100
> +++ b/openwrt/package/kernel/mac80211/patches/546-ath9k-gpio-enable.patch 
> 2016-01-20 19:56:46.681693574 +0100
> @@ -0,0 +1,368 @@
> +diff -pruN a/drivers/net/wireless/ath/ath9k/ath9k.h 
> b/drivers/net/wireless/ath/ath9k/ath9k.h
> +--- a/drivers/net/wireless/ath/ath9k/ath9k.h 2016-01-20 19:52:13.849779144 
> +0100
>  b/drivers/net/wireless/ath/ath9k/ath9k.h 2016-01-20 19:52:13.752784871 
> +0100
> +@@ -24,6 +24,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + 
> + #include "common.h"
> + #include "debug.h"
> +@@ -817,6 +818,15 @@ void ath_fill_led_pin(struct ath_softc *
> + int ath_create_gpio_led(struct ath_softc *sc, int gpio, const char *name,
> + const char *trigger, bool active_low);
> + 
> ++//
> ++/*GPIO & Buttons*/
> ++//
> ++
> ++void ath9k_register_gpio_chip(struct ath_softc *sc);
> ++void ath9k_unregister_gpio_chip(struct ath_softc *sc);
> ++void ath9k_init_buttons(struct ath_softc *sc);
> ++void ath9k_deinit_buttons(struct ath_softc *sc);
> ++
> + #else
> + static inline void ath_init_leds(struct ath_softc *sc)
> + {
> +@@ -828,6 +838,20 @@ static inline void ath_deinit_leds(struc
> + static inline void ath_fill_led_pin(struct ath_softc *sc)
> + {
> + }
> ++
> ++static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
> ++{
> ++}
> ++static inline void ath9k_unregister_gpio_chip(struct ath_softc *sc)
> ++{
> ++}
> ++
> ++void ath9k_init_buttons(struct ath_softc *sc)
> ++{
> ++}
> ++void ath9k_deinit_buttons(struct ath_softc *sc)
> ++{
> ++}
> + #endif
> + 
> + //
> +@@ -963,6 +987,12 @@ struct ath_led {
> + struct led_classdev cdev;
> + };
> + 
> ++struct ath9k_gpio_chip {
> ++struct ath_softc *sc;
> ++char label[32];
> ++struct gpio_chip gchip;
> ++};
> ++
> + struct ath_softc {
> + struct ieee80211_hw *hw;
> + struct device *dev;
> +@@ -1017,6 +1047,10 @@ struct ath_softc {
> + #ifdef CPTCFG_MAC80211_LEDS
> + const char *led_default_trigger;
> + struct list_head leds;
> ++
> ++struct ath9k_gpio_chip *gpiochip;
> ++
> ++struct platform_device *btnpdev;/* gpio-keys-polled */
> + #endif
> + 
> + #ifdef CPTCFG_ATH9K_DEBUGFS
> +diff -pruN a/drivers/net/wireless/ath/ath9k/gpio.c 
> b/drivers/net/wireless/ath/ath9k/gpio.c
> +--- a/drivers/net/wireless/ath/ath9k/gpio.c  2016-01-20 19:52:13.859778553 
> +0100
>  b/drivers/net/wireless/ath/ath9k/gpio.c  2016-01-20 19:52:13.761784340 
> +0100
> +@@ -22,6 +22,11 @@
> + //
> + 
> + #ifdef CPTCFG_MAC80211_LEDS
> ++
> ++#include 
> ++#include 
> ++#include 
> ++
> + static void ath_led_brightness(struct led_classdev *led_cdev,
> +

Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Arjen de Korte


Citeren Felix Fietkau :


On 2016-01-22 22:29, edgar.sol...@web.de wrote:

On 22.01.2016 16:20, Felix Fietkau wrote:

On 2016-01-22 16:03, edgar.sol...@web.de wrote:

On 22.01.2016 14:32, Weedy wrote:

Question: The busybox binary (for me) goes from 366,401 bytes to 300,327

with the removal of wget from it.  Therefore, the uclient-fetch binary
swapout causes a 46,379 byte increase in size. I assume the  
desire to move
to uclient-fetch from busybox is for the SSL support?  If so, it  
still does

not support SSL without also building ustream-ssl.


yeah. an ssl capable wget (whatever it's called) out of the box  
would be greatly appreciated.


@Felix: is that on the table?

It's already done. With uclient-fetch, you can simply install any
ustream-ssl variant (along with ca-certificates if you want to have
proper validation), and it'll immediately be SSL capable. That was my
main motivation behind replacing wget with ustream-ssl.

The aforementioned size increase is probably either a bug or a
measurement error (see my other mail regarding that subject).



nice! is there a possibility to create a wget wrapper? i assume not
everyone is familiar with uclient-fetch, so at least a stub noting to
use uclient-fetch might probably help when users are confused that wget
isn't there.

You keep asking for things that are already there :)

The uclient-fetch package provides a symlink to wget and it is fully
command line compatible as well. Users don't have to change their habits
and scripts that don't hardcode the path will continue to work as well.


Not entirely. It (r48456) segfaults on receiving a 301 redirect for  
http->https:


# /bin/uclient-fetch -O- 'http://de-korte.org/robots.txt'
Downloading 'http://de-korte.org/robots.txt'
Connecting to 2001:470:7ad2::10:80
Segmentation fault

It also behaves differently with the http://dyn.dns.he.net servers  
(returning a Connection failure, despite also returning a result). See  
below:


# /bin/uclient-fetch -O-  
'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'
Downloading  
'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=1.2.3.4'

Connecting to 2001:470:0:193::3000:443
Writing to stdout
nochg 1.2.3.4Connection error: Connection failed

I'm not too concerned about the first, but the latter is a bit  
inconvenient. I suspect the HE servers close the connection  
immediately after sending the result and that this is not expected.  
For example, the following works as expected:


# /bin/uclient-fetch -O- 'https://de-korte.org/robots.txt'
Downloading 'https://de-korte.org/robots.txt'
Connecting to 2001:470:7ad2::10:443
Writing to stdout
User-agent: *
Disallow: /

(null)   100% |***|27
0:00:00 ETA

Download completed (27 bytes)

Regards, Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Felix Fietkau

On 2016-01-22 22:29, edgar.sol...@web.de wrote:
> On 22.01.2016 16:20, Felix Fietkau wrote:
>> On 2016-01-22 16:03, edgar.sol...@web.de wrote:
>>> On 22.01.2016 14:32, Weedy wrote:
> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
 with the removal of wget from it.  Therefore, the uclient-fetch binary
 swapout causes a 46,379 byte increase in size. I assume the desire to move
 to uclient-fetch from busybox is for the SSL support?  If so, it still does
 not support SSL without also building ustream-ssl.
>>>
>>> yeah. an ssl capable wget (whatever it's called) out of the box would be 
>>> greatly appreciated.
>>>
>>> @Felix: is that on the table?
>> It's already done. With uclient-fetch, you can simply install any
>> ustream-ssl variant (along with ca-certificates if you want to have
>> proper validation), and it'll immediately be SSL capable. That was my
>> main motivation behind replacing wget with ustream-ssl.
>> 
>> The aforementioned size increase is probably either a bug or a
>> measurement error (see my other mail regarding that subject).
>> 
> 
> nice! is there a possibility to create a wget wrapper? i assume not
> everyone is familiar with uclient-fetch, so at least a stub noting to
> use uclient-fetch might probably help when users are confused that wget
> isn't there.
You keep asking for things that are already there :)

The uclient-fetch package provides a symlink to wget and it is fully
command line compatible as well. Users don't have to change their habits
and scripts that don't hardcode the path will continue to work as well.

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

Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread edgar . soldin

thx John! neat.. that should do the trick. finally a small ssl capable wget, 
jippee! ..ede

On 22.01.2016 22:32, John Clark wrote:
> There is a symbolic link:
> 
> lrwxrwxrwx1 root root13 Jan 22 20:04 wget -> 
> uclient-fetch*
> 
> 
> On 1/22/16 4:29 PM, edgar.sol...@web.de wrote:
>> On 22.01.2016 16:20, Felix Fietkau wrote:
>>> On 2016-01-22 16:03, edgar.sol...@web.de wrote:
 On 22.01.2016 14:32, Weedy wrote:
>> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
> with the removal of wget from it.  Therefore, the uclient-fetch binary
> swapout causes a 46,379 byte increase in size. I assume the desire to move
> to uclient-fetch from busybox is for the SSL support?  If so, it still 
> does
> not support SSL without also building ustream-ssl.
 yeah. an ssl capable wget (whatever it's called) out of the box would be 
 greatly appreciated.

 @Felix: is that on the table?
>>> It's already done. With uclient-fetch, you can simply install any
>>> ustream-ssl variant (along with ca-certificates if you want to have
>>> proper validation), and it'll immediately be SSL capable. That was my
>>> main motivation behind replacing wget with ustream-ssl.
>>>
>>> The aforementioned size increase is probably either a bug or a
>>> measurement error (see my other mail regarding that subject).
>>>
>> nice! is there a possibility to create a wget wrapper? i assume not everyone 
>> is familiar with uclient-fetch, so at least a stub noting to use 
>> uclient-fetch might probably help when users are confused that wget isn't 
>> there.
>>
>> ..ede
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread edgar . soldin

On 22.01.2016 16:20, Felix Fietkau wrote:
> On 2016-01-22 16:03, edgar.sol...@web.de wrote:
>> On 22.01.2016 14:32, Weedy wrote:
 Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
>>> with the removal of wget from it.  Therefore, the uclient-fetch binary
>>> swapout causes a 46,379 byte increase in size. I assume the desire to move
>>> to uclient-fetch from busybox is for the SSL support?  If so, it still does
>>> not support SSL without also building ustream-ssl.
>>
>> yeah. an ssl capable wget (whatever it's called) out of the box would be 
>> greatly appreciated.
>>
>> @Felix: is that on the table?
> It's already done. With uclient-fetch, you can simply install any
> ustream-ssl variant (along with ca-certificates if you want to have
> proper validation), and it'll immediately be SSL capable. That was my
> main motivation behind replacing wget with ustream-ssl.
> 
> The aforementioned size increase is probably either a bug or a
> measurement error (see my other mail regarding that subject).
> 

nice! is there a possibility to create a wget wrapper? i assume not everyone is 
familiar with uclient-fetch, so at least a stub noting to use uclient-fetch 
might probably help when users are confused that wget isn't there.

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

Re: [OpenWrt-Devel] [PATCH 4/4] ramips: HLK-RM04 - Enable GPIO14 for WPS button

2016-01-22 Thread John Clark

>>Also note that target/linux/ramips/dts/WT1520.dtsi is for the "Nexx 
WT1520" and should be named "WT1520.dts" instead. I will send that 
change through as a different patch.


I went to fix WT1520.dtsi and see there are 9 boards not using the .dts 
naming convention.  Felix / JohnCr, should I rename them or leave them 
alone?


ec2-user@ip-192-168-74-100 ~/owrt-trunk/target/linux/ramips/dts $ ll *.dtsi
-rw-rw-r-- 1 ec2-user ec2-user  244 Jan 18 08:26 AWM002-4M.dtsi
-rw-rw-r-- 1 ec2-user ec2-user  244 Jan 18 08:26 AWM002-8M.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 1159 Jan 18 08:26 AWM002.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 2186 Jan 18 08:26 HC5XXX.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 9342 Jan 18 08:26 mt7620a.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 5997 Jan 18 08:26 mt7620n.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 6371 Jan 18 08:26 mt7621.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 7542 Jan 18 08:26 mt7628an.dtsi
-rw-rw-r-- 1 ec2-user ec2-user  829 Jan 18 08:26 PX-4885.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 3240 Jan 18 08:26 rt2880.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 4733 Jan 18 08:26 rt3050.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 5269 Jan 18 08:26 rt3352.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 7375 Jan 18 08:26 rt3883.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 5868 Jan 22 19:37 rt5350.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 3364 Jan 18 08:26 VOCORE.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 1385 Jan 18 08:26 WRTNODE2.dtsi
-rw-rw-r-- 1 ec2-user ec2-user  671 Jan 22 19:40 WT1520.dtsi
-rw-rw-r-- 1 ec2-user ec2-user 1644 Jan 18 08:26 Y1.dtsi


--John


On 1/22/16 3:40 PM, John Clark wrote:

The top half of UARTF on the HLK-RM04 is used for GPIO.

   mode 1   mode 2
RIN GPIO14
DSR_N   GPIO13
DCD_N   GPIO12
DTR_N   GPIO11
RXD GPIO10
CTS_N   GPIO09
TXD GPIO08
RTS_N   GPIO07

This patch applys 3'b101 mode to UARTF:

GPIO14
GPIO13
GPIO12
GPIO11
RXD
CTS_N
TXD
RTS_N

Because the base rt5350.dtsi file forces 3'b000 mode, remove the pin setting 
from this file and apply it directly to the files that inherit from it 
(WIZFI630A.dts and WT1520.dtsi).  This change makes the rt5350.dtsi file 
consistent with the mt7620a.dtsi file.

Signed-off-by: John Clark 
---
  Also note that target/linux/ramips/dts/WT1520.dtsi is for the "Nexx WT1520" and should 
be named "WT1520.dts" instead.  I will send that change through as a different patch.

  target/linux/ramips/dts/HLKRM04.dts   | 5 +
  target/linux/ramips/dts/WIZFI630A.dts | 2 ++
  target/linux/ramips/dts/WT1520.dtsi   | 2 ++
  target/linux/ramips/dts/rt5350.dtsi   | 3 ---
  4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/target/linux/ramips/dts/HLKRM04.dts 
b/target/linux/ramips/dts/HLKRM04.dts
index 713b51f..3c9a93c 100644
--- a/target/linux/ramips/dts/HLKRM04.dts
+++ b/target/linux/ramips/dts/HLKRM04.dts
@@ -63,6 +63,11 @@
ralink,group = "i2c", "jtag";
ralink,function = "gpio";
};
+
+   uartf_gpio {
+   ralink,group = "uartf";
+   ralink,function = "gpio uartf";
+   };
};
};
  
diff --git a/target/linux/ramips/dts/WIZFI630A.dts b/target/linux/ramips/dts/WIZFI630A.dts

index 39d68c3..e2a51ec 100644
--- a/target/linux/ramips/dts/WIZFI630A.dts
+++ b/target/linux/ramips/dts/WIZFI630A.dts
@@ -59,6 +59,8 @@
interrupt-parent = <&intc>;
interrupts = <5>;
reg-shift = <2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&uartf_pins>;
status = "okay";
};
  
diff --git a/target/linux/ramips/dts/WT1520.dtsi b/target/linux/ramips/dts/WT1520.dtsi

index b8c4e0a..13ff268 100644
--- a/target/linux/ramips/dts/WT1520.dtsi
+++ b/target/linux/ramips/dts/WT1520.dtsi
@@ -15,6 +15,8 @@
  
  	palmbus@1000 {

uart@500 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uartf_pins>;
status = "okay";
};
};
diff --git a/target/linux/ramips/dts/rt5350.dtsi 
b/target/linux/ramips/dts/rt5350.dtsi
index 27f7bf6..b8712e9 100644
--- a/target/linux/ramips/dts/rt5350.dtsi
+++ b/target/linux/ramips/dts/rt5350.dtsi
@@ -94,9 +94,6 @@
  
  			reg-shift = <2>;
  
-			pinctrl-names = "default";

-   pinctrl-0 = <&uartf_pins>;
-
status = "disabled";
};
  

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

Re: [OpenWrt-Devel] [PATCH 0/2 v2] linux: add support of ARC HS38-based boards

2016-01-22 Thread Alexey Brodkin

Hi Felix,

On Mon, 2016-01-18 at 20:51 +0300, Alexey Brodkin wrote:
> This patch introduces support of new boards with ARC HS38 cores.
> 
> ARC HS38 is a new generation of ARC cores which utilize ARCv2 ISA.
> Because of new ISA ARC HS38 are binary incompatible with ARC 700
> cores which requires both separate toolchain and target applications
> including Linux kernel for that new cores.
> 
> As with ARC770 we're addind support for 2 boards for now:
> 
>  [1] Synopsys SDP board (AXS103)
>  This is the same base-board as in AXS101 but with
>  FPGA-based CPU-tile where ARCHs38 core is implemented.
> 
>  [2] nSIM
>  Again this is the same simulation engine but configured for
>  new instruction set and features of new CPU.

Any chance that tiny series gets reviewed sometime soon?

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

[OpenWrt-Devel] [PATCH] lantiq: Move the definition of the xrx200-net node to vr9.dtsi

2016-01-22 Thread Martin Blumenstingl

This removes a lot of duplicate register and interrupt definitions by
moving the xrx200-net definition to vr9.dtsi and making all devices re-
use it.

Signed-off-by: Martin Blumenstingl 
---
 target/linux/lantiq/dts/ARV7519RW22.dts  | 147 -
 target/linux/lantiq/dts/BTHOMEHUBV5A.dts | 170 ++---
 target/linux/lantiq/dts/EASY80920.dtsi   | 179 +++
 target/linux/lantiq/dts/FRITZ3370.dts| 131 +++---
 target/linux/lantiq/dts/P2812HNUFX.dtsi  | 148 -
 target/linux/lantiq/dts/TDW89X0.dtsi | 129 ++
 target/linux/lantiq/dts/VG3503J.dtsi |  85 +++
 target/linux/lantiq/dts/VGV7510KW22.dtsi | 129 ++
 target/linux/lantiq/dts/VGV7519.dtsi | 173 ++---
 target/linux/lantiq/dts/VR200v.dts   | 129 ++
 target/linux/lantiq/dts/vr9.dtsi |  13 +++
 11 files changed, 669 insertions(+), 764 deletions(-)

diff --git a/target/linux/lantiq/dts/ARV7519RW22.dts 
b/target/linux/lantiq/dts/ARV7519RW22.dts
index dfc7e8f..6f5d356 100644
--- a/target/linux/lantiq/dts/ARV7519RW22.dts
+++ b/target/linux/lantiq/dts/ARV7519RW22.dts
@@ -72,85 +72,6 @@
};
};
 
-   eth@E108000 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "lantiq,xrx200-net";
-   reg = < 0xE108000 0x3000 /* switch */
-   0xE10B100 0x70 /* mdio */
-   0xE10B1D8 0x30 /* mii */
-   0xE10B308 0x30 /* pmac */
-   >;
-   interrupt-parent = <&icu0>;
-   interrupts = <73 72>;
-
-   lan: interface@0 {
-   compatible = "lantiq,xrx200-pdi";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0>;
-   mtd-mac-address = <&boardconfig 0x16>;
-   lantiq,switch;
-
-   ethernet@0 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <0>;
-   phy-mode = "rgmii";
-   phy-handle = <&phy0>;
-   };
-   ethernet@1 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <4>;
-   phy-mode = "mii";
-   phy-handle = <&phy13>;
-   };
-   ethernet@2 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <5>;
-   phy-mode = "mii";
-   phy-handle = <&phy14>;
-   };
-   ethernet@3 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <2>;
-   phy-mode = "mii";
-   phy-handle = <&phy11>;
-   };
-   ethernet@4 {
-   compatible = "lantiq,xrx200-pdi-port";
-   reg = <3>;
-   phy-mode = "mii";
-   phy-handle = <&phy12>;
-   };
-   };
-
-   mdio@0 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "lantiq,xrx200-mdio";
-   phy0: ethernet-phy@0 {
-   reg = <0x0>;
-   compatible = "lantiq,phy11g", 
"ethernet-phy-ieee802.3-c22";
-   };
-   phy11: ethernet-phy@11 {
-   reg = <0x11>;
-   compatible = "lantiq,phy22f", 
"ethernet-phy-ieee802.3-c22";
-   };
-   phy12: ethernet-phy@12 {
-   reg = <0x12>;
-   compatible = "lantiq,phy22f", 
"ethernet-phy-ieee802.3-c22";
-   };
-   phy13: ethernet-phy@13 {
-   reg = <0x13>;
-

[OpenWrt-Devel] [PATCH 4/4] ramips: HLK-RM04 - Enable GPIO14 for WPS button

2016-01-22 Thread John Clark

The top half of UARTF on the HLK-RM04 is used for GPIO.

  mode 1   mode 2
   RIN GPIO14
   DSR_N   GPIO13
   DCD_N   GPIO12
   DTR_N   GPIO11
   RXD GPIO10
   CTS_N   GPIO09
   TXD GPIO08
   RTS_N   GPIO07

This patch applys 3'b101 mode to UARTF:

   GPIO14
   GPIO13
   GPIO12
   GPIO11
   RXD
   CTS_N
   TXD
   RTS_N

Because the base rt5350.dtsi file forces 3'b000 mode, remove the pin setting 
from this file and apply it directly to the files that inherit from it 
(WIZFI630A.dts and WT1520.dtsi).  This change makes the rt5350.dtsi file 
consistent with the mt7620a.dtsi file.

Signed-off-by: John Clark 
---
 Also note that target/linux/ramips/dts/WT1520.dtsi is for the "Nexx WT1520" 
and should be named "WT1520.dts" instead.  I will send that change through as a 
different patch.

 target/linux/ramips/dts/HLKRM04.dts   | 5 +
 target/linux/ramips/dts/WIZFI630A.dts | 2 ++
 target/linux/ramips/dts/WT1520.dtsi   | 2 ++
 target/linux/ramips/dts/rt5350.dtsi   | 3 ---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/target/linux/ramips/dts/HLKRM04.dts 
b/target/linux/ramips/dts/HLKRM04.dts
index 713b51f..3c9a93c 100644
--- a/target/linux/ramips/dts/HLKRM04.dts
+++ b/target/linux/ramips/dts/HLKRM04.dts
@@ -63,6 +63,11 @@
ralink,group = "i2c", "jtag";
ralink,function = "gpio";
};
+
+   uartf_gpio {
+   ralink,group = "uartf";
+   ralink,function = "gpio uartf";
+   };
};
};
 
diff --git a/target/linux/ramips/dts/WIZFI630A.dts 
b/target/linux/ramips/dts/WIZFI630A.dts
index 39d68c3..e2a51ec 100644
--- a/target/linux/ramips/dts/WIZFI630A.dts
+++ b/target/linux/ramips/dts/WIZFI630A.dts
@@ -59,6 +59,8 @@
interrupt-parent = <&intc>;
interrupts = <5>;
reg-shift = <2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&uartf_pins>;
status = "okay";
};
 
diff --git a/target/linux/ramips/dts/WT1520.dtsi 
b/target/linux/ramips/dts/WT1520.dtsi
index b8c4e0a..13ff268 100644
--- a/target/linux/ramips/dts/WT1520.dtsi
+++ b/target/linux/ramips/dts/WT1520.dtsi
@@ -15,6 +15,8 @@
 
palmbus@1000 {
uart@500 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uartf_pins>;
status = "okay";
};
};
diff --git a/target/linux/ramips/dts/rt5350.dtsi 
b/target/linux/ramips/dts/rt5350.dtsi
index 27f7bf6..b8712e9 100644
--- a/target/linux/ramips/dts/rt5350.dtsi
+++ b/target/linux/ramips/dts/rt5350.dtsi
@@ -94,9 +94,6 @@
 
reg-shift = <2>;
 
-   pinctrl-names = "default";
-   pinctrl-0 = <&uartf_pins>;
-
status = "disabled";
};
 
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/4] rampis: HLK-RM04 - Setup I2C as GPIO

2016-01-22 Thread John Clark

The I2C function of the RT5350 SoC on the HLK-RM04 is used for GPIO1 and GPIO2.

Take note that the I2C_SD pin is GPIO1 on the RT5350 and is exposed on the 
HLK-RM04 as GPIO0
Likewise the I2C_SCLK pin is GPIO2 on the RT5350 and is exposed on the HLK-RM04 
as GPIO1

 group   mode 1mode 2   hlk-rm04 pin & export
  i2ci2c_sdgpio1   (pin 8, hlk-rm04:gpio0)
  i2ci2c_sclk  gpio2   (pin 9, hlk-rm04:gpio1)

reference:
  http://www.hlktech.net/product_detail.php?ProId=39
  http://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf

Signed-off-by: John Clark 
---
 target/linux/ramips/dts/HLKRM04.dts | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/target/linux/ramips/dts/HLKRM04.dts 
b/target/linux/ramips/dts/HLKRM04.dts
index 5f43642..713b51f 100644
--- a/target/linux/ramips/dts/HLKRM04.dts
+++ b/target/linux/ramips/dts/HLKRM04.dts
@@ -60,7 +60,7 @@
pinctrl {
state_default: pinctrl0 {
gpio {
-   ralink,group = "jtag";
+   ralink,group = "i2c", "jtag";
ralink,function = "gpio";
};
};
@@ -82,6 +82,25 @@
status = "okay";
};
 
+   gpio-export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+   /* I2C */
+   gpio1 {
+   /* I2C_I2C_SD */
+   gpio-export,name = "hlk-rm04:gpio0";
+   gpio-export,direction_may_change = <1>;
+   gpios = <&gpio0 1 0>;
+   };
+   gpio2 {
+   /* I2C_I2C_SCLK */
+   gpio-export,name = "hlk-rm04:gpio1";
+   gpio-export,direction_may_change = <1>;
+   gpios = <&gpio0 2 0>;
+   };
+   };
+
gpio-keys-polled {
compatible = "gpio-keys-polled";
#address-cells = <1>;
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/4] ramips: HLK-RM04 - Fix push button functions

2016-01-22 Thread John Clark

The RESET button of the HLK-RM04 is connected to GPIO0, linux function 0x198
The WPS button of the HLK-RM04 is connected to GPIO14, linux function 0x211

Signed-off-by: John Clark 
---
 target/linux/ramips/dts/HLKRM04.dts | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/target/linux/ramips/dts/HLKRM04.dts 
b/target/linux/ramips/dts/HLKRM04.dts
index 7996f99..5f43642 100644
--- a/target/linux/ramips/dts/HLKRM04.dts
+++ b/target/linux/ramips/dts/HLKRM04.dts
@@ -87,11 +87,15 @@
#address-cells = <1>;
#size-cells = <0>;
poll-interval = <20>;
-
-   wps {
+   reset {
label = "reset";
-   gpios = <&gpio0 14 1>;
+   gpios = <&gpio0 0 1>;
linux,code = <0x198>;
};
+   wps {
+   label = "wps";
+   gpios = <&gpio0 14 1>;
+   linux,code = <0x211>;
+   };
};
 };
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/4] ramips: HLK-RM04 - Remove power LED config

2016-01-22 Thread John Clark

The power LED on the HLK-RM04 is hard wired to the power bus and is not under 
GPIO control, remove the bogus config for it.
(Note that GPIO0 is actually connected to the RESET button.)

Signed-off-by: John Clark 
---
 target/linux/ramips/dts/HLKRM04.dts | 9 -
 1 file changed, 9 deletions(-)

diff --git a/target/linux/ramips/dts/HLKRM04.dts 
b/target/linux/ramips/dts/HLKRM04.dts
index f90a9ac..7996f99 100644
--- a/target/linux/ramips/dts/HLKRM04.dts
+++ b/target/linux/ramips/dts/HLKRM04.dts
@@ -94,13 +94,4 @@
linux,code = <0x198>;
};
};
-
-   gpio-leds {
-   compatible = "gpio-leds";
-
-   power {
-   label = "hlk-rm04:red:power";
-   gpios = <&gpio0 0 1>;
-   };
-   };
 };
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Commits] r48276 - trunk/target/linux/ar71xx/image

2016-01-22 Thread Felix Fietkau

Hi Arjen,

I've reverted the commit for now. Another approach might be to use
mtdconcat and set it up from the mach file.

Thanks,

- Felix

On 2016-01-22 20:11, Arjen de Korte wrote:
> This doesn't look good. This patch will move the location of the  
> 'caldata_backup' partition from the factory default location
> 
> 0x01fc-0x0200 : "caldata_backup"
> 
> to
> 
> 0x07fc-0x0800 : "caldata_backup"
> 
> But since the data of this partition is not moved beforehand, the  
> previous location will be overwritten by the larger "firmware"  
> partition and the new location will probably contain nothing but FF.  
> While I agree it is a waste to not use the 96 MB in location  
> 0x0200-0x0800, just moving the "caldata_backup"  
> partition to a new location and hope for the best is not a good  
> solution.
> 
> Regards, Arjen
> 
> Citeren openwrt-comm...@openwrt.org:
> 
>> Author: nbd
>> Date: 2016-01-17 12:16:56 +0100 (Sun, 17 Jan 2016)
>> New Revision: 48276
>>
>> Modified:
>>trunk/target/linux/ar71xx/image/Makefile
>> Log:
>> ar71xx: Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4
>>
>> Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.
>>
>> Credit to @Tuochenlyu on GitHub.
>>
>> Signed-off-by: Chris Marchesi 
>>
>> Modified: trunk/target/linux/ar71xx/image/Makefile
>> ===
>> --- trunk/target/linux/ar71xx/image/Makefile 2016-01-17 11:16:52 UTC  
>> (rev 48275)
>> +++ trunk/target/linux/ar71xx/image/Makefile 2016-01-17 11:16:56 UTC  
>> (rev 48276)
>> @@ -1581,7 +1581,7 @@
>>   
>> wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
>>   
>> r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a(firmware),2048k(language),3072k(traffic_meter)
>>   
>> tew823dru_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(nvram)ro,15296k(firmware),192k(lang)ro,512k(my-dlink)ro,64k(mac)ro,64k(art)ro
>> -wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c(firmware),256k(caldata_backup),-(reserved)
>> +wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c(firmware),256k(caldata_backup),-(reserved)
>>   
>> zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5(firmware)
>>   
>> mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
>>   
>> mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
>> ___
>> openwrt-commits mailing list
>> openwrt-comm...@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Commits] r48276 - trunk/target/linux/ar71xx/image

2016-01-22 Thread Arjen de Korte

This doesn't look good. This patch will move the location of the  
'caldata_backup' partition from the factory default location


0x01fc-0x0200 : "caldata_backup"

to

0x07fc-0x0800 : "caldata_backup"

But since the data of this partition is not moved beforehand, the  
previous location will be overwritten by the larger "firmware"  
partition and the new location will probably contain nothing but FF.  
While I agree it is a waste to not use the 96 MB in location  
0x0200-0x0800, just moving the "caldata_backup"  
partition to a new location and hope for the best is not a good  
solution.


Regards, Arjen

Citeren openwrt-comm...@openwrt.org:


Author: nbd
Date: 2016-01-17 12:16:56 +0100 (Sun, 17 Jan 2016)
New Revision: 48276

Modified:
   trunk/target/linux/ar71xx/image/Makefile
Log:
ar71xx: Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.

Credit to @Tuochenlyu on GitHub.

Signed-off-by: Chris Marchesi 

Modified: trunk/target/linux/ar71xx/image/Makefile
===
--- trunk/target/linux/ar71xx/image/Makefile	2016-01-17 11:16:52 UTC  
(rev 48275)
+++ trunk/target/linux/ar71xx/image/Makefile	2016-01-17 11:16:56 UTC  
(rev 48276)

@@ -1581,7 +1581,7 @@
  
wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
  
r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a(firmware),2048k(language),3072k(traffic_meter)
  
tew823dru_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(nvram)ro,15296k(firmware),192k(lang)ro,512k(my-dlink)ro,64k(mac)ro,64k(art)ro

-wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c(firmware),256k(caldata_backup),-(reserved)
+wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c(firmware),256k(caldata_backup),-(reserved)
  
zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5(firmware)
  
mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
  
mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro

___
openwrt-commits mailing list
openwrt-comm...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits

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

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread John Clark

After a full distclean, uclient-fetch is now automatically being 
selected by make defconfig (running make clean / feeds update -a / feeds 
install -a / make defconfig without distclean did not trigger it for me).


I just wanted to report back that outside of the ddns-scripts issue 
Weedy reported, all of my wget issues should be considered resolved at 
this point.


--John

On 1/22/16 10:26 AM, John Clark wrote:
I don't know if I looked at the wrong file or what, but I have 
recompiled several times since then so I can't be enitrely certain 
anymore.


At this point I also see the same tiny binary you see.  Please 
disregard my earlier comment as to a 112K size.  Mine is a ramips 
build, fwiw:


-rwxr-xr-x1 root root 12343 Jan 22 12:02 uclient-fetch*
-rw-r--r--1 root root 16687 Jan 22 12:02 
/usr/lib/libuclient.so


--John


On 1/22/16 10:18 AM, Felix Fietkau wrote:

On 2016-01-22 14:21, John Clark wrote:

yes, is was dropped with r48386 + 48379
so it *should* be automatically work with wget -> uclient-fetch
I have updated to the latest trunk commit where I see your 
/usr/bin/wget
-> /bin/wget patch.  I have updated the feeds and symlinks to the 
latest

and greatest.  The packages are currently not configured to build
uclient-fetch by default, so I manually selected it.

My resulting build now has a 112,453 byte /bin/uclient-fetch binary and
I can confirm wget does work.  I guess the only thing left to do is to
have the uclient-fetch binary build by default.

Did you use any weird build options? Here's the size from my own build
(ar71xx):
nbd@nf > ls -la bin/uclient-fetch usr/lib/libuclient.so
-rwxr-xr-x  1 nbd  staff  12344 Jan 21 15:39 bin/uclient-fetch
-rw-r--r--  1 nbd  staff  16684 Jan 21 15:39 usr/lib/libuclient.so

Question: The busybox binary (for me) goes from 366,401 bytes to 
300,327

with the removal of wget from it.  Therefore, the uclient-fetch binary
swapout causes a 46,379 byte increase in size. I assume the desire to
move to uclient-fetch from busybox is for the SSL support?  If so, it
still does not support SSL without also building ustream-ssl.

ustream-ssl already ships with standard LuCI enabled builds.
Also, you can choose which TLS provider you want to use.
The way it's implemented right now, enabling SSL also does not require
recompiling uclient-fetch - it detects at run time whether SSL support
is availble.

- Felix



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

Re: [OpenWrt-Devel] [PATCH 1/1] [ar71xx] Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

2016-01-22 Thread Chris Marchesi

On Tue, Jan 12, 2016 at 7:48 AM, Eric Schultz 
 wrote:

> Chris,
>
> We're glad to have you involved! Welcome to the party :)
>

Just a quick (belated) email to say thanks for the words Eric and for the
inclusion of the patch everyone!

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

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread John Clark

I don't know if I looked at the wrong file or what, but I have 
recompiled several times since then so I can't be enitrely certain anymore.


At this point I also see the same tiny binary you see.  Please disregard 
my earlier comment as to a 112K size.  Mine is a ramips build, fwiw:


-rwxr-xr-x1 root root 12343 Jan 22 12:02 uclient-fetch*
-rw-r--r--1 root root 16687 Jan 22 12:02 
/usr/lib/libuclient.so


--John


On 1/22/16 10:18 AM, Felix Fietkau wrote:

On 2016-01-22 14:21, John Clark wrote:

yes, is was dropped with r48386 + 48379
so it *should* be automatically work with wget -> uclient-fetch

I have updated to the latest trunk commit where I see your /usr/bin/wget
-> /bin/wget patch.  I have updated the feeds and symlinks to the latest
and greatest.  The packages are currently not configured to build
uclient-fetch by default, so I manually selected it.

My resulting build now has a 112,453 byte /bin/uclient-fetch binary and
I can confirm wget does work.  I guess the only thing left to do is to
have the uclient-fetch binary build by default.

Did you use any weird build options? Here's the size from my own build
(ar71xx):
nbd@nf > ls -la bin/uclient-fetch usr/lib/libuclient.so
-rwxr-xr-x  1 nbd  staff  12344 Jan 21 15:39 bin/uclient-fetch
-rw-r--r--  1 nbd  staff  16684 Jan 21 15:39 usr/lib/libuclient.so


Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
with the removal of wget from it.  Therefore, the uclient-fetch binary
swapout causes a 46,379 byte increase in size. I assume the desire to
move to uclient-fetch from busybox is for the SSL support?  If so, it
still does not support SSL without also building ustream-ssl.

ustream-ssl already ships with standard LuCI enabled builds.
Also, you can choose which TLS provider you want to use.
The way it's implemented right now, enabling SSL also does not require
recompiling uclient-fetch - it detects at run time whether SSL support
is availble.

- Felix

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

Re: [OpenWrt-Devel] /usr/bin/ip missing in 15.05.1

2016-01-22 Thread Nishant Sharma


On Friday 22 January 2016 08:56 PM, Felix Fietkau wrote:

Here's what feeds.conf.default in the 15.05 branch contains:
src-git packages https://github.com/openwrt/packages.git;for-15.05
src-git luci https://github.com/openwrt/luci.git;for-15.05
src-git routing https://github.com/openwrt-routing/packages.git;for-15.05
src-git telephony https://github.com/openwrt/telephony.git;for-15.05
src-git management https://github.com/openwrt-management/packages.git;for-15.05


Thanks a lot Felix and Lars.

It seems I was compiling bleeding edge packages all this while and was 
wondering why a lot of them didn't compile successfully on 15.05.1 while 
they did on 15.05.


/me goes to re-build the images and packages.

Regards,
Nishant
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] /usr/bin/ip missing in 15.05.1

2016-01-22 Thread Felix Fietkau

On 2016-01-22 15:19, Nishant Sharma wrote:
> Hi,
> 
> On Friday 22 January 2016 05:44 PM, Felix Fietkau wrote:
>> Looks like you may have used the mwan3 package from the master branch 
>> in your 15.05 build. You need to use the for-15.05 branch from the 
>> packages feed. - Felix 
> My feeds.conf contains following lines:
> 
> src-git packages https://github.com/openwrt/packages.git
> src-git luci https://github.com/openwrt/luci.git
> src-git routing https://github.com/openwrt-routing/packages.git
> src-git telephony https://github.com/openwrt/telephony.git
> src-git management https://github.com/openwrt-management/packages.git
> src-git targets https://github.com/openwrt/targets.git
> 
> On GitHub, no matter what branch I choose, I always get the same clone URL:
> 
> e.g. at https://github.com/openwrt/packages/tree/for-15.05
> the clone URL I get is https://github.com/openwrt/packages.git
> 
> and at https://github.com/openwrt/packages/tree/master
> the clone URL is https://github.com/openwrt/packages.git
> 
> Am I missing something?
Here's what feeds.conf.default in the 15.05 branch contains:
src-git packages https://github.com/openwrt/packages.git;for-15.05
src-git luci https://github.com/openwrt/luci.git;for-15.05
src-git routing https://github.com/openwrt-routing/packages.git;for-15.05
src-git telephony https://github.com/openwrt/telephony.git;for-15.05
src-git management https://github.com/openwrt-management/packages.git;for-15.05

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

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Felix Fietkau

On 2016-01-22 14:21, John Clark wrote:
>>> yes, is was dropped with r48386 + 48379
>>> so it *should* be automatically work with wget -> uclient-fetch
> 
> I have updated to the latest trunk commit where I see your /usr/bin/wget 
> -> /bin/wget patch.  I have updated the feeds and symlinks to the latest 
> and greatest.  The packages are currently not configured to build 
> uclient-fetch by default, so I manually selected it.
> 
> My resulting build now has a 112,453 byte /bin/uclient-fetch binary and 
> I can confirm wget does work.  I guess the only thing left to do is to 
> have the uclient-fetch binary build by default.
Did you use any weird build options? Here's the size from my own build
(ar71xx):
nbd@nf > ls -la bin/uclient-fetch usr/lib/libuclient.so
-rwxr-xr-x  1 nbd  staff  12344 Jan 21 15:39 bin/uclient-fetch
-rw-r--r--  1 nbd  staff  16684 Jan 21 15:39 usr/lib/libuclient.so

> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327 
> with the removal of wget from it.  Therefore, the uclient-fetch binary 
> swapout causes a 46,379 byte increase in size. I assume the desire to 
> move to uclient-fetch from busybox is for the SSL support?  If so, it 
> still does not support SSL without also building ustream-ssl.
ustream-ssl already ships with standard LuCI enabled builds.
Also, you can choose which TLS provider you want to use.
The way it's implemented right now, enabling SSL also does not require
recompiling uclient-fetch - it detects at run time whether SSL support
is availble.

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

Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Felix Fietkau

On 2016-01-22 16:03, edgar.sol...@web.de wrote:
> On 22.01.2016 14:32, Weedy wrote:
>>> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
>> with the removal of wget from it.  Therefore, the uclient-fetch binary
>> swapout causes a 46,379 byte increase in size. I assume the desire to move
>> to uclient-fetch from busybox is for the SSL support?  If so, it still does
>> not support SSL without also building ustream-ssl.
> 
> yeah. an ssl capable wget (whatever it's called) out of the box would be 
> greatly appreciated.
> 
> @Felix: is that on the table?
It's already done. With uclient-fetch, you can simply install any
ustream-ssl variant (along with ca-certificates if you want to have
proper validation), and it'll immediately be SSL capable. That was my
main motivation behind replacing wget with ustream-ssl.

The aforementioned size increase is probably either a bug or a
measurement error (see my other mail regarding that subject).

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

[OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread edgar . soldin

On 22.01.2016 14:32, Weedy wrote:
>> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
> with the removal of wget from it.  Therefore, the uclient-fetch binary
> swapout causes a 46,379 byte increase in size. I assume the desire to move
> to uclient-fetch from busybox is for the SSL support?  If so, it still does
> not support SSL without also building ustream-ssl.

yeah. an ssl capable wget (whatever it's called) out of the box would be 
greatly appreciated.

@Felix: is that on the table?

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

Re: [OpenWrt-Devel] [PATCH] Ubnt EdgeRouter: Use mmcblk0p3 as ext4 rootfs for default ?

2016-01-22 Thread daniel

On 01/21/2016 08:57 AM, John Crispin wrote:
> 
> 
> On 20/01/2016 17:15, daniel wrote:
>> The UBNT EdgeRouter has an internal mmc flash card.
>> (unlike the EdgeRouter Lite)
>>
>> The factory mmc flash card layout is:
>>
>> Device Boot  Start End Sectors  Size Id Type
>> /dev/mmcblk0p1 *63   17135   17073  8.3M 83 Linux
>> /dev/mmcblk0p2   17199  149183  131985 64.5M 83 Linux
>> /dev/mmcblk0p3  149247 2246831 20975851G 83 Linux
>>
>> This patch edits the kernel command line to use the the 3rd partition
>> as rootfs (ext4).
>> I think this makes sense for a default configuration when installing
>> openwrt on the mmc flash card of the EdgeRouter.
>>
>> What do you think ?
>>
>> Signed-off-by: Daniel Danzberger 
>>
>>
>>
> 
> we use block2mtd so that sysupgrade works. your patch technically is
> fine but will break at least sysupgrade on this target.
> 

I changed the patch to use block2mtd.

While testing sysupgrade, I noticed that it's currently borken on this
device, because the /tmp/sysinfo/board_name file contains "ubnt,er200".
For sysupgrade to work, the file should contain "er".
However, deleting the file before running sysupgrade fixes the problem.

With this patch, I am now able to use the EdgeRouter properly with an
1 GB ext4 rootfs. But squashfs images won't work anymore due the change
of the rootfstype= in the kernel cmdline.

Maybe the squashfs image should be removed for the Edgerouter builds ?
Or is there a way to use different cmdlines for each image ?

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

-- 
Regards

Daniel Danzberger
embeDD GmbH, Breitenweg 10, CH-6370 Stans
--- a/target/linux/octeon/image/Makefile
+++ b/target/linux/octeon/image/Makefile
@@ -23,7 +23,7 @@ define Image/BuildKernel/Initramfs/Template
$(STAGING_DIR_HOST)/bin/patch-cmdline $(BIN_DIR)/$(IMG_PREFIX)-$(1)-vmlinux-initramfs.elf '$(strip $(2))'
 endef
 
-ER_CMDLINE:=-mtdparts=phys_mapped_flash:640k(boot0)ro,640k(boot1)ro,64k(eeprom)ro block2mtd.block2mtd=/dev/mmcblk0p2,65536,rootfs,5 root=/dev/mtdblock3 rootfstype=squashfs rootwait
+ER_CMDLINE:=-mtdparts=phys_mapped_flash:640k(boot0)ro,640k(boot1)ro,64k(eeprom)ro block2mtd.block2mtd=/dev/mmcblk0p3,512,rootfs,5 rootfstype=ext4 root=/dev/mtdblock3 rootwait
 ERLITE_CMDLINE:=-mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@1024k(eeprom) block2mtd.block2mtd=/dev/sda2,65536,rootfs,5 root=/dev/mtdblock3 rootfstype=squashfs rootwait
 
 define Image/BuildKernel
@@ -49,6 +49,7 @@ endef
 
 define Image/Build/ext4
$(call Image/Build/sysupgrade,erlite,generic,ext4)
+   $(call Image/Build/sysupgrade,er,er,ext4)
 endef
 
 define Image/Build/squashfs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] /usr/bin/ip missing in 15.05.1

2016-01-22 Thread Lars

hey,

have a look at 15.05's feeds.conf.example for the correct feed lines:
http://git.openwrt.org/?p=15.05/openwrt.git;a=blob;f=feeds.conf.default;h=8e1490150d82ba944388d96d8a25d6233c393698;hb=HEAD

example:
src-git packages https://github.com/openwrt/packages.git;for-15.05

cheers,
lars

On 22.01.2016 15:19, Nishant Sharma wrote:
> Hi,
> 
> On Friday 22 January 2016 05:44 PM, Felix Fietkau wrote:
>> Looks like you may have used the mwan3 package from the master branch
>> in your 15.05 build. You need to use the for-15.05 branch from the
>> packages feed. - Felix 
> My feeds.conf contains following lines:
> 
> src-git packages https://github.com/openwrt/packages.git
> src-git luci https://github.com/openwrt/luci.git
> src-git routing https://github.com/openwrt-routing/packages.git
> src-git telephony https://github.com/openwrt/telephony.git
> src-git management https://github.com/openwrt-management/packages.git
> src-git targets https://github.com/openwrt/targets.git
> 
> On GitHub, no matter what branch I choose, I always get the same clone URL:
> 
> e.g. at https://github.com/openwrt/packages/tree/for-15.05
> the clone URL I get is https://github.com/openwrt/packages.git
> 
> and at https://github.com/openwrt/packages/tree/master
> the clone URL is https://github.com/openwrt/packages.git
> 
> Am I missing something?
> 
> Regards,
> Nishant
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


0x7E86809F.asc
Description: application/pgp-keys
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] /usr/bin/ip missing in 15.05.1

2016-01-22 Thread Nishant Sharma


Hi,

On Friday 22 January 2016 05:44 PM, Felix Fietkau wrote:
Looks like you may have used the mwan3 package from the master branch 
in your 15.05 build. You need to use the for-15.05 branch from the 
packages feed. - Felix 

My feeds.conf contains following lines:

src-git packages https://github.com/openwrt/packages.git
src-git luci https://github.com/openwrt/luci.git
src-git routing https://github.com/openwrt-routing/packages.git
src-git telephony https://github.com/openwrt/telephony.git
src-git management https://github.com/openwrt-management/packages.git
src-git targets https://github.com/openwrt/targets.git

On GitHub, no matter what branch I choose, I always get the same clone URL:

e.g. at https://github.com/openwrt/packages/tree/for-15.05
the clone URL I get is https://github.com/openwrt/packages.git

and at https://github.com/openwrt/packages/tree/master
the clone URL is https://github.com/openwrt/packages.git

Am I missing something?

Regards,
Nishant
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] /usr/bin/ip missing in 15.05.1

2016-01-22 Thread Nishant Sharma


Hi,

On Friday 22 January 2016 05:44 PM, Felix Fietkau wrote:
Looks like you may have used the mwan3 package from the master branch 
in your 15.05 build. You need to use the for-15.05 branch from the 
packages feed. - Felix 

My feeds.conf contains following lines:

src-git packages https://github.com/openwrt/packages.git
src-git luci https://github.com/openwrt/luci.git
src-git routing https://github.com/openwrt-routing/packages.git
src-git telephony https://github.com/openwrt/telephony.git
src-git management https://github.com/openwrt-management/packages.git
src-git targets https://github.com/openwrt/targets.git

On GitHub, no matter what branch I choose, I always get the same clone URL:

e.g. at https://github.com/openwrt/packages/tree/for-15.05
the clone URL I get is https://github.com/openwrt/packages.git

and at https://github.com/openwrt/packages/tree/master
the clone URL is https://github.com/openwrt/packages.git

Am I missing something?

Regards,
Nishant
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] qos-scripts: Add IPv6 support

2016-01-22 Thread Michael Marley

The problem still happens for me even without the txqueuelen change.

Michael

On 01/22/16 07:15, Felix Fietkau wrote:
> On 2016-01-22 13:12, Weedy wrote:
>> ~Off topic~
>>
>> So I'm going to guess this means both of you have qos-scripts running
>> on current trunk builds?
>>
>> Have you seen anyone complaining about kernel panic in hfsc? Should I
>> make a trac ticket?
>>
>> ar71xx/TLWDR4300
>> WARNING: CPU: 0 PID: 0 at net/sched/sch_hfsc.c:1429 0x831f5b2c()
> Can you please test if my recent removal of the txqueuelen override
> makes a difference here?
>
> - Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Felix Fietkau

On 2016-01-22 14:32, Weedy wrote:
> 
> On 22 Jan 2016 08:22, "John Clark"  > wrote:

 yes, is was dropped with r48386 + 48379
 so it *should* be automatically work with wget -> uclient-fetch
>>
>>
>> I have updated to the latest trunk commit where I see your
> /usr/bin/wget -> /bin/wget patch.  I have updated the feeds and symlinks
> to the latest and greatest.  The packages are currently not configured
> to build uclient-fetch by default, so I manually selected it.
>>
>> My resulting build now has a 112,453 byte /bin/uclient-fetch binary
> and I can confirm wget does work.  I guess the only thing left to do is
> to have the uclient-fetch binary build by default.
>>
>> Question: The busybox binary (for me) goes from 366,401 bytes to
> 300,327 with the removal of wget from it.  Therefore, the uclient-fetch
> binary swapout causes a 46,379 byte increase in size. I assume the
> desire to move to uclient-fetch from busybox is for the SSL support?  If
> so, it still does not support SSL without also building ustream-ssl.
>>
>> --John
> 
> This also seems to have broken ddns-scripts.
> Or at least now I need full wget/curl to update dyndns.
Christian, please check the ddns package and make the same kind of 
adjustments that I did for 6in4 here:
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=80cdacc0b9ae6c063499cc12cc62b7a083f62974

Thanks,

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

Re: [OpenWrt-Devel] [PATCH] busybox: sysntpd - use NTP servers received via DHCP

2016-01-22 Thread Felix Fietkau

On 2016-01-22 14:12, Amine Aouled Hamed wrote:
> Hi,
> I tried this method the first time but it does nothing.
> I just tried it again now and the same thing happens (added a log
> message to logread in case it is restarted).
> Thats why I went to the hotplug script, add to it the fact that we cant
> choose specific interfaces to listen to using this method.
You can also choose specific interfaces via triggers, I just wrote the
simple variant that catches all changes. Please show me the exact patch
that you tried, so I can check it to see if I can spot the bug.

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

Re: [OpenWrt-Devel] [PATCH] qos-scripts: Add IPv6 support

2016-01-22 Thread Felix Fietkau

On 2016-01-22 14:10, Weedy wrote:
> On 22 Jan 2016 07:15, "Felix Fietkau"  > wrote:
>>
>> On 2016-01-22 13:12, Weedy wrote:
>> > ~Off topic~
>> >
>> > So I'm going to guess this means both of you have qos-scripts running
>> > on current trunk builds?
>> >
>> > Have you seen anyone complaining about kernel panic in hfsc? Should I
>> > make a trac ticket?
>> >
>> > ar71xx/TLWDR4300
>> > WARNING: CPU: 0 PID: 0 at net/sched/sch_hfsc.c:1429 0x831f5b2c()
>> Can you please test if my recent removal of the txqueuelen override
>> makes a difference here?
>>
>> - Felix
> 
> It's running 48424 and I just double checked that I still have the
> override in place.
> 
> Is the override likely to cause or mask the problem?
Maybe the override caused the problem or made it more likely, I don't
know. It's just a wild guess...

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

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Weedy

On 22 Jan 2016 08:22, "John Clark"  wrote:
>>>
>>> yes, is was dropped with r48386 + 48379
>>> so it *should* be automatically work with wget -> uclient-fetch
>
>
> I have updated to the latest trunk commit where I see your /usr/bin/wget
-> /bin/wget patch.  I have updated the feeds and symlinks to the latest
and greatest.  The packages are currently not configured to build
uclient-fetch by default, so I manually selected it.
>
> My resulting build now has a 112,453 byte /bin/uclient-fetch binary and I
can confirm wget does work.  I guess the only thing left to do is to have
the uclient-fetch binary build by default.
>
> Question: The busybox binary (for me) goes from 366,401 bytes to 300,327
with the removal of wget from it.  Therefore, the uclient-fetch binary
swapout causes a 46,379 byte increase in size. I assume the desire to move
to uclient-fetch from busybox is for the SSL support?  If so, it still does
not support SSL without also building ustream-ssl.
>
> --John

This also seems to have broken ddns-scripts.
Or at least now I need full wget/curl to update dyndns.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread John Clark


yes, is was dropped with r48386 + 48379
so it *should* be automatically work with wget -> uclient-fetch


I have updated to the latest trunk commit where I see your /usr/bin/wget 
-> /bin/wget patch.  I have updated the feeds and symlinks to the latest 
and greatest.  The packages are currently not configured to build 
uclient-fetch by default, so I manually selected it.


My resulting build now has a 112,453 byte /bin/uclient-fetch binary and 
I can confirm wget does work.  I guess the only thing left to do is to 
have the uclient-fetch binary build by default.


Question: The busybox binary (for me) goes from 366,401 bytes to 300,327 
with the removal of wget from it.  Therefore, the uclient-fetch binary 
swapout causes a 46,379 byte increase in size. I assume the desire to 
move to uclient-fetch from busybox is for the SSL support?  If so, it 
still does not support SSL without also building ustream-ssl.


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

Re: [OpenWrt-Devel] [PATCH] busybox: sysntpd - use NTP servers received via DHCP

2016-01-22 Thread Amine Aouled Hamed

Hi,
I tried this method the first time but it does nothing.
I just tried it again now and the same thing happens (added a log message
to logread in case it is restarted).
Thats why I went to the hotplug script, add to it the fact that we cant
choose specific interfaces to listen to using this method.


On Wed, Jan 20, 2016 at 1:51 PM, Felix Fietkau  wrote:

> On 2016-01-20 13:34, amine ahd wrote:
> > The current state of NTP is to load the list of NTP servers
> > from the static file /etc/config/system.
> > This patch allows ntpd to get NTP servers from DHCP.
> >
> >
> > Changes from V1:
> >   -Users could choose not to use DHCP by setting "use_dhcp" to 0 in
> /etc/config/system under the ntp section.
> >   -Users could specify which interfaces to use to get NTP servers
> from.
> >   -Sysntpd will exit if no servers are specified in the static list
> and the DHCP option is disabled.
> >   -Sysntpd will restart only if all of the following conditions are
> met:
> >   *The user allowed DHCP to be used for NTP.
> >   *The iface action is UP.
> >   *The iface is specified in the list.
> >   *The protocol in use is either DHCP or DHCPv6.
> >   -Code improvements.
> >
> > Signed-off-by: amine hamed 
> > ---
> >  package/utils/busybox/Makefile  |  3 ++
> >  package/utils/busybox/files/sysntpd | 31 +++--
> >  package/utils/busybox/files/sysntpd.hotplug | 54
> +
> >  3 files changed, 85 insertions(+), 3 deletions(-)
> >  create mode 100644 package/utils/busybox/files/sysntpd.hotplug
> >
> > diff --git a/package/utils/busybox/files/sysntpd.hotplug
> b/package/utils/busybox/files/sysntpd.hotplug
> > new file mode 100644
> > index 000..34a2f7a
> > --- /dev/null
> > +++ b/package/utils/busybox/files/sysntpd.hotplug
> > @@ -0,0 +1,54 @@
> > +#!/bin/sh
> > +
> > +. /lib/functions.sh
> > +. /usr/share/libubox/jshn.sh
> > +
> > +is_valid_interface() {
> > + local list="$(uci get system.ntp.dhcp_ifaces)"
> > + [ -z "$list" ] && return 0
> > +
> > + case " $list " in
> > + *" $INTERFACE "*)
> > + return 0
> > + ;;
> > + *)
> > + return 1
> > + ;;
> > + esac
> > +}
> > +
> > +config_load system
> > +local proto="$(uci get network.$INTERFACE.proto)"
> > +config_get_bool "use_dhcp" "ntp" "use_dhcp"
> > +[ "$use_dhcp" = 1 ] && [ "$ACTION" = ifup ] && is_valid_interface && [
> "$proto" = dhcp -o "$proto" = dhcp6 ] || exit 0
> > +
> > +handle_default_ntp_servers() {
> > + local server="$1"
> > + new_ntp_servers="$new_ntp_servers $server"
> > +}
> > +
> > +local dhcp_ntp_servers iface status ntpserver dump
> > +local dhcp_ifaces="$(uci -q get system.ntp.dhcp_ifaces)"
> > +if [ -z "$dhcp_ifaces" ]; then
> > + dump="$(ubus call network.interface dump)"
> > + dhcp_ntp_servers=$(jsonfilter -s "$dump" -e
> '$["interface"][*]["data"]["ntpserver"]')
> > +else
> > + for iface in $dhcp_ifaces; do
> > + status="$(ubus call network.interface.$iface status)"
> > + ntpserver=$(jsonfilter -s "$status" -e
> '$["data"]["ntpserver"]')
> > + [ -n "$ntpserver" ] && \
> > + dhcp_ntp_servers="$dhcp_ntp_servers $ntpserver"
> > + done
> > +fi
> > +
> > +new_ntp_servers="$dhcp_ntp_servers"
> > +#get the default list of ntp servers from the config file and append it
> to the new list
> > +config_list_foreach "ntp" "server" handle_default_ntp_servers
> > +
> > +#get the current list of ntp servers in the running instance
> > +local current_ntp_servers=$(ubus call service list '{"name":"sysntpd",
> "verbose":true}' | jsonfilter -e
> '$["sysntpd"]["instances"][*]["data"]["ntp_servers"]')
> > +#if its an up action, the iface uses DHCP and the new list of ntp
> servers is different from the old, restart sysntpd
> > +[ "$current_ntp_servers" != "$new_ntp_servers" ] || exit 0
> > +
> > +logger -t sysntpd "Reloading sysntpd due to $ACTION of interface
> $INTERFACE and a change of NTP servers"
> > +/etc/init.d/sysntpd enabled && /etc/init.d/sysntpd reload
> This is all way more complex than it needs to be. There's a simple
> solution -
> just replace the sysntpd init script service_triggers function with this:
>
> service_triggers() {
> local script=$(readlink "$initscript")
> local name=$(basename ${script:-$initscript})
>
> procd_open_trigger
> procd_add_raw_trigger "interface.*" 2000 /etc/init.d/$name reload
> procd_close_trigger
>
> procd_add_reload_trigger "system"
> procd_add_validation validate_ntp_section
> }
>
> You can drop the hotplug script entirely.
> What this will do is it will instruct procd to run the init script,
> whenever an interface up/down event arrives (waiting for up to 2 seconds
> before starting the script instead of starting it once for every single
> event). procd will en

Re: [OpenWrt-Devel] [PATCH] qos-scripts: Add IPv6 support

2016-01-22 Thread Weedy

On 22 Jan 2016 07:15, "Felix Fietkau"  wrote:
>
> On 2016-01-22 13:12, Weedy wrote:
> > ~Off topic~
> >
> > So I'm going to guess this means both of you have qos-scripts running
> > on current trunk builds?
> >
> > Have you seen anyone complaining about kernel panic in hfsc? Should I
> > make a trac ticket?
> >
> > ar71xx/TLWDR4300
> > WARNING: CPU: 0 PID: 0 at net/sched/sch_hfsc.c:1429 0x831f5b2c()
> Can you please test if my recent removal of the txqueuelen override
> makes a difference here?
>
> - Felix

It's running 48424 and I just double checked that I still have the override
in place.

Is the override likely to cause or mask the problem?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] qos-scripts: Add IPv6 support

2016-01-22 Thread Felix Fietkau

On 2016-01-22 13:12, Weedy wrote:
> ~Off topic~
> 
> So I'm going to guess this means both of you have qos-scripts running
> on current trunk builds?
> 
> Have you seen anyone complaining about kernel panic in hfsc? Should I
> make a trac ticket?
> 
> ar71xx/TLWDR4300
> WARNING: CPU: 0 PID: 0 at net/sched/sch_hfsc.c:1429 0x831f5b2c()
Can you please test if my recent removal of the txqueuelen override
makes a difference here?

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

Re: [OpenWrt-Devel] /usr/bin/ip missing in 15.05.1

2016-01-22 Thread Felix Fietkau

On 2016-01-22 09:37, Nishant Sharma wrote:
> Hi,
> 
> I compiled 15.05.1 for x86, x86_64 and ar71xx (mikrotik RB951Ui) and 
> found that mwan3 didn't work because it was looking for /usr/bin/ip.
> 
> I have compiled ip-full into the image.
> 
> I had to symlink /usr/sbin/ip to /usr/bin/ip in order for mwan3 to work.
> 
> OpenVPN-openssl worked as expected and as able to add routes to the system.
Looks like you may have used the mwan3 package from the master branch in
your 15.05 build. You need to use the for-15.05 branch from the packages
feed.

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

Re: [OpenWrt-Devel] [PATCH] qos-scripts: Add IPv6 support

2016-01-22 Thread Weedy

~Off topic~

So I'm going to guess this means both of you have qos-scripts running
on current trunk builds?

Have you seen anyone complaining about kernel panic in hfsc? Should I
make a trac ticket?

ar71xx/TLWDR4300
WARNING: CPU: 0 PID: 0 at net/sched/sch_hfsc.c:1429 0x831f5b2c()
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] qos-scripts: Add IPv6 support

2016-01-22 Thread Felix Fietkau

On 2016-01-22 04:45, Michael Marley wrote:
> I apologize, my client mangled my previous attempt at resubmission.
> 
> Here is an updated version with three improvements.  The problem with
> the rules not being removed (which was not new and actually caused by a
> grep command incompatible with musl) was fixed by using an updated grep
> command (thanks nbd!).  The problems pertaining to the xtables lock
> (including "too many links" and "directory not empty") were fixed by
> always executing ip[6]tables with the "-w" command-line argument to make
> it wait for the xtables lock.  Lastly, I fixed a place where I hardcoded
> "iptables" and "ip6tables" instead of looping over the array like
> everywhere else.
> --trim here--
> 
> This adds IPv6 support to qos-scripts for both tc/qdisc and the
> iptables classification rules.  The tc/qdisc part is accomplished
> by removing "protocol ip" from the tc command line, causing the
> rule to be applied to all protocols.  The iptables part is
> accomplished by adding each rule using both iptables and ip6tables.
> 
> This patch is based on previous work by Ilkka Ollakka and
> Dominique Martinet.
> 
> Signed-off-by: Michael Marley 
> ---
Applied. Next time, please write any comments under the "---" line. That
way I don't have to manually edit the commit message.

Thanks,

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

[OpenWrt-Devel] LuCI FileUpload in network section

2016-01-22 Thread Jakub Jančo

Hello,

I'm trying to upload file in interface configuration, but it always
save file as value in config file. Is there something like switch to
upload original file?

I added this option to
/usr/lib/lua/luci/model/cbi/admin_network/proto_newproto.lua
---
op_tls_auth = section:taboption( "security", FileUpload, "tls_auth",
"Key file" )
---


And after Save or Save and apply


/etc/config/network

config interface 'test'
option proto 'newproto'
option tls_auth 'line1 filecontent
line2 filecontent
'


Thanks for help.

--
S pozdravom Jakub Janco
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] /usr/bin/ip missing in 15.05.1

2016-01-22 Thread Nishant Sharma


Hi,

I compiled 15.05.1 for x86, x86_64 and ar71xx (mikrotik RB951Ui) and 
found that mwan3 didn't work because it was looking for /usr/bin/ip.


I have compiled ip-full into the image.

I had to symlink /usr/sbin/ip to /usr/bin/ip in order for mwan3 to work.

OpenVPN-openssl worked as expected and as able to add routes to the system.

Regards,
Nishant
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

2016-01-22 Thread Bastian Bittorf

* John Clark  [22.01.2016 07:55]:
> Is it intentional that wget is not available by default in the

i just send a patch. thanks for spotting this.

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] base-files: fix sysupgrade 'wget' handling

2016-01-22 Thread Bastian Bittorf

with r48379 and r48386 the path of wget changed.
respect that and adjust the dirname.

this fixes #21680

Signed-off-by: Bastian Bittorf 
---
 package/base-files/files/lib/upgrade/common.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 761b4c1..adf290c 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -48,7 +48,7 @@ supivot() { #  
 
 run_ramfs() { #  [...]
install_bin /bin/busybox /bin/ash /bin/sh /bin/mount /bin/umount
\
-   /sbin/pivot_root /usr/bin/wget /sbin/reboot /bin/sync /bin/dd   
\
+   /sbin/pivot_root /bin/wget /sbin/reboot /bin/sync /bin/dd   
\
/bin/grep /bin/cp /bin/mv /bin/tar /usr/bin/md5sum "/usr/bin/[" 
\
/bin/dd /bin/vi /bin/ls /bin/cat /usr/bin/awk /usr/bin/hexdump  
\
/bin/sleep /bin/zcat /usr/bin/bzcat /usr/bin/printf /usr/bin/wc 
\
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

47 matches

Mail list logo