Assuming that the kernel does not send more than a page is no longer valid,
and enabling MSG_PEEK'ing by default to figure out the exact message buffer
requirements can have a negative influence on the performance of existing
applications. Bumping the default receive buffer space to 4 pages seems
a sane default.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
rtnl_link_af_unregister() attempts to write-lock info_lock twice
instead of releasing it before returning. It also will return with
info_lock write-locked if passed a NULL ops.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
There seams to be an error in the calculation of needed space for the message in nla_reserve. The current size of the message is counted twice: Once in NLMSG_ALIGN, once in the condition below.
This causes nla_put_* calls to be rejected if the allocation size of the message has been strictly calculated by the caller.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
- each *_get() should have corresponding *_put(). That rule was broken in nl_socket_alloc()
- Also, check if cb is NULL in nl_socket_set_cb (calls BUG())
Passing a NULL pointer would cause a NULL pointer dereference within
nl_object_free().
Returning early on NULL pointer is the behavior free(3) and other
nl*_free() functions.
Signed-off-by: Emmanuel Roullit <emmanuel.roullit@gmail.com>
Previously 0 was returned which gave the caller no chance of detecting
when a non-blocking socket would block. If a caller intends to never
see an error message it should utilize poll()/select() to only read
when the socket has pending data or information.
Reported-by: Holger Eitzenberger <holger@eitzenberger.org>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Add ICMPv6 type, code and ID (if set) by using the already available
conntrack atttributes.
Currently the ICMPv6 conntrack objects in libnl are without type, code
and ID. This e. g. is the output of nl_object_dump() without the patch:
ipv6-icmp ::1 <-> ::1
id 0xdd0871f0 family inet6 timeout 30s <NOREPLY,SNAT_INIT,DNAT_INIT>
The attached patch tries to solve that. It then looks like
ipv6-icmp ::1 <-> ::1 icmp type 128 code 0 id 28253
id 0xdf3a11f0 family inet6 timeout 30s <SNAT_INIT,DNAT_INIT>
It is the 'small' approach, because it reuses the existing ICMP
attributes of the conntrack object (currently only used for IPv4).
This way I can avoid to add new _icmp6_get_, _icmp6_set_ and
_icmp6_test_ functions.
Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
The cache layer uses the message type array stored in the cache
ops to lookup which cache a message belongs to. Update to the
the message array with the resolved generic netlink id to make
it compatible with the caching API.
Allows to use nl_cache_refill() and others for generic netlink
based caches with dynamic generic netlink ids.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Previously if using rtnl_addr_set_prefixlen() the new prefix length
was not forwarded to the corresponding 'struct nl_addr' objects
associated with address already and thus the comparison function
would fail.
This patch also clears the internal ADDR_ATTR_PREFIXLEN flag if
the prefix length has been reset.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
memset() the binary address before overwriting it with new data
to avoid leaving around old portions of the address.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Use a debugging message to warn applications if an attribute is
found multiple times in the same message. It is perfectly valid
to rely on this behaviour but it is likely to indicate a bug.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
This patch fixes a bug where because of the af_ops check
being first in the function, we were returning ~0 if af_ops
was null even if both objects really did not have af_data
and we should be returning 0.
Its better to have the af_data present check before anything else.
So, Rearranged some of the code in rtnl_link_af_data_compare.
Changes include:
- Do the attribute present check before anything else
- If ao_compare op not present, return ~0
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>
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 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>
Thomas Graf