Fixes FS#3231
Signed-off-by: Yousong Zhou
---
zones.c | 8
1 file changed, 8 insertions(+)
diff --git a/zones.c b/zones.c
index 68b02ab..d45077a 100644
--- a/zones.c
+++ b/zones.c
@@ -580,6 +580,14 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct
fw3_state *state,
> The disadvantage is that the wireless config has to be different if we switch
> to a default config with no separate LAN bridge, and it becomes potentially
> more confusing for common use cases.
> I think semantically it fits quite well to just assign a Wifi interface to
> the lan network and
The toolchain packages partly contain local code like patches and
configuration files. These files are not tracked via PKG_VERSION as this
variable only covers the upstream package version.
To allow versioning of the buildsystem, this commit adds PKG_RELEASE:=1
to all toolchain packages with local
> On 23. Jul 2020, at 14:17, Jo-Philipp Wich wrote:
>
> Hi,
>
>> 1. Have VLAN devices on top of vlan-enabled bridges to define hotplug
>> ops where applicable, so LAN could be a plain VLAN interface switch0.1
>> instead of its own bridge.
>> 2. With these wrapper hotplug ops, a default VLAN wo
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 Mon, 20 Jul 2020 at 21:15, Todor Colov wrote:
> Signed-off-by: Todor Colov
You put the whole commit message as the subject. Please use a short
subject message + proper description.
> @@ -36,7 +36,9 @@ fwtool_check_image() {
> }
> [ "$REQUIRE_IMAGE_METADATA" =
Hi again,
> What about spelling out the dependency explicitly? Instead of overloading the
> meaning of "option network", add an "option bridge" instead which reuses the
> existing vlan notation followed by a vlan id spec as defined by the "option
> ports" notation for bridge devices, e.g.
That sh
Hi,
> 1. Have VLAN devices on top of vlan-enabled bridges to define hotplug
> ops where applicable, so LAN could be a plain VLAN interface switch0.1
> instead of its own bridge.
> 2. With these wrapper hotplug ops, a default VLAN would be passed as
> well, unless overwritten by other VLAN settings
Ok I see, but then wouldn't it be much simpler to specify the bridge
device directly in wifi-ifaces instead of the network?
It's also needed in this case to ensure that the bridge-vlan section
can configure tagging on the bridge interface itself.
On Thu, 23 Jul 2020 at 13:53, Felix Fietkau wrote
> On 23. Jul 2020, at 13:44, Josh Bendavid wrote:
>
> "1. Have VLAN devices on top of vlan-enabled bridges to define hotplug
> ops where applicable, so LAN could be a plain VLAN interface switch0.1
> instead of its own bridge."
>
> By this you mean that the creation of the switch0.1 device wil
"1. Have VLAN devices on top of vlan-enabled bridges to define hotplug
ops where applicable, so LAN could be a plain VLAN interface switch0.1
instead of its own bridge."
By this you mean that the creation of the switch0.1 device will
trigger automatically through the hotplug op
"bridge vlan add de
Hi,
On 2020-07-23 12:10, Jo-Philipp Wich wrote:
> yeah I forgot to elaborate that in my last mail. The problem of dynamic / not
> explicitly addressable wifi interface names in the network config remains.
>
> The best solution I can think of is fixing the wifi ifnames using "option
> ifname" in t
From: Hauke Mehrtens
5c201be Add LDFLAGS when building libsparse.a
ec17045 make_ext4fs: fix build on musl systems
Signed-off-by: Hauke Mehrtens
(cherry picked from commit 271d0c825ba5821160e4a516497796fa342c2eff)
---
tools/make-ext4fs/Makefile | 6 +++---
tools/make-ext4f
Our 19.07 branch actually uses a make-ext4fs checkout from 2016.
This has been reported to not build on systems with musl libc.
Cherry-pick the fixes from master to resolve that.
Christian Lamparter (1):
make-ext4fs: update to HEAD of 2017-05-29 - eebda1
Hauke Mehrtens (1):
make_ext4fs: Upda
From: Christian Lamparter
Update make-ext4fs to commit eebda1d55d9701ace2700d7ae461697fadf52d1f
git log --pretty=oneline --abbrev-commit 484903e4..eebda1d5
eebda1d make_ext4: Add strict prototypes.
bb9cf91 make_ext4fs: Remove off64_t in favor of standard off_t
Created with the help of the make
Another option, as long as the standard method is to attach a wireless
interface to a bridge though the "option network" in the wifi-ifaces,
would be to add a corresponding "option pvid" to wifi-ifaces which
could then be propagated to the bridge when the wifi interface is
added.
On Thu, 23 Jul 20
Hi,
yeah I forgot to elaborate that in my last mail. The problem of dynamic / not
explicitly addressable wifi interface names in the network config remains.
The best solution I can think of is fixing the wifi ifnames using "option
ifname" in the wifi-iface sections (which causes some very interes
Ok sure, but the documentation currently says "As WLAN interface names
may be dynamic or unpredictable, it is strongly recommended that they
be assigned to bridges using the network option in UCI wireless
configuration"
This is referring to the list of interfaces for the bridge, but
presumably the
Hi,
> Related to this, is it possible to add a wireless interface to a
> bridge specifying a non-default PVID?
I would have expected that something like
config bridge-vlan
option device mybridge0
option vlan 100
option ports 'wlan0:u*'
achieves that effect. The wlan0 interface would be a
Ok thanks, I agree this makes much more sense.
As Luiz mentioned earlier, this exposes more explicitly the
awkwardness of the "network" option for wifi-iface pointing to an
interface rather than a device.
Related to this, is it possible to add a wireless interface to a
bridge specifying a non-def
Hi Jo,
On Thu, 23 Jul 2020 at 14:31, Jo-Philipp Wich wrote:
>
> Hi Yousong,
>
>
> On 7/23/20 6:05 AM, Yousong Zhou wrote:
> > Fixes FS#3231
> >
> > Signed-off-by: Yousong Zhou
> > ---
> > zones.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/zones.c b/zones.c
> > index
Hi,
> One thing which is a bit awkward as long as the bridge itself is
> configured as an interface, is that as far as I have understood,
> creating a tagged interface to the bridge requires first setting up an
> interface for the bridge, e.g. with protocol Unmanaged, and then
> setting up one or
22 matches
Mail list logo
