[OpenWrt-Devel] New CT firmware images

2018-12-19 Thread Ben Greear

Hello,

New CT FW images are on my site, packaged up for OpenWRT.

The wave-1 firmware has one assert removed.

The wave-2 has 3 crash fixes that users recently reported.  Assuming these stay
fixed, that will fix all recent firmware crashes I have seen lately.

If someone could update OpenWRT makefile and spot-check this, I'd appreciate
it.

Thanks,
Ben

988x
0080035ce21c83ec452cfb4051fe0ec5a1f6cc99c8887bc9cc0b8be54043be72  
firmware-2-ct-full-community-22.bin.lede.002
30dd88647c543486166a72b3ab1b02732048f217518c4d999e94e2cb2d29feaa  
firmware-2-ct-full-htt-mgt-community-22.bin.lede.002
/home/greearb/candela_html/downloads
9887
ba543d0966d4c3ca53a732613ea8aea14b9d3c388792ba914110f8c8609da4c8  
firmware-2-ct-full-community-22.bin.lede.002
7d9e3abbbe12dab13447c96707dcb747c90d0663c7a687352c9bba55e2f4debc  
firmware-2-ct-full-htt-mgt-community-22.bin.lede.002
/home/greearb/candela_html/downloads
9980
1d4fd0c05368efbaa987e903c1f9c88eb594e23db93e36869f9d5016734996d4  
firmware-5-ct-full-community-12.bin-lede.002
435877ebba90224fe3b696c1c459da281230f527ea05c316b7eeceb1a13b5e19  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.002
/home/greearb/candela_html/downloads
9984
b9bbb25f5f6753ca46aeaaf93b6b8d84354b38ef292e4ea6255c627edfb00ad7  
firmware-5-ct-full-community-12.bin-lede.002
15fd6aa58e5bf96bf7232c739c97598b4573bb514974a8969a8fe21eb3015356  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.002
/home/greearb/candela_html/downloads
4019
6ba3a1b883d65546353f4a9246f7e5327922c7c9dfd472c71926737d94cff2db  
firmware-5-ct-full-community-12.bin-lede.002
fe0d0a32d2f04885ec613b2af0402e8b80783fb165265ded988524e8914af0b2  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.002
/home/greearb/candela_html/downloads
9888
46e5bc1e2b3e13f48ef1d81a0927a6053bda1ef18a2acad93da5cc992ffc3e36  
firmware-5-ct-full-community-12.bin-lede.002
7a5f3ef4e906549c3e4cd6e6f4e4c68d777206ed7c9f870c0b2d68b59928883e  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.002

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [RFC PATCH] kernel: drop MIPS: fix cache flushing for highmem pages

2018-12-19 Thread Rosen Penev
On Wed, Dec 19, 2018 at 9:54 AM Kevin 'ldir' Darbyshire-Bryant
 wrote:
>
>
>
> > On 19 Dec 2018, at 09:57, Felix Fietkau  wrote:
> >
> > On 2018-12-18 17:43, Rosen Penev wrote:
> >>>
> >> I've tested removing the patch on a 512MB mt7621 device where HIGHMEM
> >> is used for the second 256MB. No issues.
> > I think to be on the safe side we should test running fuse (ntfs-3g or
> > sshfs or something similar) on such a device. If that doesn't turn up
> > any weird hangs or data corruption within a few minutes of use, I'm all
> > for dropping this patch.
> >
>
> Rosen, is that something you could take a closer look at with your 512MB 
> device?
Just ran a sha256sum on a video file followed by a 10 minute dd read
of the whole drive(interrupted) followed by another sha256sum.

They check out. This was on an ntfs formatted drive mounted by ntfs-3g.
>
> Kevin

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Add support for kernel 4.19

2018-12-19 Thread Daniel Engberg

On 2018-12-09 15:57, Hauke Mehrtens wrote:

Hi Daniel,

On 12/3/18 11:22 AM, Daniel Engberg wrote:

Hi Hauke!

First of all, great work and also thanks to the others who 
contributed!


Thanks for testing this Daniel,

The target code still needs some work, I only added this to test the
generic code.

I gave this a try on my Orange Pi PC (Allwinner H3) and it seems to 
run
fine overall. Ethernet TX is a bit slow (~65mbit using iperf3) while 
RX

does full line speed (~94mbit) more or less and USB also seems to work
as it should.


I used a Xunlong Orange Pi R1 (Allwinner H3) and got 94 Mbits/sec in RX
and TX on both LAN ports (Allwinner MAC and Realtek USB MAC).

CONFIG_REGULATOR_SY8106A=y should probably be added to the kernel 
config

as it's need to make cpufreq usable on this board.


Ok, I will add it.


Looking at Armbian's repo we seem to lack a few kernel options which
might be useful in regards of thermal performance/power consumption.

CONFIG_ARM_CPUIDLE=y
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_DT_IDLE_STATES=y


I think there are still some pull requests open where people want to
backport these features to 4.14, we should probably at least activate
them in the kernel where they are available.

For those using A64/H5 the Armbian repo contains quite a bit of 
patches

which might be worth looking at.
https://github.com/armbian/build/tree/master/patch/kernel/sunxi-dev
It should also be noted that they're using
https://github.com/megous/linux instead of mainline but it seems close
to mainline in general.


I think the non video parts are well supported in mainline by now, is
there something particular interesting this this repository?

Hauke


Hi,

Allwinner H5 SoCs are known to run very hot and they do quite easily
overheat so it's probably a good idea to import cpufreq support 
otherwise

there should at least be a warning at boot that it'll most likely
overheat which in turn will cause a bad user experience.
This also seems to plague the A64 SoC to some extent.

There are also a few patches for nanopi boards which perhaps we should
import?

At least on my board any kind of cpufreq/power management seems to be
disabled by default which might be a good idea to change?

Best regards,
Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-19 Thread Petr Štetiar
Dave Taht  [2018-12-19 04:35:26]:

> Still... "Friends don't let friends run factory firmware".

Sure, that's why there is table of hardware in the wiki and few forum topics
where you can find hardware suitable for your needs and your budget. Or did I
missed something?

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [RFC PATCH] kernel: drop MIPS: fix cache flushing for highmem pages

2018-12-19 Thread Kevin 'ldir' Darbyshire-Bryant



> On 19 Dec 2018, at 09:57, Felix Fietkau  wrote:
> 
> On 2018-12-18 17:43, Rosen Penev wrote:
>>> 
>> I've tested removing the patch on a 512MB mt7621 device where HIGHMEM
>> is used for the second 256MB. No issues.
> I think to be on the safe side we should test running fuse (ntfs-3g or
> sshfs or something similar) on such a device. If that doesn't turn up
> any weird hangs or data corruption within a few minutes of use, I'm all
> for dropping this patch.
> 

Rosen, is that something you could take a closer look at with your 512MB device?

Kevin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH firewall3 2/2] utils: Free args in __fw3_command_pipe()

2018-12-19 Thread Jo-Philipp Wich
Hi,

> Signed-off-by: Hauke Mehrtens 

Acked-by: Jo-Philipp Wich 


~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH firewall3 1/2] options.c, redirects.c: Fix possible buffer overflows

2018-12-19 Thread Jo-Philipp Wich
Hi,

> Signed-off-by: Hauke Mehrtens 

Acked-by: Jo-Philipp Wich 


~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-19 Thread Dave Taht


Still... "Friends don't let friends run factory firmware".


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH firewall3 1/2] options.c, redirects.c: Fix possible buffer overflows

2018-12-19 Thread Hauke Mehrtens
This fixes two possible situations where strncpy() produces a not null
terminated buffer.

Coverity IDs:
* 1412247 Buffer not null terminated
* 1412279 Buffer not null terminated

Signed-off-by: Hauke Mehrtens 
---
 options.c   | 2 +-
 redirects.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/options.c b/options.c
index 5184346..c763d9e 100644
--- a/options.c
+++ b/options.c
@@ -939,7 +939,7 @@ fw3_parse_setmatch(void *ptr, const char *val, bool is_list)
return false;
}
 
-   strncpy(m->name, p, sizeof(m->name));
+   strncpy(m->name, p, sizeof(m->name) - 1);
 
for (i = 0, p = strtok(NULL, " \t,");
 i < 3 && p != NULL;
diff --git a/redirects.c b/redirects.c
index ab95395..97529ee 100644
--- a/redirects.c
+++ b/redirects.c
@@ -154,7 +154,7 @@ resolve_dest(struct uci_element *e, struct fw3_redirect 
*redir,
if (!compare_addr(addr, >ip_redir))
continue;
 
-   strncpy(redir->dest.name, zone->name, 
sizeof(redir->dest.name));
+   strncpy(redir->dest.name, zone->name, 
sizeof(redir->dest.name) - 1);
redir->dest.set = true;
redir->_dest = zone;
 
-- 
2.19.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH firewall3 2/2] utils: Free args in __fw3_command_pipe()

2018-12-19 Thread Hauke Mehrtens
args was not freed after leaving this function.

Fixes Coverity issue 1412470 Resource leak

Signed-off-by: Hauke Mehrtens 
---
 utils.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/utils.c b/utils.c
index 4f892a7..684b2c3 100644
--- a/utils.c
+++ b/utils.c
@@ -252,6 +252,7 @@ __fw3_command_pipe(bool silent, const char *command, ...)
switch ((pid = fork()))
{
case -1:
+   free(args);
return false;
 
case 0:
@@ -275,6 +276,7 @@ __fw3_command_pipe(bool silent, const char *command, ...)
}
 
pipe_fd = fdopen(pfds[1], "w");
+   free(args);
return true;
 }
 
-- 
2.19.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH procd] hotplug.c: Make sure hotplug buffer is NULL terminated

2018-12-19 Thread Hauke Mehrtens
Sets the final byte explicitly to NULL because we later do string
operations on this buffer.

Fixes Coverity issue 1430926 String not null terminated

Signed-off-by: Hauke Mehrtens 
---
 plug/hotplug.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/plug/hotplug.c b/plug/hotplug.c
index 80e6e4d..37b918e 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -545,10 +545,12 @@ static void hotplug_handler(struct uloop_fd *u, unsigned 
int ev)
 {
int i = 0;
static char buf[4096];
-   int len = recv(u->fd, buf, sizeof(buf), MSG_DONTWAIT);
+   int len = recv(u->fd, buf, sizeof(buf) - 1, MSG_DONTWAIT);
void *index;
if (len < 1)
return;
+   else
+   buf[len] = '\0';
 
blob_buf_init(, 0);
index = blobmsg_open_table(, NULL);
-- 
2.19.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [RFC PATCH] kernel: drop MIPS: fix cache flushing for highmem pages

2018-12-19 Thread Felix Fietkau
On 2018-12-18 17:43, Rosen Penev wrote:
> On Tue, Dec 18, 2018 at 2:35 AM Kevin 'ldir' Darbyshire-Bryant
>  wrote:
>>
>> Signed-off-by: Kevin Darbyshire-Bryant 
>> ---
>>
>> This patch, in a variety of forms, has been around since beginning 2016
>> as e756c2bb07, ending up in present form 0aa6c7df60 (kernel 4.4.13 bump)
>> and carried forward ever since.
>>
>> There have been a number of MIPS kernel memory handling changes since,
>> including VDSO fixes that meant openwrt patches have been dropped with
>> no apparent fallout.
>>
>> I'm basically wondering if this patch needs to still exist in the kernel
>> 4.14.88 world?  I have been running without this patch for 3+ months on
>> Archer C7 v2 with no obvious ill effects (I'd expect to see "nasty
>> segfaults and kernel crashes")
>>
>> If it does still need to exist, should it go upstream?
>>
>> Thoughts, comments, more testers?
> I've tested removing the patch on a 512MB mt7621 device where HIGHMEM
> is used for the second 256MB. No issues.
I think to be on the safe side we should test running fuse (ntfs-3g or
sshfs or something similar) on such a device. If that doesn't turn up
any weird hangs or data corruption within a few minutes of use, I'm all
for dropping this patch.

Thanks,

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-19 Thread Petr Štetiar
Dave Taht  [2018-12-18 07:05:41]:

Hi,

> How many of the 28 can be reflashed with modern openwrt?

I just did a quick `git grep`:

 rt-ac55u|ac55u|ac55 - no match
 dir-850l|850 - no match
 dir-880l|880 - no match
 e2500|2500 - brcm47xx/linksys-e2500
 ea6100|6100 - no match
 ea6900|6900 - no match
 ea8500|8500 - ipq806x/linksys_ea8500
 WNDR4300v2|4300 - just ar71xx/WNDR4300V1 under legacy devices
 r6100|6100 - ar71xx/r6100 under legacy devices
 r7000|7000 - bcm53xx/netgear-r7000
 rt-ac3200|ac3200 - no match
 rt-ac68u|ac68u|ac68 - bcm53xx/asus-rt-ac68u
 rt-ac86u|ac86u|ac86 - no match
 rt-ac88u|ac88u|ac88 - no match
 dir-842|842 - no match
 dir-890l|890 - no match
 dir-895l|895 - no match
 wrt1900ac|1900ac|1900 - mvebu/linksys-wrt1900ac
 wrt32x|32x - mvebu/linksys-wrt32x
 r8000|8000 - bcm53xx/netgear-r8000
 r9000|9000 - no match
 rbr50|r50 - no match
 xr500|xr500 - no match
 rt2600ac|2600 - no match
 ac1750|1750 - just ar71xx/Belkin AC1750DB under tiny legacy devices
 ad7200|7200 - no match
 c3150_v2|c3150|3150 - no match
 tew-827dru_v2|827d - no match

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel