thom311 / libnl Goto Github PK
View Code? Open in Web Editor NEWNetlink Library Suite
License: GNU Lesser General Public License v2.1
Netlink Library Suite
License: GNU Lesser General Public License v2.1
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.
Google made themselves a patch to nla_reserve to check for negative attrlen
values in nla_reserve
, but to me that points to a deeper issue that attrlen should have been unsigned to begin with.
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
Also, yacc does not work. bison is needed. That should be checked, or sources fixed
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.
It needed, for example, for implementing ULOG. It sends broadcast message with type ULOG_NL_EVENT = 111
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.
This is a mode of queue that direct kernel ACCEPT packet that exceed queue length instead of DROP.
I mean flag in the kernel:
NFQA_CFG_F_FAIL_OPEN
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.
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;
}
(The same as NETLINK_INET_DIAG)
I don't really understand this stuff very well but:
When kismet links to libnl-3 and libpcap, but libpcap is linked to libnl-1, this causes segfaults.
Downstream gentoo bug offers some patches to help correct these kinds of issues which are prevalent across distributions.
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
Hello,
The new package http://www.infradead.org/~tgr/libnl/files/libnl-3.2.14.tar.gz seems to be broken because it has no lib/ directory and configure script says:
config.status: error: cannot find input file: `lib/Makefile.in'
Also the size of the package became 310Kb instead of 1.1Mb for libnl-3.2.13.tar.gz
Thanks.
On huge netlink traffic (like ULOG or NFLOG) receiving one message per syscall affect performance. Receiving multiple mesasges at once give preformance boost.
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?
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:
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
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
++
nl_recv()
..
++
but this comment seems not true when i see code.
Is this old comment and needs to be updated ?
Due to this my app does not know about connection closure
Appreciate your comments on this
Thanks
Prashant
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
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?
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 ๐
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
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
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
i.e. some function that returns libnl version. Unfortunatelly, this is required for things like pytyon's ctypes, that should make decision based on version of library.
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.
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
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
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
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
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
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
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)
I mean
setsockopt(fd, SOL_SOCKET, SO_DETACH_FILTER, &val, sizeof(val));
setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, &val, sizeof(val));
This make sense for large amount of data sent over socket. For example, one may filter only interesting messages during listing of conntrack items. This is implemented in
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=libnetfilter_conntrack.git
Line 102 in 4818248
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 ?
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?
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.
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 ?
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.
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
Used in ULOG iptables taget. vanilla usage shown in libipulog
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.
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
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?
Description: Ubuntu 12.04.5 LTS
https://s3.amazonaws.com/archive.travis-ci.org/jobs/222234411/log.txt
This is a default travis build machine. Version 3.2.25 was building fine.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.