b06c23a9dd
This patch reverts back the AF_UNSPEC check introduced by AF_BRIDGE changes at http://lists.infradead.org/pipermail/libnl/2012-November/000796.html After the addition of AF_BRIDGE support, link cache can now contain objects of type AF_BRIDGE. To make sure existing api's did not return AF_BRIDGE objects and surprise existing callers, I introduced the check for AF_UNSPEC. But from what Andy Wang reported, rtnl_link_get_by_name returns the first link object with matching ifindex and that could have not only been AF_UNSPEC but also of family AF_INET6. And his app always got an AF_INET6 object prior to the patch that introduced the AF_UNSPEC check. I could just add AF_INET6 family check along with AF_UNSPEC in the apis and that should work well. But thinking about it some more, removing the AF_UNSPEC change seems to be safer at this point. That way this api will retain its semantics and return the first object with matching ifindex. It could be of any supported family. The user will know if the cache contains bridge objects, because they are available only with the cache flag NL_CACHE_AF_ITER. Besides, if new users want to search for a specific object, nl_cache_find is a better option. Reported-by: Andy Wang <Andy.Wang@watchguard.com> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: Thomas Graf <tgraf@suug.ch> |
||
|---|---|---|
| doc | ||
| etc | ||
| include | ||
| lib | ||
| m4 | ||
| man | ||
| python | ||
| src | ||
| tests | ||
| .gitignore | ||
| COPYING | ||
| ChangeLog | ||
| Makefile.am | ||
| autogen.sh | ||
| configure.ac | ||
| libnl-3.0.pc.in | ||
| libnl-cli-3.0.pc.in | ||
| libnl-genl-3.0.pc.in | ||
| libnl-nf-3.0.pc.in | ||
| libnl-route-3.0.pc.in | ||