Giter Site home page Giter Site logo

libnl's People

Contributors

bengal avatar congwang avatar d0u9 avatar dsahern avatar gobenji avatar holyshitman avatar ice799 avatar jef-oliver-intel avatar jengelh avatar jonasj76 avatar kaber avatar kanjimonster avatar lekensteyn avatar lxerandrew avatar michael-dev avatar michaelforney avatar rmfought avatar roopa-prabhu avatar socketpair avatar spellingmistake avatar stv0g avatar tgraf avatar thom311 avatar thomasjwinter avatar tklauser avatar troglobit avatar vaesoo avatar villemoes avatar voldymyr avatar zstas avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libnl's Issues

vlan_put_attrs missing IFLA_VLAN_PROTOCOL

The vlan_put_attrs function in lib/route/link/vlan.c is missing:

    if (vi->vi_mask & VLAN_HAS_ID)
        NLA_PUT_U16(msg, IFLA_VLAN_ID, vi->vi_vlan_id);

+   if (vi->vi_mask & VLAN_HAS_PROTOCOL)
+       NLA_PUT_U16(msg, IFLA_VLAN_PROTOCOL, vi->vi_protocol);

    if (vi->vi_mask & VLAN_HAS_FLAGS) {
        struct ifla_vlan_flags flags = {
            .flags = vi->vi_flags,
            .mask = vi->vi_flags_mask,
        };

Because of this the protocol value set by rtnl_link_vlan_set_protocol is not passed to the kernel and only 802.1Q interfaces can be created.

genl_connect fails with NLE_EXIST

Hi
I am new to libnl.My app uses libnl-3.2.22
We are using netlink with memory map.
In the app, the netlink socket is closed (nl_socket_free() ) on some
error condition and new netlink connection is established.
But I am seeing that genl_connect() is failing with -6 (NLE_EXIST
"Object exists") when i try to create new net link connection.
My guess is this is EADDRINUSE from bind inside genl_connect()
Should i set SO_REUSEADDR on netlink socket to resolve this error?
Or is this issue fixed in latest libnl version libnl-3.2.29 ?
Could you please help me resolve this issue?
Thanks

nl_recvmsgs return code issue

nl_recvmsgs returns success (0) even in case of no data is read (i.e if recvmsg returns 0 )

[ * @return 0 on success or a negative error code from nl_recv(). ]

Then how caller of nl_recvmsgs should get to know about remote close (remote closed is indicated by 0 returned from recvmsg ) ?
Instead ,nl_recvmsgs () should just return whatever nl_recv returns, so that now callers will get 0 when remote is closed.

regression - exposing nl_{msgtype,cache_ops,object}

Previous versions of libnl3 exposed nl_msgtype, nl_cache_ops and nl_object.
That way it was possible to use nl_cache_get_ops(arg) to overwrite co_include_event and define your own nl_cache_include.
In my case the default nl_cache_include was overwritten to get a copy of the old object, so I could compare which aspect of the object changed.

In current (3.2.23) version of libnl, the required structures are private and can not be used. As there is no workaround other than using an old version of libnl or copying the required declarations into my own project, I'd appreciate if this regression could be resolved by exposing the mentioned structures again.

NFQUEUE: payload length C type

nfnl_queue_msg_send_verdict_payload() : length argument decalred as unsigned
iov[2].iov_len = NLA_ALIGN(payload_len); - so, length is size_t
nfnl_queue_msg_get_payload(): returned payload length is just int

Seems, the most good type for that -- is size_t. Should I make a patch for that? This may break ABI. So, in order not to break one, I can fix all that places to use uint32_t

NFQUEUE: ENOBUF is reported as ENOMEM

case ENOBUFS: return NLE_NOMEM;
:

int nl_syserr2nlerr(int error)
...
    case ENOBUFS:       return NLE_NOMEM;
    case ENOMEM:        return NLE_NOMEM;
...

This is a bug, as I think.
ENOBUFS - is not the same as "Out of memory". Example -- receiving NFQEUEUE messages. When queue is overflowed, nl_recvmsgs_default() returns -5 (i.e. NLE_NOMEM) due to recvmsg() returns -1 and set errno to ENOBUFS. Is it indistinguishable from real out of memory situation.

Can you add NLE_ENOBUFS or something like that ?

nl_recvmsgs() does not inform caller when other end closes connection

Hi
I am new to libnl.
We are using libnl-3.2.22
i am seeing issue where my app goes to 100% cpu utilization and when i looked further i see that i am getting lots of EPOLLERR in epoll_wait()ing on netlink socket.
we are using non-blocking netlink socket

I have few queries

  1. From comments in nl_recv()

++
nl_recv()
..

  • This function blocks until data is available to be read unless the socket
  • has been put into non-blocking mode using nl_socket_set_nonblocking() in
  • which case this function will return immediately with a return value of 0.

++
but this comment seems not true when i see code.

Is this old comment and needs to be updated ?

  1. In case where socket is non-blocking and recvmsg() returns 0 (this happens when we get EPOLLERR on that soket), do libnl APIs inform caller when other end closes connection i.e when recvmsg() inside nl_recv return 0 ?
    libnl doesnot seem to have a way to let app know about this case.

Due to this my app does not know about connection closure

  1. Why am i getting EPOLLERR in epoll_wait() on netlink socket ? is this because other side of netlink ie kernel side closed connection ?
    even if kernel side closed connection why non-stop repeated EPOLLERR s on netlink sockets ?

Appreciate your comments on this
Thanks
Prashant

link: set ifi_change in rtnl_link_build_add_request

Should rtnl_link_build_add_request() (in lib/route/link.c) not also populate ".ifi_changes" of the "ifi" struct? Not populating the mask makes it impossible to to use rtnl_link_add() to unset the IFF_UP flag to bring the interface down (which is supported by the kernel). I found there was a similar issue with rtnl_link_change() before, and the "add" case may have simply been missed when fixing it: https://github.com/thom311/libnl/commit/34ccb7210f1238f89229c117dc3d28cea7ae00bb

I have found that this change (in bold) resolved the issue for me:

int rtnl_link_build_add_request(struct rtnl_link _link, int flags,
struct nl_msg *_result)
{
struct ifinfomsg ifi = {
.ifi_family = link->l_family,
.ifi_index = link->l_index,
.ifi_flags = link->l_flags,
.ifi_change = link->l_flag_mask,
};

return build_link_msg(RTM_NEWLINK, &ifi, link, flags, result);

}

I am new to using libnl, so if I am mistaken, I sincerely apologise.

High socket recv buffer usage and size

Hi,

I have a application that listens to Netlink neighbor events using libnl. When I tested it receiving about 1000 simultaneous NEWNEIGH events, I noticed that my application was missing some of them.

While debugging it, I could see in /proc/net/netlink that my socket had some drops and that nl_recvmsgs_default was returning -5 (ENOMEM) confirming the missing events. Debugging it further I've found out that libnl is remapping -5 from 105 which is ENOBUFS in the socket recv function. So to fix the problem I had to increase my receive buffer using nl_socket_set_buffer_size and also the Linux limit (using sysctl net.core.rmem_max) since it was below what I need for nl_socket_set_buffer_size.

So this fixed my problem, but to handle all 1000 events I had to increase the buffer to 2MiB which, according to the SO_RCVBUF documentation, the Kernel effectively doubles it to 4MiB for bookkeeping overhead. This value seems too high since each Netlink event is less that 100 bytes long (about 80 from what I saw in the libnl's debug messages). So is my buffer size correct for what the number of events I am expecting, the Kernel really needs that much or am I missing something?

Thanks,
CB

Private function nl_strerror_l exported in dynamic lib

Commit 683f27f ("lib: add utility function nl_strerror_l()") introduced a new helper function nl_strerror_l, advertised as private.

But this function is exported in the dynamic lib:

$ objdump -T /usr/lib/libnl-route-3.so.200.24.0 | grep nl_strerror
0000000000000000      DF *UND*	0000000000000000  libnl_3_2_29 nl_strerror_l

Is this expected? It seems to cause issues downstream https://bugs.lede-project.org/index.php?do=details&task_id=748 (admittedly, in this case, it looks like bmon was compiled against a different version of libnl-route than the one installed, so it was likely to break)

NL_CB_MSG_OUT doesn't get triggered.

http://pastebin.com/bLdPSUXD

When executing this code, the callback function get executed only when I receive a msg and not when a msg is sent.
I already tried just set the callback to NL_CB_MSG_OUT with nl_cb_set() and it gaves the same result.

What's happening ?
Is this a bug ?
Thanks.

Use of cache manager not working

Hi,

I am new user and trying to use the cache manager, and the basic example in the test directory is not working, it is failing nl_cache_mngr_add with the error message of "unknown or invalid cache type" when I am trying to add the cache "route/link" or anything else like "route/addr" etc.

Can you please let me know what am I missing, I am able to do other things like get a cache dump or get individual link elements etc.

Thanks
jana

libnl does not compile with old kernel headers

Hi,

I notice that libnl would fail to build on my CentOS system. I dig up a little, and found out where the issues was.

The file lib/netfilter/exp_obj.c uses NF_CT_EXPECT_PERMANENT, NF_CT_EXPECT_INACTIVE and NF_CT_EXPECT_USERSPACE constants. The three of them appears to be defined within the linux/netfilter/nf_conntrack_common.h. However, these values were not defined prior to the Linux Kernel 2.6.37 and thus are not found within the kernel headers.

I don't quite know what's the best approach here. I attached a quick and dirty patch that make the compilation succeed on my side.

Regards,
Tony

stack question

Needed to know if there is any way in python/scapy to create a wireless access that links with the scapy TCP/IP stack so I can intercept communications flowing through the stack? What I am aiming to achieve is to create a wlan access point and use scapy to implement a system for sniffing packets sent to that interface and its clients and then choose to reject/accept packets based on rules, think firewall. I am not very skilled in python and my job does'nt even involve infosec or programming. This is a hobby that I have and I don't know as much as some of you guys reading this but I was hoping to find a solution to my problem.

rtnl_link_is_bridge not working

Hi, I am wrapping libnl3 for use with Racket at https://github.com/Mordae/racket-rtnl and it seems as if rtnl_link_is_bridge fails on newly obtained bridge link objects. For example:

-> (let ((virbr0 (rtnl-link-get/kernel socket -1 "virbr0")))
     (rtnl-link-is-bridge? virbr0))
#f

However, if I properly modify the link object, it seems to work fine:

-> (let ((virbr0 (rtnl-link-get/kernel socket -1 "virbr0")))
     (rtnl-link-set-family! virbr0 'bridge)
     (rtnl-link-is-bridge? virbr0))
#t

Is this to be expected? I mean, with VLAN interfaces I can confirm their type right away.

-> (let ((em1.123 (rtnl-link-get/kernel socket -1 "em1.123")))
     (rtnl-link-is-vlan? em1.123))
#t

3.2.24_rc1 - link_policy missing nl_ prefix on export

See:

https://bugzilla.gnome.org/show_bug.cgi?id=720902
https://bugs.gentoo.org/show_bug.cgi?id=494890

nm-ip6-manager.c:1262:26: error: static declaration of 'link_policy' follows
non-static declaration
static struct nla_policy link_policy[IFLA_MAX + 1] = {
^
In file included from /usr/include/libnl3/netlink/route/addr.h:20:0,
from nm-ip6-manager.c:28:
/usr/include/libnl3/netlink/route/link.h:101:26: note: previous declaration of
'link_policy' was here
extern struct nla_policy link_policy[];
^
Makefile:526: recipe for target 'libip6_manager_la-nm-ip6-manager.lo' failed
make[4]: *** [libip6_manager_la-nm-ip6-manager.lo] Error 1
make[4]: Leaving directory
'/var/tmp/portage/net-misc/networkmanager-0.9.8.8/work/NetworkManager-0.9.8.8/src/ip6-manager'
Makefile:1721: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
'/var/tmp/portage/net-misc/networkmanager-0.9.8.8/work/NetworkManager-0.9.8.8/src'
Makefile:813: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory
'/var/tmp/portage/net-misc/networkmanager-0.9.8.8/work/NetworkManager-0.9.8.8/src'
Makefile:650: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/var/tmp/portage/net-misc/networkmanager-0.9.8.8/work/NetworkManager-0.9.8.8'
Makefile:542: recipe for target 'all' failed
make: *** [all] Error 2

Use recvmmsg() when available

On huge netlink traffic (like ULOG or NFLOG) receiving one message per syscall affect performance. Receiving multiple mesasges at once give preformance boost.

link/api.h: error: expected ‘}’ at end of input

libnl-3.2.14 and older

There is no closing bracket at end of netlink/route/link/api.h and netlink/route/link/inet.h for the appropriate opening bracket:

#ifdef __cplusplus
extern "C" {
#endif

So, the G++ compiler reports:

error: expected ‘}’ at end of input

This code should be added to the end of that headers before the last #endif:

#ifdef __cplusplus
}
#endif

segfault in rtnl_link_sriov_parse_vflist during __rtnl_link_alloc_cache

After upgrading to libnl3 3.29-1 on Fedora 25, I get the following crash reliably when I try to run any program that calls netcf's netlink_init() (e.g. libvirtd, or "ncftool list") on a machine with an SRIOV network adapter (in my case an Intel 82576, which uses the igb driver and has 2 x 7 VFs):

Program received signal SIGBUS, Bus error.
rtnl_link_sriov_parse_vflist (link=link@entry=0x55555583ce00,
tb=tb@entry=0x7fffffffd7e0) at route/link/sriov.c:571
571 vf_vlan_info[len] = nla_data(nla_list);
Missing separate debuginfos, use: dnf debuginfo-install libselinux-2.5-13.fc25.x86_64 ncurses-libs-6.0-6.20160709.fc25.x86_64 pcre-8.40-1.fc25.x86_64 xz-libs-5.2.2-2.fc24.x86_64
(gdb) where
#0 rtnl_link_sriov_parse_vflist (link=link@entry=0x55555583ce00,
tb=tb@entry=0x7fffffffd7e0) at route/link/sriov.c:571
#1 0x00007ffff610048d in link_msg_parser (ops=,
who=, n=0x555555843900, pp=0x7fffffffdb00)
at route/link.c:631
#2 0x00007ffff5eca6e3 in nl_cache_parse (ops=0x7ffff634e920 <rtnl_link_ops>,
who=0x55555583c328, nlh=0x555555843900, params=0x7fffffffdb00)
at cache.c:994
#3 0x00007ffff5eca72b in update_msg_parser (msg=,
arg=) at cache.c:670
#4 0x00007ffff5ed0c3c in nl_cb_call (msg=,
type=, cb=)
at ../include/netlink-private/netlink.h:146
#5 recvmsgs (cb=0x55555583c230, sk=0x55555583bf70) at nl.c:1004
#6 nl_recvmsgs_report (sk=sk@entry=0x55555583bf70, cb=cb@entry=0x55555583c230)
at nl.c:1055
#7 0x00007ffff5ed1069 in nl_recvmsgs (sk=sk@entry=0x55555583bf70,
cb=cb@entry=0x55555583c230) at nl.c:1079
#8 0x00007ffff5ec9acb in __cache_pickup (sk=sk@entry=0x55555583bf70,
cache=cache@entry=0x55555583a8d0, param=param@entry=0x7fffffffdb00)
at cache.c:703
#9 0x00007ffff5eca65d in __nl_cache_pickup (checkdup=0, cache=0x55555583a8d0,
sk=0x55555583bf70) at cache.c:750
---Type to continue, or q to quit---
#10 nl_cache_pickup (sk=sk@entry=0x55555583bf70,
cache=cache@entry=0x55555583a8d0) at cache.c:783
#11 0x00007ffff5eca891 in nl_cache_refill (sk=sk@entry=0x55555583bf70,
cache=cache@entry=0x55555583a8d0) at cache.c:1063
#12 0x00007ffff60fee55 in rtnl_link_alloc_cache_flags (sk=0x55555583bf70,
family=family@entry=0, result=result@entry=0x7fffffffdbb0,
flags=flags@entry=0) at route/link.c:1230
#13 0x00007ffff60feea7 in rtnl_link_alloc_cache (sk=,
family=family@entry=0, result=result@entry=0x7fffffffdbb0)
at route/link.c:1265
#14 0x00007ffff7bcc52f in __rtnl_link_alloc_cache (sk=)
at dutil_linux.c:80
#15 netlink_init (ncf=ncf@entry=0x55555575d410) at dutil_linux.c:692
#16 0x00007ffff7bcd707 in drv_init (ncf=0x55555575d410) at drv_redhat.c:399
#17 0x00005555555560f9 in main (argc=2, argv=0x7fffffffde58) at ncftool.c:851

Memory leak in CAN link on PowerPC

Now, I'm not sure if this is related to the architecture, compiler or the kernel, but the following code leaks memory on this specific embedded system:

#include <stdio.h>
#include <assert.h>
#include <netlink/netlink.h>
#include <netlink/cache.h>
#include <netlink/route/route.h>
#include <netlink/route/rtnl.h>
#include <netlink/route/link.h>
#include <netlink/route/link/can.h>

struct nl_sock* alloc_socket()
{
    struct nl_sock* socket = nl_socket_alloc();
    assert(socket != NULL);
    return socket;
}

struct nl_cache* alloc_cache()
{
    struct nl_cache* cache = NULL;
    assert(rtnl_link_alloc_cache(NULL, 0, &cache) == 0);
    assert(cache != NULL);
    return cache;
}

void request_link(struct nl_sock* socket, const char* name)
{
    struct nl_msg* message = NULL;
    assert(rtnl_link_build_get_request(0, name, &message) == 0);
    assert(message != NULL);

    assert(nl_send_auto(socket, message) >= 0);
    nlmsg_free(message);
}

int main(int argc, char* argv[])
{
    char* iface = argc > 1 ? argv[1] : "can0";

    struct nl_sock* socket = alloc_socket();

    assert(nl_connect(socket, 0) == 0);

    struct nl_cache* cache = alloc_cache();

    request_link(socket, iface);

    assert(nl_cache_pickup(socket, cache) == 0);

    nl_cache_free(cache);
    nl_close(socket);
    nl_socket_free(socket);

    return 0;
}

This is the output from valgrind:

root@skjastod:~# valgrind --leak-check=full ./meh can0
==18015== Memcheck, a memory error detector
==18015== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==18015== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==18015== Command: ./meh can0
==18015== 
==18015== 
==18015== HEAP SUMMARY:
==18015==     in use at exit: 112 bytes in 1 blocks
==18015==   total heap usage: 40 allocs, 39 frees, 27,611 bytes allocated
==18015== 
==18015== 112 bytes in 1 blocks are definitely lost in loss record 1 of 1
==18015==    at 0xFFB495C: calloc (vg_replace_malloc.c:593)
==18015==    by 0xFF17BFB: can_alloc (in /usr/lib/libnl-route-3.so.200.20.0)
==18015==    by 0xFEF6033: rtnl_link_set_type (in /usr/lib/libnl-route-3.so.200.20.0)
==18015==    by 0xFEF1A8B: link_msg_parser (in /usr/lib/libnl-route-3.so.200.20.0)
==18015==    by 0xFF7A3E3: nl_cache_parse (in /usr/lib/libnl-3.so.200.20.0)
==18015==    by 0xFF7980F: update_msg_parser (in /usr/lib/libnl-3.so.200.20.0)
==18015==    by 0xFF816C7: nl_cb_call (in /usr/lib/libnl-3.so.200.20.0)
==18015==    by 0xFF831EF: recvmsgs (in /usr/lib/libnl-3.so.200.20.0)
==18015==    by 0xFF8339B: nl_recvmsgs_report (in /usr/lib/libnl-3.so.200.20.0)
==18015==    by 0xFF833E3: nl_recvmsgs (in /usr/lib/libnl-3.so.200.20.0)
==18015==    by 0xFF79953: __cache_pickup (in /usr/lib/libnl-3.so.200.20.0)
==18015==    by 0xFF79B3B: nl_cache_pickup (in /usr/lib/libnl-3.so.200.20.0)
==18015== 
==18015== LEAK SUMMARY:
==18015==    definitely lost: 112 bytes in 1 blocks
==18015==    indirectly lost: 0 bytes in 0 blocks
==18015==      possibly lost: 0 bytes in 0 blocks
==18015==    still reachable: 0 bytes in 0 blocks
==18015==         suppressed: 0 bytes in 0 blocks
==18015== 
==18015== For counts of detected and suppressed errors, rerun with: -v
==18015== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 3)

Version info:

  • libnl 3.2.25
  • gcc 4.5.2
  • Linux 2.6.33-rc6

Note that this only leaks for a can interface; eth0 is fine.

Here's some debug output:

DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations fib_lookup/fib_lookup
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations ip6tnl
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations vti
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations sit
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations gre
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations ipip
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations veth
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations vxlan
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations macvlan
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations can
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations bond
DBG<1>    route/link/api.c:302  rtnl_link_af_register: Registered link address family operations 2
DBG<1>    route/link/api.c:302  rtnl_link_af_register: Registered link address family operations 10
DBG<1>    route/link/api.c:302  rtnl_link_af_register: Registered link address family operations 7
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations dummy
DBG<1>    route/link/api.c:124  rtnl_link_register_info: Registered link info operations vlan
DBG<1>  route/cls/ematch.c:50   rtnl_ematch_register: ematch module "meta" registered
DBG<1>  route/cls/ematch.c:50   rtnl_ematch_register: ematch module "text" registered
DBG<1>  route/cls/ematch.c:50   rtnl_ematch_register: ematch module "nbyte" registered
DBG<1>  route/cls/ematch.c:50   rtnl_ematch_register: ematch module "cmp" registered
DBG<1>  route/cls/ematch.c:50   rtnl_ematch_register: ematch module "container" registered
DBG<1>     route/classid.c:444  classid_init: Failed to read classid file: Object not found
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/rule
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/route
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/qdisc
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/neightbl
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/neigh
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/link
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/act
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/cls
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/class
DBG<1>        cache_mngt.c:268  nl_cache_mngt_register: Registered cache operations route/addr
DBG<2>             cache.c:212  nl_cache_alloc: Allocated cache 0x10011250 <route/link>.
DBG<2>               msg.c:282  __nlmsg_alloc: msg 0x10012290: Allocated new message, maxlen=4096
DBG<2>               msg.c:356  nlmsg_alloc_simple: msg 0x10012290: Allocated new simple message
DBG<2>               msg.c:425  nlmsg_reserve: msg 0x10012290: Reserved 16 (16) bytes, pad=4, nlmsg_len=32
DBG<2>               msg.c:451  nlmsg_append: msg 0x10012290: Appended 16 bytes with padding 4
DBG<2>              attr.c:478  nla_reserve: msg 0x10012290: attr <0x100122f0> 3: Reserved 12 (5) bytes at offset +16 nlmsg_len=44
DBG<2>              attr.c:509  nla_put: msg 0x10012290: attr <0x100122f0> 3: Wrote 5 bytes at offset +16
DBG<4>                nl.c:318  nl_sendmsg: sent 44 bytes
DBG<4>               msg.c:565  nlmsg_free: Returned message reference 0x10012290, 0 remaining
DBG<2>               msg.c:572  nlmsg_free: msg 0x10012290: Freed
DBG<2>             cache.c:693  __cache_pickup: Picking up answer for cache 0x10011250 <route/link>
DBG<3>                nl.c:791  recvmsgs: Attempting to read from 0x10011218
DBG<3>                nl.c:800  recvmsgs: recvmsgs(0x10011218): Read 396 bytes
DBG<3>                nl.c:804  recvmsgs: recvmsgs(0x10011218): Processing valid message...
DBG<2>               msg.c:282  __nlmsg_alloc: msg 0x10012290: Allocated new message, maxlen=396
DBG<4>            object.c:72   nl_object_alloc: Allocated new object 0x100164e0
DBG<3>    route/link/can.c:92   can_parse: Parsing CAN link infoDBG<5>        route/link.c:895  link_keygen: link 0x100164e0 key (dev 2 fam 0) keysz 8, hash 0x3b9
DBG<4>            object.c:208  nl_object_get: New reference to object 0x100164e0, total 2
DBG<5>        route/link.c:895  link_keygen: link 0x100164e0 key (dev 2 fam 0) keysz 8, hash 0x3b9
DBG<5>         hashtable.c:134  nl_hash_table_add: adding cache entry of obj 0x100164e0 in table 0x10011278, with hash 0x3b9
DBG<4>            object.c:208  nl_object_get: New reference to object 0x100164e0, total 3
DBG<3>             cache.c:452  __cache_add: Added object 0x100164e0 to cache 0x10011250 <route/link>, nitems 1
DBG<4>            object.c:222  nl_object_put: Returned object reference 0x100164e0, 2 remaining
DBG<4>               msg.c:565  nlmsg_free: Returned message reference 0x10012290, 0 remaining
DBG<2>               msg.c:572  nlmsg_free: msg 0x10012290: Freed
DBG<3>             cache.c:416  nl_cache_free: Decremented cache 0x10011250 <route/link> reference count, 0 remaining
DBG<2>             cache.c:370  nl_cache_clear: Clearing cache 0x10011250 <route/link>...
DBG<5>        route/link.c:895  link_keygen: link 0x100164e0 key (dev 2 fam 0) keysz 8, hash 0x3b9
DBG<4>            object.c:222  nl_object_put: Returned object reference 0x100164e0, 1 remaining
DBG<5>         hashtable.c:174  nl_hash_table_del: deleting cache entry of obj 0x100164e0 in table 0x10011278, with hash 0x3b9
DBG<4>            object.c:222  nl_object_put: Returned object reference 0x100164e0, 0 remaining
DBG<4>            object.c:188  nl_object_free: Freed object 0x100164e0
DBG<2>             cache.c:572  nl_cache_remove: Deleted object 0x100164e0 from cache 0x10011250 <route/link>.
DBG<2>             cache.c:383  __nl_cache_free: Freeing cache 0x10011250 <route/link>...
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/addr
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/class
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/cls
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/act
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/link
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/neigh
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/neightbl
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/qdisc
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/route
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations route/rule
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations vlan
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations dummy
DBG<1>    route/link/api.c:345  rtnl_link_af_unregister: Unregistered link address family operations 7
DBG<1>    route/link/api.c:345  rtnl_link_af_unregister: Unregistered link address family operations 10
DBG<1>    route/link/api.c:345  rtnl_link_af_unregister: Unregistered link address family operations 2
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations bond
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations macvlan
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations vxlan
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations veth
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations ipip
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations gre
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations sit
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations vti
DBG<1>    route/link/api.c:163  rtnl_link_unregister_info: Unregistered link info operations ip6tnl
DBG<1>        cache_mngt.c:305  nl_cache_mngt_unregister: Unregistered cache operations fib_lookup/fib_lookup

Correct usage of nl_cache_mngr

I am trying to utilize the cache manager to track changes to the network interfaces and their corresponding ip addresses. However, I am running into some misunderstandings in terms of how the cache manager is supposed to work. Most importantly, the change callback is only called with the newly modified nl_link object. The problem is that there are a large number of attributes that can change on an interface and the old nl_link object is not provided. So there is no way to actually know what has changed without performing another layer of caching. Is this how it is intended to work? I am supposed to build a thin caching layer on top of the cache manager? How else would someone be able to generate events to an application based on the cache manager?

Conflicts between linux/if.h and net/if.h

My project is based in c++ and uses boost and a number of other third party libraries. It appears that all of these libraries prefer net/if.h over linux/if.h. As it turns out, there is a conflict between the two. So what I have now that I have integrated libnl with the rest of my project is a bunch of multiple definition errors as follows:

/usr/include/linux/if.h:143:8: error: redefinition of 'ifmap'
struct ifmap {
       ^
/usr/include/net/if.h:111:8: note: previous definition is here
struct ifmap

Doing a quick grep through the source code of all of my third party libs shows that they all use net/if.h rather than linux/if.h. There are about 8 or 9 libs that include net/if.h. Not a single library out of the dozen or so include linux/if.h.

$ grep -r "net/if.h" *
third-party/boost/libs/asio/include/boost/asio/detail/socket_types.hpp:# include <net/if.h>
third-party/libtorrent-rasterbar/src/enum_net.cpp:#include <net/if.h>
.
.
.

I don't see any way to currently resolve this issue. Is this something that has come up before? There seems to be a long checkered history of conflicts between these two headers.

Make default iov buffer size configurable

Suppose netlink protocol that pass big messages (larger than PAGE_SIZE) i.e. ULOG/NFLOG. Performance of curent implementation will not be good (require two syscalls per message). Another case is performance on large number of small messages. Increasing default buffer will allow to receive much more messages per syscall (again, ULOG, but in real life).

Why not to make default buffer size configurable ? I mean API like this:

int nl_socket_set_initial_recv_bufsize(struct nl_sock *sk, size_t size);

nl_socket_set_buffer_size should be synchronized as appropriate, i.e. if user expect large messages, why not to enlarge SO_RCVBUF to at least the same value?

NLE_OBJ_NOTFOUND

Hi
I am getting NLE_OBJ_NOTFOUND (-12) on nl_recvmsgs_default ()
This does not happen always.
how to debug to find root cause for this ?
Thanks

Change callbacks for wireless interfaces are wrong

I have been running through most of my testing with wired ethernet interfaces. Today I started testing with wireless interfaces. I am seeing some strange behavior that looks like a bug. I am using network manager on Linux Mint 17.1 to toggle the wireless interface on and off. Here is what I see from the object dumps in the change callbacks. It is starting from a state where wlan0 is initially disabled:

wlan0 ether f8:16:54:2c:f3:6c <broadcast,multicast,up> group 0 
    mtu 1500 txqlen 1000 weight 0 qdisc mq index 3 
    txq 4 rxq 1 brd ff:ff:ff:ff:ff:ff state down mode default carrier down
wlan0 ether <broadcast,multicast,up> 
    mtu 0 txqlen 0 weight 0 index 3 
    mode default carrier down
wlan0 ether f8:16:54:2c:f3:6c <broadcast,multicast,up,lowerup> group 0 
    mtu 1500 txqlen 1000 weight 0 qdisc mq index 3 
    txq 4 rxq 1 brd ff:ff:ff:ff:ff:ff state dormant mode dormant carrier up
wlan0 ether <broadcast,multicast,up,lowerup> 
    mtu 0 txqlen 0 weight 0 index 3 
    mode default carrier down
wlan0 ether f8:16:54:2c:f3:6c <broadcast,multicast,up,running,lowerup> group 0 
    mtu 1500 txqlen 1000 weight 0 qdisc mq index 3 
    txq 4 rxq 1 brd ff:ff:ff:ff:ff:ff state up mode dormant carrier up

Then after about 3-4 seconds I end up with this:

wlan0 ether <broadcast,multicast,up,running,lowerup> 
    mtu 0 txqlen 0 weight 0 index 3 
    mode default carrier down

When I investigate the state of the interface using the 'ip' command I get this:

$ ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 80:fa:5b:06:25:50 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether f8:16:54:2c:f3:6c brd ff:ff:ff:ff:ff:ff

So clearly something in linbl is not working correctly. Not sure what at this point but the cache is very suspect. I have a version I wrote using libnl sockets without the cache manager. I'll resurrect it and see if it is reproducible there as well but I am willing to bet that it is not. I tried running under valgrind to see if it could catch anything but the run produced the same result and no memory errors were reported. For what it is worth, this is 100% reproducible for me.

What is epollerr means for netlink sockets

Hi
Why am i getting EPOLLERR in epoll_wait() on netlink socket ? is this because other side of netlink ie kernel side closed connection ?
even if kernel side closed connection why non-stop repeated EPOLLERR s on netlink sockets ?

I can't run 'make install' successfully:cannot stat '.libs/libnl-3.so.200.23.0': No such file or directory

Hello:

I need to cross compile hostapd for my project from my work. And That depend libnl-3.2.

I Download the code from release: https://github.com/thom311/libnl/releases/tag/libnl3_2_28. and apply patch from: 16a9fad.

And I need to cross-compile it:

./configure --host=arm-hisiv300-linux --prefix=$SOME_DIR/libnl-3.2.28-build

and then

${MAKE} install -C $(LIBNL_DIR)

then I get error message:

 /usr/bin/mkdir -p '/home/chen.wq3/camerasystem/branches/chen.wq3/hotspot/app/hotspot/build/libnl-3.2.28-build/lib'
 /bin/sh ../libtool   --mode=install /usr/bin/install -c   libnl-3.la libnl-genl-3.la libnl-route-3.la libnl-nf-3.la libnl-idiag-3.la libnl-xfrm-3.la '/home/chen.wq3/camerasystem/branches/chen.wq3/hotspot/app/hotspot/build/libnl-3.2.28-build/lib'
libtool: install: /usr/bin/install -c .libs/libnl-3.so.200.23.0 /home/chen.wq3/camerasystem/branches/chen.wq3/hotspot/app/hotspot/build/libnl-3.2.28-build/lib/libnl-3.so.200.23.0
/usr/bin/install: cannot stat '.libs/libnl-3.so.200.23.0': No such file or directory
make[5]: *** [install-libLTLIBRARIES] Error 1
make[4]: *** [install-am] Error 2
make[3]: *** [install] Error 2
make[2]: *** [install-recursive] Error 1
make[1]: *** [libnl32] Error 2
/home/chen.wq3/camerasystem/branches/chen.wq3/hotspot/app/hotspot/build/module_lib_a_nl.mk: error occured

I search libnl-3, and .libs does not have libnl-3.so.200.23.0.

[chen.wq3@video-test libnl-3.2.28]$ find | grep libnl-3
./libnl-3.sym
./libnl-3.0.pc.in
./lib/.libs/libnl-3.so.200
./lib/.libs/libnl-3.so
./lib/.libs/libnl-3.a
./lib/.libs/libnl-3.lai
./lib/.libs/libnl-3.la
./lib/libnl-3.la
./libnl-3.0.pc

How to set priority in a bridge...kernel version 3.5.0

Hello,

I have tried to create bridge using
sk = nl_socket_alloc();
if ((err = nl_connect(sk, NETLINK_ROUTE)) < 0) {
nl_perror(err, "Unable to connect socket");
return err;
}

 link1 = rtnl_link_alloc();

if ((err = rtnl_link_set_type(link1, "bridge")) < 0) {
nl_perror(err, "Unable to set link info type");
return err;
}
rtnl_link_set_name(link1, "br0");
//rtnl_link_set_link(link, master_index);

if ((err = rtnl_link_add(sk, link1, NLM_F_CREATE)) < 0) {
nl_perror(err, "Unable to add link");
return err;
}
rtnl_link_put(link1);

nl_close(sk);

It works fine but when I access the link from link_cache and trying to set BRIDGE PRIORITY or check rtnl_link_is_bridge(link)...It does not work.

if ((err = rtnl_link_alloc_cache(sk, AF_UNSPEC, &link_cache)) < 0) {
nl_perror(err, "Unable to allocate cache");
return err;
}

link1=rtnl_link_get_by_name(link_cache, "br0");

int k = rtnl_link_is_bridge(link1);
printf("\nsuccess %d\n",k );
k = rtnl_link_bridge_set_priority(link1,300);
printf("\nsuccess %d\n",k );

It shows Assertion '0' failed and no changes in bridge configuration...it could not able to detect AF_BRIDGE...

my kernel version is 3.5.0-23-generic ....

please help me out..

Thanks

rtnl_link_get returns NULL for USB wireless indexes if it has ever been unplugged

I have a small application where I iterate through the interfaces of my system like so:

485 int index = 1;
486
487 forever {
488 struct rtnl_link *link = rtnl_link_get(link_cache, index);
489
490 if(link != NULL) {
491 char *name = rtnl_link_get_name(link);
492
493 qDebug() << "found interface: " << name;
494
495 linkList << name;
496
497 rtnl_link_put(link);
498 }else{
499 break;
500 }
501
502 ++index;
503 }

This works fine to detect all my ethernet interfaces as well as USB wireless, until the wireless adapter is unplugged. Once it is re-plugged, rtnl_link_get returns NULL for the index associated with the wireless adapter. All other system utilities such as ip, iw etc. continue to work fine after the adapter is re-plugged, just not libnl. As a workaround I instead read from /sys/class/net to find the system's interfaces until this issue is resolved. Any idea what could be wrong?

Valgrind - Invalid read of size 4

Hi,

I have code that uses libnl, when testing with valgrind I get an error that appears to be due to libnl memory allocation.

My code calls rtnl_route_alloc_cache(), which internally allocates space for a struct nl_addr. Later this struct is fetched from the cache using rtnl_route_get_dst(). My code then tries to copy the IPv4 address using nl_addr_fill_sockaddr() and that's when valgrind detects the invalid read.

The valgrind output (trimmed to hide my code) is:

==15124== Invalid read of size 4
==15124== at 0x5782952: memcpy (string3.h:51)
==15124== by 0x5782952: nl_addr_fill_sockaddr (addr.c:711)
==15124== by 0x41FF33:
==15124== by 0x42027B:
==15124== by 0x4195C7: main
==15124== Address 0xc4d77f4 is 0 bytes after a block of size 20 alloc'd
==15124== at 0x4C2B200: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==15124== by 0x5782531: nl_addr_alloc (addr.c:189)
==15124== by 0x59B8626: rtnl_route_parse (route_obj.c:1047)
==15124== by 0x59B6584: route_msg_parser (route.c:36)
==15124== by 0x5784E78: nl_cache_parse (cache.c:914)
==15124== by 0x5784ECA: update_msg_parser (cache.c:668)
==15124== by 0x578A67E: nl_cb_call (netlink.h:134)
==15124== by 0x578A67E: recvmsgs (nl.c:904)
==15124== by 0x578A67E: nl_recvmsgs_report (nl.c:955)
==15124== by 0x578AA48: nl_recvmsgs (nl.c:979)
==15124== by 0x578435F: __cache_pickup (cache.c:701)
==15124== by 0x5784DFC: nl_cache_pickup (cache.c:753)
==15124== by 0x5784FFF: nl_cache_refill (cache.c:983)
==15124== by 0x59B6643: rtnl_route_alloc_cache (route.c:92)
==15124== by 0x41FE02:
==15124== by 0x42027B:
==15124== by 0x4195C7: main

Looking at the allocation and the subsequent use of struct nl_addr, I think the problem is in route/route_obj.c:

1047├> if (!(dst = nl_addr_alloc(0)))
1048│ goto errout_nomem;
1049│ nl_addr_set_family(dst, rtm->rtm_family);

By calling nl_addr_alloc() with a parameter of zero, calloc() is used to allocate 20 bytes.

(gdb) p *dst
$7 = {
a_family = 0,
a_maxsize = 0,
a_len = 0,
a_prefixlen = 0,
a_refcnt = 1,
a_addr = 0x64b824 ""
}

No space is allocated for a_addr, it's an array of zero bytes.

(gdb) p sizeof dst->a_addr
$8 = 0
(gdb) ptype *dst
type = struct nl_addr {
int a_family;
unsigned int a_maxsize;
unsigned int a_len;
int a_prefixlen;
int a_refcnt;
char a_addr[];
}

The address family is then set to that of rtm->rtm_family. Which in my case happens to be AF_INET. In this case a_addr needs space to hold 4 bytes. However other address families could require more space (e.g. AF_INET6).

1049│ nl_addr_set_family(dst, rtm->rtm_family);

Therefore I think the zero parameter passed to nl_addr_alloc() is the cause of this issue. It should be set to a value that accommodates all address families or the value of rtm->rtm_family should be used to calculate the value passed into nl_addr_alloc().

Within nl_addr_fill_sockaddr(), this line triggers the valgrind error:

711├> memcpy(&sai->sin_addr, addr->a_addr, 4);

Since no space has been allocated for addr->a_addr, this is indeed a read of 4 bytes starting 0 bytes after the block of 20 allocated bytes.

Please let me know if the above analysis is reasonable and if the issue can be fixed. Also, let me know if you need more information.

Thanks,
Paul

rtnl_addr_delete 3.2.24 doesn't work

Hi,

i am working on the 3.2.24 version of libnl, and i think there are a bug on the rtnl_addr_add and rtnl_addr_delete.

Even the test library in src fail to remove a route with interactive command :
swissdotnet@ubuntu:~/networkManager/workspace/libnl/libnl-3.2.24/src$ sudo ./nl-addr-delete -i
127.0.0.1/8 inet dev lo scope host
Delete? (y/N) n
10.110.0.247/24 inet dev eth3 scope global
Delete? (y/N) y
Error: Unable to delete address: Invalid input data or parameter

With debug informations :

----------------------- BEGIN NETLINK MESSAGE ---------------------------
[NETLINK HEADER] 16 octets
.nlmsg_len = 88
.type = 2
.flags = 0 <>
.seq = 1394642172
.port = 10735
[ERRORMSG] 20 octets
.error = -22 "Invalid argument"
[ORIGINAL MESSAGE] 16 octets
.nlmsg_len = 16
.type = 21 <0x15>
.flags = 5 <REQUEST,ACK>
.seq = 1394642172
.port = 10735
--------------------------- END NETLINK MESSAGE ---------------------------
-- Error received: Invalid argument
-- Original message: type=0x15 length=68 flags=<REQUEST,ACK> sequence-nr=1394642172 pid=10735
Error: Unable to delete address: Invalid input data or parameter

I have check with version 3.2.7 and i have no problem with this version.

Thanks

The cache manager test is not working (test-cache-mngr.c)

I am running Linux Mint 17 and have a freshly built libnl pulled here from github. When I run the test I get the following error:

$ test-cache-manager "route/addr"
Unable to add cache route/addr: Unknown or invalid cache type

In tracing through the code I came accross:

 lib/cache_mngt.c
 33 static struct nl_cache_ops *cache_ops;
 34 static NL_RW_LOCK(cache_ops_lock);

So when running the test I end up here:

lib/cache_mngr.c
321 int nl_cache_mngr_add(struct nl_cache_mngr *mngr, const char *name,
322               change_func_t cb, void *data, struct nl_cache **result)
323 {
324     struct nl_cache_ops *ops;
325     struct nl_cache *cache;
326     int err;
327 
328     ops = nl_cache_ops_lookup_safe(name);
329     if (!ops)
330         return -NLE_NOCACHE;

So it seems that there is something missing from the test because it is behaving like I am supposed to somehow populate cache ops? Any insights?

--as-needed, __init and libnl3

gcc -I/usr/include/libnl3 minimal.c -lnl-3 -lnl-nf-3

in Ubuntu 15 this program will compile, but will not work with message

nl_cache_mngr_add: Unknown or invalid cache type

But, it works when using clang !! what the hell ?! the evil in --as-needed used in Ubuntu's gcc by default. Since gcc do not knows that libnl-nf-3 uses __init function, it is eliminated from list of libraries to link.

So, if I add -Wl,--no-as-needed, everything works as expected.

So will you add some fix against that? maybe make this flag to appear in $(shell pkg-config --libs libnl-xxxx ) ?

Here is a minimal program:

#include <netlink/netfilter/nfnl.h>
#include <netlink/netfilter/ct.h>

static void change_cb (struct nl_cache *cache, struct nl_object *obj, int action, void *data) {}

int main (void)
{
  struct nl_sock *sock;
  struct nl_cache_mngr *mngr;
  struct nl_cache *ct_cache;
  int err;
  if ((sock = nl_socket_alloc ()) == NULL)
    return 1;
  if ((err = nl_cache_mngr_alloc (sock, NETLINK_NETFILTER, NL_AUTO_PROVIDE, &mngr)) < 0)
  {
    nl_perror (err, "err=nl_cache_mngr_alloc");
    return 2;
  }
  if ((err = nl_cache_mngr_add (mngr, "netfilter/ct", &change_cb, NULL, &ct_cache)) < 0)
  {
    nl_perror (err, "nl_cache_mngr_add");
    return 3;
  }
  return 0;
}

What license is LibNL distributed in?

I'm looking at the following files:
external/libnl/include/linux/if_arp.h:
external/libnl/include/linux/if_bad.h
external/libnl/include/linux/if_ether.h
external/libnl/lib/route/pktloc.c
external/libnl/src/cls/basic.c
external/libnl/src/cls/cgroup.c
external/libnl/src/cls/utils.c
external/libnl/src/cls/utils.h
external/libnl/src/nl-addr-add.c
external/libnl/src/nl-addr-delete.c
external/libnl/src/nl-addr-list.c
external/libnl/src/nl-cls-add.c

And they're all distributed with GPLv2. Looking at the COPYING file, it says that LibNL is distributed as LGPL.

If someone familiar with licensing can explain the licensing for this project, that would be immensely helpful 😃

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.