netdev - Re: Bridge port userspace events broken?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJieiUjvamKds6+hbsKhwCJ_MDC9_9Wfy8ogyB1f3OrSgXKC6w@mail.gmail.com>
Date:   Wed, 16 Oct 2019 21:10:06 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Richard Weinberger <richard@....at>
Cc:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Richard Weinberger <richard.weinberger@...il.com>,
        netdev <netdev@...r.kernel.org>,
        bridge@...ts.linux-foundation.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Bridge port userspace events broken?

On Wed, Oct 16, 2019 at 2:16 PM Richard Weinberger <richard@....at> wrote:
>
> Roopa, Nikolay,
>
> ----- Ursprüngliche Mail -----
> > +1,  this can be fixed....but in general all new bridge and link
> > attributes have better support with netlink.
> > In this case its IFLA_BRPORT_GROUP_FWD_MASK link attribute available
> > via ip monitor or bridge monitor.
> > you probably cannot use it with udev today.
> >
> > For the future, I think having udev listen to netlink link and devlink
> > events would make sense (Not sure if anybody is working on it).
> > AFAIK the sysfs uevent mechanism for link attributes don't  receive
> > the required attention and testing like the equivalent netlink events.
>
> I understand that netlink works best for you but sysfs notifications are still
> useful.
> Please let me explain my use case a little bit more.
>
> The application I work on operates on network interfaces, in this case the
> interface happens to be a bridge.
> systemd-networkd sets up the bridge as soon all slave interfaces emerge.
>
> Therefore the systemd service file of the application depends on the bridge.
> i.e.
> Requires=sys-subsystem-net-devices-br0.device
>

interesting. We do have a lot of applications that depend on network
interfaces and we
 simply make them depend on the networking service eg with
"After=networking.service".

we don't use systemd-networkd today..but our network interface
management software (https://packages.debian.org/buster/ifupdown2)
registers itself as  networking.service. For unsupported options the
network interface manager provides hooks to invoke pre and post
commands
which takes care of the unsupported attributes case you mention above.
In absence of that, we would probably use systemd ExecStartPost

> In one specific setup the bridge needs to forward more than usual and
> group_fwd_mask needs to be altered. Sadly this is nothing systemd-networkd
> can do right now, so I added the following line to the service file of
> the application:
> ExecStartPre=/bin/bash -c "echo 0xfffd > /sys/class/net/eth0/brport/group_fwd_mask"

ok, yeah the right thing here will be for your network manager
(systemd-networkd)  to support this config attribute.

But understand that there will always be an attribute that your
network interface manager does not support :)

>
> Here comes the problem, the unit is activated as soon br0 is created but
> at this time eth0 is sometimes not yet a slave or br0. It takes some time.
>
> So I need a way to model this dependency in a systemd environment.
> A common approach to do so is setting up an udev rule which set a systemd notify
> as soon a specific sysfs file arrives.

That is cleaver. But, you now have systemd-networkd and udevd to get
your interfaces configured right.
You may be able to get past this for now to find more problems later.

>
> Teaching the application to listen for bridge specific netlink messages is
> another possible approach but seems overkill to me.

understood. In your case, the ideal thing to do is have all your
configuration done via systemd-networkd.
that will also make sure your config persists in a single place.
Agreed that having your application understand netlink to just deal
with this attribute is overkill.

> Or maybe there is some nice wrapper/helper?

There are many netlink libraries from libnl, python-nlmanager, pyroute2 etc

>
> It would be nice to have sysfs notifications for bridge devices too.
> I can understand that not everyone likes this approach but this is the way
> how *many* systems out there work these day. Actually almost any (embedded)
> system with systemd.
>

I think if you are using systemd, systemd-networkd which uses netlink
is the best
option to deal with interface link events.

Regardless, for existing bridge sysfs attribute files, Nikolay might
have a solution after he is back from vacation.
This should help your  immediate problem with group_fwd_mask.