[OpenWrt-Devel] Help with SysupgradeNAND
Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... Thanks, Ben ___ 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] Help with SysupgradeNAND
Hi! I also noticed after upgrading that routers with jffs2 in ubi (rootfs_data) are not supported anymore. The jffs2 is not mounted after an upgrade, resulting in loss of configuration. I had to clear rootfs_data to be able to mount it again as ubifs. That's okay if you know it! I noticed a second issue. hostapd (running in some kind of dfs loop) was not killed by sysupgrade nand. That resulted in breaking the upgrade. System rebooted with old image. I personnaly added a check in sysupgrade if it runs below upgraded and if that's true, I kill _all_ processes. If interested I could publish the patch. A third point is the upgrade itself. I the rootfs image grows, and rootfs_data has all the remaining space aligned, it will not work because rootfs cannot grow. Perhaps rootfs_data should always be recreated in the update process. If interested I could also supply a patch. Kind regards, André On 09.07.2014 09:02, John Crispin wrote: On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... Thanks, Ben ___ 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 -- Mit freundlichen Grüßen, André Valentin Projektkoordination / Systemadministration MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld Fon: +49 (521) 95945-0 | Fax -18 URL: http://www.marcant.net | http://www.global-m2m.com Geschäftsführer: Thorsten Hojas Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238 ___ CONFIDENTIALITY NOTICE The contents of this email are confidential to the ordinary user of the email address to which it was addressed and may also be privileged. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this email in error please email the sender by replying to this message. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On 09/07/2014 09:14, Andre Valentin wrote: Hi! I also noticed after upgrading that routers with jffs2 in ubi (rootfs_data) are not supported anymore. The jffs2 is not mounted after an upgrade, resulting in loss of configuration. I had to clear rootfs_data to be able to mount it again as ubifs. That's okay if you know it! i think using squash+ubifs is a better option as we dont need to use the gluebi layer anymore. this makes the whole setup a lot nice i think. that is why jffs2 support for nand is gone. however i am open to hear use cases for why jffs2 support should be added for nand. I noticed a second issue. hostapd (running in some kind of dfs loop) was not killed by sysupgrade nand. That resulted in breaking the upgrade. System rebooted with old image. I personnaly added a check in sysupgrade if it runs below upgraded and if that's true, I kill _all_ processes. If interested I could publish the patch. please send a patch A third point is the upgrade itself. I the rootfs image grows, and rootfs_data has all the remaining space aligned, it will not work because rootfs cannot grow. Perhaps rootfs_data should always be recreated in the update process. If interested I could also supply a patch. please send a patch John Kind regards, André On 09.07.2014 09:02, John Crispin wrote: On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... Thanks, Ben ___ 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] Help with SysupgradeNAND
On Wed, 2014-07-09 at 09:02 +0200, John Crispin wrote: On 09/07/2014 08:42, Ben Mulvihill wrote: Hello Daniel, I have got SysupgradeNAND working on the BTHOMEHUBV2B with an all-ubifs rootfs, with a patch which I'll submit in another email, once I've recompiled with the latest trunk and made sure that everything is working, but in the meantime I have a question: am I right in thinking that the only type of overlay supported is squashfs + ubifs, not squashfs + jffs2 ? ubifs is jffs3 essentially, a jffs2 with nand awareness added ... correct me if i am wrong ... At the moment, SysupgradeNAND recreates rootfs_data as ubifs, then after reboot, the system tries to mount it as jffs2 and generates errors. But as you said in your reply to André, there is no particular benefit to using jffs2 instead of ubifs for rootfs_data. jffs2 just happens to be what is used currently. I'll have a look at moving over to squashfs + ubifs. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On 09.07.2014 09:48, John Crispin wrote: i think using squash+ubifs is a better option as we dont need to use the gluebi layer anymore. this makes the whole setup a lot nice i think. that is why jffs2 support for nand is gone. however i am open to hear use cases for why jffs2 support should be added for nand. No, not from me. I want it simple and not another layer. I think this is the best solution. I will send the proposed patches for sysupgrade today, perhaps the rootfs_data part later. Kind regards, André ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uhttpd: Cert error sec_error_reused_issuer_and_serial
Hello hackers, so, we've been bumping lately into what seems to be a pretty well known bug, that noone cared enough to fix yet? the symptom of the issue is that after flashing several same-model routers with the same openwrt binary, then accessing them over https, and accepting the self-signed certificate, after a few iterations on different hosts, firefox refuses to connect due to a reused issuer and serial number on the certificate sent by the server (openwrt) the root of the issue is that openwrt generates certificates with px5g, which as far as i dug into, bases the generated serialNumber upon the epoch (with up-to-the-second-precision) same hardware, same binary, and with the same startup date at first boot... the chances of two different routers running the /etc/init.d/uhttpd start at the exact same second are pretty high (in our experience - at least 3 in a lot of 10) routers get the correct date afterwards, with ntpdate, but then it's too late: px5g already generated the certificate with identical serialNumber as the other routers. this is aggravated by a (particularly long standing) bug in firefox https://bugzilla.mozilla.org/show_bug.cgi?id=435013 which makes it impossible to remove such information (already seen issuer+serial) from the browser PKI internal database. chromium overreacts in a comparable way. the poor linksys customers complaining in mozilla's ticket are probably doomed, after 6 years seeing the issue Assigned To: Nobody; OK to take it and work on it :P but maybe we can do our part on openwrt? PX5G X.509 Certificate Generator Utility v0.1 Copyright (c) 2009 Steven Barth ste...@midlink.org Steven, do you think it would possible to add a bit of randomness to the serialNumber generation function? i understand entropy is scarce in embedded devices, especially on first boot, and my C coding skills are null, so i'm hoping someone can throw a pointer here? relevant snippet AFAIU: from feeds/luci/libs/px5g/src/library/x509write.c /* * CertificateSerialNumber ::= INTEGER */ srand((unsigned int) time(NULL)); serial = rand(); if ((ret = asn1_add_int(serial, chain-serial)) != 0) return ret; cheers! gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] sysupgrade: Enable killing of all processes under upgraded
If the sysupgrade scripts is called under upgraded, it will not kill all
other processes as it should to avoid interference by locked filesystem.
This patch checks the parent and if it is upgraded, it kills all.
Signed-off-by: André Valentin avalen...@marcant.net
---
package/base-files/files/lib/upgrade/common.sh | 39
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index 6f1880f..ba9de99 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -99,6 +99,13 @@ kill_remaining() { # [ signal ]
local sig=${1:-TERM}
echo -n Sending $sig to remaining processes ...
+ local my_pid=$$
+ local my_ppid=$(cut -d' ' -f4 /proc/$my_pid/stat)
+ local my_ppisupgraded=
+ grep -q upgraded /proc/$my_ppid/cmdline /dev/null {
+ local my_ppisupgraded=1
+ }
+
local stat
for stat in /proc/[0-9]*/stat; do
[ -f $stat ] || continue
@@ -113,18 +120,26 @@ kill_remaining() { # [ signal ]
# Skip kernel threads
[ -n $cmdline ] || continue
- case $name in
- # Skip essential services
-
*procd*|*upgraded*|*ash*|*init*|*watchdog*|*ssh*|*dropbear*|*telnet*|*login*|*hostapd*|*wpa_supplicant*|*nas*)
: ;;
-
- # Killable process
- *)
- if [ $pid -ne $$ ] [ $ppid -ne $$ ]; then
- echo -n $name
- kill -$sig $pid 2/dev/null
- fi
- ;;
- esac
+ if [ $$ -eq 1 ] || [ $my_ppid -eq 1 ] [ -n
$my_ppisupgraded ]; then
+ # Running as init process, kill everything except me
+ if [ $pid -ne $$ ] [ $pid -ne $my_ppid ]; then
+ echo -n $name
+ kill -$sig $pid 2/dev/null
+ fi
+ else
+ case $name in
+ # Skip essential services
+
*procd*|*ash*|*init*|*watchdog*|*ssh*|*dropbear*|*telnet*|*login*|*hostapd*|*wpa_supplicant*|*nas*)
: ;;
+
+ # Killable process
+ *)
+ if [ $pid -ne $$ ] [ $ppid -ne $$ ];
then
+ echo -n $name
+ kill -$sig $pid 2/dev/null
+ fi
+ ;;
+ esac
+ fi
done
echo
}
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Help with SysupgradeNAND
On Wed, Jul 9, 2014 at 12:48 AM, John Crispin j...@phrozen.org wrote: On 09/07/2014 09:14, Andre Valentin wrote: Hi! I also noticed after upgrading that routers with jffs2 in ubi (rootfs_data) are not supported anymore. The jffs2 is not mounted after an upgrade, resulting in loss of configuration. I had to clear rootfs_data to be able to mount it again as ubifs. That's okay if you know it! i think using squash+ubifs is a better option as we dont need to use the gluebi layer anymore. this makes the whole setup a lot nice i think. that is why jffs2 support for nand is gone. however i am open to hear use cases for why jffs2 support should be added for nand. One of the reasons why I didn't even consider jffs2 for IMX6 is that the IMX6 NAND controller with hardware ECC support uses the entire OOB area which was needed by jffs2. Their might be support in jffs2 now for not using OOB data but ubi/ubifs does seem to be the popular choice these days for NAND based filesystems. Tim ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenSSL/StrongSwan: AA binary feed update
libopenssl/strongswan - AA binary feed update
libopenssl was updated from 1.0.1g to 1.0.1h.
strongswan was updated from 5.0.0 to 5.1.3.
We updated the AA binary release. The Packages index was also updated.
If you use openssl or strongswan on your unit you need to run :
# opkg update
# opkg upgrade libopenssl/strongswan-{full,...}
In order to ensure that all affected services are using the updated
OpenSSL library it is recommended to reboot the device after applying
the upgrade.
OpenWrt Developers
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc menuconfig
Ok, just ignore the question. I already noticed that libthread_db is only available at trunk. On 8 July 2014 17:50, Carlos Ferreira carlosmf...@gmail.com wrote: Hello all! Can anyone tell me how can I enable the pthread debug mode in uClibc? I followed the instructions as explained here https://forum.openwrt.org/viewtopic.php?id=25741 with no luck in obtaining the libthread_db.so. In here http://cursos.leon.uia.mx/temporal/software/openwrt/openwrt/docs/buildroot-documentation.html#custom_uclibc, the explanation for accessing the menuconfig for uClibc does not work in trunk. Does anyone knows if the uclibc menuconfig still exists in current trunk? -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt Skype GTalk - carlosmf...@gmail.com LinkedIn - http://www.linkedin.com/in/carlosmferreira -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt Skype GTalk - carlosmf...@gmail.com LinkedIn - http://www.linkedin.com/in/carlosmferreira ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uhttpd: Cert error sec_error_reused_issuer_and_serial
Hey Gui, I think we can extract a few bits of entropy by using the MAC addresses, should be easy to obtain them through getifaddrs(). ~ Jow signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel module development workflow
On 8 July 2014 21:24, Tomas Daujotas socc...@gmail.com wrote: I was looking for a good reference for OpenWRT kernel module development workflow. See attached file with commands. This allow you writing some external module as an OpenWrt package. helloworld/Makefile will have probably white spaces broken, you may fix them by hand cd package/kernel mkdir -p helloworld/src echo obj-m += helloworld.o helloworld/src/Makefile touch helloworld/src/helloworld.c cat 'EOF' helloworld/Makefile include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=helloworld PKG_RELEASE:=1 include $(INCLUDE_DIR)/package.mk define KernelPackage/helloworld SECTION:=kernel CATEGORY:=Kernel modules TITLE:=Hello world kernel module FILES:= \ $(PKG_BUILD_DIR)/helloworld.ko AUTOLOAD:=$(call AutoLoad,30,helloworld) endef define Build/Prepare # Copy sources mkdir -p $(PKG_BUILD_DIR) cp -R ./src/* $(PKG_BUILD_DIR)/ endef define Build/Compile $(MAKE) -C $(LINUX_DIR) \ CROSS_COMPILE=$(TARGET_CROSS) \ ARCH=$(LINUX_KARCH) \ SUBDIRS=$(PKG_BUILD_DIR) \ modules endef $(eval $(call KernelPackage,helloworld)) EOF ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Status of DFS in OpenWrt - ath9k
Hi, for me it seems that DFS is broken in current trunk for ath9k. I use trunk and compiled ar71xx. With the following configuration on a Ubiquity Nanostation locoM5 - config wifi-device 'radio0' option type 'mac80211' option hwmode '11na' option path 'pci:00/:00:00.0' option htmode 'HT20' option country 'DE' option channel '104' option txpower '20' config wifi-iface option device 'radio0' option encryption 'none' option network 'wifi' option mode 'ap' option ssid 'OpenWRT' option ifname 'wlan0' - All DFS channel attempts fail with start_dfs_cac() failed, -1 Full log is as follows: - Sat Jul 5 21:19:56 2014 daemon.notice netifd: Interface 'wifi' is enabled Sat Jul 5 21:19:56 2014 kern.info kernel: [ 337.93] IPv6: ADDRCONF(NETDEV_UP): br-wifi: link is not ready Sat Jul 5 21:19:58 2014 kern.info kernel: [ 339.14] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Sat Jul 5 21:19:58 2014 kern.info kernel: [ 339.15] device wlan0 entered promiscuous mode Sat Jul 5 21:19:58 2014 kern.info kernel: [ 339.16] device wlan0 left promiscuous mode Sat Jul 5 21:19:58 2014 kern.info kernel: [ 339.16] br-wifi: port 1(wlan0) entered disabled state Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): Configuration file: /var/run/hostapd-phy0.conf Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): wlan0: interface state UNINITIALIZED-COUNTRY_UPDATE Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): wlan0: interface state COUNTRY_UPDATE-DFS Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): wlan0: DFS-CAC-START freq=5520 chan=104 sec_chan=0, width=0, seg0=0, seg1=0, cac_time=60s Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): DFS start_dfs_cac() failed, -1 Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): Interface initialization failed Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): wlan0: interface state DFS-DISABLED Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): wlan0: AP-DISABLED Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): wlan0: Unable to setup interface. Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): hostapd_free_hapd_data: Interface wlan0 wasn't started Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): ELOOP: remaining socket: sock=18 eloop_data=0xab9020 user_data=(nil) handler=0x4136d5 Sat Jul 5 21:19:58 2014 daemon.notice netifd: radio0 (4156): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory I know that I already used DFS channels in March but I am not sure whether it was with plain trunk or additional own patches. Regards, Martin On 7/8/14, 12:20 AM, Andre Valentin wrote: Hi! this should also be in your .config # CONFIG_ATH_USER_REGD is not set See http://wireless.kernel.org/en/users/Drivers/ath10k - Limitations 3/3 Kind regards, André On 04.07.2014 16:29, Jacek Kikiewicz wrote: Hello, I have CONFIG_PACKAGE_ATH_DFS=y and still cannot use this... any idea how / what should be debugged? .. CONFIG_PACKAGE_ATH_DFS=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] procd: correctly identify ubifs in tar file
A missing path prevents the rootfs type contained in a SysupgradeNAND
tar file from being determined correctly.
This fixes it, and also corrects a minor spelling mistake.
Signed-off-by: Ben Mulvihill ben.mulvih...@gmail.com
---
--- a/package/system/procd/files/nand.sh2014-07-09 08:11:04.563205951
+0200
+++ b/package/system/procd/files/nand.sh2014-07-09 08:11:49.548253354
+0200
@@ -180,7 +180,7 @@ nand_do_upgrade_success() {
sync
[ -f $conf_tar ] nand_restore_config $conf_tar
- echo sysupgrade successfull
+ echo sysupgrade successful
reboot -f
}
@@ -226,7 +226,7 @@ nand_upgrade_tar() {
local kernel_length=`(tar xf $tar_file sysupgrade-$board_name/kernel -O
| wc -c) 2 /dev/null`
local rootfs_length=`(tar xf $tar_file sysupgrade-$board_name/root -O |
wc -c) 2 /dev/null`
- local rootfs_type=$(identify_tar $tar_file root)
+ local rootfs_type=$(identify_tar $tar_file
sysupgrade-$board_name/root)
local has_kernel=1
local has_env=0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
