[LEDE-DEV] [PATCH] brcm47xx: remove versions from linksys-e1000 target

The target name does not need to included a revision if all revisions are supported. This target supports all revisions (v1, v2, v2.1). Signed-off-by: Moritz Warning --- target/linux/brcm47xx/image/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff

[LEDE-DEV] [PATCH] brcm47xx: proper region code in image name

Replace 'north-america' by 'us' and remove 'other-regions' in image files for Netgear WGR614 v10. Signed-off-by: Moritz Warning --- target/linux/brcm47xx/image/Makefile | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

[LEDE-DEV] Adding firewall extensions for xt_geoip usage

Jo and others: Is there an easy way to extend firewall rules? I’d like to add support to blocking on a per-country basis, possibly with qualified exceptions. For instance, if I wanted to block all ISP’s from RU, but allow email from Kaspersky’s servers in Russia. I’d like to do something

[LEDE-DEV] [PATCH] ar71xx: fix board detection with newer RouterBOOT versions

Recent RouterBOOT version (at least version 3.41 on RB911G-5HPacD) use "Board=" kernel parameter instead of "board=" to pass the board name to the kernel. Due to this change the board detection code is not working on the devices shipped with the new RouterBOOT version. Because the kernel is unable

Re: [LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname

08.12.2017 21:14, Daniel Golle: Hi Mathias, On Fri, Dec 08, 2017 at 09:35:26AM +0100, Mathias Kresin wrote: udhcpc doesn't send a hostname by default. Use the system hostname if nothing else is specified, to always send a hostname. It syncs the behaviour to odhcpc, which always sends a

Re: [LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname

Hi Mathias, On Fri, Dec 08, 2017 at 09:35:26AM +0100, Mathias Kresin wrote: > udhcpc doesn't send a hostname by default. Use the system hostname if > nothing else is specified, to always send a hostname. > > It syncs the behaviour to odhcpc, which always sends a hostname. Could we somehow allow

Re: [LEDE-DEV] [FINAL CALL] Merging the 'OpenWrt merge' patches

On Fri, 8 Dec 2017, Felix Fietkau wrote: On 2017-12-07 15:55, Felix Fietkau wrote: Hi, Are there any remaining concerns about those 'OpenWrt merge' patches that have been sitting in my staging tree for a while now? If not, I plan on pushing them to master this weekend. Done. - Felix

Re: [LEDE-DEV] [FINAL CALL] Merging the 'OpenWrt merge' patches

On 2017-12-07 15:55, Felix Fietkau wrote: > Hi, > > Are there any remaining concerns about those 'OpenWrt merge' patches > that have been sitting in my staging tree for a while now? > > If not, I plan on pushing them to master this weekend. Done. - Felix

Re: [LEDE-DEV] [PATCH 1/7] ag71xx: Reorder some more structs based on warmth.

On 2017-12-08 04:37, Rosen Penev wrote: Should help slightly. Hi, Rosen, did you actually see any measurable improvements when applying these? I was playing with these QCA changes back in 4.1 times and didn't see any improvement. When there are several patches it would be better to

Re: [LEDE-DEV] Latest trunk pull fails to compile?

Your build is based on an old .config that enables "odhcpd" (as it was the default in the past). The latest master includes a package "odhcpd-ipv6only", which is the default since c7b052db739e50f8a40f95ac17a21363b1593e33. Our Kconfig-based .config management can't properly deal with conficting

Re: [LEDE-DEV] Latest trunk pull fails to compile?

Citeren Mauro Mozzarelli : Hello, I am trying to compile trunk just pulled today and this is how it fails: [...] Configuring libpopt. Configuring getopt. Configuring gzip. Configuring atm-tools. Configuring kmod-ltq-deu-vr9. Configuring kmod-fs-cifs. Configuring

[LEDE-DEV] Latest trunk pull fails to compile?

Hello, I am trying to compile trunk just pulled today and this is how it fails: [...] Configuring libpopt. Configuring getopt. Configuring gzip. Configuring atm-tools. Configuring kmod-ltq-deu-vr9. Configuring kmod-fs-cifs. Configuring kmod-usb-storage-extras. Configuring xz-utils.

[LEDE-DEV] [PATCH][netifd] handler: replace is_error() helper with NULL check

The `is_error()` is just a macro that checks that object is NULL (which is considered an error in libjson-c terminology). Newer libjson-c versions have deprecated this. Signed-off-by: Alexandru Ardelean --- handler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [LEDE-DEV] [PATCH] handler: replace is_error() helper with NULL check

On Fri, Dec 8, 2017 at 4:19 PM, Alexandru Ardelean wrote: > The `is_error()` is just a macro that checks > that object is NULL (which is considered an error > in libjson-c terminology). > > Newer libjson-c versions have deprecated this. I forgot to add the [netifd] tag.

[LEDE-DEV] [PATCH] handler: replace is_error() helper with NULL check

The `is_error()` is just a macro that checks that object is NULL (which is considered an error in libjson-c terminology). Newer libjson-c versions have deprecated this. Signed-off-by: Alexandru Ardelean --- handler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[LEDE-DEV] [PATCH odhcpd v2] Support muliple RAs on single interface

From: Pierre Pfister IETF is moving toward implementing IPv6 multihoming by sending multiple RAs on a single interface: - draft-ietf-intarea-provisioning-domains-00 - draft-ietf-rtgwg-enterprise-pa-multihoming-02 odhcpd supports configuration of multiple software interfaces

Re: [LEDE-DEV] [PATCH odhcpd] Support muliple RAs on single interface

On Fri, Dec 8, 2017 at 10:33 AM, wrote: > From: Pierre Pfister > > IETF is moving toward implementing IPv6 multihoming by sending > multiple RAs on a single interface: > - draft-ietf-intarea-provisioning-domains-00 > -

Re: [LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname

On Fri, Dec 8, 2017 at 1:43 PM, Stijn Tintel wrote: > On 08-12-17 09:35, Mathias Kresin wrote: >> udhcpc doesn't send a hostname by default. Use the system hostname if >> nothing else is specified, to always send a hostname. >> >> It syncs the behaviour to odhcpc, which

Re: [LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname

On 08-12-17 09:35, Mathias Kresin wrote: > udhcpc doesn't send a hostname by default. Use the system hostname if > nothing else is specified, to always send a hostname. > > It syncs the behaviour to odhcpc, which always sends a hostname. > > Signed-off-by: Mathias Kresin > --- >

Re: [LEDE-DEV] [PATCH 2/7] ag71xx: add method to count ag71xx probes

On 2017-12-08 03:37, Rosen Penev wrote: > This patch is preparation for ag71xx usage of external, on-die > resources. Since these resources are limited, we need to track how > many instances we have probed. > > Signed-off-by: Ben Menchaca > Signed-off-by: Rosen

Re: [LEDE-DEV] [PATCH 5/7] ag71xx: Replace AG71XX_DESC_SIZE macro with a struct member.

On 2017-12-08 03:37, Rosen Penev wrote: > Moves the code more in line with QCA code. Also reduces variable to a u16 > instead of s32. > > QCA code has the roundup component behind a Makefile config. Not sure if > enabled by default so I opted to keep current behavior. > > Signed-off-by: Rosen

Re: [LEDE-DEV] [PATCH 6/7] ag71xx: Put ring_size in ag71xx_ring struct.

On 2017-12-08 03:37, Rosen Penev wrote: > Less verbose code. Should help when porting some of the other patches. NACK. I don't think it makes things simpler in any meaningful way. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org

Re: [LEDE-DEV] Lede/Openwrt documentation

May I make a late contribution to this thread? As a user and occasional contributor to openwrt and lede I'd like to stress how invaluable the openwrt wiki in its current form is, precisely because it is real hotchpotch. Of course it is unstructured, of course there is redundancy, of course some

[LEDE-DEV] [PATCH odhcpd] Support muliple RAs on single interface

From: Pierre Pfister IETF is moving toward implementing IPv6 multihoming by sending multiple RAs on a single interface: - draft-ietf-intarea-provisioning-domains-00 - draft-ietf-rtgwg-enterprise-pa-multihoming-02 odhcpd supports configuration of multiple software interfaces

[LEDE-DEV] [PATCH] netifd: always send DHCPv4 hostname

udhcpc doesn't send a hostname by default. Use the system hostname if nothing else is specified, to always send a hostname. It syncs the behaviour to odhcpc, which always sends a hostname. Signed-off-by: Mathias Kresin ---