[OpenWrt-Devel] WMAC LED Problems
The problem of wmac based leds on WZR-HP-AG300H stimulated some research on status of led support on other buffalo units with wmac based leds. The following results and observations are based on the trunk revision r32910. COMMON - Wmac based leds do not appear in the /sys/class/leds directory until the corresponding phy is recognized and initialized, which happens during regular init. This suggest that we can not use wmac based leds to indicate the boot/init progress. WZR-HP-G300NH2 - Current /etc/diag.sh uses buffalo:red:diag for indicating boot/init progress. This led is connected to the platform's gpio, so it works. However, the problem is that it REMAINS LIT when the boot/init completes. VERY mis-leading. - Wmac leds works fine WITHOUT phy initialization (by means of wifi command execution). WZR-HP-G450H - Current /etc/diag.sh does not support boot/init progress indication. - Wmac leds works fine WITHOUT phy initialization (by means of wifi command execution). WZR-HP-AG300H - Current /etc/diag.sh does not support boot/init progress indication. - Wmac leds REQUIRES phy initialization (by means of wifi command execution) to start working. After the first phy initialization, they continue to work fine. OBSERVATION - If we can initiate the phy recognition before preinit, it would solve the entire problem, but I suspect this is extremely hard. - Using the buffalo:red:diag in the /etc/diag.sh seems to be the only solution, but it must be turned off when done. - The dependency on phy initialization on AG300H must be investigated. As WZR-HP-G300NH2 and WZR-HP-AG300H uses the same phy driver, there must be some discrepancy between AR9220/AR9223 and AR9280. - I wonder if other non-buffalo units with wmac leds are dealing with the problem. Comments are welcome. --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Problem with sysupgrade
Hello folks, i'm currently develop a custom version of openwrt for openwisp.org project. So i have to install it remotely to a large number of access points distributed in the province of Rome. (i cannot reach the ap's easily) So when i perform a sysupgrade with our firmware i put in it a recovery tarball that contains some files included the old network configuration. The command sysupgrade -v -f old_sys.tgz new_firmware.img goes fine it replace correctly all the needed files except the /etc/config/network. In this case the one in the new firmware is preserved but we need to replace that one with the settings in the tgz package. I wish i'm explain the problem correctly. Any suggestions? Thank you. (please put me in cc) Andrea. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Linux 3.3.x has been EOLed ; time to move on ?
Hello, I understand that a lot of effort has been pushed in making Linux 3.3 the trunk kernel, and I understand that I probably missed long (IRC?) discussions on this very subject, but since 3.3.8 is going to be the last supported kernel in the 3.3.x branch it might be a good idea to move on to another, more recent kernel version - and to do it slightly better. Not that anything is really bad, but there were obviously better choices that 3.3 at the time it came up. First and foremost, 3.3 has never been a -longterm. In fact, 3.(2n+1) are doomed to be supported only for a short period of time, given that: * they are not supported by any -rt patch * and thus, will probably not promoted to -longterm. The only existing, official -longterm at this point is 3.0, as stated on GKH blog [1]. The very first argument against 3.3 would have been that given that 3.0 was already known to be a -longterm at this point, it should have been selected. 3.0-rt are also going to be maintained as -longterm by Steven Rostedt. Ben Hutchings proposed to maintain a -longterm of Linux 3.2 when GKH dropped its support ; Steven immediately stated that 3.2-rt are going to stay for a long time as well. 3.2 is going to be used by Debian and Ubuntu for (quite possibly) a long time, so we can be sure that this version is indeed a longterm although it's a kind-of community-maintained one. I know that these lines do not add much to the debate. I get that. The thing is, OpenWRT is supposed to be used in, well, wireless routers - possibly commercial ones. Commercial consumer products need to have at least two things : * they need to be able to pick a recent kernel when they start the development of their product. There is no real point today to select a 4 years old kernel because it's known to work. Given the development model of Linux, kernel breakage are less and less frequent (they still happen, but then the regressions are spotted quite fast). * the need to pick a kernel that they know will be supported for some time. This decrease the workload on the kernel crew in this company, and increase their productivity. A third point should not be left aside: * sometimes, having a realtime kernel is necessary. Some VoIP apps mandate this (there is a reason why RTP is called RTP). These should be the points to consider when its time to select a new kernel version to work on. It may mean that the OpenWRT tree needs to store two different kernel (a known longterm - maybe - the current kernel version). There are also important things to factor in. * the -rt maintainers pledged to maintaina -rt patch for every 3.(2n) releases (and possibly for every 4.(2n) releases after that). That means that 3.(2n+1) have virtually no chance to become a -longterm since distributions are more and more interested in proposing both the -rt and the !-rt kernel to their users (see Debian, for example). * One -longterm will be selected every year and will be maintained by GKH. Given the development pace, it will probably happen around 3.6 since 3.0 has been elected last year. The selection of 3.2 by Ben Hutchings is not related to the selection of another longterm by GKH. Anyway, whatever your (OWRT maintainers) choices are, we're going to accept and support them. But it might be good to at least publish some kind of rationale document when a new kernel is pushed in the tree. Hoping I have not been too disruptive, best regard, -- Emmanuel Deloget [1] http://www.kroah.com/log/linux/stable-status-01-2012.html [2] http://thread.gmane.org/gmane.linux.kernel/1284809/focus%3D1285786 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with sysupgrade
How about adding the -n flag? --- shinoda On 2012/08/01, at 16:43, Andrea Ferraresi wrote: Hello folks, i'm currently develop a custom version of openwrt for openwisp.org project. So i have to install it remotely to a large number of access points distributed in the province of Rome. (i cannot reach the ap's easily) So when i perform a sysupgrade with our firmware i put in it a recovery tarball that contains some files included the old network configuration. The command sysupgrade -v -f old_sys.tgz new_firmware.img goes fine it replace correctly all the needed files except the /etc/config/network. In this case the one in the new firmware is preserved but we need to replace that one with the settings in the tgz package. I wish i'm explain the problem correctly. Any suggestions? Thank you. (please put me in cc) Andrea. ___ 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] Fwd: [PATCH] Add SSH VPN support to sshtunnel package
Signed-off-by: Henning Botha hjbotha at gmail.com
Index: net/sshtunnel/files/sshtunnel.init
===
--- net/sshtunnel/files/sshtunnel.init (revision 32927)
+++ net/sshtunnel/files/sshtunnel.init (working copy)
@@ -73,6 +73,24 @@
append_string ARGS_tunnels -D $localaddress:$localport
}
+load_tunnelW() {
+config_get section_server $1 server
+[ $server = $section_server ] || return 0 # continue to read
next section if this is not for the current server
+let count++ # count nr of valid sections to make sure there are at
least one
+
+config_get localdev $1 localdev *
+config_get remotedev$1 remotedev *
+config_get vpntype $1 vpntype *
+
+[ $vpntype == ethernet ] || [ $vpntype == point-to-point ]
|| append_string error [tunnelW: $1] vpntype must be \ethernet\ (tap)
or \pointopoint\ (tun) ;
+[ $localdev == any ] || [ $localdev -ge 0 ] || append_string
error [tunnelW: $1] localdev must be an integer or \any\ ;
+[ $remotedev == any ] || [ $remotedev -ge 0 ] ||
append_string error [tunnelW: $1] remotedev must be an integer or
\any\ ;
+[ $user == root ] || logger -p user.warn -t sshtunnel
warning: root is required unless the tunnel device has been created
manually
+[ -n $error ] return 1
+
+append_string ARGS_tunnels -w $localdev:$remotedev -o
Tunnel=$vpntype
+}
+
load_server() {
server=$1
Index: net/sshtunnel/files/uci_sshtunnel
===
--- net/sshtunnel/files/uci_sshtunnel (revision 32927)
+++ net/sshtunnel/files/uci_sshtunnel (working copy)
@@ -49,3 +49,15 @@
# option server disney
# option localaddress *
# option localport 4055
+
+# tunnelW - creates TUN/TAP devices on client and server to establish a
VPN tunnel between them
+# vpntypes:
+# point-to-point = TUN
+# ethernet = TAP
+#
+#config tunnelW proxy
+# option server disney
+# option vpntype point-to-point|ethernet
+# option localdev any|0|1|2|...
+# option remotedev any|0|1|2|...
+
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WMAC LED Problems
On 07/31/2012 11:45 PM, LEO Airwarosu Yoichi Shinoda wrote: The problem of wmac based leds on WZR-HP-AG300H stimulated some research on status of led support on other buffalo units with wmac based leds. The following results and observations are based on the trunk revision r32910. COMMON - Wmac based leds do not appear in the /sys/class/leds directory until the corresponding phy is recognized and initialized, which happens during regular init. This suggest that we can not use wmac based leds to indicate the boot/init progress. WZR-HP-G300NH2 - Current /etc/diag.sh uses buffalo:red:diag for indicating boot/init progress. This led is connected to the platform's gpio, so it works. However, the problem is that it REMAINS LIT when the boot/init completes. VERY mis-leading. The problem here is that the LED handling is done in the wrong order. I submitted a fix/patch(?) for this months ago, but it seems to have been ignored or lost. I can dig it out again - the fix is pretty simple. But yes, the requirement to enable WLAN first is a bit annoying. In many of our deployments, we don't even use that - we use G300NH, G300NH2 and AG300H. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with sysupgrade
On 01/08/12 03:43 AM, Andrea Ferraresi wrote: Hello folks, i'm currently develop a custom version of openwrt for openwisp.org project. So i have to install it remotely to a large number of access points distributed in the province of Rome. (i cannot reach the ap's easily) So when i perform a sysupgrade with our firmware i put in it a recovery tarball that contains some files included the old network configuration. I wrote about 100-150 lines of bash that rsyncs $TOPDIR/files/ with local copies for each router in my network. After the initial compile I can rebuild images for 120 (and counting) routers in 30 minutes accross 3 targets. then I just script mtd to flash them. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Linux 3.3.x has been EOLed ; time to move on ?
On 01/08/12 04:57 AM, Emmanuel Deloget wrote: Hello, I understand that a lot of effort has been pushed in making Linux 3.3 the trunk kernel, and I understand that I probably missed long (IRC?) discussions on this very subject, but since 3.3.8 is going to be the last supported kernel in the 3.3.x branch it might be a good idea to move on to another, more recent kernel version - and to do it slightly better. Not that anything is really bad, but there were obviously better choices that 3.3 at the time it came up. 3.3 was probably chosen based on wifi driver quality at the time. I think we started with 3.3.2 or .3 so it was pretty new at the time. Because of that we (most probably) can't drop down to 3.0. Trying to sync with a -rt kernel does seem like a good idea, -longterm seems unnecessary. For the record my production networks runs trunk (something around 31xxx, I forget right now). It's a VPN mesh consisting of over 100 nodes and minutes of downtime is measured in thousands of dollars. Ignoring the whole REAL MEN USE TRUNK(tm) the tagged releases are just too old to do anything fun with. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] eglibc build fix for re
With eglibc needs to define -D_GNU_SOURCE in cflags to avoid following error: CC build-mips/sa/pton.o src/sa/pton.c: In function 'net_inet_pton': src/sa/pton.c:233:7: error: 'const struct in6_addr' has no member named 's6_addr32' src/sa/pton.c:233:7: error: 'const struct in6_addr' has no member named 's6_addr32' src/sa/pton.c:233:7: error: 'const struct in6_addr' has no member named 's6_addr32' Signed-off-by: Mika Laitio mika.lai...@nokia.com --- libs/re/Makefile |4 1 file changed, 4 insertions(+) diff --git a/libs/re/Makefile b/libs/re/Makefile index c3cc27b..fbafd47 100644 --- a/libs/re/Makefile +++ b/libs/re/Makefile @@ -28,6 +28,10 @@ endef TARGET_CFLAGS += $(FPIC) +ifneq ($(CONFIG_USE_EGLIBC),) +TARGET_CFLAGS += -D_GNU_SOURCE +endif + define Build/Compile $(MAKE) -C $(PKG_BUILD_DIR) \ HAVE_LIBRESOLV= \ -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] knock eglibc build fix
Fix knock build with the openwrt eglibc toolchain by including the limits.h from knockd.c. This will fix the error caused by undefined PATH_MAX variable. Signed-off-by: Mika Laitio mika.lai...@nokia.com --- net/knock/patches/010_eglibc_define_PATH_MAX.patch | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 net/knock/patches/010_eglibc_define_PATH_MAX.patch diff --git a/net/knock/patches/010_eglibc_define_PATH_MAX.patch b/net/knock/patches/010_eglibc_define_PATH_MAX.patch new file mode 100644 index 000..98d66ff --- /dev/null +++ b/net/knock/patches/010_eglibc_define_PATH_MAX.patch @@ -0,0 +1,11 @@ +diff -Naur knock-0.5/src/knockd.c knock-0.5-new/src/knockd.c +--- knock-0.5/src/knockd.c 2005-06-27 08:11:34.0 +0300 knock-0.5-new/src/knockd.c 2012-07-31 22:49:13.670323836 +0300 +@@ -46,6 +46,7 @@ + #include syslog.h + #include pcap.h + #include errno.h ++#include limits.h /* PATH_MAX in eglibc env */ + #include list.h + + static char version[] = 0.5; -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] snort eglibc build fix
Fix the snort build with openwrt eglibc toolchain by adding build depends to librpc if the toolchain uses eglibc. Without this the build is failing to missing rpc/rpc.h headers because the eglibc 2.15 does not anymore ship the rpc libraries in itself. Instead eglibc users are expected to use separate librpc library. (for example libtirpc) Signed-off-by: Mika Laitio mika.lai...@nokia.com --- net/snort/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/snort/Makefile b/net/snort/Makefile index d3eaeaf..4c17420 100644 --- a/net/snort/Makefile +++ b/net/snort/Makefile @@ -15,7 +15,7 @@ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://dl.snort.org/snort-current/ PKG_MD5SUM:=63f4e76ae96a2d133f4c7b741bad5458 -PKG_BUILD_DEPENDS:=USE_UCLIBC:librpc +PKG_BUILD_DEPENDS:=USE_UCLIBC:librpc USE_EGLIBC:librpc PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION) PKG_FIXUP:=autoreconf PKG_INSTALL:=1 -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/3] more build fixes to packages with eglibc
Here is another set of build fixes to packages when openwrt uses eglibc instead of uclibc. I have tested the patches by doing builds both with the openwrt/uclibc toolchain and openwrt/eglibc toolchain. Mika Laitio (3): eglibc build fix for re knock eglibc build fix snort eglibc build fix libs/re/Makefile |4 net/knock/patches/010_eglibc_define_PATH_MAX.patch | 11 +++ net/snort/Makefile |2 +- 3 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 net/knock/patches/010_eglibc_define_PATH_MAX.patch -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Linux 3.3.x has been EOLed ; time to move on ?
Hi, my impression is, that a kernel version makes it into trunk if it is either a long term kernel, or it brings essential new functions. For 3.3 this was most certainly the introduction of BQL code. Keeping in mind that our main targets are network routers, the bufferbloat issue probably concerns most of the maintainers. Emmanuel Deloget schrieb: Hello, I understand that a lot of effort has been pushed in making Linux 3.3 the trunk kernel, and I understand that I probably missed long (IRC?) discussions on this very subject, but since 3.3.8 is going to be the last supported kernel in the 3.3.x branch it might be a good idea to move on to another, more recent kernel version - and to do it slightly better. Not that anything is really bad, but there were obviously better choices that 3.3 at the time it came up. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WMAC LED Problems
On 2012/08/01, at 22:39, Peter Naulls wrote: The problem here is that the LED handling is done in the wrong order. I submitted a fix/patch(?) for this months ago, but it seems to have been ignored or lost. I can dig it out again - the fix is pretty simple. I would definitely would like to take a look at it. --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
