Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
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
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
[OpenWrt-Devel] Discussion: Replace BUSYBOX NSLOOKUP by hostip package
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
[OpenWrt-Devel] [PATCH] lantiq: Make the ar9.dtsi sram node match "simple-bus"
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
Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
Citeren 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&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. 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 Indeed. Thanks! 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
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&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. >> >> 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
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]
Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
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&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. 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
[OpenWrt-Devel] [PATCH 1/1 v2] package/uhttpd: generate 2048 bit RSA key
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
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&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. 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
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&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. > > 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
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
Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
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
* 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: root@box:~ wget -qO - http://127.0.0.1:2006|wc -l 709 root@box:~ command -V wget wget is a tracked alias for /bin/wget (so it's working fine) bye, bastian ___ 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
>> 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. 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
