Thomas Graf [Fri, 1 Feb 2013 09:41:45 +0000 (10:41 +0100)]
neigh: Remove check for AF_UNSPEC in rtnl_neigh_get()
This check was introduces to not accidently return AF_BRIDGE objects
to unaware API users as they do differ in structure. However, such
objects are only available if explicitely requests using the
NL_CACHE_AF_ITER flag or by using arg1 == AF_BRIDGE for the cache.
Therefore remove this check and allow rtnl_neigh_get() to be used to
fetch any neighbor object of a cache.
Reported-by: Maxime Bizon <mbizon@freebox.fr> Signed-off-by: Thomas Graf <tgraf@suug.ch>
roopa [Mon, 28 Jan 2013 15:46:16 +0000 (07:46 -0800)]
link cache: remove AF_UNSPEC check in rtnl_get_link and rtnl_get_link_by_name
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>
This commit causes a regression so no app using libnl can be compiled
against it. This patch fixes it by removing includes of no-longe
existing headers.
Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Thomas Graf <tgraf@suug.ch>
roopa [Thu, 17 Jan 2013 14:48:59 +0000 (06:48 -0800)]
route cache: This patch adds route priority to route object oo_id_attrs
The kernel allows multiple entries in the main table which differ in the
priority value. In libnl currently, since priority is not part of the base
netlink route message, it is not used as part of the key. This patch
includes priority in the key/oo_id_attrs and defaults the value to zero
for messages where priority is not included.
One point to note is that the actual selection of route from multiple
options is done implicitly in the kernel by storing the routes in sort
priority order, but there is no explicit communication to a client of libnl
of that.
Thomas Graf [Tue, 22 Jan 2013 18:10:38 +0000 (19:10 +0100)]
No longer install module API headers
Various header files providing an API to implement own cache and
object types or implement link types have been available in the
past. Their API is marked unstable in the documentation and nobody
is using them so far.
Technically they have been causing ABI breakages in at least two
3.2.x releases. In order to avoid future accidental breakage, no
longer install these and require module developers to clone the
git tree and build modules off the git tree directly to make sure
that the API is unstable at this point.
Thomas Graf [Tue, 22 Jan 2013 18:07:09 +0000 (19:07 +0100)]
Undo soname bump
The soname was bumped before 3.2.18 was released to reflect
an ABI change in the cache and object API.
This caused a discussion with various distribution maintainers
involved as it prevented them from including the release in
their stable branches. This is especially unfortunate as the
corresponding API is unused outside of libnl as of now.
For this reason, I have decided to undo the soname bump and
instead remove the corresponding header files from the list of
installable headers and thus remove them from the public API.
This is a API break technically but since nobody is using
them it should not matter. If you are in fact using any of the
*-api.h headers please let me know and we are most likely to
start a new development branch.
If your application linked against 3.2.18 or 3.2.19 you will need
to relink if you want it to use >= 3.2.20.
roopa [Fri, 18 Jan 2013 00:29:04 +0000 (16:29 -0800)]
link: Add af data compare to link objects
Today the link compare function does not
compare af data of a link. We have found a
need for this to get approriate change callbacks
when af_data of a link changes.
This patch adds support to compare af_data
to link_compare function. This patch today
only adds support to compare af_data set by
PROTINFO attributes. It can be extended to
support compares of af_data set by AF_SPEC
attributes
It has been tested for AF_BRIDGE objects.
In case of AF_BRIDGE objects, this helps with
bridge port change notification callbacks.
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
roopa [Tue, 8 Jan 2013 13:29:08 +0000 (05:29 -0800)]
link af ops: Add new ao_compare op to compare link af_data
This patch adds new operation to compare link af_data.
ao_compare is similar to object oo_compare operation.
This op can be used when two links are compared
for their af data. It takes two link objects in
question, an object specific bitmask defining which
attributes should be compared and flags to control
the behaviour. The function must return a bitmask
with the relevant bit set for each attribute that mismatches.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
cache: make sure the user has specified a callback
In cache_include(), the user callback is used even though one might not
have been specified, leading to a crash. This happens, for example, when
NetworkManager calls nl_cache_include() with the change_cb argument set
to NULL. Fix it by making sure the callback points to a valid address.
Signed-off-by: Mihai Dontu <mihai.dontu@gmail.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Eric Paris [Thu, 3 Jan 2013 19:26:00 +0000 (14:26 -0500)]
nlmsg_ok comparison between signed and unsigned
The nlmsg_ok macro has a comparison between an int and a size_t
(unsigned int). The C spec says the int is cast to unsigned int before
the comparison. This is a problem as the audit system will send skb's
with skb->len == nlhhdr->nlmsg_len which are NOT aligned. Thus you can
end up with remaining being negative. So the comparison becomes
(unsigned int)(-1) >= (unsigned int)16
Which turns out to be true! It should clearly be false. So if we cast
the size_t to an int we get a signed comparison and it works. (This is
what linux/netlink.h and all of the kernel netlink headers do)
Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
roopa [Fri, 21 Dec 2012 02:32:00 +0000 (18:32 -0800)]
cache pickup: Avoid duplicates during cache pickup
This patch adds search and replace/update functionality
to cache pickup_cb. This change is required to avoid
duplicates getting into the cache during pickup. Also
helps updating existing objects during cache pickup.
We have seen this in cases of ipv6 equal cost multipath
routes
The current code does a rtnl_link_put on new object instead of
old object. This patch fixes it. None of the caches have support
for object update, so this should not have affected anyone yet.
roopa [Thu, 13 Dec 2012 05:50:49 +0000 (21:50 -0800)]
route cache: Fix handling of ipv6 multipath routes
There are two ways kernel handles ipv6 equal cost multipath routes
depending on which kernel version you are looking at.
older kernels without ipv6 ECMP support, accept the below ECMP routes,
#ip -6 route add 2001::/16 nexthop via fe80:2::2 dev swp1
#ip -6 route add 2001::/16 nexthop via fe80:2::3 dev swp1
store them as separate routes and pick the last one during lookup.
Newer kernels, after the support for equal cost multipath routes
was added http://patchwork.ozlabs.org/patch/188562/,
now accept multipath routes added individually using the
above 'ip -6 route' format OR
sent using RTA_MULTIPATH with the below command
#ip -6 route add 2001::/16 nexthop via fe80:2::2 dev swp1 nexthop via fe80:2::3 dev swp1
And the kernel now stores and treats them as equal cost multipath routes
during lookups.
However in all cases above, netlink notifications to ipv6 ECMP route adds and deletes
come separately for each next hop.
Example libnl notification in the above case with both old and new kernels:
inet6 2001::/16 table main type unicast
scope global priority 0x400 protocol boot
nexthop via fe80:2::2 dev swp1
inet6 2001::/16 table main type unicast
scope global priority 0x400 protocol boot
nexthop via fe80:2::3 dev swp1
Since they are separate route notifications for objects with same key,
libnl replaces the existing ones and hence only the last route update sticks.
This patch uses the oo_update feature to not replace but update an
existing route if its a ipv6 equal cost multipath route.
The object after an update looks like the below (similar to ipv4 ECMP routes):
inet6 2001::/16 table main type unicast
scope global priority 0x400 protocol boot
nexthop via fe80:2::2 dev swp1
nexthop via fe80:2::3 dev swp1
Signed-off-by: Shrijeet Mukherjee <shm@cumulusnetworks.com> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by: Nolan Leake <nolan@cumulusnetworks.com> Reviewed-by: Wilson Kok <wkok@cumulusnetworks.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
Compiling libnl versions that include doc or the git tree produce this
checking for python build information...
checking for python2.6... python2.6
checking for main in -lpython2.6... yes
checking python2.6/Python.h usability... yes
checking python2.6/Python.h presence... yes
checking for python2.6/Python.h... yes
./configure: line 4272: test: !=: unary operator expected
checking for python2.5... (cached) python2.6
checking for main in -lpython2.6... (cached) yes
checking for python2.6/Python.h... (cached) yes
./configure: line 4272: test: !=: unary operator expected
checking for python2.4... (cached) python2.6
checking for main in -lpython2.6... (cached) yes
checking for python2.6/Python.h... (cached) yes
./configure: line 4272: test: !=: unary operator expected
checking for python2.3... (cached) python2.6
checking for main in -lpython2.6... (cached) yes
checking for python2.6/Python.h... (cached) yes
./configure: line 4272: test: !=: unary operator expected
checking for python2.2... (cached) python2.6
checking for main in -lpython2.6... (cached) yes
checking for python2.6/Python.h... (cached) yes
./configure: line 4272: test: !=: unary operator expected
checking for python2.1... (cached) python2.6
checking for main in -lpython2.6... (cached) yes
checking for python2.6/Python.h... (cached) yes
./configure: line 4272: test: !=: unary operator expected
checking for python... (cached) python2.6
checking for main in -lpython2.6... (cached) yes
checking for python2.6/Python.h... (cached) yes
./configure: line 4272: test: !=: unary operator expected
results of the Python check:
Binary: python2.6
Library: python2.6
Include Dir: no
Fix the unary operator warning allow to break when one python version is found
Add the more recent python versions
Change send upstream as http://savannah.gnu.org/patch/index.php?7897 Signed-off-by: Thomas Graf <tgraf@suug.ch>
Controller Area Network (CAN) is a networking technology which has
widespread use in automation, embedded devices and automotive fields.
The socket-CAN package is an implementation of CAN protocols for Linux.
All socket-CAN related configurations are carried out through Netlink.
Add basic socket-CAN support to libnl to be able to configure CAN devices
with libnl.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de> Signed-off-by: Thomas Graf <tgraf@suug.ch>
On openSUSE, /usr/bin/lex is a wrapper that calls `flex -l ...`.
libnl however requires flex, not lex or a compat mode thereof,
so using ${FLEX} is the proper thing to do.
Jan Engelhardt [Mon, 26 Nov 2012 19:49:02 +0000 (20:49 +0100)]
build: resolve automake-1.12 warnings
/usr/share/automake-1.12/am/ltlibrary.am: warning: 'libnl-cli-3.la':
linking libtool libraries using a non-POSIX archiver requires
'AM_PROG_AR' in 'configure.ac'
(one for each .la file)
Thomas Graf [Mon, 26 Nov 2012 10:50:56 +0000 (11:50 +0100)]
cache: only continue iterating over co_groups if it is available
A co_groups == NULL must enter the loop to trigger the initial
fill of the cache but may never bump the grp pointer as doing
so prevents the loop from being escaped correctly.
roopa [Mon, 19 Nov 2012 06:14:23 +0000 (22:14 -0800)]
Bug Fix: Add new fill socket to cache manager
This patch adds a new socket to cache manager to request fill's on.
cache manager today uses cm_sock to request dump from
the kernel. It also listens to netlink async events on the same sock.
The problem with this is that when libnl is waiting to process the
response to get dump request sent to the kernel during fill,
it may receive an async event, resulting in libnl complaining about
unexpected msg
This is usually reproducible when there is heavy netlink async event
traffic during nl_cache_mngr_add.
This patch adds a new cm_sync_sock to use for fill during cache manager
add cache.
The other option is to provide an api to set the cm_sync_sock. But since
this is a bug fix its probably better to fix the cache manager add api
like this patch does. Please suggest otherwise.
Thomas Graf [Fri, 16 Nov 2012 00:11:55 +0000 (01:11 +0100)]
cache: provide safe variant of nl_cache_mngt_require() and use it
This makes runtime removal of cache operations possible if non-safe
API is not in use by application. The non-safe API will be removed
in the next major version.
roopa [Wed, 14 Nov 2012 19:33:51 +0000 (11:33 -0800)]
Add master support to rtnl_neigh for AF_BRIDGE objects
AF_BRIDGE neigh objects can be uniquely identified by
the family, lladdr and bridge ifindex. This patch adds
bridge ifindex to AF_BRIDGE neigh objects.
Things will be ok even without this patch with just family and
lladdr if we assume that we will have unique lladdr's
accross bridges in a system.
Kernel does not send the bridge ifindex in the AF_BRIDGE
fdb/neigh message. This patch tries to get that info by a
link cache lookup and adds it to the bridge neigh object
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by: Nolan Leake <nolan@cumulusnetworks.com> Reviewed-by: Shrijeet Mukherjee <shm@cumulusnetworks.com> Reviewed-by: Wilson Kok <wkok@cumulusnetworks.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
roopa [Wed, 14 Nov 2012 19:33:50 +0000 (11:33 -0800)]
Add AF_BRIDGE support to neigh cache
This patch adds AF_BRIDGE to the list of families
supported by the cache. Implements oo_id_attrs_get to
declare separate id attributes for AF_UNSPEC and AF_BRIDGE
neigh objects
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by: Nolan Leake <nolan@cumulusnetworks.com> Reviewed-by: Shrijeet Mukherjee <shm@cumulusnetworks.com> Reviewed-by: Wilson Kok <wkok@cumulusnetworks.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
roopa [Wed, 14 Nov 2012 14:06:41 +0000 (06:06 -0800)]
Add AF_BRIDGE support to link cache
This patch was previously submitted as the first approach in
RFC http://lists.infradead.org/pipermail/libnl/2012-November/000730.html
It adds support for AF_BRIDGE family in link cache.
And the key for link object lookups will now be ifindex and family.
This allows for AF_UNSPEC rtnl link objects to co-exist with the AF_BRIDGE
link objects in the same cache.
I have changed some of the rtnl_link api's to explicitly check for
AF_UNSPEC to not break existing apps. I will submit a new patch to
introduce equivalent rtnl_bridge_link_* api's.
We had also discussed updating the existing link objects with
AF_BRIDGE attributes, but realized that the updates to link objects will
be both AF_UNSPEC and AF_BRIDGE. And that would change link cache to always
update existing objects, resulting in comparing and updating close to
thirty attributes at cache_include time which seems like a overkill.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by: Nolan Leake <nolan@cumulusnetworks.com> Reviewed-by: Shrijeet Mukherjee <shm@cumulusnetworks.com> Reviewed-by: Wilson Kok <wkok@cumulusnetworks.com> Signed-off-by: Thomas Graf <tgraf@suug.ch>
roopa [Mon, 12 Nov 2012 20:38:33 +0000 (12:38 -0800)]
Add NL_CACHE_AF_ITER support during refill and resync
This patch adds support to iter over all supported families
during cache fill and resync.
The motivation for this was previously introduced at
http://lists.infradead.org/pipermail/libnl/2012-November/000734.html
In short, this patch allows caches to request dump on all supported
families instead of only AF_UNSPEC as done today.
With feedback from thomas this patch makes the iter over all families
conditional on per cache flag NL_CACHE_AF_ITER
roopa [Mon, 12 Nov 2012 20:38:32 +0000 (12:38 -0800)]
New cache manager add cache api
This patch is an attempt to add a new nl_cache_mngr_add_cache api
to allow adding an existing cache to cache manager.
Since the new api is similar to nl_cache_mngr_add
except for allocating the cache, the patch moves most of the
nl_cache_mngr_add code to nl_cache_mngr_add_cache and changes
nl_cache_mngr_add to call nl_cache_mngr_add_cache.
One use case for this api as pointed out by thomas would be to set cache
flags before associating the cache with a cache manager.
projects / libnl / log