Re: [LEDE-DEV] [PATCH v3] busybox: update to 1.27.1

[Bastian Bittorf]

* Magnus Kroken  [08.08.2017 18:23]:
> Refresh patches, delete patches backported from upstream.
> 
> Signed-off-by: Magnus Kroken 
> ---
> v2: Delete 120-remove_uclibc_rpc_check.patch as well,
> as suggested by Baptiste Jonglez. Also rework changes in
> Config-defaults.in, so lines that are simply reordered
> are not touched, to make the patch more readable.
> 
> v3: Actually update configs as well.

please also remove 
"501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch"
(see LEDE commit dde9da46c1586c0bda54e7fa6de05f0fc76e557a)
this should be included already in the 1.27.1 release...

bye, bastian

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

[LEDE-DEV] [PATCH] busybox: ash/hush fix for read-builtin command

[Bastian Bittorf]

this is a cherrypick from busybox-git HEAD:
f5470419404d643070db99d058405b714695b817

and can be removed when upgrading to
next busybox release. discussion here:
http://lists.busybox.net/pipermail/busybox/2017-May/085439.html

Signed-off-by: Bastian Bittorf <b...@npl.de>
---
 ...ush-fix-SIGCHLD-interrupting-read-builtin.patch | 147 +
 1 file changed, 147 insertions(+)
 create mode 100644 
package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch

diff --git 
a/package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch
 
b/package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch
new file mode 100644
index 000..1386dad
--- /dev/null
+++ 
b/package/utils/busybox/501-ash-hush-fix-SIGCHLD-interrupting-read-builtin.patch
@@ -0,0 +1,147 @@
+From f5470419404d643070db99d058405b714695b817 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko <vda.li...@googlemail.com>
+Date: Mon, 22 May 2017 19:34:45 +0200
+Subject: [PATCH] ash,hush: fix SIGCHLD interrupting read builtin
+
+function old new   delta
+readcmd  169 217 +48
+shell_builtin_read  10871097 +10
+localcmd 366 364  -2
+builtin_read 197 193  -4
+--
+(add/remove: 0/0 grow/shrink: 2/2 up/down: 58/-6)  Total: 52 bytes
+
+Signed-off-by: Denys Vlasenko <vda.li...@googlemail.com>
+Signed-off-by: Bastian Bittorf <b...@npl.de>
+---
+ shell/ash.c  |  7 +++
+ shell/ash_test/ash-read/read_SIGCHLD.right   |  2 ++
+ shell/ash_test/ash-read/read_SIGCHLD.tests   |  4 
+ shell/hush.c |  5 -
+ shell/hush_test/hush-read/read_SIGCHLD.right |  2 ++
+ shell/hush_test/hush-read/read_SIGCHLD.tests |  4 
+ shell/shell_common.c | 20 +++-
+ 7 files changed, 34 insertions(+), 10 deletions(-)
+ create mode 100644 shell/ash_test/ash-read/read_SIGCHLD.right
+ create mode 100755 shell/ash_test/ash-read/read_SIGCHLD.tests
+ create mode 100644 shell/hush_test/hush-read/read_SIGCHLD.right
+ create mode 100755 shell/hush_test/hush-read/read_SIGCHLD.tests
+
+diff --git a/shell/ash.c b/shell/ash.c
+index 70ee15e..60c8ffe 100644
+--- a/shell/ash.c
 b/shell/ash.c
+@@ -13268,6 +13268,7 @@ readcmd(int argc UNUSED_PARAM, char **argv 
UNUSED_PARAM)
+   /* "read -s" needs to save/restore termios, can't allow ^C
+* to jump out of it.
+*/
++ again:
+   INT_OFF;
+   r = shell_builtin_read(setvar0,
+   argptr,
+@@ -13280,6 +13281,12 @@ readcmd(int argc UNUSED_PARAM, char **argv 
UNUSED_PARAM)
+   );
+   INT_ON;
+ 
++  if ((uintptr_t)r == 1 && errno == EINTR) {
++  /* to get SIGCHLD: sleep 1 & read x; echo $x */
++  if (pending_sig == 0)
++  goto again;
++  }
++
+   if ((uintptr_t)r > 1)
+   ash_msg_and_raise_error(r);
+ 
+diff --git a/shell/ash_test/ash-read/read_SIGCHLD.right 
b/shell/ash_test/ash-read/read_SIGCHLD.right
+new file mode 100644
+index 000..b3dc7ab
+--- /dev/null
 b/shell/ash_test/ash-read/read_SIGCHLD.right
+@@ -0,0 +1,2 @@
++x='Ok'
++exitcode:0
+diff --git a/shell/ash_test/ash-read/read_SIGCHLD.tests 
b/shell/ash_test/ash-read/read_SIGCHLD.tests
+new file mode 100755
+index 000..c5f673a
+--- /dev/null
 b/shell/ash_test/ash-read/read_SIGCHLD.tests
+@@ -0,0 +1,4 @@
++x=BAD
++{ sleep 0.4; echo Ok; } | { sleep 0.2 & read x; echo "x='$x'"; }
++echo "exitcode:$?"
++
+diff --git a/shell/hush.c b/shell/hush.c
+index e18920f..125463a 100644
+--- a/shell/hush.c
 b/shell/hush.c
+@@ -9038,6 +9038,9 @@ static int FAST_FUNC builtin_type(char **argv)
+  * - terminates shell (regardless of interactivity);
+  * if it has non-empty trap:
+  * - executes trap and returns to read;
++ * SIGCHLD from children:
++ * - does not interrupt read regardless of interactivity:
++ *   try: sleep 1 & read x; echo $x
+  */
+ static int FAST_FUNC builtin_read(char **argv)
+ {
+@@ -9071,7 +9074,7 @@ static int FAST_FUNC builtin_read(char **argv)
+ 
+   if ((uintptr_t)r == 1 && errno == EINTR) {
+   unsigned sig = check_and_run_traps();
+-  if (sig && sig != SIGINT)
++  if (sig != SIGINT)
+   goto again;
+   }
+ 
+diff --git a/shell/hush_test/hush-read/read_SIGCHLD.right 
b/shell/hush_test/hush-read/read_SIGCHLD.right
+new file mode 100644
+index 000..b3dc7ab
+--- /dev/null
 b/shell/hush_test/hush-read/read_SIGCHLD.right
+@@ -0,0 +1,2 @@
++x='Ok'
++exitcode:0
+diff --git a/shell/hush_test/hush-read/re

Re: [LEDE-DEV] dropbear & gcc 7.1.0

[Bastian Bittorf]

* Syrone Wong  [29.05.2017 10:03]:
> > have you tried to '/etc/init.d/dropbear'?
> 
> The problem is you cannot access the router, which means you cannot
> execute any commands.

ok, maybe you can execute a command with LuCI?
(i'am not familiar with LuCI)
maybe you can try serial console.
maybe you can put that into /etc/rc.local

i wanted to write: '/etc/init.d/dropbear restart', sorry for that.

bye, bastian

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

Re: [LEDE-DEV] dropbear & gcc 7.1.0

[Bastian Bittorf]

* e9hack  [29.05.2017 08:59]:
> if I select gcc 7.1.0 instead of gcc 6.3.0, anything seems to be work with 
> exception of dropbear (and a few build fixes
> for some packages are necessary). Dropbear is running, but it isn't possible 
> to connect. The message from WinSCP is
> 'Network error: Connection to "wlan-xyz" refused' or from PuTTY 'Network 
> error: connection refused'. If I copy the
> dropbear image from a previous build with gcc 6.3.0 to the router, it's 
> possible to connect with PuTTY and WinSCP. This
> problem occurs for three builds: TP-Link Archer C7, TP-Link wdr3600 and 
> 8devices carambola. All are using as target the
> ar71xx platform.
> 
> Any ideas?

i have also seen this on a lot of routers:
have you tried to '/etc/init.d/dropbear'?
it seems to work around this problem here,
but i do not fully understand it for now...

bye, bastian

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

Re: [LEDE-DEV] [PATCH usbmode] fix indices of messages

[Bastian Bittorf]

* Julian Labus  [19.05.2017 07:29]:
> to me it looks like LEDE has its own implementation of usb-modeswitch
> and only uses usb-modeswitch-data from the upstream project or is this
> just a mirror?
> 
> https://git.lede-project.org/?p=project/usbmode.git

You are totally right. I was confused bye the Makefile,
which loads "usb-modeswitch-data"* from draisberghof.de - sorry.

bye, bastian

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

Re: [LEDE-DEV] [PATCH usbmode] fix indices of messages

[Bastian Bittorf]

* Julian Labus  [18.05.2017 20:16]:
> the way how the script checked if a key already exists in a hash
> leads to wrong indices for %messages.
> 
> Signed-off-by: Julian Labus 
> ---
>  convert-modeswitch.pl | 9 +

thanks for your patch.
it seems you must send your patch upstream:
http://www.draisberghof.de/usb_modeswitch

lede does only use this package.

bye, bastian

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

Re: [LEDE-DEV] [PATCH v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [15.05.2017 09:27]:
> > +   [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> 
> thanks for the patch!
> 
> please test for 'bool_true' not for 1

sorry for the noise, this is already normalized by
config_get_bool() - so testing for 0 or 1 is fine.

bye, bastian

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

Re: [LEDE-DEV] [PATCH v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

[Bastian Bittorf]

* Paul Oranje  [15.05.2017 09:08]:
> fixes FS#785
> v1: write /tmp/resolv.conf also when nosolv is true
> v2: also change guard in dnsmasq_stop() routine
> 
> Signed-off-by: Paul Oranje 
> ---
>  package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 30fec7a4ee..c7506ed4ea 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -947,7 +947,7 @@ dnsmasq_start()
>   echo >> $CONFIGFILE_TMP
>   mv -f $CONFIGFILE_TMP $CONFIGFILE
>  
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {

thanks for the patch!

please test for 'bool_true' not for 1
also: should'nt it be 'noresolv'?

bye, bastian

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

Re: [LEDE-DEV] [PATCH 1/5] base-files: introduce /lib/functions/board.sh

[Bastian Bittorf]

* Felix Fietkau  [30.04.2017 09:30]:
> > +board_name()
> > +{
> > +   sysinfo board_name
> > +}
> > +
> > +board_model()
> > +{
> > +   sysinfo model
> > +}

> Do we really need board_model() at all? I think it's better to leave the
> board_name() function where it is instead of adding this extra include file.

the difference is that:

# root@box:~ cat /tmp/sysinfo/model 
# TP-Link TL-WDR4300 v1
# root@box:~ cat /tmp/sysinfo/board_name 
# tl-wdr4300

we use 'model' e.g. for our monitoring.

bye, bastian

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

[LEDE-DEV] rb532 / install to NAND

[Bastian Bittorf]

i'am having problems getting NAND to work.
i can boot r3979 from compact flash without problems and do:

# sysupgrade -n lede-rb532-nand-squashfs-sysupgrade.bin
(and hope it writes to nand, so i can remove the CF-card)

it looks good so far:
root@LEDE:~# sysupgrade -n /tmp/lede-rb532-nand-squashfs-sysupgrade.bin
UBI device number 0, total 960 LEBs (123863040 bytes, 118.1 MiB), available 0 
LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
ssh: Connection to root@fe80::20c:42ff:fe0a:f4bb%eth0.2:22 exited: Remote 
closed the connection


but according to the leds it reboots every second.
what is a known way to migrate to NAND?

bye, bastian

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

[LEDE-DEV] [PATCH] dnsmasq: fix uninitialized varname in init-script

[Bastian Bittorf]

minor/cosmetic: fixes the following misleading message:

root@box:~ /etc/init.d/dnsmasq restart
sh: out of range

Signed-off-by: Bastian Bittorf <b...@npl.de>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 83553f1..448d3ee 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -698,7 +698,7 @@ dnsmasq_start()
 
if [ -x /usr/sbin/odhcpd -a -x /etc/init.d/odhcpd ] ; then
local odhcpd_is_main odhcpd_is_enabled
-   config_get odhcpd_is_main odhcpd maindhcp
+   config_get odhcpd_is_main odhcpd maindhcp 0
/etc/init.d/odhcpd enabled && odhcpd_is_enabled=1 || 
odhcpd_is_enabled=0
 
 
-- 
1.9.1


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

Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency

[Bastian Bittorf]

* James Feeney  [29.03.2017 10:15]:
> Let me say again, I think that this is an important issue that the LEDE 
> project
> needs to address and remedy.  I believe that the ultimate credibility and
> reputation of the LEDE project is at stake.

what we do "internally":

checkout LEDE and all feeds at a specific timestamp.
Maybe thats an option for you too.

bye, bastian

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

Re: [LEDE-DEV] Kodi

[Bastian Bittorf]

* Stijn Tintel  [15.03.2017 10:03]:
> work on Raspberry Pi. My main question now is: is there any interest in
> having Kodi for LEDE at all, or should I not bother preparing it for
> submission.

i like it...any repo where we can see your changes?

bye, bastian

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

Re: [LEDE-DEV] [PATCH] mac80211: Fix race condition leading to wifi interfaces not coming up at boot sometimes.

[Bastian Bittorf]

* Vittorio Gambaletta (VittGam)  [14.03.2017 07:55]:
> +mac80211_iw_interface_add() {
> + local phy="$1"
> + local ifname="$2"
> + local type="$3"
> + local wdsflag="$4"

please add a 'local ret' here, or better use the common 'local rc=0'
and later always "return $rc"

> +
> + iw phy "$phy" interface add "$ifname" type "$type" $wdsflag
> + ret="$?"
> +
> + [ "$ret" = 233 ] && {
> + # Device might have just been deleted, give the kernel some 
> time to finish cleaning it up
> + sleep 1
> +
> + iw phy "$phy" interface add "$ifname" type "$type" $wdsflag
> + ret="$?"
> + }
> +
> + [ "$ret" != 0 ] && {
> + wireless_setup_failed INTERFACE_CREATION_FAILED
> + return 1
> + }
> +
> + return 0
> +}

thank you for debugging this! bye, bastian

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

Re: [LEDE-DEV] [RFC] au1000: drop support / serial console

[Bastian Bittorf]

* Bruno Randolf  [09.03.2017 14:15]:
> The connector is on the second picture 
> (http://intercity-vpn.de/files/openwrt/au1000/.800/.html/IMG_20170309_085751.jpg.html),
> above the 4G logo. It's actually a 24 pin connector. I updated the
> wiki.

thanks a lot, it works. will dig deeper, something is wrong here now.
i have seen a booting 4.9.13 kernel, but now it...:

YAMON> load /ram.srec
About to load tftp://192.168.0.100/ram.srec
Press Ctrl-C to break






Start = 0x810001c0, range = (0x8100,0x8119e7a7), format = SREC
YAMON> go 0x810001c0 

* Exception (user) : Bus error (instruction fetch) *

CAUSE= 0x00808018  STATUS   = 0x0002
EPC  = 0x9000  ERROREPC = 0x
BADVADDR = 0x9dffed9b

$ 0(zr):0x  $ 8(t0):0x0000  $16(s0):0x80004000 $24(t8):0x
$ 1(at):0x  $ 9(t1):0x001f  $17(s1):0x80004000 $25(t9):0x
$ 2(v0):0x8010  $10(t2):0x0010  $18(s2):0x0020 $26(k0):0x
$ 3(v1):0x  $11(t3):0x0800  $19(s3):0x0020 $27(k1):0x
$ 4(a0):0x0001  $12(t4):0x800e0662  $20(s4):0x4000 $28(gp):0x
$ 5(a1):0x80082920  $13(t5):0x80082920  $21(s5):0x0080 $29(sp):0x800fff90
$ 6(a2):0x80044838  $14(t6):0x80044838  $22(s6):0x $30(s8):0x8008ca44
$ 7(a3):0x0400  $15(t7):0x0400  $23(s7):0x $31(ra):0x8100019c

YAMON>

need some distance 8-)
btw: i think only the ethernet-driver has probs...

bye, bastian 

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

Re: [LEDE-DEV] [RFC] au1000: drop support / serial console

[Bastian Bittorf]

* Florian Fainelli  [09.03.2017 08:36]:
> Is that already a compressed kernel, seems like you could easily get it
> down to 1-2MiB with compression.

at the moment i have problems finding the real serial pinout.
(YAMON is not enough at this stage). I uploaded 7 pictures here:
http://intercity-vpn.de/files/openwrt/au1000/

the wiki says that the "T-Mobile Internet Box" has a 10 pin-connector
near the Ethernet port, but I can not spot it.
https://wiki.openwrt.org/toh/4g.systems/access.cube#serial_and_jtag

bye, bastian

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

Re: [LEDE-DEV] [RFC] au1000: drop support

[Bastian Bittorf]

* Florian Fainelli  [09.03.2017 08:36]:
> > partition size, which is 44 blocks and ~2816 kilobytes. Our kernel
> > is around 3,3mb...ofcourse i can reduce the size, is that an option
> > for that target?
> 
> Is that already a compressed kernel, seems like you could easily get it
> down to 1-2MiB with compression.

You are right, and I was confused be the size of the .srec file.
Will do further experiments today...the kernel IS compressed, but
the .srec-format bloats it up - it seems, that YAMON refused to
upload .srec-files for the kernel which are >3.1mb - never mind,
i will report.

bye, bastian

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

Re: [LEDE-DEV] [RFC] au1000: drop support

[Bastian Bittorf]

* John Crispin  [26.02.2017 20:20]:
> ok, send your v4.9 series when it is ready.

after some trial and error: the (ram-)kernel boots without issues,
but flashing is not possible, because we have only 0x2c kernel
partition size, which is 44 blocks and ~2816 kilobytes. Our kernel
is around 3,3mb...ofcourse i can reduce the size, is that an option
for that target?

bye, bastian

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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [07.03.2017 11:07]:
> * Tino Reichardt <list-l...@mcmilk.de> [06.03.2017 08:24]:
> > BE AWARE:
> > My patch seems to work fine, even the dsl modem seems to be correctly
> > loaded. But it's not tested currently... so please do not flash your
> > modems, when they are needed currently ;)
> 
> Impressive! i will check if pppoe works later and report.

it seems, that the modem is not initialised correctly,
there is e.g. no blinking of the led and 'nas0' will not
come up and so no pppoe...if somebody has an idea, i can test.

bye, bastian

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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Tino Reichardt  [06.03.2017 08:24]:
> BE AWARE:
> My patch seems to work fine, even the dsl modem seems to be correctly
> loaded. But it's not tested currently... so please do not flash your
> modems, when they are needed currently ;)

Impressive! i will check if pppoe works later and report.
here a small walktrough when unboxing and reflashing a thing:

# telnet with root/admin into original firmware...:

BusyBox v1.00 (2012.03.02-08:09+) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# killall dsl_cpe_control
# ps
  PID  Uid VmSize Stat Command
1 root336 S   init
2 rootSW  [keventd]
3 rootSWN [ksoftirqd_CPU0]
4 rootSW  [kswapd]
5 rootSW  [bdflush]
6 rootSW  [kupdated]
7 rootSW  [swapper]
8 rootSW  [mtdblockd]
   18 root 60 S   /usr/sbin/swreset
  137 root296 S   /sbin/syslogd -s 8 -b 2 -l 8
  186 rootSW  [autbtex]
  187 rootSW  [atm_led_complet]
  188 rootSW  [pmex_ne]
  191 rootSW  [pmex_fe]
  854 root232 S   ./devm
  855 root   1000 S   /usr/sbin/devmapp
  905 root320 S   /usr/sbin/inetd /etc/inetd.conf
 1044 root328 S   /sbin/getty 115200 ttyS0
 1207 root304 S   /usr/sbin/br2684ctld
 1249 root364 S   /usr/sbin/dnrd
 1332 root300 S   telnetd
 1333 root312 S   -sh
 1335 root336 R   ps

# cd /ramdisk/tftp_upload

# tftp -g -r uImage 172.16.1.1
# tftp -g -r flashwrite 172.16.1.1
# tftp -g -r fw_setenv 172.16.1.1
# tftp -g -r fw.conf 172.16.1.1
# ln -s fw_setenv fw_printenv
# chmod +x *

# ls -l
-rwxr-xr-x1 root root38200 Mar  2 16:44 flashwrite
-rwxr-xr-x1 root root  972 Mar  2 16:44 fw.conf
lrwxrwxrwx1 root root9 Mar  2 16:44 fw_printenv -> fw_setenv
-rwxrwxrwx1 root root58012 Mar  2 16:44 fw_setenv
-rwxr-xr-x1 root root  2883758 Mar  2 16:42 uImage

# ./fw_setenv disable_recovery y
[crc0 data:3d744984 flash:3d744984!]

# ./fw_setenv kernel_addr 0xb001
[crc0 data:  9b028f flash:  9b028f!]

# ./flashwrite /dev/mtd/1 uImage 0
Performing Flash Erase of length 65536 at offset 0
Performing Flash Erase of length 65536 at offset 65536
Performing Flash Erase of length 65536 at offset 131072
Performing Flash Erase of length 65536 at offset 196608
Performing Flash Erase of length 65536 at offset 262144
Performing Flash Erase of length 65536 at offset 327680
Performing Flash Erase of length 65536 at offset 393216
Performing Flash Erase of length 65536 at offset 458752
Performing Flash Erase of length 65536 at offset 524288
Performing Flash Erase of length 65536 at offset 589824
Performing Flash Erase of length 65536 at offset 655360
Performing Flash Erase of length 65536 at offset 720896
Performing Flash Erase of length 65536 at offset 786432
Performing Flash Erase of length 65536 at offset 851968
Performing Flash Erase of length 65536 at offset 917504
Performing Flash Erase of length 65536 at offset 983040
Performing Flash Erase of length 65536 at offset 1048576
Performing Flash Erase of length 65536 at offset 1114112
Performing Flash Erase of length 65536 at offset 1179648
Performing Flash Erase of length 65536 at offset 1245184
Performing Flash Erase of length 65536 at offset 1310720
Performing Flash Erase of length 65536 at offset 1376256
Performing Flash Erase of length 65536 at offset 1441792
Performing Flash Erase of length 65536 at offset 1507328
Performing Flash Erase of length 65536 at offset 1572864
Performing Flash Erase of length 65536 at offset 1638400
Performing Flash Erase of length 65536 at offset 1703936
Performing Flash Erase of length 65536 at offset 1769472
Performing Flash Erase of length 65536 at offset 1835008
Performing Flash Erase of length 65536 at offset 1900544
Performing Flash Erase of length 65536 at offset 1966080
Performing Flash Erase of length 65536 at offset 2031616
Performing Flash Erase of length 65536 at offset 2097152
Performing Flash Erase of length 65536 at offset 2162688
Performing Flash Erase of length 65536 at offset 2228224
Performing Flash Erase of length 65536 at offset 2293760
Performing Flash Erase of length 65536 at offset 2359296
Performing Flash Erase of length 65536 at offset 2424832
Performing Flash Erase of length 65536 at offset 2490368
Performing Flash Erase of length 65536 at offset 2555904
Performing Flash Erase of length 65536 at offset 2621440
Performing Flash Erase of length 65536 at offset 2686976
Performing Flash Erase of length 65536 at offset 2752512
Performing Flash Erase of length 65536 at offset 2818048
Performing Flash Erase of length 65536 at offset 2883584
Writing the firmware of length 2883758 at 0...

[LEDE-DEV] Q: bad longshot: iw dev wlanX station dump - what is: "rx drop misc:"

[Bastian Bittorf]

I have a bad performing "longshot" (~10 meters):
both sides with recent LEDE, one 1043ND and one WDR4300 on 2.4GHz.

The link performs bad, although the values seem OK:

# iw dev wlan0 station dump (on 1043ND)
Station 64:70:02:d3:24:0b (on wlan0)
inactive time:  0 ms
rx bytes:   1856328043
rx packets: 3090925
tx bytes:   1529873286
tx packets: 2423239
tx retries: 433117
tx failed:  809
rx drop misc:   28492
signal: -60 [-67, -63, -66] dBm
signal avg: -59 [-66, -62, -65] dBm
tx bitrate: 117.0 MBit/s MCS 14
rx bitrate: 130.0 MBit/s MCS 15
expected throughput:42.388Mbps
authorized: yes
authenticated:  yes
associated: yes
preamble:   long
WMM/WME:yes
MFP:no
TDLS peer:  no
DTIM period:0
beacon interval:1000
connected time: 229269 seconds

# iw dev wlan0 station dump (on WDR4300)
Station f4:ec:38:9d:81:82 (on wlan0)
inactive time:  150 ms
rx bytes:   113057100
rx packets: 318848
tx bytes:   172204259
tx packets: 248059
tx retries: 25208
tx failed:  322
rx drop misc:   892
signal: -57 [-60, -60] dBm
signal avg: -52 [-58, -56] dBm
tx bitrate: 130.0 MBit/s MCS 15
rx bitrate: 104.0 MBit/s MCS 13
expected throughput:44.677Mbps
authorized: yes
authenticated:  yes
associated: yes
preamble:   long
WMM/WME:yes
MFP:no
TDLS peer:  no
DTIM period:0
beacon interval:1000
connected time: 31557 seconds

Both sides have set on 2.4GHz with channel 14:
wireless.radio0.chanbw=5
wireless.radio0.txpower=20

The question: what is "rx drop misc"?
I have a packetloss of ~20%. Any idea why that?

bye, bastian 

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

Re: [LEDE-DEV] [RFC] au1000: drop support

[Bastian Bittorf]

* John Crispin  [26.02.2017 16:18]:
> This target failed to boot with v4.4 and we did not have the hardware to
> test. Bruno and myself were the last users and neither of us has any future

I have 50 of them and will try to get some serial output, what is wrong this 
week.

bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* David Lang  [25.02.2017 20:11]:
> The kernel already includes facilities for signing modules, if you
> are looking for a way to sign and verify things, it seems like it
> would make sense to adapt that to sign the entire image.

It is not about signing the image/modules, but giving a "thrustable"
feedback to the download-server, that image_XYZ was successfully flashed.

Sorry, that I have mixed up the words somehow (or my description was
not good enough)

bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Felix Fietkau  [25.02.2017 14:50]:
> > root@LEDE:~ :) usign -B
> > 98021604736550012081493806018992642304441039324849310980174888200312941028157
> > 114543661949658574850110716953530268394806126479026079327889534650057251922973
> I think patching something existing like usign does not make any sense,
> you're only creating extra maintenance work for yourself.
> You should make a separate small binary for it...

you are right, i just needed a fast hack.
The like the idea of Michael Richardson: just export it
to userspace via the kernel-commandline. I have to think
about both approaches...

Thanks for your input! - bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Michael Richardson  [24.02.2017 19:00]:
> 2) call the first 16 bytes the build-identifier, base64 it. Or perhaps
>bubble-babble it, and show it to the user, etc. as the recognizable
>build name.

the 'bubble-babble' thing is really interesting:
http://bohwaz.net/archives/web/Bubble_Babble.html

We will discuss it...i think it is unneeded here, because it's
a mostly (if not full) automated way, but it can make sense for
other things - just wanted to underline it.

bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Michael Richardson  [24.02.2017 19:00]:
> >> Anyone can multiply two large prime numbers to get the solution.
> 
> > oh, i was thinking that when you have a large number, e.g.
> > 
> 11542007683190179498670464887074061547264589525228033835453784092033868174972196125349942808504088511053804942426194431961451801392254016733776993893835781
> 
> > you can not easily say what the 2 prime factors are to get this result?
> > Or is this really a "fast" cumputation?
> 
> That's the essence of assymetric cryptographic algorithms, yes.
> But, you don't want to create your own, because there are subtlies which
> matter.  And I don't think you used this mechanism right.  If you really want
> to go this way, and can assume you have libssl around, then it will let
> do a signature rather easily.

i use openssl for that:

 #!/bin/sh
 PRIME1=$(openssl prime -generate -bits 256)
 PRIME2=$(openssl prime -generate -bits 256)

The product of these 2 primes factors is stored for each image on
the download-server and public - see field "code_proof_of_boot":
http://intercity-vpn.de/networks/liszt28/firmware/models/Mikrotik%20Routerboard%20532/testing/Standard,kalua/info.json

bye, bastian

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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Tino Reichardt  [24.02.2017 16:26]:
> Hidden Webinterface on default Firmware: http://172.16.1.254:8235/, with
> user "admin" and password: "coolwhite"

really ugly + HTML v0.9 - i found now:
advanced settings -> system -> firmware -> upgrade

bye, bastian

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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Tino Reichardt  [24.02.2017 16:26]:
> Telnet on Port 23 is also there. I will check, if it can be upgraded via
> telnet or webinterface.

user: root
pass: admin

cool!

# cat /etc/inetd.conf
tftpdgram   udp waitroottftpifxftp  -   -
/usr/bin/tftpd  /usr/bin/tftpd -I -d /ramdisk/tftp_upload
telnet  stream  tcp waitroottelnet  ifxrcon -   -
/usr/sbin/telnetd   telnetd
httpd   stream tcp wait root httpd ifxhttpd - - /usr/sbin/httpd httpd -h
/usr/web -H /usr/cli -A httpd
/tmp/cli_be_socket stream unix wait root httpd ifxhttpd - -
/usr/sbin/httpd httpd -h /usr/web -H /usr/cli -A cli
/tmp/cli_fe_socket stream unix wait root cli ifxcli - - /usr/sbin/cli_be

# cat /proc/mtd
dev:size   erasesize  name
mtd0: 0001 2000 "U-Boot"
mtd1: 003f 0001 "RootFS,Kernel,Data,Environment"

there is an interesting binary:

# upgrade --help
Usage : upgrade file_name image_type expand_direction saveenv_copy
[reboot]
ToolChain:lxdb-1-3-2/3.3.6/0.9.28
Version:1.0.5

there are also /bin/busybox + /bin/busybox2 which has httpd + tftpd,
so uploading an image should be possible 8-) weekend-hacking!

bye, bastian 


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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Tino Reichardt  [24.02.2017 16:26]:
> Hidden Webinterface on default Firmware: http://172.16.1.254:8235/, with
> user "admin" and password: "coolwhite"

indeed! the webif suggests, that there is a TFTP service running.
do you know the Telnet pass?

bye, bastian

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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Tino Reichardt  [24.02.2017 13:30]:
> I have created a small homepage for the patch, it is located here:
> https://mcmilk.de/projects/all0333cj/

the only way flashing it, is using a serial line?

bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Michael Richardson  [24.02.2017 09:03]:
> > large random primenumbers. On the serverside, we store the product
> > (aka: solution) of these 2 numbers. This is repeated for each generated
> > image. (sorry, it breaks reproducable builds for now)
> 
> Anyone can multiply two large prime numbers to get the solution.

oh, i was thinking that when you have a large number, e.g.
11542007683190179498670464887074061547264589525228033835453784092033868174972196125349942808504088511053804942426194431961451801392254016733776993893835781

you can not easily say what the 2 prime factors are to get this result?
Or is this really a "fast" cumputation?

> So I can't understand what you are doing.
> You can't hide things in binaries.  That's total snake oil.

It is, it's only about having a proof, that the image runs.
If several people "say" that the image runs, other routers start
to automatically flash it. I want to make sure, that nobody can
fake that information it easily.

> I thought from the subject line and explanation that it was to permit a
> firmware image to be validated as being uncorrupted/tained.  One might do
> this before flashing a device with it.

how should this be done before flashing?
if there is a mistake (e.g. forgotten package during build) the
image itself is fine, but not "good".

> Now I get the impression that the idea for a user to be able to prove
> which firmware image they actually used?

yes, if the image boots fine the user/a script will send
the 'secret' and an sha256_signature if the image-hash.
These hashes are added to the info.json:
http://intercity-vpn.de/networks/liszt28/firmware/models/Buffalo%20WZR-HP-AG300H/testing/Standard,DSLR,fotobox,kalua/info.json
(see: 'bittorf').

Other users have installed my public.key and can so check the signature.
Also to flag "firmware_manually_checked" is changed to 'true'.

bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Eric Schultz  [23.02.2017 07:57]:
> prpl member IntrinsicID has physically unclonable function technology which
> allows a key to be generated at bootup based upon the physical
> characteristics of the device. It's the same key generated everytime but it

this is not what i'am looking for: IntrinsicID seems like a hash based
on the specific hardware/board. I need an ID (a prove), that the used runs
(=has successfully flashed) a specific image.

bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Michael Richardson <m...@sandelman.ca> [23.02.2017 07:57]:
> Yes, use an asymmetric key, and distribute the public part only.

thanks people, for all the input and your ideas. our approach
is now this: we hook into the 'usign' sourcecode and "hide" a
secret there: 2 large random primenumbers. On the serverside,
we store the product (aka: solution) of these 2 numbers. This
is repeated for each generated image. (sorry, it breaks reproducable
builds for now)

The user can prove that he flashed *the specific* image by
calling 'usign -B' and send back the 2 primenumbers to the build-server.
There are some more implications, but basically thats it.

I recognized early, that including a 'quine' is senseless, because
you can read it in plaintext in the object-dump.

I'am not an expert in crypto, but as far as I understand
the approach is an asymetric key. I'am interested in feedback, see
the patch attached.

bye, bastian
>From bbd520f1ee96f2876a7dfd8ad14ba0445ed1abea Mon Sep 17 00:00:00 2001
From: Bastian Bittorf <b...@npl.de>
Date: Thu, 23 Feb 2017 08:16:28 +0100
Subject: [PATCH] usign: support new option '-B': print a secret which was
 included during build

we MUST patch the sourcecode (string PRIME1/PRIME2) before compiling:
we need to include two large random primenumbers, like:

 #!/bin/sh
 P1=$(openssl prime -generate -bits 256)
 P2=$(openssl prime -generate -bits 256)
 sed -e "s/PRIME1/\"$P1\"/" -e "s/PRIME2/\"$P2\"/" main.c

after that, a user can prove that he knows the
solution (two prime factors) to a serverside stored "product",
which is generated for each image, so the user can prove,
that he really flashed the image, and that it works.

Signed-off-by: Bastian Bittorf <b...@npl.de>
---
 main.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/main.c b/main.c
index 3536443..84aa4c1 100644
--- a/main.c
+++ b/main.c
@@ -334,6 +334,7 @@ static int usage(const char *cmd)
 		"  -S:			sign (needs at least -m and -s)\n"
 		"  -F:			print key fingerprint of public/secret key or signature\n"
 		"  -G:			generate a new keypair (needs at least -p and -s)\n"
+		"  -B:			show a secret, which was included during build\n"
 		"Options:\n"
 		"  -c : 	add comment to keys\n"
 		"  -m :		message file\n"
@@ -360,8 +361,11 @@ int main(int argc, char **argv)
 	const char *msgfile = NULL;
 	int ch;
 
-	while ((ch = getopt(argc, argv, "FGSVc:m:P:p:qs:x:")) != -1) {
+	while ((ch = getopt(argc, argv, "BFGSVc:m:P:p:qs:x:")) != -1) {
 		switch (ch) {
+		case 'B':
+			fprintf(stdout, "%s %s\n", PRIME1, PRIME2);
+			return 0;
 		case 'V':
 			set_cmd(argv[0], CMD_VERIFY);
 			break;
-- 
1.9.1

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Yousong Zhou  [22.02.2017 13:19]:
> How about generating at build time a piece of c code whose output when
> run at the target board will be the source code itself (quine).  We
> can use the output content to seed the computation of signature.  The
> binary itself should be cross-compiled in a reproducible way so that
> integrity of the binary itself can be verified...

that is a *great* idea and I will go for it and implement...

bye, bastian

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

* Joris de Vries  [22.02.2017 10:34]:
> Still it is a very interesting idea and I’d love to read more thoughts on 
> this!

i will give a talk about this on battlemesh/vienna.
I the slides are ready, i will poke the list...

bye, bastian

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

[LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[Bastian Bittorf]

dear devs,

I'm polishing up our work-in-progress regarding automated
firmware-upgrades in our community network and I have a concept problem:

our images/the sha256-sum's are signed:
http://intercity-vpn.de/networks/liszt28/firmware/models/Buffalo%20WZR-HP-AG300H/testing/Standard,DSLR,fotobox,kalua/info.json

The downloader checks against a list of signatures, where
e.g. 3 signatures must match the sha256 sum.

There are "automated" signatures (e.g. from builbot) and manual ones,
from humans. For protecting ourselfes from bad admins, there
should be a "secret thing" which is baked into the firmware and
only seeable during runtime: this way we can prevent, that a lazy
admin "signs" a sha256 sum, without really has flashed the image
and can make sure that it really runs.

Now the question: a secret can be e.g.
# ls -la /etc | md5sum

This is naive, and a dumb admin can e.g. unsquashfs the
image for getting the data. are there better methods? any ideas?

bye, bastian

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

Re: [LEDE-DEV] need help / info [httpd/apache]

[Bastian Bittorf]

* Denis Periša  [21.02.2017 06:44]:
> Thank you Bastian. I've come to realize it could be possible :)
> Only thing that lacks is apaches nice way of redirecting 404 page to
> php, here if I do that it sends php file as html, without execution.

this should work. Have you set e.g.:
uhttpd.main.interpreter='.php=/bin/php'

bye, bastian

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

Re: [LEDE-DEV] need help / info [httpd/apache]

[Bastian Bittorf]

* Denis Periša  [20.02.2017 09:06]:
> Is there any other httpd that supports php and 404 error pages?

the "builtin" server 'uhttpd' supports both.
read the wiki about uci/uhttpd.

bye, bastian

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

Re: [LEDE-DEV] massive speed-loss using 'make defconfig'

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [09.02.2017 17:45]:
> is 'make menuconfig' also using 'package-metadata.pl'?
> 
> I ask, because start 'menuconfig' and selecting/unselecting
> symbols with the GUI is very fast, but the same operation - is'nt it?

i will answer the question myself: it is not.
defconfig must be called after working with 'menuconfig'.

maybe you have an idea, how we can speedup our workflow:


echo  >.config 'CONFIG_TARGET_ar71xx=y'
echo >>.config 'CONFIG_TARGET_ar71xx_generic=y'
make defconfig

(apply some symbols)
make defconfig

[...]

(apply some symbols)
make defconfig

This is called up to 30 times till our '.config' is ready.

Question: is it *safe* to call 'defconfig' only at there very end?

bye, bastian

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

Re: [LEDE-DEV] anonymous stats / was: Release Candidate Test Plan - first draft

[Bastian Bittorf]

* Etienne Champetier  [07.02.2017 16:27]:
> not a fan of leaking revision number on public network by default (if
> you are connected to public wifi or ...)

This is a valid point somehow, but:
because model and revision number can/must be encoded with e.g. base64
it is at least not plaintext, but far from encrypted 8-)

Is it really an issue sending the revision-number/model over wire?
Is an opt-out (uci-var) thinkable?

> If someone do something, can this be over https?

it's about sending via DNS, so no http/https involved here.

bye, bastian

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

Re: [LEDE-DEV] massive speed-loss using 'make defconfig'

[Bastian Bittorf]

* Jo-Philipp Wich  [07.02.2017 15:20]:
> Check "git log scripts/config/" and compare the complexity & size of
> "./scripts/metadata.pl config tmp/.packageinfo" in OpenWrt with
> "./scripts/package-metadata.pl config tmp/.packageinfo" on LEDE.
> 
> Also compare the runtimes of "make prepare-tmpinfo" as well as
> "scripts/config/conf --defconfig=.config Config.in".

i understand...hmmm, this is something for a long winter evening.
thanks for pointing at the internals...

bye, bastian

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

[LEDE-DEV] massive speed-loss using 'make defconfig'

[Bastian Bittorf]

in our build-process we make intensive use of
'make defconfig' and registrated a massive speed-loss
in building comparing with OpenWrt r49276 on the
same machine with nearly the same .config:

r49276: ~1.2sec
LEDE: ~10 sec

everything is in a tmpfs, it's a Xeon 5680@3.33GHz

I'am not sure, what is internally done and how,
can somebody point me to the program.c so maybe i
get an idea whats "wrong".

bye, bastian

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

Re: [LEDE-DEV] Release Candidate Test Plan - first draft

[Bastian Bittorf]

* Giuseppe Lippolis  [07.02.2017 10:00]:
> My proposal for the anonymous datacollection is to send 
> 1) an UDP telegram with sysupgraded.$boardname at the end of the sysupgrade
> 2) an UDP telegram with firstboot.$boardname at the end of the firstboot

sorry, i just forgot: the revision number must be included.
also the boardname must be base64 encoded (or something alike)
otherwise it can get lost on the DNS way.

bye, bastian

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

Re: [LEDE-DEV] Release Candidate Test Plan - first draft

[Bastian Bittorf]

* Daniel Golle  [06.02.2017 08:59]:
> Imho we should make a note on each board which successfully booted the
> release and make a note whether it was flashed using sysupgrade or

there was an idea, to do sort of anonymous datacollection by executing
e.g. 'nslookup sysupgraded.$boardname.lede-project.org'
after each hotplug.wan - so we can get a feeling for problems...

there is also a listener needed on the serverside...
anybody has some sparetime? 8-)

bye, bastian

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

Re: [LEDE-DEV] the ipv6 issues and the notions of timer

[Bastian Bittorf]

* Karl Palsson <ka...@tweak.net.au> [25.01.2017 13:58]:
> Bastian Bittorf <b...@npl.de> wrote:
> > * Dave Taht <dave.t...@gmail.com> [24.01.2017 08:52]:
> > > I'd love a "simple ubus listen daemon example - one that listens
> > > merely for events on a set of interfaces. or routes or on a proto".
> > 
> > root@box:~ ubus listen
> > { "network.interface": {"action":"ifdown","interface":"lan"} }  
> > 
> > { "network.interface": {"action":"ifup","interface":"lan"} }
> 
> You know ubus listen only shows you the public sends right? You
> don't get to see _any_ of the stuff sent via ubus as RPC.

Good point. Any idea about that?

bye, bastian

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

Re: [LEDE-DEV] the ipv6 issues and the notions of timer

[Bastian Bittorf]

* Dave Taht  [24.01.2017 08:52]:
> I'd love a "simple ubus listen daemon example - one that listens
> merely for events on a set of interfaces. or routes or on a proto".

root@box:~ ubus listen
{ "network.interface": {"action":"ifdown","interface":"lan"} }  

{ "network.interface": {"action":"ifup","interface":"lan"} }

> For all I know there's better tools for looking at ubus but my head
> spins from installing my post-eyeball json checker. I'd like to for
> example be checking that everything is always correctly formatted json
> passing through... is there a way to do that? While, like, um,
> hammering ubus?

. /usr/share/libubox/jshn.sh
MYJSON="$( devstatus eth0.2 )"
json_load "$MYJSON" || something_is_wrong
json_cleanup

bye, bastian

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

[LEDE-DEV] [PATCH v3] procd: update procd.sh to disallow signal-numbers, enforce signal-names

[Bastian Bittorf]

A given signal-name is now converted to the corresonding number. In general
it's good style to use names (readability) and it's more portable: signal
numbers can be architecture-dependent, so we are more safe giving names.

A real world example is signal 10, which is BUS on ramips and USR1 on PPC.

All users of 'procd_send_signal' must change their code to reflect this.

Signed-off-by: Bastian Bittorf <b...@npl.de>
---

Changelog:
v2: give example in decription and safe 1 line of code
v3: simplify code (do not parse kill-output, but give an argument to kill)
enforce using of names instead of numbers
thanks for suggestions to 'Etienne Champetier' and 'Jo-Philipp Wich'


 package/system/procd/files/procd.sh | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/package/system/procd/files/procd.sh 
b/package/system/procd/files/procd.sh
index 8f18cda..a1b9f2f 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -213,9 +213,12 @@ _procd_set_param() {
json_add_string "" "$@"
json_close_array
;;
-   nice|reload_signal)
+   nice)
json_add_int "$type" "$1"
;;
+   reload_signal)
+   json_add_int "$type" $(kill -l "$1")
+   ;;
pidfile|user|seccomp|capabilities)
json_add_string "$type" "$1"
;;
-- 
1.9.1


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

[LEDE-DEV] [PATCH v2] procd: update procd.sh to support both: signal-names and signal-numbers

[Bastian Bittorf]

It is automatically detected if the input is an integer. If not,
the name is converted to the corresonding number. In general it's
good style to use names (readability) and it's more portable: signal
numbers can be architecture-dependent, so we are more safe giving names.

A real world example is signal 10, which is BUS on ramips and USR1 on PPC.

Signed-off-by: Bastian Bittorf <b...@npl.de>
---

Changelog:
v2: give example in decription and safe 1 line of code

 package/system/procd/files/procd.sh | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/package/system/procd/files/procd.sh 
b/package/system/procd/files/procd.sh
index 8f18cda..0a441b1 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -200,6 +200,7 @@ _procd_add_jail_mount_rw() {
 
 _procd_set_param() {
local type="$1"; shift
+   local obj old_obj signal
 
case "$type" in
env|data|limits)
@@ -213,9 +214,17 @@ _procd_set_param() {
json_add_string "" "$@"
json_close_array
;;
-   nice|reload_signal)
+   nice)
json_add_int "$type" "$1"
;;
+   reload_signal)
+   signal="$1"
+   test "$signal" -eq "$signal" 2>/dev/null || {
+   for obj in $( kill -l ) NOT_FOUND; do test 
"$signal" = "$obj" && break; old_obj="$obj"; done
+   signal="${old_obj%)}"
+   }
+   json_add_int "$type" "$signal"
+   ;;
pidfile|user|seccomp|capabilities)
json_add_string "$type" "$1"
;;
-- 
1.9.1


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

Re: [LEDE-DEV] procd & custom reload support

[Bastian Bittorf]

* Jo-Philipp Wich  [13.01.2017 15:38]:
> To enable it, add "procd_set_param reload_signal 10" to your init script.

i send a patch to the mailinglist,
with this it is possible to write

procd_set_param reload_signal USR1

be warned: if you are e.g. on ramips, than
the signal 10 is 'BUS', so thats not what you want 8-)

bye, bastian

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

[LEDE-DEV] [PATCH] procd: update procd.sh to support both: signal-names and signal-numbers

[Bastian Bittorf]

It is automatically detected if the input is a number. If not,
the name is converted to the corresonding number. In general it's
good style to use names and it's more portable: signal numbers can
be architecture-dependent, so we are more safe giving names.

Signed-off-by: Bastian Bittorf <b...@npl.de>
---
 package/system/procd/files/procd.sh | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/package/system/procd/files/procd.sh 
b/package/system/procd/files/procd.sh
index 8f18cda..695d815 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -200,6 +200,7 @@ _procd_add_jail_mount_rw() {
 
 _procd_set_param() {
local type="$1"; shift
+   local obj old_obj signal
 
case "$type" in
env|data|limits)
@@ -213,9 +214,18 @@ _procd_set_param() {
json_add_string "" "$@"
json_close_array
;;
-   nice|reload_signal)
+   nice)
json_add_int "$type" "$1"
;;
+   reload_signal)
+   signal="$1"
+   test "$signal" -eq "$signal" 2>/dev/null || {
+   set -- $( kill -l ) NOT_FOUND
+   for obj in "$@"; do test "$signal" = "$obj" && 
break; old_obj="$obj"; done
+   signal="${old_obj%)}"
+   }
+   json_add_int "$type" "$signal"
+   ;;
pidfile|user|seccomp|capabilities)
json_add_string "$type" "$1"
;;
-- 
1.9.1


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

Re: [LEDE-DEV] Branching LEDE 17.01 / problems with ath9k

[Bastian Bittorf]

* Thomas Endt  [13.01.2017 09:19]:
> > the page https://lede-project.org changed again and 'reporting bugs'
> > is hidden under 'Developer Guide' which is just...wrong Please make
> > this more "friendly".
> 
> https://lede-project.org/contact contains a link to
> https://bugs.lede-project.org/ since 11/11/2016.
> IMHO the perfect place.

thank you - that makes sense. maybe move it more
ontop? it's nearly the last entry after, even after
"Server Status Changes Announcements on Twitter" 8-)

bye, bastian

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

Re: [LEDE-DEV] Branching LEDE 17.01 / problems with ath9k

[Bastian Bittorf]

Thanks for these strong steps toward a release,
the last weeks where full of commits and everybody
seems to work very hard.

What i want to mention is, that older ath9k chips (ar91xx?)
are not useable with LEDE anymore, e.g. TP-Link 1043nd v1

This needs more testing and reporting. Maybe someone has
time to jump in. I have opened a ticket for that:
https://bugs.lede-project.org/index.php?do=details_id=373

bye, bastian

BTW:
the page https://lede-project.org changed again and 'reporting bugs'
is hidden under 'Developer Guide' which is just...wrong
Please make this more "friendly".

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

Re: [LEDE-DEV] newbie opkg upgrading questions..

[Bastian Bittorf]

* B. Cook  [08.01.2017 16:19]:
>  //  LE  \  ||___|___/|___|  lede-project.org
>  \\   DE /
>   \LE  \/  ---
>\  DE\  /Reboot (SNAPSHOT, r2701-c5ca304)
> \\/---
> 
> Your JFFS2-partition seems full and overlayfs is mounted read-only.
> Please try to remove files from /overlay/upper/... and reboot!

it clearly says: "remove files from /overlay/upper/..." and reboot.
so there is no need for "mount -rw" or things like that.

do you have a better text which should shown as help?

bye, bastian

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

Re: [LEDE-DEV] newbie opkg upgrading questions..

[Bastian Bittorf]

* Yousong Zhou  [04.01.2017 09:09]:
> > root@wzr-ag300h:~# mount
> > proc on /proc type proc (ro,noatime)
> > tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
> > overlayfs:/overlay on / type overlay
> > (ro,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
> > tmpfs on /dev type tmpfs (ro,relatime,size=512k,mode=755)
> > devpts on /dev/pts type devpts (ro,relatime,mode=600)

in /etc/profile there is a check which should
warn about this special issue on login. Mr. Cook, can
you please post the output of /proc/mounts ?

what is the output of:
grep '/ overlay ro,' /proc/mounts

thanks & bye, bastian

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

Re: [LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

[Bastian Bittorf]

* John Crispin  [28.12.2016 14:41]:
> please create a bullet list of the feature provided by the daemons
> mentioned above that you are missing in current procd/lede setups.

i will jump in and speak for martin (some community/firmware team):

procd should know a method for executing regular checks, e.g.

procd_set_param 'check_interval' '20min'
procd_set_param 'check_script' '/path/to/myscript'

depending on the returncode? or somehow definded
procd should send signals or restart the daemon.

basically thats it. what comes to my mind is:

we have services which are checked each 60 secs,
but it is a wish that all these checks are not 
run at the same time but one after another.

thanks & bye, bastian

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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [22.11.2016 23:47]:
> answer myself: CONFIG_TARGET_ROOTFS_PARTSIZE is unset?
> 
> see 'Image/Build/squashfs' in 'uml/Image/Makefile'

indeed, it works when i set it manually and i can boot into UML:

root@uml:/ df -h
FilesystemSize  Used Available Use% Mounted on
/dev/root 3.9M  3.9M 0 100% /rom
tmpfs12.6M768.0K 11.8M   6% /tmp
/dev/loop0   10.7M249.0K  9.6M   2% /overlay
overlayfs:/overlay   10.7M249.0K  9.6M   2% /
tmpfs   512.0K 0512.0K   0% /dev
tmpfs   128.0K 0128.0K   0% /coredumps

root@uml:/ cat /proc/mounts 
/dev/root /rom squashfs ro,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
/dev/loop0 /overlay ext4 rw,noatime,data=ordered 0 0
overlayfs:/overlay / overlay
rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0
tmpfs /coredumps tmpfs rw,nosuid,nodev,relatime,size=128k 0 0


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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [22.11.2016 23:01]:
> * Felix Fietkau <n...@nbd.name> [22.11.2016 22:42]:
> > > here the build-error with "inodes full".
> > > (the same images works, if i just raise the inodes to 2048)
> > Try disabling the ext4 image via make menuconfig.
> 
> sorry, does not help. i did:
> make menuconfig (unselect ext4)
> make clean
> make BUILD_LOG=1
> (build aborted)
> 
> (Q: where does this dd: invalid number come from?)

answer myself: CONFIG_TARGET_ROOTFS_PARTSIZE is unset?

see 'Image/Build/squashfs' in 'uml/Image/Makefile'

bye, bastian

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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[Bastian Bittorf]

* Jo-Philipp Wich  [22.11.2016 10:08]:
> a huge block size on small partition simply makes no sense. If you
> already configure 16MB partitions then you can as well change block size
> from 4K to 1K or 512B as well since you're deviating from the defaults
> anyway.
> 
> Having different code paths for small and huge partitions is annoying
> and leads to maintenance overhead, having to care about inode counts is
> not ideal either as this is imho too much of a filesystem implementation
> detail.

i understand, so we can:

1)
detect via makefile if PARTITION is small and autoadjust BLOCKSIZE
(if not given)

2)
set BLOCKSIZE default to 1K via x86/UML-Makefile

3)
the first approach by changing 'make_ext4fs.c'

what is the best method? - bye, bastian

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

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.31

[bittorf wireless )) Bastian Bittorf]

* Koen Vandeputte  [16.11.2016 17:45]:
> 3)
> - When a kernel update patch is posted, it requires at least 2
> additional "tested-by"'s on different targets before it can be
> considered for merging. (Covering 5 .. 6 targets in total

thanks for these insights.
i think the 2 testers if a senseful thing.

i can at least test
ar71xx ath25 au1000 brcm47xx kirkwood mpc85xx omap ppc40x ramips rb532 sunxi 
uml x86 xburst
on real hardware and because of autoupdate it's not too hard.

bye, bastian

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

Re: [LEDE-DEV] iw / ath9k / mediatek / strange values for 'signal'

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [21.10.2016 23:02]:
> we use the signal reported from 'iw' for some actions
> and I can see them beeing inconsistent or maybe even
> wrong calculated (strange values are marked)

I tried LEDE r2167 and it's still the
same: at *** the signal value is just wrong.
should i report this to linux-wireless?

Station 60:5b:b4:9a:e4:8b (on wlan0-1)
inactive time:  140 ms
rx bytes:   3062044
rx packets: 21583
tx bytes:   50191110
tx packets: 36631
tx retries: 9527
tx failed:  2
rx drop misc:   2
*** signal: -101 [-58, -63, -59] dBm
signal avg: -68 [-56, -62, -59] dBm
tx bitrate: 52.0 MBit/s MCS 5
rx bitrate: 130.0 MBit/s MCS 15
expected throughput:28.14Mbps
authorized: yes
authenticated:  yes
associated: yes
preamble:   short
WMM/WME:yes
MFP:no
TDLS peer:  no
DTIM period:2
beacon interval:125
short preamble: yes
short slot time:yes
connected time: 825 seconds

bye, bastian

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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [12.11.2016 09:54]:
> +# doubles the default inode amount
> +INODES=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*64*2)))
>  E2SIZE=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024*1024)))

bye the way:
i mimic'ed the existing style, but is'nt this too much?
can't this be expressed like this:

INODES=$(( $(CONFIG_TARGET_ROOTFS_PARTSIZE)*64*2 ))

(instead of explicitely calling the shell)

bye, bastian

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

Re: [LEDE-DEV] ar71xx: swconfig does not reflect changes

[Bastian Bittorf]

* mil...@betternet.co  [12.11.2016 09:54]:
> I own an ar71xx bboard (GL-6416 to be exact). Whether the ethernet
> cable is connected to WAN port or not, running `swconfig dev switch0
> show` returns the following:

your WAN is a MII-style device, which is not "supported" from swconfig.

try this:
devstatus "$WANDEV" | grep '"speed": '

bye, bastian

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

[LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[Bastian Bittorf]

A rootfs typically has lots of small files, so the default
counter with 1024 inodes for 16 megabytes partition size can
be too restrictive and leads to e.g.

root@box:/ touch /etc/config/test
touch: /etc/config/test: No space left on device

the solution is to just double the amount of inodes
during image creation, so a 16mb part has 2048 inodes.

see also:
http://lists.infradead.org/pipermail/lede-dev/2016-November/003977.html

Signed-off-by: Bastian Bittorf <b...@npl.de>
---
 include/image.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/image.mk b/include/image.mk
index 8b183ab..e74a71d 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -239,11 +239,13 @@ define Image/mkfs/ubifs
-o $@ -d $(call mkfs_target_dir,$(1))
 endef
 
+# doubles the default inode amount
+INODES=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*64*2)))
 E2SIZE=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024*1024)))
 
 define Image/mkfs/ext4
$(STAGING_DIR_HOST)/bin/make_ext4fs \
-   -l $(E2SIZE) -b $(CONFIG_TARGET_EXT4_BLOCKSIZE) \
+   -l $(E2SIZE) -i $(INODES) -b $(CONFIG_TARGET_EXT4_BLOCKSIZE) \
$(if $(CONFIG_TARGET_EXT4_RESERVED_PCT),-m 
$(CONFIG_TARGET_EXT4_RESERVED_PCT)) \
$(if $(CONFIG_TARGET_EXT4_JOURNAL),,-J) \
$(if $(SOURCE_DATE_EPOCH),-T $(SOURCE_DATE_EPOCH)) \
-- 
1.9.1


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

Re: [LEDE-DEV] [PATCH] Use printf instead of echo.

[Bastian Bittorf]

* Felix Fietkau  [23.08.2016 13:59]:
> > For now, the change I submitted is whats needed to fix breakage on my 
> > system. For others, I will send patches if no one takes it up in a few days.
> Actually, you might be able to simplify the change even more by forcing
> the hostapd build shell to bash (some other packages do this as well).

this look simple, but in the long run...

# "Stick to portable constructs where possible, and
#  you will make somebody's life easier in the future.
#  Maybe your own."

so using /bin/sh with 'printf' is safe.
(no matter which underlying shell-interpreter we use)

bye, bastian

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

Re: [LEDE-DEV] ext4 / no space left on device / UML

[Bastian Bittorf]

* Bjørn Mork  [11.11.2016 19:04]:
> > can you read something interesting?
> 
> Sure. "Free inodes: 0" is not good.  And what was I suspected.  We've
> all been there in the past ;)

thanks for spotting this - i never saw this before 8-)
 
> Can you reduce the number of small files on this file system somehow?
> If not, then you need to recreate it.  AFAIK there is no way to adjust
> the inode count of an existing file system.

it's just an UML image which is for boot testing.
I send a patch for increasing the inodes default.

bye, bastian

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

Re: [LEDE-DEV] ext4 / no space left on device / UML

[Bastian Bittorf]

* Bjørn Mork  [11.11.2016 14:58]:
> > in fact there is enough space, but not useable.
> 
> And "df -i" says?

this seems not supported by the busybox applet, but
on the host i can see this:

bastian@LEDE:/home/bastian/ledebot/source$ tune2fs -l 
bin/targets/uml/generic/lede-uml-ext4.img
tune2fs 1.42.13 (17-May-2015)
Filesystem volume name:   
Last mounted on:  /
Filesystem UUID:  57f8f4bc-abf4-655f-bf67-946fc0f9f25b
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  ext_attr resize_inode filetype extent
sparse_super large_file uninit_bg
Filesystem flags: unsigned_directory_hash 
Default mount options:(none)
Filesystem state: clean
Errors behavior:  Remount read-only
Filesystem OS type:   Linux
Inode count:  1024
Block count:  4096
Reserved block count: 0
Free blocks:  875
Free inodes:  0
First block:  0
Block size:   4096
Fragment size:4096
Reserved GDT blocks:  7
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 1024
Inode blocks per group:   64
Last mount time:  Fri Nov 11 14:43:21 2016
Last write time:  Fri Nov 11 14:43:04 2016
Mount count:  1
Maximum mount count:  -1
Last checked: Fri Nov 11 14:43:04 2016
Check interval:   0 ()
Lifetime writes:  652 kB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Required extra isize: 28
Desired extra isize:  28
Default directory hash:   tea
Journal backup:   inode blocks

can you read something interesting?

bye, bastian

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

[LEDE-DEV] ext4 / no space left on device / UML

[Bastian Bittorf]

i'am using LEDE with target UML and rr2155 and has this problem:

root@uml:/ df -h
FilesystemSize  Used Available Use% Mounted on
/dev/root15.7M 12.3M  3.1M  80% /
tmpfs12.5M320.0K 12.2M   3% /tmp
tmpfs   512.0K 0512.0K   0% /dev
tmpfs   128.0K 0128.0K   0% /coredumps

root@uml:/ touch /etc/config/test
touch: /etc/config/test: No space left on device


in fact there is enough space, but not useable.
it seems this is the culprit:
https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

did we changed something with ext4?
maybe this is even a problem on real disks.

btw: can we link the bugtracker on the main page?

bye, bastian

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

Re: [LEDE-DEV] Crash on D-Link DIR-869-A1 (ar71xx) with ath10k / Coova-Chilli

[Bastian Bittorf]

* James Wood  [09.11.2016 20:40]:
> Wed Nov  9 14:13:24 2016 kern.warn kernel: hostapd invoked oom-killer:
> gfp_mask=0x24201ca, order=0, oom_score_adj=0

its just oom, is'nt it?

bye, bastian

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

Re: [LEDE-DEV] Cubietruck / WiFi:brcmfmac / SDIO / firmware

[Bastian Bittorf]

* Mathias Kresin <d...@kresin.me> [08.11.2016 10:44]:
> 2016-11-08 8:54 GMT+01:00 Bastian Bittorf <b...@npl.de>:
> > with recent trunk r2116 i cannot get WiFi working.
> > First it only seems the SDIO-support must be activated
> > CONFIG_BRCMFMAC_SDIO=y (which is not!) but even with this i see:
> >
> > root@lede:~ :) dmesg | grep -i brcm
> > [   11.319793] brcmfmac mmc1:0001:1: Direct firmware load for 
> > brcm/brcmfmac43362-sdio.bin failed with error -2
> > [   11.329540] brcmfmac mmc1:0001:1: Falling back to user helper
> > [   11.345082] firmware brcm!brcmfmac43362-sdio.bin: 
> > firmware_loading_store: map pages failed
> 
> Package brcmfmac-firmware-43362-sdio is installed?

now it is, i already found it digging through the makefiles:
(it's just the dependency missing in the makefile)

root@CubieNAS:~ :) dmesg | grep -i brc 
[   15.018376] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 
2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
[   15.047205] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 
0x30)
[   15.059210] usbcore: registered new interface driver brcmfmac

root@CubieNAS:~ :) uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.country='US'
wireless.radio0.channel='11'
wireless.radio0.frag='off'
wireless.radio0.path='platform/soc@01c0/1c12000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
wireless.radio0.hwmode='11g'
wireless.radio0.chanbw='20'
wireless.radio0.distance='100'
wireless.radio0.beacon_int='250'
wireless.radio0.txpower='10'
wireless.@wifi-iface[0]=wifi-iface
wireless.@wifi-iface[0].device='radio0'
wireless.@wifi-iface[0].network='wlan'
wireless.@wifi-iface[0].mode='ap'
wireless.@wifi-iface[0].disabled='0'
wireless.@wifi-iface[0].disassoc_low_ack='1'
wireless.@wifi-iface[0].max_inactivity='30'
wireless.@wifi-iface[0].mcast_rate='1000'
wireless.@wifi-iface[0].ssid='weimar.freifunk.net'

it does not matter if 'ap' or 'ibss', the dev 'wlan0' keep down.
when doing 'ip link set dev wlan0 up' and 'if dev wlan0 scan' i get
a large/fine list, so it receives...

but when bringing the interface up the kernel says:
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

and yes:
oot@CubieNAS:~ :) ip address show dev wlan0
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state 
DOWN qlen 1000
link/ether 6c:fa:a7:16:12:5a brd ff:ff:ff:ff:ff:ff

bye, bastian

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

[LEDE-DEV] Cubietruck / WiFi:brcmfmac / SDIO / firmware

[Bastian Bittorf]

with recent trunk r2116 i cannot get WiFi working.
First it only seems the SDIO-support must be activated
CONFIG_BRCMFMAC_SDIO=y (which is not!) but even with this i see:

root@lede:~ :) dmesg | grep -i brcm
[   11.319793] brcmfmac mmc1:0001:1: Direct firmware load for 
brcm/brcmfmac43362-sdio.bin failed with error -2
[   11.329540] brcmfmac mmc1:0001:1: Falling back to user helper
[   11.345082] firmware brcm!brcmfmac43362-sdio.bin: firmware_loading_store: 
map pages failed
[   12.390780] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 
0x50
[   13.400836] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 
0x50
[   13.430723] usbcore: registered new interface driver brcmfmac

any hints about that? was it already working and is now broken,
or was it never possible to use the WiFi for this board?

bye, bastian

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

Re: [LEDE-DEV] [PATCH v3 00/13] shell code improvement for /scripts

[bittorf wireless )) Bastian Bittorf]

* John Crispin  [27.10.2016 12:55]:
> obvious,  additionally i find it hard to believe that alot his stuff
> has been properly tested. unless someone steps up and starts reviewing
> these patches on the next 1-2 days i will NAK them and ask you to start
> resending it in smaller chunks.

I'am a lot further regarding the automated test-framework
and will submit a first draft next week. IMHO such patches must
prove their correctness with tests (and correct commit-messages)

bye, bastian

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

Re: [LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

[Bastian Bittorf]

* Chris Blake  [24.10.2016 07:47]:
> Alexis is correct, it's to ensure any chance of a random error is
> suppressed. 2> /dev/null was just added as a protection.

i will explain why this makes no sense:

grep will complain if e.g. the file '/proc/mounts' does not exist,
otherwise it output the lines matching the pattern or an empty result
if there is no match.

if there is really an error, it's a good idea NOT to suppress it.
so please resend without this 2>...

bye, bastian

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

Re: [LEDE-DEV] [PATCH v4] base-files: Ensure reset only works if an overlay exists

[Bastian Bittorf]

* Chris Blake  [23.10.2016 21:10]:
> +OVERLAY="$( grep ' /overlay ' /proc/mounts 2>/dev/null )"

whats the reason for the 2>...?

bye, bastian

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

[LEDE-DEV] iw / ath9k / mediatek / strange values for 'signal'

[Bastian Bittorf]

we use the signal reported from 'iw' for some actions
and I can see them beeing inconsistent or maybe even
wrong calculated (strange values are marked)

root@box:~ iw dev wlan0-1 station get 60:5b:b4:9a:e4:8b
Station 60:5b:b4:9a:e4:8b (on wlan0-1)
inactive time:  10 ms
rx bytes:   820080
rx packets: 6018
tx bytes:   13855366
tx packets: 9884
tx retries: 1696
tx failed:  0
*** signal: -4 [-59, -59, -54] dBm
signal avg: -53 [-57, -57, -52] dBm
tx bitrate: 58.5 MBit/s MCS 6
rx bitrate: 130.0 MBit/s MCS 15
expected throughput:30.120Mbps
authorized: yes
authenticated:  yes
preamble:   short
WMM/WME:yes
MFP:no
TDLS peer:  no
connected time: 161 seconds

root@box:~ iw dev wlan0-1 station get 60:5b:b4:9a:e4:8b
Station 60:5b:b4:9a:e4:8b (on wlan0-1)
inactive time:  70 ms
rx bytes:   1262941
rx packets: 8861
tx bytes:   19504789
tx packets: 14266
tx retries: 2572
tx failed:  0
*** signal: -95 [-58, -58, -53] dBm
signal avg: -55 [-56, -57, -52] dBm
tx bitrate: 78.0 MBit/s MCS 12
rx bitrate: 117.0 MBit/s MCS 14
expected throughput:35.613Mbps
authorized: yes
authenticated:  yes
preamble:   short
WMM/WME:yes
MFP:no
TDLS peer:  no
connected time: 292 seconds

root@box:~ iw dev wlan0-1 station get 60:5b:b4:9a:e4:8b
Station 60:5b:b4:9a:e4:8b (on wlan0-1)
inactive time:  20 ms
rx bytes:   2460373
rx packets: 9789
tx bytes:   19619950
tx packets: 14761
tx retries: 2599
tx failed:  0
*** signal: -20 [-59, -58, -53] dBm
signal avg: -85 [-57, -58, -53] dBm
tx bitrate: 117.0 MBit/s MCS 14
rx bitrate: 52.0 MBit/s MCS 11
expected throughput:42.296Mbps
authorized: yes
authenticated:  yes
preamble:   short
WMM/WME:yes
MFP:no
TDLS peer:  no
connected time: 313 seconds

beside these 3 shots, i can see also values for signal of:
"8" (positive!) and "-126"...

i can see this with different versions of OpenWRT and LEDE
and with ath9k and Mediathek. What can I do for debugging this
better? The connected station is *not* moving.

bye, bastian

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

Re: [LEDE-DEV] [PATCH v3 04/13] scripts: $/${} is unnecessary on arithmetic variables

[Bastian Bittorf]

* Jo-Philipp Wich  [06.10.2016 16:35]:
> removing the dollar signs lets expressions succeed which would otherwise
> fail - which means it introduces a behavior change.

thanks for showing this. i must repeat myself:

before we merge such cleanups, we should write tests
and checkers for proving that nothing break.

bye, bastian

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

Re: [LEDE-DEV] [PATCH v3 04/13] scripts: $/${} is unnecessary on arithmetic variables

[Bastian Bittorf]

* Sebastian Moeller  [06.10.2016 13:48]:
> It might be not be necessary, but does it hurt? Are you concerned that the 
> current practice will hide variables changing their "type" from arithmetic 
> and that removing the $ prefix will silence this instead of giving an error 
> message? Or does this change improve run time of the scripts noticeable? I am 
> just asking, as a non-experts in shell coding it seems less error prone to 
> always use ${VARIABLE_NAME}...
>

e.g. this case:

A=7
B=3
SUM=$(( A + B ))# correct

instead of SUM=$(( $A + $B ))   # old

it is not about hurting, it's about make the code checkable.
"every" parser will complain about this mistake, so satisfy them
and we safe a few bytes 8-)

bye, bastian

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

Re: [LEDE-DEV] Automated shell code debugging

[Bastian Bittorf]

* Jan-Tarek Butt  [05.10.2016 07:47]:
> > also we must "mute" some "errors", e.g. the usage of 
> > 'local' in functions, which is not POSIX (but is in the
> > process of inclusion)
> 
> shellcheck is able to do that.
> 
> for mutin just add the comment
> 
> # shellcheck disable=

is is not that easy. shellcheck defines error-numbers
but sadly it combines ~10 errors into 1 code: SC2039:
https://github.com/koalaman/shellcheck/wiki/SC2039

so if you mute this 'local var' thingy, you are hiding
alot of other stuff also...

bye, bastian

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

Re: [LEDE-DEV] Call defines for minifying scripting languages

[Bastian Bittorf]

* Karl Palsson  [04.10.2016 08:38]:

[...]

> about the scripts _at all_ right up until they try and look in
> one to debug something behaving oddly. At _that_ point they will
> care _very much_ that it's all minified garbage, with some
> presumption that they could "just get the source somewhere else"

I have the same impression. But making it a non-default option
for advanced users/self-builders is ok. Lets see what he can
reach in the end...

bye, bastian

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

Re: [LEDE-DEV] Call defines for minifying scripting languages

[Bastian Bittorf]

* Jan-Tarek Butt  [03.10.2016 16:55]:
> currently I am working on a Shellscript minifyer
> there are not realy exsist one so I write a new one.

hopefully in haskell 8-)
you made my day 8-) ROFL!

I think this is a bad idea. In practise you
safe nothing but make debugging harder, the JFFS2 or
squashfs already compresses text/shellscripts very good.

bye, bastian

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

Re: [LEDE-DEV] Automated shell code debugging

[Bastian Bittorf]

* Jan-Tarek Butt  [02.10.2016 17:48]:
> As a part of code quallity enhancemend and prevenition. We can do an ondemand 
> daemon as engine to
> check all shell scrips. We can use the opensource Project shellcheck [0].
> 
> My idea is to do an insatnce on a server:
> This insatnce can pull the lede repo daily and run some thing like:
> 
> find . -type f -name "*.sh" | xargs shellcheck
> 
> if something news pulled and shellcheck detecs some misstating we can send 
> via bsd-mailx
> on our ML the shellceck output.
> 
> Sould I build something for that?

it's not *that* easy. for now the shell-codebase has *thousands* of
errors. we need something that checks small parts (e.g. functions)
and compares the error-count before and after. the output of this
approach should maybe be included in the commit-message.

also we must "mute" some "errors", e.g. the usage of 
'local' in functions, which is not POSIX (but is in the
process of inclusion)

bye, bastian 

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

Re: [LEDE-DEV] [PATCH v2] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64MiB RAM

[Bastian Bittorf]

* Bastian Bittorf <b...@npl.de> [16.09.2016 19:43]:
> changes v1 -> v2: (suggestions from Felix Fietkau, Rafał Miłecki)

sorry, please drop that - i can see the change now:
https://git.lede-project.org/?p=source.git;a=commitdiff;h=25dab5d217715300dc609df07b56e5b73cefdfc1

bye, bastian

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

[LEDE-DEV] [PATCH v2] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64MiB RAM

[Bastian Bittorf]

with 5c9cc7b7f8920944a413644e1c2ea23bfe655bcb we changed the default
value of 'vm.min_free_kbytes' from ~650 to 4096 kilobytes on 32MiB-RAM-devices.
This makes them hardly useable with a lot of OOM-crashes.

Change that and use 1024 kilobytes for 32MiB-RAM-devices.
For devices with more than 32MiB RAM we keep the behaviour / the values.

While we are at it, localize vars and read the memory without AWK/nonforking.

changes v1 -> v2: (suggestions from Felix Fietkau, Rafał Miłecki)
- keep -quiet option from sysctl
- use 1024 kilobyte on 32MiB-devices instead of the kernel default
- consistently use unit [MiB]
---
 package/base-files/files/etc/init.d/sysctl | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/package/base-files/files/etc/init.d/sysctl 
b/package/base-files/files/etc/init.d/sysctl
index a0daec0..7a16e01 100755
--- a/package/base-files/files/etc/init.d/sysctl
+++ b/package/base-files/files/etc/init.d/sysctl
@@ -4,16 +4,20 @@
 START=11
 
 set_vm_min_free() {
-   mem="$(grep MemTotal /proc/meminfo  | awk '{print $2}')"
-   if [ "$mem" -gt 65536 ]; then # 128M
+   local mem value
+
+   read -r _ mem _ http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64mb RAM

[Bastian Bittorf]

with 5c9cc7b7f8920944a413644e1c2ea23bfe655bcb we changed the default
value from ~650 to 4096 kilobyte on 32mb-RAM-devices. This makes them
hardly useable with a lot of oom-crashes. Fix that and keep the default.
For devices with more than 32mb we keep the behaviour and tweak the value.
We dont suppress output of sysctl-command, so the use has a chance to spot it.

While we are at it, localize vars and read the memory without AWK/nonforking.

Signed-off-by: Bastian Bittorf <b...@npl.de>
---
 package/base-files/files/etc/init.d/sysctl | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/package/base-files/files/etc/init.d/sysctl 
b/package/base-files/files/etc/init.d/sysctl
index a0daec0..c3b48f4 100755
--- a/package/base-files/files/etc/init.d/sysctl
+++ b/package/base-files/files/etc/init.d/sysctl
@@ -4,17 +4,19 @@
 START=11
 
 set_vm_min_free() {
-   mem="$(grep MemTotal /proc/meminfo  | awk '{print $2}')"
-   if [ "$mem" -gt 65536 ]; then # 128M
+   local mem value
+
+   read -r _ mem _ http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Memory Usage of LEDE trunk on devices with only 32mb memory.

[Bastian Bittorf]

* Jo-Philipp Wich  [15.09.2016 16:58]:
>   http://git.lede-project.org/5c9cc7b7f8920944a413644e1c2ea23bfe655bcb ?

indeed! this makes a huge difference on 32mb devices.
so my proposal is:

1) dont touch vm.min_free_kbytes for 32mb-devices
2) when changing defaults with 'sysctl' dont be quiet,
so the user has at least a chance to debug this.

patch is on the way...bye, bastian

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

Re: [LEDE-DEV] [PATCH] base-files: sysupgrade. Added the ability to use URL as source

[Bastian Bittorf]

* ad...@yapic.net  [05.07.2016 10:55]:
> +wget_if_URL(){
> + local url="$1"
> + local url_repl_file="/tmp/sysupgrade-URL.bin"
> +
> + case "$url" in
> + http://*|https://*|ftp://*) break ;;
> + *) return 1 ;;

please use 'return 0' here, otherwise...

> + esac
> +
> + wget "$url" -O "$url_repl_file" || {
> + echo "Wget return error $? for url '$url'"
> + echo "Exiting"
> + rm -f $url_repl_file
> +
> + return 1
> + }
> +
> + ARGV=${ARGV/"$url"/"$url_repl_file"}
> + return 0
> +}
> +
> +# if URL was specified then download image file throw wget
> +wget_if_URL "$ARGV" || exit 1

...we always break here if ARGV has no url


thanks & bye...please send the next patch with a e.g. 'v3' and short
describe changes - so the commiters are aware which one is the right
one.

bye, bastian

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

Re: [LEDE-DEV] [PATCH] base-files: sysupgrade. Added the ability to use URL as source

[Bastian Bittorf]

* ad...@yapic.net  [04.07.2016 17:27]:
> +wget_if_URL(){
> + local url="$1"
> + local url_repl_file="/tmp/sysupgrade-URL.bin"

empty line here

> + case "$url" in
> + http://*|https://*|ftp://*) break ;;
> + *) return 1 ;;
> + esac

empty line here

> + rm -f $url_repl_file

why? if we dont --continue it is overwritten anyway

empty line here


> + wget "$url" -O "$url_repl_file" || {
> + echo "Wget return error $? for url '$url'"
> + echo "Exiting"
> + rm -f $url_repl_file

empty line here

> + exit 1

please 'return 1'

> + }

empty line here


thanks & bye - bastian

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

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

[Bastian Bittorf]

* David Lang  [28.05.2016 13:48]:
> rather than making a bunch of scripts for specific models, how about
> some scripts that will let you build from a downloaded .config (yes,
> you can do this manually, but it could be greatly simplified)

but for this, you cont need a script at all. its just:

cp $download_config .config
make defconfig
make

is'n it?

bye, bastian

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

Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

[Bastian Bittorf]

* Conor O'Gorman  [13.05.2016 11:52]:
> On 13/05/16 07:23, Alexandru Ardelean wrote:
> >Short version is: we have a configuration management system on top of
> >OpenWrt ; system boots with default settings (on every boot), and
> >config management applies config changes (whether it's right after
> >boot, or during system's normal operation).
> >Maybe other people do something similar.
> Not many. Most people store the config, which is the current model.
> It has benefits.

We also have an approach like Alexandru, but i dont see
the problem: logd starts at START='12'. Our config-thingy
fires at START=01 and uci-sets all the stuffs. So we can still
"rotate the knobs" e.g. uci set system.@system[0].log_size=64

bye, bastian

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