Re: [LEDE-DEV] ar71xx: Need advice on parsing specific board config data on TP-Link TL-WR942N

[Piotr Dymacz]

Hello Sergey,

2017-02-21 0:00 GMT+01:00 Sergey Studzinski :
> I'm currently working on LEDE port for TP-Link TL-WR942N v1 N450 router.
> Hardware is mostly like Archer C59 QCA9561 platform but no 5GHz ac
> radio and two USB2.0 ports.
> Most work is already done against 17.01-rc2 and there is working
> factory and sysupgrade images.

Please, base your work on master branch.

> Special thanks to Henryk Heisig and Felix Fietkau for their work!
> Pecularities are found with MAC and some other specific board config
> data which are not stored on first
> mtd0(u-boot) partition like on Archers but right after rootfs
> partition in a slightly different format (ASCII instead
> of binary). Due this router starts with random MACs now.

Just checking, have you tried to look for MAC in binary format in
whole flash dump?

[...]

> root@LEDE:~# hexdump -C /dev/mtd4
>   00 00 00 16 00 00 00 00  4d 41 43 3a 38 34 2d 31  |MAC:84-1|
> 0010  36 2d 12 34 2d 56 78 2d  9a bc 2d de f0 0a ff ff  |6-F9-12-34-56...|

TP-Link surprises me with every new device...

[...]

> Is there already special parser for this data somewhere in LEDE tree
> or should we write new one?

We have a shell function mtd_get_mac_ascii() in [1] and some boards
under ar71xx target utilize it [2]. But I'm sure it won't work with
such format - equal sign as separator is hardcoded there.
Maybe we can extend it, add another one parameter with separator and
keep it as "=" by default, for backward compatibility. You would also
need to take a look at macaddr_canonicalize() function and check if it
can work with this MAC format.

> Or can we move this data on the second mtd0 sector on the first boot
> and have it mostly like and
> compatible with Archer C59/c60 code? BTW factory u-boot fits on first
> 64kbytes and second 64K
> sector is completely 0xFF.

[...]

IMHO, overwriting any kind of factory data in flash should be at the
very end of list with possible solutions/workarounds, especially if we
are talking here about second sector of flash, just after the U-Boot
image.

As I can see, "fs-boot" partition in factory firmware for this device
is 128 KB size and I'm pretty sure not without a reason. I can imagine
someday TP-Link will release update for this device with U-Boot image
bigger than 64 KB and from that point our image will start breaking
user's devices.

[1] 
https://github.com/lede-project/source/blob/master/package/base-files/files/lib/functions/system.sh#L11
[2] 
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/base-files/etc/board.d/02_network#L483

---
Cheers,
Piotr

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

Re: [LEDE-DEV] need help / info [httpd/apache]

[Bastian Bittorf]

* Denis Periša  [21.02.2017 06:44]:
> Thank you Bastian. I've come to realize it could be possible :)
> Only thing that lacks is apaches nice way of redirecting 404 page to
> php, here if I do that it sends php file as html, without execution.

this should work. Have you set e.g.:
uhttpd.main.interpreter='.php=/bin/php'

bye, bastian

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

Re: [LEDE-DEV] [PATCH] build: unsilence move command

[Rafał Miłecki]

On 20 February 2017 at 17:48, Thomas Reifferscheid
 wrote:
> The @ sign in front of the "mv" command was significantly suppressing
> output to stdout. When reviewing the make/build logs it was tricking
> me a whole lot and it mad me lose time. Removing the @ sign will get
> stdout and logs right about what happened when.
>
> Signed-off-by: Thomas Reifferscheid 

Looks good to me.

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

Re: [LEDE-DEV] Identifying kernel version (major) during build (.mk file)

[Rafał Miłecki]

On 20 February 2017 at 20:03, Mauro Mozzarelli  wrote:
> There is in some cases where kernel drivers have changed. As you might see
> in the ip_vs patch I posted, kernel drivers differ in Kernel 3 and 4

Jonas is correct. Such a change could happen between 3.18 and 3.19 as
well. It was can a coincidence. There isn't anything magic about 3.x
vs 4.x.

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

[LEDE-DEV] s25fl064k w25q64 and UBNT PBE-M5-620

[Joe Ayers]

Was there ever a conclusion to the different NOR chips returning the
same JEDEC ID?

reference:  
http://lists.infradead.org/pipermail/linux-mtd/2016-March/066333.html

Looks like the issue still exists in 17.01-SNAPSHOT, r3202-4d1ab84 on
the PBE-M5-620 using the Rocket-xw image.   Was this the determined
resolution?:

"As 'mtd: spi-nor: wait for SR_WIP to clear on initial unlock' has
fixed that, I think we can just unconditionally unlock all flash with
SNOR_MFR_WINBOND again without breaking Spansion flash."

I'm getting this failure:

[ 0.542840] m25p80 spi0.0: found s25fl064k, expected m25p80
[ 0.548580] m25p80 spi0.0: s25fl064k (8192 Kbytes)
[0.553468] 5 cmdlinepart partitions found on MTD device spi0.0
[0.559488] Creating 5 MTD partitions on "spi0.0":
[0.564352] 0x-0x0004 : "u-boot"
[0.572011] 0x0004-0x0005 : "u-boot-env"
[0.579398] 0x0005-0x007b : "firmware"
[0.596050] 2 uimage-fw partitions found on MTD device firmware
[0.602114] 0x0005-0x0019 : "kernel"
[0.609005] 0x0019-0x007b : "rootfs"
[0.615940] mtd: device 4 (rootfs) set to be root filesystem
[0.621791] 1 squashfs-split partitions found on MTD device rootfs
[0.628069] 0x0037-0x007b : "rootfs_data"
[0.635533] 0x007b-0x007f : "cfg"
[0.642330] 0x007f-0x0080 : "EEPROM"
[7.158165] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
[   15.648842] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[   15.655839] jffs2_build_filesystem(): unlocking the mtd device... done.
[   15.662627] jffs2_build_filesystem(): erasing all blocks after the
end marker...
[   15.689881] jffs2: Newly-erased block contained word 0x19852003 at
offset 0x0043
   --- a lot more removed and uninteresting 
[   17.540053] jffs2: Newly-erased block contained word 0xc0bff600 at
offset 0x0001
[   17.570020] jffs2: Newly-erased block contained word 0xdeadc0de at
offset 0x
[   17.577888] done.
[   17.579908] jffs2: notice: (789) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan)
and 0 of xref (0 dead, 0 orphan) found.


root@LEDE:~# df -h
FilesystemSize  Used Available Use% Mounted on
/dev/root 2.0M  2.0M 0 100% /rom
tmpfs29.5M 60.0K 29.5M   0% /tmp
tmpfs29.5M 40.0K 29.5M   0% /tmp/root
overlayfs:/tmp/root  29.5M 40.0K 29.5M   0% /
tmpfs   512.0K 0512.0K   0% /dev
/dev/mtdblock54.3M  4.3M 0 100% /rom/overlay

Regards,
Joe AE6XE

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

[LEDE-DEV] [PATCH, v2] kmodloader: fix not being able to find some modules

[Nathan Hintz]

kmodloader is using slightly different criteria for ordering the AVL tree
versus what it uses to traverse it.  This sometimes results in not being
able to find some modules.

Reference: https://bugs.lede-project.org/index.php?do=details_id=443

Signed-off-by: Nathan Hintz 
---

v2: changed "inline" to "static inline"

 kmodloader.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/kmodloader.c b/kmodloader.c
index 465d3de..ac14bac 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -985,20 +985,23 @@ out:
return 0;
 }
 
+static inline char weight(char c)
+{
+   return c == '_' ? '-' : c;
+}
+
 static int avl_modcmp(const void *k1, const void *k2, void *ptr)
 {
const char *s1 = k1;
const char *s2 = k2;
 
-   while (*s1 && ((*s1 == *s2) ||
-  ((*s1 == '_') && (*s2 == '-')) ||
-  ((*s1 == '-') && (*s2 == '_'
+   while (*s1 && (weight(*s1) == weight(*s2)))
{
s1++;
s2++;
}
 
-   return *(const unsigned char *)s1 - *(const unsigned char *)s2;
+   return (unsigned char)weight(*s1) - (unsigned char)weight(*s2);
 }
 
 int main(int argc, char **argv)
-- 
2.9.3


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

Re: [LEDE-DEV] [PATCH] kmodloader: fix not being able to find some modules

[Yousong Zhou]

On 21 February 2017 at 01:54, Nathan Hintz  wrote:
> kmodloader is using slightly different criteria for ordering the AVL tree
> versus what it uses to traverse it.  This sometimes results in not being
> able to find some modules.
>
> Reference: https://bugs.lede-project.org/index.php?do=details_id=443
>
> Signed-off-by: Nathan Hintz 
> ---
>  kmodloader.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/kmodloader.c b/kmodloader.c
> index 465d3de..8343836 100644
> --- a/kmodloader.c
> +++ b/kmodloader.c
> @@ -985,20 +985,23 @@ out:
> return 0;
>  }
>
> +inline char weight(char c)
> +{
> +   return c == '_' ? '-' : c;
> +}

This should be marked as static.

> +
>  static int avl_modcmp(const void *k1, const void *k2, void *ptr)
>  {
> const char *s1 = k1;
> const char *s2 = k2;
>
> -   while (*s1 && ((*s1 == *s2) ||
> -  ((*s1 == '_') && (*s2 == '-')) ||
> -  ((*s1 == '-') && (*s2 == '_'
> +   while (*s1 && (weight(*s1) == weight(*s2)))
> {
> s1++;
> s2++;
> }
>
> -   return *(const unsigned char *)s1 - *(const unsigned char *)s2;
> +   return (unsigned char)weight(*s1) - (unsigned char)weight(*s2);

This line seems to be the change and it makes sense, but I failed to
see how it will resolve the referred bug report.  Can you please give
an example to show the said subtle difference and how it will cause
issue?

Thanks,
yousong


>  }
>
>  int main(int argc, char **argv)
> --
> 2.9.3
>
>
> ___
> 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] procd: update modprobe path

[Yousong Zhou]

On 21 February 2017 at 04:39, Nathan Hintz  wrote:
> Commit 81aeba9b7f619ee1af1a64f355ae8001fa147d03 in LEDE source.git moved
> modprobe to the "/sbin" directory.  Update procd with the new path.
>
> Signed-off-by: Nathan Hintz 
> ---
>  initd/zram.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/initd/zram.c b/initd/zram.c
> index 9fab794..0e78195 100644
> --- a/initd/zram.c
> +++ b/initd/zram.c
> @@ -53,9 +53,9 @@ static int
>  early_insmod(char *module)
>  {
> pid_t pid = fork();
> +   char *modprobe[] = { "/sbin/modprobe", NULL, NULL };
>
> if (!pid) {
> -   char *modprobe[] = { "/usr/sbin/modprobe", NULL, NULL };
> char *path;
> struct utsname ver;
>
> @@ -64,12 +64,12 @@ early_insmod(char *module)
> sprintf(path, module, ver.release);
> modprobe[1] = path;
> execvp(modprobe[0], modprobe);
> -   ERROR("Can't exec /usr/sbin/modprobe\n");
> +   ERROR("Can't exec %s\n", modprobe[0]);
> exit(-1);
> }
>
> if (pid <= 0) {
> -   ERROR("Can't exec /usr/sbin/modprobe\n");
> +   ERROR("Can't exec %s\n", modprobe[0]);

Though it happens rarely, it would be better if we can distinguish
from log the error between fork and exec call.

> return -1;
> } else {
> waitpid(pid, NULL, 0);
> @@ -107,10 +107,10 @@ mount_zram_on_tmp(void)
> pid = fork();
> if (!pid) {
> execvp(mkfs[0], mkfs);
> -   ERROR("Can't exec /sbin/mkfs.ext4\n");
> +   ERROR("Can't exec %s\n", mkfs[0]);
> exit(-1);
> } else if (pid <= 0) {
> -   ERROR("Can't exec /sbin/mkfs.ext4\n");
> +   ERROR("Can't exec %s\n", mkfs[0]);

Same here.

Other than that, ACK from me.  Thanks

yousong

> return -1;
> } else {
> waitpid(pid, NULL, 0);
> --
> 2.9.3
>
>
> ___
> 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

[LEDE-DEV] Mikrotik sysupgrade install not working on sxt lite2.

[Alen Opacic]

On sxt lite 2 (older version with 128mb nand flash) using
lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-mikrotik-vmlinux-initramfs.elf image,
than sysupgrade to
lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-mikrotik-nand-
large-squashfs-sysupgrade.bin.
After reboot sxt is in a boot loop state, boots allways from network boot
(tftp). This can be called a regresion since this sxt works fine with CC
and wget2nand.

How can i help debug this ishue.

Ps: if someone can help maybe we can get sxtg2hnd
(not lite version) to work with
openwrt. This one as far as i know newer worked with openwrt/lede.

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

[LEDE-DEV] ar71xx: Need advice on parsing specific board config data on TP-Link TL-WR942N

[Sergey Studzinski]

I'm currently working on LEDE port for TP-Link TL-WR942N v1 N450 router.
Hardware is mostly like Archer C59 QCA9561 platform but no 5GHz ac
radio and two USB2.0 ports.
Most work is already done against 17.01-rc2 and there is working
factory and sysupgrade images.
Special thanks to Henryk Heisig and Felix Fietkau for their work!
Pecularities are found with MAC and some other specific board config
data which are not stored on first
mtd0(u-boot) partition like on Archers but right after rootfs
partition in a slightly different format (ASCII instead
of binary). Due this router starts with random MACs now.

There is factory partition table:
-
root@LEDE:~# strings /dev/mtd5
partition fs-uboot base 0x0 size 0x2
partition os-image base 0x2 size 0x15
partition file-system base 0x17 size 0xcd
partition default-mac base 0xe4 size 0x00200
partition pin base 0xe40200 size 0x00200
partition product-info base 0xe40400 size 0x0fc00
partition partition-table base 0xe5 size 0x1
partition soft-version base 0xe6 size 0x1
partition support-list base 0xe7 size 0x1
partition profile base 0xe8 size 0x1
partition default-config base 0xe9 size 0x1
partition user-config base 0xea size 0x4
partition qos-db base 0xee size 0x4
partition certificate base 0xf2 size 0x1
partition usb-config base 0xfb size 0x1
partition log base 0xfc size 0x2
partition radio-bk base 0xfe size 0x1
partition radio base 0xff size 0x1
-
Currently on the LEDE port three partitions (defalt-mac, pin,
product-info) are united in one 64K
partition. Content is like:
-
root@LEDE:~# hexdump -C /dev/mtd4
  00 00 00 16 00 00 00 00  4d 41 43 3a 38 34 2d 31  |MAC:84-1|
0010  36 2d 12 34 2d 56 78 2d  9a bc 2d de f0 0a ff ff  |6-F9-12-34-56...|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0200  00 00 00 09 00 00 00 00  35 38 36 33 33 37 32 34  |58633724|
0210  0a 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
0220  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0400  00 00 00 96 00 00 00 00  76 65 6e 64 6f 72 5f 6e  |vendor_n|
0410  61 6d 65 3a 54 50 2d 4c  49 4e 4b 0a 76 65 6e 64  |ame:TP-LINK.vend|
0420  6f 72 5f 75 72 6c 3a 77  77 77 2e 74 70 2d 6c 69  |or_url:www.tp-li|
0430  6e 6b 2e 63 6f 6d 0a 70  72 6f 64 75 63 74 5f 6e  |nk.com.product_n|
0440  61 6d 65 3a 54 4c 2d 57  52 39 34 32 4e 0a 6c 61  |ame:TL-WR942N.la|
0450  6e 67 75 61 67 65 3a 55  4e 0a 70 72 6f 64 75 63  |nguage:UN.produc|
0460  74 5f 76 65 72 3a 31 2e  30 2e 30 0a 70 72 6f 64  |t_ver:1.0.0.prod|
0470  75 63 74 5f 69 64 3a 30  39 34 32 30 30 30 31 0a  |uct_id:09420001.|
0480  73 70 65 63 69 61 6c 5f  69 64 3a 35 32 35 35 30  |special_id:52550|
0490  30 30 30 0a 63 6f 75 6e  74 72 79 3a 52 55 00 ff  |000.country:RU..|
04a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0001
-

Is there already special parser for this data somewhere in LEDE tree
or should we write new one?
Or can we move this data on the second mtd0 sector on the first boot
and have it mostly like and
compatible with Archer C59/c60 code? BTW factory u-boot fits on first
64kbytes and second 64K
sector is completely 0xFF.
As for now partitions from 0xe4 is not writable to preserve OEM
firmware compatibility. IMHO it is not good idea to broke it.

Thank You on future advice.

Serg Studzinski

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

[LEDE-DEV] [PATCH] ar71xx: WNDR4300: Fix switch HW controlled LEDs

[Daniel Gonzalez Cabanelas]

The Netgear WNDR4300, equipped with an Atheros AR8327 Gigabit Switch,
has two LEDs on each port for monitoring LAN activity, but it currently 
only uses one. Fix the configuration to use both.

The patch provides this new configuration:
- green LED: 1 Gbps link, 4Hz blink frequency
- amber LED: 10/100 Mbps link. 4Hz for 100Mbps, 2Hz for 10Mbps  

Signed-off-by: Daniel Gonzalez Cabanelas 
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wndr4300.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wndr4300.c
index 2884c6c..2a00a0e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wndr4300.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wndr4300.c
@@ -136,11 +136,11 @@ static struct ar8327_pad_cfg wndr4300_ar8327_pad0_cfg = {
 };
 
 static struct ar8327_led_cfg wndr4300_ar8327_led_cfg = {
-   .led_ctrl0 = 0xc737c737,
-   .led_ctrl1 = 0x,
+   .led_ctrl0 = 0xcc35cc35,
+   .led_ctrl1 = 0xcb37cb37,
.led_ctrl2 = 0x,
-   .led_ctrl3 = 0x0030c300,
-   .open_drain = false,
+   .led_ctrl3 = 0x00f3cf00,
+   .open_drain = true,
 };
 
 static struct ar8327_platform_data wndr4300_ar8327_data = {


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

Re: [LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

[Mathias Kresin]

18.02.2017 19:05, Felix Fietkau:

On 2017-02-18 16:57, Mathias Kresin wrote:

@Felix: Would you please do a review of my changes. You added the
function in question with c536da3 "lantiq: add VLAN handling fixes to
xrx200 ethernet driver" but unfortunately without commit message.

I'm not sure about the purpose of the introduced function or which
(reproducible) issue gets fixed with the function. Might be that there
is some kind of logic bug in the function that I workaround for
broadcast packages now. The best case would be if you only missed that
is_multicast_ether_addr() is true for the broadcast address as well and
the function was never intended to handle broadcast packages.

This function actually was intended to handle broadcast packets, and in
the tests that I made back when I wrote the patch, it resolved an issue
pretty much like you're describing.

So the patch in your staging tree which adds the is_broadcast_ether_addr
check is wrong, and we need to look into why the portmap feature for
multicast packets doesn't work properly.

If you can reproduce the issue, please add a printk to show the data of
the special tag for packets which are leaking onto the wrong vlan, as
well as the switch configuration and the values of hw->vlan_port_map.


Hey Felix,

here are the requested printks:

special tag pre multicast cond:  0x0201
special tag post multicast cond: 0x0200c0af
special tag final:   0x0200c0ef

I observed leaking spanning tree protocol packages as well, which made 
it obvious that my patch doesn't properly fix the issue.


It should be fairly easy to reproduce the issue. Create two vlans, ping 
a not assigned ipv4 address in one of the vlans ipv4 subnets to force 
the arp packages => arp request is send to both vlans/all ports. The STP 
packages leak to the wan interface as soon as STP is enabled for the lan 
bridge.


As soon as I remove the whole "is multicast" condition the special tag 
variable has the following values:


special tag pre multicast cond:  0x0201
special tag post multicast cond: 0x0201
special tag final:   0x026f

and I'm no longer able to observe any package leakage. I've tested with 
local broadcast (ARP) and with STP packages. To test whether this change 
causes package leaks for external send packages, I've send ARP packages 
and IGMPv3 packages from an client to the router. But still no package 
leakage.


I've reverted my setup to have the lantiq,wan eth1 interface again and 
even in this setup I wasn't able cause package leakage between vlans 
with the whole "is multicast" condition removed.


Mathias

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

[LEDE-DEV] [PATCH] procd: update modprobe path

[Nathan Hintz]

Commit 81aeba9b7f619ee1af1a64f355ae8001fa147d03 in LEDE source.git moved
modprobe to the "/sbin" directory.  Update procd with the new path.

Signed-off-by: Nathan Hintz 
---
 initd/zram.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/initd/zram.c b/initd/zram.c
index 9fab794..0e78195 100644
--- a/initd/zram.c
+++ b/initd/zram.c
@@ -53,9 +53,9 @@ static int
 early_insmod(char *module)
 {
pid_t pid = fork();
+   char *modprobe[] = { "/sbin/modprobe", NULL, NULL };
 
if (!pid) {
-   char *modprobe[] = { "/usr/sbin/modprobe", NULL, NULL };
char *path;
struct utsname ver;
 
@@ -64,12 +64,12 @@ early_insmod(char *module)
sprintf(path, module, ver.release);
modprobe[1] = path;
execvp(modprobe[0], modprobe);
-   ERROR("Can't exec /usr/sbin/modprobe\n");
+   ERROR("Can't exec %s\n", modprobe[0]);
exit(-1);
}
 
if (pid <= 0) {
-   ERROR("Can't exec /usr/sbin/modprobe\n");
+   ERROR("Can't exec %s\n", modprobe[0]);
return -1;
} else {
waitpid(pid, NULL, 0);
@@ -107,10 +107,10 @@ mount_zram_on_tmp(void)
pid = fork();
if (!pid) {
execvp(mkfs[0], mkfs);
-   ERROR("Can't exec /sbin/mkfs.ext4\n");
+   ERROR("Can't exec %s\n", mkfs[0]);
exit(-1);
} else if (pid <= 0) {
-   ERROR("Can't exec /sbin/mkfs.ext4\n");
+   ERROR("Can't exec %s\n", mkfs[0]);
return -1;
} else {
waitpid(pid, NULL, 0);
-- 
2.9.3


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

Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing capabilities

[Jonas Gorski]

On 20 February 2017 at 10:47, Jonas Gorski  wrote:
> On 19 February 2017 at 13:01, Mauro Mozzarelli  wrote:
>> Author: Mauro Mozzarelli 
>> Date:   Sun Feb 19 11:33:23 2017 +
>>
>> IPVS (IP Virtual Server) implements transport-layer load balancing
>> inside the Linux kernel, so called Layer-4 switching. IPVS running on a host
>> acts as a load balancer at the front of a cluster of real servers, it can
>> direct requests for TCP/UDP based services to the real servers, and makes
>> services of the real servers to appear as a virtual service on a single IP
>> address.
>>
>> This patch adds kmod-nf-ipvs kernel modules option to LEDE kernel
>> netfilter
>>
>> Signed-off-by: Mauro Mozzarelli 
>>
>> diff --git a/package/kernel/linux/modules/netfilter.mk
>> b/package/kernel/linux/modules/netfilter.mk
>> index 6162dbc..7c51d9f 100644
>> --- a/package/kernel/linux/modules/netfilter.mk
>> +++ b/package/kernel/linux/modules/netfilter.mk
>> @@ -271,6 +271,117 @@ define KernelPackage/ipt-ipset
>>  endef
>>  $(eval $(call KernelPackage,ipt-ipset))
>>
>> +IPVS_K3_MODULES:= \
>> +ip_vs \
>> +ip_vs_lc \
>> +ip_vs_wlc \
>> +ip_vs_rr \
>> +ip_vs_wrr \
>> +ip_vs_lblc \
>> +ip_vs_lblcr \
>> +ip_vs_dh \
>> +ip_vs_sh \
>> +ip_vs_fo \
>> +ip_vs_nq \
>> +ip_vs_sed \
>> +ip_vs_ftp
>
> (snip)
>
>> +IPVS_K4_MODULES:= \
>> +ip_vs \
>> +ip_vs_lc \
>> +ip_vs_wlc \
>> +ip_vs_rr \
>> +ip_vs_wrr \
>> +ip_vs_lblc \
>> +ip_vs_lblcr \
>> +ip_vs_dh \
>> +ip_vs_sh \
>> +ip_vs_fo \
>> +ip_vs_nq \
>> +ip_vs_sed
>
> These seem mostly the same, the only difference is ip_vs_ftp in 3.18.
> You can annotate the FILES with kernel versions, e.g.
> ip_vs_ftp.ko@lt4.0" would mean "copy this file only if kernel version
> is less than 4.0". That way you should be able to just have one
> KernelPackage definition.

Actually looking at the linux sources, ip_vs_ftp is still present in
4.10, so I don't see why you need to do the distinction at all. Does
it not build?


Regards
Jonas

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

Re: [LEDE-DEV] Identifying kernel version (major) during build (.mk file)

[Jonas Gorski]

Hi,

please don't top-post.

On 20 February 2017 at 20:03, Mauro Mozzarelli  wrote:
> Jonas,
>
>
> There is in some cases where kernel drivers have changed. As you might see
> in the ip_vs patch I posted, kernel drivers differ in Kernel 3 and 4 and
> thus it is necessary to know which kernel I am building for to select the
> appropriate kernel configuration.
>
> If the granularity requires to specify the patchlevel, and if LEDE had more
> than one Kernel 3 patchlevel instead of just 3_18, then I would have to
> specify all of them in my makefile. Not only that, but also I would have to
> modify my makefile to include new Kernel 3 versions should they be added in
> future to the LEDE build.

But there is no significant 3.x vs 4.x difference. You might see a
module that was introduced in 4.0 so it happens to look like a 3.19-
vs 4.0+ (so 3.x vs 4.x) change, but that's just coincidence. It might
have as well be introduced in 4.1, or in 3.19. So there really is no
reason to treat the 3.19 => 4.0 switch differently.


Jonas

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

Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing capabilities

[Felix Fietkau]

On 2017-02-20 20:08, Mauro Mozzarelli wrote:
> Hello John,
> 
> Thank you for reviewing the patch. I extracted it with "git show" which 
> added the tabs, but I can always edit the patch file manually and remove 
> them if it helps.
> 
> Please could you clarify what is the problem with line wrapping? It is 
> there for better readability, would you like everything to be in one line?
> 
> Also I am not sure I understand your reference to "patchwork mangling".
> 
> To create the patch file I do the following (to a freshly cloned LEDE 
> trunk repository):
> 
> 1. git checkout -b myproject
> 2. Apply changes
> 3. git add path to changed files
> 4. git commit and edit comments (I add my comments without tabs)
> 5. git show to extract patch file (git adds the tabs here)
> 
> Please could you let me know if there is a best practice to create patch 
> files?
Please use git send-email to send them directly. If you really need to
generate them manually, use git format-patch.

- Felix


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

Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing capabilities

[Mauro Mozzarelli]

Hello John,

Thank you for reviewing the patch. I extracted it with "git show" which 
added the tabs, but I can always edit the patch file manually and remove 
them if it helps.


Please could you clarify what is the problem with line wrapping? It is 
there for better readability, would you like everything to be in one line?


Also I am not sure I understand your reference to "patchwork mangling".

To create the patch file I do the following (to a freshly cloned LEDE 
trunk repository):


1. git checkout -b myproject
2. Apply changes
3. git add path to changed files
4. git commit and edit comments (I add my comments without tabs)
5. git show to extract patch file (git adds the tabs here)

Please could you let me know if there is a best practice to create patch 
files?


Best regards,

Mauro


On 20/02/17 08:31, John Crispin wrote:

Hi,

comments inline

On 19/02/2017 13:01, Mauro Mozzarelli wrote:

Author: Mauro Mozzarelli 
Date:   Sun Feb 19 11:33:23 2017 +

 IPVS (IP Virtual Server) implements transport-layer load balancing

^ stray tab


inside the Linux kernel, so called Layer-4 switching. IPVS running on a
host acts as a load balancer at the front of a cluster of real servers,
it can direct requests for TCP/UDP based services to the real servers,
and makes services of the real servers to appear as a virtual service on
a single IP address.

 This patch adds kmod-nf-ipvs kernel modules option to LEDE kernel

^ stray tab


netfilter

 Signed-off-by: Mauro Mozzarelli 



^ stray tab and obfuscated mail addr


diff --git a/package/kernel/linux/modules/netfilter.mk
b/package/kernel/linux/modules/netfilter.mk
index 6162dbc..7c51d9f 100644
--- a/package/kernel/linux/modules/netfilter.mk
+++ b/package/kernel/linux/modules/netfilter.mk
@@ -271,6 +271,117 @@ define KernelPackage/ipt-ipset
  endef
  $(eval $(call KernelPackage,ipt-ipset))

+IPVS_K3_MODULES:= \
+ip_vs \
+ip_vs_lc \
+ip_vs_wlc \
+ip_vs_rr \
+ip_vs_wrr \
+ip_vs_lblc \
+ip_vs_lblcr \
+ip_vs_dh \
+ip_vs_sh \
+ip_vs_fo \
+ip_vs_nq \
+ip_vs_sed \
+ip_vs_ftp
+
+define KernelPackage/nf-ipvs
+  SUBMENU:=Netfilter Extensions
+  TITLE:=IP Virtual Server modules Kernel 3
+  DEPENDS:=+kmod-lib-crc32c @(LINUX_3_18)
+  KCONFIG:= \
+CONFIG_IP_VS \
+CONFIG_IP_VS_IPV6=y \
+CONFIG_IP_VS_DEBUG=n \
+CONFIG_IP_VS_PROTO_TCP=y \
+CONFIG_IP_VS_PROTO_UDP=y \
+CONFIG_IP_VS_PROTO_AH_ESP=y \
+CONFIG_IP_VS_PROTO_ESP=y \
+CONFIG_IP_VS_PROTO_AH=y \
+CONFIG_IP_VS_PROTO_SCTP=y \
+CONFIG_IP_VS_TAB_BITS=12 \
+CONFIG_IP_VS_RR \
+CONFIG_IP_VS_WRR \
+CONFIG_IP_VS_LC \
+CONFIG_IP_VS_WLC \
+CONFIG_IP_VS_FO \
+CONFIG_IP_VS_OVF \
+CONFIG_IP_VS_LBLC \
+CONFIG_IP_VS_LBLCR \
+CONFIG_IP_VS_DH \
+CONFIG_IP_VS_SH \
+CONFIG_IP_VS_SED \
+CONFIG_IP_VS_NQ \
+CONFIG_IP_VS_SH_TAB_BITS=8 \
+CONFIG_IP_VS_NFCT=n \
+CONFIG_IP_VS_FTP=m \
+CONFIG_NETFILTER_XT_MATCH_IPVS=n
+
+  FILES:=$(foreach
mod,$(IPVS_K3_MODULES),$(LINUX_DIR)/net/netfilter/ipvs/$(mod).ko)

^ line wrapping, there are various more of these below.
additionally you sent this in some obscure way leading to patchwork
mangling it -> https://patchwork.ozlabs.org/patch/729538/

please fix and resend a properly formatted patch so that we can review it.

John


+  $(call AddDepends/ipt,+kmod-ipt-conntrack)
+endef
+$(eval $(call KernelPackage,nf-ipvs))
+
+define KernelPackage/nf-ipvs/description
+ IPVS (IP Virtual Server) implements transport-layer load balancing
inside the Linux kernel
+ so called Layer-4 switching.
+endef
+
+IPVS_K4_MODULES:= \
+ip_vs \
+ip_vs_lc \
+ip_vs_wlc \
+ip_vs_rr \
+ip_vs_wrr \
+ip_vs_lblc \
+ip_vs_lblcr \
+ip_vs_dh \
+ip_vs_sh \
+ip_vs_fo \
+ip_vs_nq \
+ip_vs_sed
+
+define KernelPackage/nf-ipvs
+  SUBMENU:=Netfilter Extensions
+  TITLE:=IP Virtual Server modules
+  DEPENDS:=+kmod-lib-crc32c @!(LINUX_3_18)
+  KCONFIG:= \
+CONFIG_IP_VS \
+CONFIG_IP_VS_IPV6=y \
+CONFIG_IP_VS_DEBUG=n \
+CONFIG_IP_VS_PROTO_TCP=y \
+CONFIG_IP_VS_PROTO_UDP=y \
+CONFIG_IP_VS_PROTO_AH_ESP=y \
+CONFIG_IP_VS_PROTO_ESP=y \
+CONFIG_IP_VS_PROTO_AH=y \
+CONFIG_IP_VS_PROTO_SCTP=y \
+CONFIG_IP_VS_TAB_BITS=12 \
+CONFIG_IP_VS_RR \
+CONFIG_IP_VS_WRR \
+CONFIG_IP_VS_LC \
+CONFIG_IP_VS_WLC \
+CONFIG_IP_VS_FO \
+CONFIG_IP_VS_OVF \
+CONFIG_IP_VS_LBLC \
+CONFIG_IP_VS_LBLCR \
+CONFIG_IP_VS_DH \
+CONFIG_IP_VS_SH \
+CONFIG_IP_VS_SED \
+CONFIG_IP_VS_NQ \
+CONFIG_IP_VS_SH_TAB_BITS=8 \
+CONFIG_IP_VS_NFCT=n \
+CONFIG_NETFILTER_XT_MATCH_IPVS=n
+
+  FILES:=$(foreach
mod,$(IPVS_K4_MODULES),$(LINUX_DIR)/net/netfilter/ipvs/$(mod).ko)
+  $(call AddDepends/ipt,+kmod-ipt-conntrack)
+endef
+$(eval $(call KernelPackage,nf-ipvs))
+
+define KernelPackage/nf-ipvs/description
+ IPVS (IP Virtual Server) implements transport-layer load 

Re: [LEDE-DEV] Identifying kernel version (major) during build (.mk file)

[Mauro Mozzarelli]

Jonas,


There is in some cases where kernel drivers have changed. As you might 
see in the ip_vs patch I posted, kernel drivers differ in Kernel 3 and 4 
and thus it is necessary to know which kernel I am building for to 
select the appropriate kernel configuration.


If the granularity requires to specify the patchlevel, and if LEDE had 
more than one Kernel 3 patchlevel instead of just 3_18, then I would 
have to specify all of them in my makefile. Not only that, but also I 
would have to modify my makefile to include new Kernel 3 versions should 
they be added in future to the LEDE build.



Mauro


On 20/02/17 09:40, Jonas Gorski wrote:

On 19 February 2017 at 12:50, Mauro Mozzarelli  wrote:

Thanks to those who provided directions.

I will settle with checking on LINUX_3_18.

I am not sure who manages build variables, but in future it would be useful
to be able to identify which kernel major version we are building for.

Major version has no real meaning, what was expected to become 3.20
Linus decided to name 4.0, but the amount of changes between 3.19 and
4.0 were not significantly larger or more radical than the changes
between 3.18 and 3.19, or 4.0 and 4.1. IIRC the main reason for
increasing the major version was to keep the minor version from
growing too large.

So I don't think there is really anything to be gained by being able
to explicitly tell 3.x and 4.x (or 4.x and 5.x etc) apart.

Regards
Jonas



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

[LEDE-DEV] [wiki]Table of packages is officially live!

[Alberto Bursi]

The wiki feature showing what packages are in LEDE (and some information 
about them) is now complete! Hooray! :)

https://lede-project.org/packages/start

The packages in the table/indexes are updated automatically from sources 
every sunday.

It is currently tracking Snapshot, will also track Releases when available.

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

Re: [LEDE-DEV] [PATCH] ar71xx: fix vlan settings for some boards

[John Crispin]

On 20/02/2017 19:31, Piotr Dymacz wrote:
> Hello,
> 
> 2017-02-20 13:11 GMT+01:00 Conor O'Gorman :
>> On 18/02/17 14:32, Weijie Gao wrote:
>>>
>>> For AR71XX devices, GMAC1 always connects port 0 of the built-in switch,
>>> as the CPU port.
>>>
>>> This patch sets correct vlan for some devices with wrong settings:
>>> a) mark port 0 as CPU port, tagged
>>> b) reverse port order, marking these ports untagged
>>>
>> This change affects all these boards:
>> dir-615-i1|\
>> omy-g1|\
>> r6100|\
>> smart-300|\
>> tl-mr3420-v2|\
>> tl-wdr6500-v2|\
>> tl-wr841n-v8|\
>> tl-wr940n-v4|\
>> tl-wr941nd-v5|\
>> tl-wr941nd-v6|\
>> wnr1000-v2|\
>> wnr2000-v4|\
>> wnr2200|\
>> wnr612-v2|\
>> wpn824n)
>>
>> Which ones have you tested?
> 
> At least for TL-WR841N v8 and TL-MR3420 v2 switch port mapping should be:
> "0@eth1" "1:lan:4" "2:lan:1" "3:lan:2" "4:lan:3"
> 
> ---
> Cheers,
> Piotr
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

looks like i merged this too early, i had a look at the file beforehand
and concluded that only one board was changed, apparently it was too
early. i'll revert the commit

John

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

Re: [LEDE-DEV] [LEDE DEV][wiki] Login with github

[Thomas Endt]

Hi Baptiste,

jow already fixed this issue with a workaround (see comments in your linked
bug report).

To get this fixed in the OAuth plugin, I created a bug report

https://github.com/cosmocode/dokuwiki-plugin-oauth/issues/45

Regards, Thomas


> -Ursprüngliche Nachricht-
> von Baptiste Jonglez
> Gesendet: Montag, 20. Februar 2017 16:20
> 
> Hi Thomas,
> 
> Is the github login integration supposed to work?  There is a bug
> reported about a 404 error when trying to login:
> 
>   https://bugs.lede-project.org/index.php?do=details_id=531
> 
> Thanks!
> Baptiste
> 
> On Sat, Oct 01, 2016 at 05:25:54PM +0200, Thomas Endt wrote:
> > IIRC it was Martin who proposed to use oAuth to log in to the wiki
> > with github credentials.
> >
> > I installed the oAuth plugin (https://www.dokuwiki.org/plugin:oauth)
> > for this purpose and created an oAuth application with my github
> > account for testing purposes.
> >
> > Since the owner of the application is shown under
> > https://github.com/settings/applications and to avoid a SPOF, the
> > owner of the LEDE-Wiki login application should probably be someone
> other than me.
> > I'm not sure if github organizations (i.e. lede-project) can create
> > oAuth applications. Can someone of the devs please try?
> >
> >  Things to enter in https://github.com/settings/applications/new
> >
> > Application name: LEDE wiki login
> > Homepage URL: https://wiki.lede-project.org/doku.php
> > Application description : Log in to the LEDE wiki with your
> github account.
> > Authorization callback URL  : https://wiki.lede-project.org/doku.php
> >
> > After successful creation of the application, the "Client ID" and
> > "Client Secret" need to be entered in the oAuth config of the wiki (-
> >
> > admin -> config -> oAuth). You can either do this yourself or let me
> know.
> >
> > To use the login via github, the user needs to update his wiki
> profile
> > accordingly:
> > -> Update profile -> Login with other Services -> check Github ->
> save
> >
> > Please let me know your thoughts.
> >
> > Regards,
> > Thomas
> 
> 
> > ___
> > 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

[LEDE-DEV] [PATCH] kmodloader: fix not being able to find some modules

[Nathan Hintz]

kmodloader is using slightly different criteria for ordering the AVL tree
versus what it uses to traverse it.  This sometimes results in not being
able to find some modules.

Reference: https://bugs.lede-project.org/index.php?do=details_id=443

Signed-off-by: Nathan Hintz 
---
 kmodloader.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/kmodloader.c b/kmodloader.c
index 465d3de..8343836 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -985,20 +985,23 @@ out:
return 0;
 }
 
+inline char weight(char c)
+{
+   return c == '_' ? '-' : c;
+}
+
 static int avl_modcmp(const void *k1, const void *k2, void *ptr)
 {
const char *s1 = k1;
const char *s2 = k2;
 
-   while (*s1 && ((*s1 == *s2) ||
-  ((*s1 == '_') && (*s2 == '-')) ||
-  ((*s1 == '-') && (*s2 == '_'
+   while (*s1 && (weight(*s1) == weight(*s2)))
{
s1++;
s2++;
}
 
-   return *(const unsigned char *)s1 - *(const unsigned char *)s2;
+   return (unsigned char)weight(*s1) - (unsigned char)weight(*s2);
 }
 
 int main(int argc, char **argv)
-- 
2.9.3


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

[LEDE-DEV] ./scripts/feeds install modules.mk not included

[Mehrtens, Hauke]

When I install a target from a feed the kernel packages from the modules.mk of 
the target are not automatically available in LEDE. I have to remove this file  
tmp/info/.packageinfo-kernel_linux , then it gets regenerated in the next make 
run and it contains the new packages for the target's modules.mk. 

I have looked into the feed script but haven't understood where I should add my 
code so that the cache gets purged and regenerated later on, should I just 
delete this file always when a new target was added from a feed?

Hauke Mehrtens
Intel Connected Home Division (CHD)

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

[LEDE-DEV] [PATCH] build: unsilence move command

[Thomas Reifferscheid]

The @ sign in front of the "mv" command was significantly suppressing
output to stdout. When reviewing the make/build logs it was tricking
me a whole lot and it mad me lose time. Removing the @ sign will get
stdout and logs right about what happened when.

Signed-off-by: Thomas Reifferscheid 
---
 include/image-commands.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 49e4389..c513f19 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -8,7 +8,7 @@ define Build/uImage
-O linux -T kernel \
-C $(1) -a $(KERNEL_LOADADDR) -e $(if 
$(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
-n '$(if $(UIMAGE_NAME),$(UIMAGE_NAME),$(call 
toupper,$(LINUX_KARCH)) LEDE Linux-$(LINUX_VERSION))' -d $@ $@.new
-   @mv $@.new $@
+   mv $@.new $@
 endef
 
 define Build/buffalo-enc
-- 
2.1.4


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

[LEDE-DEV] [PATCH] [17.01] dnsmasq: Add upstream patch fixing SERVFAIL issues with multiple servers

[Baptiste Jonglez]

From: Baptiste Jonglez 

This fixes FS#391 for lede-17.01

Signed-off-by: Baptiste Jonglez 
---
 .../patches/000-fix-servfail-handling.patch| 130 +
 1 file changed, 130 insertions(+)
 create mode 100644 
package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch

diff --git 
a/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch 
b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
new file mode 100644
index 00..e311c34729
--- /dev/null
+++ b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
@@ -0,0 +1,130 @@
+From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
+From: Baptiste Jonglez 
+Date: Mon, 6 Feb 2017 21:09:11 +
+Subject: [PATCH] Stop treating SERVFAIL as a successful response from upstream
+ servers.
+
+This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
+error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
+SERVFAIL) as an unsuccessful upstream response").
+
+With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
+upstream server, it stops trying to resolve the query and simply returns
+SERVFAIL to the client.  With this commit, dnsmasq will instead try to
+query other upstream servers upon receiving a SERVFAIL response.
+
+According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
+temporary error condition.  Recursive resolvers are expected to encounter
+network or resources issues from time to time, and will respond with
+SERVFAIL in this case.  Similarly, if a validating DNSSEC resolver [RFC
+4033] encounters issues when checking signatures (unknown signing
+algorithm, missing signatures, expired signatures because of a wrong
+system clock, etc), it will respond with SERVFAIL.
+
+Note that all those behaviours are entirely different from a negative
+response, which would provide a definite indication that the requested
+name does not exist.  In our case, if an upstream server responds with
+SERVFAIL, another upstream server may well provide a positive answer for
+the same query.
+
+Thus, this commit will increase robustness whenever some upstream servers
+encounter temporary issues or are misconfigured.
+
+Quoting RFC 1034, Section 4.3.1. "Queries and responses":
+
+If recursive service is requested and available, the recursive response
+to a query will be one of the following:
+
+   - The answer to the query, possibly preface by one or more CNAME
+ RRs that specify aliases encountered on the way to an answer.
+
+   - A name error indicating that the name does not exist.  This
+ may include CNAME RRs that indicate that the original query
+ name was an alias for a name which does not exist.
+
+   - A temporary error indication.
+
+Here is Section 5.2.3. of RFC 1034, "Temporary failures":
+
+In a less than perfect world, all resolvers will occasionally be unable
+to resolve a particular request.  This condition can be caused by a
+resolver which becomes separated from the rest of the network due to a
+link failure or gateway problem, or less often by coincident failure or
+unavailability of all servers for a particular domain.
+
+And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
+widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
+
+RCODE   Response code - this 4 bit field is set as part of
+responses.  The values have the following
+interpretation:
+(...)
+
+2   Server failure - The name server was
+unable to process this query due to a
+problem with the name server.
+
+For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
+Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
+
+A validating resolver can determine the following 4 states:
+(...)
+
+Insecure: The validating resolver has a trust anchor, a chain of
+   trust, and, at some delegation point, signed proof of the
+   non-existence of a DS record.  This indicates that subsequent
+   branches in the tree are provably insecure.  A validating resolver
+   may have a local policy to mark parts of the domain space as
+   insecure.
+
+Bogus: The validating resolver has a trust anchor and a secure
+   delegation indicating that subsidiary data is signed, but the
+   response fails to validate for some reason: missing signatures,
+   expired signatures, signatures with unsupported algorithms, data
+   missing that the relevant NSEC RR says should be present, and so
+   forth.
+(...)
+
+This specification only defines how security-aware name servers can
+signal non-validating stub resolvers that 

Re: [LEDE-DEV] [PATCH] dnsmasq: Add upstream patch fixing SERVFAIL issues with multiple servers

[Baptiste Jonglez]

Sorry, I forgot to add the 17.01 tag.  I am resending it with the proper tag.

On Mon, Feb 20, 2017 at 04:48:49PM +0100, Baptiste Jonglez wrote:
> From: Baptiste Jonglez 
> 
> This fixes FS#391 for lede-17.01
> 
> Signed-off-by: Baptiste Jonglez 
> ---
>  .../patches/000-fix-servfail-handling.patch| 130 
> +
>  1 file changed, 130 insertions(+)
>  create mode 100644 
> package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
> 
> diff --git 
> a/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch 
> b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
> new file mode 100644
> index 00..e311c34729
> --- /dev/null
> +++ b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
> @@ -0,0 +1,130 @@
> +From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
> +From: Baptiste Jonglez 
> +Date: Mon, 6 Feb 2017 21:09:11 +
> +Subject: [PATCH] Stop treating SERVFAIL as a successful response from 
> upstream
> + servers.
> +
> +This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
> +error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
> +SERVFAIL) as an unsuccessful upstream response").
> +
> +With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
> +upstream server, it stops trying to resolve the query and simply returns
> +SERVFAIL to the client.  With this commit, dnsmasq will instead try to
> +query other upstream servers upon receiving a SERVFAIL response.
> +
> +According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
> +temporary error condition.  Recursive resolvers are expected to encounter
> +network or resources issues from time to time, and will respond with
> +SERVFAIL in this case.  Similarly, if a validating DNSSEC resolver [RFC
> +4033] encounters issues when checking signatures (unknown signing
> +algorithm, missing signatures, expired signatures because of a wrong
> +system clock, etc), it will respond with SERVFAIL.
> +
> +Note that all those behaviours are entirely different from a negative
> +response, which would provide a definite indication that the requested
> +name does not exist.  In our case, if an upstream server responds with
> +SERVFAIL, another upstream server may well provide a positive answer for
> +the same query.
> +
> +Thus, this commit will increase robustness whenever some upstream servers
> +encounter temporary issues or are misconfigured.
> +
> +Quoting RFC 1034, Section 4.3.1. "Queries and responses":
> +
> +If recursive service is requested and available, the recursive response
> +to a query will be one of the following:
> +
> +   - The answer to the query, possibly preface by one or more CNAME
> + RRs that specify aliases encountered on the way to an answer.
> +
> +   - A name error indicating that the name does not exist.  This
> + may include CNAME RRs that indicate that the original query
> +   name was an alias for a name which does not exist.
> +
> +   - A temporary error indication.
> +
> +Here is Section 5.2.3. of RFC 1034, "Temporary failures":
> +
> +In a less than perfect world, all resolvers will occasionally be unable
> +to resolve a particular request.  This condition can be caused by a
> +resolver which becomes separated from the rest of the network due to a
> +link failure or gateway problem, or less often by coincident failure or
> +unavailability of all servers for a particular domain.
> +
> +And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
> +widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
> +
> +RCODE   Response code - this 4 bit field is set as part of
> +responses.  The values have the following
> +interpretation:
> +(...)
> +
> +2   Server failure - The name server was
> +unable to process this query due to a
> +problem with the name server.
> +
> +For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
> +Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
> +
> +A validating resolver can determine the following 4 states:
> +(...)
> +
> +Insecure: The validating resolver has a trust anchor, a chain of
> +   trust, and, at some delegation point, signed proof of the
> +   non-existence of a DS record.  This indicates that subsequent
> +   branches in the tree are provably insecure.  A validating resolver
> +   may have a local policy to mark parts of the domain space as
> +   insecure.
> +
> +Bogus: The validating resolver has a trust anchor and a secure
> +   delegation indicating that subsidiary data is signed, but the
> +   

[LEDE-DEV] [PATCH] dnsmasq: Add upstream patch fixing SERVFAIL issues with multiple servers

[Baptiste Jonglez]

From: Baptiste Jonglez 

This fixes FS#391 for lede-17.01

Signed-off-by: Baptiste Jonglez 
---
 .../patches/000-fix-servfail-handling.patch| 130 +
 1 file changed, 130 insertions(+)
 create mode 100644 
package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch

diff --git 
a/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch 
b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
new file mode 100644
index 00..e311c34729
--- /dev/null
+++ b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
@@ -0,0 +1,130 @@
+From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
+From: Baptiste Jonglez 
+Date: Mon, 6 Feb 2017 21:09:11 +
+Subject: [PATCH] Stop treating SERVFAIL as a successful response from upstream
+ servers.
+
+This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
+error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
+SERVFAIL) as an unsuccessful upstream response").
+
+With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
+upstream server, it stops trying to resolve the query and simply returns
+SERVFAIL to the client.  With this commit, dnsmasq will instead try to
+query other upstream servers upon receiving a SERVFAIL response.
+
+According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
+temporary error condition.  Recursive resolvers are expected to encounter
+network or resources issues from time to time, and will respond with
+SERVFAIL in this case.  Similarly, if a validating DNSSEC resolver [RFC
+4033] encounters issues when checking signatures (unknown signing
+algorithm, missing signatures, expired signatures because of a wrong
+system clock, etc), it will respond with SERVFAIL.
+
+Note that all those behaviours are entirely different from a negative
+response, which would provide a definite indication that the requested
+name does not exist.  In our case, if an upstream server responds with
+SERVFAIL, another upstream server may well provide a positive answer for
+the same query.
+
+Thus, this commit will increase robustness whenever some upstream servers
+encounter temporary issues or are misconfigured.
+
+Quoting RFC 1034, Section 4.3.1. "Queries and responses":
+
+If recursive service is requested and available, the recursive response
+to a query will be one of the following:
+
+   - The answer to the query, possibly preface by one or more CNAME
+ RRs that specify aliases encountered on the way to an answer.
+
+   - A name error indicating that the name does not exist.  This
+ may include CNAME RRs that indicate that the original query
+ name was an alias for a name which does not exist.
+
+   - A temporary error indication.
+
+Here is Section 5.2.3. of RFC 1034, "Temporary failures":
+
+In a less than perfect world, all resolvers will occasionally be unable
+to resolve a particular request.  This condition can be caused by a
+resolver which becomes separated from the rest of the network due to a
+link failure or gateway problem, or less often by coincident failure or
+unavailability of all servers for a particular domain.
+
+And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
+widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
+
+RCODE   Response code - this 4 bit field is set as part of
+responses.  The values have the following
+interpretation:
+(...)
+
+2   Server failure - The name server was
+unable to process this query due to a
+problem with the name server.
+
+For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
+Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
+
+A validating resolver can determine the following 4 states:
+(...)
+
+Insecure: The validating resolver has a trust anchor, a chain of
+   trust, and, at some delegation point, signed proof of the
+   non-existence of a DS record.  This indicates that subsequent
+   branches in the tree are provably insecure.  A validating resolver
+   may have a local policy to mark parts of the domain space as
+   insecure.
+
+Bogus: The validating resolver has a trust anchor and a secure
+   delegation indicating that subsidiary data is signed, but the
+   response fails to validate for some reason: missing signatures,
+   expired signatures, signatures with unsupported algorithms, data
+   missing that the relevant NSEC RR says should be present, and so
+   forth.
+(...)
+
+This specification only defines how security-aware name servers can
+signal non-validating stub resolvers that 

Re: [LEDE-DEV] kmod-ebtables: install fails

[yanosz]

Hello,

Am 02/20/2017 um 04:09 PM schrieb Baptiste Jonglez:
> On Sun, Feb 19, 2017 at 01:48:04PM +0100, yanosz wrote:
>> Hello,
>>
>> I've some trouble installing kmod-ebtables on lede 17.01 rc2.
>>
>> root@Node-2:/etc/config# opkg install kmod-ebtables
>> Package kmod-ebtables (4.4.47-1) installed in root is up to date.
> 
> It looks like kmod-ebtables is already installed in your system?

well ... didn't install it.

On a fresh 17.02 rc I did:
$ ssh node
Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.


BusyBox v1.25.1 () built-in shell (ash)

 _
//\  ____ ___  ___
   /  LE/  \| |  | __|   \| __|
  /DE  /\   | |__| _|| |) | _|
 //  LE  \  ||___|___/|___|
lede-project.org
 \\   DE /
  \LE  \/
---
   \  DE\  /Reboot (17.01.0-rc2, r3131-42f3c1f)
\\/
---

=== WARNING! =
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--
root@LEDE:~# opkg update
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/targets/ar71xx/generic/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_core
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/targets/ar71xx/generic/packages/Packages.sig
Signature check passed.
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/base/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_base
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/base/Packages.sig
Signature check passed.
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_luci
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/luci/Packages.sig
Signature check passed.
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_packages
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/packages/Packages.sig
Signature check passed.
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_routing
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/routing/Packages.sig
Signature check passed.
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_telephony
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/telephony/Packages.sig
Signature check passed.
root@LEDE:~# opkg install ebtables
Installing ebtables (2.0.10-4-5) to root...
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/packages/mips_24kc/base/ebtables_2.0.10-4-5_mips_24kc.ipk
Installing kmod-ebtables (4.4.47-1) to root...
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/targets/ar71xx/generic/packages/kmod-ebtables_4.4.47-1_mips_24kc.ipk
Installing kmod-bridge (4.4.47-1) to root...
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/targets/ar71xx/generic/packages/kmod-bridge_4.4.47-1_mips_24kc.ipk
Installing kmod-stp (4.4.47-1) to root...
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/targets/ar71xx/generic/packages/kmod-stp_4.4.47-1_mips_24kc.ipk
Installing kmod-llc (4.4.47-1) to root...
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/targets/ar71xx/generic/packages/kmod-llc_4.4.47-1_mips_24kc.ipk
Installing kmod-br-netfilter (4.4.47-1) to root...
Downloading
http://downloads.lede-project.org/releases/17.01.0-rc2/targets/ar71xx/generic/packages/kmod-br-netfilter_4.4.47-1_mips_24kc.ipk
Configuring kmod-llc.
Configuring kmod-stp.
Configuring kmod-bridge.
Configuring kmod-br-netfilter.
Configuring kmod-ebtables.
ebtable_broute is already loaded
ebtable_filter is already loaded
ebtable_nat is already loaded
ebt_802_3 is already loaded
ebt_among is already loaded
ebt_limit is already loaded
ebt_mark_m is already loaded
ebt_pkttype is already loaded
ebt_stp is already loaded
ebt_vlan is already loaded
ebt_mark is already loaded
ebt_redirect is already loaded
Configuring ebtables.
Collected errors:
 * pkg_run_script: package "kmod-ebtables" postinst script returned
status 255.
 * opkg_configure: kmod-ebtables.postinst returned 255.


-- 
For those of you without hope, we have rooms with color TV,
cable and air conditioning

[LEDE-DEV] image-commands.mk: remove at-sign for mv

[Thomas Reifferscheid]

This is my first post to lede-dev, so hi everybody!

Please submit the attached patch. The @ sign in front of the "mv" 
command was significantly delaying the output to stdout.
When reviewing the make/build logs it was tricking me a whole lot and it 
mad me lose time. Removing the @ sign will get stdout and logs right 
about what happened when.


Please let me know your thoughts. Thank you.

Regards
Thomas


--
Thomas Reifferscheid
Krauskopfallee 39
D-65388 Schlangenbad
Tel.: +49 175 268 9153

--- lede-trunk/include/image-commands.mk.orig   2017-02-20 15:37:49.623129613 
+0100
+++ lede-trunk/include/image-commands.mk2017-02-20 15:38:07.427130154 
+0100
@@ -8,7 +8,7 @@
-O linux -T kernel \
-C $(1) -a $(KERNEL_LOADADDR) -e $(if 
$(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
-n '$(if $(UIMAGE_NAME),$(UIMAGE_NAME),$(call 
toupper,$(LINUX_KARCH)) LEDE Linux-$(LINUX_VERSION))' -d $@ $@.new
-   @mv $@.new $@
+   mv $@.new $@
 endef
 
 define Build/buffalo-enc
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [LEDE DEV][wiki] Login with github

[Baptiste Jonglez]

Hi Thomas,

Is the github login integration supposed to work?  There is a bug reported
about a 404 error when trying to login:

  https://bugs.lede-project.org/index.php?do=details_id=531

Thanks!
Baptiste

On Sat, Oct 01, 2016 at 05:25:54PM +0200, Thomas Endt wrote:
> IIRC it was Martin who proposed to use oAuth to log in to the wiki with
> github credentials.
> 
> I installed the oAuth plugin (https://www.dokuwiki.org/plugin:oauth) for
> this purpose and created an oAuth application with my github account for
> testing purposes.
> 
> Since the owner of the application is shown under
> https://github.com/settings/applications and to avoid a SPOF, the owner of
> the LEDE-Wiki login application should probably be someone other than me.
> I'm not sure if github organizations (i.e. lede-project) can create oAuth
> applications. Can someone of the devs please try?
> 
>  Things to enter in https://github.com/settings/applications/new
> 
> Application name  : LEDE wiki login
> Homepage URL  : https://wiki.lede-project.org/doku.php
> Application description   : Log in to the LEDE wiki with your github 
> account.
> Authorization callback URL: https://wiki.lede-project.org/doku.php
> 
> After successful creation of the application, the "Client ID" and "Client
> Secret" need to be entered in the oAuth config of the wiki (-> admin ->
> config -> oAuth). You can either do this yourself or let me know.
> 
> To use the login via github, the user needs to update his wiki profile
> accordingly:
> -> Update profile -> Login with other Services -> check Github -> save
> 
> Please let me know your thoughts.
> 
> Regards,
> Thomas


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



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

Re: [LEDE-DEV] kmod-ebtables: install fails

[Baptiste Jonglez]

On Sun, Feb 19, 2017 at 01:48:04PM +0100, yanosz wrote:
> Hello,
> 
> I've some trouble installing kmod-ebtables on lede 17.01 rc2.
> 
> root@Node-2:/etc/config# opkg install kmod-ebtables
> Package kmod-ebtables (4.4.47-1) installed in root is up to date.

It looks like kmod-ebtables is already installed in your system?

> Configuring kmod-ebtables.
> ebtable_broute is already loaded
> ebtable_filter is already loaded
> ebtable_nat is already loaded
> ebt_802_3 is already loaded
> ebt_among is already loaded
> ebt_limit is already loaded
> ebt_mark_m is already loaded
> ebt_pkttype is already loaded
> ebt_stp is already loaded
> ebt_vlan is already loaded
> ebt_mark is already loaded
> ebt_redirect is already loaded
> Collected errors:
>  * pkg_run_script: package "kmod-ebtables" postinst script returned
> status 255.
>  * opkg_configure: kmod-ebtables.postinst returned 255.
> 
> uname -a
> root@Node-2:/etc/config# uname -a
> Linux Node-2 4.4.47 #0 Mon Feb 6 21:34:28 2017 mips GNU/Linux
> 
> I don't know what went wrong .. ebtables looks usable ... It seems like
> kmod-ebtables is suprised by its modules already been loaded ...
> 
> Greetz, yanosz




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



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

[LEDE-DEV] [PATCH] ar71xx: WNDR4300: Fix network vlan IDs

[Daniel Gonzalez Cabanelas]

The Netgear WNDR4300 has the VLAN IDs flipped in LuCi, fix it.


Signed-off-by: Daniel Gonzalez Cabanelas 
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index e08d7dd..a55e50a 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -254,8 +254,7 @@ ar71xx_setup_interfaces()
esr900|\
mynet-n750|\
sr3200|\
-   wndr3700v4|\
-   wndr4300)
+   wndr3700v4)
ucidef_add_switch "switch0" \
"0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan"
;;
@@ -334,7 +333,8 @@ ar71xx_setup_interfaces()
dir-869-a1|\
epg5000|\
esr1750|\
-   tl-wr1043nd-v4)
+   tl-wr1043nd-v4|\
+   wndr4300)
ucidef_add_switch "switch0" \
"0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "5:wan"
;;


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

Re: [LEDE-DEV] [PATCH] ar71xx: fix vlan settings for some boards

[Conor O'Gorman]

On 18/02/17 14:32, Weijie Gao wrote:

For AR71XX devices, GMAC1 always connects port 0 of the built-in switch,
as the CPU port.

This patch sets correct vlan for some devices with wrong settings:
a) mark port 0 as CPU port, tagged
b) reverse port order, marking these ports untagged


This change affects all these boards:
dir-615-i1|\
omy-g1|\
r6100|\
smart-300|\
tl-mr3420-v2|\
tl-wdr6500-v2|\
tl-wr841n-v8|\
tl-wr940n-v4|\
tl-wr941nd-v5|\
tl-wr941nd-v6|\
wnr1000-v2|\
wnr2000-v4|\
wnr2200|\
wnr612-v2|\
wpn824n)

Which ones have you tested?

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

[LEDE-DEV] [PATCH] procd.sh: use parrameterized respawn values

[Claudiu Brasovean]

Signed-off-by: Claudiu Brasovean 
---
 package/system/procd/files/procd.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/system/procd/files/procd.sh 
b/package/system/procd/files/procd.sh
index 6347de5..9fbf47e 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -351,8 +351,10 @@ _procd_close_instance() {
if json_select respawn ; then
json_get_values respawn_vals
if [ -z "$respawn_vals" ]; then
+   local respawn_threshold=$(uci_get 
system.@service[0].respawn_threshold)
+   local respawn_timeout=$(uci_get 
system.@service[0].respawn_timeout)
local respawn_retry=$(uci_get 
system.@service[0].respawn_retry)
-   _procd_add_array_data 3600 5 ${respawn_retry:-5}
+   _procd_add_array_data ${respawn_threshold:-3600} 
${respawn_timeout:-5} ${respawn_retry:-5}
fi
json_select ..
fi
-- 
2.1.4


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

[LEDE-DEV] [PATCH packages] lighttpd: update to 1.4.45

[Rafał Miłecki]

From: Rafał Miłecki 

Update to 1.4.42 introduced a problem with starting lighttpd as
OpenWrt/LEDE service. It was stopping whole init process at sth like:
  783 root  1124 S{S50lighttpd} /bin/sh /etc/rc.common 
/etc/rc.d/S50lighttpd boot
  799 root  1164 S/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

It was hanging until getting random pool:
[  176.340007] random: nonblocking pool is initialized
and then immediately the rest of init process followed:
[  176.423475] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[  176.430754] jffs2_build_filesystem(): unlocking the mtd device... done.
[  176.437615] jffs2_build_filesystem(): erasing all blocks after the end 
marker... done.

This was fixed in 1.4.44, but bump directly to 1.4.45 while at it.

Signed-off-by: Rafał Miłecki 
---
I think it's also a good candidate for 17.01.
---
 net/lighttpd/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/lighttpd/Makefile b/net/lighttpd/Makefile
index 1c17cefb..64b8500f 100644
--- a/net/lighttpd/Makefile
+++ b/net/lighttpd/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=lighttpd
-PKG_VERSION:=1.4.42
-PKG_RELEASE:=2
+PKG_VERSION:=1.4.45
+PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://download.lighttpd.net/lighttpd/releases-1.4.x
-PKG_MD5SUM:=53c55d7e1dac7adec161cd5490491f6d
+PKG_MD5SUM:=a128e1eda76899ce3fd115efae5fe631
 
 PKG_LICENSE:=BSD-3c
 PKG_LICENSE_FILES:=COPYING
-- 
2.11.0


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

Re: [LEDE-DEV] need help / info [httpd/apache]

[Bastian Bittorf]

* Denis Periša  [20.02.2017 09:06]:
> Is there any other httpd that supports php and 404 error pages?

the "builtin" server 'uhttpd' supports both.
read the wiki about uci/uhttpd.

bye, bastian

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

Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing capabilities

[Jonas Gorski]

On 19 February 2017 at 13:01, Mauro Mozzarelli  wrote:
> Author: Mauro Mozzarelli 
> Date:   Sun Feb 19 11:33:23 2017 +
>
> IPVS (IP Virtual Server) implements transport-layer load balancing
> inside the Linux kernel, so called Layer-4 switching. IPVS running on a host
> acts as a load balancer at the front of a cluster of real servers, it can
> direct requests for TCP/UDP based services to the real servers, and makes
> services of the real servers to appear as a virtual service on a single IP
> address.
>
> This patch adds kmod-nf-ipvs kernel modules option to LEDE kernel
> netfilter
>
> Signed-off-by: Mauro Mozzarelli 
>
> diff --git a/package/kernel/linux/modules/netfilter.mk
> b/package/kernel/linux/modules/netfilter.mk
> index 6162dbc..7c51d9f 100644
> --- a/package/kernel/linux/modules/netfilter.mk
> +++ b/package/kernel/linux/modules/netfilter.mk
> @@ -271,6 +271,117 @@ define KernelPackage/ipt-ipset
>  endef
>  $(eval $(call KernelPackage,ipt-ipset))
>
> +IPVS_K3_MODULES:= \
> +ip_vs \
> +ip_vs_lc \
> +ip_vs_wlc \
> +ip_vs_rr \
> +ip_vs_wrr \
> +ip_vs_lblc \
> +ip_vs_lblcr \
> +ip_vs_dh \
> +ip_vs_sh \
> +ip_vs_fo \
> +ip_vs_nq \
> +ip_vs_sed \
> +ip_vs_ftp

(snip)

> +IPVS_K4_MODULES:= \
> +ip_vs \
> +ip_vs_lc \
> +ip_vs_wlc \
> +ip_vs_rr \
> +ip_vs_wrr \
> +ip_vs_lblc \
> +ip_vs_lblcr \
> +ip_vs_dh \
> +ip_vs_sh \
> +ip_vs_fo \
> +ip_vs_nq \
> +ip_vs_sed

These seem mostly the same, the only difference is ip_vs_ftp in 3.18.
You can annotate the FILES with kernel versions, e.g.
ip_vs_ftp.ko@lt4.0" would mean "copy this file only if kernel version
is less than 4.0". That way you should be able to just have one
KernelPackage definition.


Regards
Jonas

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

Re: [LEDE-DEV] Identifying kernel version (major) during build (.mk file)

[Jonas Gorski]

On 19 February 2017 at 12:50, Mauro Mozzarelli  wrote:
> Thanks to those who provided directions.
>
> I will settle with checking on LINUX_3_18.
>
> I am not sure who manages build variables, but in future it would be useful
> to be able to identify which kernel major version we are building for.

Major version has no real meaning, what was expected to become 3.20
Linus decided to name 4.0, but the amount of changes between 3.19 and
4.0 were not significantly larger or more radical than the changes
between 3.18 and 3.19, or 4.0 and 4.1. IIRC the main reason for
increasing the major version was to keep the minor version from
growing too large.

So I don't think there is really anything to be gained by being able
to explicitly tell 3.x and 4.x (or 4.x and 5.x etc) apart.

Regards
Jonas

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

Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing capabilities

[John Crispin]

Hi,

comments inline

On 19/02/2017 13:01, Mauro Mozzarelli wrote:
> Author: Mauro Mozzarelli 
> Date:   Sun Feb 19 11:33:23 2017 +
> 
> IPVS (IP Virtual Server) implements transport-layer load balancing

^ stray tab

> inside the Linux kernel, so called Layer-4 switching. IPVS running on a
> host acts as a load balancer at the front of a cluster of real servers,
> it can direct requests for TCP/UDP based services to the real servers,
> and makes services of the real servers to appear as a virtual service on
> a single IP address.
> 
> This patch adds kmod-nf-ipvs kernel modules option to LEDE kernel

^ stray tab

> netfilter
> 
> Signed-off-by: Mauro Mozzarelli 
> 


^ stray tab and obfuscated mail addr

> diff --git a/package/kernel/linux/modules/netfilter.mk
> b/package/kernel/linux/modules/netfilter.mk
> index 6162dbc..7c51d9f 100644
> --- a/package/kernel/linux/modules/netfilter.mk
> +++ b/package/kernel/linux/modules/netfilter.mk
> @@ -271,6 +271,117 @@ define KernelPackage/ipt-ipset
>  endef
>  $(eval $(call KernelPackage,ipt-ipset))
> 
> +IPVS_K3_MODULES:= \
> +ip_vs \
> +ip_vs_lc \
> +ip_vs_wlc \
> +ip_vs_rr \
> +ip_vs_wrr \
> +ip_vs_lblc \
> +ip_vs_lblcr \
> +ip_vs_dh \
> +ip_vs_sh \
> +ip_vs_fo \
> +ip_vs_nq \
> +ip_vs_sed \
> +ip_vs_ftp
> +
> +define KernelPackage/nf-ipvs
> +  SUBMENU:=Netfilter Extensions
> +  TITLE:=IP Virtual Server modules Kernel 3
> +  DEPENDS:=+kmod-lib-crc32c @(LINUX_3_18)
> +  KCONFIG:= \
> +CONFIG_IP_VS \
> +CONFIG_IP_VS_IPV6=y \
> +CONFIG_IP_VS_DEBUG=n \
> +CONFIG_IP_VS_PROTO_TCP=y \
> +CONFIG_IP_VS_PROTO_UDP=y \
> +CONFIG_IP_VS_PROTO_AH_ESP=y \
> +CONFIG_IP_VS_PROTO_ESP=y \
> +CONFIG_IP_VS_PROTO_AH=y \
> +CONFIG_IP_VS_PROTO_SCTP=y \
> +CONFIG_IP_VS_TAB_BITS=12 \
> +CONFIG_IP_VS_RR \
> +CONFIG_IP_VS_WRR \
> +CONFIG_IP_VS_LC \
> +CONFIG_IP_VS_WLC \
> +CONFIG_IP_VS_FO \
> +CONFIG_IP_VS_OVF \
> +CONFIG_IP_VS_LBLC \
> +CONFIG_IP_VS_LBLCR \
> +CONFIG_IP_VS_DH \
> +CONFIG_IP_VS_SH \
> +CONFIG_IP_VS_SED \
> +CONFIG_IP_VS_NQ \
> +CONFIG_IP_VS_SH_TAB_BITS=8 \
> +CONFIG_IP_VS_NFCT=n \
> +CONFIG_IP_VS_FTP=m \
> +CONFIG_NETFILTER_XT_MATCH_IPVS=n
> +
> +  FILES:=$(foreach
> mod,$(IPVS_K3_MODULES),$(LINUX_DIR)/net/netfilter/ipvs/$(mod).ko)

^ line wrapping, there are various more of these below.
additionally you sent this in some obscure way leading to patchwork
mangling it -> https://patchwork.ozlabs.org/patch/729538/

please fix and resend a properly formatted patch so that we can review it.

John

> +  $(call AddDepends/ipt,+kmod-ipt-conntrack)
> +endef
> +$(eval $(call KernelPackage,nf-ipvs))
> +
> +define KernelPackage/nf-ipvs/description
> + IPVS (IP Virtual Server) implements transport-layer load balancing
> inside the Linux kernel
> + so called Layer-4 switching.
> +endef
> +
> +IPVS_K4_MODULES:= \
> +ip_vs \
> +ip_vs_lc \
> +ip_vs_wlc \
> +ip_vs_rr \
> +ip_vs_wrr \
> +ip_vs_lblc \
> +ip_vs_lblcr \
> +ip_vs_dh \
> +ip_vs_sh \
> +ip_vs_fo \
> +ip_vs_nq \
> +ip_vs_sed
> +
> +define KernelPackage/nf-ipvs
> +  SUBMENU:=Netfilter Extensions
> +  TITLE:=IP Virtual Server modules
> +  DEPENDS:=+kmod-lib-crc32c @!(LINUX_3_18)
> +  KCONFIG:= \
> +CONFIG_IP_VS \
> +CONFIG_IP_VS_IPV6=y \
> +CONFIG_IP_VS_DEBUG=n \
> +CONFIG_IP_VS_PROTO_TCP=y \
> +CONFIG_IP_VS_PROTO_UDP=y \
> +CONFIG_IP_VS_PROTO_AH_ESP=y \
> +CONFIG_IP_VS_PROTO_ESP=y \
> +CONFIG_IP_VS_PROTO_AH=y \
> +CONFIG_IP_VS_PROTO_SCTP=y \
> +CONFIG_IP_VS_TAB_BITS=12 \
> +CONFIG_IP_VS_RR \
> +CONFIG_IP_VS_WRR \
> +CONFIG_IP_VS_LC \
> +CONFIG_IP_VS_WLC \
> +CONFIG_IP_VS_FO \
> +CONFIG_IP_VS_OVF \
> +CONFIG_IP_VS_LBLC \
> +CONFIG_IP_VS_LBLCR \
> +CONFIG_IP_VS_DH \
> +CONFIG_IP_VS_SH \
> +CONFIG_IP_VS_SED \
> +CONFIG_IP_VS_NQ \
> +CONFIG_IP_VS_SH_TAB_BITS=8 \
> +CONFIG_IP_VS_NFCT=n \
> +CONFIG_NETFILTER_XT_MATCH_IPVS=n
> +
> +  FILES:=$(foreach
> mod,$(IPVS_K4_MODULES),$(LINUX_DIR)/net/netfilter/ipvs/$(mod).ko)
> +  $(call AddDepends/ipt,+kmod-ipt-conntrack)
> +endef
> +$(eval $(call KernelPackage,nf-ipvs))
> +
> +define KernelPackage/nf-ipvs/description
> + IPVS (IP Virtual Server) implements transport-layer load balancing
> inside the Linux kernel
> + so called Layer-4 switching.
> +endef
> 
>  define KernelPackage/ipt-nat
>TITLE:=Basic NAT targets
> 
> 
> ___
> 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