Perry writes:
> With dsaconfig, all vlans get tagged on the switch to "self". I
> understand this as tagging the cpu port.
>
> It is exactly this step which I skip to have unmanageable switched
> vlans. The devices do not show up with "ip l" but the vlans can be seen
> with "bridge v".
Yes, I'd
> > config bridge br-lan <- the real bridge device name
>
> This is invalid uci syntax, dashes are not allowed. It also duplicates "config
> device" with "option type bridge".
Yes, "config device" is better. If used, a wireless definition would
now reference a device
and not an interface.
> > o
Hi,
In the setup that I have (dsa), in addition to creating interfaces which
are managed, I also have vlans which are not managed at all, thus having
pure switching for these specific vlans.
With dsaconfig, all vlans get tagged on the switch to "self". I
understand this as tagging the cpu port.
Ok thanks.
I think my main point was not that this belongs in interface per-se,
but that it makes sense for the configuration of vlan tagging to apply
to bridges in general (and to have as little as possible special
handling of dsa in uci, since the logic is that it should be possible
to configure
Hello!!
I am experiencing my router answering dns requests coming from WAN interface.
Is this something I introduced with my config BTW, or not?
My config is pretty standard, but who knows.
I may send it when I have access to my device.
Enrico
___
Jordan Geoghegan writes:
> This isn't about 500 bytes of space anymore is it?
FWIW, I believe it is. It is about the sum of all the 500 bytes of
space contributed by each feature which doesn't qualify as strictly
necessary.
The upside is that OpenWrt runs on devices with almost no RAM and fla
Hi,
> [...]
> The same feeling is still with this DSA proposal. The syntax "lan2.t
> lan2 lan3 lan5" is unstructured and it does not help too.
What is unstructured about it? The fact that it is not a uci list? That can be
easily changed.
> The use of "switch0" for cpu interface is good and I thi
Hello,
I had the same feeling since I saw this patch. I would really like
something that could transparently allow me to bridge
either DSA ports, standard ethernet ports or even have a syntax that
would be compatible with swconfig (where dsa is not available).
It is a good opportunity to rebuild
On 2020-07-14 02:54, Bjørn Mork wrote:
Jordan Geoghegan writes:
'tr' is a standard system utility, I wasn't expecting such pushback
against making it behave as every other modern implementation does.
OpenWrt exists because it is different from every other distribution.
https://openwrt.org/
Hi,
> [...]
> Isn't it conceptually more correct in this case for the vlan filtering
> to be configured as part of the "interface" in uci?
> Ie I configure an interface of type "bridge" which bridges the switch
> ports, then the vlan filtering is a configuration property of this
> interface (just
Hi,
I have a somewhat radical comment on this.
As far as I understand, the vlan filtering support in the linux bridge
subsystem is not specific to dsa, but can equally be configured for a
pure software bridge. The fact that the switch supports dsa/switchdev
then simply allows this to be transpare
The original idea was to pull-in swap-utils when the required BusyBox utilities
were unavailable. However, this made the zram-swap package strictly depend on
swap-utils when using the image builder, which is incorrect. Moreover,
swap-utils dropped the swapon/swapoff utilities years ago.
Let's just
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patchset introduces a compa
This revised patchset provides some polishing to the initial submission.
It does not change the mechanics substantially, but just provides some
aesthetic improvements.
Notable functional changes:
- compat version check is now executed _after_ the supported_devices check
- the DEVICE_COMPAT_MESSAG
This implements the newly introduced compat-version to prevent
upgrade between swconfig and DSA for mvebu.
Just define a compat version with minor increment and an appropriate
message for both image (in Makefile) and device (in base-files).
Having taken care of sysupgrade, we can put back the SUP
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patchset introduces a compa
This implements the newly introduced compat-version to prevent
upgrade between swconfig and DSA for kirkwood.
Just define a compat version with minor increment and an appropriate
message for both image (in Makefile) and device (in base-files).
Since we never removed SUPPORTED_DEVICES for this tar
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patchset introduces a compa
So far, the compatibility mechanism only works if both device and
image are already updated to the new routines. This patch extends
the sysupgrade metadata and fwtool_check_image() to account for
"older" images as well:
The basic mechanism for older devices to check for image compatibility
is the
On 2020-07-14 13:57, Florian Eckert wrote:
>
>> What's the use case for this?
> As much as I remember there was the problem in 2017 that you can't
> change the country code or have to restrict it.
> https://ec.europa.eu/growth/sectors/electrical-engineering/red-directive_de
> Of course this chang
Fix at least one rare wave-2 crash.
Signed-off-by: Michael Yartys
---
package/firmware/ath10k-ct-firmware/Makefile | 56 ++--
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/package/firmware/ath10k-ct-firmware/Makefile
b/package/firmware/ath10k-ct-firmware/Makefi
From: Michael Yartys
Fix at least one rare wave-2 crash.
Signed-off-by: Michael Yartys
---
package/firmware/ath10k-ct-firmware/Makefile | 56 ++--
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/package/firmware/ath10k-ct-firmware/Makefile
b/package/firmware/at
Currently both PMKSA caching and Opportunistic Key Caching are set by the
option auth_cache. iOS devices are unable to connect to WPA3-Personal
networks when PMKSA caching is not enabled, but setting auth_cache to 1
also enables Opportunistic Key Caching which is not required. This doesn't
seem to
Split auth_cache into pmksa_cache (PMKSA caching) and
okc (Opportunistic Key Caching) to enable setting these options
individually.
Signed-off-by: Michael Yartys
---
.../network/services/hostapd/files/hostapd.sh | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --g
Don't enable Opportunistic Key Caching by default on WPA3-Personal
networks. iOS devices only require PMKSA caching to be enabled to connect
to a WPA3-Personal network, not Opportunistic Key Caching.
Fixes: 3034f8c3b85e70b1dd9b4cd5cd33e9d2cd8be3b8 ("hostapd: enable PMKSA and OK
caching for WPA3-P
What's the use case for this?
As much as I remember there was the problem in 2017 that you can't
change the country code or have to restrict it.
https://ec.europa.eu/growth/sectors/electrical-engineering/red-directive_de
Of course this change can't fulfill with this patch, but it wouldn't be
For mt7621, console is set up via DTS bootargs individually in
device DTS/DTSI files. However, 44 of 74 statements use the
following setting:
chosen {
bootargs = "console=ttyS0,57600";
};
Therefore, don't repeat ourselves and move that definition to the SoC
DTSI fi
Jordan Geoghegan writes:
> 'tr' is a standard system utility, I wasn't expecting such pushback
> against making it behave as every other modern implementation does.
OpenWrt exists because it is different from every other distribution.
https://openwrt.org/about describes it as "all the features
On 2020-07-14 02:08, Petr Štetiar wrote:
Jordan Geoghegan [2020-07-13 23:06:30]:
Also, the use of "tr 'a-z'..." is unsafe for exotic locales
Buildsystem sets LC_ALL=C explicitly, so whats the issue here?
I've reported that 'tr' behaves abnormally, that's about all I can do.
If you guys w
Jordan Geoghegan [2020-07-13 23:06:30]:
> Also, the use of "tr 'a-z'..." is unsafe for exotic locales
Buildsystem sets LC_ALL=C explicitly, so whats the issue here?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.o
Jordan Geoghegan [2020-07-13 22:44:05]:
> scripts/mkits.sh
> 59:ARCH_UPPER=$(echo "$ARCH" | tr '[:lower:]' '[:upper:]')
What's a problem here? It's running on host, so this classes are supported.
> ryzen$ rg "tr '\["
> utils/lxc/patches/010-Remove-distro-check.patch
> 43:-with_distro=`echo ${wi
> 2.About "missing reg property".
> Adrian Schmutzler wrote a letter to me about that, then I tested as he said,
> it was ok. Here is the letter from him.
@Petr: The reg property is in the DTS files, while everything else is in the
DTSI. It's also a case of DRY :-)
> 5.About "Be DRY, use some c
32 matches
Mail list logo
