This provides support for the new bridging attributes provided
in IFLA_PROTINFO while maintaining backwards compatibility
with older kernels.
A set of new API functions are exported to access the bridging
information. rtnl_link_bridge_has_ext_info() can be used to
check whether a bridge object has been constructed based on
the newly available attributes or the old message format.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
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>
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>
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.
Signed-off-by: Shrijeet Mukherjee <shm@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
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>
This patch adds a new api rtnl_linl_af_data_compare to
compare link af_data
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
This patch adds support for ao_compare operation
to bridge link af data operations.
Adds field ce_mask to struct bridge_data to work
with the ATTR attributes. I can submit separate
patches to introduce mask field to ATTR macros.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
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>
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>
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.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
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>
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>
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>
This patch adds keygen function to the neigh object
Signed-off-by: Shrijeet Mukherjee <shm@cumulusnetworks.com>
Signed-off-by: Nolan Leake <nolan@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
This patch adds keygen function to link cache
Signed-off-by: Shrijeet Mukherjee <shm@cumulusnetworks.com>
Signed-off-by: Nolan Leake <nolan@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Based on clang diagnostics:
1. lib/nl.c: recvmsgs(): nla filling with zeros commented.
2. lib/route/classid.c: & lib/route/pktloc.c:
remove zero-filling of struct stat
3. lib/route/qdisc/htb.c: Fix htb_qdisc_msg_fill(): fix zero-filling
4. ematch/container.c: container_parse:
commented why only 4 bytes are copied
len marked as unused to eliminate compiler warning
New functions:
rtnl_link_set_group(link, group)
rtnl_link_get_group(link)
The group identifier is printed in the brief section as "group N"
Signed-off-by: Thomas Graf <tgraf@redhat.com>
1. According to man asprintf:
If memory allocation wasn't possible, or some other error occurs,
these functions will return -1, and the contents of strp is undefined.
2. Sometimes, errp was not filled at all. In high-level code, free(errp)
will called, so segmantation fault may appear in case of error in parser
3. The most cases of using asprintf is to report about allocation fail.
So, probability of allocation of asprintf buffer is very high. And that
will lead to trash in errp.
4. For simple casses I decide to replace asprintf with strdup
On some architectures, uint64_t is defined as:
typedef unsigned long long int __u64;
on another architectures as:
typedef unsigned long int __u64;
So, according to man 3 printf,
uint64_t should be printed as "%llu" on some architectures, and as "%lu" on another. The same for scanf.
To eliminate that challenge, there is inttypes.h, in which appropriate constants
are defined for current architecture.
32-bit types (and even 16 and 8 bit types) should be printed using such constants if
printed variable defined as uint_XXXt or intXXXt type. But in reality 32-bit and less
types does not gain run-time error (except in scanf), because they pushed to stack as
32-bit values at least. So, I decide not to fix that.
I ran into a bug today related to how Linux handles a route's nexthop
flags when there is just one nexthop. Namely Linux expects the flags
to be OR'd into the rtm_flags field when there is only one nexthop and
so rtnl_route_build_msg needs to check the number of nexthops and
store the nexthops flags into this field prior to calling
nlmsg_append(...&rtmsg).
Conversely the rtnl_route_parse function needs to pull these lower
0xff bits when a single nexthop is detected.
Attached is my patch. I don't like the slight duplication of doing
the rtnl_route_get_nnexthops check twice but it seemed to be the least
turmoil of any solution I thought of.
