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

2016-01-23 Thread Martin Tippmann 
>> 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=munged=1.2.3.4'
>> Downloading
>> 'https://dyn.dns.he.net/nic/update?hostname=example.com=munged=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.

There is another problem - if you use it to get olsr data from
httpinfo plugin uclient-fetch stalls and times out:

# uclient-fetch -O- http://127.0.0.1:2006
Downloading 'http://127.0.0.1:2006'
Connecting to 127.0.0.1:2006
Connection error: Connection timed out

The daemon should work fine, at least curl and wget on Ubuntu handle it fine.

# echo GET /all | nc 127.0.0.1 2006 | head
HTTP/1.0 200 OK
Content-type: text/plain

Table: Links
Local IPRemote IP   Hyst.   LQ  NLQ Cost
10.63.231.1 10.63.33.1290.001.000   1.000   1.000
...


regards
Martin
___
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-23 Thread Felix Fietkau 
On 2016-01-23 01:25, Felix Fietkau wrote:
> On 2016-01-23 00:45, Arjen de Korte wrote:
>> 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=munged=1.2.3.4'
>> Downloading  
>> 'https://dyn.dns.he.net/nic/update?hostname=example.com=munged=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.

Figured it out. It was a mix of two things:

- Needed to change ustream-ssl to treat SSL close notification as EOF
- The he.net HTTP server sends \n as linebreak instead of \r\n

I've changed the code to deal with both issues, it should work now, as
of r48463. Please test.

Thanks,

- 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-23 Thread Felix Fietkau 
On 2016-01-23 13:53, Martin Tippmann wrote:
>>> 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=munged=1.2.3.4'
>>> Downloading
>>> 'https://dyn.dns.he.net/nic/update?hostname=example.com=munged=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.
> 
> There is another problem - if you use it to get olsr data from
> httpinfo plugin uclient-fetch stalls and times out:
> 
> # uclient-fetch -O- http://127.0.0.1:2006
> Downloading 'http://127.0.0.1:2006'
> Connecting to 127.0.0.1:2006
> Connection error: Connection timed out
> 
> The daemon should work fine, at least curl and wget on Ubuntu handle it fine.
Please try the latest version (r48463)

Thanks,

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

[OpenWrt-Devel] [PATCH 1/1] uhttpd.init: generate 2048 bit RSA key

2016-01-23 Thread Heinrich Schuchardt 
RSA keys should be generated with sufficient length.
Using 1024 bits is considered unsafe.
In other packages the used key length is 2048 bits.

Signed-off-by: Heinrich Schuchardt 
---
 package/network/services/uhttpd/files/uhttpd.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/uhttpd/files/uhttpd.init 
b/package/network/services/uhttpd/files/uhttpd.init
index add0924..4ca6c8d 100755
--- a/package/network/services/uhttpd/files/uhttpd.init
+++ b/package/network/services/uhttpd/files/uhttpd.init
@@ -45,7 +45,7 @@ generate_keys() {
 
[ -x "$PX5G_BIN" ] && {
$PX5G_BIN selfsigned -der \
-   -days ${days:-730} -newkey rsa:${bits:-1024} -keyout 
"${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \
+   -days ${days:-730} -newkey rsa:${bits:-2048} -keyout 
"${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \
-subj 
/C="${country:-DE}"/ST="${state:-Saxony}"/L="${location:-Leipzig}"/CN="${commonname:-OpenWrt}"
sync
mv "${UHTTPD_KEY}.new" "${UHTTPD_KEY}"
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/1 v2] package/uhttpd: generate 2048 bit RSA key

2016-01-23 Thread Heinrich Schuchardt 
RSA keys should be generated with sufficient length.
Using 1024 bits is considered unsafe.
In other packages the used key length is 2048 bits.

Signed-off-by: Heinrich Schuchardt 
---
 package/network/services/uhttpd/files/uhttpd.config | 2 +-
 package/network/services/uhttpd/files/uhttpd.init   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/uhttpd/files/uhttpd.config 
b/package/network/services/uhttpd/files/uhttpd.config
index 61f8a49..41f930b 100644
--- a/package/network/services/uhttpd/files/uhttpd.config
+++ b/package/network/services/uhttpd/files/uhttpd.config
@@ -111,7 +111,7 @@ config cert px5g
option days 730
 
# RSA key size
-   option bits 1024
+   option bits 2048
 
# Location
option country  ZZ
diff --git a/package/network/services/uhttpd/files/uhttpd.init 
b/package/network/services/uhttpd/files/uhttpd.init
index add0924..4ca6c8d 100755
--- a/package/network/services/uhttpd/files/uhttpd.init
+++ b/package/network/services/uhttpd/files/uhttpd.init
@@ -45,7 +45,7 @@ generate_keys() {
 
[ -x "$PX5G_BIN" ] && {
$PX5G_BIN selfsigned -der \
-   -days ${days:-730} -newkey rsa:${bits:-1024} -keyout 
"${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \
+   -days ${days:-730} -newkey rsa:${bits:-2048} -keyout 
"${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \
-subj 
/C="${country:-DE}"/ST="${state:-Saxony}"/L="${location:-Leipzig}"/CN="${commonname:-OpenWrt}"
sync
mv "${UHTTPD_KEY}.new" "${UHTTPD_KEY}"
-- 
2.1.4
___
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-23 Thread Martin Tippmann 
2016-01-23 14:36 GMT+01:00 Bastian Bittorf :
> * Martin Tippmann  [23.01.2016 14:23]:
>> The daemon should work fine, at least curl and wget on Ubuntu handle it fine.
>
> i cannot reproduce this here:

Sorry if I was not clear - I meant uclient-fetch not wget.

# opkg list | grep uclient
libuclient - 2016-01-21-b9808a8c3a8922ed8df4e6fe45848ac2e52f13be
uclient-fetch - 2016-01-21-b9808a8c3a8922ed8df4e6fe45848ac2e52f13be

# uclient-fetch -O- http://127.0.0.1:2006
Downloading 'http://127.0.0.1:2006'
Connecting to 127.0.0.1:2006
Connection error: Connection timed out

it works fine with the busybox wget or regulary curl/wget but
uclient-fetch fails.

regards
Martin
___
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-23 Thread Arjen de Korte 

Citeren Felix Fietkau :


On 2016-01-23 01:25, Felix Fietkau wrote:

On 2016-01-23 00:45, Arjen de Korte wrote:

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=munged=1.2.3.4'
Downloading
'https://dyn.dns.he.net/nic/update?hostname=example.com=munged=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.


Figured it out. It was a mix of two things:

- Needed to change ustream-ssl to treat SSL close notification as EOF
- The he.net HTTP server sends \n as linebreak instead of \r\n

I've changed the code to deal with both issues, it should work now, as
of r48463. Please test.


The above mentioned problems seem to be fixed. I can now successfully  
send the update to the HE servers. I do notice another issue however.  
When using the -O  option, the output file is not truncated  
before writing data. This is undesireable if the file already contains  
data and less than the existing data is written. After the new data is  
written, the remaining old data is still there. A strategically placed  
O_TRUNC flag will probably fix this.


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-23 Thread Felix Fietkau 
On 2016-01-23 20:54, Arjen de Korte wrote:
> Citeren Felix Fietkau :
> 
>> On 2016-01-23 01:25, Felix Fietkau wrote:
>>> On 2016-01-23 00:45, Arjen de Korte wrote:
 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=munged=1.2.3.4'
 Downloading
 'https://dyn.dns.he.net/nic/update?hostname=example.com=munged=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.
>>
>> Figured it out. It was a mix of two things:
>>
>> - Needed to change ustream-ssl to treat SSL close notification as EOF
>> - The he.net HTTP server sends \n as linebreak instead of \r\n
>>
>> I've changed the code to deal with both issues, it should work now, as
>> of r48463. Please test.
> 
> The above mentioned problems seem to be fixed. I can now successfully  
> send the update to the HE servers. I do notice another issue however.  
> When using the -O  option, the output file is not truncated  
> before writing data. This is undesireable if the file already contains  
> data and less than the existing data is written. After the new data is  
> written, the remaining old data is still there. A strategically placed  
> O_TRUNC flag will probably fix this.
Should be fixed in r48465

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

[OpenWrt-Devel] Bug Report: zram corrupts memory / misbehaves on ar71xx

2016-01-23 Thread Martin Tippmann 
Hi, are here any other users of zram? We see some serious issues:

- application segfaults on memory pressure, without zram the OOM
killer is invoked but with zram random SIGSEVs starting to happen.
This happens also with light memory pressure e.g. when using luci.

Unfortunately I'm at loss how to debug this - I've switched on
CONFIG_DEBUG_VM and other memory related knobs unter make
kernel_menuconfig -> Kernel Hacking and changed the cmdline to add
debug but there are no messages that indicate any error.

I'm on trunk as of today on ar71xx (TP-LINK 841Nv8)

To reproduce:

- enable zram
- put a lot of memory pressure on the machine in a short time

While testing around I've discovered that lz4 for zram is broken -
this patch never got upstream and fixes the problem:
https://lkml.org/lkml/2014/7/21/736

Any ideas how to pinpoint this?

Here is a typical result with lots of segfaults (with
kernel.print-fatal-signals=1):

[  223.902219] do_page_fault(): sending SIGSEGV to netifd for invalid
write access to 
[  223.910852] epc = 77398a6c in libc.so[7731c000+92000]
[  223.916159] ra  = 77398a6c in libc.so[7731c000+92000]
[  223.921440]
[  224.281923] potentially unexpected fatal signal 11.
[  224.286990] CPU: 0 PID: 1110 Comm: netifd Not tainted 4.1.15 #2
[  224.293176] task: 81932ef8 ti: 816f6000 task.ti: 816f6000
[  224.298750] $ 0   :   0003 
[  224.304450] $ 4   : 773a88ed ff456461 80808080 fefefeff
[  224.309887] $ 8   : f73abb54  4000 8eac4000
[  224.315370] $12   : 000a  000e 00023ab1
[  224.320808] $16   : 773a88ed 773abb55 7fbe7048 7fbe6f50
[  224.326257] $20   :  773abb55 0062 00400019
[  224.331687] $24   :  7738d8d0
[  224.337143] $28   : 773c6320 7fbe6ec8 7fbe7048 77398a6c
[  224.342821] Hi: 003a
[  224.345799] Lo: 0012
[  224.348782] epc   : 77398a6c 0x77398a6c
[  224.352815] ra: 77398a6c 0x77398a6c
[  224.356776] Status: 0100f413 USER EXL IE
[  224.360951] Cause : 008c
[  224.363953] BadVA : 
[  224.366928] PrId  : 0001974c (MIPS 74Kc)
[  230.081537]
[  230.081537] do_page_fault(): sending SIGSEGV to sh for invalid read
access from 
[  230.090122] epc =  in busybox[40+46000]
[  230.095227] ra  =  in busybox[40+46000]
[  230.100289]
[  230.791874] potentially unexpected fatal signal 11.
[  230.796942] CPU: 0 PID: 3982 Comm: sh Not tainted 4.1.15 #2
[  230.802763] task: 8071da18 ti: 81cc task.ti: 81cc
[  230.808342] $ 0   :  0001 0f8f 
[  230.814067] $ 4   :  7fad75fc  
[  230.819506] $ 8   :  80064f20 803c9154 803244d8
[  230.824962] $12   : 001a 0013 000e 0007
[  230.830626] $16   :    
[  230.836100] $20   :  77fba000 7fad84f4 77fbd490
[  230.841529] $24   : 0001 77f936c0
[  230.847122] $28   :  7fad75a8  
[  230.852606] Hi: 
[  230.855580] Lo: 0007
[  230.858556] epc   :    (null)
[  230.862363] ra:    (null)
[  230.866143] Status: 0100f413 USER EXL IE
[  230.870318] Cause : 0088
[  230.873317] BadVA : 
[  230.876449] PrId  : 0001974c (MIPS 74Kc)
[  244.728483] potentially unexpected fatal signal 11.
[  244.733635] CPU: 0 PID: 3976 Comm: ubusd Not tainted 4.1.15 #2
[  244.739663] task: 8071f430 ti: 81496000 task.ti: 81496000
[  244.745275] $ 0   :   2462 779ba020
[  244.750739] $ 4   : 779ba000 0001 779ba020 
[  244.756405] $ 8   :  f400 0011 8514
[  244.761891] $12   : 00077469   6d656f75
[  244.767322] $16   : 779b29b0 779ba000 77a590b0 77a57538
[  244.772961] $20   : 77a54000 77a54000 7fdfaaf4 77a57490
[  244.778398] $24   :  779d0560
[  244.783873] $28   : 779ba020 7fdfaa30  7799dbf9
[  244.789312] Hi: 00399e63
[  244.792307] Lo: 49be433d
[  244.795285] epc   : 7799dce9 0x7799dce9
[  244.799322] ra: 7799dbf9 0x7799dbf9
[  244.803335] Status: 0100f413 USER EXL IE
[  244.807510] Cause : 00800010
[  244.810485] BadVA : 24630003
[  244.813650] PrId  : 0001974c (MIPS 74Kc)
[  248.265148]
[  248.265148] do_page_fault(): sending SIGSEGV to mac80211.sh for
invalid write access to 2020202c
[  248.274339] epc = 77590968 in libc.so[7756a000+92000]
[  248.279598] ra  = 77591880 in libc.so[7756a000+92000]
[  248.284873]
[  248.301767] potentially unexpected fatal signal 11.
[  248.306897] CPU: 0 PID: 3977 Comm: mac80211.sh Not tainted 4.1.15 #2
[  248.313515] task: 8071e9c0 ti: 804f2000 task.ti: 804f2000
[  248.319086] $ 0   :   7760d9c8 20202020
[  248.324578] $ 4   : 7760b008 0020 0020 
[  248.330016] $ 8   : fefefeff 80808080 0008 65726661
[  248.335464] $12   : 65737469   6e617469
[  248.341107] $16   : 7760b008 7760b008 7760d9c8 0020
[  248.346593] $20   : 7760f0b0 7760a000 7760d7c0 7760d7c0
[  248.352068]

[OpenWrt-Devel] [PATCH] lantiq: Make the ar9.dtsi sram node match "simple-bus"

2016-01-23 Thread Martin Blumenstingl 
All other SoC types are using "lantiq,sram" and "simple-bus" to ensure
that all child nodes are set up correctly during linux kernel
initialization (plat_of_setup(void) in arch/mips/lantiq/prom.c). Without
this some of sram child nodes might not be parsed.

Signed-off-by: Martin Blumenstingl 
---
 target/linux/lantiq/dts/ar9.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/dts/ar9.dtsi b/target/linux/lantiq/dts/ar9.dtsi
index 0be95c3..9feb8a0 100644
--- a/target/linux/lantiq/dts/ar9.dtsi
+++ b/target/linux/lantiq/dts/ar9.dtsi
@@ -40,7 +40,7 @@
sram@1F00 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "lantiq,sram";
+   compatible = "lantiq,sram", "simple-bus";
reg = <0x1F00 0x80>;
ranges = <0x0 0x1F00 0x7F>;
 
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Discussion: Replace BUSYBOX NSLOOKUP by hostip package

2016-01-23 Thread Christian Schoenebeck 
For some (good) reason you decided to remove wget from BusyBox and replace it 
by uclient-fetch.
Why not also remove nslookup from BusyBox.
- If compiled with musl it malfunction with given dns-server
- use hostip package instead. Tiny and functional
What do you think?
___
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-23 Thread Felix Fietkau 
On 2016-01-24 00:21, Christian Schoenebeck wrote:
> For whatever reason uclient-fetch is installed into /bin directory.
> Your plan is to use it as a replacement for Busybox Wget. Fine.
> Why do you place the wget link to uclient-fetch also into /bin ?
> wget default location is /usr/bin/wget
> 
> If you later install GNU wget the package will remove /usr/bin/wget and build 
> a new link to wget-ssl.
> With your /bin/wget link to uclient-fetch you will have two wget installation 
> afterwards.
> So it depends on your PATH environment which one is used.
> 
> I suggest wherever you install uclient-fetch the link must be from 
> /usr/bin/wget.
We decided that we want to move replaceable utilities that ship with the
default image to /bin, so that replacements (like GNU wget) can install
themselves to /usr/bin, which has priority in $PATH.
All this symlink mangling nonsense in postinst/postrm needs be ripped
out completely.

- 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-23 Thread Christian Schoenebeck 
For whatever reason uclient-fetch is installed into /bin directory.
Your plan is to use it as a replacement for Busybox Wget. Fine.
Why do you place the wget link to uclient-fetch also into /bin ?
wget default location is /usr/bin/wget

If you later install GNU wget the package will remove /usr/bin/wget and build a 
new link to wget-ssl.
With your /bin/wget link to uclient-fetch you will have two wget installation 
afterwards.
So it depends on your PATH environment which one is used.

I suggest wherever you install uclient-fetch the link must be from 
/usr/bin/wget.

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