[LEDE-DEV] Can the OpenWRT Wiki be included in the reboot?

[Martin Tippmann]

Hi,

I'm not affiliated with OpenWRT nor LEDE (just a member of a small
Freifunk group) but the Wiki was (and still is) always my first choice
when looking for documentation.
Is there a plan to provide a LEDE wiki? The licence is CC
Attribution-Noncommercial-Share Alike 3.0[1] so it should be fine to
take the data.

It's maybe not a top priority at the moment but from a user
perspective it's something I don't want to miss.

I could provide hosting on a university machine for the near future
but I think it's hosted at subsignal at the moment so there is
probably no reason to switch.

So - is the Wiki on the roadmap? Are there plans?

Grüße aus Weimar,
Martin


1: https://creativecommons.org/licenses/by-nc-sa/3.0/

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

Re: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[Yousong Zhou]

On 25 May 2016 at 07:52,   wrote:
> Hi,
>
>> How about
>>
>> option ssid Lede-$(cat /sys/class/ieee80211/${dev}/macaddress | awk -F
>> ":" '{print $4""$5""$6 }'| tr a-z A-Z)
>
> Or with sed:
>
> sed -ne 'y/abcdef/ABCDEF/; 1s/^.*:\(..\):\(..\):\(..\)$/\1\2\3/p' \
> /sys/class/ieee80211/${dev}/macaddress
>

Or with awk:

awk -F: '{ print toupper($4$5$6) }' /sys/class/ieee80211/phy0/macaddress

yousong

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

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

Re: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[jo]

Hi,

> How about
> 
> option ssid Lede-$(cat /sys/class/ieee80211/${dev}/macaddress | awk -F
> ":" '{print $4""$5""$6 }'| tr a-z A-Z)

Or with sed:

sed -ne 'y/abcdef/ABCDEF/; 1s/^.*:\(..\):\(..\):\(..\)$/\1\2\3/p' \
/sys/class/ieee80211/${dev}/macaddress

~ Jo

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

Re: [LEDE-DEV] 1043ND v2.1 LEDE trunk kernel panic

[John Crispin]

On 24/05/2016 07:48, John Crispin wrote:
> 
> 
> On 24/05/2016 07:33, Yousong Zhou wrote:
>> On 24 May 2016 at 12:35, John Crispin  wrote:
>>>
>>>
>>> On 24/05/2016 02:00, A. Benz wrote:
 Hi

 Trunk build of LEDE gets a kernel panic on TPLink 1043ND v2.1

 See log:
 http://paste.debian.net/698070/

>>>
>>> looks like there is no rootfs flashed. whih image did you use ?
>>>
>>> John
>>
>> Just in case it may help, last time we saw that "Attempted to kill
>> init, exitcode=0x4" was in malta-on-qemu [1].  The exitcode 4 there
>> was caused by SIGILL but that one also had a stack trace.
>>
>> [1] https://dev.openwrt.org/ticket/16881
>>
>> yousong
>>
> 
> 
> i have a 1043 v2.1 here, let me try and build an image for it just now
> 
>   John
> 

ar71xx seems to boot fine with todays HEAD revision but i tried it on a
slightly different SoC. i'll try to track down a QCA9558 for testing.

did you test this with the default config ?

John

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

[LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[Rafał Miłecki]

LEDE project seems to be using "LEDE" as its acronym everywhere. To keep
things consistent adjust default wireless SSID.

Signed-off-by: Rafał Miłecki 
---
 package/kernel/mac80211/files/lib/wifi/mac80211.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh 
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index 77247cb..9b15de5 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -123,7 +123,7 @@ config wifi-iface
option device   radio$devidx
option network  lan
option mode ap
-   option ssid Lede
+   option ssid LEDE
option encryption none
 
 EOF
-- 
1.8.4.5


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

[LEDE-DEV] [PATCH] procd: Update to latest head

[Alexey Brodkin]

This includes a fix for building against uClibc:
http://git.openwrt.org/?p=project/procd.git;a=commit;h=9a6f83d3c168523ac7b898ae481c2fd8c501d6a6

Signed-off-by: Alexey Brodkin 
Cc: John Crispin 
---
 package/system/procd/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile
index 7ba2be3..cb7ab05 100644
--- a/package/system/procd/Makefile
+++ b/package/system/procd/Makefile
@@ -8,14 +8,14 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=procd
-PKG_VERSION:=2016-05-19
+PKG_VERSION:=2016-05-24
 
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=$(OPENWRT_GIT)/project/procd.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=1418c6ce8559ea125c525c2663105fa5ff14905e
+PKG_SOURCE_VERSION:=9a6f83d3c168523ac7b898ae481c2fd8c501d6a6
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
 CMAKE_INSTALL:=1
 
-- 
2.5.0


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

Re: [LEDE-DEV] Multi-Profile selection support

[Felix Fietkau]

On 2016-05-24 07:34, Rafał Miłecki wrote:
> On 23 May 2016 at 13:38, Felix Fietkau  wrote:
>> You can find my work in progress in my staging tree:
>> https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary
>>
>> If you have some time, feedback and patches converting profiles/* stuff
>> into proper device profiles will be appreciated.
> 
> I'm afraid building bcm53xx images doesn't work anymore using your
> tree. Can you verify that?
>> ls bin/targets/bcm53xx/generic/
> md5sums
> packages
> sha256sums
Fixed now, thanks for reporting.

- Felix

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

[LEDE-DEV] uci-lua: error checking problems

[Karl Palsson]

When using the lua binding for UCI, there's cases where failures
aren't properly propagating to the lua caller environment.

eg: (Starting from an empty file)

root@blah:/# lua
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio (double int32)
> uci = require("uci")
> x = uci.cursor()
> =x:set("unknown", "unused", "someoption", "somevalue")
true   << lies!
> =x:save("unknown")
true  << more lies!
> =x:commit("unknown")
true  << redundant lies!
> 
root@blah:/# uci show unknown
root@blah:/# ^^ hah! 

In this particular case, the problem is that "err =
UCI_ERR_INVAL" should be "ctx->err = UCI_ERR_INVAL" however this
turns out to be a prevalent problem across the lua binding.

http://git.openwrt.org/?p=project/uci.git;a=blob;f=lua/uci.c;h=47d59c883ab9320b39304fdd46297576c3550fa1;hb=HEAD#l613

Options are some global replacing, or overhauling how the general
utility functions handle codes like this.

"Filed" as an email, as this is too big to fix in a few minutes
on IRC

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] netifd: Add option to configure gc_stale_time for each device

[Alin Nastac]

The UCI parameter neighgcstaletime allows to control how much time will
STALE entries be kept in the neighbour table for both IPv4 and IPv6.

Signed-off-by: Alin Nastac 
---
 device.c   | 14 ++
 device.h   |  4 
 system-linux.c | 38 ++
 3 files changed, 56 insertions(+)

diff --git a/device.c b/device.c
index 7004bfd..3e182f3 100644
--- a/device.c
+++ b/device.c
@@ -45,6 +45,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_IGMPVERSION] = { .name = "igmpversion", .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MLDVERSION] = { .name = "mldversion", .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_NEIGHREACHABLETIME] = { .name = "neighreachabletime", .type = 
BLOBMSG_TYPE_INT32 },
+   [DEV_ATTR_NEIGHGCSTALETIME] = { .name = "neighgcstaletime", .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_RPS] = { .name = "rps", .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_XPS] = { .name = "xps", .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = "dadtransmits", .type = 
BLOBMSG_TYPE_INT32 },
@@ -171,6 +172,10 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
s->neigh4reachabletime : os->neigh4reachabletime;
n->neigh6reachabletime = s->flags & DEV_OPT_NEIGHREACHABLETIME ?
s->neigh6reachabletime : os->neigh6reachabletime;
+   n->neigh4gcstaletime = s->flags & DEV_OPT_NEIGHGCSTALETIME ?
+   s->neigh4gcstaletime : os->neigh4gcstaletime;
+   n->neigh6gcstaletime = s->flags & DEV_OPT_NEIGHGCSTALETIME ?
+   s->neigh6gcstaletime : os->neigh6gcstaletime;
n->dadtransmits = s->flags & DEV_OPT_DADTRANSMITS ?
s->dadtransmits : os->dadtransmits;
n->multicast = s->flags & DEV_OPT_MULTICAST ?
@@ -258,6 +263,11 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s->flags |= DEV_OPT_NEIGHREACHABLETIME;
}
 
+   if ((cur = tb[DEV_ATTR_NEIGHGCSTALETIME])) {
+   s->neigh6gcstaletime = s->neigh4gcstaletime = 
blobmsg_get_u32(cur);
+   s->flags |= DEV_OPT_NEIGHGCSTALETIME;
+   }
+
if ((cur = tb[DEV_ATTR_RPS])) {
s->rps = blobmsg_get_bool(cur);
s->flags |= DEV_OPT_RPS;
@@ -960,6 +970,10 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, "neigh4reachabletime", 
st.neigh4reachabletime);
blobmsg_add_u32(b, "neigh6reachabletime", 
st.neigh6reachabletime);
}
+   if (st.flags & DEV_OPT_NEIGHGCSTALETIME) {
+   blobmsg_add_u32(b, "neigh4gcstaletime", 
st.neigh4gcstaletime);
+   blobmsg_add_u32(b, "neigh6gcstaletime", 
st.neigh6gcstaletime);
+   }
if (st.flags & DEV_OPT_DADTRANSMITS)
blobmsg_add_u32(b, "dadtransmits", st.dadtransmits);
if (st.flags & DEV_OPT_MULTICAST_TO_UNICAST)
diff --git a/device.h b/device.h
index 9c4b822..0b8cd6a 100644
--- a/device.h
+++ b/device.h
@@ -45,6 +45,7 @@ enum {
DEV_ATTR_MULTICAST_TO_UNICAST,
DEV_ATTR_MULTICAST_ROUTER,
DEV_ATTR_MULTICAST,
+   DEV_ATTR_NEIGHGCSTALETIME,
__DEV_ATTR_MAX,
 };
 
@@ -88,6 +89,7 @@ enum {
DEV_OPT_MULTICAST_TO_UNICAST= (1 << 14),
DEV_OPT_MULTICAST_ROUTER= (1 << 15),
DEV_OPT_MULTICAST   = (1 << 16),
+   DEV_OPT_NEIGHGCSTALETIME= (1 << 17),
 };
 
 /* events broadcasted to all users of a device */
@@ -143,6 +145,8 @@ struct device_settings {
unsigned int mldversion;
unsigned int neigh4reachabletime;
unsigned int neigh6reachabletime;
+   unsigned int neigh4gcstaletime;
+   unsigned int neigh6gcstaletime;
bool rps;
bool xps;
unsigned int dadtransmits;
diff --git a/system-linux.c b/system-linux.c
index f79625a..62c51b5 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -310,6 +310,16 @@ static void system_set_neigh6reachabletime(struct device 
*dev, const char *val)

system_set_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/base_reachable_time_ms", 
dev->ifname, val);
 }
 
+static void system_set_neigh4gcstaletime(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl("/proc/sys/net/ipv4/neigh/%s/gc_stale_time", 
dev->ifname, val);
+}
+
+static void system_set_neigh6gcstaletime(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/gc_stale_time", 
dev->ifname, val);
+}
+
 static void system_set_dadtransmits(struct device *dev, const char *val)
 {
system_set_dev_sysctl("/proc/sys/net/ipv6/conf/%s/dad_transmits", 
dev->ifname, val);
@@ -446,6 +456,18 @@ static int system_get_neigh6reachabletime(struct device 
*dev, char *buf, const s
dev->ifname, buf, buf_sz);
 }
 

Re: [LEDE-DEV] 1043ND v2.1 LEDE trunk kernel panic

[A. Benz]

Hi,

I cleaned my buildroot unfortunately.. Only after I accidentally erased 
my bootloader while attempting to recover the router by tftp flashing a 
new image (factory vanilla).


My unit has no activity whatsoever now (no serial output) and only power 
LED is on.


Rev 2.1 doesn't have a JTAG header like 1.x.

PS - Killer command: erase 0x9f00 +0x7c
Should have been: erase 0x9f02 +0x7c

Can't believe I did that :(

Regards,
A. Benz

On 05/24/16 17:24, Felix Fietkau wrote:

On 2016-05-24 02:00, A. Benz wrote:

Hi

Trunk build of LEDE gets a kernel panic on TPLink 1043ND v2.1

See log:
http://paste.debian.net/698070/

I can't reproduce the issue on the same device. Please post the output
of ./scripts/diffconfig.sh

- Felix



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

Re: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[Jo-Philipp Wich]

Hi Refal,

ack from me.

~ Jo

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

Re: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[John Crispin]

On 24/05/2016 19:02, Jo-Philipp Wich wrote:
> Hi Refal,
> 
> ack from me.
> 
> ~ Jo

ack from me aswell

John

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

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

Re: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[Alexander Couzens]

On Tue, 24 May 2016 19:09:15 +0200
John Crispin  wrote:

> On 24/05/2016 19:02, Jo-Philipp Wich wrote:
> > Hi Refal,
> > 
> > ack from me.
> ack from me aswell
ack
- lynxis
-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgp69dKdxfitQ.pgp
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Test farm for routers / tetaneutral.net

[Laurent GUERBY]

Hi,

The not-for-profit ISP tetaneutral.net would like to provide
a hardware test farm for small routers in addition to the LEDE mirror
(and GCC Compile Farm machines hosting, RIPE probe, NLNOG ring VM),
as we use OpenWRT/LEDE for all of our member "internet box" (1)

Has anyone made and documented such a setup?

I can think of:
- ssh access to the gateway with LAN services (DHCP/RA/VLAN trunk)
- switch with per port configurable VLAN (doc for what is plugged where)
- client/server machines to generate LAN/WAN traffic
- remote power control
- remote push button control
- webcam view (for LEDs)
- remote serial (soldering needed)
- local build servers

Other things? 

We can start small with TP-Link TL-WR841N v11.1 which works well with
LEDE snapshort (wifi+LAN+WAN v4/v6) but has (cosmetics) LEDs not
working :).

We have pile of hardware for our needs (TP-Link, Ubiquity, Mikrotik,
Netonix, ...) and have budget of around 1500 EUR per month
free to invest on what we want (1).

Sincerely

Laurent
AS197422 http://tetaneutral.net

(1) Our imagebuilder based scripts
https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openwrt-tools
https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openwrt-tools/revisions/master/entry/quick_841n_ttn_lede.sh

(2) We're transparent about it:
https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Inventaire
https://tetaneutral.net/#Transparence
http://pad.tetaneutral.net/p/budget2016
http://pad.tetaneutral.net/p/stock



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

Re: [LEDE-DEV] [OpenWrt-Devel] OpenWrt / LEDE

[Hauke Mehrtens]

add lede-dev

On 05/24/2016 10:31 PM, Hauke Mehrtens wrote:
> Hi,
> 
> As it looks like the IRC meeting will not happen, because not so big
> interest by the people not already involved in LEDE and problems finding
> a time, lets discuss on the mailing list like suggested by Jow.
> 
> Currently it looks like only Luka is working on OpenWrt as he committed
> many patches from LEDE to OpenWrt, which is fine.
> 
> What will happen to the OpenWrt project? To me it looks like nobody
> except Luka is interested in working on OpenWrt. Are there any plans to
> continue the OpenWrt project or will it just die, only nobody wants to
> say it?
> Currently this is a bad situation for people that want to contribute
> patches because they do not exactly know were to contribute, some post
> them just to both list which is probably the best solution for the time
> we do not have a real solution.
> 
> I do not plan to contribute much to OpenWrt any more and I do not know
> if I can commit anything any more, at least it looks like I was kicked
> from the openwrt-hackers mailing list without informing me.
> 
> 
> I would like to see a reunion of LEDE and OpenWrt, so do any of the non
> LEDE but OpenWrt core devs have any problems with the LEDE rules and so on?
> 
> Hauke

This is my personal opinion and this was not somehow internally planned
with other LEDE people.

Hauke

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

Re: [LEDE-DEV] [OpenWrt-Devel] OpenWrt / LEDE

[Daniel Curran-Dickinson]

On Tue, 2016-05-24 at 23:57 +0200, Zoltan HERPAI wrote:
[snip] 
> Hi,
> >> I would like to see a reunion of LEDE and OpenWrt, so do any of the non
> >> LEDE but OpenWrt core devs have any problems with the LEDE rules and so on?
> >>
> > This is my personal opinion and this was not somehow internally planned
> > with other LEDE people.
> 
> If I start a discussion about my employer-related topics along a beer with 
> a couple friends, that's a private discussion with personal opinions. If I 
> do it on any public channel, I can be felt to represent my employer on 
> that topic. You seem to be representing LEDE.
> 

That's the kind of bollock that damages the ability of employees to have
a right to free speech which disagrees with (or is at least
independently developed of) their employers views.

As long it as someone makes it clear when they are speaking for
themselves and not as a representative of the group, it should be
accepted on that basis, unless if there is a reason to believe otherwise
*other than* just that the person happens to be a member of some group.

It's kind of like saying a black who says he or she speaking for himself
speaks for all blacks, just because it's known he or she is black and he
speaks on a public channel.

It's bollocks.  People are indivduals and have a right be such, and to
have, and be seen to have, views independent of the various groups the
are members of.

I certainly don't speak for all white male IT professionals from North
America.

Regards,

Daniel


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

Re: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

[Ted Hess]

From: Rafał Miłecki
Sent: Tuesday, May 24, 2016 3:37 AM
To: lede-dev@lists.infradead.org
Cc: Rafał Miłecki
Subject: [LEDE-DEV] [PATCH] mac80211: change default SSID from Lede to LEDE

LEDE project seems to be using "LEDE" as its acronym everywhere. To keep
things consistent adjust default wireless SSID.


Hi Rafał -

+1 from me - I like the idea of changing the default SSID of the freshly 
installed system.
It would really be cool if it could be something unique like LEDE where 
'' is the last
4-6digits of the MAC addr.

I'm just sayin'.

/ted


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