Hi team,
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 generation of RSA and ECC keys, where
uhttpd currently defaults to RSA with 2048 keys.
The question came up if we really want R
> On Aug 30, 2020, at 00:57, Paul Spooren wrote:
>
> Hi team,
>
> 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 generation of RSA and ECC keys, where uhttpd
> currently default
These are copied from OEM firmware.
Signed-off-by: Tomasz Maciej Nowak
---
v1 -> v2
- adjust commit title to changes in patch adding the main support
- add plural
package/firmware/ipq-wifi/Makefile | 2 ++
.../ipq-wifi/board-luma_wrtq-329acn.qca4019 | Bin 0 -> 24324 bytes
..
Luma Home WRTQ-329ACN, also known as Luma WiFi System, is a dual-band
wireless access point.
Specification
SoC: Qualcomm Atheros IPQ4018
RAM: 256 MB DDR3
Flash: 2 MB SPI NOR
128 MB SPI NAND
WIFI: 2.4 GHz 2T2R integrated
5 GHz 2T2R integrated
Ethernet: 2x 10/100/1000 Mbps QCA8075
USB:
On 29-08-20, Baptiste Jonglez wrote:
> On 28-08-20, Hauke Mehrtens wrote:
> > Hi,
> >
> > I would like to do a 19.07.4 and a 18.06.9 release on Sunday or
> > beginning of next week.
>
> Cool, looks good to me.
>
> > Is there something missing in the current branches which should get into
> > thi
On 8/30/20 9:57 AM, Paul Spooren wrote:
> Hi team,
>
> 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 generation of RSA and ECC keys, where
> uhttpd currently defaults to RSA with 204
Hi Hauke,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Hauke Mehrtens
> Sent: Samstag, 29. August 2020 20:33
> To: openwrt-devel@lists.openwrt.org
> Cc: Hauke Mehrtens
> Subject: [PATCH] uhttpd: Increase default certificate val
On 8/30/20 3:09 PM, Adrian Schmutzler wrote:
> Hi Hauke,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of Hauke Mehrtens
>> Sent: Samstag, 29. August 2020 20:33
>> To: openwrt-devel@lists.openwrt.org
>> Cc: Hauke Mehrtens
>> S
Hi Christian,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Christian Lamparter
> Sent: Sonntag, 30. August 2020 05:04
> To: openwrt-devel@lists.openwrt.org
> Cc: ra...@milecki.pl; ha...@hauke-m.de; f.faine...@gmail.com;
> chrisr
Hello Adrian,
On 2020-08-30 15:28, Adrian Schmutzler wrote:
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Christian Lamparter
Sent: Sonntag, 30. August 2020 05:04
To: openwrt-devel@lists.openwrt.org
Cc: ra...@milecki.pl; ha...@hauke-
Deactivate multiple personalities support, because this causes compile
problems at least on the x86/64 target. As OpenWrt compiles all
binaries itself all binaries will use the native personality which is
also used by strace. This change will make it impossible to debug i386
binaries on x86_64 Open
Branch: refs/heads/master
Home: https://github.com/sdwalker/sdwalker.github.io
Commit: 89f9131b48dd7f21b0c0bf2643c62ed4a44beb48
https://github.com/sdwalker/sdwalker.github.io/commit/89f9131b48dd7f21b0c0bf2643c62ed4a44beb48
Author: Stephen Walker
Date: 2020-08-30 (Sun, 30 Aug 2
On Sat, Aug 29, 2020 at 10:15 PM Hauke Mehrtens wrote:
>
> Signed-off-by: Hauke Mehrtens
Tested-by: Hans Dedecker
> ---
> package/network/utils/ethtool/Makefile | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/package/network/utils/ethtool/Makefile
> b/package/net
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 to all other
tplink-safeloader devices where it is part of a read-only partition.
Am Sonntag, 30. August 2020, 22:43:32 CEST schrieb Adrian Schmutzler:
> 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 to al
As defined in currently used iptables v1.8.4 [0], [1], chain name must be
under 29 chars. Thus, user can only edit 11 chars. See also [3].
[0]
https://git.netfilter.org/iptables/tree/iptables/xtables.c?h=v1.8.4&id=2b506c6681c7b01803f06b258a39e9da9012e5c5#n1004
[1]
https://git.netfilter.org/iptab
The previous fix seems to not be enough.
/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);
Signe
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 generation of RSA and ECC keys, where
uhttpd
> currently defaults to RSA with 2048 keys.
> T
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 generation of RSA and ECC keys, where
uhttpd
SYS_settimeofday is no longer present. That is, it's replaced with the
time32 variant. There is no time64 variant.
Note that 5a7c064bdbb71bfbcded073c7c0a8723be306009 switched the patch to
use the syscall instead of the function as musl's settimeofday does not
use the tz argument for anything.
Ins
The date -k patch is non standard and was removed.
Tested behavior to be identical with a simple C program:
#define _GNU_SOURCE
#include
#include
#include
#include
int main()
{
struct timezone tt;
struct timezone tz;
int a = syscall(SYS_gettimeofday, NULL, &tt);
Michael Richardson writes:
> 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 additional op
22 matches
Mail list logo
