link deleted from cache when removed from a bridge

[Andrew Kraslavsky]

> > Everything works great until I remove an interface from a bridge using brctl, e.g.:
> >
> > brctl delif br0 eth2
> >
> > I then see an unexpected interface deletion event for eth2 as logged by the link_cb callback function and eth2 is removed from the link_cache cache (I can see this when I ask my program to dump the current contents of link cache).
> >
> > As an experiment, I added a nl_cache_refill() call to my program when it sees that eth2 has been deleted and verified that eth2 then shows up in the refilled cache.
> >
> > My guess is that this deletion event is really just supposed to mean that eth2 is no longer part of bridge br0 but that the event is being taken to mean that eth2 has been deleted from the system.
>
> Yes.
>
> > Is this actually the expected behavior?
>
> No, this is a bug.
>
> > If it helps, I would be _very_ happy to use libnl to manage the bridge through my program.  Meaning, if this problem is occurring because brctl uses ioctl calls and there are libnl calls I can use instead that would avoid the problem, that would be great!
> >
>
> Could you run your program with the NLCB=debug environment variable set and send me
> the output which is produced during the brctl delif operation takes places?

Here's the output. In this case, physical Ethernet interface eth5 was removed
from bridge br6.

The ifindex of eth5 is 7 and the ifindex of br6 is 11 (0x0b) and I see that
the "master" field of the eth5 link is set to that value.

-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 80
    .nlmsg_type = 17 <route/link::del>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 0
    .nlmsg_pid = 0
  [PAYLOAD] 16 octets
    07 00 01 00 07 00 00 00 03 10 00 00 00 00 00 00       ................
  [ATTR 03] 5 octets
    65 74 68 35 00                                        eth5.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 10] 4 octets
    0b 00 00 00                                           ....
  [ATTR 04] 4 octets
    dc 05 00 00                                           ....
  [ATTR 16] 1 octets
    02                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 01] 6 octets
    00 90 7f 82 66 90                                     ....f.
  [PADDING] 2 octets
    00 00                                                 ..
---------------------------  END NETLINK MESSAGE   ---------------------------

I don't know if it will be of any help but here's the output for earlier
when eth5 was added to br6:

- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 88
    .nlmsg_type = 16 <route/link::new>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 0
    .nlmsg_pid = 0
  [PAYLOAD] 16 octets
    07 00 01 00 07 00 00 00 03 10 00 00 00 00 00 00       ................
  [ATTR 03] 5 octets
    65 74 68 35 00                                        eth5.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 10] 4 octets
    0b 00 00 00                                           ....
  [ATTR 04] 4 octets
    dc 05 00 00                                           ....
  [ATTR 16] 1 octets
    02                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 01] 6 octets
    00 90 7f 82 66 90                                     ....f.
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 12] 1 octets
    00                                                    .
  [PADDING] 3 octets
    00 00 00
---------------------------  END NETLINK MESSAGE   ---------------------------