-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bridge object in link cache may get replaced by an incomplete object #377
Comments
Grepping through the code, I guess this message comes from rtnl_bridge_notify(), which only sends a minimal message:
I guess the proper solution would be to have a oo_update() that can merge this message into the existing object? |
Scratch that, looking at This implies this comes from
which sends an update with just the VLAN info filled. And no |
That sounds right. |
I observed the link cache sometimes returning an incomplete object of family
AF_BRIDGE
, but with no link type set (and thus any rtnl_link_bridge_* call triggering an assert).This happens shortly after creation and attaching a port to a bridge.
Running with
NLCB=debug
, the following messages can be seen:complete bridge object ("good" kernel message) => link cache returns a full object
but shortly after that the kernel sends a short message with incomplete bridge state:
Note how
[ATTR 26]
is basically empty, andl_family
is set to 07 /AF_BRIDGE
.While the first message has
l_family
set 00 /AF_UNSPEC
, libnl changes this to 07 /AF_BRIDGE
based on theIFLA_INFO_KIND
"bridge" in[ATTR 18]
.This then causes the previous full bridge object in the link cache to be replaced with an empty one based on the short message.
Not sure what the correct course of action here is. Ignore the short message? Update the bridge object instead of replacing it? If we wouldn't replace the
l_family
based on the value inIFLA_INFO_KIND
, both objects would co-exist and there would be no issue, but likely not doing that would now break the API and users.FWIW, this is libnl 3.8 with kernel 6.6, though the behavior also exists in 6.1.
The text was updated successfully, but these errors were encountered: