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
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
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
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
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 @@
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
-
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
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
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
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
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
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
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
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
14 matches
Mail list logo
