On 14.07.20 04:28, Adrian Schmutzler wrote:
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
On 14.07.20 04:28, Adrian Schmutzler wrote:
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
On 14.07.20 04:28, Adrian Schmutzler wrote:
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
On 2020-07-15 13:52, John Crispin wrote:
>
> On 15.07.20 13:39, Jo-Philipp Wich wrote:
>> Hi,
>>
>>> If we can't come up with a working automatic scheme, maybe we could have
>>> an option to disable the cpu port per vlan?
>> Having a default-enabled "option self" or "option local" was my idea as
Hi,
the OpenWrt system requires the calculation of both md5 and sha256 sums
at various places, this is partly done via a small C file in
./scripts/mkhash.c and partly by using a sha256sum binary. A ancient
wrapper ./scripts/md5sum is added for Mac OS X compatibility.
* Should we create our
In the past buildinfo files where added to enable testing for
reproducible builds. The combination of the three buildinfo files
feeds.buildinfo, config.buildinfo and version.buildinfo allow to
recreate the buildsystem and check if compiled binaries are bit for bit
the same as distributed on
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 ---
СОВЕТСКИЕ МУЛЬТФИЛЬМЫ
Большая
On Wed, Jul 15, 2020 at 5:15 PM Paul Spooren wrote:
>
> The Ed25519 key pairs are much shorter than RSA pairs and are supported
> by default in OpenSSH. Looking at websites explaining how to create new
> SSH keys, many suggest using Ed25519 rather than RSA, however consider
> the former as not
The Ed25519 key pairs are much shorter than RSA pairs and are supported
by default in OpenSSH. Looking at websites explaining how to create new
SSH keys, many suggest using Ed25519 rather than RSA, however consider
the former as not yet widely established. OpenWrt likely has a positive
influence
dnsmasq sometimes does not listen for DHCP at bootup on lan (see bug FS#1765).
This occurs because netifd can incorrectly indicate carrier down on an
interface through devstatus after issuing a carrier up hotplug event.
This patch ignores carrier status for bridge interfaces, as this does not
I have resent the patch, hopefully without the legal text being added on by our
company email server.
Reuben
-Original Message-
From: Petr Štetiar
Sent: Sunday, 12 July 2020 1:25 am
To: Reuben Dowle
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] dnsmasq:
On Wed, 15 Jul 2020, m...@adrianschmutzler.de wrote:
At least for the 4.14 targets, I expect them to be archived if there is no
update until after the next release (or at the latest after the one following
it).
I'm working on bringing pistachio up to 5.4, apart from the spi-nand (which
> > At least for the 4.14 targets, I expect them to be archived if there is no
> update until after the next release (or at the latest after the one following
> it).
> >
> I'm working on bringing pistachio up to 5.4, apart from the spi-nand (which is
> quite a core item obviously, so I thought
The swapon/swapoff applets enabled by default in BusyBox have more features than
the ones from block-mount's block app, which makes them redundant.
This patch removes only those applets, while both keeping all the internal
functionality required to handle hotplug/fstab swap and also shaving off a
The swapon/swapoff applets enabled by default in BusyBox have more features than
the ones from block-mount's block app, which makes them redundant.
This patch removes disables the creation of the symlinks for the swapon/swapoff
block applets. A follow-up patch will remove the applets themselves
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jo-Philipp Wich
> Sent: Mittwoch, 15. Juli 2020 14:19
> To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Subject: Re: [RFC PATCH v2 0/1] Introduce UCI support for
I guess the vlan_default_pvid setting would fit into the config device
block in this scheme?
On Wed, 15 Jul 2020 at 09:59, Jo-Philipp Wich wrote:
>
> Hi,
>
> > Changes:
> > - The device is created as a netifd bridge
> > - Bridge vlan sections should always refer to the bridge instead of
> >
Hi,
> I'm not sure whether using an asterisk is wise here, as it might pose
> interesting problems when people use scripts to set/evaluate uci
> config (as you have to be extra careful to not have it treated as a
> wildcard.) I'd be happy if we could find another symbol here.
hm, can you
> - For denoting pvid I used a trailing asterisk, like the old roboswitch config
I'm not sure whether using an asterisk is wise here, as it might pose
interesting problems when people use scripts to set/evaluate uci config (as you
have to be extra careful to not have it treated as a wildcard.)
On 15.07.20 13:39, Jo-Philipp Wich wrote:
Hi,
If we can't come up with a working automatic scheme, maybe we could have
an option to disable the cpu port per vlan?
Having a default-enabled "option self" or "option local" was my idea as
well. Any idea which name fits better?
~ Jo
self is
Hi,
> If we can't come up with a working automatic scheme, maybe we could have
> an option to disable the cpu port per vlan?
Having a default-enabled "option self" or "option local" was my idea as
well. Any idea which name fits better?
~ Jo
___
Jo-Philipp Wich writes:
> config device
> option name switch0
> option type bridge
>
> config bridge-vlan
> option device switch0
> option vlan 1
> list ports 'lan1'
> list ports 'lan2:t'
If we can't come up with a working automatic scheme, maybe we could
Hi all,
I played today a bit with dt-schema[0] which allows to validate
device-tree schema files via something called json-schema[1], a schema
description written in, *drums*, yaml. Ideally vendors specify their
hardware in the Kernel[2] and dt-schema validates each .dts file added
to
On 2020-07-15 09:56, Jo-Philipp Wich wrote:
> Hi,
>
>> Changes:
>> - The device is created as a netifd bridge
>> - Bridge vlan sections should always refer to the bridge instead of
>> automatically be applied to the first one
>> - Use = instead of . to mark tagging modifiers. "." is already
Hi,
> Changes:
> - The device is created as a netifd bridge
> - Bridge vlan sections should always refer to the bridge instead of
> automatically be applied to the first one
> - Use = instead of . to mark tagging modifiers. "." is already used
> for vlan interface names and reusing it here
Hi,
I would like to propose an alternative configuration format that is
structurally close to your proposal, but more generic in that it is not
tied to DSA directly but configures bridge vlans instead.
Here's the converted form of your example:
config device switch0
option name switch0
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,
27 matches
Mail list logo
