The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Aug 31, 2020, at 7:28 PM, Adria
On Tue, 1 Sep 2020 at 06:45, Yousong Zhou wrote:
>
> It's worth mentioning that recent versions of macos since 10.15 have a
> restriction on certificate validity period, self-signed or not. It's
> a strong restriction that the browser ui will have no buttons or knobs
> to bypass the certificate v
---
tools/firmware-utils/Makefile | 4 +-
tools/firmware-utils/src/linksys/addfwhdr.c | 195
tools/firmware-utils/src/linksys/bcmdefs.h| 318 +
.../firmware-utils/src/linksys/code_pattern.h | 396
tools/firmware-utils/src/linksys/crc.c
---
.../ipq806x/base-files/etc/board.d/01_leds| 3 +
.../ipq806x/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 3 +-
.../arm/boot/dts/qcom-ipq8064-e8350-v1.dts| 246 ++
target/linux/ipq806x/image/Makefile | 29 +++
bundle of 4 patches to add support for Linksys E8350 dual band wifi router type
AC2350
FCC ID: Q87-E8350
- device specifications are already in place under the openwrt wiki
URL: https://openwrt.org/inbox/toh/linksys/linksys_ea8350_1$
- successful test firmware has been confirmed
---
package/base-files/files/etc/rc.button/rfkill | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/base-files/files/etc/rc.button/rfkill
b/package/base-files/files/etc/rc.button/rfkill
index fbdda40ed5..2d4f0f86ff 100755
--- a/package/base-files/files/etc/rc.button/rfki
---
package/base-files/files/lib/upgrade/nand.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/base-files/files/lib/upgrade/nand.sh
b/package/base-files/files/lib/upgrade/nand.sh
index ad04bbc753..91eea3bd3a 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/bas
---
tools/firmware-utils/Makefile | 4 +-
tools/firmware-utils/src/linksys/addfwhdr.c | 195
tools/firmware-utils/src/linksys/bcmdefs.h| 318 +
.../firmware-utils/src/linksys/code_pattern.h | 396
tools/firmware-utils/src/linksys/crc.c
---
package/base-files/files/lib/upgrade/nand.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/base-files/files/lib/upgrade/nand.sh
b/package/base-files/files/lib/upgrade/nand.sh
index ad04bbc753..91eea3bd3a 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/bas
---
.../ipq806x/base-files/etc/board.d/01_leds| 3 +
.../ipq806x/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 3 +-
.../arm/boot/dts/qcom-ipq8064-e8350-v1.dts| 246 ++
target/linux/ipq806x/image/Makefile | 29 +++
bundle of 4 patches to add support for Linksys E8350 dual band wifi router type
AC2350
FCC ID: Q87-E8350
- device specifications are already in place under the openwrt wiki
URL: https://openwrt.org/inbox/toh/linksys/linksys_ea8350_1$
- successful test firmware has been confirmed
---
package/base-files/files/etc/rc.button/rfkill | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/base-files/files/etc/rc.button/rfkill
b/package/base-files/files/etc/rc.button/rfkill
index fbdda40ed5..2d4f0f86ff 100755
--- a/package/base-files/files/etc/rc.button/rfki
Hi again,
> -Original Message-
> From: Raylynn Knight [mailto:raykni...@me.com]
> Sent: Montag, 24. August 2020 10:00
> To: Adrian Schmutzler
> Cc: OpenWrt Development List ;
> ro...@advem.lv
> Subject: Re: [PATCH 0/6] rb532: update to kernel 5.4
>
> Result from using sysupgrade:
>
> --
On Tue, Sep 01, 2020 at 06:45:02AM +0800, Yousong Zhou wrote:
> It's worth mentioning that recent versions of macos since 10.15 have a
> restriction on certificate validity period, self-signed or not. It's
> a strong restriction that the browser ui will have no buttons or knobs
> to bypass the cer
It's worth mentioning that recent versions of macos since 10.15 have a
restriction on certificate validity period, self-signed or not. It's
a strong restriction that the browser ui will have no buttons or knobs
to bypass the certificate validation, rendering such sites
inaccessible. I remembered
On 8/31/20 8:34 PM, Michael Richardson wrote:
>
> Stijn Tintel wrote:
> >> The question came up if we really want RSA certificates for LuCI or if
> >> the faster and "more modern" ECC P-256 wouldn't be a better choice.
> >>
> >> If px5g is added to the next release, certificates a
> On Aug 31, 2020, at 9:41 AM, Hauke Mehrtens wrote:
>
> On 8/31/20 11:35 AM, Petr Štetiar wrote:
>> Rosen Penev [2020-08-31 02:06:50]:
>>
>>> I compile with target GCC 10, not host.
>>
>> Then as you can see its probably some issue with GCC 10 for that target
>> (which
>> one is that?) or
On 8/31/20 9:37 PM, Adrian Schmutzler wrote:
>>> For OpenWrt to OpenWrt upgrades (after a factory upgrade), I think you
>>> are right that soft-version and support-list can be left untouched.
>>> last_sysupgrade_partition could then be 'file-system', given the
>>> modified partition table for th
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Roederer
> Sent: Sonntag, 30. August 2020 22:57
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: tplink-safeloader support-list on CPE/WBS devices
>
> Am Sonntag, 30. August
> > For OpenWrt to OpenWrt upgrades (after a factory upgrade), I think you
> > are right that soft-version and support-list can be left untouched.
> > last_sysupgrade_partition could then be 'file-system', given the
> > modified partition table for these devices.
> >
> On CPE510 v1 etc., OpenW
On 8/31/20 11:18 AM, Sander Vanheule wrote:
> Hi Adrian,
>
> On Sun, 2020-08-30 at 22:43 +0200, Adrian Schmutzler wrote:
>> Hi,
>>
>> while increasing the kernel partition for the TP-Link CPE devices, I
>> found that the partitions called "soft-version" and "support-list"
>> are handled as a part
Stijn Tintel wrote:
>> The question came up if we really want RSA certificates for LuCI or if
>> the faster and "more modern" ECC P-256 wouldn't be a better choice.
>>
>> If px5g is added to the next release, certificates are generated on
>> first boot and most users are unlik
On 31/08/2020 14:26, Michael Richardson wrote:
Yes, many many many devices will break.
But browser makers don't really care about that.
This is a no-win situation until we can find a way to give proper names and
certificates to devices.
And offloading this into Let's Encrypt is **NOT** an answe
Bjørn Mork wrote:
>> I have running code that deploys LetsEncrypt certificates to devices in
the
>> "factory". This requires a DNS name for dns-01 challenge.
>> That's clearly not feasible for random end-users who flash openwrt on
their own.
>> I would like to explore some add
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Koen Vandeputte
> Sent: Donnerstag, 4. Juni 2020 09:34
> To: OpenWrt Development List
> Subject: [OpenWrt-Devel] cns3xxx and kernel 5.4
>
> Hi All,
>
> I've tried to bump this
Paul Spooren wrote:
> On 30.08.20 12:32, Michael Richardson wrote:
>> Paul Spooren wrote:
>> > I recently rewrote px5g[1] to use WolfSSL instead of MbedTLS, as the
former
>> > will be included in OpenWrt 20.x per default.
>>
>> > Both implementations support the generatio
Sorry, forgot to reply:
On 31-08-20, Daniel Golle wrote:
> On Wed, Aug 26, 2020 at 11:57:55AM -1000, Paul Spooren wrote:
> >
> > On 26.08.20 09:17, Baptiste Jonglez wrote:
> > > On 25-08-20, Paul Spooren wrote:
> > > > The key folder is used by `opkg` and `usign` to store and retrieve
> > > > tru
On 8/31/20 11:35 AM, Petr Štetiar wrote:
> Rosen Penev [2020-08-31 02:06:50]:
>
>> I compile with target GCC 10, not host.
>
> Then as you can see its probably some issue with GCC 10 for that target (which
> one is that?) or something like that, because I'm not able to trigger that
> with my GCC
New features:
* Per client tls-crypt keys
* ChaCha20-Poly1305 can be used to encrypt the data channel
* Routes are added/removed via Netlink instead of ifconfig/route
(unless iproute2 support is enabled).
* VLAN support when using a TAP device
Significant changes:
* Server support can no longer
These tools have been used by the orion target which has been
removed in Jan 2020 [1].
Both were specifically meant for the WRT350Nv2, which is not
supported anymore.
So, let's remove them as well.
[1] 89f2deb372b7 ("orion: remove unmaintained target")
Signed-off-by: Adrian Schmutzler
---
too
This sorts the added tools and builddir dependencies alphabetically
to make it easier to find something in the Makefile.
Signed-off-by: Adrian Schmutzler
---
tools/Makefile | 75 +-
1 file changed, 37 insertions(+), 38 deletions(-)
diff --git a/to
On 30/08/2020 10:57, Paul Spooren wrote:
> The question came up if we really want RSA certificates for LuCI or if
> the faster and "more modern" ECC P-256 wouldn't be a better choice.
>
> If px5g is added to the next release, certificates are generated on
> first boot and most users are unlikely to
Hi Felix, John and all,
when looking for leftovers of removed targets, I found the following patch in
generic that states it's specific to ixp4xx target (which has been removed a
while ago):
https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-5.4/412-mtd-partial_eraseblo
On Wed, Aug 26, 2020 at 11:57:55AM -1000, Paul Spooren wrote:
>
> On 26.08.20 09:17, Baptiste Jonglez wrote:
> > On 25-08-20, Paul Spooren wrote:
> > > The key folder is used by `opkg` and `usign` to store and retrieve
> > > trusted public keys. Using `opkg-key` outside a running device is
> > > u
Rosen Penev [2020-08-31 02:06:50]:
> I compile with target GCC 10, not host.
Then as you can see its probably some issue with GCC 10 for that target (which
one is that?) or something like that, because I'm not able to trigger that
with my GCC 10. Your proposed fix seems not correct as well, as b
Hi Adrian,
On Sun, 2020-08-30 at 22:43 +0200, Adrian Schmutzler wrote:
> Hi,
>
> while increasing the kernel partition for the TP-Link CPE devices, I
> found that the partitions called "soft-version" and "support-list"
> are handled as a part of the file-system/firmware partition, in
> contrast t
Sent from my iPhone
> On Aug 31, 2020, at 01:29, Petr Štetiar wrote:
>
> Rosen Penev [2020-08-31 00:53:32]:
>
/service.c:242:10: error: 'strncpy' offset 6 from the object at 'b' is
out of the bounds of referenced subobject 'name' with type 'uint8_t[]'
{aka 'unsigned char[]'} a
Rosen Penev [2020-08-31 00:53:32]:
> >> /service.c:242:10: error: 'strncpy' offset 6 from the object at 'b' is
> >> out of the bounds of referenced subobject 'name' with type 'uint8_t[]'
> >> {aka 'unsigned char[]'} at offset 6 [-Werror=array-bounds]
> >> 242 | s->id = strncpy(d_id, blobmsg_name(
> On Aug 31, 2020, at 00:08, Petr Štetiar wrote:
>
> Rosen Penev [2020-08-30 15:07:03]:
>
> Hi,
>
>> /service.c:242:10: error: 'strncpy' offset 6 from the object at 'b' is
>> out of the bounds of referenced subobject 'name' with type 'uint8_t[]'
>> {aka 'unsigned char[]'} at offset 6 [-Werror
Cleanup Makefile for consistency with other ones.
Remove PKG_SSP. It can be fixed with -lssp_nonshared.
Add PKG_BUILD_PARALLEL for faster compilation.
Add apline patch to fix compilation with aarch64.
Add alpine patch to fix pkgconfig file.
Backport GCC 10 patch to fix compilation.
Remove the
Rosen Penev [2020-08-30 15:07:03]:
Hi,
> /service.c:242:10: error: 'strncpy' offset 6 from the object at 'b' is
> out of the bounds of referenced subobject 'name' with type 'uint8_t[]'
> {aka 'unsigned char[]'} at offset 6 [-Werror=array-bounds]
> 242 | s->id = strncpy(d_id, blobmsg_name(b), n)
41 matches
Mail list logo
