From mail at usportmailer.info  Sun Apr  1 21:42:58 2012
From: mail at usportmailer.info (AMP)
Date: Sun, 1 Apr 2012 18:42:58 -0700
Subject: Community & educational development
Message-ID: <133328500399f194b31fa22478f193a830f906fea1_@usportmailer.info>


Press Release 


 The American Grants and Loans Catalog is now available. Our new and revised
2012 edition contains more than 2800 financial programs, subsidies, scholarships, 
grants and loans offered by the US federal government. 
 
In addition you will also have access to over 2400 programs funded by private 
corporations and foundations. That is over 5200 programs available through 
various sources of financial providing organizations.

NEW: You will also have access to our live Database that is updated on a daily 
basis. This product also provides daily email alerts as programs are announced.

The Database is also available with IP recognition. This allows you to login
 without a username or password (Great for libraries or educational institutions
 who want their users to access the database).
 
Businesses, students, researchers, scientists, teachers, doctors, private individuals, 
municipalities, government departments, educational institutions, law enforcement 
agencies, nonprofits, foundations and associations will find a wealth of information 
that will help them with their new ventures or existing projects.
 
The document is a fully searchable PDF file for easy access to your particular 
needs and interests. Simply enter your keywords to search through the publication.
 
It is the perfect tool for libraries and educational institutions to use as a 
reference guide for students who require funds to pursue their education.
 

 Contents of the Directory:
 
* Web link to program announcement page
* Web link to Federal agency or foundation administering the program
* Authorization upon which a program is based
* Objectives and goals of the program
* Types of financial assistance offered under a program
* Uses and restrictions placed upon a program
* Eligibility requirements
* Application and award process
* Regulations, guidelines and literature relevant to a program
* Information contacts at the headquarters, regional, and local offices
* Programs that are related based upon program objectives and uses
 
            
Programs in the Catalog provide a wide range of benefits and services
for categories such as:
            
* Agriculture
* Arts
* Business and Commerce
* Community Development
* Consumer Protection
* Cultural Affairs
* Disaster Prevention and Relief
* Education
* Employment, Labor and Training
* Energy
* Engineering
* Environmental Quality
* Food and Nutrition
* Health
* Housing
* Income Security and Social Services
* Information and Statistics
* Law, Justice, and Legal Services
* Natural Resources
* Regional Development
* Science and Technology
* Transportation
            
 
CD version: $69.95
Printed version: $149.95
 
To order please call: 1 (800) 610-4543


Please do not respond to this message. This is a post-only mailing.

This is a CANSPAM ACT compliant advertising broadcast sent by:
American Publishing Inc., 7025 County Road 46A, Suite 1071,
Lake Mary, FL, 32746-4753 
Please do not respond to this message. This is a post-only mailing.
If you do not wish to receive information from us in the future please 
reply here: abort103 at email.com
Copyright ? 2012 American Publishing Inc.. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120401/4d126152/attachment.html>

From bonbons at linux-vserver.org  Tue Apr  3 06:17:54 2012
From: bonbons at linux-vserver.org (Bruno =?UTF-8?B?UHLDqW1vbnQ=?=)
Date: Tue, 3 Apr 2012 12:17:54 +0200
Subject: netlink: 12 bytes leftover after parsing attributes - triggered
 by iproute2 libnetlink's rtnl_dump_request()
In-Reply-To: <20120403100157.GA8611@canuck.infradead.org>
References: <20120320134107.6acea83c@pluto.restena.lu>
 <20120320074140.39a1b3f0@nehalam.linuxnetplumber.net>
 <1332255630.8043.11.camel@deadeye>
 <20120320170229.49de95f5@nehalam.linuxnetplumber.net>
 <20120403100157.GA8611@canuck.infradead.org>
Message-ID: <20120403121754.56e7727b@pluto.restena.lu>

Thomas,

On Tue, 3 Apr 2012 06:01:57 Thomas Graf <tgraf at infradead.org> wrote:
> Can you send a full bug report to libnl at lists.infradead.org and I'll make sure
> this gets addressed in libnl.

Here it comes (mostly initial mail with some adjustments):


Starting with linux-3.3 when using collectd's netlink plugin to monitor
interface statistics I'm seeing 3 lines of complaint in kernel log per
monitoring loop (10s interval)

  [64951.027953] netlink: 12 bytes leftover after parsing attributes.

The same userspace code running on 3.2 does not produce the lines in
kernel log.



Basic source code to reproduce (netlink subset of collectd's netlink plugin):
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
#include <libnetlink.h>

int link_filter (const struct sockaddr_nl *sa, struct nlmsghdr *nmh, void *args) {
	return 0; /* would present the data */
}

int main(int argc, char **argv) {
	struct rtnl_handle rth;
	struct ifinfomsg im;
	struct tcmsg tm;

	memset(&rth, 0, sizeof(rth));
	rtnl_open(&rth, 0);
	memset(&im, 0, sizeof(im));
	im.ifi_type = AF_UNSPEC;

	rtnl_dump_request(&rth, RTM_GETLINK, &im, sizeof(im));
	rtnl_dump_filter(&rth, link_filter, NULL, NULL, NULL);
	rtnl_close(&rth);
	return 0;
}



Compile with
  $CC -o test test.c -lnetlink
  (here using libnetlink.a from iproute2-2.6.38)



Strace of test code shows the following:
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(2)=[{" \0\0\0\22\0\1\3\272[hO\0\0\0\0", 16}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 2980
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 20

Note: when omitting the rtnl_dump_filter() call only two lines appear
in kernel log.

Comparing to iproute2 call (ip -s link list) which does not trigger the same
message in kernel log I have:
send(3, "\24\0\0\0\22\0\1\3\225]hO\0\0\0\0\21\0\0\0", 20, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 2980
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 20





Looking at kernel history related to net/netlink I've seen the following
commit which introduced the warning (or rather started using kernel's
nla_parse() function in this path - and that function complains):


commit 115c9b81928360d769a76c632bae62d15206a94a
Author: Greg Rose <gregory.v.rose at intel.com>
Date:   Tue Feb 21 16:54:48 2012 -0500

    rtnetlink: Fix problem with buffer allocation
    
    Implement a new netlink attribute type IFLA_EXT_MASK.  The mask
    is a 32 bit value that can be used to indicate to the kernel that
    certain extended ifinfo values are requested by the user application.
    At this time the only mask value defined is RTEXT_FILTER_VF to
    indicate that the user wants the ifinfo dump to send information
    about the VFs belonging to the interface.
    
    This patch fixes a bug in which certain applications do not have
    large enough buffers to accommodate the extra information returned
    by the kernel with large numbers of SR-IOV virtual functions.
    Those applications will not send the new netlink attribute with
    the interface info dump request netlink messages so they will
    not get unexpectedly large request buffers returned by the kernel.
    
    Modifies the rtnl_calcit function to traverse the list of net
    devices and compute the minimum buffer size that can hold the
    info dumps of all matching devices based upon the filter passed
    in via the new netlink attribute filter mask.  If no filter
    mask is sent then the buffer allocation defaults to NLMSG_GOODSIZE.
    
    With this change it is possible to add yet to be defined netlink
    attributes to the dump request which should make it fairly extensible
    in the future.


A kernel at preceding commit 84338a6c9dbb6ff3de4749864020f8f25d86fc81 (neighbour:
Fixed race condition at tbl->nht) does not show the log message,
starting with that commit the message appears.


A working adjustment to collectd (or above test code) is to call
rtnl_wilddump_request() instead of rtnl_dump_request() in order to
get the information.
rtnl_wilddump_request() is also the function used internally by iproute2's
ip command to fetch the data.



Bruno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collectd-netlink-kernwarn-fix.patch
Type: text/x-patch
Size: 1650 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120403/456c7850/attachment.bin>

From veytser at ll.mit.edu  Tue Apr  3 15:38:06 2012
From: veytser at ll.mit.edu (Veytser, Leonid - 0665 - MITLL)
Date: Tue, 3 Apr 2012 15:38:06 -0400
Subject: libnl userspace to userspace
Message-ID: <CBA0C9DD.7FDA%veytser@ll.mit.edu>

I am trying to do the same thing actually. I am able to send and receive netlink messages between userspace processes as long as the genl family is registered by a kernel module. I am trying to remove the requirement of needing this module and register the family from userspace. However, judging by your last message that is not currently possible? Is that correct?

Thanks,

Lenny

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120403/b2e0222c/attachment.html>

From zhenya48.80 at mail.ru  Wed Apr  4 09:12:33 2012
From: zhenya48.80 at mail.ru (=?UTF-8?B?R2F2cmlsZW5rbyBFdWdlbmU=?=)
Date: Wed, 04 Apr 2012 17:12:33 +0400
Subject: =?UTF-8?B?Q3JlYXRpbmcgVkxBTiBsaW5rcyB3aXRoIGxpYm5sLXJvdXRl?=
Message-ID: <E1SFQ0n-0005yG-3n.zhenya48-80-mail-ru@f161.mail.ru>

Hello!
I'm novice in using libnl and libnl-route and have some questions,
but I can't find any tutorials or articles on it.

I need to perform some operations with VLAN interfaces: create, delete etc.
I created VLAN link as described in 'User's Guide' of libnl-route.?
Created link is OK, but it's always has name 
such as "vlanxxx". 
I run "sudo vconfig set_name_type DEV_PLUS_VID_NO_PAD" but rtnl_link_add(...) still
creates "vlanxxx"es. 
Is it possible to create VLAN link with name such as "eth1.xxx",
like command "vconfig" does, with function rtnl_link_add(...)?

After creating VLAN link I need it's interface index and name for future operations.
But it seems like the "xxx" part of created name is not the vlan_id.
How can I get the created "vlanxxx" name and interface index after link's creation??

Thanx!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120404/8dad64f8/attachment.html>

From veytser at ll.mit.edu  Wed Apr  4 14:40:20 2012
From: veytser at ll.mit.edu (Veytser, Leonid - 0665 - MITLL)
Date: Wed, 4 Apr 2012 14:40:20 -0400
Subject: libnl userspace to userspace
In-Reply-To: <CBA0C9DD.7FDA%veytser@ll.mit.edu>
Message-ID: <CBA20D1E.800B%veytser@ll.mit.edu>

Looking through genetlink.h file I notice that among the control commands
there are CTRL_CMD_NEWFAMILY and CTRL_CMD_NEWMCAST_GRP commands defined.
Does this mean that in theory there is a facility to create new generic
netlink families and new multicast groups from userspace?

Thanks,

Lenny

From:  Leonid Veytser <veytser at ll.mit.edu>
Date:  Tue, 3 Apr 2012 15:38:06 -0400
To:  "libnl at lists.infradead.org" <libnl at lists.infradead.org>
Cc:  "sbonar at cradlepoint.com" <sbonar at cradlepoint.com>,
"tgraf at infradead.org" <tgraf at infradead.org>
Subject:  Re: libnl userspace to userspace

I am trying to do the same thing actually. I am able to send and receive
netlink messages between userspace processes as long as the genl family is
registered by a kernel module. I am trying to remove the requirement of
needing this module and register the family from userspace. However, judging
by your last message that is not currently possible? Is that correct?

Thanks,

Lenny



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120404/83dc0d3e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5132 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120404/83dc0d3e/attachment.p7s>

From tgraf at infradead.org  Thu Apr  5 04:09:01 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 5 Apr 2012 04:09:01 -0400
Subject: libnl userspace to userspace
In-Reply-To: <CBA20D1E.800B%veytser@ll.mit.edu>
References: <CBA0C9DD.7FDA%veytser@ll.mit.edu>
 <CBA20D1E.800B%veytser@ll.mit.edu>
Message-ID: <20120405080901.GC5124@canuck.infradead.org>

On Wed, Apr 04, 2012 at 02:40:20PM -0400, Veytser, Leonid - 0665 - MITLL wrote:
> Looking through genetlink.h file I notice that among the control commands
> there are CTRL_CMD_NEWFAMILY and CTRL_CMD_NEWMCAST_GRP commands defined.
> Does this mean that in theory there is a facility to create new generic
> netlink families and new multicast groups from userspace?

Nope, these message types are used exclusively for notifications and to
reply to GET requests.

If we ever implement this facitliy we would  certain reuse those commands.

Maybe it's time to think about this and allow for a controller in userspace
to manage a list of userspace-userpace generic netlink families. I think
it does not make sense to bother the kernel with this if we can avoid it.


From zhenya48.80 at mail.ru  Thu Apr  5 03:41:19 2012
From: zhenya48.80 at mail.ru (=?UTF-8?B?R2F2cmlsZW5rbyBFdWdlbmU=?=)
Date: Thu, 05 Apr 2012 11:41:19 +0400
Subject: =?UTF-8?B?UmU6IENyZWF0aW5nIFZMQU4gbGlua3Mgd2l0aCBsaWJubC1yb3V0ZQ==?=
Message-ID: <E1SFhJn-0001tL-O1.zhenya48-80-mail-ru@f160.mail.ru>

Hello!
As I realized 'vconfig' utitlity uses ioctl(...) interface rather than Netlink messages.
To create? VLAN link with name "eth1.xxx" we just need to call function rtnl_link_set_name() before calling rtnl_link_add().
For examle: ? rtnl_link_set_name(link, "eth1.1");
After that we can obtain interafce index by calling ?rtnl_link_get_kernel(sock, 0, "eth1.1", &link) and rtnl_link_get_ifindex(link).
The problem is solved.
Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120405/abe0cb1b/attachment.html>

From tgraf at infradead.org  Thu Apr  5 04:12:25 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 5 Apr 2012 04:12:25 -0400
Subject: Creating VLAN links with libnl-route
In-Reply-To: <E1SFhJn-0001tL-O1.zhenya48-80-mail-ru@f160.mail.ru>
References: <E1SFhJn-0001tL-O1.zhenya48-80-mail-ru@f160.mail.ru>
Message-ID: <20120405081225.GD5124@canuck.infradead.org>

On Thu, Apr 05, 2012 at 11:41:19AM +0400, Gavrilenko Eugene wrote:
> Hello!
> As I realized 'vconfig' utitlity uses ioctl(...) interface rather than Netlink messages.
> To create? VLAN link with name "eth1.xxx" we just need to call function rtnl_link_set_name() before calling rtnl_link_add().
> For examle: ? rtnl_link_set_name(link, "eth1.1");
> After that we can obtain interafce index by calling ?rtnl_link_get_kernel(sock, 0, "eth1.1", &link) and rtnl_link_get_ifindex(link).
> The problem is solved.

Excactly, the kernel does not care how you name your interfaces.


From mawaszkiewicz at tycoint.com  Fri Apr  6 12:29:14 2012
From: mawaszkiewicz at tycoint.com (Waszkiewicz, Marek)
Date: Fri, 6 Apr 2012 17:29:14 +0100
Subject: [bug?] bug in the htb netlink messages ?
Message-ID: <8E459EED6B356D469071FDC814554FC4534DE1EB@COR1MBX01.emea.tsp.ad>

Hi,

I wonder if bug regarding htb rate and ceil values is fixed already ? If not when it will ?


Thanks
Marek


________________________________
Tyco Safety Products/CEM Systems Ltd.
Registered in Northern Ireland: NI 25728.  Registered Office: 195 Airport Road West, Belfast, BT3 9ED.

Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete any copies in your possession.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120406/5dbe5cdf/attachment.html>

From aranjbar4 at gmail.com  Mon Apr  9 17:07:47 2012
From: aranjbar4 at gmail.com (Ali Ranjbar)
Date: Mon, 9 Apr 2012 14:07:47 -0700
Subject: genl_ctrl_resolve failure
Message-ID: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>

I have a user space program that I thought should work, but it fails when
it calls the genl_Ctrl_resolve (see below). Can anyone help me why? I am
using the libl 3.2.7. Both user space and kernel module compile and link. I
cut and paste it here, so I maybe missing a } or something, but don't focus
on that. Like I said, both programs compile and link, so no syntax issue.

Kernel side during the init calls the genl_register_family(),
genl_register_ops(), so I don't understand why when the user space call to
genl_ctrl_resolve() failes?
 #include <stdio.h>
  2 #include <netlink/netlink.h>
  3 #include <netlink/genetlink.h>
  4 #include <netlink/genl/genl.h>
  5 #include <netlink/genl/ctrl.h>
  6 #include <linux/errno.h>

int clear_ctf_table() {
 58         struct nl_sock *sock;
 59         struct nl_msg *msg;
 60         int family;
 61         printf("**************Entering the USER SPACE portion***\n");
 62         /* Allocate a new netlink socket in userspace */
 63         sock = nl_socket_alloc();
 64         if(sock == NULL) {
 65                 printf("couldn't allocate socket\n");
 66                 goto out;
 67         }
 68
 69         /* Connect to the generic netlink socket family in the kernel */
 70         if (genl_connect(sock) < 0) {
 71                 printf("error while connecting\n");
 72                 goto out;
 73         }
 74
 75         /* obtain the family id for the CONTROL_GUARDIAN family */
 76         family = genl_ctrl_resolve(sock, "generic_netlink_family_name");
 77         if (family < 0) {
 78                 printf("error obtaining family\n");
 79                 goto out;
 80         }
........

It fails and prints "error obtaining family"

I followed the examples given and was expecting this to work.

On the kernel side I have the following code. The module is loaded in
kernel and I see the module is loaded in kernel and init passes

Kernel side code:
#include <net/netlink.h>
#include <net/genetlink.h>
#include <linux/module.h>
#include <linux/kernel.h>

/* attributes (variables): the index in this enum is used as a reference
for the type,
 *             userspace application has to indicate the corresponding type
 *             the policy is used for security considerations
 */
enum {
        DOC_GUARD_ATT_UNSPEC,
        DOC_GUARD_ATT_MSG,
        __DOC_GUARD_ATT_MAX,
};
#define DOC_GUARD_ATT_MAX (__DOC_GUARD_ATT_MAX - 1)

/* attribute policy: defines which attribute has which type (e.g int, char
* etc)
 * possible values defined in net/netlink.h
 */
static struct nla_policy doc_exmpl_genl_policy[DOC_GUARD_ATT_MAX + 1] = {
        [DOC_GUARD_ATT_MSG] = { .type = NLA_NUL_STRING },
};

#define VERSION_NR 1
/* family definition */
static struct genl_family doc_exmpl_gnl_family = {
        .id = GENL_ID_GENERATE,         //genetlink should generate an id
        .hdrsize = 0,
        .name ="generic_netlink_family_name",        //the name of this
family, used by userspace application
        .version = VERSION_NR,                   //version number
        .maxattr = DOC_GUARD_ATT_MAX,
};

/* commands: enumeration of all commands (functions),
 * used by userspace application to identify command to be ececuted
 */
enum {
        DOC_GUARD_COMM_UNSPEC,
        DOC_GUARD_COMM_ECHO,
        __DOC_GUARD_COMM_MAX,
};
#define DOC_GUARD_COMM_MAX (__DOC_GUARD_COMM_MAX - 1)


/* an echo command, receives a message, prints it and sends another message
back */
int guardian_exmpl_echo(struct sk_buff *skb_2, struct genl_info *info)
#include <net/netlink.h>
#include <net/genetlink.h>
#include <linux/module.h>
#include <linux/kernel.h>

/* attributes (variables): the index in this enum is used as a reference
for the type,
 *             userspace application has to indicate the corresponding type
 *             the policy is used for security considerations
 */
enum {
        DOC_GUARD_ATT_UNSPEC,
        DOC_GUARD_ATT_MSG,
        __DOC_GUARD_ATT_MAX,
};
#define DOC_GUARD_ATT_MAX (__DOC_GUARD_ATT_MAX - 1)

/* attribute policy: defines which attribute has which type (e.g int, char
* etc)
 * possible values defined in net/netlink.h
 */
static struct nla_policy doc_exmpl_genl_policy[DOC_GUARD_ATT_MAX + 1] = {
        [DOC_GUARD_ATT_MSG] = { .type = NLA_NUL_STRING },
};

#define VERSION_NR 1
/* family definition */
static struct genl_family doc_exmpl_gnl_family = {
        .id = GENL_ID_GENERATE,         //genetlink should generate an id
        .hdrsize = 0,
        .name ="generic_netlink_family_name",        //the name of this
family, used by userspace application
        .version = VERSION_NR,                   //version number
        .maxattr = DOC_GUARD_ATT_MAX,
};

/* commands: enumeration of all commands (functions),
 * used by userspace application to identify command to be ececuted
 */
enum {
        DOC_GUARD_COMM_UNSPEC,
        DOC_GUARD_COMM_ECHO,
        __DOC_GUARD_COMM_MAX,
};
#define DOC_GUARD_COMM_MAX (__DOC_GUARD_COMM_MAX - 1)


/* an echo command, receives a message, prints it and sends another message
back */
int guardian_exmpl_echo(struct sk_buff *skb_2, struct genl_info *info)
{
        struct nlattr *na;
        struct sk_buff *skb;
        int rc;
        void *msg_head;
        char * mydata;

        if (info == NULL)
                goto out;

        /*for each attribute there is an index in info->attrs which points
to a nlattr structure
         *in this structure the data is given
         */
        na = info->attrs[DOC_GUARD_ATT_MSG];
        if (na) {
                mydata = (char *)nla_data(na);
                if (mydata == NULL)
                        printk("error while receiving data\n");
                else
                        printk("received: %s\n", mydata);
                }
        else
                printk("no info->attrs %i\n", DOC_GUARD_ATT_MSG);

        /* send a message back*/
        /* allocate some memory, since the size is not yet known use
NLMSG_GOODSIZE*/
        skb = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
        if (skb == NULL)
                goto out;

        /* create the message headers */
        /* arguments of genlmsg_put:
           struct sk_buff *,
           int (sending) pid,
           int sequence number,
           struct genl_family *,
           int flags,
           u8 command index (why do we need this?)
        */
        msg_head = genlmsg_put(skb, 0, info->snd_seq+1,
&doc_exmpl_gnl_family, 0, DOC_GUARD_COMM_ECHO);
        if (msg_head == NULL) {
                rc = -ENOMEM;
                goto out;
                 }
        /* add a DOC_GUARD_ATT_MSG attribute (actual value to be sent) */
        rc = nla_put_string(skb, DOC_GUARD_ATT_MSG, "hello world from
kernel space");
        if (rc != 0)
                goto out;

        /* finalize the message */
        genlmsg_end(skb, msg_head);

        /* send the message back */
        rc = genlmsg_unicast(skb,info->snd_pid );
        if (rc != 0)
                goto out;
        return 0;

 out:
        printk("an error occured in guardian_exmpl_echo:\n");

      return 0;
}
/* commands: mapping between the command enumeration and the actual
function*/
struct genl_ops doc_exmpl_gnl_ops_echo = {
        .cmd = DOC_GUARD_COMM_ECHO,
        .flags = 0,
        .policy = doc_exmpl_genl_policy,
        .doit = guardian_exmpl_echo,
        .dumpit = NULL,
};

static int __init gnKernel_init(void)
{
        int rc;
        printk("INIT GENERIC NETLINK EXEMPLE MODULE\n");

        /*register new family*/
        rc = genl_register_family(&doc_exmpl_gnl_family);
        if (rc != 0)
                goto failure;

        printk("genl_register_family passed\n");
        /*register functions (commands) of the new family*/
        rc = genl_register_ops(&doc_exmpl_gnl_family,
&doc_exmpl_gnl_ops_echo);
        if (rc != 0){
                printk("register ops: %i\n",rc);
                genl_unregister_family(&doc_exmpl_gnl_family);
                goto failure;

135,2-16      71%
                     }

        printk("genl_register_ops passed\n");
        return 0;

  failure:
        printk("an error occured while inserting the generic netlink
example module\n");
        return -1;


}

static void __exit gnKernel_exit(void)
{
        int ret;
        printk("EXIT GENERIC NETLINK GUARDIAN EXEMPLE MODULE\n");
        /*unregister the functions*/
        ret = genl_unregister_ops(&doc_exmpl_gnl_family,
&doc_exmpl_gnl_ops_echo);
        if(ret != 0){
                printk("unregister ops: %i\n",ret);
                return;
        }
        /*unregister the family*/
        ret = genl_unregister_family(&doc_exmpl_gnl_family);
        if(ret !=0){
                printk("unregister family %i\n",ret);
        }
}


module_init(gnKernel_init);
module_exit(gnKernel_exit);
MODULE_LICENSE("GPL");
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120409/884e46d7/attachment.html>

From brett.ciphery at windriver.com  Wed Apr 11 10:55:44 2012
From: brett.ciphery at windriver.com (Brett Ciphery)
Date: Wed, 11 Apr 2012 10:55:44 -0400
Subject: bug in nl_cache_mngr_data_ready / nl_cache_refill / nl_cache_resync
Message-ID: <20120411145544.GF11748@windriver.com>

I've been using the libnl cache facilities recently for route and have
been seeing some interesting results when explicitly repopulating the
cache.  It seems the update functions won't process all the new events
in a single invocation.

The test case:

----------------------
...

        while(1) {
                err = nl_cache_mngr_data_ready(mngr);
                printf("err: %d\n", err);
                if (err > 0) {
                        count = 0;
                        nl_cache_foreach(route_cache, route_process, NULL);
                        printf("count: %d\n", count);
                }
                sleep(5);
        }

...
----------------------

count is a global variable which is incremented in route_process.  If I
run this program and in a separate terminal do:

for i in {1..10} ; do sudo ip route add $i.$i.$i.0/24 dev br0 ; done

then the count printf is incremented by 1 each time the loop runs.. e.g.
from 4 -> 14.  Similarly it's decremented from 14 -> 4 when I delete the
routes.

Using nl_cache_refill is a little different in that count remains
constant at 4 until I add the 10 routes, and then it drops to 1 but
route_process only sees/parses every odd route 2.2.2.0/24, 4.4.4.0/24
... 10.10.0.0/24.  Then count goes to 0 for a few iterations, and then
back to 14 (as expected).

I'm going to dig into this but it looks like it could be a little hairy.
Any thoughts as to which might be the offending function would help.

Cheers.
Brett


From nicolas.carrier.ext at parrot.com  Thu Apr 12 08:55:00 2012
From: nicolas.carrier.ext at parrot.com (Nicolas CARRIER)
Date: Thu, 12 Apr 2012 14:55:00 +0200
Subject: [PATCH]Remove unneeded header inclusion
In-Reply-To: <20120411145544.GF11748@windriver.com>
References: <20120411145544.GF11748@windriver.com>
Message-ID: <4F86D0A4.2030100@parrot.com>

Hello,
When using libnl, one can't include both netlink/route/link.h and net/if.h because it leads to structure redefinitions :
    ...
    /usr/include/linux/if.h:137:8: error: redefinition of 'struct ifmap'
    /usr/include/net/if.h:112:8: note: originally defined here
    ...

The attached patch removes the unneeded linux/if.h inclusion from netlink/route/link.h and fixed the problem for me.
It should apply to the current master's HEAD.

Note that I'm no libnl specialist and hence not sure this is the right way to achieve it...

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-don-t-include-linux-if.h-which-conflicts-with-net-if.patch
Type: text/x-diff
Size: 661 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120412/895cd72a/attachment.bin>

From brett.ciphery at windriver.com  Thu Apr 12 17:16:18 2012
From: brett.ciphery at windriver.com (Brett Ciphery)
Date: Thu, 12 Apr 2012 17:16:18 -0400
Subject: bug in nl_cache_mngr_data_ready / nl_cache_refill /
 nl_cache_resync [+patch proposition]
In-Reply-To: <20120411145544.GF11748@windriver.com>
References: <20120411145544.GF11748@windriver.com>
Message-ID: <20120412211618.GA5730@windriver.com>

[bug in nl_cache_mngr_data_ready / nl_cache_refill / nl_cache_resync] On 11/04/2012 (Wed 10:55) Brett Ciphery wrote:

> I've been using the libnl cache facilities recently for route and have
> been seeing some interesting results when explicitly repopulating the
> cache.  It seems the update functions won't process all the new events
> in a single invocation.
> 

<snip>

> 
> Using nl_cache_refill is a little different in that count remains
> constant at 4 until I add the 10 routes, and then it drops to 1 but
> route_process only sees/parses every odd route 2.2.2.0/24, 4.4.4.0/24
> ... 10.10.0.0/24.  Then count goes to 0 for a few iterations, and then
> back to 14 (as expected).
> 

Parsing every odd route turned out to be me accidentally using
nl_cache_mngr_data_ready() serially with nl_cache_refill().  After I
realized this it showed the same behaviour e.g. incrementing by 1.

--

The below patch makes nl_cache_mngr_data_ready() behave as expected, but
it's hard to say if it will have effects across the library.  I tried
nl_cache_refill() and it was less broken :-) ... but one remaining
issue.  The first looping call to nl_cache_refill() after 10 route
inserts caused it to add 20 routes (duplicates of the 10) to its cache.
The second loop iteration corrected it so count went from 24 -> 14.

Brett

--

Patch:

commit 6556567d7db11712bed32c9c4cfa1b6560d16da1
Author: Brett Ciphery <brett.ciphery at windriver.com>
Date:   Thu Apr 12 16:57:52 2012 -0400

    make recvmsgs() repeatedly call nl_recv() until error

    recvmsgs() was not processing all messages available in
    the socket and instead was handling one per call.  this
    had other transient effects such as not fully updating a
    cache when explicitly requested to do so using
    nl_cache_mngr_data_ready().

    Signed-off-by: Brett Ciphery <brett.ciphery at windriver.com>

diff --git a/lib/nl.c b/lib/nl.c
index bcf89da..c0c47ff 100644
--- a/lib/nl.c
+++ b/lib/nl.c
@@ -740,10 +740,7 @@ skip:
        msg = NULL;
        creds = NULL;

-       if (multipart) {
-               /* Multipart message not yet complete, continue reading
                */
-               goto continue_reading;
-       }
+       goto continue_reading;
 stop:
        err = 0;
 out:



From nicolas.carrier.ext at parrot.com  Fri Apr 13 07:51:44 2012
From: nicolas.carrier.ext at parrot.com (Nicolas CARRIER)
Date: Fri, 13 Apr 2012 13:51:44 +0200
Subject: [PATCH]Memory leak in classid.c
Message-ID: <4F881350.6000001@parrot.com>

Hello,
I'm using libnl in a program which I give to valgrind in order to track memory errors / leaks.
When my program exits, it complains about non-freed memory, allocated in 3 places in classid.c, at lines 280, 284 and 289.

It seems related to the module's constructor classid_init which allocates resources, with no destructor to free it.

The attached patch tries to fix this issue by registering a destructor which performs the tree liberation at exit.
-- 
Nicolas CARRIER - 6081 - 2?me centre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cleanly-destroy-search-tree-in-desctuctor.patch
Type: text/x-diff
Size: 1731 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120413/988ac681/attachment.bin>

From Hanks.Wang at watchguard.com  Tue Apr 17 05:51:25 2012
From: Hanks.Wang at watchguard.com (Hanks Wang)
Date: Tue, 17 Apr 2012 09:51:25 +0000
Subject: No subject
Message-ID: <43B2C23440FEB148BE71718D7751B349AF8AAD@ES02Ch.wgti.net>

Hi all,

In libnl3, I found a little problem.
When use NL_AUTO_PROVIDE as the third parameter for rtnl_route_alloc_cache, some routing info has been lost! Then use rtnl_route_get_flags to get flags, the result of flags is right.
Use 0 as the third parameter "int flags" for rtnl_route_alloc_cache, the routing info is correct, but then use rtnl_route_get_flags to get flags, it will always return zero.

I found that GNOME group also found this problem, but I have not found the similar bug in our bug queue. How to understand this problem?

uint32_t rtnl_route_get_flags(struct rtnl_route *route)
{
                return route->rt_flags;
}


int rtnl_route_alloc_cache(struct nl_sock *sk, int family, int flags,
                                                   struct nl_cache **result)
{
                struct nl_cache *cache;
                int err;

                if (!(cache = nl_cache_alloc(&rtnl_route_ops)))
                                return -NLE_NOMEM;

                cache->c_iarg1 = family;
                cache->c_iarg2 = flags;

                if (sk && (err = nl_cache_refill(sk, cache)) < 0) {
                                free(cache);
                                return err;
                }

                *result = cache;
                return 0;
}

Reference for GNOME on this libnl issue:
http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00233.html

Yours sincerely,
-Hanks.Wang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120417/4f6c4c9b/attachment.html>

From Hanks.Wang at watchguard.com  Tue Apr 17 05:52:25 2012
From: Hanks.Wang at watchguard.com (Hanks Wang)
Date: Tue, 17 Apr 2012 09:52:25 +0000
Subject: rtnl_route_alloc_cache lost some route messages
Message-ID: <43B2C23440FEB148BE71718D7751B349AF8ABB@ES02Ch.wgti.net>

Hi all,

In libnl3, I found a little problem.
When use NL_AUTO_PROVIDE as the third parameter for rtnl_route_alloc_cache, some routing info has been lost! Then use rtnl_route_get_flags to get flags, the result of flags is right.
Use 0 as the third parameter "int flags" for rtnl_route_alloc_cache, the routing info is correct, but then use rtnl_route_get_flags to get flags, it will always return zero.

I found that GNOME group also found this problem, but I have not found the similar bug in our bug queue. How to understand this problem?

uint32_t rtnl_route_get_flags(struct rtnl_route *route)
{
                return route->rt_flags;
}


int rtnl_route_alloc_cache(struct nl_sock *sk, int family, int flags,
                                                   struct nl_cache **result)
{
                struct nl_cache *cache;
                int err;

                if (!(cache = nl_cache_alloc(&rtnl_route_ops)))
                                return -NLE_NOMEM;

                cache->c_iarg1 = family;
                cache->c_iarg2 = flags;

                if (sk && (err = nl_cache_refill(sk, cache)) < 0) {
                                free(cache);
                                return err;
                }

                *result = cache;
                return 0;
}

Reference for GNOME on this libnl issue:
http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00233.html

Yours sincerely,
-Hanks.Wang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120417/ae562f20/attachment.html>

From tgraf at infradead.org  Thu Apr 19 12:51:44 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 19 Apr 2012 12:51:44 -0400
Subject: [PATCH]Memory leak in classid.c
In-Reply-To: <4F881350.6000001@parrot.com>
References: <4F881350.6000001@parrot.com>
Message-ID: <20120419165144.GB503@canuck.infradead.org>

On Fri, Apr 13, 2012 at 01:51:44PM +0200, Nicolas CARRIER wrote:
> Hello,
> I'm using libnl in a program which I give to valgrind in order to track memory errors / leaks.
> When my program exits, it complains about non-freed memory, allocated in 3 places in classid.c, at lines 280, 284 and 289.
> 
> It seems related to the module's constructor classid_init which allocates resources, with no destructor to free it.
> 
> The attached patch tries to fix this issue by registering a destructor which performs the tree liberation at exit.

Applied, thanks Nicolas


From tgraf at infradead.org  Thu Apr 19 12:57:06 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 19 Apr 2012 12:57:06 -0400
Subject: genl_ctrl_resolve failure
In-Reply-To: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
References: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
Message-ID: <20120419165706.GC503@canuck.infradead.org>

On Mon, Apr 09, 2012 at 02:07:47PM -0700, Ali Ranjbar wrote:
> I have a user space program that I thought should work, but it fails when
> it calls the genl_Ctrl_resolve (see below). Can anyone help me why? I am
> using the libl 3.2.7. Both user space and kernel module compile and link. I
> cut and paste it here, so I maybe missing a } or something, but don't focus
> on that. Like I said, both programs compile and link, so no syntax issue.
> 
> Kernel side during the init calls the genl_register_family(),
> genl_register_ops(), so I don't understand why when the user space call to
> genl_ctrl_resolve() failes?


Can you run src/genl-ctrl-list and show me the output? I haven't gone
through your kernel side code but the lookup code looks OK so I
wonder if the registration works correctly.


From tgraf at infradead.org  Thu Apr 19 13:09:10 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 19 Apr 2012 13:09:10 -0400
Subject: bug in nl_cache_mngr_data_ready / nl_cache_refill /
 nl_cache_resync [+patch proposition]
In-Reply-To: <20120412211618.GA5730@windriver.com>
References: <20120411145544.GF11748@windriver.com>
 <20120412211618.GA5730@windriver.com>
Message-ID: <20120419170910.GD503@canuck.infradead.org>

On Thu, Apr 12, 2012 at 05:16:18PM -0400, Brett Ciphery wrote:
> commit 6556567d7db11712bed32c9c4cfa1b6560d16da1
> Author: Brett Ciphery <brett.ciphery at windriver.com>
> Date:   Thu Apr 12 16:57:52 2012 -0400
> 
>     make recvmsgs() repeatedly call nl_recv() until error
> 
>     recvmsgs() was not processing all messages available in
>     the socket and instead was handling one per call.  this
>     had other transient effects such as not fully updating a
>     cache when explicitly requested to do so using
>     nl_cache_mngr_data_ready().
> 
>     Signed-off-by: Brett Ciphery <brett.ciphery at windriver.com>

Good catch Brett

Unfortunately I believe we can't change the behaviour of
nl_recvmsgs() from reading a single netlink message to
multiple by default. That would possibly break a lot of
applications.

What we can do is extend recvmsgs() do offer both behaviours
and have the cache manager direct it to continue reading
as long as there is data.

I'll fix that. I'm planning to look into and improve the
cache manager anyway. It's not reliable enough at the moment.


From tgraf at infradead.org  Thu Apr 19 13:10:24 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 19 Apr 2012 13:10:24 -0400
Subject: rtnl_route_alloc_cache lost some route messages
In-Reply-To: <43B2C23440FEB148BE71718D7751B349AF8ABB@ES02Ch.wgti.net>
References: <43B2C23440FEB148BE71718D7751B349AF8ABB@ES02Ch.wgti.net>
Message-ID: <20120419171024.GE503@canuck.infradead.org>

On Tue, Apr 17, 2012 at 09:52:25AM +0000, Hanks Wang wrote:
> Hi all,
> 
> In libnl3, I found a little problem.
> When use NL_AUTO_PROVIDE as the third parameter for rtnl_route_alloc_cache, some routing info has been lost! Then use rtnl_route_get_flags to get flags, the result of flags is right.
> Use 0 as the third parameter "int flags" for rtnl_route_alloc_cache, the routing info is correct, but then use rtnl_route_get_flags to get flags, it will always return zero.
> 
> I found that GNOME group also found this problem, but I have not found the similar bug in our bug queue. How to understand this problem?
> 
> uint32_t rtnl_route_get_flags(struct rtnl_route *route)
> {
>                 return route->rt_flags;
> }
> 
> 
> int rtnl_route_alloc_cache(struct nl_sock *sk, int family, int flags,
>                                                    struct nl_cache **result)
> {
>                 struct nl_cache *cache;
>                 int err;
> 
>                 if (!(cache = nl_cache_alloc(&rtnl_route_ops)))
>                                 return -NLE_NOMEM;
> 
>                 cache->c_iarg1 = family;
>                 cache->c_iarg2 = flags;
> 
>                 if (sk && (err = nl_cache_refill(sk, cache)) < 0) {
>                                 free(cache);
>                                 return err;
>                 }
> 
>                 *result = cache;
>                 return 0;
> }
> 
> Reference for GNOME on this libnl issue:
> http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00233.html

This is definitely a bug! Is there any chance someone is abusing
your route cache while you access it?


From ali.ranjbar at ieee.org  Thu Apr 19 17:46:33 2012
From: ali.ranjbar at ieee.org (Ali Ranjbar)
Date: Thu, 19 Apr 2012 14:46:33 -0700
Subject: genl_ctrl_resolve failure
In-Reply-To: <20120419165706.GC503@canuck.infradead.org>
References: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
 <20120419165706.GC503@canuck.infradead.org>
Message-ID: <CAO8NCspfyDkh2YT-8RtzJsTdgrGLJKaGds1qTeVoX08+7vK_+A@mail.gmail.com>

Thomas;

aranjbar at aranjbar-desktop:~/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src$
./genl-ctrl-list
./genl-ctrl-list: line 117:
/home/aranjbar/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src/.libs/lt-genl-ctrl-list:
cannot execute binary file
./genl-ctrl-list: line 117:
/home/aranjbar/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src/.libs/lt-genl-ctrl-list:
Success
aranjbar at aranjbar-desktop:~/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src$



I hope this is what you were asking for. Sorry, I am new to using libnl. If
this isn't the right info, please send me more detailed instructions.
Thanks for your help in advance.

On Thu, Apr 19, 2012 at 9:57 AM, Thomas Graf <tgraf at infradead.org> wrote:

> On Mon, Apr 09, 2012 at 02:07:47PM -0700, Ali Ranjbar wrote:
> > I have a user space program that I thought should work, but it fails when
> > it calls the genl_Ctrl_resolve (see below). Can anyone help me why? I am
> > using the libl 3.2.7. Both user space and kernel module compile and
> link. I
> > cut and paste it here, so I maybe missing a } or something, but don't
> focus
> > on that. Like I said, both programs compile and link, so no syntax issue.
> >
> > Kernel side during the init calls the genl_register_family(),
> > genl_register_ops(), so I don't understand why when the user space call
> to
> > genl_ctrl_resolve() failes?
>
>
> Can you run src/genl-ctrl-list and show me the output? I haven't gone
> through your kernel side code but the lookup code looks OK so I
> wonder if the registration works correctly.
>



-- 

Best Regards;
Ali Ranjbar
Founder
Embedded Software DTI Corp.
Mobile: 847-337-8895
Email: ali.ranjbar at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120419/2c973847/attachment.html>

From Hanks.Wang at watchguard.com  Thu Apr 19 21:24:58 2012
From: Hanks.Wang at watchguard.com (Hanks Wang)
Date: Fri, 20 Apr 2012 01:24:58 +0000
Subject: rtnl_route_alloc_cache lost some route messages
In-Reply-To: <43B2C23440FEB148BE71718D7751B349AF987F@ES02Ch.wgti.net>
References: <43B2C23440FEB148BE71718D7751B349AF8ABB@ES02Ch.wgti.net>,
 <20120419171024.GE503@canuck.infradead.org>
 <43B2C23440FEB148BE71718D7751B349AF987F@ES02Ch.wgti.net>
Message-ID: <43B2C23440FEB148BE71718D7751B349AF98F1@ES02Ch.wgti.net>

Hi Thomas,

Any patch to fix it? I see one patch on our git tree, because there is little comment, I don't confirm it. The patch information is attached following.



avoid dangling co_major_cache reference to NL_AUTO_PROVIDE caches

authorAlexander Sack <asac at jwsdot.com>
Fri, 21 Oct 2011 06:31:39 +0800 (00:31 +0200)
committerThomas Graf <tgraf at redhat.com>
Wed, 11 Jan 2012 19:31:40 +0800 (12:31 +0100)
commit9819717444e8f58bcf707aac724488c4d5f4e1d7
tree164d098fc82cb4fbe2967b36623caf475b5b7f3btree | snapshot
parent4a7791eca1268e24225c33ed1c00c140a14cd955commit | diff


avoid dangling co_major_cache reference to NL_AUTO_PROVIDE caches

lib/cache_mngr.c



Really thanks for your help.
-Hanks.Wang


________________________________________
???: Thomas Graf [tgr at infradead.org] ?? Thomas Graf [tgraf at infradead.org]
????: 2012?4?20? 1:10
?: Hanks Wang
Cc: libnl at lists.infradead.org; tgraf at redhat.com
??: Re: rtnl_route_alloc_cache lost some route messages

On Tue, Apr 17, 2012 at 09:52:25AM +0000, Hanks Wang wrote:
> Hi all,
>
> In libnl3, I found a little problem.
> When use NL_AUTO_PROVIDE as the third parameter for rtnl_route_alloc_cache, some routing info has been lost! Then use rtnl_route_get_flags to get flags, the result of flags is right.
> Use 0 as the third parameter "int flags" for rtnl_route_alloc_cache, the routing info is correct, but then use rtnl_route_get_flags to get flags, it will always return zero.
>
> I found that GNOME group also found this problem, but I have not found the similar bug in our bug queue. How to understand this problem?
>
> uint32_t rtnl_route_get_flags(struct rtnl_route *route)
> {
>                 return route->rt_flags;
> }
>
>
> int rtnl_route_alloc_cache(struct nl_sock *sk, int family, int flags,
>                                                    struct nl_cache **result)
> {
>                 struct nl_cache *cache;
>                 int err;
>
>                 if (!(cache = nl_cache_alloc(&rtnl_route_ops)))
>                                 return -NLE_NOMEM;
>
>                 cache->c_iarg1 = family;
>                 cache->c_iarg2 = flags;
>
>                 if (sk && (err = nl_cache_refill(sk, cache)) < 0) {
>                                 free(cache);
>                                 return err;
>                 }
>
>                 *result = cache;
>                 return 0;
> }
>
> Reference for GNOME on this libnl issue:
> http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00233.html

This is definitely a bug! Is there any chance someone is abusing
your route cache while you access it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120420/476925c9/attachment-0001.html>

From tgraf at infradead.org  Fri Apr 20 07:10:20 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Fri, 20 Apr 2012 07:10:20 -0400
Subject: rtnl_route_alloc_cache lost some route messages
In-Reply-To: <43B2C23440FEB148BE71718D7751B349AF98F1@ES02Ch.wgti.net>
References: <43B2C23440FEB148BE71718D7751B349AF8ABB@ES02Ch.wgti.net>
 <20120419171024.GE503@canuck.infradead.org>
 <43B2C23440FEB148BE71718D7751B349AF987F@ES02Ch.wgti.net>
 <43B2C23440FEB148BE71718D7751B349AF98F1@ES02Ch.wgti.net>
Message-ID: <20120420111020.GF503@canuck.infradead.org>

On Fri, Apr 20, 2012 at 01:24:58AM +0000, Hanks Wang wrote:
> Hi Thomas,
> 
> Any patch to fix it? I see one patch on our git tree, because there is little comment, I don't confirm it. The patch information is attached following.
> 
> 
> 
> avoid dangling co_major_cache reference to NL_AUTO_PROVIDE caches
> 
> authorAlexander Sack <asac at jwsdot.com>
> Fri, 21 Oct 2011 06:31:39 +0800 (00:31 +0200)
> committerThomas Graf <tgraf at redhat.com>
> Wed, 11 Jan 2012 19:31:40 +0800 (12:31 +0100)
> commit9819717444e8f58bcf707aac724488c4d5f4e1d7
> tree164d098fc82cb4fbe2967b36623caf475b5b7f3btree | snapshot
> parent4a7791eca1268e24225c33ed1c00c140a14cd955commit | diff
> 
> 
> avoid dangling co_major_cache reference to NL_AUTO_PROVIDE caches
> 
> lib/cache_mngr.c

This would be an explanation. Do you see the issue with the patch
included?


From tgraf at infradead.org  Fri Apr 20 07:17:46 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Fri, 20 Apr 2012 07:17:46 -0400
Subject: genl_ctrl_resolve failure
In-Reply-To: <CAO8NCspfyDkh2YT-8RtzJsTdgrGLJKaGds1qTeVoX08+7vK_+A@mail.gmail.com>
References: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
 <20120419165706.GC503@canuck.infradead.org>
 <CAO8NCspfyDkh2YT-8RtzJsTdgrGLJKaGds1qTeVoX08+7vK_+A@mail.gmail.com>
Message-ID: <20120420111746.GG503@canuck.infradead.org>

On Thu, Apr 19, 2012 at 02:46:33PM -0700, Ali Ranjbar wrote:
> Thomas;
> 
> aranjbar at aranjbar-desktop:~/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src$
> ./genl-ctrl-list
> ./genl-ctrl-list: line 117:
> /home/aranjbar/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src/.libs/lt-genl-ctrl-list:
> cannot execute binary file
> ./genl-ctrl-list: line 117:
> /home/aranjbar/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src/.libs/lt-genl-ctrl-list:
> Success
> aranjbar at aranjbar-desktop:~/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src$
> 
> 
> 
> I hope this is what you were asking for. Sorry, I am new to using libnl. If
> this isn't the right info, please send me more detailed instructions.
> Thanks for your help in advance.

Something seems to have screwed up your build. The output should be
something like this:

[tgraf at lsx libnl]$ src/genl-ctrl-list 
0x0010 nlctrl version 2
0x0011 NLBL_MGMT version 3
0x0012 NLBL_CIPSOv4 version 3
0x0013 NLBL_UNLBL version 3
0x0014 acpi_event version 1
0x0015 thermal_event version 1
0x0016 VFS_DQUOT version 1
0x0017 TASKSTATS version 1
0x0018 NET_DM version 2
[tgraf at lsx libnl]$ 

This allows you to verify whether your kernel side generic netlink
family was successfully registered.

It even allows you to list the operations that you have registered:

[tgraf at lsx libnl]$ src/genl-ctrl-list -f details
0x0010 nlctrl version 2
    hdrsize 0 maxattr 7
      op GETFAMILY (0x03) <has-doit,has-dump,has-policy>
      grp notify (0x10)
0x0011 NLBL_MGMT version 3
    hdrsize 0 maxattr 10
      op unknown (0x01) <admin-perm,has-doit,has-policy>
      op unknown (0x02) <admin-perm,has-doit,has-policy>
      op unknown (0x03) <has-dump,has-policy>
      op unknown (0x04) <admin-perm,has-doit,has-policy>
      op unknown (0x05) <admin-perm,has-doit,has-policy>
      op unknown (0x06) <has-doit,has-policy>
      op unknown (0x07) <has-dump,has-policy>
      op unknown (0x08) <has-doit,has-policy>
0x0012 NLBL_CIPSOv4 version 3
    hdrsize 0 maxattr 12
      op unknown (0x01) <admin-perm,has-doit,has-policy>
      op unknown (0x02) <admin-perm,has-doit,has-policy>
      op unknown (0x03) <has-doit,has-policy>
      op unknown (0x04) <has-dump,has-policy>
0x0013 NLBL_UNLBL version 3
    hdrsize 0 maxattr 7
      op unknown (0x03) <admin-perm,has-doit,has-policy>
      op unknown (0x04) <admin-perm,has-doit,has-policy>
      op unknown (0x05) <has-dump,has-policy>
      op unknown (0x06) <admin-perm,has-doit,has-policy>
      op unknown (0x07) <admin-perm,has-doit,has-policy>
      op unknown (0x08) <has-dump,has-policy>
      op unknown (0x01) <admin-perm,has-doit,has-policy>
      op unknown (0x02) <has-doit,has-policy>
0x0014 acpi_event version 1
    hdrsize 0 maxattr 1
      grp acpi_mc_group (0x01)
0x0015 thermal_event version 1
    hdrsize 0 maxattr 1
      grp thermal_mc_grou (0x02)
0x0016 VFS_DQUOT version 1
    hdrsize 0 maxattr 6
0x0017 TASKSTATS version 1
    hdrsize 0 maxattr 4
      op unknown (0x01) <admin-perm,has-doit,has-policy>
      op unknown (0x04) <has-doit,has-policy>
0x0018 NET_DM version 2
    hdrsize 0 maxattr 4
      op unknown (0x02) <has-doit>
      op unknown (0x03) <has-doit>
      op unknown (0x04) <has-doit>



From ali.ranjbar at ieee.org  Fri Apr 20 13:51:02 2012
From: ali.ranjbar at ieee.org (Ali Ranjbar)
Date: Fri, 20 Apr 2012 10:51:02 -0700
Subject: genl_ctrl_resolve failure
In-Reply-To: <20120420111746.GG503@canuck.infradead.org>
References: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
 <20120419165706.GC503@canuck.infradead.org>
 <CAO8NCspfyDkh2YT-8RtzJsTdgrGLJKaGds1qTeVoX08+7vK_+A@mail.gmail.com>
 <20120420111746.GG503@canuck.infradead.org>
Message-ID: <CAO8NCsqF=L97fj-Ve3793v1UcD1Mv5NfeEEzdea3MHviByHLnQ@mail.gmail.com>

Thomas;

Interesting, I had to cross compile the libnl using a compiler for mips
provided by Broadcom, I don't know if that could be an issue. I had
integrate this library within an existing code base which has 1000 of
Makefile and all. One more thing. As you see below, I only linked nl and
genl not the route or nf portions of the library? Could this be a problem?
I thought, I can do this, since you have divided the library to 4 different
portion (so final execution won't get too big), so I only link portions of
the library I need. The way I determined which library I need was to start
with all and build, then start commenting out specific libraries and see if
linker complains. This is how i determined that I only need lnl-3 and
lnl-genl-3.

Thanks for your help.

#LDFLAGS   += -lnl-nf-3
LDFLAGS   += -lpthread -lsqlite3 -liniparser -lcrypt -lnl-3 -lnl-genl-3
#LDFLAGS   += -lcrypt -lnl-route-3


On Fri, Apr 20, 2012 at 4:17 AM, Thomas Graf <tgraf at infradead.org> wrote:

> On Thu, Apr 19, 2012 at 02:46:33PM -0700, Ali Ranjbar wrote:
> > Thomas;
> >
> > aranjbar at aranjbar-desktop
> :~/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src$
> > ./genl-ctrl-list
> > ./genl-ctrl-list: line 117:
> >
> /home/aranjbar/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src/.libs/lt-genl-ctrl-list:
> > cannot execute binary file
> > ./genl-ctrl-list: line 117:
> >
> /home/aranjbar/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src/.libs/lt-genl-ctrl-list:
> > Success
> > aranjbar at aranjbar-desktop
> :~/p4ws/alranjba/lego/branches/e2xxx_dev_ctf/bentley/output/debug/libnl-3.2.7/src$
> >
> >
> >
> > I hope this is what you were asking for. Sorry, I am new to using libnl.
> If
> > this isn't the right info, please send me more detailed instructions.
> > Thanks for your help in advance.
>
> Something seems to have screwed up your build. The output should be
> something like this:
>
> [tgraf at lsx libnl]$ src/genl-ctrl-list
> 0x0010 nlctrl version 2
> 0x0011 NLBL_MGMT version 3
> 0x0012 NLBL_CIPSOv4 version 3
> 0x0013 NLBL_UNLBL version 3
> 0x0014 acpi_event version 1
> 0x0015 thermal_event version 1
> 0x0016 VFS_DQUOT version 1
> 0x0017 TASKSTATS version 1
> 0x0018 NET_DM version 2
> [tgraf at lsx libnl]$
>
> This allows you to verify whether your kernel side generic netlink
> family was successfully registered.
>
> It even allows you to list the operations that you have registered:
>
> [tgraf at lsx libnl]$ src/genl-ctrl-list -f details
> 0x0010 nlctrl version 2
>    hdrsize 0 maxattr 7
>      op GETFAMILY (0x03) <has-doit,has-dump,has-policy>
>      grp notify (0x10)
> 0x0011 NLBL_MGMT version 3
>    hdrsize 0 maxattr 10
>      op unknown (0x01) <admin-perm,has-doit,has-policy>
>      op unknown (0x02) <admin-perm,has-doit,has-policy>
>      op unknown (0x03) <has-dump,has-policy>
>      op unknown (0x04) <admin-perm,has-doit,has-policy>
>      op unknown (0x05) <admin-perm,has-doit,has-policy>
>      op unknown (0x06) <has-doit,has-policy>
>      op unknown (0x07) <has-dump,has-policy>
>      op unknown (0x08) <has-doit,has-policy>
> 0x0012 NLBL_CIPSOv4 version 3
>    hdrsize 0 maxattr 12
>      op unknown (0x01) <admin-perm,has-doit,has-policy>
>      op unknown (0x02) <admin-perm,has-doit,has-policy>
>      op unknown (0x03) <has-doit,has-policy>
>      op unknown (0x04) <has-dump,has-policy>
> 0x0013 NLBL_UNLBL version 3
>    hdrsize 0 maxattr 7
>      op unknown (0x03) <admin-perm,has-doit,has-policy>
>      op unknown (0x04) <admin-perm,has-doit,has-policy>
>      op unknown (0x05) <has-dump,has-policy>
>      op unknown (0x06) <admin-perm,has-doit,has-policy>
>      op unknown (0x07) <admin-perm,has-doit,has-policy>
>      op unknown (0x08) <has-dump,has-policy>
>      op unknown (0x01) <admin-perm,has-doit,has-policy>
>      op unknown (0x02) <has-doit,has-policy>
> 0x0014 acpi_event version 1
>    hdrsize 0 maxattr 1
>      grp acpi_mc_group (0x01)
> 0x0015 thermal_event version 1
>    hdrsize 0 maxattr 1
>      grp thermal_mc_grou (0x02)
> 0x0016 VFS_DQUOT version 1
>    hdrsize 0 maxattr 6
> 0x0017 TASKSTATS version 1
>    hdrsize 0 maxattr 4
>      op unknown (0x01) <admin-perm,has-doit,has-policy>
>      op unknown (0x04) <has-doit,has-policy>
> 0x0018 NET_DM version 2
>    hdrsize 0 maxattr 4
>      op unknown (0x02) <has-doit>
>      op unknown (0x03) <has-doit>
>      op unknown (0x04) <has-doit>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120420/b2828949/attachment.html>

From tgraf at infradead.org  Fri Apr 20 16:39:04 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Fri, 20 Apr 2012 16:39:04 -0400
Subject: genl_ctrl_resolve failure
In-Reply-To: <CAO8NCsqF=L97fj-Ve3793v1UcD1Mv5NfeEEzdea3MHviByHLnQ@mail.gmail.com>
References: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
 <20120419165706.GC503@canuck.infradead.org>
 <CAO8NCspfyDkh2YT-8RtzJsTdgrGLJKaGds1qTeVoX08+7vK_+A@mail.gmail.com>
 <20120420111746.GG503@canuck.infradead.org>
 <CAO8NCsqF=L97fj-Ve3793v1UcD1Mv5NfeEEzdea3MHviByHLnQ@mail.gmail.com>
Message-ID: <20120420203904.GH503@canuck.infradead.org>

On Fri, Apr 20, 2012 at 10:51:02AM -0700, Ali Ranjbar wrote:
> Thomas;
> 
> Interesting, I had to cross compile the libnl using a compiler for mips
> provided by Broadcom, I don't know if that could be an issue.

This could be related. What I am trying to say here is that there is
code in src/genl-ctrl-list.c which can easily verify whether the
kernel part is functioning properly so you can easily track down the
origin of your problem quickly.

> I had
> integrate this library within an existing code base which has 1000 of
> Makefile and all. One more thing. As you see below, I only linked nl and
> genl not the route or nf portions of the library? Could this be a problem?
> I thought, I can do this, since you have divided the library to 4 different
> portion (so final execution won't get too big), so I only link portions of
> the library I need. The way I determined which library I need was to start
> with all and build, then start commenting out specific libraries and see if
> linker complains. This is how i determined that I only need lnl-3 and
> lnl-genl-3.

This is perfectly acceptable and you are encouraged to do so.


From ali.ranjbar at ieee.org  Fri Apr 20 16:48:12 2012
From: ali.ranjbar at ieee.org (Ali Ranjbar)
Date: Fri, 20 Apr 2012 13:48:12 -0700
Subject: genl_ctrl_resolve failure
In-Reply-To: <20120420203904.GH503@canuck.infradead.org>
References: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
 <20120419165706.GC503@canuck.infradead.org>
 <CAO8NCspfyDkh2YT-8RtzJsTdgrGLJKaGds1qTeVoX08+7vK_+A@mail.gmail.com>
 <20120420111746.GG503@canuck.infradead.org>
 <CAO8NCsqF=L97fj-Ve3793v1UcD1Mv5NfeEEzdea3MHviByHLnQ@mail.gmail.com>
 <20120420203904.GH503@canuck.infradead.org>
Message-ID: <CAO8NCsqM2y16s6mMTxfpTrZsgoZK8FrSqePg7T=6s_LnqanezQ@mail.gmail.com>

For this test genl-ctrl-list to work properly, shouldn't there be a kernel
module who is listening for this? In other words, should I run this command
after I have loaded  and insmod the kernel part of my code? This library
is in user space, after all right, whereas the netlink related code is in
the kernel.

On Fri, Apr 20, 2012 at 1:39 PM, Thomas Graf <tgraf at infradead.org> wrote:

> On Fri, Apr 20, 2012 at 10:51:02AM -0700, Ali Ranjbar wrote:
> > Thomas;
> >
> > Interesting, I had to cross compile the libnl using a compiler for mips
> > provided by Broadcom, I don't know if that could be an issue.
>
> This could be related. What I am trying to say here is that there is
> code in src/genl-ctrl-list.c which can easily verify whether the
> kernel part is functioning properly so you can easily track down the
> origin of your problem quickly.
>
> > I had
> > integrate this library within an existing code base which has 1000 of
> > Makefile and all. One more thing. As you see below, I only linked nl and
> > genl not the route or nf portions of the library? Could this be a
> problem?
> > I thought, I can do this, since you have divided the library to 4
> different
> > portion (so final execution won't get too big), so I only link portions
> of
> > the library I need. The way I determined which library I need was to
> start
> > with all and build, then start commenting out specific libraries and see
> if
> > linker complains. This is how i determined that I only need lnl-3 and
> > lnl-genl-3.
>
> This is perfectly acceptable and you are encouraged to do so.
>



-- 

Best Regards;
Ali Ranjbar
Founder
Embedded Software DTI Corp.
Mobile: 847-337-8895
Email: ali.ranjbar at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120420/6b532cef/attachment.html>

From tgraf at infradead.org  Sat Apr 21 03:56:56 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Sat, 21 Apr 2012 03:56:56 -0400
Subject: genl_ctrl_resolve failure
In-Reply-To: <CAO8NCsqM2y16s6mMTxfpTrZsgoZK8FrSqePg7T=6s_LnqanezQ@mail.gmail.com>
References: <CAO8NCso-1wEmfmvqOaGYUZ2gwnBnHKYGy_iBGJG0w4czhX-Ddg@mail.gmail.com>
 <20120419165706.GC503@canuck.infradead.org>
 <CAO8NCspfyDkh2YT-8RtzJsTdgrGLJKaGds1qTeVoX08+7vK_+A@mail.gmail.com>
 <20120420111746.GG503@canuck.infradead.org>
 <CAO8NCsqF=L97fj-Ve3793v1UcD1Mv5NfeEEzdea3MHviByHLnQ@mail.gmail.com>
 <20120420203904.GH503@canuck.infradead.org>
 <CAO8NCsqM2y16s6mMTxfpTrZsgoZK8FrSqePg7T=6s_LnqanezQ@mail.gmail.com>
Message-ID: <20120421075656.GI503@canuck.infradead.org>

On Fri, Apr 20, 2012 at 01:48:12PM -0700, Ali Ranjbar wrote:
> For this test genl-ctrl-list to work properly, shouldn't there be a kernel
> module who is listening for this? In other words, should I run this command
> after I have loaded  and insmod the kernel part of my code? This library
> is in user space, after all right, whereas the netlink related code is in
> the kernel.

The kernel part is called controller and is built into the generic
netlink module. The generic netlink module is always built into the
kernel.

It is the very same module/interface you use to resolve a generic
netlink family name to its identifier from userspace.


From adrian.ban at mantech.ro  Sat Apr 21 06:26:03 2012
From: adrian.ban at mantech.ro (Adrian Ban)
Date: Sat, 21 Apr 2012 13:26:03 +0300
Subject: Using libnl to create u32 hashkey
In-Reply-To: <4EE766E3.3090308@mantech.ro>
References: <4ECAC011.1020306@mantech.ro>
 <20111122112532.GB30664@canuck.infradead.org> <4ECD895B.90609@mantech.ro>
 <4ECECF3F.2050007@mantech.ro> <20111213143057.GE8885@canuck.infradead.org>
 <4EE766E3.3090308@mantech.ro>
Message-ID: <4F928B3B.30204@mantech.ro>

Hi,

Any progress with hash filters and the patch I've submitted?

Best regards,
Adrian

On 12/13/2011 04:53 PM, Adrian Ban wrote:
> Thanks for info.
>
> On 12/13/2011 4:30 PM, Thomas Graf wrote:
>> On Fri, Nov 25, 2011 at 01:11:59AM +0200, Adrian Ban wrote:
>>> Hi,
>>>
>>> Here is the patch for u32 hash filters for libnl3.
>>> Attached you have the patch and the source code for HTB qdisc, class
>>> and hash filters.
>> FYI, this is still in my queue to be processed. I haven't had time
>> to look at this closely. I want to get the API right the first time.
>> Will process this ASAP.
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl


From tgraf at infradead.org  Sat Apr 21 06:51:20 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Sat, 21 Apr 2012 06:51:20 -0400
Subject: bug in nl_cache_mngr_data_ready / nl_cache_refill /
 nl_cache_resync [+patch proposition]
In-Reply-To: <20120419170910.GD503@canuck.infradead.org>
References: <20120411145544.GF11748@windriver.com>
 <20120412211618.GA5730@windriver.com>
 <20120419170910.GD503@canuck.infradead.org>
Message-ID: <20120421105120.GA27640@canuck.infradead.org>

On Thu, Apr 19, 2012 at 01:09:10PM -0400, Thomas Graf wrote:
> What we can do is extend recvmsgs() do offer both behaviours
> and have the cache manager direct it to continue reading
> as long as there is data.
> 
> I'll fix that. I'm planning to look into and improve the
> cache manager anyway. It's not reliable enough at the moment.

See commit a518a31 (cache_mngr: Let nl_cache_mngr_data_ready()
read multiple messages).

It should fix your case Brett while keeping the behaviour for
blocking sockets the same.


From tgraf at infradead.org  Sat Apr 21 09:54:27 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Sat, 21 Apr 2012 09:54:27 -0400
Subject: rtnl_route_alloc_cache lost some route messages
In-Reply-To: <20120420111020.GF503@canuck.infradead.org>
References: <43B2C23440FEB148BE71718D7751B349AF8ABB@ES02Ch.wgti.net>
 <20120419171024.GE503@canuck.infradead.org>
 <43B2C23440FEB148BE71718D7751B349AF987F@ES02Ch.wgti.net>
 <43B2C23440FEB148BE71718D7751B349AF98F1@ES02Ch.wgti.net>
 <20120420111020.GF503@canuck.infradead.org>
Message-ID: <20120421135427.GB27640@canuck.infradead.org>

On Fri, Apr 20, 2012 at 07:10:20AM -0400, Thomas Graf wrote:
> This would be an explanation. Do you see the issue with the patch
> included?

I have pushed several cache manager related fixes to the git tree
and provided a new testing tool in tests/test-cache-mngr.c

Run 'make check' to compile it.

It will dump the contents of the manager after each polling
intervall and thus will allow for easy debugging of such problems.

$ tests/test-cache-mngr route/link
cache-manager <0xb613a0>
  .protocol = route
  .flags    = 0x3
  .nassocs  = 16
  .sock     = <0xb61330>
  .cache[0] = <0xb61370> {
    .name = route/link
    .change_func = <0x400af0>
    .change_data = <(nil)>
    .nitems = 8
    .objects = {
      lo loopback <loopback,up,running,lowerup> 
      p20p1 ether 00:1f:d0:ae:3f:2a <broadcast,multicast,up> 
      p21p1 ether 00:1f:d0:ae:41:99 <broadcast,multicast,up,running,lowerup> 
      virbr1 ether 52:54:00:33:4b:7a <broadcast,multicast,up> 
      virbr1-nic ether 52:54:00:33:4b:7a master virbr1 <broadcast,multicast> 
      virbr0 ether 52:54:00:cb:da:db <broadcast,multicast,up> 
      virbr0-nic ether 52:54:00:cb:da:db master virbr0 <broadcast,multicast> 
      tun0 nohdr <pointopoint,multicast,noarp,up,running,lowerup> 
    }
  }



From bruiz at alienvault.com  Sat Apr 21 10:57:44 2012
From: bruiz at alienvault.com (Borja Ruiz-Castro)
Date: Sat, 21 Apr 2012 16:57:44 +0200
Subject: libnl segmentation fault
Message-ID: <CAONoiAGh4gobxyTC_MDoTzn+EVW9Dgxz6q5CH1_r6Cr2yBVXXA@mail.gmail.com>

Hi!

I think a just found a bug using lorcon + linbl (segmentation fault)

The problem is *genl_unregister():*


(gdb) disass 0x00007ffff77afb8d
Dump of assembler code for function genl_unregister:
=> 0x00007ffff77afb80 <+0>: push   %rbx
   0x00007ffff77afb81 <+1>: mov    %rdi,%rbx
   0x00007ffff77afb84 <+4>: callq  0x7ffff778dbf0
<nl_cache_mngt_unregister at plt>
   0x00007ffff77afb89 <+9>: mov    0x40(%rbx),%rax
*   0x00007ffff77afb8d <+13>: mov    0x28(%rax),%rdx*
   0x00007ffff77afb91 <+17>: mov    0x30(%rax),%rcx
   0x00007ffff77afb95 <+21>: mov    %rcx,0x8(%rdx)
   0x00007ffff77afb99 <+25>: mov    0x30(%rax),%rax
   0x00007ffff77afb9d <+29>: mov    %rdx,(%rax)
   0x00007ffff77afba0 <+32>: pop    %rbx
   0x00007ffff77afba1 <+33>: retq
End of assembler dump.


A segmentation fault occurs when trying to copy %rdx into (%rax)+0x28,
because the content's of %eax is 0x00!

I attach the debug log file!

Regards!

Borja Ruiz.

-- 
Borja Ruiz-Castro
Senior Security Consultant
QA testing engineer



*AlienVault Europe* C/Cronos 63, Planta 2a, Oficina 6
CP: 28037 Madrid, Spain Tlf   +34 91 515-1344
Fax +34 91 413-5968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120421/da961a4e/attachment.html>
-------------- next part --------------
borja at arch:~/lorcon $ ldd uno
    linux-vdso.so.1 =>  (0x00007fffd0dff000)
    /usr/lib/libswmhack.so.0.0 (0x00007f242af5d000)
    liborcon-2.0.0.so => /usr/local/lib/liborcon-2.0.0.so (0x00007f242ad4f000)
    libnl.so.1 => /usr/lib/libnl.so.1 (0x00007f242aafd000)
    libpcap.so.1 => /usr/lib/libpcap.so.1 (0x00007f242a8bf000)
    libc.so.6 => /lib/libc.so.6 (0x00007f242a51e000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f242a1e4000)
    libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f2429fdb000)
    libXtst.so.6 => /usr/lib/libXtst.so.6 (0x00007f2429dd4000)
    libm.so.6 => /lib/libm.so.6 (0x00007f2429adf000)
    libnl-genl-3.so.200 => /usr/lib/libnl-genl-3.so.200 (0x00007f24298da000)
    libnl-3.so.200 => /usr/lib/libnl-3.so.200 (0x00007f24296c1000)
    /lib/ld-linux-x86-64.so.2 (0x00007f242b15f000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f24294a3000)
    libdl.so.2 => /lib/libdl.so.2 (0x00007f242929f000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f242908c000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f2428e81000)
    libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f2428c73000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007f2428a57000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f2428853000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f242864d000)
borja at arch:~/lorcon $ gdb ./uno
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/borja/lorcon/uno...done.
(gdb) r
Starting program: /home/borja/lorcon/uno 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
argc: 1
Uso: /home/borja/lorcon/uno <opcion> 

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77afb8d in genl_unregister () from /usr/lib/libnl.so.1
(gdb) bt
#0  0x00007ffff77afb8d in genl_unregister () from /usr/lib/libnl.so.1
#1  0x00007ffff7de9f3f in _dl_fini () from /lib/ld-linux-x86-64.so.2
#2  0x00007ffff71d17c1 in __run_exit_handlers () from /lib/libc.so.6
#3  0x00007ffff71d1845 in exit () from /lib/libc.so.6
#4  0x0000000000400d7e in main (argc=1, argv=0x7fffffffe8f8) at uno.c:40
(gdb) backtrace 
#0  0x00007ffff77afb8d in genl_unregister () from /usr/lib/libnl.so.1
#1  0x00007ffff7de9f3f in _dl_fini () from /lib/ld-linux-x86-64.so.2
#2  0x00007ffff71d17c1 in __run_exit_handlers () from /lib/libc.so.6
#3  0x00007ffff71d1845 in exit () from /lib/libc.so.6
#4  0x0000000000400d7e in main (argc=1, argv=0x7fffffffe8f8) at uno.c:40
(gdb) 
#0  0x00007ffff77afb8d in genl_unregister () from /usr/lib/libnl.so.1
#1  0x00007ffff7de9f3f in _dl_fini () from /lib/ld-linux-x86-64.so.2
#2  0x00007ffff71d17c1 in __run_exit_handlers () from /lib/libc.so.6
#3  0x00007ffff71d1845 in exit () from /lib/libc.so.6
#4  0x0000000000400d7e in main (argc=1, argv=0x7fffffffe8f8) at uno.c:40
(gdb) q
A debugging session is active.

    Inferior 1 [process 25370] will be killed.

Quit anyway? (y or n) y
borja at arch:~/lorcon $ cat Makefile 
#
#
#

INCLUDE_DIR = /usr/local/src/lorcon/
FLAGS = -ggdb

nodebug:
    gcc -I$(INCLUDE_DIR) -o uno.o -c uno.c 
    gcc -o uno uno.o -lorcon -lnl -lpcap

debug:
    gcc -I$(INCLUDE_DIR) -o uno.o -c uno.c -ggdb
    gcc -o uno uno.o -lorcon -lnl -lpcap

clean:
    rm uno.o uno
borja at arch:~/lorcon $ gdb ./uno
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/borja/lorcon/uno...done.
(gdb) break _dl_fini
Function "_dl_fini" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_dl_fini) pending.
(gdb) r
Starting program: /home/borja/lorcon/uno 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
argc: 1
Uso: /home/borja/lorcon/uno <opcion> 

Breakpoint 1, 0x00007ffff7de9d64 in _dl_fini () from /lib/ld-linux-x86-64.so.2
(gdb) step
Single stepping until exit from function _dl_fini,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77afb8d in genl_unregister () from /usr/lib/libnl.so.1
(gdb) bt
#0  0x00007ffff77afb8d in genl_unregister () from /usr/lib/libnl.so.1
#1  0x00007ffff7de9f3f in _dl_fini () from /lib/ld-linux-x86-64.so.2
#2  0x00007ffff71d17c1 in __run_exit_handlers () from /lib/libc.so.6
#3  0x00007ffff71d1845 in exit () from /lib/libc.so.6
#4  0x0000000000400d7e in main (argc=1, argv=0x7fffffffe8f8) at uno.c:40
(gdb) i r
rax            0x0  0
rbx            0x7ffff675a260   140737328292448
rcx            0x0  0
rdx            0x7ffff7535630   140737342821936
rsi            0xffffffff   4294967295
rdi            0x7ffff7535620   140737342821920
rbp            0x7fffffffe770   0x7fffffffe770
rsp            0x7fffffffe640   0x7fffffffe640
r8             0x1  1
r9             0x7ffff77b56f8   140737345443576
r10            0x7ffff77b56f7   140737345443575
r11            0x0  0
r12            0x7ffff6759d30   140737328291120
r13            0x7fffffffe690   140737488348816
r14            0x7fffffffe700   140737488348928
r15            0x1  1
rip            0x7ffff77afb8d   0x7ffff77afb8d <genl_unregister+13>
eflags         0x10293  [ CF AF SF IF RF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0
fs             0x0  0
gs             0x0  0
(gdb) break genl_unregister
Breakpoint 2 at 0x7ffff77afb80 (2 locations)
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/borja/lorcon/uno 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
argc: 1
Uso: /home/borja/lorcon/uno <opcion> 

Breakpoint 1, 0x00007ffff7de9d64 in _dl_fini () from /lib/ld-linux-x86-64.so.2
(gdb) n
Single stepping until exit from function _dl_fini,
which has no line number information.

Breakpoint 2, 0x00007ffff77afb80 in genl_unregister () from /usr/lib/libnl.so.1
(gdb) i r
rax            0x0  0
rbx            0x7ffff7fd2000   140737353949184
rcx            0x0  0
rdx            0x16 22
rsi            0x0  0
rdi            0x7ffff79ca460   140737347626080
rbp            0x7fffffffe770   0x7fffffffe770
rsp            0x7fffffffe648   0x7fffffffe648
r8             0x7fffffffe650   140737488348752
r9             0x7ffff7bd8600   140737349780992
r10            0x7fffffffe3f0   140737488348144
r11            0x7ffff77afb80   140737345420160
r12            0x7ffff79c6100   140737347608832
r13            0x7fffffffe670   140737488348784
r14            0x7fffffffe700   140737488348928
r15            0x16 22
rip            0x7ffff77afb80   0x7ffff77afb80 <genl_unregister>
eflags         0x206    [ PF IF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0
fs             0x0  0
gs             0x0  0
(gdb) x/x 0x00007ffff77afb8d
0x7ffff77afb8d <genl_unregister+13>:    0x28508b48
(gdb) x/s 0x00007ffff77afb8d
0x7ffff77afb8d <genl_unregister+13>:     "H\213P(H\213H0H\211J\bH\213 at 0H\211\020[\303fffff.\017\037\204"
(gdb) dissas 0x00007ffff77afb8d
Undefined command: "dissas".  Try "help".
(gdb) disass 0x00007ffff77afb8d
Dump of assembler code for function genl_unregister:
=> 0x00007ffff77afb80 <+0>: push   %rbx
   0x00007ffff77afb81 <+1>: mov    %rdi,%rbx
   0x00007ffff77afb84 <+4>: callq  0x7ffff778dbf0 <nl_cache_mngt_unregister at plt>
   0x00007ffff77afb89 <+9>: mov    0x40(%rbx),%rax
   0x00007ffff77afb8d <+13>:    mov    0x28(%rax),%rdx
   0x00007ffff77afb91 <+17>:    mov    0x30(%rax),%rcx
   0x00007ffff77afb95 <+21>:    mov    %rcx,0x8(%rdx)
   0x00007ffff77afb99 <+25>:    mov    0x30(%rax),%rax
   0x00007ffff77afb9d <+29>:    mov    %rdx,(%rax)
   0x00007ffff77afba0 <+32>:    pop    %rbx
   0x00007ffff77afba1 <+33>:    retq   
End of assembler dump.
(gdb) step
Single stepping until exit from function genl_unregister,
which has no line number information.
0x00007ffff77b3ca8 in _fini () from /usr/lib/libnl.so.1
(gdb) disass 0x00007ffff77afb8d
Dump of assembler code for function genl_unregister:
   0x00007ffff77afb80 <+0>: push   %rbx
   0x00007ffff77afb81 <+1>: mov    %rdi,%rbx
   0x00007ffff77afb84 <+4>: callq  0x7ffff778dbf0 <nl_cache_mngt_unregister at plt>
   0x00007ffff77afb89 <+9>: mov    0x40(%rbx),%rax
   0x00007ffff77afb8d <+13>:    mov    0x28(%rax),%rdx
   0x00007ffff77afb91 <+17>:    mov    0x30(%rax),%rcx
   0x00007ffff77afb95 <+21>:    mov    %rcx,0x8(%rdx)
   0x00007ffff77afb99 <+25>:    mov    0x30(%rax),%rax
   0x00007ffff77afb9d <+29>:    mov    %rdx,(%rax)
   0x00007ffff77afba0 <+32>:    pop    %rbx
   0x00007ffff77afba1 <+33>:    retq   
End of assembler dump.
(gdb) c
Continuing.

Breakpoint 2, 0x00007ffff77afb80 in genl_unregister () from /usr/lib/libnl.so.1
(gdb) disass 0x00007ffff77afb80
Dump of assembler code for function genl_unregister:
=> 0x00007ffff77afb80 <+0>: push   %rbx
   0x00007ffff77afb81 <+1>: mov    %rdi,%rbx
   0x00007ffff77afb84 <+4>: callq  0x7ffff778dbf0 <nl_cache_mngt_unregister at plt>
   0x00007ffff77afb89 <+9>: mov    0x40(%rbx),%rax
   0x00007ffff77afb8d <+13>:    mov    0x28(%rax),%rdx
   0x00007ffff77afb91 <+17>:    mov    0x30(%rax),%rcx
   0x00007ffff77afb95 <+21>:    mov    %rcx,0x8(%rdx)
   0x00007ffff77afb99 <+25>:    mov    0x30(%rax),%rax
   0x00007ffff77afb9d <+29>:    mov    %rdx,(%rax)
   0x00007ffff77afba0 <+32>:    pop    %rbx
   0x00007ffff77afba1 <+33>:    retq   
End of assembler dump.
(gdb) disass 0x00007ffff77afb8d
Dump of assembler code for function genl_unregister:
=> 0x00007ffff77afb80 <+0>: push   %rbx
   0x00007ffff77afb81 <+1>: mov    %rdi,%rbx
   0x00007ffff77afb84 <+4>: callq  0x7ffff778dbf0 <nl_cache_mngt_unregister at plt>
   0x00007ffff77afb89 <+9>: mov    0x40(%rbx),%rax
   0x00007ffff77afb8d <+13>:    mov    0x28(%rax),%rdx
   0x00007ffff77afb91 <+17>:    mov    0x30(%rax),%rcx
   0x00007ffff77afb95 <+21>:    mov    %rcx,0x8(%rdx)
   0x00007ffff77afb99 <+25>:    mov    0x30(%rax),%rax
   0x00007ffff77afb9d <+29>:    mov    %rdx,(%rax)
   0x00007ffff77afba0 <+32>:    pop    %rbx
   0x00007ffff77afba1 <+33>:    retq   
End of assembler dump.
(gdb) break 0x00007ffff77afb8d
Function "0x00007ffff77afb8d" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 3 (0x00007ffff77afb8d) pending.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77afb8d in genl_unregister () from /usr/lib/libnl.so.1
(gdb) i r
rax            0x0  0
rbx            0x7ffff675a260   140737328292448
rcx            0x0  0
rdx            0x7ffff7535630   140737342821936
rsi            0xffffffff   4294967295
rdi            0x7ffff7535620   140737342821920
rbp            0x7fffffffe770   0x7fffffffe770
rsp            0x7fffffffe640   0x7fffffffe640
r8             0x1  1
r9             0x7ffff77b56f8   140737345443576
r10            0x7ffff77b56f7   140737345443575
r11            0x0  0
r12            0x7ffff6759d30   140737328291120
r13            0x7fffffffe690   140737488348816
r14            0x7fffffffe700   140737488348928
r15            0x1  1
rip            0x7ffff77afb8d   0x7ffff77afb8d <genl_unregister+13>
eflags         0x10293  [ CF AF SF IF RF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0
fs             0x0  0
gs             0x0  0
(gdb) x/x 0x7ffff675a260+40
0x7ffff675a288: 0x00
(gdb) x/x $rax+28
0x1c:   Cannot access memory at address 0x1c
(gdb) q
A debugging session is active.

    Inferior 1 [process 25388] will be killed.

Quit anyway? (y or n) y


From tgraf at infradead.org  Sat Apr 21 11:18:04 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Sat, 21 Apr 2012 11:18:04 -0400
Subject: libnl segmentation fault
In-Reply-To: <CAONoiAGh4gobxyTC_MDoTzn+EVW9Dgxz6q5CH1_r6Cr2yBVXXA@mail.gmail.com>
References: <CAONoiAGh4gobxyTC_MDoTzn+EVW9Dgxz6q5CH1_r6Cr2yBVXXA@mail.gmail.com>
Message-ID: <20120421151804.GC27640@canuck.infradead.org>

On Sat, Apr 21, 2012 at 04:57:44PM +0200, Borja Ruiz-Castro wrote:
> Hi!
> 
> I think a just found a bug using lorcon + linbl (segmentation fault)
> 
> The problem is *genl_unregister():*
> 
> 
> (gdb) disass 0x00007ffff77afb8d
> Dump of assembler code for function genl_unregister:
> => 0x00007ffff77afb80 <+0>: push   %rbx
>    0x00007ffff77afb81 <+1>: mov    %rdi,%rbx
>    0x00007ffff77afb84 <+4>: callq  0x7ffff778dbf0
> <nl_cache_mngt_unregister at plt>
>    0x00007ffff77afb89 <+9>: mov    0x40(%rbx),%rax
> *   0x00007ffff77afb8d <+13>: mov    0x28(%rax),%rdx*
>    0x00007ffff77afb91 <+17>: mov    0x30(%rax),%rcx
>    0x00007ffff77afb95 <+21>: mov    %rcx,0x8(%rdx)
>    0x00007ffff77afb99 <+25>: mov    0x30(%rax),%rax
>    0x00007ffff77afb9d <+29>: mov    %rdx,(%rax)
>    0x00007ffff77afba0 <+32>: pop    %rbx
>    0x00007ffff77afba1 <+33>: retq
> End of assembler dump.
> 
> 
> A segmentation fault occurs when trying to copy %rdx into (%rax)+0x28,
> because the content's of %eax is 0x00!

Looks like NULL is passed to genl_unregister() which would be a
bug in the application.


From bruiz at alienvault.com  Sat Apr 21 12:04:01 2012
From: bruiz at alienvault.com (Borja Ruiz-Castro)
Date: Sat, 21 Apr 2012 18:04:01 +0200
Subject: libnl segmentation fault
In-Reply-To: <20120421151804.GC27640@canuck.infradead.org>
References: <CAONoiAGh4gobxyTC_MDoTzn+EVW9Dgxz6q5CH1_r6Cr2yBVXXA@mail.gmail.com>
 <20120421151804.GC27640@canuck.infradead.org>
Message-ID: <CAONoiAEvVRmTG=axCePBa6hSp28Jcu2u7BiVLV0p=Bnb-w6Stg@mail.gmail.com>

Hi!

Yep, you right! I'm looking at lorcon source code!

Cheers!

Borja.

On 21 April 2012 17:18, Thomas Graf <tgraf at infradead.org> wrote:

> On Sat, Apr 21, 2012 at 04:57:44PM +0200, Borja Ruiz-Castro wrote:
> > Hi!
> >
> > I think a just found a bug using lorcon + linbl (segmentation fault)
> >
> > The problem is *genl_unregister():*
> >
> >
> > (gdb) disass 0x00007ffff77afb8d
> > Dump of assembler code for function genl_unregister:
> > => 0x00007ffff77afb80 <+0>: push   %rbx
> >    0x00007ffff77afb81 <+1>: mov    %rdi,%rbx
> >    0x00007ffff77afb84 <+4>: callq  0x7ffff778dbf0
> > <nl_cache_mngt_unregister at plt>
> >    0x00007ffff77afb89 <+9>: mov    0x40(%rbx),%rax
> > *   0x00007ffff77afb8d <+13>: mov    0x28(%rax),%rdx*
> >    0x00007ffff77afb91 <+17>: mov    0x30(%rax),%rcx
> >    0x00007ffff77afb95 <+21>: mov    %rcx,0x8(%rdx)
> >    0x00007ffff77afb99 <+25>: mov    0x30(%rax),%rax
> >    0x00007ffff77afb9d <+29>: mov    %rdx,(%rax)
> >    0x00007ffff77afba0 <+32>: pop    %rbx
> >    0x00007ffff77afba1 <+33>: retq
> > End of assembler dump.
> >
> >
> > A segmentation fault occurs when trying to copy %rdx into (%rax)+0x28,
> > because the content's of %eax is 0x00!
>
> Looks like NULL is passed to genl_unregister() which would be a
> bug in the application.
>



-- 
Borja Ruiz-Castro
Senior Security Consultant
QA testing engineer



*AlienVault Europe* C/Cronos 63, Planta 2a, Oficina 6
CP: 28037 Madrid, Spain Tlf   +34 91 515-1344
Fax +34 91 413-5968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120421/39dceebe/attachment.html>

From tgraf at infradead.org  Sun Apr 22 05:13:53 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Sun, 22 Apr 2012 05:13:53 -0400
Subject: libnl segmentation fault
In-Reply-To: <CAONoiAEvVRmTG=axCePBa6hSp28Jcu2u7BiVLV0p=Bnb-w6Stg@mail.gmail.com>
References: <CAONoiAGh4gobxyTC_MDoTzn+EVW9Dgxz6q5CH1_r6Cr2yBVXXA@mail.gmail.com>
 <20120421151804.GC27640@canuck.infradead.org>
 <CAONoiAEvVRmTG=axCePBa6hSp28Jcu2u7BiVLV0p=Bnb-w6Stg@mail.gmail.com>
Message-ID: <20120422091353.GE27640@canuck.infradead.org>

On Sat, Apr 21, 2012 at 06:04:01PM +0200, Borja Ruiz-Castro wrote:
> Hi!
> 
> Yep, you right! I'm looking at lorcon source code!

I just pushed this patch to prevent such failures because other
similiar functions in the library behave the same way

commit 8bbcd2208e366f8d8a708d56974966dd7651ffdf
Author: Thomas Graf <tgraf at redhat.com>
Date:   Sun Apr 22 11:12:01 2012 +0200

    genl: Make genl_unregister() a NOP if NULL pointer is passed



From nicolas.carrier.ext at parrot.com  Mon Apr 23 09:57:00 2012
From: nicolas.carrier.ext at parrot.com (Nicolas CARRIER)
Date: Mon, 23 Apr 2012 15:57:00 +0200
Subject: [PATCH]Remove unneeded header inclusion
Message-ID: <4F955FAC.5090603@parrot.com>

By digging in the mailing list archive, I found that I erroneously posted a patch into a non-related discussion.
Hence I start a new thread to give it more visibility.
Please forgive me for the inconvenience,

Here comes the original message :

Hello,
When using libnl, one can't include both netlink/route/link.h and net/if.h because it leads to structure redefinitions :
    ...
    /usr/include/linux/if.h:137:8: error: redefinition of 'struct ifmap'
    /usr/include/net/if.h:112:8: note: originally defined here
    ...

The attached patch removes the unneeded linux/if.h inclusion from netlink/route/link.h and fixed the problem for me.
It should apply to the current master's HEAD.

Note that I'm no libnl specialist and hence not sure this is the right way to achieve it...

Regards

-- 
Nicolas CARRIER - Software Engineer - Parrot France
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-don-t-include-linux-if.h-which-conflicts-with-net-if.patch
Type: text/x-diff
Size: 661 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20120423/44a1c75f/attachment.bin>

From brett.ciphery at windriver.com  Mon Apr 23 10:42:58 2012
From: brett.ciphery at windriver.com (Brett Ciphery)
Date: Mon, 23 Apr 2012 10:42:58 -0400
Subject: bug in nl_cache_mngr_data_ready / nl_cache_refill /
 nl_cache_resync [+patch proposition]
In-Reply-To: <20120421105120.GA27640@canuck.infradead.org>
References: <20120411145544.GF11748@windriver.com>
 <20120412211618.GA5730@windriver.com>
 <20120419170910.GD503@canuck.infradead.org>
 <20120421105120.GA27640@canuck.infradead.org>
Message-ID: <20120423144258.GD5730@windriver.com>

[Re: bug in nl_cache_mngr_data_ready / nl_cache_refill / nl_cache_resync [+patch proposition]] On 21/04/2012 (Sat 06:51) Thomas Graf wrote:

> On Thu, Apr 19, 2012 at 01:09:10PM -0400, Thomas Graf wrote:
> > What we can do is extend recvmsgs() do offer both behaviours
> > and have the cache manager direct it to continue reading
> > as long as there is data.
> > 
> > I'll fix that. I'm planning to look into and improve the
> > cache manager anyway. It's not reliable enough at the moment.
> 
> See commit a518a31 (cache_mngr: Let nl_cache_mngr_data_ready()
> read multiple messages).
> 
> It should fix your case Brett while keeping the behaviour for
> blocking sockets the same.

Many thanks.

I was looking at comments of nl_recvmsgs() which
nl_cache_mngr_data_ready() calls:

 * Repeatedly calls nl_recv() or the respective replacement if provided
 * by the application (see nl_cb_overwrite_recv()) and parses the
 * received data as netlink messages. Stops reading if one of the
 * callbacks returns NL_STOP or nl_recv returns either 0 or a negative
 * error code.

and so thought the expected behaviour would be to loop until there was
nothing left.  Returning a count is clean though, I'll check how this
works with nl_cache_mngr_data_ready() and other cache refilling
functions.

Brett


From tgraf at infradead.org  Tue Apr 24 03:09:24 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Tue, 24 Apr 2012 03:09:24 -0400
Subject: bug in nl_cache_mngr_data_ready / nl_cache_refill /
 nl_cache_resync [+patch proposition]
In-Reply-To: <20120423144258.GD5730@windriver.com>
References: <20120411145544.GF11748@windriver.com>
 <20120412211618.GA5730@windriver.com>
 <20120419170910.GD503@canuck.infradead.org>
 <20120421105120.GA27640@canuck.infradead.org>
 <20120423144258.GD5730@windriver.com>
Message-ID: <20120424070924.GF27640@canuck.infradead.org>

On Mon, Apr 23, 2012 at 10:42:58AM -0400, Brett Ciphery wrote:
> I was looking at comments of nl_recvmsgs() which
> nl_cache_mngr_data_ready() calls:
> 
>  * Repeatedly calls nl_recv() or the respective replacement if provided
>  * by the application (see nl_cb_overwrite_recv()) and parses the
>  * received data as netlink messages. Stops reading if one of the
>  * callbacks returns NL_STOP or nl_recv returns either 0 or a negative
>  * error code.
> 
> and so thought the expected behaviour would be to loop until there was
> nothing left.  Returning a count is clean though, I'll check how this
> works with nl_cache_mngr_data_ready() and other cache refilling
> functions.

I will reword that comment, it's misleading. Thanks Brett.


From tgraf at infradead.org  Tue Apr 24 05:51:38 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Tue, 24 Apr 2012 05:51:38 -0400
Subject: [PATCH]Remove unneeded header inclusion
In-Reply-To: <4F955FAC.5090603@parrot.com>
References: <4F955FAC.5090603@parrot.com>
Message-ID: <20120424095138.GG27640@canuck.infradead.org>

On Mon, Apr 23, 2012 at 03:57:00PM +0200, Nicolas CARRIER wrote:
> By digging in the mailing list archive, I found that I erroneously posted a patch into a non-related discussion.
> Hence I start a new thread to give it more visibility.
> Please forgive me for the inconvenience,
> 
> Here comes the original message :
> 
> Hello,
> When using libnl, one can't include both netlink/route/link.h and net/if.h because it leads to structure redefinitions :
>    ...
>    /usr/include/linux/if.h:137:8: error: redefinition of 'struct ifmap'
>    /usr/include/net/if.h:112:8: note: originally defined here
>    ...
> 
> The attached patch removes the unneeded linux/if.h inclusion from netlink/route/link.h and fixed the problem for me.
> It should apply to the current master's HEAD.
> 
> Note that I'm no libnl specialist and hence not sure this is the right way to achieve it...

This is an known problem. The problem is that <net/if.h> does not
provide all the flag definitions that <linux/if.h> provides.

Seeing all the trouble it causes, it would be wise to remove the
include and make the application responsible for including the
approporiate header file.

The problem with doing so is that it might break existing code which
relies on that include.


From jobhunts02 at aol.com  Wed Apr 25 02:57:37 2012
From: jobhunts02 at aol.com (jobhunts02 at aol.com)
Date: Wed, 25 Apr 2012 02:57:37 -0400 (EDT)
Subject: No subject
Message-ID: <8CEF0C7D577AE96-4F8-2A0EC@webmail-d146.sysops.aol.com>

http://gentileimages.com/wp-content/themes/ag/job14.html


From tgraf at infradead.org  Thu Apr 26 05:35:57 2012
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 26 Apr 2012 05:35:57 -0400
Subject: libnl 3.2.8
Message-ID: <20120426093557.GK27640@canuck.infradead.org>

Hello everyone

I'm pleased to announce the release of libnl 3.2.8. It contains
various fixes and several new API additions.

Thanks to everyone who contributed to this release.

Brett Ciphery (1):
      add new function to provide neighbour event parsing

Nicolas CARRIER (1):
      Memory leak in classid.c

Romary Sonrier (1):
      missing extended Table attribute for lib/route/

Shriram Rajagopalan (1):
      Support plug qdisc - queue traffic until explicit release

Thierry Reding (1):
      Add new nl_cache_clone() function.

Thomas Graf (25):
      doc: Fix typos in autoconf example
      doc: Fix incorrect nl_socket_add_memberships() example
      genl-ctrl-list: Introduce -d|--details as a shortcut for --format=details
      genl-ctrl-list: Provide manual page
      genl-ctrl-list: fix copyright and summary
      genl-ctrl-list: Mark for installation
      cache_mngr: document uncommon error codes
      tests: Convert tests/Makefile to use automake
      tests: fix test programs to compile again
      cache_mngr: Don't modify callback setup of socket
      cache_manager: Move documentation to doc/core.txt
      cache_mngr: Automatically allocate socket if needed
      test-cache-mngr: Let the cache manager allocate the socket
      cache_mngr: Fix memory corruption after resizing
      nl: Make nl_recvmsgs() return the number of netlink messages processed
      cache_mngr: Let nl_cache_mngr_data_ready() read multiple messages
      cache_mngr: API doc updates
      cache_mngr: Provide nl_cache_mngr_info() to pring cache manager details
      test-cache-mngr: Allow for management of arbitary caches via argument string
      cache_mngr: Make providing the result pointer to nl_cache_mngr_add() optional
      genl: Make genl_unregister() a NOP if NULL pointer is passed
      cache: improve documentation of co_event_filter
      cache: Add co_include_event allowing caches to provide their own nl_cache_include() implementation
      object: Add functions to access the object type, cache and object ops
      3.2.8 release

The source tarball can be found at the usual location:
http://www.infradead.org/~tgr/libnl/


Thomas


