On 15/05/2021 18:57, Alberto Bursi wrote:
If HTTPS is still an optional it makes no sense to treat it
differently from all other optional packages.
The only moment it should be included by default is when it becomes
mandatory, and the HTTP interface is disabled.
Maybe you are right here.
> On 15/05/21 22:13, Fernando Frediani wrote:
On 15/05/2021 16:59, Alberto Bursi wrote:
I'm personally in the "encrypt all the things" camp. I fully support a
switch to https only.
But it should be a default, not a "let's add stuff people might want
to enable later". Either all in or
From: Rafał Miłecki
Old "interface" sections for bridges were mixing layer 2 and layer 3.
Migrate them to the new styles that has:
1. "device" UCI section for L2 bridge
2. "interface" UCI section for L3 interface
Signed-off-by: Rafał Miłecki
---
.../files/etc/uci-defaults/11_network-bridge |
On 5/15/21 7:18 PM, Rafał Miłecki wrote:
> On 15.05.2021 11:09, Paul Oranje wrote:
>> Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het
>> volgende geschreven:
>>>
>>> From: Rafał Miłecki
>>>
>>> Bridge aggregates multiple ports so use a more accurate name ("ports").
>> Confusing that a logical
On 15/05/2021 16:59, Alberto Bursi wrote:
I'm personally in the "encrypt all the things" camp. I fully support a
switch to https only.
But it should be a default, not a "let's add stuff people might want
to enable later". Either all in or all out.
Perhaps that's the problem.
There has
On 14/05/21 10:58, Petr Štetiar wrote:
Fernando Frediani [2021-05-11 20:13:18]:
Hi,
I am no sure https support should still be something by default in the
images as it's not something really essential
to me it's like discussion about telnet versus SSH. (Puting aside, that one
shouldn't
From: Rafał Miłecki
This switches from the old way of defining bridges in an "interface" UCI
section type (that should be used for layer 3 only). From now a defualt
board switch will have its own "device" UCI section type. It's a new &
preferred way of defining L2 devices.
Before:
config
Yeah I understand even if HTTPS wouldn't come enabled by default (and it
shouldn't), but only available with that and that may seem Ok. My only
concern has been how much these extras consume on the default image for
not being something essential.
I understand there has been a movement to have
On 15.05.2021 11:09, Paul Oranje wrote:
Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het volgende
geschreven:
From: Rafał Miłecki
Bridge aggregates multiple ports so use a more accurate name ("ports").
Confusing that a logical network "interface" references something physical like a
[ answering some comments which also apply to the NR7101 ]
"Adrian Schmutzler" writes:
>> +partition@14 {
>> +label = "Kernel";
>> +reg = <0x14 0x1ec>;
>> +};
>
> "ubi" is part of kernel?
The operator specific firmware
On Sat, May 15, 2021 at 04:28:58PM +0200, Hauke Mehrtens wrote:
> On 5/15/21 1:34 AM, Daniel Golle wrote:
> > On Fri, May 14, 2021 at 11:31:27PM +0200, Hauke Mehrtens wrote:
> > > On 5/14/21 12:17 PM, Paul Spooren wrote:
> > > > Hi,
> > > >
> > > > On 5/13/21 1:32 AM, Hauke Mehrtens wrote:
> > >
On 5/15/21 1:34 AM, Daniel Golle wrote:
On Fri, May 14, 2021 at 11:31:27PM +0200, Hauke Mehrtens wrote:
On 5/14/21 12:17 PM, Paul Spooren wrote:
Hi,
On 5/13/21 1:32 AM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key
Hi,
comments below.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of André Valentin
> Sent: Samstag, 15. Mai 2021 02:12
> To: openwrt-devel@lists.openwrt.org
> Cc: avalen...@marcant.net
> Subject: [PATCH 2/2] ramips: mt7621: Add
André Valentin writes:
> This adds a new device id to the image tools.
>
> Signed-off-by: André Valentin
> ---
> tools/firmware-utils/src/zytrx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/firmware-utils/src/zytrx.c
> b/tools/firmware-utils/src/zytrx.c
> index
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 ---
Good morning !
Thanks for trying
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 ---
Good morning !
Thanks for trying
realtek: Fix VLAN issues introduced by multicast patches
This adds the CPU port to the unknown multicast flooding port mask,
which fixes the VLAN issues introduced by the multicast group patches
Signed-off-by: Birger Koblitz
---
v2: fixed typo in "unknown"
diff --git
17 matches
Mail list logo
