sorry, use_bcrypt isn't something in mainline busybox but a patched
vesrion so I think sha256 is best option here
2024-01-19 오후 4:28에 abnoeh 이(가) 쓴 글:
that option only applies if we use busybox internal crypt,
BUSYBOX_DEFAULT_USE_BB_CRYPT is set but we don't so it doesn't needed
(it's using
that option only applies if we use busybox internal crypt,
BUSYBOX_DEFAULT_USE_BB_CRYPT is set but we don't so it doesn't needed
(it's using musl here)
you'd need to change this option (line 1367) on same file
config BUSYBOX_DEFAULT_FEATURE_DEFAULT_PASSWD_ALGO
string
default
> On Jan 18, 2024, at 12:11 PM, Dave Taht wrote:
>
> OpenWrt One could use a logo...
Could we get the designer of the current OpenWrt logo/wordmark to augment it
with the word "One"?
See:
On 1/18/24 12:01, Tim Harvey wrote:
Greetings,
I seem to recall a way to ask OpenWrt's build system to output a list
of all variable values used in the build but can't find it documented
or in my notes. Does anyone know how to do that?
Also, is there a way to output a post-processed Makefile
On 1/18/24 10:37, Chuanhong Guo wrote:
MT7981 is such a chip with NAT offload capability, and the
flow-offload driver mentioned in other threads is actually
a driver for this hardware block.
Since it's a cost-down MT7986 I would imagine this particular
feature is the same between them:
HW NAT
−
Greetings,
I seem to recall a way to ask OpenWrt's build system to output a list
of all variable values used in the build but can't find it documented
or in my notes. Does anyone know how to do that?
Also, is there a way to output a post-processed Makefile after all the
define foo gets done? I
On Thu, Jan 18, 2024 at 12:04 PM Gregers Baur-Petersen wrote:
>
>
>
> On 18/01/2024 17.50, Dave Taht wrote:
> > tee-hee. For the record, I would prefer less (and less buggy) offloads
> > than offloads, and to work on scaling software better to multi-cores.
I had heard there was a mt76? mt79?
On 18/01/2024 17.50, Dave Taht wrote:
tee-hee. For the record, I would prefer less (and less buggy) offloads
than offloads, and to work on scaling software better to multi-cores.
I also would love to find a chip where fq_codel could be offloaded,
but with open source for the offload, since
tee-hee. For the record, I would prefer less (and less buggy) offloads
than offloads, and to work on scaling software better to multi-cores.
I also would love to find a chip where fq_codel could be offloaded,
but with open source for the offload, since the nss drivers are
slightly broken...
I
Hi!
On Fri, Jan 19, 2024 at 12:23 AM Fernando Frediani wrote:
>
> Hi, interesting. Is it enough to give it the necessary performance boost
> when doing NAT ? Is it capable of doing it on the chip or does it do on
> the CPU ? Reading about it seems to be a software thing although seems
> there
Hi,
you will also need to enable additional ciphers in musl libc (disabling the
crypt size hack).
Please disregard that remark, it has already been pointed out that the hack is
disabled by default since quite some time.
~ Jo
___
openwrt-devel
Hi,
Does the following do the trick?
you will also need to enable additional ciphers in musl libc (disabling the
crypt size hack).
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Hi,
> however Busybox doesn't configed to use those and still use md5 as
> default, while we bring other hash algos into flash anyway:
Does the following do the trick?
diff --git a/package/utils/busybox/Config-defaults.in
b/package/utils/busybox/Config-defaults.in
index b3c3f9a0b2..5ae8dd5622
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 ---
Dzień dobry,
w jaki sposób
14 matches
Mail list logo
