From feckert at tdt.de  Tue Mar 12 12:41:46 2013
From: feckert at tdt.de (Eckert Florian)
Date: Tue, 12 Mar 2013 17:41:46 +0100
Subject: kernel version
Message-ID: <1DE55DF1B1AC954693C4C2F51C7597CFE8EB56339E@MS.tdt.local>

Hello

I have some problems compiling wpa_supplicant-2.0 with the libnl-3.x against the Kernel 2.6.32.45. I always get some linker errors "undefined reference to..."

I think it has to do with the Kernel API version

What is the min kernel version release to build the libnl-3.x

Mit freundlichen Gr??en,
Kind regards

Florian Eckert
Entwicklung
Development

TDT GmbH             Tel.      +49 (0) 8703 929 00
Siemensstr. 18       Fax       +49 (0) 8703 929 201
84051 Essenbach      E-Mail    feckert at tdt.de
Germany              Internet  www.tdt.de

--------------------------------------------------------------------------
Die gesetzlichen Pflichtangaben finden Sie unter http://www.tdt.de/imprint
--------------------------------------------------------------------------



From tony.cheneau at amnesiak.org  Sat Mar 16 00:23:17 2013
From: tony.cheneau at amnesiak.org (Tony Cheneau)
Date: Sat, 16 Mar 2013 00:23:17 -0400
Subject: [PATCH 0/2] Very small code cleanup
Message-ID: <1363407799-20938-1-git-send-email-tony.cheneau@amnesiak.org>

While reading some header files, I found some code that was duplicated or
useless. These two patches aim to fix that.

Regards

Tony Cheneau (2):
  1/2] Remove rtnl_link_free() declaration from the header file.
  2/2] Remove superfluous declaration of rtnl_route_put()

 include/netlink/route/link.h  | 1 -
 include/netlink/route/route.h | 1 -
 2 files changed, 2 deletions(-)

-- 
1.7.12.4



From tony.cheneau at amnesiak.org  Sat Mar 16 00:23:18 2013
From: tony.cheneau at amnesiak.org (Tony Cheneau)
Date: Sat, 16 Mar 2013 00:23:18 -0400
Subject: [PATCH 1/2] 1/2] Remove rtnl_link_free() declaration from the header
 file.
In-Reply-To: <1363407799-20938-1-git-send-email-tony.cheneau@amnesiak.org>
References: <1363407799-20938-1-git-send-email-tony.cheneau@amnesiak.org>
Message-ID: <1363407799-20938-2-git-send-email-tony.cheneau@amnesiak.org>

Reason: there is no rtnl_link_free() definition anywhere in the code.

Signed-off-by: Tony Cheneau <tony.cheneau at amnesiak.org>
---
 include/netlink/route/link.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/netlink/route/link.h b/include/netlink/route/link.h
index dbde72f..321a80d 100644
--- a/include/netlink/route/link.h
+++ b/include/netlink/route/link.h
@@ -99,7 +99,6 @@ typedef enum {
 
 extern struct rtnl_link *rtnl_link_alloc(void);
 extern void	rtnl_link_put(struct rtnl_link *);
-extern void	rtnl_link_free(struct rtnl_link *);
 
 extern int	rtnl_link_alloc_cache(struct nl_sock *, int, struct nl_cache **);
 extern struct rtnl_link *rtnl_link_get(struct nl_cache *, int);
-- 
1.7.12.4



From tony.cheneau at amnesiak.org  Sat Mar 16 00:23:19 2013
From: tony.cheneau at amnesiak.org (Tony Cheneau)
Date: Sat, 16 Mar 2013 00:23:19 -0400
Subject: [PATCH 2/2] 2/2] Remove superfluous declaration of rtnl_route_put()
In-Reply-To: <1363407799-20938-1-git-send-email-tony.cheneau@amnesiak.org>
References: <1363407799-20938-1-git-send-email-tony.cheneau@amnesiak.org>
Message-ID: <1363407799-20938-3-git-send-email-tony.cheneau@amnesiak.org>

rtnl_route_put() is declared twice in the same header file

Signed-off-by: Tony Cheneau <tony.cheneau at amnesiak.org>
---
 include/netlink/route/route.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/netlink/route/route.h b/include/netlink/route/route.h
index d3543af..477250d 100644
--- a/include/netlink/route/route.h
+++ b/include/netlink/route/route.h
@@ -54,7 +54,6 @@ extern int	rtnl_route_alloc_cache(struct nl_sock *, int, int,
 				       struct nl_cache **);
 
 extern void	rtnl_route_get(struct rtnl_route *);
-extern void	rtnl_route_put(struct rtnl_route *);
 
 extern int	rtnl_route_parse(struct nlmsghdr *, struct rtnl_route **);
 extern int	rtnl_route_build_msg(struct nl_msg *, struct rtnl_route *);
-- 
1.7.12.4



From tgraf at suug.ch  Sun Mar 17 12:32:17 2013
From: tgraf at suug.ch (Thomas Graf)
Date: Sun, 17 Mar 2013 16:32:17 +0000
Subject: [PATCH 0/2] Very small code cleanup
In-Reply-To: <1363407799-20938-1-git-send-email-tony.cheneau@amnesiak.org>
References: <1363407799-20938-1-git-send-email-tony.cheneau@amnesiak.org>
Message-ID: <20130317163217.GA10210@casper.infradead.org>

On 03/16/13 at 12:23am, Tony Cheneau wrote:
> While reading some header files, I found some code that was duplicated or
> useless. These two patches aim to fix that.
> 
> Regards
> 
> Tony Cheneau (2):
>   1/2] Remove rtnl_link_free() declaration from the header file.
>   2/2] Remove superfluous declaration of rtnl_route_put()

Applied, thanks Tony!


From tony.cheneau at amnesiak.org  Mon Mar 18 13:32:00 2013
From: tony.cheneau at amnesiak.org (Tony Cheneau)
Date: Mon, 18 Mar 2013 18:32:00 +0100
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
Message-ID: <8c89d67f19660ebc473452992f24752a@amnesiak.org>

Hello,

I just ran a git-bisect and can new affirm that the issue has been 
introduced with commit a2207c7beb80050671d209650aaaeba429658e49 (just 
before version 3.2.15). I joined a patch, that disable the issue for 
now, but I don't believe it should be applied to the tree, as it does 
not fix the real problem. Unfortunately, I don't have time or in-depth 
knowledge of the code to actually fix the issue properly.

Please note that I was only interested in the "route" submodule, so it 
is the only one I tested. It could also affect some other submodules 
(given previous commits seem to affect similar portions of the code in 
those others submodules).

I'd be interested to know if I'm the only one having this issue.

Regards,
Tony

P.-S.: I cc'ed Roopa, because both of us had a private email exchange 
about this topic.

Le 2013-02-05 23:43, Tony Cheneau a ?crit?:
> Hello,
>
> For my own purposes, I'm building a bunch of python wrappers around
> libraries exposed by CLI tools (that is the functions exposed in the
> netlink/cli directory). To be more precise, I'm using cython to glue
> the libnl C code within a python wrapper. While performing my tests, 
> I
> found out a odd behavior when playing with default routes: I could 
> not
> always remove them. To me, it qualifies as a bug, but it might be an
> intended behavior. This issue is also present with the 
> nl-route-delete
> binary, so I'll use this tool for my bug report. Finally, I must add
> that I'm using the current git tree tip.
>
> So, first step is to add multiple default routes (lines starting with
> # are indicates the command I inputted):
> # ./nl-route-add  -d default -n via=10.0.0.3,dev=eth0
> Added inet default via 10.0.0.3 dev eth0
> # ./nl-route-add  -d default -n via=10.0.0.2,dev=eth0
> Added inet default via 10.0.0.2 dev eth0
> # ./nl-route-add  -d default -n via=10.0.0.1,dev=eth0
> Added inet default via 10.0.0.1 dev eth0
>
> Then I try listing current routes:
> # ./nl-route-list|grep default
> inet default table main type unicast via 10.0.20.200 dev eth0
> inet6 default table unspec type unreachable via dev lo
>
> I find it weird enough that the route does not show up. Only the
> initial route to my default gateway shows up (it was set before I run
> any of the previous commands).
> However, if I try adding a route again, I obtain the following
> message (that would indicate that the previous commands went 
> through):
> # ./nl-route-add  -d default -n via=10.0.0.1,dev=eth0
> Error: Unable to add route: Object exists
>
> Now, this is the part that motivates me to write this bug report, if
> I try to remove the default routes using symmetrical command
> "nl-route-delete", I obtain the following:
> # ./nl-route-delete  -d default -n via=10.0.0.3,dev=eth0
> Deleted 0 routes
> # ./nl-route-delete  -d default -n via=10.0.0.2,dev=eth0
> Deleted 0 routes
> # ./nl-route-delete  -d default -n via=10.0.0.1,dev=eth0
> Deleted 0 routes
>
> However, if I remove the next-hop selector, it works (I omitted the
> part when I removed my default gateway, because I lost connection on
> this one and could not retrieve the output):
> # ./nl-route-delete -d default
> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
> Deleted 1 routes
> # ./nl-route-delete -d default
> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
> Deleted 1 routes
> # ./nl-route-delete -d default
> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
> Deleted 1 routes
>
> It also works if I reverse the ordering when removing routes (when no
> default gateway is set):
> # ./nl-route-add  -d default -n via=10.0.0.3,dev=eth0
> Added inet default via 10.0.0.3 dev eth0
> # ./nl-route-add  -d default -n via=10.0.0.2,dev=eth0
> Added inet default via 10.0.0.2 dev eth0
> # ./nl-route-add  -d default -n via=10.0.0.1,dev=eth0
> Added inet default via 10.0.0.1 dev eth0
> # ./nl-route-delete  -d default -n via=10.0.0.1,dev=eth0
> Deleted 0 routes
> # ./nl-route-delete  -d default -n via=10.0.0.3
> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
> Deleted 1 routes
> # ./nl-route-delete  -d default -n via=10.0.0.2
> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
> Deleted 1 routes
> # ./nl-route-delete  -d default -n via=10.0.0.1
> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
> Deleted 1 routes
>
> The same phenomena seems to occur when using IPv6 addresses.
>
> (As a side note, I wanted to add that I'm aware of the various python
> bindings existing for libnl, but, to the best of my knowledge, none 
> of
> them seems to control the netlink "route" sub-system that I need.)
>
> Regards,
> Tony Cheneau
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Disable-hash-support-in-the-route-cache.patch
Type: text/x-diff
Size: 750 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130318/8ba38ce2/attachment.bin>

From roopa at cumulusnetworks.com  Mon Mar 18 18:00:57 2013
From: roopa at cumulusnetworks.com (Roopa Prabhu)
Date: Mon, 18 Mar 2013 15:00:57 -0700
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <8c89d67f19660ebc473452992f24752a@amnesiak.org>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
 <8c89d67f19660ebc473452992f24752a@amnesiak.org>
Message-ID: <51478E99.5010902@cumulusnetworks.com>

Thanks tony for the commit id.

I will try to reproduce your problem today.

On 3/18/13 10:32 AM, Tony Cheneau wrote:
> Hello,
>
> I just ran a git-bisect and can new affirm that the issue has been
> introduced with commit a2207c7beb80050671d209650aaaeba429658e49 (just
> before version 3.2.15). I joined a patch, that disable the issue for
> now, but I don't believe it should be applied to the tree, as it does
> not fix the real problem. Unfortunately, I don't have time or in-depth
> knowledge of the code to actually fix the issue properly.
>
> Please note that I was only interested in the "route" submodule, so it
> is the only one I tested. It could also affect some other submodules
> (given previous commits seem to affect similar portions of the code in
> those others submodules).
>
> I'd be interested to know if I'm the only one having this issue.
>
> Regards,
> Tony
>
> P.-S.: I cc'ed Roopa, because both of us had a private email exchange
> about this topic.
>
> Le 2013-02-05 23:43, Tony Cheneau a ?crit :
>> Hello,
>>
>> For my own purposes, I'm building a bunch of python wrappers around
>> libraries exposed by CLI tools (that is the functions exposed in the
>> netlink/cli directory). To be more precise, I'm using cython to glue
>> the libnl C code within a python wrapper. While performing my tests, I
>> found out a odd behavior when playing with default routes: I could not
>> always remove them. To me, it qualifies as a bug, but it might be an
>> intended behavior. This issue is also present with the nl-route-delete
>> binary, so I'll use this tool for my bug report. Finally, I must add
>> that I'm using the current git tree tip.
>>
>> So, first step is to add multiple default routes (lines starting with
>> # are indicates the command I inputted):
>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>> Added inet default via 10.0.0.3 dev eth0
>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>> Added inet default via 10.0.0.2 dev eth0
>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>> Added inet default via 10.0.0.1 dev eth0
>>
>> Then I try listing current routes:
>> # ./nl-route-list|grep default
>> inet default table main type unicast via 10.0.20.200 dev eth0
>> inet6 default table unspec type unreachable via dev lo
>>
>> I find it weird enough that the route does not show up. Only the
>> initial route to my default gateway shows up (it was set before I run
>> any of the previous commands).
>> However, if I try adding a route again, I obtain the following
>> message (that would indicate that the previous commands went through):
>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>> Error: Unable to add route: Object exists
>>
>> Now, this is the part that motivates me to write this bug report, if
>> I try to remove the default routes using symmetrical command
>> "nl-route-delete", I obtain the following:
>> # ./nl-route-delete -d default -n via=10.0.0.3,dev=eth0
>> Deleted 0 routes
>> # ./nl-route-delete -d default -n via=10.0.0.2,dev=eth0
>> Deleted 0 routes
>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>> Deleted 0 routes
>>
>> However, if I remove the next-hop selector, it works (I omitted the
>> part when I removed my default gateway, because I lost connection on
>> this one and could not retrieve the output):
>> # ./nl-route-delete -d default
>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>> Deleted 1 routes
>> # ./nl-route-delete -d default
>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>> Deleted 1 routes
>> # ./nl-route-delete -d default
>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>> Deleted 1 routes
>>
>> It also works if I reverse the ordering when removing routes (when no
>> default gateway is set):
>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>> Added inet default via 10.0.0.3 dev eth0
>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>> Added inet default via 10.0.0.2 dev eth0
>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>> Added inet default via 10.0.0.1 dev eth0
>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>> Deleted 0 routes
>> # ./nl-route-delete -d default -n via=10.0.0.3
>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>> Deleted 1 routes
>> # ./nl-route-delete -d default -n via=10.0.0.2
>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>> Deleted 1 routes
>> # ./nl-route-delete -d default -n via=10.0.0.1
>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>> Deleted 1 routes
>>
>> The same phenomena seems to occur when using IPv6 addresses.
>>
>> (As a side note, I wanted to add that I'm aware of the various python
>> bindings existing for libnl, but, to the best of my knowledge, none of
>> them seems to control the netlink "route" sub-system that I need.)
>>
>> Regards,
>> Tony Cheneau
>>
>> _______________________________________________
>> libnl mailing list
>> libnl at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/libnl



From roopa at cumulusnetworks.com  Tue Mar 19 07:38:29 2013
From: roopa at cumulusnetworks.com (Roopa Prabhu)
Date: Tue, 19 Mar 2013 04:38:29 -0700
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <51478E99.5010902@cumulusnetworks.com>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
 <8c89d67f19660ebc473452992f24752a@amnesiak.org>
 <51478E99.5010902@cumulusnetworks.com>
Message-ID: <51484E35.2030902@cumulusnetworks.com>

Hi Tony,

Looks like The default routes that you are trying to add end up having 
the same key attributes (ROUTE_ATTR_FAMILY | ROUTE_ATTR_TOS |
                                    ROUTE_ATTR_TABLE | ROUTE_ATTR_DST |
                                    ROUTE_ATTR_PRIO).
And they are hashing to the same route. Your old default route ends up 
replacing the ones you added.

One thing that comes to my mind is, we could store the new routes in the 
same bucket instead of knocking off the old routes. But I want to be 
sure that route replace by the kernel also works in this case. Still 
looking at it.

Have you been able to add these routes successfully using 'ip route' ? 
(I had some problems).
What command line are you using ?.


Thanks,
Roopa




On 3/18/13 3:00 PM, Roopa Prabhu wrote:
> Thanks tony for the commit id.
>
> I will try to reproduce your problem today.
>
> On 3/18/13 10:32 AM, Tony Cheneau wrote:
>> Hello,
>>
>> I just ran a git-bisect and can new affirm that the issue has been
>> introduced with commit a2207c7beb80050671d209650aaaeba429658e49 (just
>> before version 3.2.15). I joined a patch, that disable the issue for
>> now, but I don't believe it should be applied to the tree, as it does
>> not fix the real problem. Unfortunately, I don't have time or in-depth
>> knowledge of the code to actually fix the issue properly.
>>
>> Please note that I was only interested in the "route" submodule, so it
>> is the only one I tested. It could also affect some other submodules
>> (given previous commits seem to affect similar portions of the code in
>> those others submodules).
>>
>> I'd be interested to know if I'm the only one having this issue.
>>
>> Regards,
>> Tony
>>
>> P.-S.: I cc'ed Roopa, because both of us had a private email exchange
>> about this topic.
>>
>> Le 2013-02-05 23:43, Tony Cheneau a ?crit :
>>> Hello,
>>>
>>> For my own purposes, I'm building a bunch of python wrappers around
>>> libraries exposed by CLI tools (that is the functions exposed in the
>>> netlink/cli directory). To be more precise, I'm using cython to glue
>>> the libnl C code within a python wrapper. While performing my tests, I
>>> found out a odd behavior when playing with default routes: I could not
>>> always remove them. To me, it qualifies as a bug, but it might be an
>>> intended behavior. This issue is also present with the nl-route-delete
>>> binary, so I'll use this tool for my bug report. Finally, I must add
>>> that I'm using the current git tree tip.
>>>
>>> So, first step is to add multiple default routes (lines starting with
>>> # are indicates the command I inputted):
>>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>>> Added inet default via 10.0.0.3 dev eth0
>>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>>> Added inet default via 10.0.0.2 dev eth0
>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>> Added inet default via 10.0.0.1 dev eth0
>>>
>>> Then I try listing current routes:
>>> # ./nl-route-list|grep default
>>> inet default table main type unicast via 10.0.20.200 dev eth0
>>> inet6 default table unspec type unreachable via dev lo
>>>
>>> I find it weird enough that the route does not show up. Only the
>>> initial route to my default gateway shows up (it was set before I run
>>> any of the previous commands).
>>> However, if I try adding a route again, I obtain the following
>>> message (that would indicate that the previous commands went through):
>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>> Error: Unable to add route: Object exists
>>>
>>> Now, this is the part that motivates me to write this bug report, if
>>> I try to remove the default routes using symmetrical command
>>> "nl-route-delete", I obtain the following:
>>> # ./nl-route-delete -d default -n via=10.0.0.3,dev=eth0
>>> Deleted 0 routes
>>> # ./nl-route-delete -d default -n via=10.0.0.2,dev=eth0
>>> Deleted 0 routes
>>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>>> Deleted 0 routes
>>>
>>> However, if I remove the next-hop selector, it works (I omitted the
>>> part when I removed my default gateway, because I lost connection on
>>> this one and could not retrieve the output):
>>> # ./nl-route-delete -d default
>>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>>> Deleted 1 routes
>>> # ./nl-route-delete -d default
>>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>>> Deleted 1 routes
>>> # ./nl-route-delete -d default
>>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>>> Deleted 1 routes
>>>
>>> It also works if I reverse the ordering when removing routes (when no
>>> default gateway is set):
>>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>>> Added inet default via 10.0.0.3 dev eth0
>>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>>> Added inet default via 10.0.0.2 dev eth0
>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>> Added inet default via 10.0.0.1 dev eth0
>>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>>> Deleted 0 routes
>>> # ./nl-route-delete -d default -n via=10.0.0.3
>>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>>> Deleted 1 routes
>>> # ./nl-route-delete -d default -n via=10.0.0.2
>>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>>> Deleted 1 routes
>>> # ./nl-route-delete -d default -n via=10.0.0.1
>>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>>> Deleted 1 routes
>>>
>>> The same phenomena seems to occur when using IPv6 addresses.
>>>
>>> (As a side note, I wanted to add that I'm aware of the various python
>>> bindings existing for libnl, but, to the best of my knowledge, none of
>>> them seems to control the netlink "route" sub-system that I need.)
>>>
>>> Regards,
>>> Tony Cheneau
>>>
>>> _______________________________________________
>>> libnl mailing list
>>> libnl at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/libnl
>



From roopa at cumulusnetworks.com  Tue Mar 19 10:20:01 2013
From: roopa at cumulusnetworks.com (Roopa Prabhu)
Date: Tue, 19 Mar 2013 07:20:01 -0700
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <51484E35.2030902@cumulusnetworks.com>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
 <8c89d67f19660ebc473452992f24752a@amnesiak.org>
 <51478E99.5010902@cumulusnetworks.com> <51484E35.2030902@cumulusnetworks.com>
Message-ID: <51487411.6070001@cumulusnetworks.com>

On 3/19/13 4:38 AM, Roopa Prabhu wrote:
> Hi Tony,
>
> Looks like The default routes that you are trying to add end up having
> the same key attributes (ROUTE_ATTR_FAMILY | ROUTE_ATTR_TOS |
> ROUTE_ATTR_TABLE | ROUTE_ATTR_DST |
> ROUTE_ATTR_PRIO).
> And they are hashing to the same route. Your old default route ends up
> replacing the ones you added.
>
> One thing that comes to my mind is, we could store the new routes in the
> same bucket instead of knocking off the old routes. But I want to be
> sure that route replace by the kernel also works in this case. Still
> looking at it.
>
> Have you been able to add these routes successfully using 'ip route' ?
> (I had some problems).

This works with 'ip route append'. unlike nl-route-add, 'ip route add' 
adds the NLM_F_EXCL flag.

> What command line are you using ?.
>
>
> Thanks,
> Roopa
>
>
>
>
> On 3/18/13 3:00 PM, Roopa Prabhu wrote:
>> Thanks tony for the commit id.
>>
>> I will try to reproduce your problem today.
>>
>> On 3/18/13 10:32 AM, Tony Cheneau wrote:
>>> Hello,
>>>
>>> I just ran a git-bisect and can new affirm that the issue has been
>>> introduced with commit a2207c7beb80050671d209650aaaeba429658e49 (just
>>> before version 3.2.15). I joined a patch, that disable the issue for
>>> now, but I don't believe it should be applied to the tree, as it does
>>> not fix the real problem. Unfortunately, I don't have time or in-depth
>>> knowledge of the code to actually fix the issue properly.
>>>
>>> Please note that I was only interested in the "route" submodule, so it
>>> is the only one I tested. It could also affect some other submodules
>>> (given previous commits seem to affect similar portions of the code in
>>> those others submodules).
>>>
>>> I'd be interested to know if I'm the only one having this issue.
>>>
>>> Regards,
>>> Tony
>>>
>>> P.-S.: I cc'ed Roopa, because both of us had a private email exchange
>>> about this topic.
>>>
>>> Le 2013-02-05 23:43, Tony Cheneau a ?crit :
>>>> Hello,
>>>>
>>>> For my own purposes, I'm building a bunch of python wrappers around
>>>> libraries exposed by CLI tools (that is the functions exposed in the
>>>> netlink/cli directory). To be more precise, I'm using cython to glue
>>>> the libnl C code within a python wrapper. While performing my tests, I
>>>> found out a odd behavior when playing with default routes: I could not
>>>> always remove them. To me, it qualifies as a bug, but it might be an
>>>> intended behavior. This issue is also present with the nl-route-delete
>>>> binary, so I'll use this tool for my bug report. Finally, I must add
>>>> that I'm using the current git tree tip.
>>>>
>>>> So, first step is to add multiple default routes (lines starting with
>>>> # are indicates the command I inputted):
>>>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>>>> Added inet default via 10.0.0.3 dev eth0
>>>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>>>> Added inet default via 10.0.0.2 dev eth0
>>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>>> Added inet default via 10.0.0.1 dev eth0
>>>>
>>>> Then I try listing current routes:
>>>> # ./nl-route-list|grep default
>>>> inet default table main type unicast via 10.0.20.200 dev eth0
>>>> inet6 default table unspec type unreachable via dev lo
>>>>
>>>> I find it weird enough that the route does not show up. Only the
>>>> initial route to my default gateway shows up (it was set before I run
>>>> any of the previous commands).
>>>> However, if I try adding a route again, I obtain the following
>>>> message (that would indicate that the previous commands went through):
>>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>>> Error: Unable to add route: Object exists
>>>>
>>>> Now, this is the part that motivates me to write this bug report, if
>>>> I try to remove the default routes using symmetrical command
>>>> "nl-route-delete", I obtain the following:
>>>> # ./nl-route-delete -d default -n via=10.0.0.3,dev=eth0
>>>> Deleted 0 routes
>>>> # ./nl-route-delete -d default -n via=10.0.0.2,dev=eth0
>>>> Deleted 0 routes
>>>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>>>> Deleted 0 routes
>>>>
>>>> However, if I remove the next-hop selector, it works (I omitted the
>>>> part when I removed my default gateway, because I lost connection on
>>>> this one and could not retrieve the output):
>>>> # ./nl-route-delete -d default
>>>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>>>> Deleted 1 routes
>>>> # ./nl-route-delete -d default
>>>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>>>> Deleted 1 routes
>>>> # ./nl-route-delete -d default
>>>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>>>> Deleted 1 routes
>>>>
>>>> It also works if I reverse the ordering when removing routes (when no
>>>> default gateway is set):
>>>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>>>> Added inet default via 10.0.0.3 dev eth0
>>>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>>>> Added inet default via 10.0.0.2 dev eth0
>>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>>> Added inet default via 10.0.0.1 dev eth0
>>>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>>>> Deleted 0 routes
>>>> # ./nl-route-delete -d default -n via=10.0.0.3
>>>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>>>> Deleted 1 routes
>>>> # ./nl-route-delete -d default -n via=10.0.0.2
>>>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>>>> Deleted 1 routes
>>>> # ./nl-route-delete -d default -n via=10.0.0.1
>>>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>>>> Deleted 1 routes
>>>>
>>>> The same phenomena seems to occur when using IPv6 addresses.
>>>>
>>>> (As a side note, I wanted to add that I'm aware of the various python
>>>> bindings existing for libnl, but, to the best of my knowledge, none of
>>>> them seems to control the netlink "route" sub-system that I need.)
>>>>
>>>> Regards,
>>>> Tony Cheneau
>>>>
>>>> _______________________________________________
>>>> libnl mailing list
>>>> libnl at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/libnl
>>
>
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl



From tgraf at suug.ch  Tue Mar 19 13:27:03 2013
From: tgraf at suug.ch (Thomas Graf)
Date: Tue, 19 Mar 2013 17:27:03 +0000
Subject: libnl 1.1.3 released
Message-ID: <20130319172703.GC29613@casper.infradead.org>

I am pleased to announce the availability of libnl 1.1.3

Please note that libnl 1.1.x only receives essential bug fixes
at this point and should not be used for development of new
applications.

Source:
http://www.infradead.org/~tgr/libnl/files/libnl-1.1.3.tar.gz

Thanks to everyone who contributed to this release:

Thomas Graf (3):
      attr: No longer warn about attribute of type 0
      cache-api: Avoid offset modification of nl_cache_ops
      1.1.3 release


From roopa at cumulusnetworks.com  Tue Mar 19 16:37:21 2013
From: roopa at cumulusnetworks.com (Roopa Prabhu)
Date: Tue, 19 Mar 2013 13:37:21 -0700
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <51487411.6070001@cumulusnetworks.com>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
 <8c89d67f19660ebc473452992f24752a@amnesiak.org>
 <51478E99.5010902@cumulusnetworks.com> <51484E35.2030902@cumulusnetworks.com>
 <51487411.6070001@cumulusnetworks.com>
Message-ID: <5148CC81.6000700@cumulusnetworks.com>

Problem:
tony's testcase uses nl-route-add. nl-route-add does not use any 
exclusive flags, so kernel will append the route (I can reproduce the 
problem with similar routes added via 'ip route append').

And for such routes with 'no NLM_F_EXCL' or 'having NLM_F_APPEND', 
kernel also checks for next hop match. However, libnl does not check for 
next hop during lookup. Resulting in updating (add/remove) existing object.

solution:
Fix libnl to include additional attributes in the hash key depending on 
'message type + msg flags'.
ie In this case, use next hop info during lookup when ('msgtype == 
RTM_NEWROUTE  && (msgflag == NLM_F_CREATE || 'msgflag & NLM_F_APPEND' || 
'and more if needed'))

I can submit a libnl patch for this. However, the problem is, in this 
particular case (looking at the latest kernel), kernel does not send the 
required msgflags in the RTM_NEWROUTE notification msg.
I will submit a kernel patch to fix this in the future.

This will be available in the next kernel release.

So, for the current problem, a few things to note here,

- Its unclear why this would work before the hash implementation went 
in, because even the linear search algorithm used before searched for 
similar attributes (ROUTE_ATTR_FAMILY | ROUTE_ATTR_TOS |
                                    ROUTE_ATTR_TABLE | ROUTE_ATTR_DST).
I am able to reproduce it even without the hash implementation.


- If there is any problem with the hash implementation, i am willing to 
submit a patch to make the hash implementation optional. Settable via an 
api until I fix the real issue. However, for now it does not seem like 
that is the case. unless somebody confirms

- In this particular test case, multiple default ipv4 routes via the 
same interface, results in kernel picking up the first one. Unclear 
where this is really useful. So does not seem like a critical bug.

- We should probably add NLM_F_EXCL flag in nl-route-add.


Thanks,
Roopa


On 3/19/13 7:20 AM, Roopa Prabhu wrote:
> On 3/19/13 4:38 AM, Roopa Prabhu wrote:
>> Hi Tony,
>>
>> Looks like The default routes that you are trying to add end up having
>> the same key attributes (ROUTE_ATTR_FAMILY | ROUTE_ATTR_TOS |
>> ROUTE_ATTR_TABLE | ROUTE_ATTR_DST |
>> ROUTE_ATTR_PRIO).
>> And they are hashing to the same route. Your old default route ends up
>> replacing the ones you added.
>>
>> One thing that comes to my mind is, we could store the new routes in the
>> same bucket instead of knocking off the old routes. But I want to be
>> sure that route replace by the kernel also works in this case. Still
>> looking at it.
>>
>> Have you been able to add these routes successfully using 'ip route' ?
>> (I had some problems).
>
> This works with 'ip route append'. unlike nl-route-add, 'ip route add'
> adds the NLM_F_EXCL flag.
>
>> What command line are you using ?.
>>
>>
>> Thanks,
>> Roopa
>>
>>
>>
>>
>> On 3/18/13 3:00 PM, Roopa Prabhu wrote:
>>> Thanks tony for the commit id.
>>>
>>> I will try to reproduce your problem today.
>>>
>>> On 3/18/13 10:32 AM, Tony Cheneau wrote:
>>>> Hello,
>>>>
>>>> I just ran a git-bisect and can new affirm that the issue has been
>>>> introduced with commit a2207c7beb80050671d209650aaaeba429658e49 (just
>>>> before version 3.2.15). I joined a patch, that disable the issue for
>>>> now, but I don't believe it should be applied to the tree, as it does
>>>> not fix the real problem. Unfortunately, I don't have time or in-depth
>>>> knowledge of the code to actually fix the issue properly.
>>>>
>>>> Please note that I was only interested in the "route" submodule, so it
>>>> is the only one I tested. It could also affect some other submodules
>>>> (given previous commits seem to affect similar portions of the code in
>>>> those others submodules).
>>>>
>>>> I'd be interested to know if I'm the only one having this issue.
>>>>
>>>> Regards,
>>>> Tony
>>>>
>>>> P.-S.: I cc'ed Roopa, because both of us had a private email exchange
>>>> about this topic.
>>>>
>>>> Le 2013-02-05 23:43, Tony Cheneau a ?crit :
>>>>> Hello,
>>>>>
>>>>> For my own purposes, I'm building a bunch of python wrappers around
>>>>> libraries exposed by CLI tools (that is the functions exposed in the
>>>>> netlink/cli directory). To be more precise, I'm using cython to glue
>>>>> the libnl C code within a python wrapper. While performing my tests, I
>>>>> found out a odd behavior when playing with default routes: I could not
>>>>> always remove them. To me, it qualifies as a bug, but it might be an
>>>>> intended behavior. This issue is also present with the nl-route-delete
>>>>> binary, so I'll use this tool for my bug report. Finally, I must add
>>>>> that I'm using the current git tree tip.
>>>>>
>>>>> So, first step is to add multiple default routes (lines starting with
>>>>> # are indicates the command I inputted):
>>>>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>>>>> Added inet default via 10.0.0.3 dev eth0
>>>>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>>>>> Added inet default via 10.0.0.2 dev eth0
>>>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>>>> Added inet default via 10.0.0.1 dev eth0
>>>>>
>>>>> Then I try listing current routes:
>>>>> # ./nl-route-list|grep default
>>>>> inet default table main type unicast via 10.0.20.200 dev eth0
>>>>> inet6 default table unspec type unreachable via dev lo
>>>>>
>>>>> I find it weird enough that the route does not show up. Only the
>>>>> initial route to my default gateway shows up (it was set before I run
>>>>> any of the previous commands).
>>>>> However, if I try adding a route again, I obtain the following
>>>>> message (that would indicate that the previous commands went through):
>>>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>>>> Error: Unable to add route: Object exists
>>>>>
>>>>> Now, this is the part that motivates me to write this bug report, if
>>>>> I try to remove the default routes using symmetrical command
>>>>> "nl-route-delete", I obtain the following:
>>>>> # ./nl-route-delete -d default -n via=10.0.0.3,dev=eth0
>>>>> Deleted 0 routes
>>>>> # ./nl-route-delete -d default -n via=10.0.0.2,dev=eth0
>>>>> Deleted 0 routes
>>>>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>>>>> Deleted 0 routes
>>>>>
>>>>> However, if I remove the next-hop selector, it works (I omitted the
>>>>> part when I removed my default gateway, because I lost connection on
>>>>> this one and could not retrieve the output):
>>>>> # ./nl-route-delete -d default
>>>>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>>>>> Deleted 1 routes
>>>>> # ./nl-route-delete -d default
>>>>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>>>>> Deleted 1 routes
>>>>> # ./nl-route-delete -d default
>>>>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>>>>> Deleted 1 routes
>>>>>
>>>>> It also works if I reverse the ordering when removing routes (when no
>>>>> default gateway is set):
>>>>> # ./nl-route-add -d default -n via=10.0.0.3,dev=eth0
>>>>> Added inet default via 10.0.0.3 dev eth0
>>>>> # ./nl-route-add -d default -n via=10.0.0.2,dev=eth0
>>>>> Added inet default via 10.0.0.2 dev eth0
>>>>> # ./nl-route-add -d default -n via=10.0.0.1,dev=eth0
>>>>> Added inet default via 10.0.0.1 dev eth0
>>>>> # ./nl-route-delete -d default -n via=10.0.0.1,dev=eth0
>>>>> Deleted 0 routes
>>>>> # ./nl-route-delete -d default -n via=10.0.0.3
>>>>> Deleted inet default table main type unicast via 10.0.0.3 dev eth0
>>>>> Deleted 1 routes
>>>>> # ./nl-route-delete -d default -n via=10.0.0.2
>>>>> Deleted inet default table main type unicast via 10.0.0.2 dev eth0
>>>>> Deleted 1 routes
>>>>> # ./nl-route-delete -d default -n via=10.0.0.1
>>>>> Deleted inet default table main type unicast via 10.0.0.1 dev eth0
>>>>> Deleted 1 routes
>>>>>
>>>>> The same phenomena seems to occur when using IPv6 addresses.
>>>>>
>>>>> (As a side note, I wanted to add that I'm aware of the various python
>>>>> bindings existing for libnl, but, to the best of my knowledge, none of
>>>>> them seems to control the netlink "route" sub-system that I need.)
>>>>>
>>>>> Regards,
>>>>> Tony Cheneau
>>>>>
>>>>> _______________________________________________
>>>>> libnl mailing list
>>>>> libnl at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/libnl
>>>
>>
>>
>> _______________________________________________
>> libnl mailing list
>> libnl at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/libnl
>
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl



From tgraf at suug.ch  Thu Mar 21 14:04:54 2013
From: tgraf at suug.ch (Thomas Graf)
Date: Thu, 21 Mar 2013 18:04:54 +0000
Subject: kernel version
In-Reply-To: <1DE55DF1B1AC954693C4C2F51C7597CFE8EB56339E@MS.tdt.local>
References: <1DE55DF1B1AC954693C4C2F51C7597CFE8EB56339E@MS.tdt.local>
Message-ID: <20130321180454.GJ9046@casper.infradead.org>

On 03/12/13 at 05:41pm, Eckert Florian wrote:
> Hello
> 
> I have some problems compiling wpa_supplicant-2.0 with the libnl-3.x against the Kernel 2.6.32.45. I always get some linker errors "undefined reference to..."
> 
> I think it has to do with the Kernel API version
> 
> What is the min kernel version release to build the libnl-3.x

It should work with any 2.6.x kernel in fact.

Undefined reference would indicate that wpa_supplicant is using
unvailable symbols.

Can you post the actual errors?


From tgraf at suug.ch  Thu Mar 21 14:09:22 2013
From: tgraf at suug.ch (Thomas Graf)
Date: Thu, 21 Mar 2013 18:09:22 +0000
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <5148CC81.6000700@cumulusnetworks.com>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
 <8c89d67f19660ebc473452992f24752a@amnesiak.org>
 <51478E99.5010902@cumulusnetworks.com>
 <51484E35.2030902@cumulusnetworks.com>
 <51487411.6070001@cumulusnetworks.com>
 <5148CC81.6000700@cumulusnetworks.com>
Message-ID: <20130321180922.GK9046@casper.infradead.org>

On 03/19/13 at 01:37pm, Roopa Prabhu wrote:
> Fix libnl to include additional attributes in the hash key depending
> on 'message type + msg flags'.
> ie In this case, use next hop info during lookup when ('msgtype ==
> RTM_NEWROUTE  && (msgflag == NLM_F_CREATE || 'msgflag &
> NLM_F_APPEND' || 'and more if needed'))

Why do we want to only regard the nexthop info if the append flag
is set? What's wrong with always comparing nexthops?

In fact, this looks like a kernel bug. The kernel should not
use different semantics in judging uniqueness based on netlink
flags.

> So, for the current problem, a few things to note here,
> 
> - Its unclear why this would work before the hash implementation
> went in, because even the linear search algorithm used before
> searched for similar attributes (ROUTE_ATTR_FAMILY | ROUTE_ATTR_TOS
> |
>                                    ROUTE_ATTR_TABLE | ROUTE_ATTR_DST).
> I am able to reproduce it even without the hash implementation.

Right, I think this is unrelated to the hash implementation.

> - If there is any problem with the hash implementation, i am willing
> to submit a patch to make the hash implementation optional. Settable
> via an api until I fix the real issue. However, for now it does not
> seem like that is the case. unless somebody confirms

Agreed.

> - We should probably add NLM_F_EXCL flag in nl-route-add.

Right, feel free to submit a patch.


From roopa at cumulusnetworks.com  Fri Mar 22 20:21:01 2013
From: roopa at cumulusnetworks.com (Roopa Prabhu)
Date: Fri, 22 Mar 2013 17:21:01 -0700
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <20130321180922.GK9046@casper.infradead.org>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
 <8c89d67f19660ebc473452992f24752a@amnesiak.org>
 <51478E99.5010902@cumulusnetworks.com> <51484E35.2030902@cumulusnetworks.com>
 <51487411.6070001@cumulusnetworks.com> <5148CC81.6000700@cumulusnetworks.com>
 <20130321180922.GK9046@casper.infradead.org>
Message-ID: <514CF56D.6080007@cumulusnetworks.com>

On 3/21/13 11:09 AM, Thomas Graf wrote:
> On 03/19/13 at 01:37pm, Roopa Prabhu wrote:
>> Fix libnl to include additional attributes in the hash key depending
>> on 'message type + msg flags'.
>> ie In this case, use next hop info during lookup when ('msgtype ==
>> RTM_NEWROUTE&&  (msgflag == NLM_F_CREATE || 'msgflag&
>> NLM_F_APPEND' || 'and more if needed'))
>
> Why do we want to only regard the nexthop info if the append flag
> is set? What's wrong with always comparing nexthops?

I pointed out nexthop because in tony's problem, only nexthop attribute 
was different between the two routes. It could have been any other 
attribute like scope, type etc.

I think our current key attributes are correct. Kernel also seems to use 
the same during lookup. However, I was trying to say that after lookup 
we should probably use more attributes to compare the objects than 
simply nl_object identical. We could use nl_object_diff or a variant 
depending on whether kernel appended, replaced or created a fresh route. 
At this point i am afraid adding more attributes in the lookup might 
break something else.
I will think about this some more and also look at the kernel code again.

>
> In fact, this looks like a kernel bug. The kernel should not
> use different semantics in judging uniqueness based on netlink
> flags.
>
>> So, for the current problem, a few things to note here,
>>
>> - Its unclear why this would work before the hash implementation
>> went in, because even the linear search algorithm used before
>> searched for similar attributes (ROUTE_ATTR_FAMILY | ROUTE_ATTR_TOS
>> |
>>                                     ROUTE_ATTR_TABLE | ROUTE_ATTR_DST).
>> I am able to reproduce it even without the hash implementation.
>
> Right, I think this is unrelated to the hash implementation.
>
>> - If there is any problem with the hash implementation, i am willing
>> to submit a patch to make the hash implementation optional. Settable
>> via an api until I fix the real issue. However, for now it does not
>> seem like that is the case. unless somebody confirms
>
> Agreed.
>
>> - We should probably add NLM_F_EXCL flag in nl-route-add.
>
> Right, feel free to submit a patch.

I will submit a patch.

Thanks.



From tgraf at suug.ch  Sat Mar 23 03:03:59 2013
From: tgraf at suug.ch (Thomas Graf)
Date: Sat, 23 Mar 2013 07:03:59 +0000
Subject: [Bug report] Unable to remove 'default' routes using the CLI tools
In-Reply-To: <514CF56D.6080007@cumulusnetworks.com>
References: <fb84962ca41fc795640c58035e490a9d@amnesiak.org>
 <8c89d67f19660ebc473452992f24752a@amnesiak.org>
 <51478E99.5010902@cumulusnetworks.com>
 <51484E35.2030902@cumulusnetworks.com>
 <51487411.6070001@cumulusnetworks.com>
 <5148CC81.6000700@cumulusnetworks.com>
 <20130321180922.GK9046@casper.infradead.org>
 <514CF56D.6080007@cumulusnetworks.com>
Message-ID: <20130323070359.GN9046@casper.infradead.org>

On 03/22/13 at 05:21pm, Roopa Prabhu wrote:
> On 3/21/13 11:09 AM, Thomas Graf wrote:
> >On 03/19/13 at 01:37pm, Roopa Prabhu wrote:
> >>Fix libnl to include additional attributes in the hash key depending
> >>on 'message type + msg flags'.
> >>ie In this case, use next hop info during lookup when ('msgtype ==
> >>RTM_NEWROUTE&&  (msgflag == NLM_F_CREATE || 'msgflag&
> >>NLM_F_APPEND' || 'and more if needed'))
> >
> >Why do we want to only regard the nexthop info if the append flag
> >is set? What's wrong with always comparing nexthops?
> 
> I pointed out nexthop because in tony's problem, only nexthop
> attribute was different between the two routes. It could have been
> any other attribute like scope, type etc.
> 
> I think our current key attributes are correct. Kernel also seems to
> use the same during lookup. However, I was trying to say that after
> lookup we should probably use more attributes to compare the objects
> than simply nl_object identical. We could use nl_object_diff or a
> variant depending on whether kernel appended, replaced or created a
> fresh route. At this point i am afraid adding more attributes in the
> lookup might break something else.
> I will think about this some more and also look at the kernel code again.

OK, I now understand what you have been saying before. Let's look
into how we can improve the kernel situation and be more verbose
on what action was taken.


From roopa at cumulusnetworks.com  Sat Mar 23 20:42:59 2013
From: roopa at cumulusnetworks.com (roopa at cumulusnetworks.com)
Date: Sat, 23 Mar 2013 17:42:59 -0700
Subject: [PATCH] nl-route-add: Add NLM_F_EXCL flag to route add
Message-ID: <1364085779-23746-1-git-send-email-roopa@cumulusnetworks.com>

From: roopa <roopa at cumulusnetworks.com>

Signed-off-by: Roopa Prabhu <roopa at cumulusnetworks.com>
---
 src/nl-route-add.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/nl-route-add.c b/src/nl-route-add.c
index 2f187df..d4aa767 100644
--- a/src/nl-route-add.c
+++ b/src/nl-route-add.c
@@ -120,7 +120,7 @@ int main(int argc, char *argv[])
 		}
 	}
 
-	if ((err = rtnl_route_add(sock, route, 0)) < 0)
+	if ((err = rtnl_route_add(sock, route, NLM_F_EXCL)) < 0)
 		nl_cli_fatal(err, "Unable to add route: %s", nl_geterror(err));
 
 	if (!quiet) {
-- 
1.7.2.5



From tgraf at suug.ch  Sun Mar 24 05:58:41 2013
From: tgraf at suug.ch (Thomas Graf)
Date: Sun, 24 Mar 2013 09:58:41 +0000
Subject: [PATCH] nl-route-add: Add NLM_F_EXCL flag to route add
In-Reply-To: <1364085779-23746-1-git-send-email-roopa@cumulusnetworks.com>
References: <1364085779-23746-1-git-send-email-roopa@cumulusnetworks.com>
Message-ID: <20130324095841.GA27194@casper.infradead.org>

On 03/23/13 at 05:42pm, roopa at cumulusnetworks.com wrote:
> From: roopa <roopa at cumulusnetworks.com>
> 
> Signed-off-by: Roopa Prabhu <roopa at cumulusnetworks.com>

Applied, thanks Roopa.


From holger at eitzenberger.org  Sun Mar 24 17:26:21 2013
From: holger at eitzenberger.org (Holger Eitzenberger)
Date: Sun, 24 Mar 2013 22:26:21 +0100
Subject: [PATCH] ct: add ICMPv6 support
Message-ID: <20130324212621.GO13505@imap.eitzenberger.org>

Hi Thomas,

currently the ICMPv6 conntrack objects in libnl are without type, code
and ID.  This e. g. is the output of nl_object_dump():

  ct: ipv6-icmp ::1 <-> ::1 
      id 0xdd0871f0 family inet6 timeout 30s <NOREPLY,SNAT_INIT,DNAT_INIT>

The attached patch tries to solve that.  It is the 'small' approach,
because it reuses the existing ICMP attributes of the conntrack
object, which are currently only used for IPv4.  This way I can avoid
to add new _icmp6_get_, _icmp6_set_ and _icmp6_test_ functions.

Regards,

 /Holger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ct-ICMPv6-support.diff
Type: text/x-diff
Size: 2203 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130324/69e60691/attachment.bin>

From mattator at gmail.com  Wed Mar 27 15:14:18 2013
From: mattator at gmail.com (Teto)
Date: Wed, 27 Mar 2013 20:14:18 +0100
Subject: How to send a message from a userspace application to a module
Message-ID: <CADHp1Nymi2RsTpP1ZSJ9o58JwbgPrxbnunC-=9i8OPiqsV+foA@mail.gmail.com>

Hi there,

I am quite new to kernel development and netlink. I am trying to get a
linux module communicate with an userspace daemon. It is hard to find
up to date documentation or tutorials so I came up (with difficulty)
with the following code but I am not sure if this is the recommanded
way (I've seen people using netlink_kernel_create but I don't use it
for instnace).  The problem is that my module should print a message
on dmesg via printk when it receives a netlink packet but nothing
happens.


A lot of code follows but it shouldn't be too hard to read for netlink
specialists such as yourselves since it's mainly copy/paste of
examples on the Internet, that is very classical without any personal
logic.


================================================
==== USER SPACE CODE: lig_daemon.c ===
================================================
#include <netlink/netlink.h>
#include <netlink/genl/genl.h>
#include <netlink/genl/ctrl.h>
#include <netlink/genl/mngt.h>
#include <stdlib.h>
#include <stdio.h>
#include"../lig_module/lig_module.h"


static int parse_cb(struct nl_msg *msg, void *arg)
{
    printf("callbacl called\n");
//	return genl_handle_msg(msg, NULL);
}



int main()
{
    struct nl_sock *sk = 0;
    int ret = 0;
    int family_id = 0;
//    struct sk_buff *skb = 0;
    void *msg_head;

    struct nl_msg *msg;
     struct s_lig_result *user_hdr;


    printf("Starting LIG DAEMON\n");

    sk = nl_socket_alloc();

    if(!sk) {
        printf("could not allocate socket\n");
        return EXIT_FAILURE;
    }


    if(nl_connect(sk, NETLINK_GENERIC) != 0)
    {
        printf("could not connect socket\n");
        goto fail_connect;

    }


    /** 2nd parameter refers to family name defined in gnl_family.name */
    family_id = genl_ctrl_resolve (sk, LIG_FAMILY_NAME);
    if(family_id < 0 )
    {
        printf("error obtaining family\n");
        goto failure;
    }

    printf("Family No:\t%d\n", family_id);


    if (!(msg = nlmsg_alloc()))
    {
        printf("Could not allocate a new message");
        goto failure;
    }


    user_hdr = genlmsg_put(msg,
                           NL_AUTO_PORT,        /* port	Netlink port
or NL_AUTO_PORT */
                           NL_AUTO_SEQ,     /* Sequence number of
message or NL_AUTO_SEQ*/
                           family_id,       /* Numeric family identifier*/
    0,

                           0,               /* flags (optional ) */
                           ELC_RESULTS,      /* command identifier */
                           VERSION_NR       /* version */
                           );


    if (!user_hdr)
    {
        printf("Could not generate a new message");
        goto failure;

    }

    ret = nla_put_string(msg, ELA_EID, "stuff");
    if(ret != 0)
    {
        printf("Could not add string");
        goto skb_failure;
    }

    // else we fill the struct
//    user_hdr->number_of_remote_rlocs = 2;
//    user_hdr->number_of_local_rlocs = 1;




     /* finalize the message */

     ret =nl_send_auto 	( sk, msg);

    /* send message (skb, pid) */
    if(ret < 0)
    {
        printf("Could not send message");
        goto skb_failure;
    }


    nl_socket_modify_cb( sk, NL_CB_VALID, NL_CB_CUSTOM, parse_cb, NULL);


//returns -10 => NLE_OPNOTSUPP
    ret = nl_recvmsgs_default( sk );
    printf("After receive %i.\n", ret);
    if( ret < 0)
    {
        printf("Error: %s\n", nl_geterror(ret) );
    }




    // free allocated struct
    nlmsg_free(msg);
    nl_socket_free(sk);


    printf("End of  DAEMON\n");
    return EXIT_SUCCESS;



skb_failure:
    nlmsg_free(msg);

failure:
fail_connect:
    nl_socket_free(sk);


    return EXIT_FAILURE;
}



================================================
==== KERNEL MODULE CODE: lig_module.h, just a bunch of definitions ===
================================================
#ifndef LIG_MODULE_H
#define LIG_MODULE_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 E_LIG_ATTRIBUTE {
	ELA_RLOCS_NUMBER,
	ELA_EID,
	ELA_MAX

};


/* protocol version */
#define VERSION_NR 1

/*the name of this family, used by userspace application */
#define LIG_FAMILY_NAME "LIG_FAMILY"

/* commands: enumeration of all commands (functions),
 * used by userspace application to identify command to be ececuted
 */
enum E_LIG_COMMAND {
	ELC_REQUEST_RLOCS_FOR_EID,
	ELC_RESULTS,
	ELC_MAX,
};

struct s_lig_result {
    int number_of_remote_rlocs;
    int number_of_local_rlocs;
};

struct s_lig_request {
    int remote_eid;
    int local_eid;
//    int number_of_local_rlocs;
};


#endif

================================================
==== KERNEL MODULE CODE: lig_module.c, just a bunch of definitions ===
================================================


#include <linux/genetlink.h>
#include <net/genetlink.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include "lig_module.h"


#define MAX_STRING     16
#define MAX_TAB        16


//static int entier;
static char destinationIP[MAX_STRING];

//! Path towards the lig program
static char programPath[100];

// sock
//static struct sock *nl_sk = NULL;

module_param_string(destinationIP, destinationIP, sizeof(destinationIP), 0644);
module_param_string(programPath, programPath, sizeof(programPath), 0644);

MODULE_PARM_DESC(destinationIP, "EID we want to retrieve the RLOC number for");
MODULE_PARM_DESC(programPath, "Path towards the userspace lig program
this module calls ?");



MODULE_DESCRIPTION("lig_module");
MODULE_LICENSE("GPL");



/* attribute policy: defines which attribute has which type (e.g int,
char * etc)
 * possible values defined in net/netlink.h
 */
static struct nla_policy lig_policy[ ELA_MAX ] = {
	[ELA_RLOCS_NUMBER] = { .type = NLA_UNSPEC, .len = 120 },
	[ELA_EID] = { .type = NLA_UNSPEC , .len = 120}
};


/* family definition */
static struct genl_family lig_gnl_family = {
	.id = GENL_ID_GENERATE,         /* genetlink should generate an id */
	.hdrsize = 0,
	.name = LIG_FAMILY_NAME,        /*the name of this family, used by
userspace application */
	.version = VERSION_NR,                   //version number
	.maxattr = ELA_MAX,
};



/* an echo command, receives a message, prints it and sends another
message back */
int handle_results(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;

    printk("call to %s in reaction to %d \n",__func__, info->snd_pid );

    /*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[ELA_RLOCS_NUMBER];
   	if (na)
   	{
		mydata = (char *)nla_data(na);

		if (mydata == NULL)
			printk("error while receiving data\n");
		else
			printk(KERN_NOTICE "received: %s\n", mydata);
	}
	else
    {
        printk("no info->attrs %i\n", ELA_RLOCS_NUMBER);
    }


    /* 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?)
        */
    /*
     * Payload Format:
 *    <---------------------- nlmsg_len(nlh) --------------------->
 *    <------ hdrlen ------>       <- nlmsg_attrlen(nlh, hdrlen) ->
 *   +----------------------+- - -+--------------------------------+
 *   |     Family Header    | Pad |           Attributes           |
 *   +----------------------+- - -+--------------------------------+
 */

	msg_head = genlmsg_put(skb, 0, info->snd_seq+1, &lig_gnl_family, 0,
ELC_REQUEST_RLOCS_FOR_EID);

	if (msg_head == NULL) {
		rc = -ENOMEM;
		goto out;
	}
	/* add a DOC_EXMPL_A_MSG attribute (actual value to be sent) */
	rc = nla_put_string(skb, ELA_EID, "hello world from kernel space\n");
	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 %s:\n",__func__);

      return 0;
}




/*
commands: mapping between the command enumeration and the actual function

*/
struct genl_ops lig_ops[ELC_MAX] = {

    {
        .cmd = ELC_REQUEST_RLOCS_FOR_EID,
        .flags = 0,
        .policy = lig_policy,
        .doit = handle_results,	/* cb function */
        .dumpit = NULL,				/* cb function */
	} ,
	{
        .cmd = ELC_RESULTS,
        .flags = 0,
        .policy = lig_policy,
        .doit = handle_results,	/* cb function */
        .dumpit = NULL,				/* cb function */
	}
};




static int __init init_lig_module(void)
{
	int rc;
    printk("LIG MODULE initialization\n");

    /*register new family*/
	rc = genl_register_family(&lig_gnl_family);
	if (rc != 0){
		genl_unregister_family(&lig_gnl_family);
		rc = genl_register_family(&lig_gnl_family);
		if (rc != 0)
			goto failure;
	}


    /*register functions (commands) of the new family*/
	rc = genl_register_ops(&lig_gnl_family, lig_ops);
	if (rc != 0){
        printk(KERN_WARNING "could not register ops: %i\n",rc);
        genl_unregister_family(&lig_gnl_family);
		goto failure;
    }



	return 0;



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

}

static void __exit cleanup_lig_module(void)
{

	int ret = 0;
 	
 	printk(KERN_INFO "cleanup_lig_module() called\n");

 	/* do not forget to unregister family
	returns 0 on success
	unregister operations as well
 	*/
	ret = genl_unregister_family(&lig_gnl_family);
 	if( ret != 0)
 	{
 		printk(KERN_WARNING "Could not unregister family, error: %d\n", ret);
 	}

}


module_init( init_lig_module );
module_exit( cleanup_lig_module );



=====================================================
====   the debug output of the userspace application "lig_daemon" ====
=====================================================
teto at tatooine:~/lig_daemon$ NLCB=debug lig_daemon
Starting LIG DAEMON
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 20
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 773 <REQUEST,ACK,ROOT,MATCH>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    03 01 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 116
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 7 octets
    6e 6c 63 74 72 6c 00                                  nlctrl.
  [PADDING] 1 octets
    00                                                    .
  [ATTR 01] 2 octets
    10 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    02 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    07 00 00 00                                           ....
  [ATTR 06] 20 octets
    14 00 01 00 08 00 01 00 03 00 00 00 08 00 02 00 0e 00 ..................
    00 00                                                 ..
  [ATTR 07] 24 octets
    18 00 01 00 08 00 02 00 10 00 00 00 0b 00 01 00 6e 6f ................no
    74 69 66 79 00 00                                     tify..
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 232
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 10 octets
    4e 4c 42 4c 5f 4d 47 4d 54 00                         NLBL_MGMT.
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 01] 2 octets
    11 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    03 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    0a 00 00 00                                           ....
  [ATTR 06] 160 octets
    14 00 01 00 08 00 01 00 01 00 00 00 08 00 02 00 0b 00 ..................
    00 00 14 00 02 00 08 00 01 00 02 00 00 00 08 00 02 00 ..................
    0b 00 00 00 14 00 03 00 08 00 01 00 03 00 00 00 08 00 ..................
    02 00 0c 00 00 00 14 00 04 00 08 00 01 00 04 00 00 00 ..................
    08 00 02 00 0b 00 00 00 14 00 05 00 08 00 01 00 05 00 ..................
    00 00 08 00 02 00 0b 00 00 00 14 00 06 00 08 00 01 00 ..................
    06 00 00 00 08 00 02 00 0a 00 00 00 14 00 07 00 08 00 ..................
    01 00 07 00 00 00 08 00 02 00 0c 00 00 00 14 00 08 00 ..................
    08 00 01 00 08 00 00 00 08 00 02 00 0a 00 00 00       ................
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 156
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 13 octets
    4e 4c 42 4c 5f 43 49 50 53 4f 76 34 00                NLBL_CIPSOv4.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 01] 2 octets
    12 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    03 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    0c 00 00 00                                           ....
  [ATTR 06] 80 octets
    14 00 01 00 08 00 01 00 01 00 00 00 08 00 02 00 0b 00 ..................
    00 00 14 00 02 00 08 00 01 00 02 00 00 00 08 00 02 00 ..................
    0b 00 00 00 14 00 03 00 08 00 01 00 03 00 00 00 08 00 ..................
    02 00 0a 00 00 00 14 00 04 00 08 00 01 00 04 00 00 00 ..................
    08 00 02 00 0c 00 00 00                               ........
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 232
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 11 octets
    4e 4c 42 4c 5f 55 4e 4c 42 4c 00                      NLBL_UNLBL.
  [PADDING] 1 octets
    00                                                    .
  [ATTR 01] 2 octets
    13 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    03 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    07 00 00 00                                           ....
  [ATTR 06] 160 octets
    14 00 01 00 08 00 01 00 03 00 00 00 08 00 02 00 0b 00 ..................
    00 00 14 00 02 00 08 00 01 00 04 00 00 00 08 00 02 00 ..................
    0b 00 00 00 14 00 03 00 08 00 01 00 05 00 00 00 08 00 ..................
    02 00 0c 00 00 00 14 00 04 00 08 00 01 00 06 00 00 00 ..................
    08 00 02 00 0b 00 00 00 14 00 05 00 08 00 01 00 07 00 ..................
    00 00 08 00 02 00 0b 00 00 00 14 00 06 00 08 00 01 00 ..................
    08 00 00 00 08 00 02 00 0c 00 00 00 14 00 07 00 08 00 ..................
    01 00 01 00 00 00 08 00 02 00 0b 00 00 00 14 00 08 00 ..................
    08 00 01 00 02 00 00 00 08 00 02 00 0a 00 00 00       ................
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 104
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 11 octets
    61 63 70 69 5f 65 76 65 6e 74 00                      acpi_event.
  [PADDING] 1 octets
    00                                                    .
  [ATTR 01] 2 octets
    14 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    01 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    01 00 00 00                                           ....
  [ATTR 07] 32 octets
    20 00 01 00 08 00 02 00 01 00 00 00 12 00 01 00 61 63  ...............ac
    70 69 5f 6d 63 5f 67 72 6f 75 70 00 00 00             pi_mc_group...
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 112
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 14 octets
    74 68 65 72 6d 61 6c 5f 65 76 65 6e 74 00             thermal_event.
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 01] 2 octets
    15 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    01 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    01 00 00 00                                           ....
  [ATTR 07] 36 octets
    24 00 01 00 08 00 02 00 02 00 00 00 16 00 01 00 74 68 $...............th
    65 72 6d 61 6c 5f 6d 63 5f 67 72 6f 75 70 02 00 00 00 ermal_mc_group....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 68
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 10 octets
    56 46 53 5f 44 51 55 4f 54 00                         VFS_DQUOT.
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 01] 2 octets
    16 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    01 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    06 00 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 112
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 10 octets
    54 41 53 4b 53 54 41 54 53 00                         TASKSTATS.
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 01] 2 octets
    17 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    01 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    04 00 00 00                                           ....
  [ATTR 06] 40 octets
    14 00 01 00 08 00 01 00 01 00 00 00 08 00 02 00 0b 00 ..................
    00 00 14 00 02 00 08 00 01 00 04 00 00 00 08 00 02 00 ..................
    0a 00 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 1540
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 8 octets
    6e 6c 38 30 32 31 31 00                               nl80211.
  [ATTR 01] 2 octets
    18 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    01 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    98 00 00 00                                           ....
  [ATTR 06] 1340 octets
    14 00 01 00 08 00 01 00 01 00 00 00 08 00 02 00 0e 00 ..................
    00 00 14 00 02 00 08 00 01 00 02 00 00 00 08 00 02 00 ..................
    0b 00 00 00 14 00 03 00 08 00 01 00 05 00 00 00 08 00 ..................
    02 00 0e 00 00 00 14 00 04 00 08 00 01 00 06 00 00 00 ..................
    08 00 02 00 0b 00 00 00 14 00 05 00 08 00 01 00 07 00 ..................
    00 00 08 00 02 00 0b 00 00 00 14 00 06 00 08 00 01 00 ..................
    08 00 00 00 08 00 02 00 0b 00 00 00 14 00 07 00 08 00 ..................
    01 00 09 00 00 00 08 00 02 00 0b 00 00 00 14 00 08 00 ..................
    08 00 01 00 0a 00 00 00 08 00 02 00 0b 00 00 00 14 00 ..................
    09 00 08 00 01 00 0b 00 00 00 08 00 02 00 0b 00 00 00 ..................
    14 00 0a 00 08 00 01 00 0c 00 00 00 08 00 02 00 0b 00 ..................
    00 00 14 00 0b 00 08 00 01 00 0e 00 00 00 08 00 02 00 ..................
    0b 00 00 00 14 00 0c 00 08 00 01 00 0f 00 00 00 08 00 ..................
    02 00 0b 00 00 00 14 00 0d 00 08 00 01 00 10 00 00 00 ..................
    08 00 02 00 0b 00 00 00 14 00 0e 00 08 00 01 00 11 00 ..................
    00 00 08 00 02 00 0e 00 00 00 14 00 0f 00 08 00 01 00 ..................
    12 00 00 00 08 00 02 00 0b 00 00 00 14 00 10 00 08 00 ..................
    01 00 13 00 00 00 08 00 02 00 0b 00 00 00 14 00 11 00 ..................
    08 00 01 00 14 00 00 00 08 00 02 00 0b 00 00 00 14 00 ..................
    12 00 08 00 01 00 15 00 00 00 08 00 02 00 0f 00 00 00 ..................
    14 00 13 00 08 00 01 00 16 00 00 00 08 00 02 00 0b 00 ..................
    00 00 14 00 14 00 08 00 01 00 17 00 00 00 08 00 02 00 ..................
    0b 00 00 00 14 00 15 00 08 00 01 00 18 00 00 00 08 00 ..................
    02 00 0b 00 00 00 14 00 16 00 08 00 01 00 19 00 00 00 ..................
    08 00 02 00 0b 00 00 00 14 00 17 00 08 00 01 00 1f 00 ..................
    00 00 08 00 02 00 0a 00 00 00 14 00 18 00 08 00 01 00 ..................
    1a 00 00 00 08 00 02 00 0b 00 00 00 14 00 19 00 08 00 ..................
    01 00 1b 00 00 00 08 00 02 00 0b 00 00 00 14 00 1a 00 ..................
    08 00 01 00 1c 00 00 00 08 00 02 00 0a 00 00 00 14 00 ..................
    1b 00 08 00 01 00 1d 00 00 00 08 00 02 00 0b 00 00 00 ..................
    14 00 1c 00 08 00 01 00 21 00 00 00 08 00 02 00 0b 00 ........!.........
    00 00 14 00 1d 00 08 00 01 00 20 00 00 00 08 00 02 00 .......... .......
    0c 00 00 00 14 00 1e 00 08 00 01 00 4b 00 00 00 08 00 ............K.....
    02 00 0b 00 00 00 14 00 1f 00 08 00 01 00 4c 00 00 00 ..............L...
    08 00 02 00 0b 00 00 00 14 00 20 00 08 00 01 00 25 00 .......... .....%.
    00 00 08 00 02 00 0b 00 00 00 14 00 21 00 08 00 01 00 ............!.....
    26 00 00 00 08 00 02 00 0b 00 00 00 14 00 22 00 08 00 &............."...
    01 00 27 00 00 00 08 00 02 00 0b 00 00 00 14 00 23 00 ..'.............#.
    08 00 01 00 28 00 00 00 08 00 02 00 0b 00 00 00 14 00 ....(.............
    24 00 08 00 01 00 2b 00 00 00 08 00 02 00 0b 00 00 00 $.....+...........
    14 00 25 00 08 00 01 00 2c 00 00 00 08 00 02 00 0b 00 ..%.....,.........
    00 00 14 00 26 00 08 00 01 00 2d 00 00 00 08 00 02 00 ....&.....-.......
    0f 00 00 00 14 00 27 00 08 00 01 00 2e 00 00 00 08 00 ......'...........
    02 00 0b 00 00 00 14 00 28 00 08 00 01 00 30 00 00 00 ........(.....0...
    08 00 02 00 0b 00 00 00 14 00 29 00 08 00 01 00 31 00 ..........).....1.
    00 00 08 00 02 00 0b 00 00 00 14 00 2a 00 08 00 01 00 ............*.....
    32 00 00 00 08 00 02 00 0c 00 00 00 14 00 2b 00 08 00 2.............+...
    01 00 34 00 00 00 08 00 02 00 0b 00 00 00 14 00 2c 00 ..4.............,.
    08 00 01 00 35 00 00 00 08 00 02 00 0b 00 00 00 14 00 ....5.............
    2d 00 08 00 01 00 36 00 00 00 08 00 02 00 0b 00 00 00 -.....6...........
    14 00 2e 00 08 00 01 00 37 00 00 00 08 00 02 00 0b 00 ........7.........
    00 00 14 00 2f 00 08 00 01 00 38 00 00 00 08 00 02 00 ..../.....8.......
    0b 00 00 00 14 00 30 00 08 00 01 00 39 00 00 00 08 00 ......0.....9.....
    02 00 0b 00 00 00 14 00 31 00 08 00 01 00 3a 00 00 00 ........1.....:...
    08 00 02 00 0b 00 00 00 14 00 32 00 08 00 01 00 3b 00 ..........2.....;.
    00 00 08 00 02 00 0b 00 00 00 14 00 33 00 08 00 01 00 ............3.....
    43 00 00 00 08 00 02 00 0b 00 00 00 14 00 34 00 08 00 C.............4...
    01 00 3d 00 00 00 08 00 02 00 0b 00 00 00 14 00 35 00 ..=.............5.
    08 00 01 00 3e 00 00 00 08 00 02 00 0a 00 00 00 14 00 ....>.............
    36 00 08 00 01 00 3f 00 00 00 08 00 02 00 0b 00 00 00 6.....?...........
    14 00 37 00 08 00 01 00 41 00 00 00 08 00 02 00 0b 00 ..7.....A.........
    00 00 14 00 38 00 08 00 01 00 42 00 00 00 08 00 02 00 ....8.....B.......
    0b 00 00 00 14 00 39 00 08 00 01 00 44 00 00 00 08 00 ......9.....D.....
    02 00 0b 00 00 00 14 00 3a 00 08 00 01 00 45 00 00 00 ........:.....E...
    08 00 02 00 0b 00 00 00 14 00 3b 00 08 00 01 00 49 00 ..........;.....I.
    00 00 08 00 02 00 0a 00 00 00 14 00 3c 00 08 00 01 00 ............<.....
    4a 00 00 00 08 00 02 00 0b 00 00 00 14 00 3d 00 08 00 J.............=...
    01 00 4f 00 00 00 08 00 02 00 0b 00 00 00 14 00 3e 00 ..O.............>.
    08 00 01 00 52 00 00 00 08 00 02 00 0b 00 00 00 14 00 ....R.............
    3f 00 08 00 01 00 51 00 00 00 08 00 02 00 0b 00 00 00 ?.....Q...........
    14 00 40 00 08 00 01 00 53 00 00 00 08 00 02 00 0b 00 .. at .....S.........
    00 00 14 00 41 00 08 00 01 00 54 00 00 00 08 00 02 00 ....A.....T.......
    0b 00 00 00 14 00 42 00 08 00 01 00 55 00 00 00 08 00 ......B.....U.....
    02 00 0b 00 00 00 14 00 43 00 08 00 01 00 57 00 00 00 ........C.....W...
    08 00 02 00 0b 00 00 00                               ........
  [ATTR 07] 128 octets
    18 00 01 00 08 00 02 00 03 00 00 00 0b 00 01 00 63 6f ................co
    6e 66 69 67 00 00 18 00 02 00 08 00 02 00 04 00 00 00 nfig..............
    09 00 01 00 73 63 61 6e 00 00 00 00 1c 00 03 00 08 00 ....scan..........
    02 00 05 00 00 00 0f 00 01 00 72 65 67 75 6c 61 74 6f ..........regulato
    72 79 00 00 18 00 04 00 08 00 02 00 06 00 00 00 09 00 ry................
    01 00 6d 6c 6d 65 00 00 00 00 1c 00 05 00 08 00 02 00 ..mlme............
    07 00 00 00 0d 00 01 00 74 65 73 74 6d 6f 64 65 00 00 ........testmode..
    00 00                                                 ..
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 92
    .nlmsg_type = 16 <genl/family::nlctrl>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    01 02 00 00                                           ....
  [ATTR 02] 11 octets
    4c 49 47 5f 46 41 4d 49 4c 59 00                      LIG_FAMILY.
  [PADDING] 1 octets
    00                                                    .
  [ATTR 01] 2 octets
    19 00                                                 ..
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 03] 4 octets
    01 00 00 00                                           ....
  [ATTR 04] 4 octets
    00 00 00 00                                           ....
  [ATTR 05] 4 octets
    02 00 00 00                                           ....
  [ATTR 06] 20 octets
    14 00 01 00 08 00 01 00 00 00 00 00 08 00 02 00 0a 00 ..................
    00 00                                                 ..
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 20
    .nlmsg_type = 3 <DONE>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1364408051
    .nlmsg_pid = 13496
  [PAYLOAD] 4 octets
    00 00 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: End of multipart message block: type=DONE length=20
flags=<MULTI> sequence-nr=1364408051 pid=13496
End of  DAEMON




I hope it's not too much reading. I am running Ubuntu 12.10 with a
3.5.0 kernel. Please tell me if you need more infos or if I should run
a specific test.

Best regards


From dorogovtsev.dmitriy at gmail.com  Fri Mar 29 11:01:28 2013
From: dorogovtsev.dmitriy at gmail.com (=?KOI8-R?B?5M3J1NLJyiDkz9LPx8/Xw8XX?=)
Date: Fri, 29 Mar 2013 17:01:28 +0200
Subject: Possible memory leak in genl_ctrl_probe_by_name()
Message-ID: <CANowdiyJA8eih_=ZV1bBof5o2o9_1D0BgL5XVnxK1io5BS+TPg@mail.gmail.com>

Hello.

This is a small program using genl_ctrl_resolve(copied from test-genl.c).
Compile: gcc -o test main.c -I libnl-3.2.21/include/
libnl-3.2.21/lib/.libs/libnl-3.a libnl-3.2.21/lib/.libs/libnl-genl-3.a
-lpthread -lm
Run memcheck: valgrind --leak-check=full --show-reachable=yes ./test

I got following output:
...
==24905== HEAP SUMMARY:
==24905==     in use at exit: 112 bytes in 1 blocks
==24905==   total heap usage: 148 allocs, 147 frees, 31,720 bytes allocated
==24905==
==24905== 112 bytes in 1 blocks are definitely lost in loss record 1 of 1
==24905==    at 0x402A5E6: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==24905==    by 0x804F172: nl_cb_alloc (handlers.c:208)
==24905==    by 0x40A84D2: (below main) (libc-start.c:226)
==24905==
==24905== LEAK SUMMARY:
==24905==    definitely lost: 112 bytes in 1 blocks
==24905==    indirectly lost: 0 bytes in 0 blocks
==24905==      possibly lost: 0 bytes in 0 blocks
==24905==    still reachable: 0 bytes in 0 blocks
==24905==         suppressed: 0 bytes in 0 blocks
...

I think it's a bug in genl_ctrl_probe_by_name():

...
if (!(cb = nl_cb_clone(nl_socket_get_cb(sk))))
        goto out_msg_free;
...

Here we increase ref count on sk->s_cb, so i think it should be decremented
later.
With this patch i don't have valgrind memleak anymore:

--- libnl-3.2.21_o/lib/genl/ctrl.c    2013-01-24 14:30:34.000000000 +0200
+++ libnl-3.2.21/lib/genl/ctrl.c    2013-03-29 16:53:12.012950437 +0200
@@ -431,7 +431,8 @@
         err = -NLE_OBJ_NOTFOUND;
         goto errout;
     }
-
+
+    nl_cb_put( sk->s_cb );
     err = genl_family_get_id(family);
     genl_family_put(family);
 errout:

I use libnl-3.2.21 with Ubuntu 12.04 (3.2.0-39-generic-pae kernel).
Sorry for my English, and please let me know if you need additional
information.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130329/32a3a821/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 1808 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130329/32a3a821/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 310 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130329/32a3a821/attachment.obj>

From holger at eitzenberger.org  Sun Mar 31 15:16:21 2013
From: holger at eitzenberger.org (Holger Eitzenberger)
Date: Sun, 31 Mar 2013 21:16:21 +0200
Subject: [PATCH v2] ct: add ICMPv6 support
Message-ID: <20130331191621.GA8339@imap.eitzenberger.org>

Hi Thomas,

currently the ICMPv6 conntrack objects in libnl are without type, code
and ID.  This e. g. is the output of nl_object_dump() without the patch:

  ipv6-icmp ::1 <-> ::1 
  id 0xdd0871f0 family inet6 timeout 30s <NOREPLY,SNAT_INIT,DNAT_INIT>

The attached patch tries to solve that.  It then looks like

  ipv6-icmp ::1 <-> ::1 icmp type 128 code 0 id 28253 
  id 0xdf3a11f0 family inet6 timeout 30s <SNAT_INIT,DNAT_INIT>

It is the 'small' approach, because it reuses the existing ICMP
attributes of the conntrack object (currently only used for IPv4).
This way I can avoid to add new _icmp6_get_, _icmp6_set_ and
_icmp6_test_ functions.

There are two changes from the v1 patch:

* byte-swap was missing for ICMPv6 ID
* conditionally check for ICMP or ICMPv6 attributes dep. on family

Please let me know if something is missing.

Regards,

 /Holger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ct-ICMPv6-support.diff
Type: text/x-diff
Size: 2932 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130331/e9352ef5/attachment.bin>

