[OpenWrt-Devel] [PATCH] [package] gmp: add host compile

[Luiz Angelo Daros de Luca]

Currently, any package that uses host compile and depends on
libgmp.so will fail. This is because gmp is not compile for
host machine. So, staging_dir/host has only static lib for gmp

 $ ls staging_dir/host/lib/libgmp* -1
 staging_dir/host/lib/libgmp.a
 staging_dir/host/lib/libgmp.la
 staging_dir/host/lib/libgmpxx.a
 staging_dir/host/lib/libgmpxx.la

Addind host compile in gmp, the dependent package can use:

 PKG_BUILD_DEPENDS:=gmp/host

That will compile gmp to staging_dir/host with *.so files

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
---
 package/libs/gmp/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/libs/gmp/Makefile b/package/libs/gmp/Makefile
index a165131..f5839b7 100644
--- a/package/libs/gmp/Makefile
+++ b/package/libs/gmp/Makefile
@@ -22,6 +22,7 @@ PKG_FIXUP:=autoreconf
 
 PKG_USE_MIPS16:=0
 
+include $(INCLUDE_DIR)/host-build.mk
 include $(INCLUDE_DIR)/package.mk
 
 define Package/libgmp
@@ -44,7 +45,6 @@ CONFIGURE_ARGS += \
--without-readline \
--disable-fft \
 
-
 define Build/Compile
$(call Build/Compile/Default, \
DESTDIR=$(PKG_INSTALL_DIR) \
@@ -66,3 +66,4 @@ define Package/libgmp/install
 endef
 
 $(eval $(call BuildPackage,libgmp))
+$(eval $(call HostBuild))
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] OpenWRT built on OpenSuSE (x86_64) fails

[Luiz Angelo Daros de Luca]

Hello,

I'm trying to compile OpenWRT on an OpenSuSE 13.1 x86_64 targeting x86
generic (default config). However, I'm getting a strange behavior. In thunk
and BB, some packages that compiles for host machine are having problems
with pointer size:

openwrt/trunk/build_dir/host/grub-2.02~beta2 $ arch
x86_64
openwrt/trunk/build_dir/host/grub-2.02~beta2 $ grep SIZEOF_VOID_P config*h
config.h:#define BUILD_SIZEOF_VOID_P 8
*config-util.h:#define SIZEOF_VOID_P 4*

SIZEOF_VOID_P in host should be 8 if compiled for x86_64. And I get x86_64
binaries:

$ file build_dir/host/grub-2.02~beta2/grub-install
build_dir/host/grub-2.02~beta2/grub-install: *ELF 64-bit* LSB executable,
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.32, BuildID[sha1]=5082730f329f77b19783a7d9f6128bc6f3a45b10,
not stripped

I also get related warnings:

./include/grub/crypto.h:286:9: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
 || ((grub_addr_t) outptr  (sizeof (grub_uint64_t) - 1

As it compiles x86_64 program considering a pointer size from 32-bit,
programs did not work.

If I run the configure manually (with same args and PATH), the problem is
not present:

trunk/build_dir/host/grub-2.02~beta2.new $ grep SIZEOF_VOID_P config*h
config.h:#define BUILD_SIZEOF_VOID_P 8
*config-util.h:#define SIZEOF_VOID_P 8*

I isolated the problem to be the usage of
CONFIG_SITE=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/include/site/i486-openwrt-linux-uclibc

Is the usage of i486-openwrt-linux-uclibc expected? Should it be
x86_64-openwrt-linux-uclibc for host compile?

In Ubuntu, I get no problem.

In AA, I had no problem. The configure args from grub in AA and grub2 from
BB/trunk have some differences. In AA, I have a single
--target=x86_64-suse-linux but grub binaries are 32bit (but other
host/compile packages are 64-bit).

In BB/trunk I have duplicated --target= arg in configure. The first is
--target=x86_64-suse-linux but the second one is
--target=i486-openwrt-linux-uclibc. This might trigger cross compiling.

This is host configure in BB/trunk:

(cd
/home/REDETRESC/luizluca/prog-local/openwrt/trunk/build_dir/host/grub-2.02~beta2/;
if [ -x configure ]; then cp -fpR
/home/REDETRESC/luizluca/prog-local/openwrt/trunk/scripts/config.{guess,sub}
/home/REDETRESC/luizluca/prog-local/openwrt/trunk/build_dir/host/grub-2.02~beta2//
  /bin/bash ./configure CC=gcc CFLAGS=-O2
-I/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/include
-g
CPPFLAGS=-I/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/include
LDFLAGS=-L/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/lib
SHELL=/bin/bash *--target=x86_64-suse-linux *--host=x86_64-suse-linux
--build=x86_64-suse-linux --program-prefix= --program-suffix=
--prefix=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host
--exec-prefix=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host
--sysconfdir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/etc
--localstatedir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/var
--sbindir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/bin*
--target=i486-openwrt-linux-*uclibc
--sbindir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/bin
--disable-werror --disable-libzfs --disable-nls ; fi )
configure: loading site script
/home/REDETRESC/luizluca/prog-local/openwrt/trunk/include/site/i486-openwrt-linux-uclibc
configure: loading site script
/home/REDETRESC/luizluca/prog-local/openwrt/trunk/include/site/i486-openwrt-linux-uclibc
checking build system type... *x86_64-suse-linux-gnu*
checking host system type...* x86_64-suse-linux-gnu*
checking target system type...* i486-openwrt-linux-uclibc*

In Makefile, I have:

package/boot/grub2/Makefile:
 54 HOST_CONFIGURE_ARGS += \
 55 --target=$(REAL_GNU_TARGET_NAME) \

If I remove target, it does not change.

Do you guys have any clue?

Regards,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT built on OpenSuSE (x86_64) fails

[Luiz Angelo Daros de Luca]

Update: need help.

I found the problem.

OpenSuSE defines, by default, the CONFIG_SITE as:

CONFIG_SITE=/usr/share/site/x86_64-unknown-linux-gnu

This is defined in /etc/profile.d/site.sh from package site-config*.rpm,
described as:

Site configuration for autoconf based configure scripts provides smart
defaults for paths that are not specified.

Now, when building OpenWRT, if the CONFIG_SITE is defined (even empty), its
value is replaced by $TOPDIR/include/site/i486-openwrt-linux-uclibc, that
is actually the target and not the host. This might work for target
compilation but it will definitely fail for host compilation.

As a workaround, just unset the CONFIG_SITE before make.

Now, how to fix fix? It affects trunk and BB.

Regards,


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2014-08-28 20:19 GMT-03:00 Luiz Angelo Daros de Luca luizl...@gmail.com:

 Hello,

 I'm trying to compile OpenWRT on an OpenSuSE 13.1 x86_64 targeting x86
 generic (default config). However, I'm getting a strange behavior. In thunk
 and BB, some packages that compiles for host machine are having problems
 with pointer size:

 openwrt/trunk/build_dir/host/grub-2.02~beta2 $ arch
 x86_64
 openwrt/trunk/build_dir/host/grub-2.02~beta2 $ grep SIZEOF_VOID_P config*h
 config.h:#define BUILD_SIZEOF_VOID_P 8
 *config-util.h:#define SIZEOF_VOID_P 4*

 SIZEOF_VOID_P in host should be 8 if compiled for x86_64. And I get x86_64
 binaries:

 $ file build_dir/host/grub-2.02~beta2/grub-install
 build_dir/host/grub-2.02~beta2/grub-install: *ELF 64-bit* LSB executable,
 x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
 GNU/Linux 2.6.32, BuildID[sha1]=5082730f329f77b19783a7d9f6128bc6f3a45b10,
 not stripped

 I also get related warnings:

 ./include/grub/crypto.h:286:9: warning: cast from pointer to integer of
 different size [-Wpointer-to-int-cast]
  || ((grub_addr_t) outptr  (sizeof (grub_uint64_t) - 1

 As it compiles x86_64 program considering a pointer size from 32-bit,
 programs did not work.

 If I run the configure manually (with same args and PATH), the problem is
 not present:

 trunk/build_dir/host/grub-2.02~beta2.new $ grep SIZEOF_VOID_P config*h
 config.h:#define BUILD_SIZEOF_VOID_P 8
 *config-util.h:#define SIZEOF_VOID_P 8*

 I isolated the problem to be the usage of
 CONFIG_SITE=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/include/site/i486-openwrt-linux-uclibc

 Is the usage of i486-openwrt-linux-uclibc expected? Should it be
 x86_64-openwrt-linux-uclibc for host compile?

 In Ubuntu, I get no problem.

 In AA, I had no problem. The configure args from grub in AA and grub2 from
 BB/trunk have some differences. In AA, I have a single
 --target=x86_64-suse-linux but grub binaries are 32bit (but other
 host/compile packages are 64-bit).

 In BB/trunk I have duplicated --target= arg in configure. The first is
 --target=x86_64-suse-linux but the second one is
 --target=i486-openwrt-linux-uclibc. This might trigger cross compiling.

 This is host configure in BB/trunk:

 (cd
 /home/REDETRESC/luizluca/prog-local/openwrt/trunk/build_dir/host/grub-2.02~beta2/;
 if [ -x configure ]; then cp -fpR
 /home/REDETRESC/luizluca/prog-local/openwrt/trunk/scripts/config.{guess,sub}
 /home/REDETRESC/luizluca/prog-local/openwrt/trunk/build_dir/host/grub-2.02~beta2//
   /bin/bash ./configure CC=gcc CFLAGS=-O2
 -I/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/include
 -g
 CPPFLAGS=-I/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/include
 LDFLAGS=-L/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/lib
 SHELL=/bin/bash *--target=x86_64-suse-linux *--host=x86_64-suse-linux
 --build=x86_64-suse-linux --program-prefix= --program-suffix=
 --prefix=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host
 --exec-prefix=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host
 --sysconfdir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/etc
 --localstatedir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/var
 --sbindir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/bin*
 --target=i486-openwrt-linux-*uclibc
 --sbindir=/home/REDETRESC/luizluca/prog-local/openwrt/trunk/staging_dir/host/bin
 --disable-werror --disable-libzfs --disable-nls ; fi )
 configure: loading site script
 /home/REDETRESC/luizluca/prog-local/openwrt/trunk/include/site/i486-openwrt-linux-uclibc
 configure: loading site script
 /home/REDETRESC/luizluca/prog-local/openwrt/trunk/include/site/i486-openwrt-linux-uclibc
 checking build system type... *x86_64-suse-linux-gnu*
 checking host system type...* x86_64-suse-linux-gnu*
 checking target system type...* i486-openwrt-linux-uclibc*

 In Makefile, I have:

 package/boot/grub2/Makefile:
  54 HOST_CONFIGURE_ARGS += \
  55 --target=$(REAL_GNU_TARGET_NAME) \

 If I remove target, it does not change.

 Do you guys have any clue?

 Regards,

 ---
  Luiz

[OpenWrt-Devel] [PATCH] [generic] Add hotplug events for ntp updates

[Luiz Angelo Daros de Luca]

Hello,

ntpd have the ability to call a script on three events. This would be
useful for other services that need to be notified when the clock was
updated, or started/notified after ntp set the system clock (i.e.
aiccu, kerberos, winbind).

This is a simple patch that might need improvements. I don't know how
much doc should I write inside the scripts as comments as disk is a
limited resource. Also, there might be a better path for ntpd-hotplug
script (/lib/something/).

The patch adds a cmdline parameter -S script to ntpd in init.d
script (the -S function already exists). This script is called
whether one of ntpd events occurs: periodic, stratum and step.
Periodic is not very useful as cron can do a better job. stratum and
step are much more interesting as it detects when the system clock was
set or synchronized. Much better than watching logs for these events.

ntpd informs the script which event ocurred passing it as the first
cmdline argument. The script introduced here just calls hotplug-call
ntp, passing the event as an ENV variable ACTION.

This is an example of a ntp hotplug script:

#!/bin/sh
#
# ACTION=(periodic stratum step)
#
case $ACTION in
   stratum|step)
   /etc/init.d/myservice try-restart
;;
esac

PS: I first posted this patch in a trac issue (), but I guess this was
the wrong place to go.

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com

Index: package/base-files/files/usr/sbin/ntpd-hotplug
===
--- package/base-files/files/usr/sbin/ntpd-hotplug  (revisao 0)
+++ package/base-files/files/usr/sbin/ntpd-hotplug  (copia de trabalho)
@@ -0,0 +1,3 @@
+#!/bin/sh
+# ACTION=(periodic stratum step)
+ACTION=$1 /sbin/hotplug-call ntp
Index: package/base-files/files/etc/init.d/sysntpd
===
--- package/base-files/files/etc/init.d/sysntpd (revisao 34199)
+++ package/base-files/files/etc/init.d/sysntpd (copia de trabalho)
@@ -11,6 +11,7 @@
local peers
local args=-n
local enable_server
+   local hotplug_script=/usr/sbin/ntpd-hotplug
 
config_load system
config_get peers ntp server
@@ -27,6 +28,10 @@
done
fi
 
+   if [ -x $hotplug_script ]; then
+   append args -S $hotplug_script
+   fi
+
if [ $args != -n ]; then
service_start /usr/sbin/ntpd $args
fi


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

Re: [OpenWrt-Devel] milliseconds time measurements

[Luiz Angelo Daros de Luca]

Just (ab)use any other time function like time

tic() { TICFILE=$(mktemp); rm $TICFILE; mkfifo $TICFILE; ((TIME=$(time
cat $TICFILE 21 | sed -rne '/real/{s/^real[[:blank:]]*//;p}'); echo
$TIME$TICFILE )  )2/dev/null; }
toc() { echo -n $TICFILE; awk BEGIN { print $(cat $TICFILE | sed -e
's/m/ * 60 +/;s/s//') }; rm $TICFILE; }

$ tic
$ do something...
$ toc

Or you can save toc output to a var as

$ TIME=$(toc)

Ex:

root@router:~# tic; sleep 3; toc
3.01
root@router:~# tic; find /  /dev/null; toc
1.4

If lua can use module socket (package luasocket, normally not
installed), you could use:

root@router:~# lua -lsocket -e 'print(Milliseconds:  ..
socket.gettime()*1000)'
Milliseconds: 1353642672185.1

And maybe other solutions using other sources...

Regards,
---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2012/11/22 Gabriel gto...@inti.gob.ar:
 Hi,

 I'm using TP-Link WR741ND routers with openwrt, and I want to log some debug
 files, to know for example how many packets have been transmitted in a
 period of time. For that purpose I use while loops and log the results. The
 problem is that I couldn't find how to use a good time reference to measure
 the time periods. In a PC I can use the date command with nanoseconds
 resolution, but in openwrt it seems that it's not possible to get more
 resolution than 1 second, at least with the date command. I'd like to know
 if there's a way to get a resolution of at least milliseconds in user space.
 I've read in some posts that the problem with routers is that most of them
 don't have RTCs, but with ticks relative to processor's clock i'd be OK.
 I've also read here:

 https://forum.openwrt.org/viewtopic.php?id=21965

 people recommending to write a specific timer function, but i wanted to be
 sure that there's no a simple way.

 Regards

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

Re: [OpenWrt-Devel] milliseconds time measurements

[Luiz Angelo Daros de Luca]

/proc/uptime is much simplier :-)
---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2012/11/23 Bastian Bittorf bitt...@bluebottle.com:
 not possible to get more resolution than 1 second, at least with
 the
 date command. I'd like to know if there's a way to get a resolution

 you can start with 'date +%s'
 the tic() toc() approach is nice, here is what
 we do to measure exact time between 2 events:

 read t1 trash /proc/uptime
 do_something()
 read t2 trash /proc/uptime
 duration=$(( ${t2//./} - ${t1//./} ))
 logger -s lasts $(( $duration / 100 )).$(( $duration % 100 )) sec

 which outputs something like:
 lasts 7.64 sec

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

Re: [OpenWrt-Devel] [PATCH] [comgt] add support for defining dial number in config file

[Luiz Angelo Daros de Luca]

Do I need to improve anything to get commited?

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2014-03-17 18:13 GMT-03:00 luizl...@gmail.com:

 From: Luiz Angelo Daros de Luca luizl...@gmail.com

 Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
 ---
  package/network/utils/comgt/Makefile  | 2 +-
  package/network/utils/comgt/files/3g.chat | 2 +-
  package/network/utils/comgt/files/3g.sh   | 9 -
  3 files changed, 10 insertions(+), 3 deletions(-)

 diff --git a/package/network/utils/comgt/Makefile
 b/package/network/utils/comgt/Makefile
 index 5324903..89a21be 100644
 --- a/package/network/utils/comgt/Makefile
 +++ b/package/network/utils/comgt/Makefile
 @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk

  PKG_NAME:=comgt
  PKG_VERSION:=0.32
 -PKG_RELEASE:=21
 +PKG_RELEASE:=22

  PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz
  PKG_SOURCE_URL:=@SF/comgt
 diff --git a/package/network/utils/comgt/files/3g.chat
 b/package/network/utils/comgt/files/3g.chat
 index a1fa2a0..6656240 100644
 --- a/package/network/utils/comgt/files/3g.chat
 +++ b/package/network/utils/comgt/files/3g.chat
 @@ -8,5 +8,5 @@ OK  ATE1
  OK  'AT+CGDCONT=1,IP,$USE_APN'
  SAY Calling UMTS/GPRS
  TIMEOUT 30
 -OK  ATD*99***1#
 +OK  ATD$DIALNUMBER
  CONNECT ' '
 diff --git a/package/network/utils/comgt/files/3g.sh
 b/package/network/utils/comgt/files/3g.sh
 index 2dc719b..deca2c9 100644
 --- a/package/network/utils/comgt/files/3g.sh
 +++ b/package/network/utils/comgt/files/3g.sh
 @@ -13,6 +13,7 @@ proto_3g_init_config() {
 proto_config_add_string apn
 proto_config_add_string service
 proto_config_add_string pincode
 +   proto_config_add_string dialnumber
  }

  proto_3g_setup() {
 @@ -23,6 +24,7 @@ proto_3g_setup() {
 json_get_var apn apn
 json_get_var service service
 json_get_var pincode pincode
 +   json_get_var dialnumber dialnumber

 [ -e $device ] || {
 proto_set_available $interface 0
 @@ -74,10 +76,15 @@ proto_3g_setup() {
 [ -n $SIERRA ]  {
 gcom -d $device -s
 /etc/gcom/getcarrier.gcom || return 1
 }
 +
 +   if [ -z $dialnumber ]; then
 +   dialnumber=*99***1#
 +   fi
 +
 ;;
 esac

 -   connect=${apn:+USE_APN=$apn }/usr/sbin/chat -t5 -v -E -f $chat
 +   connect=${apn:+USE_APN=$apn }DIALNUMBER=$dialnumber
 /usr/sbin/chat -t5 -v -E -f $chat
 ppp_generic_setup $interface \
 noaccomp \
 nopcomp \
 --
 1.8.4.5


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

[OpenWrt-Devel] Ruby 1.9.x in trunk - fix for bug 9873

[Luiz Angelo Daros de Luca]

Hello Hauke,

I noticed you updated ruby to version 1.9.3-p484. However, there is still a
serious bug for any network access.

https://dev.openwrt.org/ticket/9873

I created a patch sometime ago but it was not commited. Could you please
take a look
at

https://github.com/luizluca/openwrt-packages/compare/ruby-fix_network?expand=1

It also updates ruby to its latest 1.9.3.

Regards,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] high load without reason

[Luiz Angelo Daros de Luca]

There is one process/thread that is in a block state but uses no CPU. I got
similar behavior with a blocked syscall waiting for a SAN lun disk recover.
Probably your process has a blocked syscall. Is there any kernel oops dmesg?

Try to kill the remaining process. A blocked process will not die even with
-9.

Regards,
Em 24/04/2014 03:56, Bastian Bittorf bitt...@bluebottle.com escreveu:

 on some boxes we can see a high load, but i have
 no idea, what the cause of this:

 Mem: 27740K used, 1264K free, 0K shrd, 2160K buff, 9592K cached
 CPU:   0% usr   0% sys   0% nic  97% idle   0% io   0% irq   1% sirq
 Load average: 1.03 1.02 1.05 1/40 9974
   PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
  3305 1 root S 1628   6%   0% /usr/sbin/olsrd -f
 /var/etc/olsrd.con
  3671  1830 root S 1556   5%   0% /usr/sbin/pppd nodetach ipparam
 wan i
  9974  9939 root R 1360   5%   0% top
  9938  3049 root S 1168   4%   0% /usr/sbin/dropbear -F -P
 /var/run/dro
  3099 1 root S 1752   6%   0% /usr/sbin/uhttpd -f -h /www -r
 EG-lab
  2359 1 root S 1556   5%   0% /usr/sbin/hostapd -P
 /var/run/wifi-ph
  9939  9938 root S 1520   5%   0% -ash
  1830 1 root S 1500   5%   0% /sbin/netifd
  3273 1 root S 1372   5%   0% /usr/sbin/crond -L /dev/null
  2172  1830 root S 1368   5%   0% udhcpc -p /var/run/udhcpc-lo.pid
 -s /
 1 0 root S 1320   5%   0% /sbin/procd
  1799 1 root S 1288   4%   0% /sbin/logd -S 16
  3771 1 nobody   S 1176   4%   0% /usr/sbin/dnsmasq -C
 /var/etc/dnsmasq
  9221 1 root S 1168   4%   0% /usr/sbin/ulogd -d
  1849 1 root S 1156   4%   0% /usr/sbin/odhcpd
  3049 1 root S 1100   4%   0% /usr/sbin/dropbear -F -P
 /var/run/dro
  3774  3771 root S  976   3%   0% /usr/sbin/dnsmasq -C
 /var/etc/dnsmasq
   378 1 root S  884   3%   0% /sbin/ubusd
 ^C722  1830 root S  804   3%   0% odhcp6c -s
 /lib/netifd/dhcpv6.script

 even after ending most of the daemons (wifi down,
 olsrd/odhcpc/uhttpd/log stop, ifdown wan + sleep 30) the load remains:

   PID USER   VSZ STAT COMMAND
 1 root  1320 S/sbin/procd
 2 root 0 SW   [kthreadd]
 3 root 0 SW   [ksoftirqd/0]
 5 root 0 SW  [kworker/0:0H]
 7 root 0 SW  [khelper]
 8 root 0 SW   [kworker/u2:1]
58 root 0 SW  [writeback]
60 root 0 SW  [bioset]
62 root 0 SW  [kblockd]
92 root 0 SW   [kswapd0]
   137 root 0 SW   [fsnotify_mark]
   152 root 0 SW  [ath79-spi]
   161 root 0 SW   [kworker/u2:2]
   229 root 0 SW  [deferwq]
   233 root 0 SW  [kworker/0:1H]
   234 root 0 SW   [kworker/0:2]
   284 root 0 DW   [khubd]
   319 root 0 SWN  [jffs2_gcd_mtd3]
   378 root   884 S/sbin/ubusd
  1704 root 0 SW  [cfg80211]
  1830 root  1504 S/sbin/netifd
  3049 root  1100 S/usr/sbin/dropbear -F -P /var/run/dropbear.1.pid
 -p 22
  9938 root  1168 S/usr/sbin/dropbear -F -P /var/run/dropbear.1.pid
 -p 22
  9939 root  1524 S-ash
 10204 root 0 SW   [kworker/0:0]
 10403 root   772 S/sbin/askfirst ttyS0 /bin/ash --login
 10994 root  1356 Rps

 LOAD:
 08:45:02 up  4:31,  load average: 1.10, 1.05, 1.05

 the tool 'top' shows nothing, but idle:98%
 OpenWrt is: r40295 on TP-LINK TL-WR1043ND

 the box is responsive and i'am connected via wifi, everything is
 working: just the load is high. can it be procd? (unsure, if the load
 of PID-1 is shown correctly). what can i do to debug further?

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

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

Re: [OpenWrt-Devel] high load without reason

[Luiz Angelo Daros de Luca]

Second look. Check if khubd keeps state D (uninterruptible sleep). Maybe a
USB device caused it.
Em 24/04/2014 04:42, Luiz Angelo Daros de Luca luizl...@gmail.com
escreveu:

There is one process/thread that is in a block state but uses no CPU. I got
similar behavior with a blocked syscall waiting for a SAN lun disk recover.
Probably your process has a blocked syscall. Is there any kernel oops dmesg?

Try to kill the remaining process. A blocked process will not die even with
-9.

Regards,
Em 24/04/2014 03:56, Bastian Bittorf bitt...@bluebottle.com escreveu:

on some boxes we can see a high load, but i have
 no idea, what the cause of this:

 Mem: 27740K used, 1264K free, 0K shrd, 2160K buff, 9592K cached
 CPU:   0% usr   0% sys   0% nic  97% idle   0% io   0% irq   1% sirq
 Load average: 1.03 1.02 1.05 1/40 9974
   PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
  3305 1 root S 1628   6%   0% /usr/sbin/olsrd -f
 /var/etc/olsrd.con
  3671  1830 root S 1556   5%   0% /usr/sbin/pppd nodetach ipparam
 wan i
  9974  9939 root R 1360   5%   0% top
  9938  3049 root S 1168   4%   0% /usr/sbin/dropbear -F -P
 /var/run/dro
  3099 1 root S 1752   6%   0% /usr/sbin/uhttpd -f -h /www -r
 EG-lab
  2359 1 root S 1556   5%   0% /usr/sbin/hostapd -P
 /var/run/wifi-ph
  9939  9938 root S 1520   5%   0% -ash
  1830 1 root S 1500   5%   0% /sbin/netifd
  3273 1 root S 1372   5%   0% /usr/sbin/crond -L /dev/null
  2172  1830 root S 1368   5%   0% udhcpc -p /var/run/udhcpc-lo.pid
 -s /
 1 0 root S 1320   5%   0% /sbin/procd
  1799 1 root S 1288   4%   0% /sbin/logd -S 16
  3771 1 nobody   S 1176   4%   0% /usr/sbin/dnsmasq -C
 /var/etc/dnsmasq
  9221 1 root S 1168   4%   0% /usr/sbin/ulogd -d
  1849 1 root S 1156   4%   0% /usr/sbin/odhcpd
  3049 1 root S 1100   4%   0% /usr/sbin/dropbear -F -P
 /var/run/dro
  3774  3771 root S  976   3%   0% /usr/sbin/dnsmasq -C
 /var/etc/dnsmasq
   378 1 root S  884   3%   0% /sbin/ubusd
 ^C722  1830 root S  804   3%   0% odhcp6c -s
 /lib/netifd/dhcpv6.script

 even after ending most of the daemons (wifi down,
 olsrd/odhcpc/uhttpd/log stop, ifdown wan + sleep 30) the load remains:

   PID USER   VSZ STAT COMMAND
 1 root  1320 S/sbin/procd
 2 root 0 SW   [kthreadd]
 3 root 0 SW   [ksoftirqd/0]
 5 root 0 SW  [kworker/0:0H]
 7 root 0 SW  [khelper]
 8 root 0 SW   [kworker/u2:1]
58 root 0 SW  [writeback]
60 root 0 SW  [bioset]
62 root 0 SW  [kblockd]
92 root 0 SW   [kswapd0]
   137 root 0 SW   [fsnotify_mark]
   152 root 0 SW  [ath79-spi]
   161 root 0 SW   [kworker/u2:2]
   229 root 0 SW  [deferwq]
   233 root 0 SW  [kworker/0:1H]
   234 root 0 SW   [kworker/0:2]
   284 root 0 DW   [khubd]
   319 root 0 SWN  [jffs2_gcd_mtd3]
   378 root   884 S/sbin/ubusd
  1704 root 0 SW  [cfg80211]
  1830 root  1504 S/sbin/netifd
  3049 root  1100 S/usr/sbin/dropbear -F -P /var/run/dropbear.1.pid
 -p 22
  9938 root  1168 S/usr/sbin/dropbear -F -P /var/run/dropbear.1.pid
 -p 22
  9939 root  1524 S-ash
 10204 root 0 SW   [kworker/0:0]
 10403 root   772 S/sbin/askfirst ttyS0 /bin/ash --login
 10994 root  1356 Rps

 LOAD:
 08:45:02 up  4:31,  load average: 1.10, 1.05, 1.05

 the tool 'top' shows nothing, but idle:98%
 OpenWrt is: r40295 on TP-LINK TL-WR1043ND

 the box is responsive and i'am connected via wifi, everything is
 working: just the load is high. can it be procd? (unsure, if the load
 of PID-1 is shown correctly). what can i do to debug further?

 bye, bastian
 ___
 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] Missing subtargets of x86 in snapshot/trunk

[Luiz Angelo Daros de Luca]

Hello,

I noticed that there is no subtarget in
http://downloads.openwrt.org/snapshots/trunk/x86/
If resource is not a problem, it would be nice to have subtargets for
testing. I'm specially interested in xen_domu.

AA has all subtarget in repo

Regards,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Fix xen domU kmod-xen-kbd package

[Luiz Angelo Daros de Luca]

Since kernel 2.6.39, XEN_KBDDEV_FRONTEND was renamed to 
INPUT_XEN_KBDDEV_FRONTEND. See:

  http://cateee.net/lkddb/web-lkddb/INPUT_XEN_KBDDEV_FRONTEND.html
  http://cateee.net/lkddb/web-lkddb/XEN_KBDDEV_FRONTEND.html

Currently, this results in an empty file in BB:

  WARNING: kmod-xen-kbddev is not available in the kernel config - generating 
empty package

Besides renaming the CONFIG_xxx flag, the patch also fixes the module path and 
adds necessary dependencies
in CONFIG_xxx and opkg

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
---
 package/kernel/linux/modules/virtual.mk | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/package/kernel/linux/modules/virtual.mk 
b/package/kernel/linux/modules/virtual.mk
index e1bbe3f..add2b21 100644
--- a/package/kernel/linux/modules/virtual.mk
+++ b/package/kernel/linux/modules/virtual.mk
@@ -142,9 +142,13 @@ $(eval $(call KernelPackage,xen-fbdev))
 define KernelPackage/xen-kbddev
   SUBMENU:=$(VIRTUAL_MENU)
   TITLE:=Xen virtual keyboard and mouse
-  DEPENDS:=@TARGET_x86_xen_domu
-  KCONFIG:=CONFIG_XEN_KBDDEV_FRONTEND
-  FILES:=$(LINUX_DIR)/drivers/input/xen-kbdfront.ko
+  DEPENDS:=@TARGET_x86_xen_domu +kmod-input-core
+  KCONFIG:= \
+   CONFIG_INPUT \
+   CONFIG_INPUT_MISC \
+   CONFIG_XEN \
+   CONFIG_INPUT_XEN_KBDDEV_FRONTEND
+  FILES:=$(LINUX_DIR)/drivers/input/misc/xen-kbdfront.ko
   AUTOLOAD:=$(call AutoLoad,08,xen-kbdfront)
 endef
 
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Fix xen domU kmod-xen-kbd package

[Luiz Angelo Daros de Luca]

Tested on xen-4.2.3_02-0.7.1.

It used to work before because xen-kbddev is optional, maybe only used for
mouse/GUI.

The driver now loads correctly:

[4.865685] input: Xen Virtual Keyboard as /devices/virtual/input/input0
[4.866167] input: Xen Virtual Pointer as /devices/virtual/input/input1

Can anyone with commit access take a look?


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2014-05-26 22:20 GMT-03:00 Luiz Angelo Daros de Luca luizl...@gmail.com:

 Since kernel 2.6.39, XEN_KBDDEV_FRONTEND was renamed to
 INPUT_XEN_KBDDEV_FRONTEND. See:

   http://cateee.net/lkddb/web-lkddb/INPUT_XEN_KBDDEV_FRONTEND.html
   http://cateee.net/lkddb/web-lkddb/XEN_KBDDEV_FRONTEND.html

 Currently, this results in an empty file in BB:

   WARNING: kmod-xen-kbddev is not available in the kernel config -
 generating empty package

 Besides renaming the CONFIG_xxx flag, the patch also fixes the module path
 and adds necessary dependencies
 in CONFIG_xxx and opkg

 Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
 ---
  package/kernel/linux/modules/virtual.mk | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git 
 a/package/kernel/linux/modules/virtual.mkb/package/kernel/linux/modules/
 virtual.mk
 index e1bbe3f..add2b21 100644
 --- a/package/kernel/linux/modules/virtual.mk
 +++ b/package/kernel/linux/modules/virtual.mk
 @@ -142,9 +142,13 @@ $(eval $(call KernelPackage,xen-fbdev))
  define KernelPackage/xen-kbddev
SUBMENU:=$(VIRTUAL_MENU)
TITLE:=Xen virtual keyboard and mouse
 -  DEPENDS:=@TARGET_x86_xen_domu
 -  KCONFIG:=CONFIG_XEN_KBDDEV_FRONTEND
 -  FILES:=$(LINUX_DIR)/drivers/input/xen-kbdfront.ko
 +  DEPENDS:=@TARGET_x86_xen_domu +kmod-input-core
 +  KCONFIG:= \
 +   CONFIG_INPUT \
 +   CONFIG_INPUT_MISC \
 +   CONFIG_XEN \
 +   CONFIG_INPUT_XEN_KBDDEV_FRONTEND
 +  FILES:=$(LINUX_DIR)/drivers/input/misc/xen-kbdfront.ko
AUTOLOAD:=$(call AutoLoad,08,xen-kbdfront)
  endef

 --
 1.9.1


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

Re: [OpenWrt-Devel] [PATCH] Compile xen-pci-frontend as module

[Luiz Angelo Daros de Luca]

Tested on xen-4.2.3_02-0.7.1

xen-pcifront.ko is only used for PCI Passthrough and not necessary for
normal network/block usage.
Before this, this module was bulltin in kernel

Can anyone with commit access take a look at this?


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2014-05-27 17:47 GMT-03:00 luizl...@gmail.com:

 From: Luiz Angelo Daros de Luca luizl...@gmail.com

 There is a package for /drivers/pci/xen-pcifront.ko (kmod-xen-pcidev)
 However, the kernel module was defined to be built-in and not loadable.
 (Is there any special reason?)
 This patch changes (back?) the xen-pcifront.ko to loadable module

 Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
 ---
  target/linux/x86/xen_domu/config-3.10 | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/target/linux/x86/xen_domu/config-3.10
 b/target/linux/x86/xen_domu/config-3.10
 index 4b7c80f..cf4a8d5 100644
 --- a/target/linux/x86/xen_domu/config-3.10
 +++ b/target/linux/x86/xen_domu/config-3.10
 @@ -69,7 +69,7 @@ CONFIG_XEN_GRANT_DEV_ALLOC=m
  CONFIG_XEN_HAVE_PVMMU=y
  CONFIG_XEN_MAX_DOMAIN_MEMORY=64
  # CONFIG_XEN_NETDEV_FRONTEND is not set
 -CONFIG_XEN_PCIDEV_FRONTEND=y
 +CONFIG_XEN_PCIDEV_FRONTEND=m
  CONFIG_XEN_PRIVCMD=m
  # CONFIG_XEN_PRIVILEGED_GUEST is not set
  CONFIG_XEN_PVHVM=y
 --
 1.8.4.5


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

Re: [OpenWrt-Devel] How to bridge 2 Wifi subnet

[Luiz Angelo Daros de Luca]

I assume that there is a NAT between WAN and LAN. So, you need to connect
the two LAN.

option 1: bridge over wireless:
- use the same ssid/pass for both
- bridge them using an WDS network, one being the client and the other one
the master
- unplug the wan cable at the wds client
- disable DHCP on the wds client
- be happy

option 2: bridge using the LAN
- connect a cable from a LAN port at router 1 to a LAN port at router 2
- unplug the wan cable at the wds client
- disable DHCP on the wds client
- be happy

option 3: use routers as AP (If the NAT is not desired)
- disable all DHCP on your routers
- plug the routers to the wired network using the LAN interface and not WAN.
- set IP address for both inside the wired ip range

Regards,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/1/29 Nguyễn Hồng Quân quanngu...@mbm.vn

 Hello,

 Here is the picture for my question: http://i.imgur.com/pFwuhsZ.png

 Two Wifi network A  B have same IP range (192.168.2.x) but separated.
 Two routers connect to the same wired network via their WAN interface.

 How can I bridge these two A  B network (with OpenWrt) so that:
 - The IP is provided by one DHCP server in one router.
 - Client in network A can ping to client in network B and vice versa.
 - Can set the same ESSIS for two routers, so that user see only 1 ESSID
 in his wifi list.

 Is it possible to use DHCP server of wired network to provide IP for AB
 clients?

 Thanks in advance.

 --
 Regards,
 Quân

 Y!IM: ng_hquan_vn
 GTalk: ng.hong.quan

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

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

[OpenWrt-Devel] [PATCH] [kernel] create packages for LP and HTCP TCP congestion algorithms

[Luiz Angelo Daros de Luca]

This patch creates packages for the tcp_lp and tcp_htcp congestion algorithms.
tcp_lp is used for low priority traffic (like torrents) and can be integrated 
with
transmission. tcp_htcp is used for high speed networks with high latency.

All kernel code is already mainstream and normally compiled as module for 
desktop distributions.

Even when loaded, these algorithms would not be available if not enabled by 
net.ipv4.tcp_allowed_congestion_control.
And they will not be used unless defined as default algorithm at 
net.ipv4.tcp_congestion_control or explicitly 
selected by program code (as transmission allows with option 
peer-congestion-algorithm: lp).

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com

Index: package/kernel/modules/netsupport.mk
===
--- package/kernel/modules/netsupport.mk(revisão 36276)
+++ package/kernel/modules/netsupport.mk(cópia de trabalho)
@@ -889,3 +889,38 @@
 
 $(eval $(call KernelPackage,slip))
 
+define KernelPackage/tcp_lp
+  SUBMENU:=$(NETWORK_SUPPORT_MENU)
+  TITLE:=TCP LP
+  KCONFIG:= \
+   CONFIG_TCP_CONG_LP
+  FILES:= \
+   $(LINUX_DIR)/net/ipv4/tcp_lp.ko
+  AUTOLOAD:=$(call AutoLoad,30,tcp_lp)
+endef
+
+define KernelPackage/tcp_lp/description
+ Kernel modules for TCP LP (Low Priority) congestion control algorithm
+endef
+
+$(eval $(call KernelPackage,tcp_lp))
+
+define KernelPackage/tcp_htcp
+  SUBMENU:=$(NETWORK_SUPPORT_MENU)
+  TITLE:=TCP HTCP
+  KCONFIG:= \
+   CONFIG_TCP_CONG_HTCP
+  FILES:= \
+   $(LINUX_DIR)/net/ipv4/tcp_htcp.ko
+  AUTOLOAD:=$(call AutoLoad,30,tcp_htcp)
+endef
+
+define KernelPackage/tcp_htcp/description
+ Kernel modules for TCP H-TCP congestion control algorithm for high speed 
networks with high latency
+endef
+
+$(eval $(call KernelPackage,tcp_htcp))
+
+
+
+
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

Hello,

I reported a bug that prevents partitions in a large disk (1.5TB) to be
used here:
https://dev.openwrt.org/ticket/13420

I already isolated it to this line:

/block/partitions/msdos.c:

this_sector = first_sector + start_sect(p) * sector_size;

And some printk show their values:

[   98.23] parse_extended: sector_size = 1
[   98.23] parse_extended: start_sect(p) = 2147488875
[   98.23] parse_extended: start_sect(p)*sector_size = 2147488875
[   98.24] parse_extended: first_sector = 125853210
[   98.25] parse_extended: first_sector + start_sect(p) * sector_size =
this_sector = 18446744071687926405

The correct output would be 2273342085 and not 18446744071687926405.
Comparing both, the  MSB 32bit of first_sector becomes all 1.

2273342085   = 0x87807285
18446744071687926405 = 0x87807285

Any idea of why? Maybe this has something to do with
target/linux/ar71xx/patches-3.3/902-unaligned_access_hacks.patch?

Thanks,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

The usage of sign-extension might be cause. The problem is that all these
variables are sector_t, which as far as I know, is a u64.
Even if it was using signed variable, all of them are 64bit and using
values much lower that 2^63.

As mips is not a 64-bit processor, the compiler must do it by parts. So,
where is this problem from? Compiler? Kernel?

I guess no one faced this problem before because it might be rare to
someone have a logical partition over 2147483648 sectors (2^31),
or a little over 1TB (1099 GB), in a arch for embebed systems.

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/4/27 David Newall open...@davidnewall.com

 On 27/04/13 11:15, Luiz Angelo Daros de Luca wrote:


 The correct output would be 2273342085 and not 18446744071687926405.
 Comparing both, the  MSB 32bit of first_sector becomes all 1.

 2273342085   = 0x87807285
 18446744071687926405 = 0x87807285

 Any idea of why? Maybe this has something to do with
 target/linux/ar71xx/patches-3.**3/902-unaligned_access_hacks.**patch?


 Looks very much like sign-extension when converting a 32-bit negative
 value to 64-bit.

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

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

Hello,

I checked sizeof(sector_t) and it is 8. The assembly code I get is similar
to what Sergey posted.
If it really is a compiler problem, which are the options? Would removing
the inline help?


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/4/27 Sergey Vlasov v...@altlinux.ru

 On Sat, Apr 27, 2013 at 02:09:22AM -0300, Luiz Angelo Daros de Luca wrote:
  The usage of sign-extension might be cause. The problem is that all these
  variables are sector_t, which as far as I know, is a u64.
  Even if it was using signed variable, all of them are 64bit and using
  values much lower that 2^63.
 
  As mips is not a 64-bit processor, the compiler must do it by parts. So,
  where is this problem from? Compiler? Kernel?

 Seems that at least gcc-4.6-linaro from AA (mips-openwrt-linux-gcc
 (Linaro GCC 4.6-2012.02) 4.6.3 20120201 (prerelease),
 PKG_MD5SUM:=2b7887846f8e5ac1ca58fe4dfaabf5a6) is buggy.  Here is a
 self-contained test case:

 madd.c:

 =
 typedef unsigned long long u64;
 typedef unsigned long u32;
 typedef unsigned char u8;

 static inline u32 get_unaligned_le32(const u8 *p)
 {
 return p[0] | p[1]  8 | p[2]  16 | p[3]  24;
 }

 static inline u64 my_get_le32(const void *p)
 {
 return (u64)get_unaligned_le32(p);
 }

 u64 test_fn(u64 arg1, void *arg2, void *arg3)
 {
 return arg1 + my_get_le32(arg2)*my_get_le32(arg3);
 }

 =

 When I compile this file with:

   $STAGING_DIR/bin/mips-openwrt-linux-gcc -march=mips32r2 -S -O2 -Wall -W
 madd.c

 I get the following output in madd.s:


 =
 .file   1 madd.c
 .section .mdebug.abi32
 .previous
 .gnu_attribute 4, 3
 .abicalls
 .option pic0
 .text
 .align  2
 .globl  test_fn
 .setnomips16
 .enttest_fn
 .type   test_fn, @function
 test_fn:
 .frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp=
 0
 .mask   0x,0
 .fmask  0x,0
 .setnoreorder
 .setnomacro
 lbu $11,1($6)
 lbu $2,2($6)
 lbu $3,2($7)
 lbu $12,1($7)
 lbu $10,0($6)
 lbu $9,3($6)
 lbu $8,0($7)
 lbu $6,3($7)
 sll $11,$11,8
 sll $7,$12,8
 sll $2,$2,16
 sll $3,$3,16
 or  $2,$11,$2
 or  $3,$7,$3
 or  $2,$2,$10
 sll $7,$9,24
 or  $3,$3,$8
 sll $6,$6,24
 mtlo$5
 or  $2,$2,$7
 or  $3,$3,$6
 mthi$4
 madd$3,$2
 mflo$3
 j   $31
 mfhi$2

 .setmacro
 .setreorder
 .endtest_fn
 .size   test_fn, .-test_fn
 .ident  GCC: (Linaro GCC 4.6-2012.02) 4.6.3 20120201 (prerelease)

 =

 The madd $3,$2 command here is incorrect - it performs sign
 extension of its arguments; it should be maddu $3,$2.

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


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

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

I was curious about the undefined. I found the text:

   The integer promotions are performed on each of the operands. The type
of the result is
   that of the promoted left operand. If the value of the right operand is
negative or is
   greater than or equal to the width of the promoted left operand, the
behavior is undefined.

So, as left operand is 8bit, the right operant must not be over 8. Does a
simple typecast solves it?

return (u32)((u32)p[0] | (u32)p[1]  8 | (u32)p[2]  16 | (u32)p[3] 
24);






---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/4/27 Sergey Vlasov v...@altlinux.ru

 On Sat, Apr 27, 2013 at 09:24:41PM +0200, Wojciech Kromer wrote:
 
   Note that adding an explicit u32 cast avoids the problem even with a
 buggy
   compiler:
  
   static inline u32 get_unaligned_le32(const u8 *p)
   {
   return (u32)p[0] | p[1]  8 | p[2]  16 | p[3]  24;
   }
  
  Generally it's a good idea to write explicit type conversions like in
  this example.
  Poor precompiler/optimizer could treat inline just like a macro (which
  is wrong)
 
  Without that (u32) first conversion in this code is probably not
  specified so it is defaulted to int.
  With a buggy version we probably have:
 ( (int)p[0] | p[1]  8 | p[2]  16 | p[3]  24 )
  as a result.

 Even worse - every operand is first promoted to int, and if you read
 the C99 standard literally, the behavior of p[3]  24 is undefined if
 p[3] = 128.  But I cannot imagine that compiler developers could dare
 to break such code deliberately.

  Of course conversion should be found as function return type.

 Yes, and putting an explicit conversion around the whole expression:

 return (u32)(p[0] | p[1]  8 | p[2]  16 | p[3]  24);

 does NOT change the generated code at all.

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


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

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

Hello Wojciech,

I'm really no gcc expert and, please, correct if I'm wrong. Maybe the
problem lies when gcc is evaluating the
 | p[2]  16 | p[3]  24;  part. As  has precedence over |, it is
evaluated before.
At that time, the evaluated expression would be p[3]  24 and
the left operator will be u8, which leads to the commented undefined
behavior. With undefined behavior, nothing else matters.
Maybe gcc was only expecting an unsigned 8-bit output and, that's why
it accepted to use 32 bit signed operator. Indeed,
I also believe that the compiler could be a little bit more heuristic, like
opting for unsigned operator when signed and unsigned are possible
and operators are all unsigned.

I'll try this typecast patch for my problem tomorrow.

--- linux-3.3.8/include/./linux/unaligned/le_byteshift.h.old 2013-04-28
03:09:46.220538584 -0300
+++ linux-3.3.8/include/./linux/unaligned/le_byteshift.h 2013-04-28
03:10:54.232538576 -0300
@@ -5,12 +5,12 @@

 static inline u16 __get_unaligned_le16(const u8 *p)
 {
- return p[0] | p[1]  8;
+ return (u16)p[0] | (u16)p[1]  8;
 }

 static inline u32 __get_unaligned_le32(const u8 *p)
 {
- return p[0] | p[1]  8 | p[2]  16 | p[3]  24;
+ return (u32)p[0] | (u32)p[1]  8 | (u32)p[2]  16 | (u32)p[3]  24;
 }

 static inline u64 __get_unaligned_le64(const u8 *p)


This might affect other archs that does not have a cpu instruction for
le-be conversion. I also changed the 16 version, as it has
the same undefined behavior problem. However, I think that this would only
trigger a bug if used on 16 processor.
I guess x86 has an cpu instruction (bswap?) and it is not affected at all.

Regards,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/4/28 Wojciech Kromer wojciech.kro...@dgt.com.pl


  So, as left operand is 8bit, the right operant must not be over 8. Does
 a simple typecast solves it?

  return (u32)((u32)p[0] | (u32)p[1]  8 | (u32)p[2]  16 | (u32)p[3] 
 24);


 return (u32)p[0] | (u32)p[1]  8 | (u32)p[2]  16 | (u32)p[3]  24;
 is correct for all compilers, and this version should be used

 anyway

 return (u32)p[0] | p[1]  8 | p[2]  16 | p[3]  24;

 is fair enough, because in gcc default typecast tights to the left
 expression in maths

 and also in gcc this typecast SHOULD default to return type,
 but does not in some versions as we can see here

 best regards

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


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

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

Hello,

I tested the patch and it works. I can see all partitions inside my disk. I
just cleaned the first typecast as it was useless and I'll send in a
cleaner patch email to this list.

Now what would be the next steps? Is it worth to submit to gcc? Should I
submit this directly to kernel mainstream?

I also looked for usages of this function. The bug will affect any arch
that does not use an cpu instruction for le/be conversion and for any use
of get_unaligned_le32, get_unaligned_le for 32bit or 64bit functions (that
uses 32bit version twice), get_unaligned for 32bit or 64bit functions when
running on little endian systems, and any derivated macro
like SYS_IND(p), flat_get_addr_from_rp, NL_INTEGER, NL_INT64. This list
might not be complete. For .c files, my rough search found these:

./linux-3.3.8/arch/blackfin/kernel/flat.c
./linux-3.3.8/arch/sh/kernel/dwarf.c
./linux-3.3.8/arch/sh/kernel/module.c
./linux-3.3.8/arch/unicore32/boot/compressed/misc.c
./linux-3.3.8/arch/x86/boot/compressed/mkpiggy.c
./linux-3.3.8/arch/x86/boot/tools/build.c
./linux-3.3.8/block/partitions/ldm.c
./linux-3.3.8/block/partitions/msdos.c
./linux-3.3.8/crypto/camellia.c
./linux-3.3.8/drivers/block/aoe/aoecmd.c
./linux-3.3.8/drivers/block/aoe/aoenet.c
./linux-3.3.8/drivers/block/drbd/drbd_nl.c
./linux-3.3.8/drivers/block/osdblk.c
./linux-3.3.8/drivers/bluetooth/hci_bcsp.c
./linux-3.3.8/drivers/char/snsc_event.c

Specially, the non arch part is important.


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/4/28 Sergey Vlasov v...@altlinux.ru

 On Sat, Apr 27, 2013 at 08:55:35PM -0300, Luiz Angelo Daros de Luca wrote:
  I was curious about the undefined. I found the text:
 
 The integer promotions are performed on each of the operands. The
 type of the result is that of the promoted left operand. If the
 value of the right operand is negative or is greater than or
 equal to the width of the promoted left operand, the behavior is
 undefined.

 Actually this part is not the problem here - the unsigned char
 argument will be promoted to int before the shift operation, and the
 width of int is 32 on all platforms currently supported by mainline
 Linux, therefore left shift by 24 bits is allowed.  The problem is the
 next paragraph:

The result of E1  E2 is E1 left-shifted E2 bit positions; vacated
bits are filled with zeros. If E1 has an unsigned type, the value
of the result is E1 * 2^E2 , reduced modulo one more than the
maximum value representable in the result type. If E1 has a signed
type and nonnegative value, and E1 * 2^E2 is representable in the
result type, then that is the resulting value; otherwise, the
behavior is undefined.

 Therefore (0x80  24) is undefined, because 0x8000 is not
 representable as a 32-bit signed int.  Apparently the intent here is
 to outlaw any form of signed integer overflow (note that the behavior
 of right shifts applied to negative signed integer values is not
 undefined, but implementation-defined - probably because this
 operation does not involve overflow).

 Note that the older C89 standard did not declare such left shift
 operations as undefined.

 GCC 4.8.0 documentation says that it currently does not treat
 overflowing left shifts of signed values as undefined:

   http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Integers-implementation.html

 However, some prerelease versions of gcc-4.8.0 had a bug related to
 such shift operations, which was fixed before the 4.8.0 release:

   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54027

 In particular, the comment 2 there says that the intent of GCC
 developers is to keep such shifts working.

  So, as left operand is 8bit, the right operant must not be over 8. Does a
  simple typecast solves it?
 
  return (u32)((u32)p[0] | (u32)p[1]  8 | (u32)p[2]  16 | (u32)p[3] 
  24);

 The outer typecast is not required at all (it will be performed during
 return anyway), and the only really required typecast according to the
 standard is the last one (other operations can be performed with
 signed int values, and the usual arithmetic conversions of signed
 int and unsigned int will result in unsigned int).

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


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

[OpenWrt-Devel] [PATCH] fix undefined behavior on get unaligned le

[Luiz Angelo Daros de Luca]

This patch fixes an undefined behavior problem that may lead to the function 
result be treated in some cases
as signed integer instead of unsigned. This affected ms-dos extended partition 
parsing for partitions that start
after sector 2^31 (or 1TB): https://dev.openwrt.org/ticket/13420
The function is only used for archs that does not implement the le/be 
conversion in hardware.

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com

Index: 
target/linux/generic/patches-3.3/141-fix_undefined_behavior_on_get_unaligned_le.patch
===
--- 
target/linux/generic/patches-3.3/141-fix_undefined_behavior_on_get_unaligned_le.patch
(revision 0)
+++ 
target/linux/generic/patches-3.3/141-fix_undefined_behavior_on_get_unaligned_le.patch
(working copy)
@@ -0,0 +1,17 @@
+--- linux-3.3.8/include/./linux/unaligned/le_byteshift.h.old2013-04-28 
03:09:46.220538584 -0300
 linux-3.3.8/include/./linux/unaligned/le_byteshift.h2013-04-28 
03:10:54.232538576 -0300
+@@ -5,12 +5,12 @@
+
+ static inline u16 __get_unaligned_le16(const u8 *p)
+ {
+-return p[0] | p[1]  8;
++return p[0] | (u16)p[1]  8;
+ }
+
+ static inline u32 __get_unaligned_le32(const u8 *p)
+ {
+-return p[0] | p[1]  8 | p[2]  16 | p[3]  24;
++return p[0] | (u32)p[1]  8 | (u32)p[2]  16 | (u32)p[3]  24;
+ }
+
+ static inline u64 __get_unaligned_le64(const u8 *p)

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

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

Thanks you all for the fix.

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/4/30 Jonas Gorski j...@openwrt.org

 On Mon, Apr 29, 2013 at 4:54 PM, Jonas Gorski j...@openwrt.org wrote:
  Still build testing, but as a addendum, vanilla 4.6.x is *not*
  affected, so selecting 4.6.3 instead of 4.6-linaro avoids the error,
  too.

 The fix is now committed to both trunk (r36486) and Attitude
 Adjustment (r36500) for all affected gcc versions. Thanks everyone for
 finding and reporting the bug and the simplified testcase, it helped a
 lot in identifying the bug.


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

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

[OpenWrt-Devel] [PATCH] packages: ruby: Fix network problem and update to 1.9.3p429

[Luiz Angelo Daros de Luca]

This patch solves the bug https://dev.openwrt.org/ticket/9873 that prevents the 
use of socket (and gems) in ruby
when crosscompiling. Also, it updates to latest 1.9.x version and remove 
unnecessary patches.

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com

Index: 
feeds/packages/lang/ruby/patches/0001-Add-option-which-enable-SSLv2-support.patch
===
--- 
feeds/packages/lang/ruby/patches/0001-Add-option-which-enable-SSLv2-support.patch
   (revision 36739)
+++ 
feeds/packages/lang/ruby/patches/0001-Add-option-which-enable-SSLv2-support.patch
   (working copy)
@@ -1,53 +0,0 @@
-From b983e73adf7a7d3fd07fdf493eee51c22881a6e6 Mon Sep 17 00:00:00 2001
-From: Nobuhiro Iwamatsu iwama...@nigauri.org
-Date: Wed, 6 Apr 2011 02:28:09 +0900
-Subject: [PATCH] Add option which enable SSLv2 support
-
-From openssl 1.0, SSLv2 becomes disable by default.
-If you want to use SSLv2 in ruby, you need config with --enable-opensslv2.
-The SSLv2 support is disable by default.
-
-Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org

- ext/openssl/extconf.rb |8 
- ext/openssl/ossl_ssl.c |2 ++
- 2 files changed, 10 insertions(+), 0 deletions(-)
-
-diff --git a/ext/openssl/extconf.rb b/ext/openssl/extconf.rb
-index b1f2d88..89c6f19 100644
 a/ext/openssl/extconf.rb
-+++ b/ext/openssl/extconf.rb
-@@ -33,6 +33,14 @@ if with_config(debug) or enable_config(debug)
-   end
- end
- 
-+## 
-+## From openssl 1.0, SSLv2 becomes disable by default.
-+## If you want to use SSLv2 in ruby, you need config with --enable-opensslv2.
-+##
-+if enable_config(opensslv2)
-+  $defs  -DENABLE_OPENSSLV2
-+end
-+
- message === Checking for system dependent stuff... ===\n
- have_library(nsl, t_open)
- have_library(socket, socket)
-diff --git a/ext/openssl/ossl_ssl.c b/ext/openssl/ossl_ssl.c
-index d8951fb..d0c9059 100644
 a/ext/openssl/ossl_ssl.c
-+++ b/ext/openssl/ossl_ssl.c
-@@ -107,9 +107,11 @@ struct {
- OSSL_SSL_METHOD_ENTRY(TLSv1),
- OSSL_SSL_METHOD_ENTRY(TLSv1_server),
- OSSL_SSL_METHOD_ENTRY(TLSv1_client),
-+#if defined(ENABLE_OPENSSLV2)
- OSSL_SSL_METHOD_ENTRY(SSLv2),
- OSSL_SSL_METHOD_ENTRY(SSLv2_server),
- OSSL_SSL_METHOD_ENTRY(SSLv2_client),
-+#endif
- OSSL_SSL_METHOD_ENTRY(SSLv3),
- OSSL_SSL_METHOD_ENTRY(SSLv3_server),
- OSSL_SSL_METHOD_ENTRY(SSLv3_client),
--- 
-1.7.4.1
-
Index: 
feeds/packages/lang/ruby/patches/000-ignore_wide_getaddrinfo_while_crosscompiling.patch
===
--- 
feeds/packages/lang/ruby/patches/000-ignore_wide_getaddrinfo_while_crosscompiling.patch
 (revision 0)
+++ 
feeds/packages/lang/ruby/patches/000-ignore_wide_getaddrinfo_while_crosscompiling.patch
 (working copy)
@@ -0,0 +1,10 @@
+--- a/ext/socket/extconf.rb2013-02-14 23:20:13.581918676 -0200
 b/ext/socket/extconf.rb2013-02-14 23:21:25.761918667 -0200
+@@ -125,6 +125,7 @@
+ have_type(PADDRINFO, %w[ ws2tcpip.h wspiapi.h ])
+ 
+ getaddr_info_ok = (enable_config(wide-getaddrinfo)  :wide) ||
++  (CROSS_COMPILING  :cross) ||
+   (checking_for(wide getaddrinfo) {try_run(EOF)}  :os)
+ #{cpp_include(headers)}
+ #include stdlib.h
Index: feeds/packages/lang/ruby/Makefile
===
--- feeds/packages/lang/ruby/Makefile   (revision 36739)
+++ feeds/packages/lang/ruby/Makefile   (working copy)
@@ -15,14 +15,14 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ruby
-PKG_VERSION:=1.9.2-p0
+PKG_VERSION:=1.9.3-p429
 PKG_RELEASE:=1
 
 PKG_LIBVER:=1.9
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=ftp://ftp.ruby-lang.org/pub/ruby/$(PKG_LIBVER)/
-PKG_MD5SUM:=d8a02cadf57d2571cd4250e248ea7e4b
+PKG_MD5SUM:=c2b2de5ef15ea9b1aaa3152f9112af1b
 
 PKG_BUILD_DEPENDS:=ruby/host
 PKG_INSTALL:=1
@@ -204,12 +204,8 @@
 
 CONFIGURE_ARGS += \
--enable-shared \
-   --enable-static \
--disable-rpath \
-   --enable-ipv6 \
-   --enable-wide-getaddrinfo \
-   --with-ruby-version=minor \
-   --with-iconv-dir=$(ICONV_PREFIX) \
+   --with-ruby-version=minor 
 
 TARGET_LDFLAGS += -L$(PKG_BUILD_DIR)
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] packages: curl: Allow fine grained protocol configuration

[Luiz Angelo Daros de Luca]

It looks like the default values matches the selected features in the
previous ./configure command.

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/7/2 Jonas Gorski j...@openwrt.org

 On Wed, May 29, 2013 at 9:52 AM, Helmut Schaa
 helmut.sc...@googlemail.com wrote:
  On Tue, May 14, 2013 at 11:19 AM, Helmut Schaa
  helmut.sc...@googlemail.com wrote:
  Disabling unused protocols in libcurl can save more then 100K, hence add
  some build time config options to enable/disable protocols.
 
  Any update on this patch?

 Do the default values match what is used when not explicitly set?
 Might make sense to not change the feature set of the built lib unless
 the user changes options, to keep surprises for users at a minimum.


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

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

Re: [OpenWrt-Devel] ruby - error: 'EC_GROUP_new_curve_GF2m' undeclared (first use in this function)

[Luiz Angelo Daros de Luca]

Hello Remzi,

I posted a patch to update ruby to its last 1.9.x version.

http://patchwork.openwrt.org/patch/3754/

However, it was not commited. The version of ruby you are using have
problems with socket.


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/7/29 Remzi AKYÜZ linuxli...@gmail.com

 Thanks a lot.
 On 07/29/2013 11:27 AM, Yousong Zhou wrote:
  Hi, Remzi,
 
  On 29 July 2013 09:10, Remzi AKYÜZ linuxli...@gmail.com wrote:
  Hi,
 
  I cannot build ruby at trunk (37568) and i got this;
 
  i486-openwrt-linux-uclibc-gcc -I. -I../../.ext/include/i486-linux
  -I../.././include -I../.././ext/openssl -DRUBY_EXTCONF_H=\extconf.h\
  -I/openwrt/trunk/staging_dir/target-i386_uClibc-0.9.33.2/usr/include
  -I/openwrt/trunk/staging_dir/target-i386_uClibc-0.9.33.2/include
 
 -I/openwrt/trunk/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/usr/include
 
 -I/openwrt/trunk/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/include
 
 -I/openwrt/trunk/staging_dir/target-i386_uClibc-0.9.33.2/usr/lib/libiconv-stub/include
 
 -I/openwrt/trunk/staging_dir/target-i386_uClibc-0.9.33.2/usr/lib/libintl-stub/include
  -D_FILE_OFFSET_BITS=64  -fPIC -O2 -pipe -march=i686 -fno-caller-saves
  -fhonour-copts -Wno-error=unused-but-set-variable
 
 -I/openwrt/trunk/staging_dir/target-i386_uClibc-0.9.33.2/usr/lib/libiconv-stub/include
 
 -I/openwrt/trunk/staging_dir/target-i386_uClibc-0.9.33.2/usr/lib/libintl-stub/include
  -fPIC  -o ossl_pkey_ec.o -c ossl_pkey_ec.c
  ossl_pkey_ec.c: In function 'ossl_ec_group_initialize':
  ossl_pkey_ec.c:761:24: warning: assignment makes pointer from integer
  without a cast [enabled by default]
  ossl_pkey_ec.c:815:29: error: 'EC_GROUP_new_curve_GF2m' undeclared
  (first use in this function)
  I guess you need to enable GF2m support for libopenssl build.
 
│   Location:
│ - Libraries
│   - SSL
│ - libopenssl... Open source
  SSL toolkit (libraries) (PACKAGE_libopenssl [=m])
│   - Configuration
│ - Enable elliptic curve support (OPENSSL_WITH_EC
 [=y])
 
  Then, Enable ec2m support.
 
  ossl_pkey_ec.c:815:29: note: each undeclared identifier is reported only
  once for each function it appears in
  make[5]: *** [ossl_pkey_ec.o] Error 1
  make[5]: Leaving directory
 
 `/openwrt/trunk/build_dir/target-i386_uClibc-0.9.33.2/ruby-1.9.2-p0/ext/openssl'
  make[4]: *** [mkmain.sh] Error 1
  make[4]: Leaving directory
  `/openwrt/trunk/build_dir/target-i386_uClibc-0.9.33.2/ruby-1.9.2-p0'
  make[3]: ***
 
 [/openwrt/trunk/build_dir/target-i386_uClibc-0.9.33.2/ruby-1.9.2-p0/.built]
  Error 2
  make[3]: Leaving directory `/openwrt/trunk/feeds/packages/lang/ruby'
 
 
 
  Thanks.
 
 
 
  ___
  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 mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] rationale behind pkg management/availability [was: binary package missing from 12.09 archive]

[Luiz Angelo Daros de Luca]

I would love a stable update repository for openwrt, with package updates,
specially if it includes some wireless fixes backported. For those
non-openwrt-dev that opt for
stable releases, they have to deal with bugs for months, years, before a
full release.

I already shared some package updates for some users but there is no
official repo to put them.

Only the kernel and some early booting code cannot be updated without a
reflash.
However, those are special cases and might not be too common.
Maybe even kernel builtin code could be fixed with something like Ksplice
;-)

BTW, I could never build a module that matches the opkg kernel version id
(the md5 part). Even copying kernel config.
Even using SDK package.


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/8/29 Paolo Pisati p.pis...@gmail.com

 Hi,

 what's the rationale behind some package (e.g. transmission) not being
 built for
 a release (e.g. 12.09)?


 http://downloads.openwrt.org/attitude_adjustment/12.09/x86/generic/packages/

 It's not marked as 'broken', so i don't see any reason why it shouldn't be
 built:

 https://dev.openwrt.org/browser/packages/net/transmission/Makefile

 Any chance we can see it hit the archive? Or is 12.09 packages archive
 frozen?

 Or shall i change my opkg.conf to point to trunk just after installation?
 IOW, what's the rationale behind pkg management/availability in openwrt?
 Do we stay on release after installation? Or do we need to add new
 repository to
 opkg.conf to get fresh content?

 I've always used to build my own version of openwrt and flash it to my
 device,
 but this time i tried a precooked version and the lack of some packages is
 puzzling me.
 --
 bye,
 p.
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] packages: enable ip on busybox

[Luiz Angelo Daros de Luca]

Someday the ip conversion must be dealt with.

First, I could not find all functions of netstat in ip command. Am I
missing something?
So, I guess it might be kept or replaced by another command (like ss).
As you guys know more than me, I'll consider ip can do whatever netstat
does.

If we drop ifconfig, netstat and route from busybox, the
ip from busybox must only need to replace the functions that
ifconfig, netstat and route does today. No need for more functions as
ip rule ACTION as, AFAIK, ifconfig, netstat and route cannot currently
deal with
rule at all. I guess we would need ip address, route, link.

Is the size of busybox with ip (only enabling functions on ip needed to
replaced ifconfig,
netstat and route) bigger than busybox with ifconfig, netstat and route,
without ip?

229047 bytes - busybox_1.19.4-7(standard openrt)
218418 bytes - busybox without ifconfig, netstat, route
?? bytes - busybox without ifconfig, netstat, route and with ip (I do
not have a clean and working build env to do it)

(these are .ipk size and not real squashfs usage but it gives a good idea)

The second problem is when someone wants to use the standard ip.
Today, it will use the extra 70kb. So, keeping requiring the extra space is
no
big deal. Here, we would have a file conflict between packages: busybox and
ip.
This conflict is a general problem. The same occurs for someone that wants
to install a full wget, full procps.
So, we need a pretty solution for multiple provides of a command. Something
like update-alternatives
does in Linux Desktop. This is not directly related to do with ip or not
ip.
Currently, I'm just a user of opkg install --force-overwrite but I feel
bad about --force*.

Also, I'm considering that all arguments, when present, work both with
busybox ip version and with standard ip the same way.

Regards,


---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/9/11 Bastian Bittorf bitt...@bluebottle.com

 * Patrick patr...@lunatiki.de [11.09.2013 07:57]:
   so we add ~80k to a standard built. i'am ok with this, because we
   also add a lot of features and possibilities which are simply not
   possible with ifconfig/route/netstat.
  I think you must compare busybox with ip, ifconfig, netstat and route.

 i did exactly this and showed, that: if we drop ifconfig, netstat and
 route from busybox and add 'ip', the image will grow ~80 Kilobytes.
 (more than 1 eraseblock).

 bye, bastian
 ___
 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] issue: usb1.x not detected in CC

[Luiz Angelo Daros de Luca]

Hello,

I'm running OpenWRT in Virtualbox. I have no problem with BB. However, when
testing trunk, I noticed that usb1.x functions simply does not work.

For BB, in a clean install (+usbutils), I get:
https://downloads.openwrt.org/barrier_breaker/14.07/x86/generic/openwrt-x86-generic-combined-ext4.img.gz

root@OpenWrt:/# lsusb
*Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet*
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
*Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub*

root@OpenWrt:/# dmesg | egrep -i '(usb|hci)'
[0.063968] ACPI: bus type USB registered
[0.064573] usbcore: registered new interface driver usbfs
[0.065292] usbcore: registered new interface driver hub
[0.065990] usbcore: registered new device driver usb
[0.511884] ahci :00:0d.0: version 3.0
[0.513388] ahci: SSS flag set, parallel bus scan disabled
[0.514182] ahci :00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps
0x1 impl SATA mode
[0.515223] ahci :00:0d.0: flags: 64bit ncq stag only ccc
[0.515945] ahci :00:0d.0: setting latency timer to 64
[0.516085] scsi0 : ahci
[0.521108] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[0.522068] ehci-pci: EHCI PCI platform driver
[0.523007] ehci-pci :00:0b.0: setting latency timer to 64
[0.523015] ehci-pci :00:0b.0: EHCI Host Controller
[0.523673] ehci-pci :00:0b.0: new USB bus registered, assigned bus
number 1
[0.524738] ehci-pci :00:0b.0: irq 10, io mem 0xf084
[0.540886] ehci-pci :00:0b.0: USB 2.0 started, EHCI 1.00
*[0.541668] hub 1-0:1.0: USB hub found*
[0.542882] ehci-platform: EHCI generic platform driver
[0.543609] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[0.544824] ohci_hcd :00:06.0: setting latency timer to 64
[0.544831] ohci_hcd :00:06.0: OHCI Host Controller
[0.545495] ohci_hcd :00:06.0: new USB bus registered, assigned bus
number 2
[0.546662] ohci_hcd :00:06.0: irq 11, io mem 0xf0804000
*[0.600350] hub 2-0:1.0: USB hub found*
[0.602055] uhci_hcd: USB Universal Host Controller Interface driver
[0.603133] usbcore: registered new interface driver usb-storage
[1.040233] usb 2-1: new full-speed USB device number 2 using ohci_hcd

And for CC, in a clean install (+usbutils), I get:
https://downloads.openwrt.org/snapshots/trunk/x86/openwrt-x86-generic-combined-ext4.img.gz

root@OpenWrt:/# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@OpenWrt:/# dmesg | egrep -i '(usb|hci)'
[0.207085] ACPI: bus type USB registered
[0.208234] usbcore: registered new interface driver usbfs
[0.210038] usbcore: registered new interface driver hub
[0.211447] usbcore: registered new device driver usb
[0.846969] ahci :00:0d.0: version 3.0
[0.850123] ahci :00:0d.0: SSS flag set, parallel bus scan disabled
[0.851991] ahci :00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps
0x1 impl SATA mode
[0.854051] ahci :00:0d.0: flags: 64bit ncq stag only ccc
[0.855726] scsi0 : ahci
[0.865267] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[0.866641] ehci-pci: EHCI PCI platform driver
[0.868536] ehci-pci :00:0b.0: EHCI Host Controller
[0.870011] ehci-pci :00:0b.0: new USB bus registered, assigned bus
number 1
[0.872088] ehci-pci :00:0b.0: irq 10, io mem 0xf0806000
[0.890021] ehci-pci :00:0b.0: USB 2.0 started, EHCI 1.00
*[0.891475] hub 1-0:1.0: USB hub found*
[0.910106] ehci-platform: EHCI generic platform driver
[0.911554] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[0.913104] ohci-platform: OHCI generic platform driver
[0.914517] uhci_hcd: USB Universal Host Controller Interface driver
[0.916619] usbcore: registered new interface driver usb-storage

In CC, there is no Linux Foundation 1.1 root hub. Only EHCI hub is
detected. ohci_hcd was expected to detect a new hub. If I disable usb2.0 in
virtualbox config, OpenWRT gets no USB support in CC. Virtual machine
configs are equal.

kmod-usb-ohci is not installed by default in both system. However, both
systems seems to have some usb modules (including usb-ohci) built in
kernel. So, kmod-usb-ohci contains only control files (CC) or no files
(BB). Anyway, installing kmod-usb-ohci does not fix the problem. BTW,
shouldn't all empty packages for built-in modules be installed by
default? (most of 1k kmod-*.ipk)

I have already tested CC installing all kmod packages with no change on the
USB problem.

Checking my Ubuntu (with kernel newer than OpenWRT), I noticed that there
is a new ohci-pci in dmesg:

ohci-pci: OHCI PCI platform driver

Maybe it is USB_OHCI_HCD_PCI that is missing.

Any tips?

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

Re: [OpenWrt-Devel] issue: usb1.x not detected in CC

[Luiz Angelo Daros de Luca]

Further information:

It was indeed the USB_OHCI_HCD_PCI option.
ohci-pci was split from ohci_hcd with:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1117afb85890adf4073c7ff18ebcb4d0495e6af

In BB, the usb controller was detected by ohci_hcd. At some point after the
BB kernel version, the USB controller started to be detected only
by ohci-pci and not ohci_hcd.

In BB:root@OpenWrt:/# dmesg | grep ohci
[0.543001] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[0.544195] ohci_hcd :00:06.0: setting latency timer to 64
[0.544203] ohci_hcd :00:06.0: OHCI Host Controller
[0.544910] ohci_hcd :00:06.0: new USB bus registered, assigned bus
number 2
[0.545964] ohci_hcd :00:06.0: irq 11, io mem 0xf0804000
[1.040235] usb 2-1: new full-speed USB device number 2 using ohci_hcd

In CC (without USB_OHCI_HCD_PCI):
root@OpenWrt:/# dmesg |grep ohci
[0.884995] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[0.890242] ohci-platform: OHCI generic platform driver

In CC (with USB_OHCI_HCD_PCI):
[0.884343] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[0.885535] ohci-pci: OHCI PCI platform driver
[0.892110] ohci-pci :00:06.0: OHCI PCI host controller
[0.893716] ohci-pci :00:06.0: new USB bus registered, assigned bus
number 2
[0.895858] ohci-pci :00:06.0: irq 11, io mem 0xf0804000
[0.965726] ohci-platform: OHCI generic platform driver
[1.400359] usb 2-1: new full-speed USB device number 2 using ohci-pci

I fixed my problem creating a new kmod-ohci-pci that includes ohci-pci.ko.
Probably, it should also be added to be built-in on every target that is
pci-based and already include CONFIG_USB_OHCI_HCD build-in, like
target/linux/x86/generic/config-default and others (which one?). However,
it loads nicely as a module.

I can submit the patch for the new kmod but I'm not sure about kernel
dependencies like LINUX_3_x as ohci-pci.ko seems to be present only after
3.10.

Looking the kernel commit log, it seems that ohci-pci wasn't the only one
driver that was split from ohci. It was an effort for multi-plataform
kernels on ARM. I guess every other one might need a kmod-ohci-xxx as well.
So, the problem might affect every OHCI controller that where split.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/usb/host/ohci-hcd.c

In summary, no OHCI controller for CC on any target (except by some drivers
that still lives inside ohci-hcd like octeon and other exotic platforms).

BTW, CONFIG_USB_OHCI_ATH79, used for kmod-usb-ohci is deprecated at 3.14.x.

This option is deprecated now and the driver was removed, use
  USB_OHCI_HCD_PLATFORM instead.

Regards,

Em Thu Jan 22 2015 at 02:19:48, Luiz Angelo Daros de Luca 
luizl...@gmail.com escreveu:

Hello,

 I'm running OpenWRT in Virtualbox. I have no problem with BB. However,
 when testing trunk, I noticed that usb1.x functions simply does not work.

 For BB, in a clean install (+usbutils), I get:
 https://downloads.openwrt.org/barrier_breaker/14.07/x86/
 generic/openwrt-x86-generic-combined-ext4.img.gz

 root@OpenWrt:/# lsusb
 *Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet*
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 *Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub*

 root@OpenWrt:/# dmesg | egrep -i '(usb|hci)'
 [0.063968] ACPI: bus type USB registered
 [0.064573] usbcore: registered new interface driver usbfs
 [0.065292] usbcore: registered new interface driver hub
 [0.065990] usbcore: registered new device driver usb
 [0.511884] ahci :00:0d.0: version 3.0
 [0.513388] ahci: SSS flag set, parallel bus scan disabled
 [0.514182] ahci :00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps
 0x1 impl SATA mode
 [0.515223] ahci :00:0d.0: flags: 64bit ncq stag only ccc
 [0.515945] ahci :00:0d.0: setting latency timer to 64
 [0.516085] scsi0 : ahci
 [0.521108] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 [0.522068] ehci-pci: EHCI PCI platform driver
 [0.523007] ehci-pci :00:0b.0: setting latency timer to 64
 [0.523015] ehci-pci :00:0b.0: EHCI Host Controller
 [0.523673] ehci-pci :00:0b.0: new USB bus registered, assigned bus
 number 1
 [0.524738] ehci-pci :00:0b.0: irq 10, io mem 0xf084
 [0.540886] ehci-pci :00:0b.0: USB 2.0 started, EHCI 1.00
 *[0.541668] hub 1-0:1.0: USB hub found*
 [0.542882] ehci-platform: EHCI generic platform driver
 [0.543609] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
 [0.544824] ohci_hcd :00:06.0: setting latency timer to 64
 [0.544831] ohci_hcd :00:06.0: OHCI Host Controller
 [0.545495] ohci_hcd :00:06.0: new USB bus registered, assigned bus
 number 2
 [0.546662] ohci_hcd :00:06.0: irq 11, io mem 0xf0804000
 *[0.600350] hub 2-0:1.0: USB hub found*
 [0.602055] uhci_hcd: USB Universal Host

[OpenWrt-Devel] x86 failing to build (including buildbot)

[Luiz Angelo Daros de Luca]

Hello,

Building for i386 target is failing with this error:

ERROR: Missing site config for architecture i386 !
   The missing file will cause configure scripts to fail during
compilation.
   Please provide a openwrt/trunk/include/site/i386 file and restart
the build.

As shown in
http://buildbot.openwrt.org:8010/builders/x86/builds/885/steps/compile_1/logs/stdio

I hacked a solution localy symlinking i486 to i386

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

[OpenWrt-Devel] [PATCH] kernel: add ip_vti tunnel module

[Luiz Angelo Daros de Luca]

IP VTI (Virtual Tunnel Interface) is used to create a virtual device
for IPsec VPN (similar to OpenVPN).

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
---
 package/kernel/linux/modules/netsupport.mk | 16 
 1 file changed, 16 insertions(+)

diff --git a/package/kernel/linux/modules/netsupport.mk 
b/package/kernel/linux/modules/netsupport.mk
index 26dd491..a5a6474 100644
--- a/package/kernel/linux/modules/netsupport.mk
+++ b/package/kernel/linux/modules/netsupport.mk
@@ -405,6 +405,22 @@ endef
 $(eval $(call KernelPackage,iptunnel))
 
 
+define KernelPackage/ipvti
+  SUBMENU:=$(NETWORK_SUPPORT_MENU)
+  TITLE:=IP VTI (Virtual Tunnel Interface)
+  DEPENDS:=+kmod-iptunnel +kmod-iptunnel4 +kmod-ipsec4
+  KCONFIG:=CONFIG_NET_IPVTI
+  FILES:=$(LINUX_DIR)/net/ipv4/ip_vti.ko
+  AUTOLOAD:=$(call AutoLoad,33,ip_vti)
+endef
+
+define KernelPackage/ipvti/description
+ Kernel modules for IP VTI (Virtual Tunnel Interface)
+endef
+
+$(eval $(call KernelPackage,ipvti))
+
+
 define KernelPackage/iptunnel4
   SUBMENU:=$(NETWORK_SUPPORT_MENU)
   TITLE:=IPv4 tunneling
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Luiz Angelo Daros de Luca]

+1

Em ter, 7 de abr de 2015 às 18:15, Daniel Petre daniel.pe...@gmail.com
escreveu:

 +1

 On 08/04/15 00:09, Bruno Randolf wrote:
  +1
 
  On 04/07/2015 08:47 PM, Hartmut Knaack wrote:
  That Doodle poll turned out to be spamed/trolled, and everyone could
 even
  change or delete other votes. Since this was just communicated over this
  mailing list, and subscribers are at least basically verified, why not
 have a
  good old fashioned poll?
 
  Give your +1 answer on this mail if you prefer Designated Driver.
  ___
  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 mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH 3/5] elfutils: import package from packages.git

[Luiz Angelo Daros de Luca]

Jiri,

The package was imported from github. There were no maintainer before
github import (that's why I took it).

I guess oldpackages is not involved on this thread.

Regards,

Em ter, 19 de mai de 2015 04:59, Jiri Slachta slac...@cesnet.cz escreveu:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 AFAIK, the packages.git located at git.openwrt.org/packages.git is
 oldpackages repository
 that does not have any use in current trunk and releases after Barrier
 Breaker.

 @see
 http://git.openwrt.org/?p=openwrt.git;a=blob;f=feeds.conf.default;hb=HEAD

 If there is PKG_MAINTAINER declared in package Makefile, you should be
 contacting the person
 first before you make any contribution to packages repository at github or
 to openwrt repository.

 There is no synchronization with oldpackages repository.

 All of this was explained by Steven Barth before Barrier Breaker was
 released:

 https://lists.openwrt.org/pipermail/openwrt-devel/2014-June/025810.html

 Kind regards,
 Jiri Slachta

 Dne 19.5.2015 v 03:43 Luiz Angelo Daros de Luca napsal(a):
  I'm curious, as current elfutils packager, how I should play in this
 import?
 
  Should this package be removed from package.git (but there is no PR for
 it)?
 
  Or will it be periodically synchronized with packages.git?
 
  Also, as I'm not a core developer, maybe it would be better to a core
 developer to take its maintainance.
 
  Regards,
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQIcBAEBCAAGBQJVWu1XAAoJECilMVBDttCPxtMQAL9fLzpG73yaWMaM4xxb26Mm
 oqv8elnP5IhHTa4JhsjhQFmSEepzhgRo8zunrZwJ8uaq+oAvL2mKzk+ndoPEFmzG
 sp9fsVqJOC5GsgZFYNYzUnEM5xlvVPvPKgKrjVgKCFbzx7DtMcCFyPQEs96U+3dU
 q8lB5qiFLnjMo0jIVN1gsszInWhKwJEtnKuuRj4PHf4qWXIYpbjnlVXYW4gyeeh0
 9YLI8QvLDC19aQ6cZZjb2jH4tmvqL3V0k21CfU3u5bpx5MiZ/mo+4HsxnpW4oHS7
 SNGc1kqJj0fOCcVICwFQS8w0xPYnJY1gZnVAbDFna6FKjMKt76UePCtjtHew6/0A
 JQuavQrriOSWuhRFTe3/TIt7N4qpFwbaR1s2plqNtm6fPUPkuScMbJUIxzTRYwZo
 lg4dhOYojZvC59QeXh/RA7BPKOKj0XfJgvBebdfOfCPXnMXUuzMIlfh3mRrGVpo3
 K3eFVwZY04C69HrIBCM5VG55Ji8WnE6m6oN9Q0eSu48/1gLSkqA/ar9UajxkPUs8
 xOypeB2yi3LyHMP2YyFF1+wa438xh1E8TaJTA2xsqBnPR2sneYjViyzUp9CCHAjk
 frCyo1YYscfddKu/UqgL9Wjai17YvhDippuAE9oBW2JnCZ/0ezsZfkOniUIy2+wZ
 2809Oi0V5tWy7vb2Bmw8
 =CX79
 -END PGP SIGNATURE-

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

[OpenWrt-Devel] [PATCH] elfutils: bump to 0.163

[Luiz Angelo Daros de Luca]

Bugfix only release.

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
---
 package/libs/elfutils/Makefile |   4 +-
 .../patches/001-elfutils-portability.patch | 263 +++--
 .../elfutils/patches/005-build_only_libs.patch |   2 +-
 package/libs/elfutils/patches/006-libdw_LIBS.patch |   2 +-
 .../libs/elfutils/patches/100-musl-compat.patch|   2 +-
 package/libs/elfutils/patches/101-no-fts.patch |   8 +-
 6 files changed, 141 insertions(+), 140 deletions(-)

diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile
index d13e15d..5303e9e 100644
--- a/package/libs/elfutils/Makefile
+++ b/package/libs/elfutils/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=elfutils
-PKG_VERSION:=0.162
+PKG_VERSION:=0.163
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=http://fedorahosted.org/releases/e/l/$(PKG_NAME)/$(PKG_VERSION)
-PKG_MD5SUM:=9334cbcc0df7669b7bf07cf7fc3ad52c
+PKG_MD5SUM:=77ce87f259987d2e54e4d87b86cbee41
 PKG_MAINTAINER:=Luiz Angelo Daros de Luca luizl...@gmail.com
 PKG_LICENSE:=GPL-3.0+
 PKG_LICENSE_FILES:=COPYING COPYING-GPLV2 COPYING-LGPLV3
diff --git a/package/libs/elfutils/patches/001-elfutils-portability.patch 
b/package/libs/elfutils/patches/001-elfutils-portability.patch
index 068235a..46954aa 100644
--- a/package/libs/elfutils/patches/001-elfutils-portability.patch
+++ b/package/libs/elfutils/patches/001-elfutils-portability.patch
@@ -1,3 +1,4 @@
+diffelfutils/backends/ChangeLog git-portable/backends/ChangeLog
 --- a/backends/ChangeLog
 +++ b/backends/ChangeLog
 @@ -498,6 +498,10 @@
@@ -46,17 +47,17 @@
  libebl_i386.so: $(cpu_i386)
 --- a/backends/Makefile.in
 +++ b/backends/Makefile.in
-@@ -83,7 +83,8 @@ host_triplet = @host@
- DIST_COMMON = $(top_srcdir)/config/eu.am $(srcdir)/Makefile.in \
-   $(srcdir)/Makefile.am $(top_srcdir)/config/depcomp \
-   $(noinst_HEADERS) ChangeLog
+@@ -90,7 +90,8 @@ PRE_UNINSTALL = :
+ POST_UNINSTALL = :
+ build_triplet = @build@
+ host_triplet = @host@
 -@SYMBOL_VERSIONING_TRUE@am__append_1 = -DSYMBOL_VERSIONING
 +@BUILD_WERROR_TRUE@am__append_1 = $(if $($(*F)_no_Werror),,-Werror)
 +@SYMBOL_VERSIONING_TRUE@am__append_2 = -DSYMBOL_VERSIONING
  subdir = backends
  ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
  am__aclocal_m4_deps = $(top_srcdir)/m4/biarch.m4 \
-@@ -289,6 +290,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
+@@ -300,6 +301,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
  INSTALL_SCRIPT = @INSTALL_SCRIPT@
  INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
  LDFLAGS = @LDFLAGS@
@@ -64,7 +65,7 @@
  LEX = @LEX@
  LEXLIB = @LEXLIB@
  LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
-@@ -320,6 +322,7 @@ SHELL = @SHELL@
+@@ -331,6 +333,7 @@ SHELL = @SHELL@
  STRIP = @STRIP@
  USE_NLS = @USE_NLS@
  VERSION = @VERSION@
@@ -72,7 +73,7 @@
  XGETTEXT = @XGETTEXT@
  XGETTEXT_015 = @XGETTEXT_015@
  XGETTEXT_EXTRA_OPTIONS = @XGETTEXT_EXTRA_OPTIONS@
-@@ -387,14 +390,14 @@ AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_sr
+@@ -398,14 +401,14 @@ AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_sr
  
  # Warn about stack usage of more than 256K = 262144 bytes.
  @ADD_STACK_USAGE_WARNING_TRUE@STACK_USAGE_WARNING = -Wstack-usage=262144
@@ -94,7 +95,7 @@
  CLEANFILES = *.gcno *.gcda $(foreach m,$(modules), libebl_$(m).map \
libebl_$(m).so $(am_libebl_$(m)_pic_a_OBJECTS))
  textrel_msg = echo WARNING: TEXTREL found in '$@'
-@@ -900,7 +903,7 @@ libebl_%.so libebl_%.map: libebl_%_pic.a
+@@ -912,7 +915,7 @@ libebl_%.so libebl_%.map: libebl_%_pic.a
$(LINK) -shared -o $(@:.map=.so) \
-Wl,--whole-archive $ $(cpu_$*) -Wl,--no-whole-archive \
-Wl,--version-script,$(@:.so=.map) \
@@ -105,7 +106,7 @@
  libebl_i386.so: $(cpu_i386)
 --- a/ChangeLog
 +++ b/ChangeLog
-@@ -253,6 +253,8 @@
+@@ -258,6 +258,8 @@
  
  2012-01-24  Mark Wielaard  m...@redhat.com
  
@@ -114,7 +115,7 @@
* COPYING: Fix address. Updated version from gnulib.
  
  2012-01-23  Mark Wielaard  m...@redhat.com
-@@ -271,6 +273,9 @@
+@@ -276,6 +278,9 @@
  
  2011-10-08  Mike Frysinger  vap...@gentoo.org
  
@@ -124,7 +125,7 @@
* configure.ac: Fix use of AC_ARG_ENABLE to handle $enableval correctly.
  
  2011-10-02  Ulrich Drepper  drep...@gmail.com
-@@ -292,6 +297,10 @@
+@@ -297,6 +302,10 @@
  
* configure.ac (LOCALEDIR, DATADIRNAME): Removed.
  
@@ -135,7 +136,7 @@
  2009-09-21  Ulrich Drepper  drep...@redhat.com
  
* configure.ac: Update for more modern autoconf.
-@@ -300,6 +309,10 @@
+@@ -305,6 +314,10 @@
  
* configure.ac (zip_LIBS): Check for liblzma too.
  
@@ -146,7 +147,7 @@
  2009-04-19  Roland McGrath  rol...@redhat.com
  
* configure.ac (eu_version): Round down here, not in version.h macros.
-@@ -311,6 +324,8 @@
+@@ -316,6 +329,8 @@
  
  2009-01-23  Roland McGrath  rol...@redhat.com
  
@@ -155,7 +156,7 @@
* configure.ac (zlib check): Check for gzdirect, need zlib = 1.2.2.3.
  
* configure.ac (__thread check): Use

Re: [OpenWrt-Devel] [PATCH 3/5] elfutils: import package from packages.git

[Luiz Angelo Daros de Luca]

OK, Sent the PR in order to remove it.

I already have a update patch that I'll send to list.
However, I guess that perf pkg maintainer (or other) should
be the one to keep the maintenance as I have no current uses
for elfutils and probably I'll not give the love it desires.

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com

2015-06-14 14:22 GMT-03:00 Felix Fietkau n...@openwrt.org:

 On 2015-05-19 03:43, Luiz Angelo Daros de Luca wrote:
  I'm curious, as current elfutils packager, how I should play in this
 import?
 
  Should this package be removed from package.git (but there is no PR for
 it)?
 
  Or will it be periodically synchronized with packages.git?
 
  Also, as I'm not a core developer, maybe it would be better to a core
  developer to take its maintainance.
 I will apply this package. When you have updates to it, please send them
 as patches to this list. The package should be removed from github
 afterwards.

 - Felix

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

Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc2

[Luiz Angelo Daros de Luca]

Guys,

I'm no svn-git mirror expert but is there any chance of having
15.05/openwrt.git branch with full history?
Is there a technical limitation/reason for it?

The git mirror of svn is a dead-end. I get history only until the branch
commit. For example, the first commit in 14.07/openwrt.git is create
branch for barrier breaker (from trunk r41863). It would be nice to keep
full git history (so the first commit in any branch would be New
repository initialized by cvs2svn.

I did a ugly workaround creating myself a git branch on openwrt.git at the
branch point and merging xx.yy/openwrt.git back into it whenever it gets
updated (leaving merge-commits on the way).

Also, for a git repo, a branch would be just fine instead of a full git
repo (but separated repos is no problem if they share the same history).

If it is only a matter of  smaller downloads, git clone --depth 1 might
do it just fine.

Cheers,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com

2015-06-14 7:09 GMT-03:00 Daniel Golle dan...@makrotopia.org:

 On Sat, Jun 13, 2015 at 04:21:55PM +0200, Steven Barth wrote:
  ** Highlights since Barrier Breaker **
  ...
  * Platform and Driver Support
  ...
  - New sunxi target for AllWinner A10/A13/A20 family and various
 boards

 Please also mention:
  - New oxnas target for Oxford/PLXTECH NAS782x family and various boards


 Cheers


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

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

Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc2

[Luiz Angelo Daros de Luca]

Still not pretty, but it works much better.

Thanks,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com

2015-06-15 0:21 GMT-03:00 Gui Iribarren g...@altermundi.net:

 On 15/06/15 00:15, Luiz Angelo Daros de Luca wrote:
  Guys,
 
  I'm no svn-git mirror expert but is there any chance of having
  15.05/openwrt.git branch with full history?
  Is there a technical limitation/reason for it?
 
  The git mirror of svn is a dead-end. I get history only until the branch
  commit. For example, the first commit in 14.07/openwrt.git is create
  branch for barrier breaker (from trunk r41863). It would be nice to
  keep full git history (so the first commit in any branch would be New
  repository initialized by cvs2svn.
 
  I did a ugly workaround creating myself a git branch on openwrt.git at
  the branch point and merging xx.yy/openwrt.git back into it whenever it
  gets updated (leaving merge-commits on the way).

 a cleaner way is using .git/info/grafts


 http://wiki.openwrt.org/doc/howto/buildroot.exigence#merged_main_repository_into_a_single_git_repository

 just replace BB with CC and so on

 (i wasn't aware of this git feature until i came across that openwrt howto)

 cheers!

 
  Also, for a git repo, a branch would be just fine instead of a full git
  repo (but separated repos is no problem if they share the same history).
 
  If it is only a matter of  smaller downloads, git clone --depth 1
  might do it just fine.
 
  Cheers,
 
  ---
   Luiz Angelo Daros de Luca, Me.
  luizl...@gmail.com mailto:luizl...@gmail.com
 
  2015-06-14 7:09 GMT-03:00 Daniel Golle dan...@makrotopia.org
  mailto:dan...@makrotopia.org:
 
  On Sat, Jun 13, 2015 at 04:21:55PM +0200, Steven Barth wrote:
   ** Highlights since Barrier Breaker **
   ...
   * Platform and Driver Support
   ...
   - New sunxi target for AllWinner A10/A13/A20 family and
 various boards
 
  Please also mention:
   - New oxnas target for Oxford/PLXTECH NAS782x family and various
 boards
 
 
  Cheers
 
 
  Daniel
  ___
  openwrt-devel mailing list
  openwrt-devel@lists.openwrt.org mailto:
 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 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] TEXTREL in x86 with musl

[Luiz Angelo Daros de Luca]

Hello,

SInce x86 started to compile with musl, elfutils package becomes broken.
http://buildbot.openwrt.org:8010/broken_packages/x86/elfutils/compile.txt

During linking, elfutils checks if there is TEXTREL in its .so files, and
it fatally fails if so. I guess this is the only package that does this
kind of test.

I'm new to PIE binary but google says that the presence of TEXTREL in an
readelf -d indicates that one of more files linked were not compiled with
-fPIC.  Following https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide, I
tried to locale the offending file with scanelf and got this:

$ trunk/build_dir/target-i386_i486_musl-1.1.10/elfutils-0.163 $ scanelf -qT
*.so libelf/*.so
  libelf.so: __func__.3897 [0xE1F1] in (optimized out: previous
__stack_chk_fail_local) [0xE1F0]
  libelf/libelf.so

I checked all .so files generated with musl and most of them (or all) got
the same output. I still have the uclibc binaries and none have TEXTREL.

What is the best way to deal with this? Turn TEXTREL into non-fatal for
elfutils?

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

Re: [OpenWrt-Devel] [PATCH] perf: replace libelf1 select by a depend

[Luiz Angelo Daros de Luca]

Hi Mathieu,

So the elfutils import from packages.git was rejected?

Regards,

Luiz Angelo,

Em ter, 26 de mai de 2015 às 18:18, Mathieu Olivari math...@codeaurora.org
escreveu:

 perf has libelf1 marked as a select, but this package is actually
 located in packages.git. As such, the dependency is ignored unless
 libelf1 package has been manually installed previously.

 To avoid any missing dependency, we'll mark it as a regular depend.
 This will make sure the dependency check doesn't silently fail.

 Signed-off-by: Mathieu Olivari math...@codeaurora.org
 ---
  package/devel/perf/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile
 index b77e29a..e31a693 100644
 --- a/package/devel/perf/Makefile
 +++ b/package/devel/perf/Makefile
 @@ -19,7 +19,7 @@ include $(INCLUDE_DIR)/package.mk
  define Package/perf
SECTION:=devel
CATEGORY:=Development
 -  DEPENDS:= @USE_GLIBC +libelf1 +libdw +libpthread +librt +binutils
 +  DEPENDS:= libelf1 +libdw +libpthread +librt +binutils
TITLE:=Linux performance monitoring tool
VERSION:=$(LINUX_VERSION)-$(PKG_RELEASE)
URL:=http://www.kernel.org
 --
 2.1.4
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] package makefile help

[Luiz Angelo Daros de Luca]

The first command compiles all subpackages listed in radvd/Makefile. You
never compile subpackages directly.


Em sex, 31 de jul de 2015 às 08:39, Pratik Prajapati 
pratik.prajapat...@gmail.com escreveu:

 Hi,

 I we write makefile using this approach
 https://dev.openwrt.org/browser/packages/ipv6/radvd/Makefile

 make package/radvd/compile V=s   works
 but
 make package/radvdump/compile V=s doesn't work

 Why?
 How to correct this?
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Syntax error in radvd.conf

[Luiz Angelo Daros de Luca]

This is a question for openwrt-users.

Anyway, interface is the logical openwrt interface (lan, wan), not Linux
devices.
http://wiki.openwrt.org/doc/uci/radvd

Regards,

Em sex, 24 de jul de 2015 09:36, Pratik Prajapati 
pratik.prajapat...@gmail.com escreveu:

 Hi,

 I want to run radvd on OpenWrt but its giving me syntax error in radvd.conf

 radvd.conf:

 config 'interface'
 option 'interface'  'eth0'
 option 'AdvSendAdvert'  '1'
 option 'AdvManagedFlag' '0'
 option 'AdvOtherConfigFlag' '0'

 config 'prefix'
 option 'interface' 'eth0'
 option 'AdvOnLink' '1'
 option 'AdvAutonomous' '1'
 option 'AdvRouterAddr' '0'

 config 'route'
 option 'interface''eth0'
 option 'prefix'   '2001:0DB8:1234:5677::/64'
 option 'AdvRouteLifetime' 'infinity'


 Error on running: radvd start

 /etc/radvd.conf:1 error: syntax error, unexpected STRING, expecting
 T_INTERFACE
 [Jul 24 12:28:09] radvd (1202): exiting, failed to read config file

 What needs to be corrected in radvd.conf ?

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

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

Re: [OpenWrt-Devel] Git mirror with branches, tags and full history

[Luiz Angelo Daros de Luca]

Hello Steven,

Thanks for the mirror!
Wouldn't it be possible to integrate PR with the maillist?
A quick google gave me this:
https://github.com/google/pull-request-mailer

Regards,

Em seg, 9 de nov de 2015 10:54, Emmanuel Deloget <log...@free.fr> escreveu:

> Hello,
>
> Same here - this is really appreciated.
>
> BR,
>
> -- Emmanuel Deloget
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: Add dependency on ip (iproute2) to cfg80211

[Luiz Angelo Daros de Luca]

Is there a way to add "provides" to a package? In RPM, I would solve this
adding "Provides: ip" to busybox.

This could also help when a kern module gets built-in. Kernel package could
provide the incorporated kmod-xxx module. It would be better if both kernel
and kmod-xxx could automatically provide every single module it provides,
so packages could requires modules and not their packages, whether it is
built-in or loadable module.

Just like the case of busybox, if someone changes a module to not be
built-in (a configuration), it will require a code (makefile) change in
order to fix broken deps.

Luiz

Em ter, 17 de nov de 2015 06:11, Cristian Morales Vega <
crist...@samknows.com> escreveu:

> On 16 November 2015 at 23:40, Felix Fietkau <n...@openwrt.org> wrote:
> > On 2015-11-16 20:28, Ted Hess wrote:
> >> Changes to netifd/wireless/mac80211.sh in r46832 invoke 'ip' when making
> >> a client association. 'ip' is not automatically included with cfg80211
> >> custom builds -- association fails.
> >>
> >> Signed-off-by: Ted Hess <th...@kitschensync.net>
> > NACK. These changes were added because the busybox ip applet was enabled
> > by default recently.
>
> So there is a dependency (ip package OR ip support in Busybox), but no
> way to express it?
>
> Not that it would make sense for anybody to disable the new default in
> busybox without enabling the ip package at the same time. Just
> curious.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] elfutils: bump to 0.164

[Luiz Angelo Daros de Luca]

Patches are refreshed except for elfutils-portability, which is gone:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2015-October/005290.html

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/libs/elfutils/Makefile |4 +-
 .../patches/001-elfutils-portability.patch | 2059 
 .../elfutils/patches/004-maybe-uninitialized.patch |2 +-
 package/libs/elfutils/patches/004-memcpy_def.patch |2 +-
 .../elfutils/patches/005-build_only_libs.patch |2 +-
 package/libs/elfutils/patches/006-libdw_LIBS.patch |4 +-
 .../libs/elfutils/patches/100-musl-compat.patch|   28 +-
 package/libs/elfutils/patches/101-no-fts.patch |8 +-
 8 files changed, 25 insertions(+), 2084 deletions(-)
 delete mode 100644 package/libs/elfutils/patches/001-elfutils-portability.patch

diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile
index 5303e9e..b1e52ba 100644
--- a/package/libs/elfutils/Makefile
+++ b/package/libs/elfutils/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=elfutils
-PKG_VERSION:=0.163
+PKG_VERSION:=0.164
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=http://fedorahosted.org/releases/e/l/$(PKG_NAME)/$(PKG_VERSION)
-PKG_MD5SUM:=77ce87f259987d2e54e4d87b86cbee41
+PKG_MD5SUM:=2e4536c1c48034f188a80789a59114d8
 PKG_MAINTAINER:=Luiz Angelo Daros de Luca <luizl...@gmail.com>
 PKG_LICENSE:=GPL-3.0+
 PKG_LICENSE_FILES:=COPYING COPYING-GPLV2 COPYING-LGPLV3
diff --git a/package/libs/elfutils/patches/001-elfutils-portability.patch 
b/package/libs/elfutils/patches/001-elfutils-portability.patch
deleted file mode 100644
index 46954aa..000
--- a/package/libs/elfutils/patches/001-elfutils-portability.patch
+++ /dev/null
@@ -1,2059 +0,0 @@
-diffelfutils/backends/ChangeLog git-portable/backends/ChangeLog
 a/backends/ChangeLog
-+++ b/backends/ChangeLog
-@@ -498,6 +498,10 @@
-   * ppc_attrs.c (ppc_check_object_attribute): Handle tag
-   GNU_Power_ABI_Struct_Return.
- 
-+2009-01-23  Roland McGrath  <rol...@redhat.com>
-+
-+  * Makefile.am (libebl_%.so): Use $(LD_AS_NEEDED).
-+
- 2008-10-04  Ulrich Drepper  <drep...@redhat.com>
- 
-   * i386_reloc.def: Fix entries for TLS_GOTDESC, TLS_DESC_CALL, and
-@@ -825,6 +829,11 @@
-   * sparc_init.c: Likewise.
-   * x86_64_init.c: Likewise.
- 
-+2005-11-22  Roland McGrath  <rol...@redhat.com>
-+
-+  * Makefile.am (LD_AS_NEEDED): New variable, substituted by configure.
-+  (libebl_%.so rule): Use it in place of -Wl,--as-needed.
-+
- 2005-11-19  Roland McGrath  <rol...@redhat.com>
- 
-   * ppc64_reloc.def: REL30 -> ADDR30.
-@@ -847,6 +856,9 @@
-   * Makefile.am (uninstall): Don't try to remove $(pkgincludedir).
-   (CLEANFILES): Add libebl_$(m).so.
- 
-+  * Makefile.am (WEXTRA): New variable, substituted by configure.
-+  (AM_CFLAGS): Use it in place of -Wextra.
-+
-   * ppc_reloc.def: Update bits per Alan Modra <amo...@bigpond.net.au>.
-   * ppc64_reloc.def: Likewise.
- 
 a/backends/Makefile.am
-+++ b/backends/Makefile.am
-@@ -119,7 +119,7 @@ libebl_%.so libebl_%.map: libebl_%_pic.a
-   $(LINK) -shared -o $(@:.map=.so) \
-   -Wl,--whole-archive $< $(cpu_$*) -Wl,--no-whole-archive \
-   -Wl,--version-script,$(@:.so=.map) \
--  -Wl,-z,defs -Wl,--as-needed $(libelf) $(libdw)
-+  -Wl,-z,defs $(LD_AS_NEEDED) $(libelf) $(libdw)
-   @$(textrel_check)
- 
- libebl_i386.so: $(cpu_i386)
 a/backends/Makefile.in
-+++ b/backends/Makefile.in
-@@ -90,7 +90,8 @@ PRE_UNINSTALL = :
- POST_UNINSTALL = :
- build_triplet = @build@
- host_triplet = @host@
--@SYMBOL_VERSIONING_TRUE@am__append_1 = -DSYMBOL_VERSIONING
-+@BUILD_WERROR_TRUE@am__append_1 = $(if $($(*F)_no_Werror),,-Werror)
-+@SYMBOL_VERSIONING_TRUE@am__append_2 = -DSYMBOL_VERSIONING
- subdir = backends
- ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
- am__aclocal_m4_deps = $(top_srcdir)/m4/biarch.m4 \
-@@ -300,6 +301,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
- INSTALL_SCRIPT = @INSTALL_SCRIPT@
- INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
- LDFLAGS = @LDFLAGS@
-+LD_AS_NEEDED = @LD_AS_NEEDED@
- LEX = @LEX@
- LEXLIB = @LEXLIB@
- LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
-@@ -331,6 +333,7 @@ SHELL = @SHELL@
- STRIP = @STRIP@
- USE_NLS = @USE_NLS@
- VERSION = @VERSION@
-+WEXTRA = @WEXTRA@
- XGETTEXT = @XGETTEXT@
- XGETTEXT_015 = @XGETTEXT_015@
- XGETTEXT_EXTRA_OPTIONS = @XGETTEXT_EXTRA_OPTIONS@
-@@ -398,14 +401,14 @@ AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_sr
- 
- # Warn about stack usage of more than 256K = 262144 bytes.
- @ADD_STACK_USAGE_WARNING_TRUE@STACK_USAGE_WARNING = -Wstack-usage=262144
--AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \
--  $(if $($(*F)_no_Werror),,-Werror) \
--  $(if $($(*F)_no_Wunused),,-Wunused -Wextra) \
--  $(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \
-

Re: [OpenWrt-Devel] [PATCH] x86/xen_domu: enable image generation

[Luiz Angelo Daros de Luca]

This was already accepted in trunk. Is there any chance to backport to cc?

Em seg, 15 de jun de 2015 04:10, Luiz Angelo Daros de Luca 
luizl...@gmail.com escreveu:

 Add features ext4 targz to target x86/xen_domu in order to
 generate images in defconfig.

 This fixes #18074.

 Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
 ---
  target/linux/x86/xen_domu/target.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/target/linux/x86/xen_domu/target.mk
 b/target/linux/x86/xen_domu/target.mk
 index 80bac3b..f7a69bf 100644
 --- a/target/linux/x86/xen_domu/target.mk
 +++ b/target/linux/x86/xen_domu/target.mk
 @@ -1,3 +1,3 @@
  BOARDNAME:=Xen Paravirt Guest
  DEFAULT_PACKAGES += kmod-xen-fs kmod-xen-evtchn kmod-xen-netdev
 kmod-xen-kbddev
 -FEATURES:=display
 +FEATURES:=display ext4 targz
 --
 2.1.4


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

Re: [OpenWrt-Devel] [PATCH v4] base-files: add /etc/profile.d support

[Luiz Angelo Daros de Luca]

Normally I like to use find instead of glob
With minpath, maxpath, name and etc, you get safe empty result when dir is
empty.

Regards,

Em sex, 4 de set de 2015 10:10, Bastian Bittorf 
escreveu:

> * Karl Palsson  [04.09.2015 15:02]:
> > So let's -d test the directory instead of -e testing every file just in
> > case the directory didn't exist?
>
> even if the directory exists but is empty, the globbing fails.
> but i get your point. what about:
>
> [ -n "$( ls -1 $dir )" ] && {
>   for FILE in $dir/*; do
> . "$FILE"
>   done
> }
>
> but i dont like it! any other comments
>
> bye, bastian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

[Luiz Angelo Daros de Luca]

IMHO, I would avoid "normal releases" rule as, at some time in future,
OpenWRT might hopefully hit T..T.. name.

Trunk, unstable or anything like this might be better.

Regards,

Em qui, 10 de set de 2015 às 17:58,  escreveu:

> How about Trusty Trunk.. no cocktail though.. so far.. ede
>
>
> On 10.09.2015 22:08, Tobias Welz wrote:
> > Just following up with the T... T... idea - I found some T T Cocktails:
> >
> > Tahitian Tea
> > Tahitian Treat
> > Tanqueray Tonic
> > Tanzanian Tonic
> >
> >
> >
> > Am 09.09.2015 um 19:57 schrieb Hannu Nyman:
> >> Tobias Welz wrote at Wed Sep 9 17:24:14 CEST 2015:
> >> > So I absolutely vote for some clear consistent naming of the trunk
> and seperate names for the releases. (What about some Cocktail with a
> letter from the end of the alphabet like Z Z or X X in case
> there exists one)
> >>
> >> On that idea, the possible permanent name for the trunk could be
> something Txx Trunk. There are over 20 releases until TT is reached, so not
> for soon. I didn't find any really suitable drink names, but below are some
> ideas:
> >> Trekking Trunk
> >> Tasty Trunk
> >> Tricky Trunk
> >> Tempting Trunk
> >> Twisty Trunk
> >> Trunk Thrill
> >> Thrilling Trunk
> >>
> >> But until that, renaming trunk to something Dxxx Dxxx would be enough
> to decrease confusion.
> >> ___
> >> 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 mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Luiz Angelo Daros de Luca]

While openwrt doesn't offer security release, hiding version in banner is
not very effective. If the attacker can detect it is OpenWRT and if there
is a known security issue for any major version, it is enough to try an
attack.

Robot.txt is effective as Google is a common tool to look for targets. I
guess brute force scanners would not care to detect luci open to web as it
is a rare target (if Google does not list them). If they care, again, they
would just try the known attack.

Regards,

Em dom, 13 de set de 2015 17:05, Daniel Dickinson <
open...@daniel.thecshore.com> escreveu:

> I do think allowing to choose to disable the banner is a minor benefit,
> however, as I've said, there are much more effective means of preventing
> accidential exposure, and quite frankly if the user is *choosing* to
> open the web interface I think an warning and disabling the banner if
> the user foolishly insists on opening the interface despite the warning
> is more useful thank disabling the banner by default.
>
> If you're going to argue it prevents against internal threats than I
> would argue that if your internal network is hostile enough that you
> need to worry about attacks on openwrt from your internal network AND
> you're not skilled enough to limit access to LuCI (or better, build an
> image without LuCI and just use SSH) to the specific trusted hosts
> (preferably by combination of MAC address and IP address) in the
> firewall, or (better) to use a 'management' VPN or VLAN that only
> trusted hosts can get on, then you're in a lot more trouble than
> eliminating the banner for LuCI will solve.
>
> Regards,
>
> Daniel
>
> On 2015-09-13 10:21 AM, MauritsVB wrote:
> > At the moment the OpenWRT www login screen provides *very* detailed
> version information before anyone has even entered a password. It displays
> not just “15.05” or “Chaos Calmer” but even the exact git version on the
> banner.
> >
> > While it’s not advised to open this login screen to the world, fact is
> that it does happen intentionally or accidentally. Just a Google search for
> “Powered by LuCI Master (git-“ will provide many accessible OpenWRT login
> screens, including exact version information.
> >
> > As soon as someone discovers a vulnerability in a OpenWRT version all an
> attacker needs to do is perform a Google search to find many installations
> with versions that are vulnerable (even if a patch is already available).
> >
> > In the interest of hardening the default OpenWRT install, can I suggest
> that by default OpenWRT doesn’t disclose the version (not even 15.05 or
> “Chaos Calmer”) on the login screen? For extra safety I would even suggest
> to leave “OpenWRT” off the login screen, the only people who should use
> this screen already know it’s running OpenWRT.
> >
> > Any thoughts?
> >
> > Maurits
> > ___
> > 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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Need help with Makefile error *** missing separator

[Luiz Angelo Daros de Luca]

Andy,

Make runs one line per time. Make the "if" inline or backslash each newline
(adding semicolon when needed)

Regards

Em seg, 4 de jan de 2016 11:56, Andy Wong <axisaxi...@163.com> escreveu:

>
> For no misunderstanding.Here is the error now
> http://pastebin.com/t4Rb08kA
>
>
>
>
>
>
> 在 2016-01-04 21:18:14，"Andy Wong" <axisaxi...@163.com> 写道：
> >Thanks.I have indented like this：define 
> >Package/openwrt-dist-luci/install#!/bin/sh$(INSTALL_DIR) 
> >$(1)/usr/lib/lua/luci/controller$(INSTALL_DATA) 
> >./files/luci/controller/$(2).lua 
> >$(1)/usr/lib/lua/luci/controller/$(2).lua $(INSTALL_DIR) 
> >$(1)/usr/lib/lua/luci/model/cbi $(INSTALL_DATA) 
> >./files/luci/model/cbi/$(2).lua 
> >$(1)/usr/lib/lua/luci/model/cbi/$(2).lua   $(INSTALL_DIR) 
> >$(1)/etc/uci-defaults   $(INSTALL_BIN) 
> >./files/root/etc/uci-defaults/luci-$(2) $(1)/etc/uci-defaults/luci-$(2) 
> >if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then $(INSTALL_DIR) 
> >$(1)/usr/lib/lua/luci/i18n  $(INSTALL_DATA) 
> >./files/luci/i18n/$(2).zh-cn.lmo $(1)/usr/lib/lua/luci/i18n
> >fiendefBut another error 
> >appears:enwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/etc/uci-defaults/luci-chinadnsif
> > [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; thenbash: -c: line 1: 
> >syntax error: unexpected end of filemake[2]: *** 
> >[/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk]
> > Error 1make[2]: Leaving directory 
> >`/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci'make[1]:
> > *** [package/my_package/openwrt-dist-luci/compile] Error 2make[1]: 
> >Leaving directory `/home/Openwrt/witi-openwrt'make: *** 
> >[package/openwrt-dist-luci/compile] 错误 2My if,then course is 
> >intending to find out if *.zh-cn.lmo exist,then install it.
> >At 2016-01-04 20:20:00, "Jo-Philipp Wich" <j...@openwrt.org> wrote:
> >>Hi.
> >>
> >>Lines in the isntall section must be indented with at least one tab
> >>since they're shell instructions.
> >>
> >>~ Jow
> >>___
> >>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 mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Atomic/failsafe upgrades?

[Luiz Angelo Daros de Luca]

Hi,

I have a client that just asked for this. As their router uses grub, its
script if enough for the fallback logic. I implemented a POC and it worked
perfectly. There is no watchdog integration so the reboot is manually done
when the new firmware fails.

I'm just waiting for them to give me a go in order to implement a complete
solution. I'll post to the list when I get a working patch.

The basic idea is to have two rootfs (and two rootfs data) in flash. I
embed the kernel into squashfs, making rootfs self contained (as grub2 can
read squashfs). If I give to sysupgrade a squashfs image, it writes
alternately into the rootfs areas. It tries to boot the new flash once
(like grub-once). If it works, mark it as permanent. If not, just reboot
and the previous flash will be used.

Now, when I give a full xxx.img file, it overwrite all the system just like
the normal openwrt image does (something like proprietary xxx_boot.img). Of
course, this type of boot firmware does not have the fallback.

Regards,

Em qui, 7 de jan de 2016 18:16, Arthur Davis <silper...@gmail.com> escreveu:

> With failsafe upgrades, there always has to be "the thing that notices"
> when something goes wrong. With a wholesale upgrade, OpenWrt can't be that
> thing. The bootloader is probably the best candidate.
>
> Also, I've worked on projects that used a separate supervisory processor
> that was able to dictate the boot image. In one case, it was a very
> powerful processor that had its own jobs in the system. In another case, it
> was very small and just watched out for system health. One way to dictate
> the boot image is to have the OpenWrt system ask via tftp, but there are
> probably other possibilities depending on your system. (And this probably
> doesn't really apply unless you are able to specify some fundamental bits
> of the hardware.)
>
> Lastly, there is OpenWrt's failsafe mode which doesn't solve all of your
> concerns, but it should be noted:
> https://wiki.openwrt.org/doc/howto/generic.failsafe
>
> Arthur
>
>
> On Thu, Jan 7, 2016 at 11:48 AM, Eric Schultz <eschu...@prplfoundation.org
> > wrote:
>
>> Joshua,
>>
>> I've had some similar interest in this topic.  As far as I know, there
>> isn't anything like this on OpenWrt. There might be some overlap with the
>> discussion of automatic updates from last week as well.
>>
>> Eric
>>
>> On Thu, Jan 7, 2016 at 11:44 AM, Joshua Judson Rosen <
>> jro...@harvestai.com> wrote:
>>
>>> I'm trying to decide on a Linux-based OS to use in a project,
>>> and one of the features that I want is failsafe upgrades--
>>> such that failing to run an upgrade procedure to completion
>>> should be non-catastrophic, and automatically recoverable; the
>>> system should always be able to (re)boot into a state
>>> where it can run normally, either in the upgraded state
>>> or in the pre-upgrade state.
>>>
>>> One option that I've deal with is to keep two parallel
>>> system installs, upgrade whichever one you're not currently using,
>>> try to boot _that one_ after the upgrade finishes,
>>> and fall back to the last-known-good install
>>> if either the upgrade fails in the middle or the boot into
>>> the preferred install fails. IIRC, there's something like this
>>> available with Yocto; and, if I understand it correctly,
>>> NixOS also does something similar in spirit to this
>>> (though perhaps with a different granularity).
>>>
>>> Are there any provisions for doing something like that
>>> with OpenWRT?
>>>
>>> --
>>> "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>
>>
>>
>> --
>> Eric Schultz, Community Manager, prpl Foundation
>> http://www.prplfoundation.org
>> eschu...@prplfoundation.org
>> cell: 920-539-0404
>> skype: ericschultzwi
>> @EricPrpl
>>
>> ___
>> 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
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] procd: hotplug.json: allow passing hotplug events from all subsystems

[Luiz Angelo Daros de Luca]

John,

How about generate the subsystem list from /etc/hotplug.d dirs. The list
could be loaded at startup and refreshed the same way hotplug.json is (
which might be "never" as procd does not have an "init q").

Regards,

Luiz

Em sáb, 28 de nov de 2015 21:14, John Crispin <blo...@openwrt.org> escreveu:

> Hi Yousong,
>
> On 28/11/2015 05:22, Yousong Zhou wrote:
> > There are time that programs need to be notified of events from
> > subsystems that are not enumerated in the .json definition, e.g. QEMU
> > guest agent by default requires /dev/virtio-ports/org.qemu.guest_agent.0
> > which is a symlink to /dev/vportMpN from virtio-ports subsystem.
> >
>
> i am not sure if this is a good idea. there are thousands of events
> being broadcast, specially during boot and we really want to avoid
> respawning the script helper for each one of them. i was under the
> impression that we had an include directive that allowed us to include
> board/target specific json files. however i am failing to find the code
> that does this so the feature might not actually be implemented yet.
> i'll need to have a closer look at this the next days.
>
> John
>
> > Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com>
> > ---
> >  package/system/procd/files/hotplug.json | 9 ++---
> >  1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/package/system/procd/files/hotplug.json
> b/package/system/procd/files/hotplug.json
> > index 27b4836..bad2340 100644
> > --- a/package/system/procd/files/hotplug.json
> > +++ b/package/system/procd/files/hotplug.json
> > @@ -69,18 +69,13 @@
> >   [ "button", "/etc/rc.button/%BUTTON%" ]
> >   ],
> >   [ "if",
> > - [ "eq", "SUBSYSTEM",
> > - [ "net", "input", "usb", "usbmisc", "ieee1394",
> "block", "atm", "zaptel", "tty", "button" ]
> > - ],
> > - [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
> > - ],
> > - [ "if",
> >   [ "and",
> >   [ "eq", "SUBSYSTEM", "usb-serial" ],
> >   [ "regex", "DEVNAME",
> >           [ "^ttyUSB", "^ttyACM" ]
> >   ],
> >   ],
> > - [ "exec", "/sbin/hotplug-call", "tty" ]
> > + [ "exec", "/sbin/hotplug-call", "tty" ],
> > + [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
> >   ],
> >  ]
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH][RFC] x86: Save and restore partition table during upgrade

[Luiz Angelo Daros de Luca]

n 1
> +   fi
> +
> +   #if nothing changed, we do not need to restore
> +   if [ "$before" = "$after" ]; then
> +   echo "Parition layout unchanged"
> +   return 0
> +   fi
> +
> +   diff=$(grep -F -x -v -f /tmp/sfdisk.before.nonempty
> /tmp/sfdisk.after.nonempty)
> +
> +   #if partition layout changed, do not restore
> +   if [ -n "$diff" ]; then
> +   echo "Partition layout changed, not restoring."
> +   return 1
> +   fi
> +
> +   echo "Restoring partition table..."
> +   sfdisk $disk --force < /tmp/sfdisk.before >&/dev/null
> +   fi
> +}
> +
>  platform_do_upgrade() {
>     platform_export_bootpart
>
> if [ -b "${BOOTPART%[0-9]}" ]; then
> sync
> +   [ $SAVE_PARTITIONS = "1" ] && save_bootparts
> get_image "$@" | dd of="${BOOTPART%[0-9]}" bs=4096
> conv=fsync
> sleep 1
> +   [ $SAVE_PARTITIONS = "1" ] && restore_bootparts
> fi
>  }
> +
> --
> 2.1.4
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFC: dropping oprofile

[Luiz Angelo Daros de Luca]

Thanks Felix. It would take me sometime to debug this.

Regards,

Em qui, 21 de jan de 2016 às 12:12, Felix Fietkau <n...@openwrt.org>
escreveu:

> On 2016-01-21 14:42, Kevin Darbyshire-Bryant wrote:
> > Reverting 0ca8e85462074e713be6468a3ea7259caca1b1ea appears to allow perf
> > to compile again.
> >
> > "
> >  elfutils: bump to 0.165
> >
> > Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
> > git-svn-id: svn://svn.openwrt.org/openwrt/trunk@48393
> > 3c298f89-4303-0410-b956-a3cf2f4a3e73"
> Fixed in r48429.
>
> Luiz, the updated elfutils version assumed you were using glibc 2.22 or
> newer (had some elf compressed header stuff in there).
> The patch that I added backports the missing definitions.
>
> - Felix
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] elfutils: bump to 0.165

[Luiz Angelo Daros de Luca]

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/libs/elfutils/Makefile  | 8 
 package/libs/elfutils/patches/003-libint-stub.patch | 2 +-
 package/libs/elfutils/patches/005-build_only_libs.patch | 4 ++--
 package/libs/elfutils/patches/006-libdw_LIBS.patch  | 6 +++---
 package/libs/elfutils/patches/100-musl-compat.patch | 4 ++--
 package/libs/elfutils/patches/101-no-fts.patch  | 4 ++--
 6 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile
index b1e52ba..fa7bc55 100644
--- a/package/libs/elfutils/Makefile
+++ b/package/libs/elfutils/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=elfutils
-PKG_VERSION:=0.164
+PKG_VERSION:=0.165
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=http://fedorahosted.org/releases/e/l/$(PKG_NAME)/$(PKG_VERSION)
-PKG_MD5SUM:=2e4536c1c48034f188a80789a59114d8
+PKG_MD5SUM:=c37fdbe18e848002b451562cba964679
 PKG_MAINTAINER:=Luiz Angelo Daros de Luca <luizl...@gmail.com>
 PKG_LICENSE:=GPL-3.0+
 PKG_LICENSE_FILES:=COPYING COPYING-GPLV2 COPYING-LGPLV3
@@ -28,7 +28,6 @@ include $(INCLUDE_DIR)/nls.mk
 define Package/elfutils/Default
   SECTION:=libs
   CATEGORY:=Libraries
-  DEPENDS:=$(INTL_DEPENDS)
   TITLE:=ELF manipulation libraries
   URL:=https://fedorahosted.org/elfutils/
 endef
@@ -41,12 +40,13 @@ endef
 
 define Package/libdw
   $(call Package/elfutils/Default)
-  DEPENDS:=libelf1 +zlib +libbz2
+  DEPENDS:=libelf1 +libbz2
   TITLE+= (libdw)
 endef
 
 define Package/libelf1
   $(call Package/elfutils/Default)
+  DEPENDS:=$(INTL_DEPENDS) +zlib
   TITLE+= (libelf)
 endef
 
diff --git a/package/libs/elfutils/patches/003-libint-stub.patch 
b/package/libs/elfutils/patches/003-libint-stub.patch
index cf6539f..d6cc707 100644
--- a/package/libs/elfutils/patches/003-libint-stub.patch
+++ b/package/libs/elfutils/patches/003-libint-stub.patch
@@ -1,6 +1,6 @@
 --- a/libelf/libelfP.h
 +++ b/libelf/libelfP.h
-@@ -42,6 +42,9 @@
+@@ -43,6 +43,9 @@
  #include 
  #include 
  
diff --git a/package/libs/elfutils/patches/005-build_only_libs.patch 
b/package/libs/elfutils/patches/005-build_only_libs.patch
index 0077369..e39b395 100644
--- a/package/libs/elfutils/patches/005-build_only_libs.patch
+++ b/package/libs/elfutils/patches/005-build_only_libs.patch
@@ -1,6 +1,6 @@
 --- a/Makefile.in
 +++ b/Makefile.in
-@@ -372,8 +372,7 @@ ACLOCAL_AMFLAGS = -I m4
+@@ -378,8 +378,7 @@ AM_MAKEFLAGS = --no-print-directory
  pkginclude_HEADERS = version.h
  
  # Add doc back when we have some real content.
@@ -12,7 +12,7 @@
 COPYING COPYING-GPLV2 COPYING-LGPLV3
 --- a/Makefile.am
 +++ b/Makefile.am
-@@ -23,8 +23,7 @@ ACLOCAL_AMFLAGS = -I m4
+@@ -27,8 +27,7 @@ AM_MAKEFLAGS = --no-print-directory
  pkginclude_HEADERS = version.h
  
  # Add doc back when we have some real content.
diff --git a/package/libs/elfutils/patches/006-libdw_LIBS.patch 
b/package/libs/elfutils/patches/006-libdw_LIBS.patch
index bcea100..34c4447 100644
--- a/package/libs/elfutils/patches/006-libdw_LIBS.patch
+++ b/package/libs/elfutils/patches/006-libdw_LIBS.patch
@@ -1,11 +1,11 @@
 --- a/libdw/Makefile.in
 +++ b/libdw/Makefile.in
-@@ -994,7 +994,7 @@ libdw.so$(EXEEXT): $(srcdir)/libdw.map l
+@@ -996,7 +996,7 @@ libdw.so$(EXEEXT): $(srcdir)/libdw.map l
-Wl,--enable-new-dtags,-rpath,$(pkglibdir) \
-Wl,--version-script,$<,--no-undefined \
-Wl,--whole-archive $(filter-out $<,$^) -Wl,--no-whole-archive\
--  -ldl $(argp_LDADD) $(zip_LIBS)
-+  -ldl $(argp_LDADD) $(zip_LIBS) $(LIBS)
+-  -ldl -lz $(argp_LDADD) $(zip_LIBS)
++  -ldl -lz $(argp_LDADD) $(zip_LIBS) $(LIBS)
@$(textrel_check)
$(AM_V_at)ln -fs $@ $@.$(VERSION)
  
diff --git a/package/libs/elfutils/patches/100-musl-compat.patch 
b/package/libs/elfutils/patches/100-musl-compat.patch
index 7427e9a..25e1504 100644
--- a/package/libs/elfutils/patches/100-musl-compat.patch
+++ b/package/libs/elfutils/patches/100-musl-compat.patch
@@ -151,7 +151,7 @@
  #include 
 --- a/src/ldlex.c
 +++ b/src/ldlex.c
-@@ -1099,7 +1099,7 @@ char *ldtext;
+@@ -1106,7 +1106,7 @@ char *ldtext;
  #include 
  #include 
  #include 
@@ -621,7 +621,7 @@
  #include 
 --- a/libcpu/i386_lex.c
 +++ b/libcpu/i386_lex.c
-@@ -571,7 +571,7 @@ char *i386_text;
+@@ -578,7 +578,7 @@ char *i386_text;
  #endif
  
  #include 
diff --git a/package/libs/elfutils/patches/101-no-fts.patch 
b/package/libs/elfutils/patches/101-no-fts.patch
index b1b2308..6a3e940 100644
--- a/package/libs/elfutils/patches/101-no-fts.patch
+++ b/package/libs/elfutils/patches/101-no-fts.patch
@@ -72,7 +72,7 @@
struct parse_opt *opt = state->hook;
 --- a/libdwfl/Makefile.in
 +++ b/libdwfl/Makefile.in
-@@ -121,7 +121,7 @@ am__libdwfl_a_SOURCES_DIST = dwfl_begin.
+@@ -120,7 +120,7 @@ am__libdwfl_a_SOUR

[OpenWrt-Devel] cannot boot current x86 snapshot

[Luiz Angelo Daros de Luca]

Hello,

I just tried the
https://downloads.openwrt.org/snapshots/trunk/x86/generic/openwrt-x86-generic-combined-squashfs.img
(r49083) and
it was not able to boot. The kernel cmdline is missing the disk signature:

...block2mtd.block2mtd=PARTUUID=-02,65536,rootfs,5...

It should be PARTUUID=-02 and not PARTUUID=-02.
I'm able to boot if I manually replace PARTUUID=-02 by /dev/sda2.

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] prereq: fixes checks that prefix env vars (ex:git)

[Luiz Angelo Daros de Luca]

If a prereq-build command check defines a command env var (ex: MANPAGER=cat git 
...)
prereq SetupHostCommand breaks. This is because it looks for the binary using 
which on
the first space-separated item (which might be the env var definition)

This patch replaces bash substitution by a sed regex that removes both env 
parameters and
command args.
---
 include/prereq.mk | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/prereq.mk b/include/prereq.mk
index 6cb590e..839b663 100644
--- a/include/prereq.mk
+++ b/include/prereq.mk
@@ -92,8 +92,11 @@ define SetupHostCommand
   $(call QuoteHostCommand,$(7)) $(call QuoteHostCommand,$(8)) \
   $(call QuoteHostCommand,$(9)); do \
if [ -n "cmd" ]; then \
+   
regex_rm_vars='s/^(\w+=(\['\'\"]']|'\''[^'\'']*'\''|"[^"]*"|[^ ]*(\\ )?)* 
)*//'; \
+   regex_rm_args='s/[[:space:]].*//'; \
+   
regex_clean_cmd="regex_rm_vars;regex_rm_args"; \
bin="(PATH="$(subst $(space),:,$(filter-out 
$(STAGING_DIR_HOST)/%,$(subst :,$(space),$(PATH" \
-   which "{cmd%% *}")"; \
+   which "(echo cmd | sed -re 
"regex_clean_cmd")")"; \
if [ -x "bin" ] && eval "cmd" 
>/dev/null 2>/dev/null; then \
mkdir -p "$(STAGING_DIR_HOST)/bin"; \
ln -sf "bin" 
"$(STAGING_DIR_HOST)/bin/$(strip $(1))"; \
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] fstools/overlayfs race condition

[Luiz Angelo Daros de Luca]

Maybe fsfreeze can avoid the race condition. (if this works with the
involved FS)
http://linux.die.net/man/8/fsfreeze
https://github.com/karelzak/util-linux/blob/master/sys-utils/fsfreeze.c

Or just temporary remount source fs as ro. It might make some writing
process unhappy but I'll keep file filesystem state.

My two cents.

Regards,

Em seg, 7 de mar de 2016 às 10:10, John Crispin <blo...@openwrt.org>
escreveu:

>
>
> On 07/03/2016 14:03, Roman Yeryomin wrote:
> > There is a race between `cp -a /tmp/root/* /rom/overlay` from
> > libfstools/overlay.c and a process creating new file(s) before
> > pivot(/rom, /mnt) occured.
> > That is a process can create a file and it will not be copied.
> >
> > Currently I do additional copy after jffs2 is ready, which is kind of
> > cumbersome (see attached patch), but there are still few potentially
> > erroneous scenarios:
> > 1. a process may recreate the file by the time second cp occurs
> > 2. a process may delete a file (not existing at that moment) and
> > second cp will copy it again
> > 3. a process may want to read created file before second cp occurs
> >
> > If attached patch is the way to go I will properly submit it.
> > Otherwise there should be a more fundamental fix but I don't see a way
> > to fix this properly.
> >
> >
>
> Hi Roman
>
> that race has been there since the day we do overlayfs. i am always
> surprised that it has not exploded in a big way yet. the only way i see
> are workarounds such as yours or sending out lots of SIGSTOP and the
> continues when we copied the files. either way it will be ugly and
> require protective gear.
>
> i'll ponder this and see if we can find a better way
>
> John
> _______________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] opkg upgrade all

[Luiz Angelo Daros de Luca]

Michal,

Google is your friend ;-)

But I'll easy your search
https://wiki.openwrt.org/doc/techref/opkg

Check the upgrade description.

Regards

Em ter, 29 de mar de 2016 às 04:45, Michal Hrusecky <michal.hruse...@nic.cz>
escreveu:

> Hi,
>
> there is a patch in OpenWRT that disables option to upgrade all packages
> and
> allows upgrading only specified packages which leads to plenty of answers
> online how to do that[1][2][3][...] Does anybody remembers the reason for
> disabling it? The only thing I can think of is discouraging people from
> doing
> upgrades and encourage them to reflash new squashfs image as they might not
> have enough free space. But as you can see, people will try and do it
> anyway so
> it might be a good idea to let the command there as it will be probably
> safer
> with integrated command than with random scripts on internet. Or is there
> some
> other reason and some real problem?
>
> [1] https://sandalov.org/blog/1777/
> [2]
> https://www.codeden.net/2015/05/upgrade-all-openwrt-packages-with-a-single-line-command/
> [3] http://blog.vanutsteen.nl/2014/01/12/openwrt-upgrade-all-packages/
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] opkg upgrade all

[Luiz Angelo Daros de Luca]

Just like any Linux distribution, it is recommended to not mix a kernel
from a different release with runtime from another release. However, if
there is no incompatibility between them, you are free to do as you want.
The more distance each kernel is, the more likely to have
incompatibilities.

OpenWRT, although, is not developed with upgrade in mind. So, packages that
are renamed will be kept at the old version, and new package will not be
installed if not required by an existing package. You might get a mix of
kernel, old and new packages at the end. If, by chance, they are all
compatible, it will work nicely.

You'll need to mix old and new repos as any new kernel module must come
from the old repo. I don't know how well opkg deal with this.

Besides that, there is the extra space used. I guess jffs2 is also worse in
performance and compression.

It is just no good reason to do an upgrade and not a reflash. If you and
the packages are doing the backup correctly, you just need to reinstall all
extra packages after the new system is installed.

Regards,

Em qua, 30 de mar de 2016 02:30, Michal Hrusecky <michal.hruse...@nic.cz>
escreveu:

> Luiz Angelo Daros de Luca -  1:41 30.03.16 wrote:
> > Michal,
> >
> > Google is your friend ;-)
>
> He pretends he is, but didn't provided the answer I was looking for, just
> plenty of workarounds I mentioned ;-)
>
> > But I'll easy your search
> > https://wiki.openwrt.org/doc/techref/opkg
> >
> > Check the upgrade description.
>
> Reread and the only thing that is mentioned there is general discourage to
> do
> upgrades and be careful what you are doing and that there are generally no
> updates available apart from trunk and that opkg will not upgrade kernel.
> No
> technical problem and no specific issue with upgrade all.
>
> > Regards
> >
> > Em ter, 29 de mar de 2016 às 04:45, Michal Hrusecky <
> michal.hruse...@nic.cz>
> > escreveu:
> >
> > > Hi,
> > >
> > > there is a patch in OpenWRT that disables option to upgrade all
> packages
> > > and
> > > allows upgrading only specified packages which leads to plenty of
> answers
> > > online how to do that[1][2][3][...] Does anybody remembers the reason
> for
> > > disabling it? The only thing I can think of is discouraging people from
> > > doing
> > > upgrades and encourage them to reflash new squashfs image as they
> might not
> > > have enough free space. But as you can see, people will try and do it
> > > anyway so
> > > it might be a good idea to let the command there as it will be probably
> > > safer
> > > with integrated command than with random scripts on internet. Or is
> there
> > > some
> > > other reason and some real problem?
> > >
> > > [1] https://sandalov.org/blog/1777/
> > > [2]
> > >
> https://www.codeden.net/2015/05/upgrade-all-openwrt-packages-with-a-single-line-command/
> > > [3] http://blog.vanutsteen.nl/2014/01/12/openwrt-upgrade-all-packages/
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > >
> > --
> >
> > Luiz Angelo Daros de Luca
> > luizl...@gmail.com
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] upstream opkg

[Luiz Angelo Daros de Luca]

Thanks Jo,

Do you have any idea how it would be possible to reduce upstream opkg
size? Create
a libarchive-mini?

Maybe we can simply revert libarchive adoption (specially if we turn it
into a ./configure option). I guess it is limited to libopkg/pkg_extract.c
file.
Maybe it is better to keep an openwrt customized pkg_extract.c than to
maintain an full opkg fork (with known issues).

deb and rpm are already possible busybox applet. Maybe opkg could also
become one (and share some code with tar/gzip).

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] IEEE 802.11s

[Luiz Angelo Daros de Luca]

Prabhu, OpenWRT does not have source code of projects inside its own
source. All needed sources, including the linux kernel, is downloaded
during the build. You'll only find kernel patches and the kernel packages
definition (which packs modules).

If you want to see the result kernel source, build OpenWRT once and check
builddir.

Regards,

Em qui, 21 de abr de 2016 16:34, Prabhu Janakaraj <wsupra...@gmail.com>
escreveu:

> Hi all,
> I am a newbie to embedded devices. I have used openwrt for building mesh
> network. I am able to build firmware from the source code and get it
> working.
>
> But I want to modifying certain things in Mesh Routing algorithm HWMP,
> kind of implementing a new routing algorithm.
>
> In generic linux kernel source code, I am able to figure the location of
> the files for IEEE 802.11. But when I look into the source code of OpenWRT,
> I am unable to find the same. Is there any place where I should look for
> the IEEE 802.11 and IEEE 802.11 Mesh ?
>
> I am kind of what to implement my own routing algorithm for Mesh.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Introducing the LEDE project

[Luiz Angelo Daros de Luca]

I like to take decisions based more on "Realpolitik" than on
ideology/feelings. I have no side and no feelings for any of people
involved. I just want to have a good router distribution.

What is a OSS project? It is the sum of work of people. So, the future of a
project lies on how much people will work on it.

Let's face: if you sum the commits count* of those leaving, you start to
worry about OpenWRT:

Core:
 10815 nbd <<
  4531 juhosg
  3649 blogic <<
  3436 florian
  2654 nico
  2183 jow <<
  1482 kaloz
  1414 hauke <<
   925 wbx
   718 cyrus <<

Packages:
  512 Steven Barth <<
   469 Ted Hess <<
   256 Marcel Denia
   250 Daniel Golle <<
   235 Nikos Mavrogiannopoulos
   230 sbyx
   214 Hannu Nyman
   202 Alexandru Ardelean
   162 Jo-Philipp Wich <<
   154 Nicolas Thill
(git shortlog -s -n | head -10)

*yes, I know that they are not the author of all commits but they were the
ones that reviewed the patches and committed them.

If you lose most of the committers, the project will REALLY lag behind, to
a point of losing its self sustainability. Those leaving represents more
than 50% of commits of all time and, since 2014, they are the top 6 devs
with more than 80% of commits.
(git shortlog -s -n 3328763a8d0abbcbcf79b5a91e6abbb0b55b3119..HEAD  | head
-10)
They are(were) the ones currently working.

One of the complaints was that there were no process of introducing new
devs. So, when a bunch of them leave, what will happen? Ease the process of
including new devs (which is one of the demanded changes)? Do we really
think that there is a suppressed supply of developers wanting to replace
the leaving devs?

It seems that the decision power in OpenWRT does not match the amount of
work each one is currently dedicating to the project.

What might happen with the fork?

OpenWRT loses 80% of its development power (not counting those that leave
to LEDE after).
LEDE might attract more devs with an open politic (as packages are much
better at github). In the end, if LEDE succeeds on balance more devs,
stability and new resources, everybody will use it and OpenWRT will start
to rot. If it fails, both projects might die and everybody loses.

This was already happened with OpenOffice/LibreOffice (I guess with
ffmpeg/libav less devs left). They created a new project because of
disagreement (with Oracle). Devs flew to the new project. The old one
started to rot and ended dropped to the community. I guess most of the
current downloaders of OpenOffice do not know LibreOffice and they are not
power users. With OpenWRT, most of downloaders are power users.

You can replace infrastructure in a matter of weeks. Replace a brand in
months. However, you need years or decades to form a development team.

What are the options for OpenWRT Decision Team (as the development team
just left)?

1) Do nothing. Let LEDE take its chances. If it succeed, it will take the
place of OpenWRT and OpenWRT will rot. If not, we'll might have a version
of mutual assured destruction.

2) The remaining OpenWRT Core Team accept some (or all) terms of the LEDE
Team. Face it. There were already most of the "OpenWRT Core Team". Now give
them the corresponding decision power.

Even if all the remaining of the OpenWRT Core Team resign now and give all
the control to LEDE, OpenWRT will be less affected than the current
situation.

If I felt that my position would put in danger a project on which I
dedicated and care so much, I would rather simply resign than let my work
be gone. OpenWRT should be more than someone's project. However, there is
no need to anyone to leave but a need of power transferring.

The ones with current decision power at OpenWRT will either give away some
of its power or they will lose it all (in favor of a rebooted OpenWRT
leaded by LEAD or because it simply became irrelevant).

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Introducing the LEDE project

[Luiz Angelo Daros de Luca]

It is really strange that the decision to create a new project was so
opaque when it was motivated to be a more "transparent project".
They could've started to be more transparent already with the decision to
create a new project.

Maybe the answer for the need of an external reboot might be not in the
names that jumped into but on those left behind.
Maybe it was easier to create a new project than to boot out the problems.

My 2 cents,

Em qua, 4 de mai de 2016 às 14:50, Roman Yeryomin <leroi.li...@gmail.com>
escreveu:

> On 4 May 2016 at 19:25, Kathy Giori <kathy.gi...@gmail.com> wrote:
> > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich <j...@openwrt.org>
> wrote:
> >> Hi,
> >>
> >> we'd like to introduce LEDE, a reboot of the OpenWrt community
> >> .
> >>
> >> The project is founded as a spin-off of the OpenWrt project and shares
> >> many of the same goals.
> >
> > While I appreciate the enthusiasm, I do not see why you cannot apply
> > these same "principles" of openness and transparency to the OpenWrt
> > project. Makes no sense to me to branch the project. That simply
> > divides the resources in the community into fewer numbers working on
> > each fork.
>
> Exactly, tearing down the project and community without any real
> explanations (and plans to solve the stated issues) is just wrong.
>
> > Also wearing my hat within the prpl Foundation, which is funded by
> > industry sponsorships that in turn provides financial support for
> > OpenWrt, no one I have spoken to in prpl understands the reason for
> > this spin-off either. It'll cause more confusion and inefficiency in
> > industry. prpl will stick with OpenWrt, and I expect most companies
> > who follow and/or contribute to OpenWrt will stick with it too.
> >
> > kathy
> > ___
> > 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
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if upstream network goes down

[Luiz Angelo Daros de Luca]

Nick, you can try lede-project bug tracker. I recently released rc1.

Em sex, 3 de fev de 2017 22:18, Nick Malyon <n...@fishun.co.uk> escreveu:

> Hi all,
>
> I tried to open the following bug report but Trac's spam filter wouldn't
> let me, so I thought I'd raise it on the mailing list to see what you
> think...
>
> I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it
> to provide a WiFi access point to my phone/tablet while I travel, and it's
> acting as a WiFi client for the various hostels I visit.
>
> If you configure it as a wifi client with a wwan interface using the LuCI
> scan/join wizard, and then you configure a wifi access point on the same
> radio, the router works as expected and when you connect to the router's
> AP, you get Internet via the client connection.
>
> However, if you move out of range of the network the router is a client
> of, or if it goes down, when you power off the OpenWrt router and power
> back on, the access point won't come up.
>
> The AP will only come up if the client network you configured is also
> working; so you have no way to connect to the router over wifi, and no way
> to reconfigure the router, if that client network is down or out of range.
>
> This is a particular problem for a travel router because it will often
> move it out of range of the original upstream network, and you may only
> have a wifi-capable device with which to reconfigure it.
>
> The Ethernet port on the router does remain active, so I can tell it does
> actually boot. It's just the radio that doesn't come up. I managed to get
> back in range of a network once, and the router worked as expected.
>
> It doesn't matter whether the AP or client connection are configured first
> or second on the radio interface, and, unticking "bring up on boot" for the
> wwan interface has no effect on the behaviour.
>
> Steps to reproduce: Connect the router to a wifi network as a client using
> the Join wizard. Add a wifi master-mode access point on the same radio
> interface. Verify you can access the Internet by joining the router's new
> master AP. Reboot the router with the original network it was a client of
> turned off. Notice the router's AP you configured never comes up.
>
> Expected behaviour: The master access point of the router should always
> come up, regardless of the availability of the client network.
>
> If anyone has a workaround that would be great — currently I managed to
> get back in range of a network to make it accessible again, and now I run
> from batteries and delete the wifi client configuration every night before
> the jungle power goes out.
>
> If this is indeed a bug, if you could please raise it in Trac for me —
> sorry, I get a "rejected due to possible spam" error, maybe because of my
> location.
>
> Many thanks!
> - Nick
> ___________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] 18.06 Status?

[Luiz Angelo Daros de Luca]

> One characteristic from OpenWrt, different from other projects is the
> lack of a leader or a person who can gather others together, make some
> decisions or push for them to happen. If one doesn't like this title it
> can also be "Project Manager" or "Project Coordinator". This, in my
> view, makes a big difference for things to flow in time.

Maybe we just need someone to be the Release Coordinator, that can be
responsible for a single
release. John seems to be doing that job for this one.

ML info about 18.xx release is scarce. Maybe something was discussed
elsewhere (IRC, forum, in person)

I really thing that a time based release would work better without a
central project leader.
The "when" would already be set. The "what" is what was already commited.
It could even be automated. If something is not commited yet, just wait for
the next release.
If we could do it more often (6 or 8 months), it would not matter too much
if a feature was skipped.

I have pending patches both on maillist (improves backup) and github (fixes
easy-rsa) that I would like
to have them commited (or even rejected). Most (if not all) pending patches
on github (77) or patchwork (44)
is from developers without commit access. They are potential future
developers that will keep the project
alive. I'm not specific talking about my patches but it would be kind to
encourage new devs to have their work
considered, even to say "NAK".

Regards,
---
  Luiz Angelo Daros de Luca
 luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 0/4] base-files: add new backup options

[Luiz Angelo Daros de Luca]

Hi Tom,

> Unrelated to upgrade. I have dnsmasq and ntpd script disabled, i make a 
> backup, then reset my device to defaults or flash some other image without 
> keeping settings. After flashing back image version from which the backup was 
> made and restoring backup, dnsmasq and ntpd are enabled again. So these 
> settings were not backed up. Not even after your changes. I've checked backup 
> file and there are no initscripts inside it.

It's an interesting situation. init system, from sysv to systemd (and
including procd) uses symlinks for service activation. If there is a
link starting with "S" at /etc/rc.d/ and it is executable, service is
enabled and it will run. When you disable a service, you get that link
removed. You can check /etc/rc.common for code.

A backup is just a tarball with files. It does not make sense to have
tarball that removes a file when extracted.

As a (not tested) suggestion, you could replace thoses link with a
broken ones, like:

ln -sf disabled /etc/rc.d/S19dnsmasq
ln -sf disabled /etc/rc.d/K19dnsmasq
ln -sf disabled /etc/rc.d/S98sysntpd
ln -sf disabled /etc/rc.d/K98sysntpd

(maybe this should be the default behavior of rccommon disable())

Another alternative is to create a startup script that tries to
disable those services on every boot.

Both might work.

> I did not apply your patch 4 that concerns packages auto installation. I 
> think you should drop that one.

It does not autoinstall packages. If a user asked for it, it only
saves a list of installed packages to help reinstalling them.

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

Re: [OpenWrt-Devel] Use DHCP by default on single port devices

[Luiz Angelo Daros de Luca]

Hi Daniel,

I do often that kind of switch: dhcpd off, static -> dhcpc. Even
though I'm not sure about this change.

I read superficially the PR. I looks like a simple change from static
to dhcp on some devices. Correct me if I'm wrong.

I guess it will break some use cases. Imagine that this change is
applied to an AP device (one ethernet, one wireless).
wireless is disable by default, ethernet now requires a DHCP server.
The user will connect that AP to a single port router (that has DHCP).
How could the use configure it? If the user plugs into the router, it
gets an IP address but wireless is still off. If the user plugs into a
computer
ethernet port, it expects a DHCP server. The user will need to install
a DHCP server on the PC. We are coming from "plug the device into
a computer port, get an IP address from device DHCP, configure the
device" to "configure PC to use static address, configure a DHCP
server, plug
the device and configure it". Remember that some home users have
limited network knowledge and no CLI experience.

Will it affect failsafe too?

Most enterprise devices do use DHCP client as default. However, they
still have a static IP address as a fallback.
If that alternative is not available, I'm fully against this change.
Static IP address might give some extra job but it is always there.
Even with a fallback IP address mechanism, DHCP server does help
configure the device the first time without touching PC settings.

"DHCP server + static IP address" still works with enterprise but
"DHCP Client", even with an alternative static IP address, might not
work for some home users.

For enterprise users, maybe it's time to customize their own firmware.
Some simple uci-defaults script can do that job nicely.

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

Re: [OpenWrt-Devel] [RFD] sysupgrade and configuration management

[Luiz Angelo Daros de Luca]

Hi Paul,

> Very nice, but having read the mail thread around Luiz' his patch, I want to 
> ask for a discussion, but outside of that patch.
>
> AFAICT from the discussion it follows that sysupgrade, opkg and UCI should be 
> kept (as much as possible) orthogonal. From the thread: opkg cannot always be 
> assumed to be available, external config management may need all 
> configuration files, not just those that changed and not just diffs, config 
> files may need changes, etc.
>
> The backup functionality in sysupgrade serves a common case of keeping config 
> files over upgrades where that's needed because the rootfs/overlay is 
> re-created. Cases where sysupgrade does not destroy the (overlay) filesystem 
> contents also exist and obviously config files aren't lost than.

Is there any case where rootfs/overlay is not destroyed? Even for x86,
sysupgrade uses dd.

> After/during a sysupgrade a normal step is the restoration of the previous 
> configuration, i.e. of config files *and* extra previously installed packages 
> - currently sysupgrade does not handle re-install of extra user installed 
> packages. This functionality could also serve cases where a certain 
> configuration is to be put on a new or other device. Where the filesystem its 
> contents is not lost during sysupgrade, this would just amount to an opkg 
> upgrade of all outdated packages after sysupgrade has upgraded the kernel and 
> possibly the rootfs.
>
> In the more common sysupgrade case though (overlay contents are lost), some 
> means is needed to preserve configuration data in order to be able to restore 
> the configuration. Where this data is preserved during sysupgrade depends 
> completely on the device specific sysupgrade mechanism; *what* data is saved 
> and *how* it is re-applied is preferably opaque to, and independent of, 
> sysupgrade.

IMHO, backup should be a different script. It's strange to ask
sysupgrade for a backup (and worse to restore one). It might be just
legacy calling for a refactoring.

> Also, during upgrades new versions of packages may require updates to the 
> config files. Preserving customisations of the config files cannot just be 
> handled with back-up/restore and may require applying a diff or user 
> intervention. How to deal with that can really only be determined by the 
> package maintainer and so must be handled by the package itself. Anyhow, this 
> clearly is in the domain of opkg and applies to upgrades outside of 
> sysupgrade as well.

RPM, as opkg, simply saves the files and let user solve it manually.
Doing it automagically will require too much resource from maintainers
and the device that we might not have.
I guess we have what we can get. CM might replace the "package
installation and configuration" part of the backup but it is not a
backup. You still might need to save some data.
For me, backup and CM are different beasts.

> In short, factoring out the configuration management functionality (CM) seems 
> a good idea. The sysupgrade subsystem handles with upgrading kernel and 
> rootfs and may invoke CM functions to preserve the user configuration. CM can 
> could also take care of user installed packages. CM calls opkg to install 
> and/or upgrade additional packages. Truly general back-up (e.g. as a defense 
> against data loss) is outside the scope of sysupgrade.
>
> Quite a few efforts have already been made toward some kind of CM, notably by 
> offering this as an external service. The task to factor out generic CM  
> functionality that can be called upon in different contexts is probably quite 
> complicated and comments on that idea are welcome.
>
> What would be a practical API, if any, for CM ?
> What (minimum) configuration data would be needed by CM, i.e. what's needed 
> besides config files to store user install selections ?
> What's needed to enhance opkg so that it can handle in a general way updates 
> to config file while preserving user settings ?
> Compatibility issues ?
>
> Paul

I just opened a ticket for improving opkg
(https://bugs.openwrt.org/index.php?do=details_id=1821).

Another great improvement would be to require that every single file
in /etc/config should be uci generated. Today, some files are manually
edited. So, when (l)uci touches them, every single line is changed,
making diff simply useless. Would it be possible to enforce that rule
in OpenWrt? OpenWrt-packages could do that with travis (uci import
conf1/uci export conf1 to conf2/fail if conf1 and conf2 differ). It
will, although, prohibit any comments in config files from packages.

My patch and these suggestions try to reduce the burden of an upgrade.
Instead of implementing CM, it might be more useful to have tools that
help with the config merging process, like a vimdiff-like app for Luci
(remember, some users does not know how to use CLI).

Regards,

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

[OpenWrt-Devel] netifd: need help to fix FS#1463 - route with gateway absent or 0.0.0.0

[Luiz Angelo Daros de Luca]

Hello,

Docs are clear that when a route does not have the gateway field, it
will use the one from interface. However, it does not work like that.
When a route does not have a gateway, it is added as an onlink route.

I added a flag to differ between '0.0.0.0' and when gateway is absent.
The problem now is to get interface gateway. It looks like
interface_set_route_info is the place where a route copy missing
information from interface. However, at the time it runs, at least for
proto dhcp, iface->proto_ip->route and iface->config_ip->route are
empty. When interface gets an address from DHCP,
proto_shell_parse_route_list is called to add the default route.

Shouldn't the interface routes be included only after the interface is
up and configured (proto_shell_update_link) and not from the config
init (config_init_routes)?

My WIP is here
https://github.com/luizluca/netifd/commit/7ab84972bda51d34295d1938e07ed7efc3b2215d

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

[OpenWrt-Devel] [PATCH v2 3/4] base-files: add sysupgrade -o to save all overlay files

[Luiz Angelo Daros de Luca]

Add sysupgrade '-o' option in order to include all overlay files in
backup, except for those that are from packages but including files
listed in conffiles, sysupgrade.conf or /lib/upgrade/keep.d.

With '-u' option, it will skip files equals to /rom and conffiles that
were not changed.

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 46 +---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index 4d221ef5d6..01a942bac6 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -9,6 +9,7 @@ export INTERACTIVE=0
 export VERBOSE=1
 export SAVE_CONFIG=1
 export SAVE_OVERLAY=0
+export SAVE_OVERLAY_PATH=
 export SAVE_PARTITIONS=1
 export SKIP_UNCHANGED=0
 export CONF_IMAGE=
@@ -27,7 +28,8 @@ while [ -n "$1" ]; do
-v) export VERBOSE="$(($VERBOSE + 1))";;
-q) export VERBOSE="$(($VERBOSE - 1))";;
-n) export SAVE_CONFIG=0;;
-   -c) export SAVE_OVERLAY=1;;
+   -c) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/etc;;
+   -o) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/;;
-p) export SAVE_PARTITIONS=0;;
-u) export SKIP_UNCHANGED=1;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
@@ -60,6 +62,8 @@ upgrade-option:
-f   restore configuration from .tar.gz (file or url)
-i   interactive mode
-c   attempt to preserve all changed files in /etc/
+   -o   attempt to preserve all changed files in /, exept those
+from packages but including changed confs.
-u   skip from backup files that are equals to those in /rom
-n   do not save configuration over reflash
-p   do not attempt to restore the partition table after flash.
@@ -129,12 +133,48 @@ add_conffiles() {
 
 add_overlayfiles() {
local file="$1"
-   ( cd /overlay/upper/; find ./etc \( -type f -o -type l \) $find_filter 
| sed \
+
+   local packagesfiles=$1.packagesfiles
+   touch "$packagesfiles"
+
+   if [ "$SAVE_OVERLAY_PATH" = / ]; then
+   local conffiles=$1.conffiles
+   local keepfiles=$1.keepfiles
+
+   list_conffiles | cut -f2 -d ' ' | sort -u > "$conffiles"
+
+   # backup files from /etc/sysupgrade.conf and 
/lib/upgrade/keep.d, but
+   # ignore those aready controlled by opkg conffiles
+   find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
+   /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) 
\
+   \( -type f -o -type l \) 2>/dev/null | sort -u |
+   grep -h -v -x -F -f $conffiles > "$keepfiles"
+
+   # backup conffiles, but only those changed if '-u'
+   [ $SKIP_UNCHANGED = 1 ] &&
+   list_changed_conffiles | sort -u > "$conffiles"
+
+   # do not backup files from packages, except those listed
+   # in conffiles and keep.d
+   find /usr/lib/opkg/info -type f -name "*.list" | sort -u |
+   xargs -r grep -h -v -x -F -f $conffiles |
+   grep -v -x -F -f $keepfiles > "$packagesfiles"
+   rm -f "$keepfiles" "$conffiles"
+   fi
+
+   # busybox grep bug when file is empty
+   [ -s "$packagesfiles" ] || echo > $packagesfiles
+
+   ( cd /overlay/upper/; find .$SAVE_OVERLAY_PATH \( -type f -o -type l \) 
$find_filter | sed \
-e 's,^\.,,' \
-e '\,^/etc/board.json$,d' \
-e '\,/[^/]*-opkg$,d' \
-e '\,^/etc/urandom.seed$,d' \
-   )> "$file"
+   -e '\,^/usr/lib/opkg/.*,d' \
+   ) | grep -v -x -F -f $packagesfiles > "$file"
+
+   rm -f "$packagesfiles"
+
return 0
 }
 
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 0/4] [RFC] base-files: add new backup options

[Luiz Angelo Daros de Luca]

My previous patch on Nov2017 
(http://lists.infradead.org/pipermail/lede-dev/2017-November/009892.html)
generated some discussion because it depends on the presence of /rom to become
effetive. So I opted to turn it into a new sysupgrade option (-u).

Besides that, I added some more stuff to sysupgrade that I use in
my systems.

Each patch in this series is almost indepenly of each other.
Except for the first one, they add new sysupgrade options:

-u) equivalent to the previous patch. I think that, if adopted as
default in future, it will make upgrades cleaner. For now, it
is optional.

-o) this option tries to save everything that was changed. It includes
all new files, conffiles (works with -u), sysupgrade.conf and
keep.d. This is what I normally use in my backups as it saves both data
and confs, keeping them as clean as possible.

-k) This adds a new file that I use to quickly reinstall all extra
packages. A future improvement would be to use it in a service that installs
install those packages as soon as network is up (similar to uci-default
scripts)

For now, it is still pending to bump package release.

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

[OpenWrt-Devel] [PATCH v2 1/4] base-files: minor cleanups on sysupgrade

[Luiz Angelo Daros de Luca]

Renamed add_uci_conffiles to add_conffiles as it includes
any conffiles listed, not only UCI ones.

Make do_save_conffiles arg mandatory

Allow other options after -l (like -c)

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index bf5428af25..46e46c3342 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -30,7 +30,7 @@ while [ -n "$1" ]; do
-p) export SAVE_PARTITIONS=0;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
-r|--restore-backup) export CONF_RESTORE="$2" NEED_IMAGE=1; 
shift;;
-   -l|--list-backup) export CONF_BACKUP_LIST=1; break;;
+   -l|--list-backup) export CONF_BACKUP_LIST=1;;
-f) export CONF_IMAGE="$2"; shift;;
-F|--force) export FORCE=1;;
-T|--test) export TEST=1;;
@@ -49,10 +49,10 @@ export CONF_TAR=/tmp/sysupgrade.tgz
 
 IMAGE="$1"
 
-[ -z "$IMAGE" -a -z "$NEED_IMAGE" -o $HELP -gt 0 ] && {
+[ -z "$IMAGE" -a -z "$NEED_IMAGE" -a $CONF_BACKUP_LIST -eq 0 -o $HELP -gt 0 ] 
&& {
cat <...] 
-   $0 [-q] [-i]  
+   $0 [-q] [-i] [-c]  
 
 upgrade-option:
-f   restore configuration from .tar.gz (file or url)
@@ -115,7 +115,7 @@ list_changed_conffiles() {
done
 }
 
-add_uci_conffiles() {
+add_conffiles() {
local file="$1"
( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
/etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
@@ -131,6 +131,7 @@ add_overlayfiles() {
-e '\,/META_[a-zA-Z0-9]*$,d' \
-e '\,/functions.sh$,d' \
-e '\,/[^/]*-opkg$,d' \
+   -e '\,/etc/urandom.seed$,d' \
> "$file"
return 0
 }
@@ -146,13 +147,13 @@ if [ $SAVE_OVERLAY = 1 ]; then
}
sysupgrade_init_conffiles="add_overlayfiles"
 else
-   sysupgrade_init_conffiles="add_uci_conffiles"
+   sysupgrade_init_conffiles="add_conffiles"
 fi
 
 include /lib/upgrade
 
 do_save_conffiles() {
-   local conf_tar="${1:-$CONF_TAR}"
+   local conf_tar="$1"
 
[ -z "$(rootfs_type)" ] && {
echo "Cannot save config while running from ramdisk."
@@ -247,7 +248,7 @@ if [ -n "$CONF_IMAGE" ]; then
get_image "$CONF_IMAGE" "cat" > "$CONF_TAR"
export SAVE_CONFIG=1
 elif ask_bool $SAVE_CONFIG "Keep config files over reflash"; then
-   [ $TEST -eq 1 ] || do_save_conffiles
+   [ $TEST -eq 1 ] || do_save_conffiles "$CONF_TAR"
export SAVE_CONFIG=1
 else
[ $TEST -eq 1 ] || rm -f "$CONF_TAR"
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/4] base-files: add sysupgrade -u to skip unchanged files

[Luiz Angelo Daros de Luca]

With '-u', for a file /aaa/bbb/ccc enlisted for backup,
it will only get into backup if /rom/aaa/bbb/ccc does not
exist or /aaa/bbb/ccc is different from /rom/aaa/bbb/ccc.

It also works with '-c', but only effective for files touched
but not modified.

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index 46e46c3342..4d221ef5d6 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -10,6 +10,7 @@ export VERBOSE=1
 export SAVE_CONFIG=1
 export SAVE_OVERLAY=0
 export SAVE_PARTITIONS=1
+export SKIP_UNCHANGED=0
 export CONF_IMAGE=
 export CONF_BACKUP_LIST=0
 export CONF_BACKUP=
@@ -28,6 +29,7 @@ while [ -n "$1" ]; do
-n) export SAVE_CONFIG=0;;
-c) export SAVE_OVERLAY=1;;
-p) export SAVE_PARTITIONS=0;;
+   -u) export SKIP_UNCHANGED=1;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
-r|--restore-backup) export CONF_RESTORE="$2" NEED_IMAGE=1; 
shift;;
-l|--list-backup) export CONF_BACKUP_LIST=1;;
@@ -52,12 +54,13 @@ IMAGE="$1"
 [ -z "$IMAGE" -a -z "$NEED_IMAGE" -a $CONF_BACKUP_LIST -eq 0 -o $HELP -gt 0 ] 
&& {
cat <...] 
-   $0 [-q] [-i] [-c]  
+   $0 [-q] [-i] [-c] [-u]  
 
 upgrade-option:
-f   restore configuration from .tar.gz (file or url)
-i   interactive mode
-c   attempt to preserve all changed files in /etc/
+   -u   skip from backup files that are equals to those in /rom
-n   do not save configuration over reflash
-p   do not attempt to restore the partition table after flash.
-T | --test
@@ -119,20 +122,19 @@ add_conffiles() {
local file="$1"
( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
/etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
-   -type f -o -type l 2>/dev/null;
+   \( -type f -o -type l \) $find_filter 2>/dev/null;
  list_changed_conffiles ) | sort -u > "$file"
return 0
 }
 
 add_overlayfiles() {
local file="$1"
-   find /overlay/upper/etc/ -type f -o -type l | sed \
-   -e 's,^/overlay\/upper/,/,' \
-   -e '\,/META_[a-zA-Z0-9]*$,d' \
-   -e '\,/functions.sh$,d' \
+   ( cd /overlay/upper/; find ./etc \( -type f -o -type l \) $find_filter 
| sed \
+   -e 's,^\.,,' \
+   -e '\,^/etc/board.json$,d' \
-e '\,/[^/]*-opkg$,d' \
-   -e '\,/etc/urandom.seed$,d' \
-   > "$file"
+   -e '\,^/etc/urandom.seed$,d' \
+   )> "$file"
return 0
 }
 
@@ -150,6 +152,15 @@ else
sysupgrade_init_conffiles="add_conffiles"
 fi
 
+find_filter=""
+if [ $SKIP_UNCHANGED = 1 ]; then
+   [ ! -d /rom/ ] && {
+   echo "'/rom/' is required by '-u'"
+   exit 1
+   }
+   find_filter='( ( -exec test -e /rom/{} ; -exec cmp -s /{} /rom/{} ; ) 
-o -print )'
+fi
+
 include /lib/upgrade
 
 do_save_conffiles() {
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 4/4] base-files: add sysupgrade -k to save list of pkgs

[Luiz Angelo Daros de Luca]

When '-k' is used, sysupgrade inserts into backup a new file
/etc/sysupgrade.installed which contains pkgname and
origin (rom, overlay, unknown).

It's maily used to reinstall all extra packages:

 # opkg update
 # grep "\toverlay" etc/sysupgrade.installed | cut -f1 | xargs opkg install
 # rm etc/sysupgrade.installed

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index 01a942bac6..c5067a757b 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -11,6 +11,7 @@ export SAVE_CONFIG=1
 export SAVE_OVERLAY=0
 export SAVE_OVERLAY_PATH=
 export SAVE_PARTITIONS=1
+export SAVE_INSTALLED_PKGS=0
 export SKIP_UNCHANGED=0
 export CONF_IMAGE=
 export CONF_BACKUP_LIST=0
@@ -31,6 +32,7 @@ while [ -n "$1" ]; do
-c) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/etc;;
-o) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/;;
-p) export SAVE_PARTITIONS=0;;
+   -k) export SAVE_INSTALLED_PKGS=1;;
-u) export SKIP_UNCHANGED=1;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
-r|--restore-backup) export CONF_RESTORE="$2" NEED_IMAGE=1; 
shift;;
@@ -50,6 +52,7 @@ done
 
 export CONFFILES=/tmp/sysupgrade.conffiles
 export CONF_TAR=/tmp/sysupgrade.tgz
+export INSTALLED_PACKAGES=/etc/sysupgrade.installed
 
 IMAGE="$1"
 
@@ -67,6 +70,8 @@ upgrade-option:
-u   skip from backup files that are equals to those in /rom
-n   do not save configuration over reflash
-p   do not attempt to restore the partition table after flash.
+   -k   include in backup a list of current installed packages at
+$INSTALLED_PACKAGES
-T | --test
 Verify image and config .tar.gz but do not actually flash.
-F | --force
@@ -203,6 +208,15 @@ fi
 
 include /lib/upgrade
 
+targz_append() {
+   local tar="$1"
+   local append_tar="$2"
+   (   gunzip -c "$tar" | head -c -1024;
+   gunzip -c $append_tar
+   ) | gzip > $tar.new
+   mv -f $tar.new $tar
+}
+
 do_save_conffiles() {
local conf_tar="$1"
 
@@ -219,6 +233,22 @@ do_save_conffiles() {
[ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
tar c${TAR_V}zf "$conf_tar" -T "$CONFFILES" 2>/dev/null
 
+   if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
+   mkdir -p /tmp/etc
+   cd /tmp/
+
+   # Format: pkg-name{rom,overlay,unkown}
+   # rom is used for pkgs in /rom, even if updated later
+   find /usr/lib/opkg/info -name "*.control" \( \
+   \( -exec test -f /rom/{} \; -exec echo {} rom \; \) -o \
+   \( -exec test -f /overlay/upper/{} \; -exec echo {} 
overlay \; \) -o \
+   \( -exec echo {} unknown \; \) \
+   \) | sed -e 's,.*/,,;s/\.control /\t/' > 
${INSTALLED_PACKAGES:1}
+
+   tar c${TAR_V}zf sysupgrade.installed.packages.tgz 
${INSTALLED_PACKAGES:1}
+   targz_append "$conf_tar" sysupgrade.installed.packages.tgz
+   rm -f sysupgrade.installed.packages.tgz ${INSTALLED_PACKAGES:1}
+   fi
rm -f "$CONFFILES"
 }
 
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2 2/4] base-files: add sysupgrade -u to skip unchanged files

[Luiz Angelo Daros de Luca]

> This patch series works very nicely for me on ar71xx, brcm47xx, ipq806x
> and lantiq, -u unclutters the overlay contents quite significantly and
> makes spotting (manual) changes a lot easier.

Thanks Stefan for the feedback. If you want to simply spot changes, I would
recommend '-o -l'.
I normally use '-o -u -k -b mybkp.tgz'.

I use backup like these for years and since last year I'm trying to share
it to everybody. It has already saved me several hours.

For those that want to keep track, I'm using this branch for it:

https://github.com/luizluca/openwrt/raw/better-backups-v2/package/base-files/files/sbin/sysupgrade

It already has some minor fixes on top of sent patches.

And for those that simply want to test it (or use it):

$ wget -O /sbin/sysupgrade.alt
https://raw.githubusercontent.com/luizluca/openwrt/better-backups-v2/package/base-files/files/sbin/sysupgrade
$ chmod +x /sbin/sysupgrade.alt

It's a shame githubusercontent.com forces https.

It is safe to use this "standalone version" even on LEDE 17.01.x for
creating backups (-b) as all used code is in sysupgrade itself.
However, I still use unchanged sysupgrade for flashing (passing the backup
archive using -f). Flashing depends on external files (/lib/upgrade)
whose changes might also depend on a sysupgrade change.

Regards,

---
  Luiz Angelo Daros de Luca
 luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Is printf considered to be guaranteed?

[Luiz Angelo Daros de Luca]

I think so. It is compiled by default:

$ grep PRINTF -A2 package/utils/busybox/Config-defaults.in
config BUSYBOX_DEFAULT_PRINTF
bool
default y
--
config BUSYBOX_DEFAULT_ASH_PRINTF
bool
default y
--
config BUSYBOX_DEFAULT_HUSH_PRINTF
bool
default n

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt Roadmap

[Luiz Angelo Daros de Luca]

Hello,

There are a significant amount of devices out there that has 4/32
specs. Even brand new ones.
If there is stability issues with newer OpenWrt versions on those
devices, we should rethink LEDE EOL.

Maintenance burden is directly related to the amount of software to
maintain. At the same time, low specs means they might have no
interest in most packages.
Maybe 15.05 life could be extend with a lower cost by limiting
maintenance to a subset of packages (core? even less?). We could
release LEDE 15.05.(x+1) LTS with feeds configured to use only that
subset of packages. We could also limit the images to those low spec
models.

EOL is not really a big deal until it requires a new HW. Routers are
things that die hard, even after a decade. It just doesn't seem right
to turn old working hw into electronic waste because of software.
Keeping old stuff running is even on of the reasons to use OSS.

Regards,

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

[OpenWrt-Devel] Download link not working for 18.06.5 and 19.07.0rc1

[Luiz Angelo Daros de Luca]

Hello,

The OpenWrt front page has a "Download a firmware image for your device"
for each released version. However, the last two links are currently
useless. Both show no devices.

For 18.06.5, it seems that something somewhere must be updated from 18.06.4
to 18.06.5.

For 19.07, it could be only a temporary issue while in RC. However, if so,
OpenWrt should not advertise that link for now.

And please, hide "Firmware OpenWrt snapshot Install URL" and "Firmware
OpenWrt snapshot Upgrade URL" from a ToH link that filter support for a
specific release. It only allows the user to wrongly install snapshot
versions.

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.07 status

[Luiz Angelo Daros de Luca]

Hello,

19.07 page has a Roadmap without dates:
https://openwrt.org/releases/19.07/start#roadmap

It should have some real info with dates, something to make clear that it
does not have a real schedule ("It's ready when it is ready") or simply get
removed.

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ethernet broken on ath79/tl-wr2543nd since upgrade to kernel 5.4

[Luiz Angelo Daros de Luca]

Hello,

Since upgrade to kernel 5.4, I got no network with tp-link tl-wr2543nd. It
failed to initialize ethernet driver:

With 5.4:

[0.747634] rtl8367 rtl8367: cannot find mdio node phandle
[0.753186] rtl8367 rtl8367: using GPIO pins 1 (SDA) and 6 (SCK)
[0.759900] rtl8367 rtl8367: RTL8367R ver. 0 chip found
[2.584910] random: fast init done
[2.799942] libphy: rtl8367: probed
[2.839257] libphy: Fixed MDIO Bus: probed
[2.847887] ag71xx: probe of 1900.eth failed with error -2

With 4.19:

[0.744922] rtl8367 rtl8367: cannot find mdio node phandle
[0.750555] rtl8367 rtl8367: using GPIO pins 1 (SDA) and 6 (SCK)
[0.757212] rtl8367 rtl8367: RTL8367R ver. 0 chip found
[2.586809] random: fast init done
[2.801820] libphy: rtl8367: probed
[2.840548] libphy: Fixed MDIO Bus: probed
[3.217608] ag71xx 1900.eth: connected to PHY at fixed-0:00
[uid=, driv]
[3.227646] eth0: Atheros AG71xx at 0xb900, irq 4, mode: rgmii

I'm using serial interface and I'm testing using initram.

Wireless and swconfig seems to be OK. However, I get not eth0.
Does anyone have a clue where it is broken?

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFC: versions.json

[Luiz Angelo Daros de Luca]

Hello,

Thinking on which info the client side would need, I would remove the
minors info if we can just skip to latest. And, It's missing a changelog
link. Also, each release can have its own info.json with more info.

How would it deal with devices that cannot be upgrades (like the past case
of 4/32)? Or will it bother the user forever with a nonsense upgrade
suggestion? How would it deal with devices target or subtarget changes
(like ar71xx -> ath79, or generic -> tiny) or this is more a "go to
OpenWrt.org" instead of "click here to download"? And aborted releases that
brick devices until a new release is ready, specially when they are
specific to a device?

The version.json would speed up upgrade rollout. It would also increase the
impact of a bugged upgrade. I would be nice to have something like a staged
release process, even just for suggesting them to the user. We could create
some form of machine id mixing device mac, urandom seed, board id and the
new release version and use it for selecting a device for a stage. It could
be a client-side-code only strategy but versions.json could inform the
proportion of each stage.

It would also be interesting to have some form of automatic or manual
success feedback like "Notify OpenWrt if your upgrade worked". This way, a
backend could be notified before the upgrade and expect a response
afterwards.

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

[OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

Hello,

I'm trying to debug
https://bugs.openwrt.org/index.php?do=details_id=2742.
So far, what I discovered:

1) it happens only in master, 19.07 is fine on both ath79 and ar71xx
2) it happens only in ath79. ar71xx is fine in master
3) rootfs_data (mtd4) contents keeps changing on each read. Each time I
run: "dd if=/dev/mtd4 | md5sum - " I get a different hash.
4) I get the random data reading flash from firmware (mtd1), rootfs (mtd3)
or rootfs_data(mtd4), but always around the region where rootfs_data is
(after squashfs). I could not identify the exactly upper and lower
boundaries where it happens (addresses are random).
5) I also happens without mounting jffs2 (failsafe)
6) Most mtd4 is 0xff (as expected). Only sparse bytes or sequence of bytes
contains other values.
7) I looked for a string inside mtd4 (if I came some a buffer), but changes
where too small and without any sequence of printable chars.

There are plenty of longs in the bug report.

Has someone faced something similar?

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

Hello,

I isolated the problem to be kernel upgrade from 4.14 to 4.19. If I build
ath79 with 4.14, it simply works.
The mtd problem also happens while booting 4.19 without touching the flash
4.19 (using initram image).

Is there a mechanism to do a kernel bisect in OpenWrt?
Or does anybody have any clue of what could have caused this?

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com


Em sex., 31 de jan. de 2020 às 03:53, Luiz Angelo Daros de Luca <
luizl...@gmail.com> escreveu:

> Hello,
>
> I'm trying to debug
> https://bugs.openwrt.org/index.php?do=details_id=2742.
> So far, what I discovered:
>
> 1) it happens only in master, 19.07 is fine on both ath79 and ar71xx
> 2) it happens only in ath79. ar71xx is fine in master
> 3) rootfs_data (mtd4) contents keeps changing on each read. Each time I
> run: "dd if=/dev/mtd4 | md5sum - " I get a different hash.
> 4) I get the random data reading flash from firmware (mtd1), rootfs (mtd3)
> or rootfs_data(mtd4), but always around the region where rootfs_data is
> (after squashfs). I could not identify the exactly upper and lower
> boundaries where it happens (addresses are random).
> 5) I also happens without mounting jffs2 (failsafe)
> 6) Most mtd4 is 0xff (as expected). Only sparse bytes or sequence of bytes
> contains other values.
> 7) I looked for a string inside mtd4 (if I came some a buffer), but
> changes where too small and without any sequence of printable chars.
>
> There are plenty of longs in the bug report.
>
> Has someone faced something similar?
>
> Regards,
> ---
>  Luiz Angelo Daros de Luca
> luizl...@gmail.com
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

Thanks Chuanhong,

That is exactly what introduced the issue. I double check with and without
the patch and without it I got the random data from mtd:

Without the patch
target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch:

root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
d339cbfaf5ce709878d98bf83b853b63  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
b97c976391ae881a8139f325a18ecdb2  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# uname -a
Linux OpenWrt 4.14.167 #0 Mon Feb 3 15:18:08 2020 mips GNU/Linux

With the patch
target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch:

root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
2404e891bd9e420fc4ec45e61cdd0ca9  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
2404e891bd9e420fc4ec45e61cdd0ca9  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
2404e891bd9e420fc4ec45e61cdd0ca9  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# uname -a
Linux OpenWrt 4.14.167 #0 Mon Feb 3 15:18:08 2020 mips GNU/Linux

Buildtime are equal... maybe it is because of some reproducibility effort
that does not consider patches.
All my tests are using initram image and kernel 4.14.

The flash is a Spansion S25FL064PIF. It is the same of TL-WR842NDv1, which
has the flash section of DTS identical.

Kernel always detects it as:
[0.656283] m25p80 spi0.0: s25sl064p (8192 Kbytes)

I tried some random changes (without knowing what I'm really doing) like:

compatible = "spansion,spi-nor";
compatible = "spansion,s25sl064p", "spansion,m25p80", "jedec,spi-nor"
m25p,fast-read;

But I guess all those name variations will, in the end, mean just the same.
"m25p,fast-read" does not fix the issue as well.

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com


Em qui., 6 de fev. de 2020 às 23:57, Chuanhong Guo 
escreveu:

> Hi!
>
> On Fri, Feb 7, 2020 at 6:44 AM Luiz Angelo Daros de Luca
>  wrote:
> >
> > Hello,
> >
> > I isolated the problem to be kernel upgrade from 4.14 to 4.19. If I
> build ath79 with 4.14, it simply works.
> > The mtd problem also happens while booting 4.19 without touching the
> flash 4.19 (using initram image).
> >
>
> Flash reading is handled differently between 4.14 and 4.19. 4.14 reads
> directly from 0x1f00 where spi is mapped. But the interface used
> for that got removed in 4.19 so bit-bang mode is used instead.
> Could you try if removing
> target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch
> also breaks ath79/4.14?
>
> Regards,
> Chuanhong Guo
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

> There's no need for this. If it's implemented we could simply
> use it on all chips and gain the increased flash reading speed.
>

Ok. I'm using it during my tests, but I could remove it in the final
version.


> On memory-mapped flash reading, spi controller issues 0x0b
> fast-read instruction. for the sake of correctness in spi-mem
> we should check whether spi-mem-op matches 0x0b + 3-byte
> address + 1-byte dummy before executing the operation.
> You'll need to set m25p,fast-read for spi-nor code to generate
> this matching operation.
>

The old fast read patch did not check the dummy byte. I'll do it as you
suggested.

I already have a working WIP patch. It does fix the issue. I might post a
RFC version today.

Regards,
> Chuanhong Guo
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Rebuild kernel modules from changed packages for each stable dot release

[Luiz Angelo Daros de Luca]

Hello,

ksmbd recently got an update for 19.07. It consists on a kernel module and
some auxiliary programs. The auxiliar programs got into the oficial repo as
usual. However, the new userland package might be incompatible with the old
kernel module.

I downloaded the last SDK and the kernel module package dir and it built
nicely.

Once a package kernel module is changed on a stable branch, can we rebuild
it with each previous dot releases SDK for each target and subtarget? And,
finally, add the new kmod*.ipk to the respective
//kmods//?

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ToH dump missing HW version

[Luiz Angelo Daros de Luca]

Hello,

I was using https://openwrt.org/_media/toh_dump_tab_separated_csv.zip from
https://openwrt.org/supported_devices and it is missing the hardware
version.
It is also missing the "unsupported features". Both are quite important for
selecting a device.
Wiki dynamic table does include them.

Can someone add it?

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] openwrt-18.06 broken since kernel bump 4.14 to 4.14.169

[Luiz Angelo Daros de Luca]

Hello,

I was doing a clean build for 18.06 and got:

x86 instruction decoder selftest (X86_DECODER_SELFTEST) [N/y/?] (NEW)
aborted!

It looks like kernel bump happened both in openwrt-19.07
(eca8a2ee0d4404d9454cac473ee8d4d1ce7152e4) and openwrt-18.06
(4eba86820fd3d0ccf1f8e6addaa24ed6cd994b2f) but only openwrt-19.07 got a fix
(d91b52b1a2edd3645c88b29deb1091ae5f82fda8)

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 19.07] libpcap: Update shared-lib patch from Debian to fix linking problems

[Luiz Angelo Daros de Luca]

Hello Hauke,

libpcap is broken and this patch might be the cause.

root@xxx:~# tcpdump
Error loading shared library libpcap.so.1: No such file or directory
(needed by /usr/sbin/tcpdump)
Error relocating /usr/sbin/tcpdump: pcap_set_tstamp_type: symbol not found
...

It's missing the last digit:

root@xxx:~# opkg files libpcap1
Package libpcap1 (1.9.1-2) is installed on root and has the following files:
/usr/lib/libpcap.so.0.8
/usr/lib/libpcap.so.

root@xxx:~# opkg info libpcap1
Package: libpcap1
Version: 1.9.1-2
Depends: libc
Provides: libpcap
Status: install user installed
Section: libs
Architecture: x86_64
Size: 100915
Filename: libpcap1_1.9.1-2_x86_64.ipk
Description: This package contains a system-independent library for
user-level network packet
capture.
Installed-Time: 1587678893

Manually creating the link "libpcap.so. -> libpcap.so.1" does solve the problem.

---
     Luiz Angelo Daros de Luca
luizl...@gmail.com

---
     Luiz Angelo Daros de Luca
luizl...@gmail.com


Em sex., 20 de mar. de 2020 às 15:07, Hauke Mehrtens
 escreveu:
>
> This updates the shared-lib patch to the recent version from debian
> found here:
> https://salsa.debian.org/rfrancoise/libpcap/-/blob/debian/1.9.1-2/debian/patches/shared-lib.diff
>
> This patch makes it include missing/strlcpy.o to the shared library
> which is needed for OpenWrt glibc builds, otherwise there is an
> undefined symbol and tcpdump and other builds are failing.
>
> Fixes: 44f11353de04 ("libpcap: update to 1.9.1")
> Signed-off-by: Hauke Mehrtens 
> ---
>  package/libs/libpcap/Makefile |   4 +-
>  .../patches/100-debian_shared_lib.patch   | 194 ++
>  .../102-makefile_disable_manpages.patch   |   6 +-
>  .../103-makefile_flex_workaround.patch|   2 +-
>  4 files changed, 157 insertions(+), 49 deletions(-)
>
> diff --git a/package/libs/libpcap/Makefile b/package/libs/libpcap/Makefile
> index fae955a54d..9a78216e3a 100644
> --- a/package/libs/libpcap/Makefile
> +++ b/package/libs/libpcap/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=libpcap
>  PKG_VERSION:=1.9.1
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>  PKG_SOURCE_URL:=http://www.us.tcpdump.org/release/ \
> @@ -32,7 +32,7 @@ define Package/libpcap
>TITLE:=Low-level packet capture library
>URL:=http://www.tcpdump.org/
>MENU:=1
> -  ABI_VERSION:=1
> +  ABI_VERSION:=2
>  endef
>
>  define Package/libpcap/description
> diff --git a/package/libs/libpcap/patches/100-debian_shared_lib.patch 
> b/package/libs/libpcap/patches/100-debian_shared_lib.patch
> index 454490fbfa..ab70417de7 100644
> --- a/package/libs/libpcap/patches/100-debian_shared_lib.patch
> +++ b/package/libs/libpcap/patches/100-debian_shared_lib.patch
> @@ -3,12 +3,13 @@ build a shared library.
>
>  --- a/Makefile.in
>  +++ b/Makefile.in
> -@@ -40,6 +40,13 @@ mandir = @mandir@
> +@@ -40,6 +40,14 @@ mandir = @mandir@
>   srcdir = @srcdir@
>   VPATH = @srcdir@
>
>  +# some defines for shared library compilation
> -+LIBVERSION=1
> ++MAJ=0.8
> ++LIBVERSION=$(shell head -1 debian/changelog | perl -nle 
> 'm/\S+\s+\((\S+)-\S+\)/ and print $$1')
>  +LIBNAME=pcap
>  +LIBRARY=lib$(LIBNAME).a
>  +SOLIBRARY=lib$(LIBNAME).so
> @@ -17,38 +18,38 @@ build a shared library.
>   #
>   # You shouldn't need to edit anything below.
>   #
> -@@ -69,7 +76,8 @@ INSTALL_RPCAPD=@INSTALL_RPCAPD@
> +@@ -69,7 +77,8 @@ INSTALL_RPCAPD=@INSTALL_RPCAPD@
>   EXTRA_NETWORK_LIBS=@EXTRA_NETWORK_LIBS@
>
>   # Standard CFLAGS for building members of a shared library
>  -FULL_CFLAGS = $(CCOPT) @V_LIB_CCOPT_FAT@ $(SHLIB_CCOPT) $(INCLS) $(DEFS) 
> $(CFLAGS)
>  +FULL_CFLAGS = $(CCOPT) @V_LIB_CCOPT_FAT@ $(SHLIB_CCOPT) $(INCLS) $(DEFS) 
> $(CFLAGS) $(CPPFLAGS)
> -+CFLAGS_SHARED = -shared -Wl,-soname,$(SHAREDLIB)
> ++CFLAGS_SHARED = -shared -Wl,-soname,$(SOLIBRARY).$(MAJ) 
> -Wl,--version-script=libpcap-symbols.lds
>
>   INSTALL = @INSTALL@
>   INSTALL_PROGRAM = @INSTALL_PROGRAM@
> -@@ -84,7 +92,11 @@ YACC = @YACC@
> +@@ -84,7 +93,11 @@ YACC = @YACC@
>   # problem if you don't own the file but can write to the directory.
>   .c.o:
> @rm -f $@
>  -  $(CC) $(FULL_CFLAGS) -c $(srcdir)/$*.c
>  +  $(CC) $(FULL_CFLAGS) -c -o $@ $(srcdir)/$*.c
>  +
> -+%_pic.o: %.c %.o
> ++%_pic.o: %.c
>  +  @rm -f $@
>  +  $(CC) -fPIC $(FULL_CFLAGS) -c -o $@ $(srcdir)/$*.c
>
>   PSRC =pcap-@V_PCAP@.c @USB_SRC@ @BT_SRC@ @BT_MONITOR_SRC@ 
> @NETFILTER_SRC@ @DBUS_SRC@ @NETMAP_SRC@ @RDMA_SRC@
>   FSRC =  @V_FINDALLDEVS@
> -@@ -101,6 +113,7 @@ SRC =  $(PSRC) $(FSRC) $(CSRC) $(SSRC) $(
> +@@ -101,6 +114,7 @@ SRC =   

Re: [OpenWrt-Devel] Signing, meta-data, etc. on images and losetup mounts...

[Luiz Angelo Daros de Luca]

>
>
>
> Thanks.  Where is the beginning of the whole disk image (and end) if I
> want to “dd” it onto an SSD or SD?
>

Meta is at the end. Gunzip will give you a warning and ignored it when
expanded.

First byte of the expanded image is the disk sector 0. It is a normal disk
image with partitions. I didn't test EFI, which might use GPT but the other
one is simply a DOSMBR partitioned disk.

The default size is about 256MB (or is it 128?). Just dd it to something a
little bit bigger and let it run.

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Luiz Angelo Daros de Luca]

Hello,

I had the same feeling since I saw this patch. I would really like
something that could transparently allow me to bridge
either DSA ports, standard ethernet ports or even have a syntax that
would be compatible with swconfig (where dsa is not available).

It is a good opportunity to rebuild current network configuration from
scratch. Today, OpenWrt config does not make clear
how this two are connected:

config switch
   option name 'switch0'
   option reset '1'
   option enable_vlan '1'

config interface 'lan'
   option type 'bridge'
   option ifname 'eth0.1'
   option proto 'static'
   option ipaddr '192.168.1.1'
   option netmask '255.255.255.0'

And we still have wireless:

config wifi-iface 'wifinet0'
   option device 'radio0'
   option mode 'ap'
   option network 'lan' #shouldn't it be "interface"?

It's confusing for someone just arriving that switch0 will use eth0
and switch0 vlan 1 will be mapped to eth0.1. And, after bringing up
the interface, we have a br-lan, not mentioned anywhere.
Both L2 and L3 configurations are mixed, with part of it being even in
a separated configuration file (wireless).

The same feeling is still with this DSA proposal. The syntax "lan2.t
lan2 lan3 lan5" is unstructured and it does not help too.
The use of "switch0" for cpu interface is good and I think it should
even be used for swconfig (simply rename eth0 to switch0 by default
and it will improve usability).
Trying to reuse the current swconfig syntax might be a curse that will
haunt us. We could have simply 2 sections: bridge (L2) and interface
(L3). My proposal:

config bridge br-lan <- the real bridge device name
  option type "auto" # use the best way to merge every ports
  # swconfig
  list port switch0@1.1 # switch0, port 1, vlan 1, untagged
  list port switch0@2.1 # switch0, port 2, vlan 1, untagged
  list port switch0@3.1t # switch0, port 3, vlan 1, tagged
  list port switch0@4.2t # switch0, port 4, vlan 2, tagged
  list port switch0@4 # switch0, port 4, no vlan filtering (trunk mode)
  # DSA
  list port lan1 # lan1, no vlan filtering (trunk mode)
  list port lan2.1  # lan2 port, vlan 1, untagged
  list port lan3.1t # lan3 port, vlan 1, tagged
  list port lan3.2t # lan3 port, vlan 2, tagged
  # Other interfaces
  list port eth0 # eth0 port, no vlan filtering (trunk mode)
  list port eth0.2t # eth0 port, vlan 2, tagged
  list port wlan0 # it could also be specified in wifi-iface

# for swconfig, where wan would be what eth0.2 is today (simply renamed).
# it might keep the current misunderstanding that eth0.2 is not wan
port but a two-port bridge
# between CPU and wan ports
bridge wan
  list port switch0@0 # swith0, port 0, no vlan filtering

# for DSA or swconfig
interface wan
  ifname wan
  proto dhcp

interface lan
  ifname lanbridge0 #<- the real bridge device name
  proto static
  ...



config wifi-iface 'wifinet'
   option bridge lanbridge0
   ...

I don't have a working DSA system to test on but according to
https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html,
it looks like DSA could allow two different ports to use the same vlan
but belong to different bridges. swconfig does not allow that setup
when you use two bridges. But, it could join them using software
bridges. There are obviously incompatible arrangements but the system
could detect them if the configured setup is not possible and avoid to
load them (or load whatever is possible). The bridge device might be
a DSA switch, a software bridge, or simply the CPU port (maybe even
using openvswitch when available?).

My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel)
but it looks easier than current swconfig and dsa proposed
configuration.
The main points are to split L2 and L3 confs, split port list into
individual options and let the system decide the best way to implement
the proposed setup.

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Luiz Angelo Daros de Luca]

> > config bridge br-lan <- the real bridge device name
>
> This is invalid uci syntax, dashes are not allowed. It also duplicates "config
> device" with "option type bridge".

Yes, "config device" is better. If used, a wireless definition would
now reference a device
and not an interface.

> >   option type "auto" # use the best way to merge every ports
>
> What possible ways would there be?

The bridge type to use. It could be a software bridge, DSA,
swconfig, openvswitch.
But with a device section, "option type 'openvswitch'" might already cover it.

> It might be a matter of taste but personally I don't see what is easier about
> it. The main change seems to be that instead by VLAN ID, your proposal groups
> the port memberships by bridge. So instead having a vlan section that attaches
> ports to a bridge, you declare a bridge containing ports with their respective
> VLAN IDs.

A bridge is a broader concept than a vlan inside a switch. It might
include ports that
use different vlans (although not very common) or devices outside the switch.
Linux configures DSA using the bridge concept and not vlans. I think using vlan
would simply make it harder to map or limit what you can do with it.

I'm still ignorant about DSA and all I know is only from docs. Would
it be possible
to simply connect any ethernet device to a DSA bridge? Something like:

ip link add name br0 type bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
ip link set dev usb0 master br0

> > The main points are to split L2 and L3 confs, split port list into
> > individual options and let the system decide the best way to implement
> > the proposed setup.
>
> Point 1 is already doable, point 2 can be easily added (in fact changing
> "option ports 'lan1 lan2 lan3'" to "list ports lan1; list ports lan2; list
> ports lan3" is possible without changing any code).
>
> I disagree with point 3. Having a network config that automagically translates
> into different things on different boards makes debugging potential issues
> very hard. The uci network config is too low level for that imho.

You are right. It would not be nice to have too much implicit
configuration. A more complex
setup might use a device that references other devices.

Regard,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

Re: Restoring (old) config backups and

[Luiz Angelo Daros de Luca]

Hello,

> The problems we've observed with the backup *restore* functionality are:
>
> * It is applied with a simple reboot, and _apparently_, it has no hooks
> or other way to ensure system sanity before (or after) the backup restore.
>
> Which would be fine if the following point was never true:
>
> * End users are likely to use the backup-restore facility across
> sysupgrade (i.e. use older backups).
>
>
>
> Some possible root causes of the issues created on backup restoration:
>
> 1. /etc/uci-defaults is not "reset" like a sysupgrade would.  When the
> backup is "outdated" from the PoV of current packages in the running
> firmware image, it can cause issues ranging from minor, to severe.

It would be interesting to have a way to do firstboot+restore in a
single step (as cmdline can sysupgrade/restore).
However uci-defaults seems to be used to generate missing
configuration, not converting an existing one. A package
update could (ab)use this to migrate an existing configuration, but it
does seem to be the ideal usage (there are pre/post scripts).

> 2. Account information is not properly sanitized/recreated (/etc/passwd,
> shadow, group).  Thus, system accounts that were meant to be used by
> packages might be missing or have incorrect contents.   This is a
> consequence of (1), thus not a "root cause", but I find it relevant
> enough to mention it explicitly.
>
> If things fail to start because of missing system users, it is bad.
> When they *don't* fail to start and instead run as root, it is arguably
> *worse*.

It is a harder problem as it is not a simple migration but a merge process.
Somehow, a merge process will have to read both files at the same time
and merge them.
Today, the backup is restored directly over existing files. The merge
process would require
to expand it to a temporary directory and do the merge process.

> Some possible solutions:
>
> * It is not too hard to bake a firmware image uuid, randomly generated
> at build-time, add it to the backup tarball, and use it to detect the
> fact that we (re-)booted into a new environment that should go through
> /etc/uci-defaults processing as if it had been through a sysupgrade.

I guess uci-defaults is not ideal for that task. Those scripts are
meant to run once and get discarded after that.
UUID gives less info than BUILD_ID. It would be nice to have some form
of version information inside the backup,
even if it is informational only, like a /etc/.config_restored_version.

> This requires /etc/uci-defaults scripts that can handle being run when
> the changes they need to apply are already in place, which is *already*
> a best-practice, but still...

I imagine it could be possible to have something similar to database
migration scripts, where a set of atomic migrations occurs between
version x and version x+1. They would run only when
/etc/.config_restored_version exists. They should run immediately
after the restore happens. After that, /etc/.config_restored_version
could be removed or, in case a migration script fails, identify the
last working step.
Ideally, all these processes should be executed in a form of
"snapshot" of existing rootfs (a new layer of overlayfs?) and just
applied when it is finished.

It looks better than an "option migrated_featureX 1".

> Alternatively, or perhaps additionally to uci-defaults, it could run
> package-provided scripts from a directory on restore (pre-reboot,
> after-reboot).

It would be better if all migration could occur immediately after the
restore. However, there are two moments when a restore happens: when
the user asks for it and during
a sysupgrade that keeps existing configuration or provides a backup file.

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Luiz Angelo Daros de Luca]

> The disadvantage is that the wireless config has to be different if we switch 
> to a default config with no separate LAN bridge, and it becomes potentially 
> more confusing for common use cases.
> I think semantically it fits quite well to just assign a Wifi interface to 
> the lan network and hide some implementation details of what that means.

I think we should try hard to split between L2 and L3 as a goal. Those
convenient shortcuts (interface.type=bridge) make it harder for a
newcomer to understand what is going on. I would try to avoid them.
I had to explain the mixed concepts dozens of times for newbies, even
for those with Linux experience. It's just confusing that linux
network devices, which are also called network interfaces, are not
OpenWrt interfaces. I hope someday I could see the same "names" both
in config and the output from network commands like ip address.
OpenWrt interface name could be a label for an address.

OpenWrt uses multiple names "ifname, iface, device, network,
interface" sometimes for the same and also different concepts. Those
names/references should be standardized. Choose one and stick with it.
Also, there is the problem of how to reference a device/interface. It
should be much easier if the section name could be always used.
However, uci has its limitations, which requires an "option name".
I would use "option name" as "section name" by default, requiring it
to be set explicitly only as a way to overcome the uci section name
limitations.

Wireless defines a network device and maybe wifi-iface should be
declared simply as a type of device with some extra options and a
reference to a radio. BTW, wireless.wifi-device introduces another
confusion with network.device and simply "radio" might be better.

It would be better to have predictable interface names for everything.
If it is not possible, we could introduce a reverse option
"device_for". As both device and interface section can have a device
option, "option device_for" could use both as a valid value.

This is a simple example to illustrate general idea:

config radio 'radio0'
   option type 'mac80211'
   option hwmode '11a'

config device 'wifinet_wan'
   option type wifi
   option ssid 'uplink_wwan'
   option radio 'radio0'
   option mode 'sta'
   option device_for wan # reverse referenced for an interface

config device 'wifinet_OpenWrt' # wifinet_ap will be the linux network
device name
   option type wifi
   option ssid 'OpenWrt'
   option radio 'radio0'
   option mode 'ap'
   option device_for brlan # reverse referenced for a device

config device 'wifinet_OpenWrt2' # wifinet_ap2 will be the linux
network device name
   option type wifi
   option ssid 'OpenWrt2'
   option radio 'radio0'
   option mode 'ap'

config device brlan
   type bridge
   # option name brlan # by default, no need to set
   list device dev1
   list device dev2
   list device dev3
   # list device wifinet_OpenWrt
   list device wifinet_OpenWrt2 # directly referencing

config interface lan
   option device brlan #device instead of ifname
   option proto static

config interface lan6
   option device @lan #the value for lan.device
   option proto static

config interface wan
   # option device wifinet_wan
   option proto dhcp

---
 Luiz Angelo Daros de Luca

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

Re: 20.xx: postponse LuCI HTTPS per default

[Luiz Angelo Daros de Luca]

Hi,

I guess we could simply ask the user by default (with options to auto
generate a certificate or ignore https). Luci already warns that a
root password must be set.
Why not also add something like: "Upgrade to a secure connection?".


   "No password Set!
   There is no ...
   ...
   "

   "You are using an unencrypted connection!
   Before informing sensitive information, like a password, it is
recommended to enable encryption (https)
   ...
# it will require authentication if a
password is already set
   "

If the user opts to use it, it could generate a self-signed
certificate and offer it to be downloaded/imported even before using
it.

   http://192.168.1.1/luci/https-settings#generate-self-signed...

   HTTP Settings:

 #if "the certificate is not trusted by the browser. Can we test it using ajax?"
   
   Click here to download and import the router certificate now.
Otherwise, your browser will
   warn you that the router certificate is not trusted. Then, you can
ignore the error and continue. However,
   it would be safer to add the router to browser certificate
exceptions. You might need to do it again every time
   the certificate is regenerated.

   If the certificate warning page reappears again for the same router
at the same browser, it might not be automatically
   trusted as it could be a malicious device impersonating your router
trying to steal your credentials.
 #endif

   [Generate a new self-signed certificate]
   [Generate a new certificate request] / [Import the signed
certificate] # if a CSR was generated
   [Generate a new Let's Encrypt certificate] # it would be a nice add-on
   [Remove current certificate and disable encryption]

The next luci request will redirect the browser to https://

My 2 cents,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Luiz Angelo Daros de Luca]

> When saving the list of installed pkgs, also store the status of the
> system services. The list is created in the etc/backup folder also
> and formated as:
>
> /etc/init.d/ {enable|disable}
>
> This way it can be sourced after sysupgrade, to restore the previous
> state.

I also liked the idea. I didn't like the use of -k option (save a list
of installed packages). I would either create a new option for it,
enable it when -c or -o is in use, or simply enable it by default.

I also think that ${SERVICE_STATUS} could be executed by default after
the reboot. If the user asked to preserve service status, it could be
implicitly assumed that the user wants to restore it after the backup
is applied. The problem is that you cannot write directly to
/etc/uci-defaults without touching the flash on each backup. The
/etc/backup is a good solution but you need to change when it is
mounted, and not only when '-k' is selected.

I would create a new /etc/uci-defaults/01-post-restore.sh provided by
base-files (and not created by a backup) that would read a possible
/etc/backup/post-restore.sh script. There you could place your
enable/disable calls.

Regards,

Luiz Angelo

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

tcpdump missing packets with different filters for different interfaces

[Luiz Angelo Daros de Luca]

Hello,

While debugging with tcpdump, I noticed some strange results. I tested
both with tcpdump-mini and tcpdump in 19.07. My router uses the
standard eth0.2 as wan, eth0.1 and multiple wlan bridged br-lan.

While pinging dns.google (ipv6 and ipv4), I tried these with tcpdump(-full):

Listening to "any", I got only IPv4 (wlan, br-lan, eth0.2 /  eth0,
eth0.2, br-lan, wlan), I got no IPv6

# tcpdump -i any icmp or icmp6 -n
01:02:21.804830 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 30, length 64
01:02:21.804830 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 30, length 64
01:02:21.804946 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 30, length 64
01:02:21.826868 ethertype IPv4, IP 8.8.8.8 > 999.999.96.75: ICMP echo
reply, id 46, seq 30, length 64
01:02:21.826868 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 30, length 64
01:02:21.826962 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 30, length 64
01:02:21.826978 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 30, length 64

If do not use filter, I can see the expected ICMPv6 packets arriving:

# tcpdump -i any -n
01:22:06.348704 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 1213, length 64
01:22:06.348704 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 1213, length 64
01:22:06.348812 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 1213, length 64
01:22:06.368259 ethertype IPv4, IP 8.8.8.8 > 999.999.96.75: ICMP echo
reply, id 46, seq 1213, length 64
01:22:06.368259 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 1213, length 64
01:22:06.368357 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 1213, length 64
01:22:06.368375 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 1213, length 64
...
01:22:06.255748 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 1324, length 64
01:22:06.255748 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 1324, length 64
01:22:06.255895 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 1324, length 64
01:22:06.278039 ethertype IPv6, IP6 2001:4860:4860:: >
2804:::::9ca: ICMP6, echo reply, seq 1324, length 64
01:22:06.278039 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 1324, length 64
01:22:06.278171 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 1324, length 64
01:22:06.278191 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 1324, length 64


Listening to "eth0", I got IPv4 and IPv6, but only incoming.

# tcpdump -i eth0 icmp or icmp6 -n
01:05:34.013966 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 222, length 64
01:05:34.014860 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 333, length 64

Again, if I change the filter to something like 'vlan 2', I can see both:

# tcpdump -i eth0 vlan 2 -n
...
01:06:56.107341 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 304, length 64
...
01:06:56.127299 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 304, length 64
...
01:06:57.067497 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 416, length 64
...
01:06:57.096174 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 416, length 64

If I capture the external vlan interface or br-lan, all works as expected:

# tcpdump -i eth0.2 icmp or icmp6 -n
01:08:38.213303 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 517, length 64
01:08:38.233701 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 517, length 64
01:08:38.256486 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 406, length 64
01:08:38.278949 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 406, length 64

# tcpdump -i br-lan icmp or icmp6 -n
01:10:40.406118 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 639, length 64
01:10:40.429046 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 639, length 64
01:10:40.432067 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 528, length 64
01:10:40.453203 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 528, length 64

The only reliable way to filter is to not use them and let the reader
(wireshark) do it afterwards. But that workaround is not
an option while capturing through the same interface you need to
capture traffic on.

Is this really expected? Maybe a weird mips bug? Or a bad side effect
from some openwrt size optimization?

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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

Usability issues for DSA upgrade

[Luiz Angelo Daros de Luca]

Hello,

While upgrading from 19.07 to 21.02, there is an scary error message
when target migrates to DSA (both Luci or CLI):

root@OpenWrt:/tmp# sysupgrade -n
openwrt-21.02.0-rc3-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin
Device linksys,shelby not supported by this image
Supported devices: linksys,wrt1900acs armada-385-linksys-shelby
linksys,shelby - Image version mismatch: image 1.1, device 1.0. Please
wipe config during upgrade (force required) or reinstall. Reason:
Config cannot be migrated from swconfig to DSA
Image check failed.

OpenWrt devs are probably confident that they can force an upgrade for
that image. "force" means "I know what I'm doing, ignore the checks".
However, for many users, sometimes non-technical ones, they do not
really know what they are doing. There might be a wave of support
requests about that message and another wave of bricked devices. Even
knowing some OpenWrt internals, I'm not sure what "...or reinstall"
means. Shouldn't '-n' be enough? Isn't sysupgrade already a reinstall?
Or should it be the factory image? If it is really suggesting factory
images, should I return to the original firmware before or use some
emergency firmware recovery?

Can we provide a 19.07 update to, at least, allow the upgrade without
errors or "force" if confs are not kept? "Force" comes with great
responsibility and it will overwrite other checks as board
compatibility.

The error message could be, instead of:

"Please wipe config during upgrade (force required) or reinstall.
Reason: Config cannot be migrated from swconfig to DSA"

Something like this:

"Configuration cannot be migrated from swconfig to DSA. To properly
validate this firmware, please update OpenWrt at least to version
19.07.8 or pkgfoobar to version 1.2.3 and retry. Alternatively, if you
are sure that this image is compatible, you can proceed not retaining
the current configuration and forcing the process."

I omitted the "...or reinstall'' as I'm still not sure what it means.
I also used "not retaining the current configuration" as Luci (nor
sysupgrade) does not mention wipe but "Keep settings and retain the
current configuration" (which, by the way, seems to be two redundant
sentences).

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

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