risk of *regressions* is greatly reduced.
--
Henrique de Moraes Holschuh
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
to execve() anything.
PS: I have attached an example of how one could do generic self-healing
of the standard low FDs in C in a POSIX environment where fcntl() and
dup2() are available. Note that FD 2 is expected to be R/W, according
to the C specification for stdio.h streams.
--
Henriqu
:16, Hauke Mehrtens escreveu:
* Update Linux kernel from 5.10.138 to 5.10.146
5.10.149 is out with a few extra wifi fixes, including a change in one
of the already backported commits.
Same for 5.4.y FWIW.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecn
WAN circuit suddenly becomes a bridge, and connects
that WAN circuit to the LAN circuit. And yes, obviously applies to
VLANs as well. Switching a port from LAN to WAN is also bad, and it can
be just as dangerous depending on several factors.
--
Henrique de Moraes Holsch
k firmware ID for the TP-Link Archer C6v3.0 (BR),
which is currently sold in Brazil. It uses exactly the same vendor
firmware as the A6v3 and C6v3.20.
Signed-off-by: Henrique de Moraes Holschuh
---
src/tplink-safeloader.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
-) Adding the mentioned PROVIDES would make life
easier for [third-party] packages that support older OpenWRT releases,
and which can't simply "drop" those dependencies because they are needed
on older OpenWRT.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Es
not going to cause user issues, is to have an
"auto" in LuCI (for UCI, that might be "unset"), for the proper default,
and let the user force-override it where wanted.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e
On 26/09/2021 06:28, Henrique de Moraes Holschuh wrote:
On 24/09/2021 17:04, e9hack wrote:
In the past (a few days ago), it was possible to disable or shut-down
wifi by introduce the command 'wifi down'. This doesn't work
currently. After some seconds, wifi is start again.
What version
"a few days ago", it might help...
Thanks for the report!
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 31/08/2021 17:42, Sander Vanheule wrote:
On Sat, 2021-08-28 at 10:24 -0300, Henrique de Moraes Holschuh wrote:
On 27/08/2021 06:38, Sander Vanheule wrote:
EAP235-Wall support will be included in the 21.02 release, but users who
have a v3 (or later) firmware installed, will not be able
ree is EOL/closed.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.o
On 06/07/2021 13:05, Michael Richardson wrote:
Henrique de Moraes Holschuh wrote:
> So, to safely and responsibly enable wireless by default in a device (or
> firmware) you're delivering to a third-party, you need that "per-unit
unique
> wireless password" pe
On 06/07/2021 14:29, Eric Luehrsen wrote:
> On Tue, Jul 6, 2021, 1:06 PM Henrique de Moraes Holschuh
> mailto:henri...@nic.br>> wrote:
>
> On 06/07/2021 12:05, Nishant Sharma wrote:
> > On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote:
> >&
I will address the other points in a separate reply.
On 06/07/2021 13:05, Michael Richardson wrote:
Henrique de Moraes Holschuh wrote:
> [1] The reports are public, and available at https://ceptro.br.
Disclaimer: I
> work for a different division of the same NGO that produced
On 06/07/2021 12:05, Nishant Sharma wrote:
On 06/07/21 7:56 pm, Henrique de Moraes Holschuh wrote:
So, to safely and responsibly enable wireless by default in a device (or
firmware) you're delivering to a third-party, you need that "per-unit
unique wireless password" per device
[1] The reports are public, and available at https://ceptro.br.
Disclaimer: I work for a different division of the same NGO that
produced those reports.
[2] not really: openwrt sysugrade *does not help* in that there is no
way to add variable information to an already *finished* image file, to
local application
source" in the "Creating Packages" wiki page?
Please do!
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC
On 06/05/2021 05:00, Petr Štetiar wrote:
Henrique de Moraes Holschuh [2021-05-05 17:49:19]:
Any updates on this?
it has been merged about month ago into master and 21.02 branches, so it's
available in 21.02.0-rc1 images and I've just pushed it into 19.07 branch as
well.
Thank you
://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
On 23/03/2021 16:46, Rui Salvaterra wrote:
On Tue, 23 Mar 2021 at 17:47, Henrique de Moraes Holschuh
wrote:
Does this change throughput or network behavior ?
I haven't noticed absolutely any differences. And note that I'm
running at HZ = 24 in my personal configuration, so my timer
, with the TEO governor.
Does this change throughput or network behavior ?
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 07/03/2021 07:27, Petr Štetiar wrote:
You've two options to test your changes from the CI perspective.
[...]
Can we have these very nice instructions added to a CONTRIBUTING.md file
(or something to that effect) for libubox?
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de
to stabilize due to the sheer number of changes,
if not for any other reasons...
I see that still happening with 18.06...
--
Henrique de Moraes Holschuh
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman
ed (likely with an added Fixes:
86aeac4fc98f42ac0ce7e0dcf1cb240e16b28f8f pseudo-header) ?
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
"use
factory images to update from vendor firmware to openwrt"...
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
__
p the -ct firmware and drivers, and
switch to vendor ath firmware and drivers, though, but if there are
other tests that can be done beforehand, it would be best.
On 22/12/2020, Henrique de Moraes Holschuh wrote:
On 21/12/2020 17:13, Tom Psyborg wrote:
In case your client doesn't support mfp,
clients.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
openwrt-devel
ormance loss.
On 21/12/2020, Henrique de Moraes Holschuh wrote:
On 21/12/2020 17:01, Tom Psyborg wrote:
Your firmware does not advertise mfp support, first check if your
client device can actually support 802.11w
Does it mean that we should expect the large performance loss for any
clien
enabled?
That sounds extremely sub-optimal, to use very nice words... so
hopefully there is more to the scenario?
On 21/12/2020, Henrique de Moraes Holschuh wrote:
On 20/12/2020 06:42, Petr Štetiar wrote:
I would like to let you know, that there was virtual meeting week ago and
you
can find
it :-(
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https
/tmp/group 2>/dev/null
# Prevent configuration corruption on a power loss
sync
}
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
_
t;name, line);
+ }
fclose(f);
}
--
Henrique de Moraes Holschuh
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
initial whitespace on comment lines, it can get
confusing for users: the vast majority of formats that support comments
starting with # up to EOL do allow whitespace before the #.
--
Henrique de Moraes Holschuh
www.nic.br
___
openwrt-devel mailing list
when backporting packages that adopt it, unless we also backport the
feature itself...
--
Henrique de Moraes Holschuh
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
that config migration
scripts are provided where applicable.
With that caveat sorted, looks like an overall win to me.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
add custom certificates,
with a default of certs/)
[ ] All other certificates we'd usually package in ca-bundle
Default would be something that gets us all the current certificates in
ca-bundle, and maybe just the custom path or LE for the SMALL_FLASH version.
--
Henrique de Moraes Holsc
he browser would use
to stop pestering the user of : be that a certificate chaining
from ., or DNSSEC, or whatever.
Well, one can hope and dream...
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.
On 24/08/2020 09:01, Baptiste Jonglez wrote:
On 24-08-20, Henrique de Moraes Holschuh wrote:
On 24/08/2020 07:53, Baptiste Jonglez wrote:
It is more user-friendly to tell the user that the checksum is wrong, so
move the file size check at the end.
It is also far more expensive in the failure
wrong, so
move the file size check at the end.
It is also far more expensive in the failure case, not to mention the
fact that you're going to process data you KNOW to be wrong when you
could have easily avoided it.
This does NOT look like a good idea to me.
--
Henrique de Moraes Holschuh
A
and the extra CCs to firewall3 maintainers) if nobody replies
to you about it in the next two or three days.
--
Henrique de Moraes Holschuh
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
, anything that is being relayed due to too-strict SPF
is being relayed with an *EMPTY* subject, and *THAT* is extremely annoying.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
organization(s) -- which are based on the U.S. -- in legal risk without
at least contacting them first and getting their approval.
Has anyone asked SPI about it yet?
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
-F" and direct flashing is
another angle to think about, as well...
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
50KiB as a first try.
And exceptional cases would only need a sufficiently good justification
in the commit log (as in, enough to convince the core team).
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists
On 31/07/2020 12:42, bapti...@bitsofnetworks.org wrote:
On 31-07-20, Henrique de Moraes Holschuh wrote:
As there has been no negative feedback about this, we will move to
configure the same SSID for 2.4 GHz and 5 GHz in the quick setup.
This will simplify the user experience.
We have never
e. No need for a [x] that triggers an UCI form change
that asks for separate SSIDs (although *that* would work as well).
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
that requires ca-certificates and keep
ca-bundle. The issue is not which one is used (IMHO): as far as I am
concerned, either one is fine as long as we never need *both* at the
same time.
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt
quirements... And it does work for anyone doing full builds.
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
present only on master. Also, handling of an
uci-defaults "reset" (so that they'd run again) in
non-initramfs/overlayfs based system is likely to pose some challenges
depending on how it is implemented...
--
Henrique de Moraes Holschuh
__
config_foreach wifi_rfkill_set wifi-device
uci commit wireless
I've always hated this "uci commit" in the wifi on/off button handling,
it causes FLASH wear for no good reason IMHO.
But that is orthogonal to this patch, of course.
--
Henrique de Morae
would cause trouble.
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
is is hard to access,
and it is going to introduce (sometimes subtle) bugs in scripts not just
from openwrt upstream, but also downstream and users.
Unless you're saving a very large amount of FLASH with this change, it
*really* isn't worth it. Not even for the 4MiB targets.
Please reconsider.
-
ot; change, it
is a tidal wave that ripples down to everything that uses OpenWRT, every
feed, every downstream, and users.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
On 01/07/2020 19:49, Hauke Mehrtens wrote:
On 7/1/20 6:50 PM, Henrique de Moraes Holschuh wrote:
On 12/05/2020 18:46, Hauke Mehrtens wrote:
On 5/12/20 12:24 PM, Bjørn Mork wrote:
Hauke Mehrtens writes:
I also get this problem with mainline kernel.
See here for some more details:
https
).
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ted. They could be, but it would
waste precious flash, it makes more sense to warn users to backup
beforehand in the LuCI interface (and not mess with sysupgrade itself,
which needs to be able to **safely** work unattended as well).
--
Henrique de Moraes Holsc
watchdog and a
please-wait-a-bit-more-I-am-doing-a-clean-shutdown API), to better know
the problem space.
--
Henrique de Moraes Holschuh
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt
On 24/04/2020 16:13, David Bauer wrote:
On 4/24/20 8:39 PM, Henrique de Moraes Holschuh wrote:
On 24/04/2020 15:09, David Bauer wrote:
This parser was added with the target, but no device seems to use it
currently, as all partitions are specified in the device-tree.
But is that a good thing
) ?
Depends on what the vendor boot loader uses, I suppose...
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt
be better to keep that naming?
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
openwrt
)
PKG_LICENSE_FILE:=LICENSE.amd-ucode
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
openwrt-devel
and configured after an ar71xx->ath79 migration as "ar71xx-ath79
WIP" unless one can add a "!beware!" sort of reminder to the listing,
though ;-)
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br
Em 05/12/2018 21:20, Thomas Endt escreveu:
Auftrag von Henrique de Moraes Holschuh
Do we have a wiki table somewhere that has the device name, ar71xx info
and ath79 info, which could be expanded with ar71xx->ath79 status (no,
yes but unverified, yes verified to be complete)?
That wo
Em 04/12/2018 19:57, Piotr Dymacz escreveu:
On 04.12.2018 17:08, Henrique de Moraes Holschuh wrote:
Another aspect was the LED configuration, as LED naming is very
inconsistent and often differs from ar71xx. Some LEDs are now not
included in UCI configuration. >
So you either need to del
Em 03/12/2018 16:23, Petr Štetiar escreveu:
On December 3, 2018 6:04:28 PM UTC, Henrique de Moraes Holschuh
wrote:
(openwrt-adm dropped from this subthread)
Is there a viable way to "sysupgrade" from ar71xx to ath79?
Have you tried it? It didn't work for you?
Even if it wou
remotely switch them to ath79...
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailin
, etc.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
67 matches
Mail list logo
