In the current code if rtnl_link_af_data_compare returns value > 0
we mark PROTINFO attribute in the diff mask and return without
comparing flags.
This patch makes af_data to be the last thing we compare.
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 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>
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 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>
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 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>
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>
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.
- changes the modules hierarchy to better represent the set of libaries
- list the header file that needs to be included
- remove examples/doc from api ref that is included in the guide
- add references to the guide
- fix doxygen api linking for version 1.8.0
- readd doxygen mainpage to config file
- fix a couple of doxygen doc bugs
In a simple test program that queries the source IP for a given
destination address I get a crash in the call to rtnl_link_alloc_cache.
Here is the stack trace (created with version 3.2.4):
Program received signal SIGSEGV, Segmentation fault.
0xb7eb7553 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7eb7553 in strlen () from /lib/libc.so.6
#1 0xb7eb7285 in strdup () from /lib/libc.so.6
#2 0xb7fcc305 in nla_strdup (nla=0x0) at attr.c:1033
#3 0xb7f9c173 in link_msg_parser (ops=0xb7fc2940, who=0x804b330, n=0x804c3e8, pp=0xbffffbf8) at route/link.c:486
#4 0xb7fcd485 in nl_cache_parse (ops=0xb7fc2940, who=0x804b330, nlh=0x804c3e8, params=0xbffffbf8) at cache.c:724
#5 0xb7fcd547 in update_msg_parser (msg=0x804b328, arg=0xbffffbb8) at cache.c:531
#6 0xb7fd1f25 in nl_cb_call (cb=<optimized out>, msg=<optimized out>, type=<optimized out>) at ../include/netlink-local.h:126
#7 recvmsgs (cb=<optimized out>, sk=<optimized out>) at nl.c:729
#8 nl_recvmsgs (sk=0x804b2d0, cb=0x804b368) at nl.c:780
#9 0xb7fcd5fd in __cache_pickup (sk=0x804b2d0, cache=<optimized out>, param=0xbffffbf8) at cache.c:560
#10 0xb7fcd83f in nl_cache_pickup (sk=0x804b2d0, cache=0x804b308) at cache.c:593
#11 0xb7fcd8c8 in nl_cache_refill (sk=0x804b2d0, cache=0x804b308) at cache.c:780
#12 0xb7f9d1fc in rtnl_link_alloc_cache (sk=0x804b2d0, family=4, result=0xbffffcd4) at route/link.c:868
#13 0x08048fd0 in libnl_init (data=<optimized out>) at helper_route.c:60
#14 iproute_get_source (destination=0xbffffeff "127.0.0.1",
source=0xbffffd0f "\b\004c\370\267\364_\370\267\260\224\004\b8\375\377\277e\024\347\267\320\016\377\267\273\224\004\b\364_\370\267\260\224\004\b", source_size=17)
at helper_route.c:105
#15 0x08048e6a in main (argc=2, argv=0xbffffde4) at ip_route_get.c:25
The attached patch (against 3.2.4) solves the problem, fixing something that
looks like a typo. The bug is still present in current Git master.
store type kind in rtnl_link independently. That would allow to use this
value even if type_ops are not present. This allows for example to
create devices of type unknown to libnl.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Adds rtnl_link_enslave() / rtnl_link_release() providing a genreic
link enslaving/release API for use with all link types which use
the IFLA_MASTER property.
- avoid unncessary name change requests
The kernel does not check if the specified IFNAME is different
from the current name. It assumes that if IFNAME and ifindex
are both specified, a name change is requested. Therefore avoid
specyfing IFNAME if ifindex is provided and original and new
name are identical.
- move link building to own function (to allow link add later on)
- error if immutable changes have been made
- better documentation
Provide nl_pickup() to pick up an answer from a netlink request and parse
it using the supplied parser.
Add rtnl_link_get_kernel() which sends an RTM_GETLINK to the kernel to
fetch a single link directly from the kernel. This can be faster than
dumping the whole table, especially if lots of links are configured.
Note: The code for this is not upstream yet.
Extends the link api to allow address family modules to fill a link
message and implements a AF_INET address family link module which
uses the new interface.
This feature isn't upstream yet. It's required to test a patch in
my local tree.
Makes the link parser understand IFLA_AF_SPEC and call the address
family specific parser.
