On Tue, Jul 28, 2015 at 4:10 AM, Nikolay Aleksandrov
<ra...@blackwall.org> wrote:
> From: Nikolay Aleksandrov <niko...@cumulusnetworks.com>
>
> Since mdb states were introduced when deleting an entry the state was
> left as it was set in the delete request from the user which leads to
> the following output when doing a monitor (for example):
> $ bridge mdb add dev br0 port eth3 grp 239.0.0.1 permanent
> (monitor) dev br0 port eth3 grp 239.0.0.1 permanent
> $ bridge mdb del dev br0 port eth3 grp 239.0.0.1 permanent
> (monitor) dev br0 port eth3 grp 239.0.0.1 temp
> ^^^
> Note the "temp" state in the delete notification which is wrong since
> the entry was permanent, the state in a delete is always reported as
> "temp" regardless of the real state of the entry.
>
Hmm?
I think it is iproute2 who forgets to set entry->state when deleting it?
} else if (strcmp(*argv, "permanent") == 0) {
if (cmd == RTM_NEWMDB)
entry.state |= MDB_PERMANENT;
Kernel simply returns what you pass to it.
Please fix iproute2.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
