Re: [OpenWrt-Devel] [PATCH] comgt-ncm: Add possibility to choose PDP context type

[Lars Melin]

On 2015-10-07 04:12, Andreas Fritiofson wrote:


I see the exact same error in the logs and I've verified that E3276
doesn't accept IPV6 (or IPV4V6, or ... ) as the second parameter by
manually echo -e 'AT+CGDCONT=1,"IPV6","internet.tele2.se
",""\r' > /dev/cdc-wdm0. Only "IP" works.



The PDP type IPV6 is only valid for some Huawei firmwares, most likely 
based on what your mobile operator has asked Huawei to include in the

dongles made for them.

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

Re: [OpenWrt-Devel] [PATCH] comgt-ncm: Add possibility to choose PDP context type

[Sami Olmari]

I suspect too that issue isn't ISP having IPv6 or not, as the error comes
instantly in the line... I'd suspect that this option "allows" for IPv6 to
be used, does it fail if no IPv6 is available (in IPV4V6) or not is issue
for further time... So does diffirent NCM-devices possibly have diffirent
option names or no support at all... Who knows... Talk about NCM being
scattered ;(

Sami Olmari
On Oct 7, 2015 10:08, "Lars Melin"  wrote:

> On 2015-10-07 04:12, Andreas Fritiofson wrote:
>
> I see the exact same error in the logs and I've verified that E3276
>> doesn't accept IPV6 (or IPV4V6, or ... ) as the second parameter by
>> manually echo -e 'AT+CGDCONT=1,"IPV6","internet.tele2.se
>> ",""\r' > /dev/cdc-wdm0. Only "IP" works.
>>
>>
> The PDP type IPV6 is only valid for some Huawei firmwares, most likely
> based on what your mobile operator has asked Huawei to include in the
> dongles made for them.
>
> wbr
> Lars
> ___
> 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

[OpenWrt-Devel] [PATCH] lantiq: bugfix luci lantiq_dsl status

[Florian Eckert]

Signed-off-by: Florian Eckert 
Signed-off-by: Helge Mader 
Reported-by: Jo-Philipp Wich 

---

Basically the problem is that the current "lucistatus" code emits
invalid Lua code by providing no value for some  parameters if dsl
is not in showtime mode.

 .../lantiq/base-files/lib/functions/lantiq_dsl.sh  | 50 +++---
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh 
b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
index 8f1d0c2..46f3a17 100755
--- a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
+++ b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
@@ -268,14 +268,14 @@ xtse() {
xtse_s="${xtse1}, ${xtse2}, ${xtse3}, ${xtse4}, ${xtse5}, ${xtse6}, 
${xtse7}, ${xtse8}"
 
if [ "$action" = "lucistat" ]; then
-   echo "dsl.xtse1=$xtse1"
-   echo "dsl.xtse2=$xtse2"
-   echo "dsl.xtse3=$xtse3"
-   echo "dsl.xtse4=$xtse4"
-   echo "dsl.xtse5=$xtse5"
-   echo "dsl.xtse6=$xtse6"
-   echo "dsl.xtse7=$xtse7"
-   echo "dsl.xtse8=$xtse8"
+   echo "dsl.xtse1=${xtse1:-nil}"
+   echo "dsl.xtse2=${xtse2:-nil}"
+   echo "dsl.xtse3=${xtse3:-nil}"
+   echo "dsl.xtse4=${xtse4:-nil}"
+   echo "dsl.xtse5=${xtse5:-nil}"
+   echo "dsl.xtse6=${xtse6:-nil}"
+   echo "dsl.xtse7=${xtse7:-nil}"
+   echo "dsl.xtse8=${xtse8:-nil}"
echo "dsl.xtse_s=\"$xtse_s\""
echo "dsl.annex_s=\"${annex_s}\""
echo "dsl.line_mode_s=\"${line_mode_s}\""
@@ -304,7 +304,7 @@ power_mode() {
esac
 
if [ "$action" = "lucistat" ]; then
-   echo "dsl.power_mode_num=$pm"
+   echo "dsl.power_mode_num=${pm:-nil}"
echo "dsl.power_mode_s=\"$s\""
else
echo "Power Management Mode:$s"
@@ -414,22 +414,22 @@ errors() {
fecn=$(dsl_val "$ccsg" nFEC)
 
if [ "$action" = "lucistat" ]; then
-   echo "dsl.errors_fec_near=$fecn"
-   echo "dsl.errors_fec_far=$fecf"
-   echo "dsl.errors_es_near=$esn"
-   echo "dsl.errors_es_far=$esf"
-   echo "dsl.errors_ses_near=$sesn"
-   echo "dsl.errors_ses_far=$sesf"
-   echo "dsl.errors_loss_near=$lossn"
-   echo "dsl.errors_loss_far=$lossf"
-   echo "dsl.errors_uas_near=$uasn"
-   echo "dsl.errors_uas_far=$uasf"
-   echo "dsl.errors_hec_near=$hecn"
-   echo "dsl.errors_hec_far=$hecf"
-   echo "dsl.errors_crc_p_near=$crc_pn"
-   echo "dsl.errors_crc_p_far=$crc_pf"
-   echo "dsl.errors_crcp_p_near=$crcp_pn"
-   echo "dsl.errors_crcp_p_far=$crcp_pf"
+   echo "dsl.errors_fec_near=${fecn:-nil}"
+   echo "dsl.errors_fec_far=${fecf:-nil}"
+   echo "dsl.errors_es_near=${esn:-nil}"
+   echo "dsl.errors_es_far=${esf:-nil}"
+   echo "dsl.errors_ses_near=${sesn:-nil}"
+   echo "dsl.errors_ses_far=${sesf:-nil}"
+   echo "dsl.errors_loss_near=${lossn:-nil}"
+   echo "dsl.errors_loss_far=${lossf:-nil}"
+   echo "dsl.errors_uas_near=${uasn:-nil}"
+   echo "dsl.errors_uas_far=${uasf:-nil}"
+   echo "dsl.errors_hec_near=${hecn:-nil}"
+   echo "dsl.errors_hec_far=${hecf:-nil}"
+   echo "dsl.errors_crc_p_near=${crc_pn:-nil}"
+   echo "dsl.errors_crc_p_far=${crc_pf:-nil}"
+   echo "dsl.errors_crcp_p_near=${crcp_pn:-nil}"
+   echo "dsl.errors_crcp_p_far=${crcp_pf:-nil}"
else
echo "Forward Error Correction Seconds (FECS):  Near: ${fecn} / 
Far: ${fecf}"
echo "Errored seconds (ES): Near: ${esn} / 
Far: ${esf}"
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] uhttpd: chunked output from cgi script

[Luigi Tarenga]

Hello list,
I'm working on a CGI written in lua and I'm using uhttpd as webserver on 
a tp-link AP.

I'm using external CGI interpreter, not embedded lua.

I need that the output from my CGI is chunked since I would like to 
avoid to buffer the

whole response and calculate the "Content-Length".

I discovered that uhttpd try to send chunked response if the response is 
a normal 200 OK
and the method is a GET. This is my case but unfortunately I ended with 
a strange behavior

where sometimes the GET return with chunked content and sometimes not.

I have an html page that call the CGI with a jquery method:

  $(document).ready(function(){
 $("#catdiv").load("../cgi-bin/board.lua?noheader=1");
  });



the board.lua script return  a piece of html code (without headers and 
footers).

The output of the CGI is always the same between test.

Debugging the http traffic with firefox I see that the GET of board.lua 
take about 33ms
when the output is chunked and 20s (the full keep-alive timeout) when 
the output is not
chunked. I see the response headers and it contain Transfer-Encoding: 
"chunked" directive
in one case on not in the other. From client side everything seems 
correctly following what

the websever gives back.

If I directly call cgi-bin/board.lua it seems to always return in 33ms. 
Debugging the code I came up
with the idea that where there are multiple GET on one http session if 
one GET is solved with
a 204 or 304 that all other GET can't be chunked anymore. In fact my 
html page load other pages

(css, js, etc about 5 GET in one page refresh).

I tried with a simple patch (I'm sure this is not the best solution 
though) that seems to correct

my problem.

--- file.c2015-10-07 15:39:45.169056639 +0200
+++ file.c2015-10-07 15:39:55.859056443 +0200
@@ -807,9 +807,10 @@
 return true;

 d = dispatch_find(url, pi);
-if (d)
+if (d) {
+cl->request.respond_chunked = true;
 uh_invoke_handler(cl, d, url, pi);
-else
+} else
 uh_file_request(cl, url, pi, tb);

 return true;


I would like to know if this have sense, if it has been corrected in 
other uhttpd version or if my patch

broke with some RFC recommendation.

my openwrt version is:
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Chaos Calmer'
DISTRIB_REVISION='r46910'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05'
DISTRIB_TAINTS='no-all no-ipv6'

thank you in advance
Luigi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH][ar71xx] add support for tp-link wr841n v10 image generation

[Daniel Petre]

This adds support to generate images for tp-link wr841n v10 which is almost 
identical with tp-link wr841n v9 but with a faster cpu at 650 Mhz. Tested on a 
european version.

Signed-off-by: Daniel Petre 

--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -529,6 +529,13 @@ define Device/tl-wr841n-v9
 TPLINK_HWID := 0x08410009
 endef
 
+define Device/tl-wr841n-v10
+$(Device/tplink-4mlzma)
+BOARDNAME := TL-WR841N-v9
+DEVICE_PROFILE := TLWR841
+TPLINK_HWID := 0x08410010
+endef
+
 define Device/tl-wr842n-v2
 $(Device/tplink-8mlzma)
 BOARDNAME := TL-WR842N-v2
@@ -549,7 +556,7 @@ define Device/tl-wr847n-v8
 DEVICE_PROFILE := TLWR841
 TPLINK_HWID := 0x08470008
 endef
-TARGET_DEVICES += tl-wr841n-v8 tl-wr841n-v9 tl-wr842n-v2 tl-wr843nd-v1 
tl-wr847n-v8
+TARGET_DEVICES += tl-wr841n-v8 tl-wr841n-v9 tl-wr841n-v10 tl-wr842n-v2 
tl-wr843nd-v1 tl-wr847n-v8
 
 define Device/tl-wr941nd-v5
 $(Device/tplink-4mlzma)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uhttpd: chunked output from cgi script

[Jo-Philipp Wich]

Hi Luigi,

thank you for your patch proposal, it prompted me to take a deeper look
into the problem.

The issue should be fixed with the following commit:

http://nbd.name/gitweb.cgi?p=uhttpd2.git;a=commitdiff;h=7ed2edc40dd6d0171266f3bfbc96466e1d25e3cd


Regards,
Jow



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Jails current broken due to not following symlinks

[Daniel Dickinson]

Hi all,

In Chaos Calmer revision 46996 which bumps procd to latest git breaks 
jails because Etienne's code fails to follow symlinks.


This is a major problem because especially for libraries symlinks are 
what is reported int the ELF header (and for busybox 'binaries', or 
other multicall binaries failure to follow symlinks also fails).


This results in jails failing with ENOENT due to inability to find the 
needed binaries.


Regards,

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

Re: [OpenWrt-Devel] Jails current broken due to not following symlinks

[Daniel Dickinson]

Hi again,

It turns out the problem isn't Etienne's code, it is the fstools update 
in revision 47083.


This causes symlinks to not be followed which breaks procd-jail even 
though the real issue is that procd-jail was in fact only working due to 
broken behaviour.


Regards,

Daniel

On 2015-10-07 11:16 PM, Daniel Dickinson wrote:

Hi all,

In Chaos Calmer revision 46996 which bumps procd to latest git breaks
jails because Etienne's code fails to follow symlinks.

This is a major problem because especially for libraries symlinks are
what is reported int the ELF header (and for busybox 'binaries', or
other multicall binaries failure to follow symlinks also fails).

This results in jails failing with ENOENT due to inability to find the
needed binaries.

Regards,

Daniel

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

Re: [OpenWrt-Devel] Jails current broken due to not following symlinks

[John Crispin]

On 08/10/2015 06:01, Daniel Dickinson wrote:
> Hi again,
> 
> It turns out the problem isn't Etienne's code, it is the fstools update
> in revision 47083.
> 
> This causes symlinks to not be followed which breaks procd-jail even
> though the real issue is that procd-jail was in fact only working due to
> broken behaviour.
> 
> Regards,
> 
> Daniel
> 
> On 2015-10-07 11:16 PM, Daniel Dickinson wrote:
>> Hi all,
>>
>> In Chaos Calmer revision 46996 which bumps procd to latest git breaks
>> jails because Etienne's code fails to follow symlinks.
>>
>> This is a major problem because especially for libraries symlinks are
>> what is reported int the ELF header (and for busybox 'binaries', or
>> other multicall binaries failure to follow symlinks also fails).
>>
>> This results in jails failing with ENOENT due to inability to find the
>> needed binaries.
>>
>> Regards,
>>
>> Daniel
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


wanna be a bit more specific ?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH procd v3 0/7] jail work

[Etienne Champetier]

Hi,

Le 5 oct. 2015 13:49, "Etienne Champetier"  a
écrit :
>
> Hi John,
>
> 2015-10-05 11:14 GMT+02:00 John Crispin :
>>
>>
>>
>> On 27/08/2015 01:26, Etienne CHAMPETIER wrote:
>> > v3 of my (u)jail work, you can now use separately
>> > namespaces jail, capabilities and seccomp
>> >
>> > Openwrt procd Makefile patch v2 is still ok
>>
>>
>>
>> Hi,
>>
>> just merged 1-5, 6 &7 fail to apply, could you rebase them and i will
>> merge them immediately
>>
>> John
>>
>
> it seems you didn't apply patch 5 (jail: add capabilities support):
>
>> $ git pull --rebase
>> remote: Counting objects: 35, done.
>> remote: Compressing objects: 100% (24/24), done.
>> remote: Total 24 (delta 17), reused 0 (delta 0)
>> Unpacking objects: 100% (24/24), done.
>> From git://nbd.name/luci2/procd
>>b6618ff..fafbf73  master -> origin/master
>> First, rewinding head to replay your work on top of it...
>> Applying: jail: add capabilities support
>> Applying: jail: cleanup include
>> Applying: jail: allow to not use namespaces
>
>
>
> patchwork.ozlabs.org/bundle/champtar/jail-work-v3/?state=*
>

Friendly ping,
Please apply my patches so future fixes are on top of my work

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

Re: [OpenWrt-Devel] Jails current broken due to not following symlinks

[Daniel Dickinson]

Ok, I thought I had found the root cause but all I'm left with is that 
symlinks aren't followed.


That is when procd-jail is installed and using procd_add_jail (or 
manually executing ujail) on x86_64 using squashfs, on (for example) 
/usr/sbin/ntpd (which is a symlink to /bin/busybox), then in syslog you 
get (assuming you have correctly included all config/pid files that ntpd 
depends on):


Thu Oct  8 06:33:12 2015 user.err syslog: jail: failed to spawn child 
/usr/sbin/ntpd: No such file or directory


Using strace I see that the mounts are occuring correctly and the 
necessary files are found, but execve of /usr/sbin/ntpd returns ENOENT.


I took a closer look and realized that e.g. /bin/busybox and the actual 
libraries that are the target of the so versions listed by ldd (i.e. the 
so versions points to a symlink which points to the actual fully 
verisoned so, such as the uClibc dependencies of busybox) were not being 
mounted.


I added the targets of the symlinks to procd_add_jail_mount and lo and 
behold the jailed daemon started correctly.


In short, at least on x86_64 with squashfs rootfs the symlinks are not 
being followed.


The behaviour was correct on previous version of Chaos Calmer (release 
commit) on ar71xx and it was not necessary to add the symlink targets to 
procd_jail_mount in that case.


Regards,

Daniel

On 2015-10-08 2:18 AM, John Crispin wrote:



On 08/10/2015 06:01, Daniel Dickinson wrote:

Hi again,

It turns out the problem isn't Etienne's code, it is the fstools update
in revision 47083.

This causes symlinks to not be followed which breaks procd-jail even
though the real issue is that procd-jail was in fact only working due to
broken behaviour.

Regards,

Daniel

On 2015-10-07 11:16 PM, Daniel Dickinson wrote:

Hi all,

In Chaos Calmer revision 46996 which bumps procd to latest git breaks
jails because Etienne's code fails to follow symlinks.

This is a major problem because especially for libraries symlinks are
what is reported int the ELF header (and for busybox 'binaries', or
other multicall binaries failure to follow symlinks also fails).

This results in jails failing with ENOENT due to inability to find the
needed binaries.

Regards,

Daniel

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



wanna be a bit more specific ?
___
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