From jgehrcke at googlemail.com  Thu Mar  3 10:13:11 2011
From: jgehrcke at googlemail.com (Jan-Philip gehrcke)
Date: Thu, 03 Mar 2011 16:13:11 +0100
Subject: get the IFLA_STATS attribute (rx/tx byte counters) for a specific
	interface
In-Reply-To: <20110225163707.GB9763@canuck.infradead.org>
References: <4D67D62E.5090901@googlemail.com>
	<20110225163707.GB9763@canuck.infradead.org>
Message-ID: <4D6FB007.2070409@googlemail.com>

On 02/25/2011 05:37 PM, Thomas Graf wrote:
> On Fri, Feb 25, 2011 at 05:17:50PM +0100, Jan-Philip gehrcke wrote:
>   
>> Hello,
>>
>> currently, I'm trying to create a bandwidth measurement program for my
>> Linux router in C. Obviously, for calculating a bandwidth, you need a
>> time and byte count difference. Due to performance reasons, I would like
>> to get the byte counters directly from the kernel, without reading from
>> /proc oder /sys. Therefore, I'm working myself through the 'ip' program,
>> gathering this data via rtnetlink using libnetlink. While searching the
>> web to understand more of this topic, I came across libnl which seems to
>> be a cleaner and more modern implementation. However, I'm a bit
>> overwhelmed by the documentation.
>>     
> You may want to have a look at:
>
> http://www.infradead.org/~tgr/bmon/
>
> It is a bandwidth measurement program I've created which is based on
> libnl.
>
>   
>> Assume I know the interface index of the interface I want to evaluate.
>> Then, what is the cleanest way to use libnl to receive the corresponding
>> IFLA_STATS attribute [1] containing the byte counters? I would
>> appreciate any guidance/suggestion that helps me orienting in libnl :-)
>>     
> A good reference would be:
>
> http://git.infradead.org/users/tgr/bmon.git/blob/HEAD:/src/in_netlink.c
>
> -Thomas
>   
Dear Thomas,

thanks for your immediate answer. I  ended up using the development
version of libnl to get to a working C program that reads out traffic
stats for a specific interface, just as I wanted to do. A small working
example is attached. However, I still have a performance-related question.

I definitely need a function that retrieves and returns the up-to-date
byte counter. In my attached example, this is get_rx_bytes(). My
motivation to use netlink API is to have a faster solution than reading
the byte counter from a file in sysfs. Now, in my benchmarks, this
function get_rx_bytes() is "only" ~2-fold as fast as some
read_int_from_file("/sys/class/net/eth0/statistics/rx_bytes") function.
I was hoping for let's say an order of magnitude of improvement.

Do you see an easy way to optimize my get_rx_bytes() function? Can I
outsource some initialization overhead? Do I retrieve too much data in
the first place via rtnl_link_alloc_cache()?

In other words: my goal is to minimize the time it takes to execute

    for (i=0; i<N; i++) {get_rx_bytes("eth0");}

How do I do this?

Could it be the case that libnl is already too "high-level" for such
optimizations? Do you expect libnetlink (used in iproute2/ip programs)
being "faster" by only retrieving the information I actually need?

Big thanks for any advice&suggestion.

Jan-Philip

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libnl_read_link_rx_bytes_minimal.c
Type: text/x-csrc
Size: 1025 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110303/c73052c5/attachment.bin>

From tgraf at infradead.org  Thu Mar  3 10:48:56 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 3 Mar 2011 10:48:56 -0500
Subject: get the IFLA_STATS attribute (rx/tx byte counters) for a
	specific interface
In-Reply-To: <4D6FB007.2070409@googlemail.com>
References: <4D67D62E.5090901@googlemail.com>
	<20110225163707.GB9763@canuck.infradead.org>
	<4D6FB007.2070409@googlemail.com>
Message-ID: <20110303154856.GE10761@canuck.infradead.org>

On Thu, Mar 03, 2011 at 04:13:11PM +0100, Jan-Philip gehrcke wrote:
> unsigned int get_rx_bytes(const char *interface_name) {
>     // load all link data into cache
>     if (rtnl_link_alloc_cache(sock, AF_UNSPEC, &link_cache) < 0) {
>         nl_socket_free(sock);
>         return -1;
>         }
> 
>     // filter link by name
>     if ((link = rtnl_link_get_by_name(link_cache, interface_name)) == NULL) {
>         printf("unknown interface/link name.\n");
>         return -1;
>         }
>         
>     // read and return counter
>     return rtnl_link_get_stat(link, RTNL_LINK_RX_BYTES);
>     }

Do rtnl_link_alloc_cache() once and only nl_cache_resync() for ever iteration.
You are currently leaking the whole cache in every iteration.

This can be done faster by using the lower level APIs and by parsing the
link message replies yourself. I am not sure why you want to optimize this
though.


From tgraf at infradead.org  Wed Mar 16 08:06:18 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 16 Mar 2011 08:06:18 -0400
Subject: problem with netlink-kernel.h
In-Reply-To: <AANLkTimqnkPAUxbJ4-=fpgSTgr7_hxdGkRutgBxsKA7S@mail.gmail.com>
References: <AANLkTimqnkPAUxbJ4-=fpgSTgr7_hxdGkRutgBxsKA7S@mail.gmail.com>
Message-ID: <20110316120618.GC10096@canuck.infradead.org>

Gery,

On Mon, Jan 03, 2011 at 09:27:40AM +0200, Kahn, Gery wrote:
> There is header file netlink-kernel.h
> It is , i understand, copy of header file from kernel.
> The header file handlers.h includes the netlink-kernel.h
> This demands to copy netlink-kernel.h while command `make install'
> 
> Now, there is situation while libc also has file netlink.h with definition
> of the same structures. As a result, compiler complains about redefinition,
> for example 'struct sockaddr_nl'.
> 
> Can the libnl use the kernel header from kernel source, without coping it?
> Any other solution would be welcome :)
> 
> I found this problem while compiling wpa_supplicant.

Sorry it took so long. The issue has been fixed in the git tree.

Thanks!


From tgraf at infradead.org  Wed Mar 16 08:09:56 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 16 Mar 2011 08:09:56 -0400
Subject: [PATCH] Fix out-of-tree build.
In-Reply-To: <1295001485-28597-1-git-send-email-thierry.reding@avionic-design.de>
References: <1295001485-28597-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <20110316120956.GD10096@canuck.infradead.org>

On Fri, Jan 14, 2011 at 11:38:05AM +0100, Thierry Reding wrote:
> This patch fixes out-of-tree build, that is, when building with
> $builddir != $srcdir. In such a case, some generated header files are
> not found because they live in a different tree and can be fixed by
> adding the directories to the compiler's include search path.

What is the use case when building outside of the source tree?

I assume you are referring to bison/flex generated header files.


From tgraf at infradead.org  Wed Mar 16 08:12:44 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 16 Mar 2011 08:12:44 -0400
Subject: [PATCH] Fix function nfnl_ct_del name
In-Reply-To: <1295520696-23126-1-git-send-email-ldefert@edenwall.com>
References: <1295520696-23126-1-git-send-email-ldefert@edenwall.com>
Message-ID: <20110316121244.GE10096@canuck.infradead.org>

On Thu, Jan 20, 2011 at 11:51:36AM +0100, Laurent Defert wrote:
> This function is named nfnl_nl_del in lib/netfilter/ct.c, while it was
> declared nfnl_ct_delete in the header.

Applied, thanks Laurent!


From tgraf at infradead.org  Wed Mar 16 08:23:05 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 16 Mar 2011 08:23:05 -0400
Subject: silent rules in build
In-Reply-To: <4D5E0392.8020209@techsoft3d.com>
References: <4D5E0392.8020209@techsoft3d.com>
Message-ID: <20110316122305.GF10096@canuck.infradead.org>

On Thu, Feb 17, 2011 at 09:28:50PM -0800, Reuben Hawkins wrote:
> Attached is a match for configure.in and lib/Makefile.am which
> allows for silent rules...  It just makes the build output
> cleaner...

Applied slightly modified version (see below)

Thanks Reuben!

commit b5c474e533fa3aceaebf3189acd3b5643092845b
Author: Reuben Hawkins <reuben at techsoft3d.com>
Date:   Thu Feb 17 21:28:50 2011 -0800

    allowing silent rules in build

diff --git a/configure.in b/configure.in
index c58a316..34ece73 100644
--- a/configure.in
+++ b/configure.in
@@ -13,6 +13,7 @@ AC_INIT(libnl, 2.1, tgraf at suug.ch)
 AC_CONFIG_HEADERS([lib/defs.h])
 AC_CONFIG_MACRO_DIR([m4])
 AM_INIT_AUTOMAKE([-Wall foreign subdir-objects])
+m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES(yes)], [])
 
 AC_PROG_CC
 AM_PROG_CC_C_O
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 13da8c2..ccab7ca 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -30,16 +30,16 @@ CLEANFILES = \
 # Hack to avoid using ylwrap. It does not function correctly in combination
 # with --header-file=
 route/pktloc_grammar.c: route/pktloc_grammar.l
-       $(LEX) --header-file=route/pktloc_grammar.h $(LFLAGS) -o $@ $^
+       $(AM_V_GEN) $(LEX) --header-file=route/pktloc_grammar.h $(LFLAGS) -o $@ $^
 
 route/pktloc_syntax.c: route/pktloc_syntax.y
-       $(YACC) -d $(YFLAGS) -o $@ $^
+       $(AM_V_GEN) $(YACC) -d $(YFLAGS) -o $@ $^
 
 route/cls/ematch_grammar.c: route/cls/ematch_grammar.l
-       $(LEX) --header-file=route/cls/ematch_grammar.h $(LFLAGS) -o $@ $^
+       $(AM_V_GEN) $(LEX) --header-file=route/cls/ematch_grammar.h $(LFLAGS) -o $@ $^
 
 route/cls/ematch_syntax.c: route/cls/ematch_syntax.y
-       $(YACC) -d $(YFLAGS) -o $@ $^
+       $(AM_V_GEN) $(YACC) -d $(YFLAGS) -o $@ $^
 
 libnl_route_la_LIBADD  = libnl.la
 libnl_route_la_SOURCES = \




From thierry.reding at avionic-design.de  Wed Mar 16 08:37:20 2011
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 16 Mar 2011 13:37:20 +0100
Subject: [PATCH] Fix out-of-tree build.
In-Reply-To: <20110316120956.GD10096@canuck.infradead.org>
References: <1295001485-28597-1-git-send-email-thierry.reding@avionic-design.de>
	<20110316120956.GD10096@canuck.infradead.org>
Message-ID: <20110316123720.GA32205@avionic-0098.mockup.avionic-design.de>

* Thomas Graf wrote:
> On Fri, Jan 14, 2011 at 11:38:05AM +0100, Thierry Reding wrote:
> > This patch fixes out-of-tree build, that is, when building with
> > $builddir != $srcdir. In such a case, some generated header files are
> > not found because they live in a different tree and can be fixed by
> > adding the directories to the compiler's include search path.
> 
> What is the use case when building outside of the source tree?

I'm building libnl as part of a custom distribution, which builds outside the
source tree by default for autotools-based packages. This is done primarily
in order to not clutter the source tree with build files, but has other
advantages as well. Allowing the build directory to be removed while keeping
the source tree (with possibly modified sources) around would be one such
advantage.

> I assume you are referring to bison/flex generated header files.

Yes.

Cheers,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110316/b9580a71/attachment.sig>

From tgraf at infradead.org  Wed Mar 16 08:47:57 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 16 Mar 2011 08:47:57 -0400
Subject: libnl version #define LIBNL_VERSION
In-Reply-To: <20110221213630.GA8964@jm.kir.nu>
References: <20110221213630.GA8964@jm.kir.nu>
Message-ID: <20110316124757.GG10096@canuck.infradead.org>

Jouni,

On Mon, Feb 21, 2011 at 11:36:30PM +0200, Jouni Malinen wrote:
> Would it be possible to add a bit more helpful define in
> netlink/version.h to allow C preprocessor to be used to select
> conditional code based on the libnl version that is installed on the
> system? Since the libnl API seems to be changing between versions in
> ways that require changes in programs using it, it would be convenient
> to be able to do this without having to use manual configuration or
> pkg-config.
> 
> Something like #define LIBNL_VERSION_NUM 0x0201 would make this easier.
> I think I can actually use #ifdef LIBNL_VERSION to distinguish 1.1 from
> 2.0, but I did not see any clear way of doing this between 2.0 and
> current git tree (2.1? 3.0?).

I've commited the following patch:

commit d8d67c0a4c348837ed3c3f8377b1f8a4e5574f5f
Author: Thomas Graf <tgraf at suug.ch>
Date:   Wed Mar 16 13:46:41 2011 +0100

    Provide numeric version defines

diff --git a/configure.in b/configure.in
index 34ece73..a0199d0 100644
--- a/configure.in
+++ b/configure.in
@@ -6,7 +6,7 @@
 #      License as published by the Free Software Foundation version 2.1
 #      of the License.
 #
-# Copyright (c) 2003-2010 Thomas Graf <tgraf at suug.ch>
+# Copyright (c) 2003-2011 Thomas Graf <tgraf at suug.ch>
 #
 
 AC_INIT(libnl, 2.1, tgraf at suug.ch)
@@ -15,6 +15,11 @@ AC_CONFIG_MACRO_DIR([m4])
 AM_INIT_AUTOMAKE([-Wall foreign subdir-objects])
 m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES(yes)], [])
 
+MAJ_VERSION=2
+AC_SUBST([MAJ_VERSION])
+MIN_VERSION=1
+AC_SUBST([MIN_VERSION])
+
 AC_PROG_CC
 AM_PROG_CC_C_O
 AC_PROG_INSTALL
diff --git a/include/netlink/version.h.in b/include/netlink/version.h.in
index 7bd38cc..9deb365 100644
--- a/include/netlink/version.h.in
+++ b/include/netlink/version.h.in
@@ -6,7 +6,7 @@
  *     License as published by the Free Software Foundation version 2.1
  *     of the License.
  *
- * Copyright (c) 2008 Thomas Graf <tgraf at suug.ch>
+ * Copyright (c) 2008-2011 Thomas Graf <tgraf at suug.ch>
  */
 
 #ifndef NETLINK_VERSION_H_
@@ -15,4 +15,9 @@
 #define LIBNL_STRING "@PACKAGE_STRING@"
 #define LIBNL_VERSION "@PACKAGE_VERSION@"
 
+#define LIBNL_VER_MAJ          @MAJ_VERSION@
+#define LIBNL_VER_MIN          @MIN_VERSION@
+#define LIBNL_VER(maj,min)     ((maj) << 8 | (min))
+#define LIBNL_VER_NUM          LIBNL_VER(LIBNL_VER_MAJ, LIBNL_VER_MIN)
+
 #endif


From tgraf at infradead.org  Wed Mar 16 08:49:27 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 16 Mar 2011 08:49:27 -0400
Subject: [PATCH] Add missing argument in rtnl_link_change example
In-Reply-To: <1298470392-31224-1-git-send-email-miguel.filho@gmail.com>
References: <1298470392-31224-1-git-send-email-miguel.filho@gmail.com>
Message-ID: <20110316124927.GH10096@canuck.infradead.org>

On Wed, Feb 23, 2011 at 11:13:12AM -0300, Miguel Di Ciurcio Filho wrote:
> Signed-off-by: Miguel Di Ciurcio Filho <miguel.filho at gmail.com>

Applied, thanks Miguel!


From mathieu.peresse at gmail.com  Thu Mar 17 05:45:09 2011
From: mathieu.peresse at gmail.com (Mathieu Peresse)
Date: Thu, 17 Mar 2011 10:45:09 +0100
Subject: libnl 2.1
Message-ID: <AANLkTiksWK1-rw9nEJEs4GVJwk3m5x2FBquMWpTW4Nex@mail.gmail.com>

Hi,

I'm currently using libnl 1 for my software and I'm considering
switching to version 2. So I was wondering if libnl 2.1 will be out
soon, or if the dev tree
is usable as of now (since you state that v2.0 is in fact a pre version).

Thanks,

-- 
a+
mathieu


From tgraf at infradead.org  Thu Mar 17 06:05:41 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 17 Mar 2011 06:05:41 -0400
Subject: libnl 2.1
In-Reply-To: <AANLkTiksWK1-rw9nEJEs4GVJwk3m5x2FBquMWpTW4Nex@mail.gmail.com>
References: <AANLkTiksWK1-rw9nEJEs4GVJwk3m5x2FBquMWpTW4Nex@mail.gmail.com>
Message-ID: <20110317100541.GJ10096@canuck.infradead.org>

On Thu, Mar 17, 2011 at 10:45:09AM +0100, Mathieu Peresse wrote:
> I'm currently using libnl 1 for my software and I'm considering
> switching to version 2. So I was wondering if libnl 2.1 will be out
> soon, or if the dev tree
> is usable as of now (since you state that v2.0 is in fact a pre version).

I am currently marking it a pre version because various subsystems
of the library are still breaking APIs regularly.

I have considered releasing the invidivual libraries in their own
versioning namespace because the core library f.e. is very stable.

The git tree is definitely useable but the API but I can't guarantee
API stability of some of the subsystems currently being developed.


From pommnitz at yahoo.com  Thu Mar 17 07:37:54 2011
From: pommnitz at yahoo.com (Joerg Pommnitz)
Date: Thu, 17 Mar 2011 04:37:54 -0700 (PDT)
Subject: How to cast a struct nl_object
Message-ID: <140179.5139.qm@web161204.mail.bf1.yahoo.com>

Hello all,
I'm somewhat at a loss regarding something that should be simple enough:
figuring out the actual type of a struct nl_object instance and casting
it to the actual type.
Unfortunately I could not figure out (so far) how to do this cleanly. There
seems to be no official way to access the NLHDR_COMMON fields.

So: If I have a freshly parsed struct nl_object instance, how do I actually
use it and get the information inside without resorting to hacks?

Just in case: Here is what I'm trying to do:
I'm subscribed to the RTNLGRP_IPV4_IFADDR group and receiving messages. I pass
the messages up to nl_msg_parse with my own callback function to actually handle
the parsed message. This is where I'm stuck: The callback function gets a 
struct nl_object instance. I'd like to access the information inside it.

 -- 
Regards 
Joerg 




From pommnitz at yahoo.com  Thu Mar 17 07:55:22 2011
From: pommnitz at yahoo.com (Joerg Pommnitz)
Date: Thu, 17 Mar 2011 04:55:22 -0700 (PDT)
Subject: AW: How to cast a struct nl_object
Message-ID: <645438.17598.qm@web161204.mail.bf1.yahoo.com>

Sorry, I feel rather stupid now. struct nl_object is actually a public type 
defined
in netlink-types.h. I was confused by the fact that "struct nl_object" is not 
documented in the DocBook documentation on 
http://www.infradead.org/~tgr/libnl/doc-2.0
Please disregard my previous question.

 -- 
Regards 
Joerg 




----- Urspr?ngliche Mail ----
> Von: Joerg Pommnitz <pommnitz at yahoo.com>
> An: libnl at lists.infradead.org
> Gesendet: Donnerstag, den 17. M?rz 2011, 12:37:54 Uhr
> Betreff: How to cast a struct nl_object
> 
> Hello all,
> I'm somewhat at a loss regarding something that should be simple  enough:
> figuring out the actual type of a struct nl_object instance and  casting
> it to the actual type.
> Unfortunately I could not figure out (so  far) how to do this cleanly. There
> seems to be no official way to access the  NLHDR_COMMON fields.
> 
> So: If I have a freshly parsed struct nl_object  instance, how do I actually
> use it and get the information inside without  resorting to hacks?
> 
> Just in case: Here is what I'm trying to do:
> I'm  subscribed to the RTNLGRP_IPV4_IFADDR group and receiving messages. I  
>pass
> the messages up to nl_msg_parse with my own callback function to  actually 
>handle
> the parsed message. This is where I'm stuck: The callback  function gets a 
> struct nl_object instance. I'd like to access the  information inside it.
> 
>  -- 
> Regards 
> Joerg 
> 
> 
> 




From tgraf at infradead.org  Thu Mar 17 09:16:12 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 17 Mar 2011 09:16:12 -0400
Subject: How to cast a struct nl_object
In-Reply-To: <645438.17598.qm@web161204.mail.bf1.yahoo.com>
References: <645438.17598.qm@web161204.mail.bf1.yahoo.com>
Message-ID: <20110317131612.GK10096@canuck.infradead.org>

On Thu, Mar 17, 2011 at 04:55:22AM -0700, Joerg Pommnitz wrote:
> Sorry, I feel rather stupid now. struct nl_object is actually a public type 
> defined
> in netlink-types.h. I was confused by the fact that "struct nl_object" is not 
> documented in the DocBook documentation on 
> http://www.infradead.org/~tgr/libnl/doc-2.0
> Please disregard my previous question.

The easiest way is to look at obj->ce_msgtype to see what kind of
message the object was derived from.

http://www.infradead.org/~tgr/libnl/doc-2.0/group__object__api.html

netlink-types.h is not part of the public API.


From pommnitz at yahoo.com  Thu Mar 17 09:38:58 2011
From: pommnitz at yahoo.com (Joerg Pommnitz)
Date: Thu, 17 Mar 2011 06:38:58 -0700 (PDT)
Subject: AW: How to cast a struct nl_object
In-Reply-To: <20110317131612.GK10096@canuck.infradead.org>
References: <645438.17598.qm@web161204.mail.bf1.yahoo.com>
	<20110317131612.GK10096@canuck.infradead.org>
Message-ID: <645392.46147.qm@web161205.mail.bf1.yahoo.com>

Well...
If I'm not allowed to access netlink-types.h, then struct nl_object is not part 
of the public API either. How am I supposed to access obj->ce_msgtype?

And actually looking at ce_msgtype seems wrong to me. The question I'm asking 
the
object is "What are you?", not "How were you made?". Sure, with background 
knowledge
one can infer the answer to the first question from the answer to the second, 
but this seems a convoluted way to go.

May I suggest that an accessor for nl_object::ce_ops::oo_name would be very 
useful?
-- 
Regards 
Joerg 

----- Urspr?ngliche Mail ----
> Von: Thomas Graf <tgraf at infradead.org>
> An: Joerg Pommnitz <pommnitz at yahoo.com>
> CC: libnl at lists.infradead.org
> Gesendet: Donnerstag, den 17. M?rz 2011, 14:16:12 Uhr
> Betreff: Re: How to cast a struct nl_object
> 
> On Thu, Mar 17, 2011 at 04:55:22AM -0700, Joerg Pommnitz wrote:
> > Sorry, I  feel rather stupid now. struct nl_object is actually a public type 


> >  defined
> > in netlink-types.h. I was confused by the fact that "struct  nl_object" is 
>not 
>
> > documented in the DocBook documentation on 
> > http://www.infradead.org/~tgr/libnl/doc-2.0
> > Please disregard my  previous question.
> 
> The easiest way is to look at obj->ce_msgtype to  see what kind of
> message the object was derived from.
> 
> http://www.infradead.org/~tgr/libnl/doc-2.0/group__object__api.html
> 
> netlink-types.h  is not part of the public API.
> 




From tgraf at infradead.org  Thu Mar 17 09:46:51 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 17 Mar 2011 09:46:51 -0400
Subject: How to cast a struct nl_object
In-Reply-To: <645392.46147.qm@web161205.mail.bf1.yahoo.com>
References: <645438.17598.qm@web161204.mail.bf1.yahoo.com>
	<20110317131612.GK10096@canuck.infradead.org>
	<645392.46147.qm@web161205.mail.bf1.yahoo.com>
Message-ID: <20110317134651.GL10096@canuck.infradead.org>

On Thu, Mar 17, 2011 at 06:38:58AM -0700, Joerg Pommnitz wrote:
> If I'm not allowed to access netlink-types.h, then struct nl_object is not part 
> of the public API either. How am I supposed to access obj->ce_msgtype?
> 
> And actually looking at ce_msgtype seems wrong to me. The question I'm asking 
> the
> object is "What are you?", not "How were you made?". Sure, with background 
> knowledge
> one can infer the answer to the first question from the answer to the second, 
> but this seems a convoluted way to go.
> 
> May I suggest that an accessor for nl_object::ce_ops::oo_name would be very 
> useful?

You bring up a good point.

NLHDR_COMMON has been public via <netlink/object-api.h> but struct nl_object
was still defined in netlink-types.h

I've moved it to <netlink/object-api.h> with the commit below.

You may access the object type via obj->ce_ops->oo_name now

commit ae5dfb1cc7268c5134a1ee1c911f3792b80ff7ea
Author: Thomas Graf <tgraf at suug.ch>
Date:   Thu Mar 17 14:44:56 2011 +0100

    Make struct nl_object public, NLHDR_COMMON has been public anyway

diff --git a/include/netlink-types.h b/include/netlink-types.h
index 24911b9..de17f9a 100644
--- a/include/netlink-types.h
+++ b/include/netlink-types.h
@@ -101,11 +101,6 @@ struct nl_parser_param;
 
 #define NL_OBJ_MARK            1
 
-struct nl_object
-{
-       NLHDR_COMMON
-};
-
 struct nl_data
 {
        size_t                  d_size;
diff --git a/include/netlink/object-api.h b/include/netlink/object-api.h
index b3337f0..70a4ddd 100644
--- a/include/netlink/object-api.h
+++ b/include/netlink/object-api.h
@@ -190,6 +190,12 @@ extern "C" {
        int                     ce_flags;       \
        uint32_t                ce_mask;
 
+struct nl_object
+{
+       NLHDR_COMMON
+};
+
+
 /**
  * Return true if attribute is available in both objects
  * @arg A              an object




From pommnitz at yahoo.com  Thu Mar 17 09:56:52 2011
From: pommnitz at yahoo.com (Joerg Pommnitz)
Date: Thu, 17 Mar 2011 06:56:52 -0700 (PDT)
Subject: How to cast a struct nl_object
In-Reply-To: <20110317134651.GL10096@canuck.infradead.org>
References: <645438.17598.qm@web161204.mail.bf1.yahoo.com>
	<20110317131612.GK10096@canuck.infradead.org>
	<645392.46147.qm@web161205.mail.bf1.yahoo.com>
	<20110317134651.GL10096@canuck.infradead.org>
Message-ID: <40921.57581.qm@web161205.mail.bf1.yahoo.com>

Thanks. I feel less stupid now :-)

 -- 
Regards 
Joerg 




----- Urspr?ngliche Mail ----
> Von: Thomas Graf <tgraf at infradead.org>
> An: Joerg Pommnitz <pommnitz at yahoo.com>
> CC: libnl at lists.infradead.org
> Gesendet: Donnerstag, den 17. M?rz 2011, 14:46:51 Uhr
> Betreff: Re: How to cast a struct nl_object
> 
> You bring up a good point.
> 
> NLHDR_COMMON has been  public via <netlink/object-api.h> but struct nl_object
> was still  defined in netlink-types.h
> 
> I've moved it to <netlink/object-api.h>  with the commit below.
> 
> You may access the object type via  obj->ce_ops->oo_name now
> 
> commit  ae5dfb1cc7268c5134a1ee1c911f3792b80ff7ea
> Author: Thomas Graf <tgraf at suug.ch>
> Date:   Thu Mar 17  14:44:56 2011 +0100
> 
>     Make struct nl_object public,  NLHDR_COMMON has been public anyway




From tgraf at infradead.org  Mon Mar 21 12:49:35 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Mon, 21 Mar 2011 12:49:35 -0400
Subject: libnl-3.0 release
Message-ID: <20110321164935.GA21027@canuck.infradead.org>

Hello everyone

I'm pleased to announce the release of libnl-3.0. I believe the
API has reached a state which can be frozen and considered stable.
All further changes will be made with API/ABI stability in mind.
The need for another development tree may arise at some point in
the future, however, such a move is not to be expected in the near
future.

Going forward, please make sure any patches do not break API/ABI.

Tarball:
http://www.infradead.org/~tgr/libnl/files/libnl-3.0.tar.gz

API reference:
http://www.infradead.org/~tgr/libnl/doc-3.0/index.html

For a history of changes run:
$ git log libnl2_0..libnl3_0

Thanks everyone for their contributions!

-Thomas


From sahne at 0x90.at  Tue Mar 22 05:45:41 2011
From: sahne at 0x90.at (Daniel Walter)
Date: Tue, 22 Mar 2011 10:45:41 +0100
Subject: [PATCH] add missing checks for ROUTE_ATTR_MULTIPATH
Message-ID: <20110322094541.GA58206@0x90.at>

Hi,

attached patch adds missing checks for ROUTE_ATTR_MULTIPATH
when dealing with multipath routing.

Affected functions

rtnl_route_remove_nexthop
rtnl_route_get_nexthops
rtnl_route_get_nnexthops

regards,

daniel


diff --git a/lib/route/route_obj.c b/lib/route/route_obj.c
index 2cbe2ae..1ad58c9 100644
--- a/lib/route/route_obj.c
+++ b/lib/route/route_obj.c
@@ -687,18 +687,24 @@ void rtnl_route_add_nexthop(struct rtnl_route *route, struct rtnl_nexthop *nh)
 
 void rtnl_route_remove_nexthop(struct rtnl_route *route, struct rtnl_nexthop *nh)
 {
-       route->rt_nr_nh--;
-       nl_list_del(&nh->rtnh_list);
+       if (route->ce_mask & ROUTE_ATTR_MULTIPATH) {
+               route->rt_nr_nh--;
+               nl_list_del(&nh->rtnh_list);
+       }
 }
 
 struct nl_list_head *rtnl_route_get_nexthops(struct rtnl_route *route)
 {
-       return &route->rt_nexthops;
+       if (route->ce_mask & ROUTE_ATTR_MULTIPATH)
+               return &route->rt_nexthops;
+       return NULL;
 }
 
 int rtnl_route_get_nnexthops(struct rtnl_route *route)
 {
-       return route->rt_nr_nh;
+       if (route->ce_mask & ROUTE_ATTR_MULTIPATH)
+               return route->rt_nr_nh;
+       return 0;
 }
 
 void rtnl_route_foreach_nexthop(struct rtnl_route *r,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110322/cab5214a/attachment.sig>

From sahne at 0x90.at  Tue Mar 22 05:53:51 2011
From: sahne at 0x90.at (Daniel Walter)
Date: Tue, 22 Mar 2011 10:53:51 +0100
Subject: [PATCH] add missing nl_cache_search in cache.h
Message-ID: <20110322095351.GB58206@0x90.at>

hi,

fix missing declaration of nl_cache_search

-daniel

diff --git a/include/netlink/cache.h b/include/netlink/cache.h
index c752920..a2d4e64 100644
--- a/include/netlink/cache.h
+++ b/include/netlink/cache.h
@@ -68,6 +68,8 @@ extern int                    nl_cache_include(struct nl_cache *,
 
 /* General */
 extern int                     nl_cache_is_empty(struct nl_cache *);
+extern struct nl_object *      nl_cache_search(struct nl_cache *cache,
+                                 struct nl_object *needle);
 extern void                    nl_cache_mark_all(struct nl_cache *);
 
 /* Dumping */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110322/d2503710/attachment.sig>

From tgraf at infradead.org  Tue Mar 22 08:13:45 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Tue, 22 Mar 2011 08:13:45 -0400
Subject: [PATCH] add missing checks for ROUTE_ATTR_MULTIPATH
In-Reply-To: <20110322094541.GA58206@0x90.at>
References: <20110322094541.GA58206@0x90.at>
Message-ID: <20110322121345.GB21027@canuck.infradead.org>

On Tue, Mar 22, 2011 at 10:45:41AM +0100, Daniel Walter wrote:
> Hi,
> 
> attached patch adds missing checks for ROUTE_ATTR_MULTIPATH
> when dealing with multipath routing.
> 
> Affected functions
> 
> rtnl_route_remove_nexthop
> rtnl_route_get_nexthops
> rtnl_route_get_nnexthops

Applied, thanks Daniel.

(I had to fix up the patch a bit in order for it to apply)


From tgraf at infradead.org  Tue Mar 22 08:14:04 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Tue, 22 Mar 2011 08:14:04 -0400
Subject: [PATCH] add missing nl_cache_search in cache.h
In-Reply-To: <20110322095351.GB58206@0x90.at>
References: <20110322095351.GB58206@0x90.at>
Message-ID: <20110322121404.GC21027@canuck.infradead.org>

On Tue, Mar 22, 2011 at 10:53:51AM +0100, Daniel Walter wrote:
> hi,
> 
> fix missing declaration of nl_cache_search
> 

Applied, thanks Daniel

(I had to fix up the patch a bit in order for it to apply)


From thierry.reding at avionic-design.de  Wed Mar 23 05:17:21 2011
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 23 Mar 2011 10:17:21 +0100
Subject: libnl 3 with kernel < 2.6.38
Message-ID: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>

Hi,

I use libnl in a project for link monitoring and recently upgraded to libnl
3. However it looks like libnl 3 does not properly work against kernels older
than 2.6.38. Specifically, rtnl_link_change() returns NLE_INVAL with code
that worked with libnl 2 on 2.6.37 (and libnl 3 on 2.6.38) but fails with
libnl 3 on 2.6.37.

Am I doing something wrong or is this expected behaviour? I couldn't find any
mention of such an incompatibility.

Cheers,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110323/cf3d4d33/attachment.sig>

From tgraf at infradead.org  Wed Mar 23 05:44:14 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 23 Mar 2011 05:44:14 -0400
Subject: libnl 3 with kernel < 2.6.38
In-Reply-To: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>
References: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>
Message-ID: <20110323094414.GA21060@canuck.infradead.org>

On Wed, Mar 23, 2011 at 10:17:21AM +0100, Thierry Reding wrote:
> I use libnl in a project for link monitoring and recently upgraded to libnl
> 3. However it looks like libnl 3 does not properly work against kernels older
> than 2.6.38. Specifically, rtnl_link_change() returns NLE_INVAL with code
> that worked with libnl 2 on 2.6.37 (and libnl 3 on 2.6.38) but fails with
> libnl 3 on 2.6.37.
> 
> Am I doing something wrong or is this expected behaviour? I couldn't find any
> mention of such an incompatibility.

This is not expected behaviour.

Can you give me some additional details on what kind of link change
you do?


From thierry.reding at avionic-design.de  Wed Mar 23 05:50:06 2011
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 23 Mar 2011 10:50:06 +0100
Subject: libnl 3 with kernel < 2.6.38
In-Reply-To: <20110323094414.GA21060@canuck.infradead.org>
References: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>
	<20110323094414.GA21060@canuck.infradead.org>
Message-ID: <20110323095006.GA5967@avionic-0098.mockup.avionic-design.de>

* Thomas Graf wrote:
> On Wed, Mar 23, 2011 at 10:17:21AM +0100, Thierry Reding wrote:
> > I use libnl in a project for link monitoring and recently upgraded to libnl
> > 3. However it looks like libnl 3 does not properly work against kernels older
> > than 2.6.38. Specifically, rtnl_link_change() returns NLE_INVAL with code
> > that worked with libnl 2 on 2.6.37 (and libnl 3 on 2.6.38) but fails with
> > libnl 3 on 2.6.37.
> > 
> > Am I doing something wrong or is this expected behaviour? I couldn't find any
> > mention of such an incompatibility.
> 
> This is not expected behaviour.
> 
> Can you give me some additional details on what kind of link change
> you do?

The following is the function that exhibits the described behaviour:

	static int link_up(struct nl_sock *sock, struct rtnl_link *link)
	{
		struct rtnl_link *request = rtnl_link_alloc();
		int err = 0;

		rtnl_link_set_flags(request, IFF_UP);

		err = rtnl_link_change(sock, link, request, 0); 
		if (err < 0) {
			rtnl_link_put(request);
			return err;
		}

		rtnl_link_put(request);
		return 0;
	}

Cheers,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110323/a20b9a88/attachment.sig>

From tgraf at infradead.org  Wed Mar 23 07:20:44 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 23 Mar 2011 07:20:44 -0400
Subject: libnl 3 with kernel < 2.6.38
In-Reply-To: <20110323095006.GA5967@avionic-0098.mockup.avionic-design.de>
References: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>
	<20110323094414.GA21060@canuck.infradead.org>
	<20110323095006.GA5967@avionic-0098.mockup.avionic-design.de>
Message-ID: <20110323112044.GB21060@canuck.infradead.org>

On Wed, Mar 23, 2011 at 10:50:06AM +0100, Thierry Reding wrote:
> > This is not expected behaviour.
> > 
> > Can you give me some additional details on what kind of link change
> > you do?
> 
> The following is the function that exhibits the described behaviour:

Can you run your code with the environment variable NLCB=debug

	$ NLCB=debug ./program

and post the output of that?

I suspect the problem is the inclusion of the IFLA_AF_SPEC
attribute.


From thierry.reding at avionic-design.de  Wed Mar 23 08:03:29 2011
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 23 Mar 2011 13:03:29 +0100
Subject: libnl 3 with kernel < 2.6.38
In-Reply-To: <20110323112044.GB21060@canuck.infradead.org>
References: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>
	<20110323094414.GA21060@canuck.infradead.org>
	<20110323095006.GA5967@avionic-0098.mockup.avionic-design.de>
	<20110323112044.GB21060@canuck.infradead.org>
Message-ID: <20110323120329.GA23101@avionic-0098.mockup.avionic-design.de>

* Thomas Graf wrote:
> On Wed, Mar 23, 2011 at 10:50:06AM +0100, Thierry Reding wrote:
> > > This is not expected behaviour.
> > > 
> > > Can you give me some additional details on what kind of link change
> > > you do?
> > 
> > The following is the function that exhibits the described behaviour:
> 
> Can you run your code with the environment variable NLCB=debug
> 
> 	$ NLCB=debug ./program
> 
> and post the output of that?
> 
> I suspect the problem is the inclusion of the IFLA_AF_SPEC
> attribute.

Attached.

Cheers,
Thierry
-------------- next part --------------
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 20
    .nlmsg_type = 18 <route/link::get>
    .nlmsg_flags = 773 <REQUEST,ACK,ROOT,MATCH>
    .nlmsg_seq = 1009839801
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00       ................
  [LEFTOVER] -12 octets
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 424
    .nlmsg_type = 16 <route/link::new>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1009839801
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 04 03 01 00 00 00 49 00 01 00 00 00 00 00       ........I.......
  [ATTR 03] 3 octets
    6c 6f 00                                              lo.
  [PADDING] 1 octets
    00                                                    .
  [ATTR 13] 4 octets
    00 00 00 00                                           ....
  [ATTR 16] 1 octets
    00                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 17] 1 octets
    00                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 04] 4 octets
    34 40 00 00                                           4 at ..
  [ATTR 06] 8 octets
    6e 6f 71 75 65 75 65 00                               noqueue.
  [ATTR 14] 28 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00                         ..........
  [ATTR 01] 6 octets
    00 00 00 00 00 00                                     ......
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 02] 6 octets
    00 00 00 00 00 00                                     ......
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 07] 92 octets
    04 00 00 00 04 00 00 00 24 01 00 00 24 01 00 00 00 00 ........$...$.....
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00                                                 ..
  [ATTR 23] 184 octets
    04 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 24 01 ................$.
    00 00 00 00 00 00 24 01 00 00 00 00 00 00 00 00 00 00 ......$...........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 420
    .nlmsg_type = 16 <route/link::new>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1009839801
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 08 03 02 00 00 00 80 00 00 00 00 00 00 00       ................
  [ATTR 03] 5 octets
    73 69 74 30 00                                        sit0.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 13] 4 octets
    00 00 00 00                                           ....
  [ATTR 16] 1 octets
    02                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 17] 1 octets
    00                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 04] 4 octets
    c8 05 00 00                                           ....
  [ATTR 06] 5 octets
    6e 6f 6f 70 00                                        noop.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 14] 28 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00                         ..........
  [ATTR 01] 4 octets
    00 00 00 00                                           ....
  [ATTR 02] 4 octets
    00 00 00 00                                           ....
  [ATTR 07] 92 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00                                                 ..
  [ATTR 23] 184 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 444
    .nlmsg_type = 16 <route/link::new>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1009839801
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 01 03 03 00 00 00 80 00 00 00 00 00 00 00       ................
  [ATTR 03] 8 octets
    69 70 36 74 6e 6c 30 00                               ip6tnl0.
  [ATTR 13] 4 octets
    00 00 00 00                                           ....
  [ATTR 16] 1 octets
    02                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 17] 1 octets
    00                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 04] 4 octets
    ac 05 00 00                                           ....
  [ATTR 06] 5 octets
    6e 6f 6f 70 00                                        noop.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 14] 28 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00                         ..........
  [ATTR 01] 16 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00       ................
  [ATTR 02] 16 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00       ................
  [ATTR 07] 92 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00                                                 ..
  [ATTR 23] 184 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 436
    .nlmsg_type = 16 <route/link::new>
    .nlmsg_flags = 2 <MULTI>
    .nlmsg_seq = 1009839801
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 01 00 04 00 00 00 02 10 00 00 00 00 00 00       ................
  [ATTR 03] 5 octets
    65 74 68 30 00                                        eth0.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 13] 4 octets
    e8 03 00 00                                           ....
  [ATTR 16] 1 octets
    02                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 17] 1 octets
    00                                                    .
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 04] 4 octets
    dc 05 00 00                                           ....
  [ATTR 06] 5 octets
    6e 6f 6f 70 00                                        noop.
  [PADDING] 3 octets
    00 00 00                                              ...
  [ATTR 14] 28 octets
    00 00 bc fe 00 00 00 00 00 00 be fe 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 17 00 00 00                         ..........
  [ATTR 01] 6 octets
    00 d0 c9 b8 70 71                                     ....pq
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 02] 6 octets
    ff ff ff ff ff ff                                     ......
  [PADDING] 2 octets
    00 00                                                 ..
  [ATTR 07] 92 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00                                                 ..
  [ATTR 23] 184 octets
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
    00 00 00 00                                           ....
  [ATTR 21] 4 octets
    00 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 = 1009839801
    .nlmsg_pid = 1980
  [PAYLOAD] 4 octets
    00 00 00 00                                           ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: End of multipart message block: type=DONE length=20 flags=<MULTI> sequence-nr=1009839801 pid=1980
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 36
    .nlmsg_type = 19 <route/link::set>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1009839802
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 00 00 02 00 00 00 81 00 00 00 00 00 00 00       ................
  [ATTR 26] 0 octets
    ---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 56
    .nlmsg_type = 2 <ERROR>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 1009839802
    .nlmsg_pid = 1980
  [ERRORMSG] 20 octets
    .error = -22 "Invalid argument"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .nlmsg_type = 19 <0x13>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1009839802
    .nlmsg_pid = 1980
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Error received: Invalid argument
-- Original message: type=0x13 length=36 flags=<REQUEST,ACK> sequence-nr=1009839802 pid=1980
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 36
    .nlmsg_type = 19 <route/link::set>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1009839803
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 00 00 03 00 00 00 81 00 00 00 00 00 00 00       ................
  [ATTR 26] 0 octets
    ---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 56
    .nlmsg_type = 2 <ERROR>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 1009839803
    .nlmsg_pid = 1980
  [ERRORMSG] 20 octets
    .error = -22 "Invalid argument"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .nlmsg_type = 19 <0x13>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1009839803
    .nlmsg_pid = 1980
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Error received: Invalid argument
-- Original message: type=0x13 length=36 flags=<REQUEST,ACK> sequence-nr=1009839803 pid=1980
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 36
    .nlmsg_type = 19 <route/link::set>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1009839804
    .nlmsg_pid = 1980
  [PAYLOAD] 16 octets
    00 00 00 00 04 00 00 00 03 10 00 00 00 00 00 00       ................
  [ATTR 26] 0 octets
    ---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 56
    .nlmsg_type = 2 <ERROR>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 1009839804
    .nlmsg_pid = 1980
  [ERRORMSG] 20 octets
    .error = -22 "Invalid argument"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .nlmsg_type = 19 <0x13>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1009839804
    .nlmsg_pid = 1980
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Error received: Invalid argument
-- Original message: type=0x13 length=36 flags=<REQUEST,ACK> sequence-nr=1009839804 pid=1980
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110323/4dc31ca7/attachment-0001.sig>

From tgraf at infradead.org  Wed Mar 23 08:43:15 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 23 Mar 2011 08:43:15 -0400
Subject: libnl 3 with kernel < 2.6.38
In-Reply-To: <20110323120329.GA23101@avionic-0098.mockup.avionic-design.de>
References: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>
	<20110323094414.GA21060@canuck.infradead.org>
	<20110323095006.GA5967@avionic-0098.mockup.avionic-design.de>
	<20110323112044.GB21060@canuck.infradead.org>
	<20110323120329.GA23101@avionic-0098.mockup.avionic-design.de>
Message-ID: <20110323124315.GC21060@canuck.infradead.org>

On Wed, Mar 23, 2011 at 01:03:29PM +0100, Thierry Reding wrote:

> -- Original message: type=0x13 length=36 flags=<REQUEST,ACK> sequence-nr=1009839803 pid=1980
> -- Debug: Sent Message:
> --------------------------   BEGIN NETLINK MESSAGE ---------------------------
>   [HEADER] 16 octets
>     .nlmsg_len = 36
>     .nlmsg_type = 19 <route/link::set>
>     .nlmsg_flags = 5 <REQUEST,ACK>
>     .nlmsg_seq = 1009839804
>     .nlmsg_pid = 1980
>   [PAYLOAD] 16 octets
>     00 00 00 00 04 00 00 00 03 10 00 00 00 00 00 00       ................
>   [ATTR 26] 0 octets
>     ---------------------------  END NETLINK MESSAGE   ---------------------------

Problem is this empty nested atribtue (IFLA_AF_SPEC)

Fixed with the following commit:

commit a0fe7a1c9abe3ab5bf8c9253fab50e114b02b87b
Author: Thomas Graf <tgraf at suug.ch>
Date:   Wed Mar 23 13:39:18 2011 +0100

    Omit empty nested attributes
    
    Check for empty nested attributes in nla_nest_end() and omit the
    attribute alltogether if is is the case.

diff --git a/lib/attr.c b/lib/attr.c
index cccd50d..a045351 100644
--- a/lib/attr.c
+++ b/lib/attr.c
@@ -1151,10 +1151,22 @@ struct nlattr *nla_nest_start(struct nl_msg *msg, int attrtype)
  */
 int nla_nest_end(struct nl_msg *msg, struct nlattr *start)
 {
-       size_t pad;
+       size_t pad, len;
 
-       start->nla_len = (unsigned char *) nlmsg_tail(msg->nm_nlh) -
-                               (unsigned char *) start;
+       len = (void *) nlmsg_tail(msg->nm_nlh) - (void *) start;
+
+       if (len == NLA_HDRLEN) {
+               /*
+                * Kernel can't handle empty nested attributes, trim the
+                * attribute header again
+                */
+               msg->nm_nlh->nlmsg_len -= NLA_HDRLEN;
+               memset(nlmsg_tail(msg->nm_nlh), 0, NLA_HDRLEN);
+
+               return 0;
+       }
+
+       start->nla_len = len;
 
        pad = NLMSG_ALIGN(msg->nm_nlh->nlmsg_len) - msg->nm_nlh->nlmsg_len;
        if (pad > 0) {




From thierry.reding at avionic-design.de  Wed Mar 23 09:14:24 2011
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 23 Mar 2011 14:14:24 +0100
Subject: libnl 3 with kernel < 2.6.38
In-Reply-To: <20110323124315.GC21060@canuck.infradead.org>
References: <20110323091721.GA26427@avionic-0098.mockup.avionic-design.de>
	<20110323094414.GA21060@canuck.infradead.org>
	<20110323095006.GA5967@avionic-0098.mockup.avionic-design.de>
	<20110323112044.GB21060@canuck.infradead.org>
	<20110323120329.GA23101@avionic-0098.mockup.avionic-design.de>
	<20110323124315.GC21060@canuck.infradead.org>
Message-ID: <20110323131424.GA21345@avionic-0098.mockup.avionic-design.de>

* Thomas Graf wrote:
> On Wed, Mar 23, 2011 at 01:03:29PM +0100, Thierry Reding wrote:
> 
> > -- Original message: type=0x13 length=36 flags=<REQUEST,ACK> sequence-nr=1009839803 pid=1980
> > -- Debug: Sent Message:
> > --------------------------   BEGIN NETLINK MESSAGE ---------------------------
> >   [HEADER] 16 octets
> >     .nlmsg_len = 36
> >     .nlmsg_type = 19 <route/link::set>
> >     .nlmsg_flags = 5 <REQUEST,ACK>
> >     .nlmsg_seq = 1009839804
> >     .nlmsg_pid = 1980
> >   [PAYLOAD] 16 octets
> >     00 00 00 00 04 00 00 00 03 10 00 00 00 00 00 00       ................
> >   [ATTR 26] 0 octets
> >     ---------------------------  END NETLINK MESSAGE   ---------------------------
> 
> Problem is this empty nested atribtue (IFLA_AF_SPEC)
> 
> Fixed with the following commit:
> 
> commit a0fe7a1c9abe3ab5bf8c9253fab50e114b02b87b
> Author: Thomas Graf <tgraf at suug.ch>
> Date:   Wed Mar 23 13:39:18 2011 +0100
> 
>     Omit empty nested attributes
>     
>     Check for empty nested attributes in nla_nest_end() and omit the
>     attribute alltogether if is is the case.
> 
> diff --git a/lib/attr.c b/lib/attr.c
> index cccd50d..a045351 100644
> --- a/lib/attr.c
> +++ b/lib/attr.c
> @@ -1151,10 +1151,22 @@ struct nlattr *nla_nest_start(struct nl_msg *msg, int attrtype)
>   */
>  int nla_nest_end(struct nl_msg *msg, struct nlattr *start)
>  {
> -       size_t pad;
> +       size_t pad, len;
>  
> -       start->nla_len = (unsigned char *) nlmsg_tail(msg->nm_nlh) -
> -                               (unsigned char *) start;
> +       len = (void *) nlmsg_tail(msg->nm_nlh) - (void *) start;
> +
> +       if (len == NLA_HDRLEN) {
> +               /*
> +                * Kernel can't handle empty nested attributes, trim the
> +                * attribute header again
> +                */
> +               msg->nm_nlh->nlmsg_len -= NLA_HDRLEN;
> +               memset(nlmsg_tail(msg->nm_nlh), 0, NLA_HDRLEN);
> +
> +               return 0;
> +       }
> +
> +       start->nla_len = len;
>  
>         pad = NLMSG_ALIGN(msg->nm_nlh->nlmsg_len) - msg->nm_nlh->nlmsg_len;
>         if (pad > 0) {

I can confirm that this patch works.

Cheers,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110323/54a58b12/attachment.sig>

From thierry.reding at avionic-design.de  Wed Mar 23 09:33:55 2011
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 23 Mar 2011 14:33:55 +0100
Subject: [PATCH] Fix out-of-tree build.
In-Reply-To: <20110316120956.GD10096@canuck.infradead.org>
References: <1295001485-28597-1-git-send-email-thierry.reding@avionic-design.de>
	<20110316120956.GD10096@canuck.infradead.org>
Message-ID: <20110323133354.GA9089@avionic-0098.mockup.avionic-design.de>

* Thomas Graf wrote:
> On Fri, Jan 14, 2011 at 11:38:05AM +0100, Thierry Reding wrote:
> > This patch fixes out-of-tree build, that is, when building with
> > $builddir != $srcdir. In such a case, some generated header files are
> > not found because they live in a different tree and can be fixed by
> > adding the directories to the compiler's include search path.
> 
> What is the use case when building outside of the source tree?
> 
> I assume you are referring to bison/flex generated header files.

I've been looking at this some more and something struck me. I usually build
tarballs for autotools-based packages using "make dist". I also run "make
distcheck" before releases to make that all needed files end up in the
tarball (note that distcheck also builds out-of-tree). However if I run "make
distcheck" for libnl from git, it gives me all kinds of errors about missing
includes and such.

This left me wondering what the current release procedure looks like, since
it cannot be "make dist". I'm also attaching a patch that fixes up the
automake files to fix this up.

Cheers,
Thierry
-------------- next part --------------
From 3e1c495291a78806031e631f3c95f81441889efa Mon Sep 17 00:00:00 2001
From: Thierry Reding <thierry.reding at avionic-design.de>
Date: Wed, 23 Mar 2011 14:27:51 +0100
Subject: [PATCH] Fix "make distcheck".

This commit adds some missing files (some header files, the files below
/etc and the bison/flex files) to the distribution tarball to ensure
that libnl can be built from the tarballs created using "make dist".

It also adds some incantations to properly generate the flex and bison
output since the generated output is no longer shipped in the tarball.
---
 Makefile.am         |    3 +++
 include/Makefile.am |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/Makefile.am     |   20 ++++++++++++++++++--
 3 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 5931a9e..07017c8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -15,6 +15,9 @@ pkgconfig_DATA = libnl-3.0.pc
 sysconfdir = @sysconfdir@/libnl
 sysconf_DATA = etc/pktloc etc/classid
 
+EXTRA_DIST = \
+	$(sysconf_DATA)
+
 .PHONY: cscope
 cscope:
 	cscope -b -q -R -Iinclude -slib -ssrc;
diff --git a/include/Makefile.am b/include/Makefile.am
index e7f1206..2fc44f5 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -59,3 +59,53 @@ nobase_include_HEADERS = \
 	netlink/types.h \
 	netlink/utils.h \
 	netlink/version.h
+
+noinst_HEADERS = \
+	linux/fib_rules.h \
+	linux/genetlink.h \
+	linux/gen_stats.h \
+	linux/if_addr.h \
+	linux/if_arp.h \
+	linux/if_ether.h \
+	linux/if.h \
+	linux/if_link.h \
+	linux/if_vlan.h \
+	linux/inetdevice.h \
+	linux/ip_mp_alg.h \
+	linux/ipv6.h \
+	linux/neighbour.h \
+	linux/netfilter.h \
+	linux/netfilter/nfnetlink_conntrack.h \
+	linux/netfilter/nfnetlink.h \
+	linux/netfilter/nfnetlink_log.h \
+	linux/netfilter/nfnetlink_queue.h \
+	linux/netlink.h \
+	linux/pkt_cls.h \
+	linux/pkt_sched.h \
+	linux/rtnetlink.h \
+	linux/snmp.h \
+	linux/tc_ematch/tc_em_meta.h \
+	netlink/cli/addr.h \
+	netlink/cli/class.h \
+	netlink/cli/cls.h \
+	netlink/cli/ct.h \
+	netlink/cli/link.h \
+	netlink/cli/neigh.h \
+	netlink/cli/qdisc.h \
+	netlink/cli/route.h \
+	netlink/cli/rule.h \
+	netlink/cli/tc.h \
+	netlink/cli/utils.h \
+	netlink/route/cls/basic.h \
+	netlink/route/cls/cgroup.h \
+	netlink/route/cls/ematch/cmp.h \
+	netlink/route/cls/ematch/meta.h \
+	netlink/route/cls/ematch/nbyte.h \
+	netlink/route/cls/ematch/text.h \
+	netlink/route/cls/ematch.h \
+	netlink/route/link/api.h \
+	netlink/route/pktloc.h \
+	netlink-generic.h \
+	netlink-local.h \
+	netlink-tc.h \
+	netlink-types.h
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 5999113..e8045b7 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -51,7 +51,6 @@ libnl_route_la_SOURCES = \
 	route/cls/fw.c route/cls/police.c route/cls/u32.c route/cls/basic.c \
 	route/cls/cgroup.c \
 	\
-	route/cls/ematch_syntax.c route/cls/ematch_grammar.c \
 	route/cls/ematch.c \
 	route/cls/ematch/container.c route/cls/ematch/cmp.c \
 	route/cls/ematch/nbyte.c route/cls/ematch/text.c \
@@ -67,8 +66,25 @@ libnl_route_la_SOURCES = \
 	\
 	fib_lookup/lookup.c fib_lookup/request.c \
 	\
-	route/pktloc_syntax.c route/pktloc_grammar.c route/pktloc.c
+	route/pktloc.c
 
+nodist_libnl_route_la_SOURCES = \
+	route/pktloc_syntax.c route/pktloc_syntax.h \
+	route/pktloc_grammar.c route/pktloc_grammar.h \
+	route/cls/ematch_syntax.c route/cls/ematch_syntax.h \
+	route/cls/ematch_grammar.c route/cls/ematch_grammar.h
+
+BUILT_SOURCES = \
+	route/cls/ematch_grammar.c \
+	route/cls/ematch_syntax.c \
+	route/pktloc_grammar.c \
+	route/pktloc_syntax.c
+
+EXTRA_DIST = \
+	route/pktloc_grammar.l \
+	route/pktloc_syntax.y \
+	route/cls/ematch_grammar.l \
+	route/cls/ematch_syntax.y
 
 if ENABLE_CLI
 nobase_pkglib_LTLIBRARIES = \
-- 
1.7.4.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110323/296100c8/attachment.sig>

From tgraf at infradead.org  Wed Mar 23 10:47:44 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 23 Mar 2011 10:47:44 -0400
Subject: [PATCH] Fix out-of-tree build.
In-Reply-To: <1295001485-28597-1-git-send-email-thierry.reding@avionic-design.de>
References: <1295001485-28597-1-git-send-email-thierry.reding@avionic-design.de>
Message-ID: <20110323144744.GD21060@canuck.infradead.org>

On Fri, Jan 14, 2011 at 11:38:05AM +0100, Thierry Reding wrote:
> This patch fixes out-of-tree build, that is, when building with
> $builddir != $srcdir. In such a case, some generated header files are
> not found because they live in a different tree and can be fixed by
> adding the directories to the compiler's include search path.

Applied, thanks Thierry.


From tgraf at infradead.org  Wed Mar 23 10:49:25 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Wed, 23 Mar 2011 10:49:25 -0400
Subject: [PATCH] Fix out-of-tree build.
In-Reply-To: <20110323133354.GA9089@avionic-0098.mockup.avionic-design.de>
References: <1295001485-28597-1-git-send-email-thierry.reding@avionic-design.de>
	<20110316120956.GD10096@canuck.infradead.org>
	<20110323133354.GA9089@avionic-0098.mockup.avionic-design.de>
Message-ID: <20110323144925.GE21060@canuck.infradead.org>

On Wed, Mar 23, 2011 at 02:33:55PM +0100, Thierry Reding wrote:
> I've been looking at this some more and something struck me. I usually build
> tarballs for autotools-based packages using "make dist". I also run "make
> distcheck" before releases to make that all needed files end up in the
> tarball (note that distcheck also builds out-of-tree). However if I run "make
> distcheck" for libnl from git, it gives me all kinds of errors about missing
> includes and such.
> 
> This left me wondering what the current release procedure looks like, since
> it cannot be "make dist". I'm also attaching a patch that fixes up the
> automake files to fix this up.

To be honest, I've been shipping a manually crafted tarball so far.

I'll be happy to use make dist if we can fix it.

> +	netlink/cli/addr.h \
> +	netlink/cli/class.h \
> +	netlink/cli/cls.h \
> +	netlink/cli/ct.h \
> +	netlink/cli/link.h \
> +	netlink/cli/neigh.h \
> +	netlink/cli/qdisc.h \
> +	netlink/cli/route.h \
> +	netlink/cli/rule.h \
> +	netlink/cli/tc.h \
> +	netlink/cli/utils.h \
> +	netlink/route/cls/basic.h \
> +	netlink/route/cls/cgroup.h \
> +	netlink/route/cls/ematch/cmp.h \
> +	netlink/route/cls/ematch/meta.h \
> +	netlink/route/cls/ematch/nbyte.h \
> +	netlink/route/cls/ematch/text.h \
> +	netlink/route/cls/ematch.h \
> +	netlink/route/link/api.h \
> +	netlink/route/pktloc.h \

Can you resend the patch with those headers being installed?


From thierry.reding at avionic-design.de  Wed Mar 23 10:57:52 2011
From: thierry.reding at avionic-design.de (Thierry Reding)
Date: Wed, 23 Mar 2011 15:57:52 +0100
Subject: [PATCH] Fix "make distcheck".
In-Reply-To: <20110323144925.GE21060@canuck.infradead.org>
References: <20110323144925.GE21060@canuck.infradead.org>
Message-ID: <1300892272-28819-1-git-send-email-thierry.reding@avionic-design.de>

This commit adds some missing files (some header files, the files below
/etc and the bison/flex files) to the distribution tarball to ensure
that libnl can be built from the tarballs created using "make dist".

It also adds some incantations to properly generate the flex and bison
output since the generated output is no longer shipped in the tarball.
---
 Makefile.am         |    3 +++
 include/Makefile.am |   50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/Makefile.am     |   20 ++++++++++++++++++--
 3 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 5931a9e..07017c8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -15,6 +15,9 @@ pkgconfig_DATA = libnl-3.0.pc
 sysconfdir = @sysconfdir@/libnl
 sysconf_DATA = etc/pktloc etc/classid
 
+EXTRA_DIST = \
+	$(sysconf_DATA)
+
 .PHONY: cscope
 cscope:
 	cscope -b -q -R -Iinclude -slib -ssrc;
diff --git a/include/Makefile.am b/include/Makefile.am
index e7f1206..50fde24 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -1,6 +1,17 @@
 # -*- Makefile -*-
 
 nobase_include_HEADERS = \
+	netlink/cli/addr.h \
+	netlink/cli/class.h \
+	netlink/cli/cls.h \
+	netlink/cli/ct.h \
+	netlink/cli/link.h \
+	netlink/cli/neigh.h \
+	netlink/cli/qdisc.h \
+	netlink/cli/route.h \
+	netlink/cli/rule.h \
+	netlink/cli/tc.h \
+	netlink/cli/utils.h \
 	netlink/fib_lookup/lookup.h \
 	netlink/fib_lookup/request.h \
 	netlink/genl/ctrl.h \
@@ -28,9 +39,17 @@ nobase_include_HEADERS = \
 	netlink/netlink.h \
 	netlink/object-api.h \
 	netlink/object.h \
+	netlink/route/cls/ematch/cmp.h \
+	netlink/route/cls/ematch/meta.h \
+	netlink/route/cls/ematch/nbyte.h \
+	netlink/route/cls/ematch/text.h \
+	netlink/route/cls/basic.h \
+	netlink/route/cls/cgroup.h \
+	netlink/route/cls/ematch.h \
 	netlink/route/cls/fw.h \
 	netlink/route/cls/police.h \
 	netlink/route/cls/u32.h \
+	netlink/route/link/api.h \
 	netlink/route/link/info-api.h \
 	netlink/route/link/vlan.h \
 	netlink/route/qdisc/cbq.h \
@@ -49,6 +68,7 @@ nobase_include_HEADERS = \
 	netlink/route/neighbour.h \
 	netlink/route/neightbl.h \
 	netlink/route/nexthop.h \
+	netlink/route/pktloc.h \
 	netlink/route/qdisc.h \
 	netlink/route/route.h \
 	netlink/route/rtnl.h \
@@ -59,3 +79,33 @@ nobase_include_HEADERS = \
 	netlink/types.h \
 	netlink/utils.h \
 	netlink/version.h
+
+noinst_HEADERS = \
+	linux/fib_rules.h \
+	linux/genetlink.h \
+	linux/gen_stats.h \
+	linux/if_addr.h \
+	linux/if_arp.h \
+	linux/if_ether.h \
+	linux/if.h \
+	linux/if_link.h \
+	linux/if_vlan.h \
+	linux/inetdevice.h \
+	linux/ip_mp_alg.h \
+	linux/ipv6.h \
+	linux/neighbour.h \
+	linux/netfilter.h \
+	linux/netfilter/nfnetlink_conntrack.h \
+	linux/netfilter/nfnetlink.h \
+	linux/netfilter/nfnetlink_log.h \
+	linux/netfilter/nfnetlink_queue.h \
+	linux/netlink.h \
+	linux/pkt_cls.h \
+	linux/pkt_sched.h \
+	linux/rtnetlink.h \
+	linux/snmp.h \
+	linux/tc_ematch/tc_em_meta.h \
+	netlink-generic.h \
+	netlink-local.h \
+	netlink-tc.h \
+	netlink-types.h
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 5999113..e8045b7 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -51,7 +51,6 @@ libnl_route_la_SOURCES = \
 	route/cls/fw.c route/cls/police.c route/cls/u32.c route/cls/basic.c \
 	route/cls/cgroup.c \
 	\
-	route/cls/ematch_syntax.c route/cls/ematch_grammar.c \
 	route/cls/ematch.c \
 	route/cls/ematch/container.c route/cls/ematch/cmp.c \
 	route/cls/ematch/nbyte.c route/cls/ematch/text.c \
@@ -67,8 +66,25 @@ libnl_route_la_SOURCES = \
 	\
 	fib_lookup/lookup.c fib_lookup/request.c \
 	\
-	route/pktloc_syntax.c route/pktloc_grammar.c route/pktloc.c
+	route/pktloc.c
 
+nodist_libnl_route_la_SOURCES = \
+	route/pktloc_syntax.c route/pktloc_syntax.h \
+	route/pktloc_grammar.c route/pktloc_grammar.h \
+	route/cls/ematch_syntax.c route/cls/ematch_syntax.h \
+	route/cls/ematch_grammar.c route/cls/ematch_grammar.h
+
+BUILT_SOURCES = \
+	route/cls/ematch_grammar.c \
+	route/cls/ematch_syntax.c \
+	route/pktloc_grammar.c \
+	route/pktloc_syntax.c
+
+EXTRA_DIST = \
+	route/pktloc_grammar.l \
+	route/pktloc_syntax.y \
+	route/cls/ematch_grammar.l \
+	route/cls/ematch_syntax.y
 
 if ENABLE_CLI
 nobase_pkglib_LTLIBRARIES = \
-- 
1.7.4.1



From nsitbon at denyall.com  Thu Mar 24 12:02:11 2011
From: nsitbon at denyall.com (Sitbon Nicolas)
Date: Thu, 24 Mar 2011 17:02:11 +0100
Subject: LIBNL 3.0 classid lookup path
Message-ID: <op.vsuutxie4i7dio@nsitbon-pc.denyall.local>

Hi,

I'm currently looking for potential issues for migrating my application  
 from libnl 2.0 to the newest 3.0.

It seems libnl try to read the file /etc/libnl/classid, /etc/libnl comes  
 from SYSCONFDIR (lib/route/classid.c:313) which is a compile time  
constant. My problem is that I don't know where my clients will install my  
application (libnl is shipped with it and it's a closed source  
application) so I can't configure (--sysconfdir) the path at compile time.  
Do you think it might be possible to add a way to modify the path to  
classid at runtime (environment variable)?

regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110324/97a95c7f/attachment.html>

From tgraf at infradead.org  Thu Mar 24 12:52:40 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 24 Mar 2011 12:52:40 -0400
Subject: LIBNL 3.0 classid lookup path
In-Reply-To: <op.vsuutxie4i7dio@nsitbon-pc.denyall.local>
References: <op.vsuutxie4i7dio@nsitbon-pc.denyall.local>
Message-ID: <20110324165240.GG21060@canuck.infradead.org>

On Thu, Mar 24, 2011 at 05:02:11PM +0100, Sitbon Nicolas wrote:
> I'm currently looking for potential issues for migrating my
> application from libnl 2.0 to the newest 3.0.
> 
> It seems libnl try to read the file /etc/libnl/classid, /etc/libnl
> comes from SYSCONFDIR (lib/route/classid.c:313) which is a compile
> time constant. My problem is that I don't know where my clients will
> install my application (libnl is shipped with it and it's a closed
> source application) so I can't configure (--sysconfdir) the path at
> compile time. Do you think it might be possible to add a way to
> modify the path to classid at runtime (environment variable)?

I guess adding support for recognizing an environment variable
NLSYSCONFDIR would solve your problem?


From nicolas.sitbon at gmail.com  Thu Mar 24 13:40:54 2011
From: nicolas.sitbon at gmail.com (nicolas sitbon)
Date: Thu, 24 Mar 2011 18:40:54 +0100
Subject: LIBNL 3.0 classid lookup path
In-Reply-To: <CF7F722762658C48B9D1E4D356EC4F2901B23849932F@daex2007.DenyAll.local>
References: <op.vsuutxie4i7dio@nsitbon-pc.denyall.local>
	<CF7F722762658C48B9D1E4D356EC4F2901B23849932F@daex2007.DenyAll.local>
Message-ID: <AANLkTin3QpuY3tdFtfUH+Fp=P+R13PXVaxS85cK45F-B@mail.gmail.com>

Le jeudi 24 mars 2011, Thomas Graf <tgraf at infradead.org> a ?crit?:
> On Thu, Mar 24, 2011 at 05:02:11PM +0100, Sitbon Nicolas wrote:
>> I'm currently looking for potential issues for migrating my
>> application from libnl 2.0 to the newest 3.0.
>>
>> It seems libnl try to read the file /etc/libnl/classid, /etc/libnl
>> comes from SYSCONFDIR (lib/route/classid.c:313) which is a compile
>> time constant. My problem is that I don't know where my clients will
>> install my application (libnl is shipped with it and it's a closed
>> source application) so I can't configure (--sysconfdir) the path at
>> compile time. Do you think it might be possible to add a way to
>> modify the path to classid at runtime (environment variable)?
>
> I guess adding support for recognizing an environment variable
> NLSYSCONFDIR would solve your problem?
>

absolutely!


From tgraf at infradead.org  Thu Mar 24 16:18:14 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 24 Mar 2011 16:18:14 -0400
Subject: LIBNL 3.0 classid lookup path
In-Reply-To: <AANLkTin3QpuY3tdFtfUH+Fp=P+R13PXVaxS85cK45F-B@mail.gmail.com>
References: <op.vsuutxie4i7dio@nsitbon-pc.denyall.local>
	<CF7F722762658C48B9D1E4D356EC4F2901B23849932F@daex2007.DenyAll.local>
	<AANLkTin3QpuY3tdFtfUH+Fp=P+R13PXVaxS85cK45F-B@mail.gmail.com>
Message-ID: <20110324201814.GH21060@canuck.infradead.org>

On Thu, Mar 24, 2011 at 06:40:54PM +0100, nicolas sitbon wrote:
> Le jeudi 24 mars 2011, Thomas Graf <tgraf at infradead.org> a ?crit?:
> > On Thu, Mar 24, 2011 at 05:02:11PM +0100, Sitbon Nicolas wrote:
> >> I'm currently looking for potential issues for migrating my
> >> application from libnl 2.0 to the newest 3.0.
> >>
> >> It seems libnl try to read the file /etc/libnl/classid, /etc/libnl
> >> comes from SYSCONFDIR (lib/route/classid.c:313) which is a compile
> >> time constant. My problem is that I don't know where my clients will
> >> install my application (libnl is shipped with it and it's a closed
> >> source application) so I can't configure (--sysconfdir) the path at
> >> compile time. Do you think it might be possible to add a way to
> >> modify the path to classid at runtime (environment variable)?
> >
> > I guess adding support for recognizing an environment variable
> > NLSYSCONFDIR would solve your problem?

commit f523f297f7fed8b64fe4c2a6e3791d31b2d2448b
Author: Thomas Graf <tgraf at suug.ch>
Date:   Thu Mar 24 21:14:52 2011 +0100

    Allow NLSYSCONFDIR environment variable to overwrite built-in sysconfdir

diff --git a/include/netlink-local.h b/include/netlink-local.h
index 32e8302..9acc0e4 100644
--- a/include/netlink-local.h
+++ b/include/netlink-local.h
@@ -186,4 +186,16 @@ static inline int wait_for_ack(struct nl_sock *sk)
                return nl_wait_for_ack(sk);
 }
 
+static inline int build_sysconf_path(char **strp, const char *filename)
+{
+       char *sysconfdir;
+
+       sysconfdir = getenv("NLSYSCONFDIR");
+
+       if (!sysconfdir)
+               sysconfdir = SYSCONFDIR;
+
+       return asprintf(strp, "%s/%s", sysconfdir, filename);
+}
+
 #endif
diff --git a/lib/route/classid.c b/lib/route/classid.c
index 35cafe6..6af0ee3 100644
--- a/lib/route/classid.c
+++ b/lib/route/classid.c
@@ -310,7 +310,8 @@ int rtnl_tc_read_classid_file(void)
        FILE *fd;
        int err;
 
-       asprintf(&path, "%s/classid", SYSCONFDIR);
+       if (build_sysconf_path(&path, "classid") < 0)
+               return -NLE_NOMEM;
 
        /* if stat fails, just (re-)read the file */
        if (stat(path, &st) == 0) {
@@ -392,7 +393,7 @@ int rtnl_classid_generate(const char *name, uint32_t *result, uint32_t parent)
 
        NL_DBG(2, "Generated new classid %#x\n", classid);
 
-       if (asprintf(&path, "%s/classid", SYSCONFDIR) < 0)
+       if (build_sysconf_path(&path, "classid") < 0)
                return -NLE_NOMEM;
 
        if (!(fd = fopen(path, "a"))) {
diff --git a/lib/route/pktloc.c b/lib/route/pktloc.c
index 4d7d9dd..b677ab5 100644
--- a/lib/route/pktloc.c
+++ b/lib/route/pktloc.c
@@ -94,7 +94,8 @@ static int read_pktlocs(void)
        int i, err;
        FILE *fd;
 
-       asprintf(&path, "%s/pktloc", SYSCONFDIR);
+       if (build_sysconf_path(&path, "pktloc") < 0)
+               return -NLE_NOMEM;
 
        /* if stat fails, just try to read the file */
        if (stat(path, &st) == 0) {
diff --git a/src/Makefile.am b/src/Makefile.am
index 64d1cce..e196b58 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2,7 +2,7 @@
 
 SUBDIRS = lib
 
-AM_CPPFLAGS  = -Wall -I${top_srcdir}/include -I${top_builddir}/include -D_GNU_SOURCE
+AM_CPPFLAGS  = -Wall -I${top_srcdir}/include -I${top_builddir}/include -D_GNU_SOURCE -DSYSCONFDIR
 AM_LDFLAGS = -L${top_builddir}/lib -L${top_builddir}/src/lib -lnl-cli -lnl -lnl-nf -lnl-genl -lnl
 
 sbin_PROGRAMS = \



From nicolas.sitbon at gmail.com  Thu Mar 24 17:18:25 2011
From: nicolas.sitbon at gmail.com (nicolas sitbon)
Date: Thu, 24 Mar 2011 22:18:25 +0100
Subject: LIBNL 3.0 classid lookup path
In-Reply-To: <20110324201814.GH21060@canuck.infradead.org>
References: <op.vsuutxie4i7dio@nsitbon-pc.denyall.local>
	<CF7F722762658C48B9D1E4D356EC4F2901B23849932F@daex2007.DenyAll.local>
	<AANLkTin3QpuY3tdFtfUH+Fp=P+R13PXVaxS85cK45F-B@mail.gmail.com>
	<20110324201814.GH21060@canuck.infradead.org>
Message-ID: <AANLkTikStC33+1rgDt5insS5c=nhmLfnBjx+ctePbRzH@mail.gmail.com>

That is perfect!
Many thanks.

2011/3/24 Thomas Graf <tgraf at infradead.org>

> On Thu, Mar 24, 2011 at 06:40:54PM +0100, nicolas sitbon wrote:
> > Le jeudi 24 mars 2011, Thomas Graf <tgraf at infradead.org> a ?crit :
> > > On Thu, Mar 24, 2011 at 05:02:11PM +0100, Sitbon Nicolas wrote:
> > >> I'm currently looking for potential issues for migrating my
> > >> application from libnl 2.0 to the newest 3.0.
> > >>
> > >> It seems libnl try to read the file /etc/libnl/classid, /etc/libnl
> > >> comes from SYSCONFDIR (lib/route/classid.c:313) which is a compile
> > >> time constant. My problem is that I don't know where my clients will
> > >> install my application (libnl is shipped with it and it's a closed
> > >> source application) so I can't configure (--sysconfdir) the path at
> > >> compile time. Do you think it might be possible to add a way to
> > >> modify the path to classid at runtime (environment variable)?
> > >
> > > I guess adding support for recognizing an environment variable
> > > NLSYSCONFDIR would solve your problem?
>
> commit f523f297f7fed8b64fe4c2a6e3791d31b2d2448b
> Author: Thomas Graf <tgraf at suug.ch>
> Date:   Thu Mar 24 21:14:52 2011 +0100
>
>    Allow NLSYSCONFDIR environment variable to overwrite built-in sysconfdir
>
> diff --git a/include/netlink-local.h b/include/netlink-local.h
> index 32e8302..9acc0e4 100644
> --- a/include/netlink-local.h
> +++ b/include/netlink-local.h
> @@ -186,4 +186,16 @@ static inline int wait_for_ack(struct nl_sock *sk)
>                return nl_wait_for_ack(sk);
>  }
>
> +static inline int build_sysconf_path(char **strp, const char *filename)
> +{
> +       char *sysconfdir;
> +
> +       sysconfdir = getenv("NLSYSCONFDIR");
> +
> +       if (!sysconfdir)
> +               sysconfdir = SYSCONFDIR;
> +
> +       return asprintf(strp, "%s/%s", sysconfdir, filename);
> +}
> +
>  #endif
> diff --git a/lib/route/classid.c b/lib/route/classid.c
> index 35cafe6..6af0ee3 100644
> --- a/lib/route/classid.c
> +++ b/lib/route/classid.c
> @@ -310,7 +310,8 @@ int rtnl_tc_read_classid_file(void)
>        FILE *fd;
>        int err;
>
> -       asprintf(&path, "%s/classid", SYSCONFDIR);
> +       if (build_sysconf_path(&path, "classid") < 0)
> +               return -NLE_NOMEM;
>
>        /* if stat fails, just (re-)read the file */
>        if (stat(path, &st) == 0) {
> @@ -392,7 +393,7 @@ int rtnl_classid_generate(const char *name, uint32_t
> *result, uint32_t parent)
>
>        NL_DBG(2, "Generated new classid %#x\n", classid);
>
> -       if (asprintf(&path, "%s/classid", SYSCONFDIR) < 0)
> +       if (build_sysconf_path(&path, "classid") < 0)
>                return -NLE_NOMEM;
>
>        if (!(fd = fopen(path, "a"))) {
> diff --git a/lib/route/pktloc.c b/lib/route/pktloc.c
> index 4d7d9dd..b677ab5 100644
> --- a/lib/route/pktloc.c
> +++ b/lib/route/pktloc.c
> @@ -94,7 +94,8 @@ static int read_pktlocs(void)
>        int i, err;
>        FILE *fd;
>
> -       asprintf(&path, "%s/pktloc", SYSCONFDIR);
> +       if (build_sysconf_path(&path, "pktloc") < 0)
> +               return -NLE_NOMEM;
>
>        /* if stat fails, just try to read the file */
>        if (stat(path, &st) == 0) {
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 64d1cce..e196b58 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -2,7 +2,7 @@
>
>  SUBDIRS = lib
>
> -AM_CPPFLAGS  = -Wall -I${top_srcdir}/include -I${top_builddir}/include
> -D_GNU_SOURCE
> +AM_CPPFLAGS  = -Wall -I${top_srcdir}/include -I${top_builddir}/include
> -D_GNU_SOURCE -DSYSCONFDIR
>  AM_LDFLAGS = -L${top_builddir}/lib -L${top_builddir}/src/lib -lnl-cli -lnl
> -lnl-nf -lnl-genl -lnl
>
>  sbin_PROGRAMS = \
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110324/fbad9f64/attachment.html>

From sahne at 0x90.at  Fri Mar 25 06:50:37 2011
From: sahne at 0x90.at (Daniel Walter)
Date: Fri, 25 Mar 2011 11:50:37 +0100
Subject: IPv6 Preferred Source selection
Message-ID: <20110325105037.GA81801@0x90.at>

Hi,

does someone if the preferred source selection is working for ipv6 ?

I've inspected route_obj.c and it seems, that the nl_msg is filled
with the prefsrc and the flag RTA_PREFSRC is set. But it seems that the
RTA_PREFSRC is completly ignored within the kernel.

see rtm_to_fib6_config in linux/net/ipv6/route.c which parses
the netlink message and (should) create the routing entry.

Does anyone know how to select the preferred source for a route for ipv6 ?

regards,
daniel


From nsitbon at denyall.com  Fri Mar 25 09:32:49 2011
From: nsitbon at denyall.com (Sitbon Nicolas)
Date: Fri, 25 Mar 2011 14:32:49 +0100
Subject: IPv6 Preferred Source selection
In-Reply-To: <20110325105037.GA81801@0x90.at>
References: <20110325105037.GA81801@0x90.at>
Message-ID: <4D8C9981.4070208@denyall.com>

Le 25/03/2011 11:50, Daniel Walter a ?crit :
> Hi,
>
> does someone if the preferred source selection is working for ipv6 ?
>
> I've inspected route_obj.c and it seems, that the nl_msg is filled
> with the prefsrc and the flag RTA_PREFSRC is set. But it seems that the
> RTA_PREFSRC is completly ignored within the kernel.
>
> see rtm_to_fib6_config in linux/net/ipv6/route.c which parses
> the netlink message and (should) create the routing entry.
>
> Does anyone know how to select the preferred source for a route for ipv6 ?
>
> regards,
> daniel
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl
Hi Daniel,
It seems to be a kernel bug: 
http://www.spinics.net/lists/netdev/msg139939.html
regards.


From nsitbon at denyall.com  Fri Mar 25 10:25:09 2011
From: nsitbon at denyall.com (Sitbon Nicolas)
Date: Fri, 25 Mar 2011 15:25:09 +0100
Subject: libnl incorrectly handles the object not found case
Message-ID: <4D8CA5C5.5090809@denyall.com>

Hi,
Removing non existent route (both ipv4 and ipv6) using rtnl_route_delete 
return NLE_FAILURE generic error code. After investigation, it seems the 
linux kernel return -ESRCH in that case (see 
http://lxr.linux.no/linux+v2.6.38/net/ipv6/route.c#L1367). Same 
behaviour apply for removing non existent address. The function 
nl_syserr2nlerr (lib/error.c) which is responsible for translating from 
kernel error to libnl error doesn't handle ESRCH. The problem is present 
at least in version 2.0 and 3.0 of libnl. I propose a patch for the 3.0 
in attachment.
Regards.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-correctly-handle-the-object-not-found-case.patch
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110325/3b0eef98/attachment.ksh>

From nsitbon at denyall.com  Fri Mar 25 10:07:23 2011
From: nsitbon at denyall.com (Nicolas Sitbon)
Date: Fri, 25 Mar 2011 15:07:23 +0100
Subject: [PATCH] correctly handle the object not found case
Message-ID: <mailman.181.1301063113.1530.libnl@lists.infradead.org>

---
 lib/error.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/error.c b/lib/error.c
index a31461e..b973cdd 100644
--- a/lib/error.c
+++ b/lib/error.c
@@ -88,6 +88,7 @@ int nl_syserr2nlerr(int error)
 	case EADDRINUSE:	return NLE_EXIST;
 	case EEXIST:		return NLE_EXIST;
 	case EADDRNOTAVAIL:	return NLE_NOADDR;
+	case ESRCH:		/* fall through */
 	case ENOENT:		return NLE_OBJ_NOTFOUND;
 	case EINTR:		return NLE_INTR;
 	case EAGAIN:		return NLE_AGAIN;
-- 
1.6.0.4


--------------050703060205090501000809--


From laine at redhat.com  Fri Mar 25 11:14:47 2011
From: laine at redhat.com (Laine Stump)
Date: Fri, 25 Mar 2011 11:14:47 -0400
Subject: API differences from libnl-1.1 to 3.0
Message-ID: <4D8CB167.6080605@redhat.com>

I've been looking around and can't find an authoritative list of the API 
differences between libnl 1.1 and 3.0. Is there such a list? (or failing 
that, 1.1->2.0, and 2.0->3.0)

Also, it would be useful to have a similar list for 1.0 vs 1.1 (helpful 
when trying to make a package work on an older platform that is frozen 
on libnl-1.0 (eg RHEL5 or CentOS 5).


From tgraf at infradead.org  Fri Mar 25 11:48:40 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Fri, 25 Mar 2011 11:48:40 -0400
Subject: API differences from libnl-1.1 to 3.0
In-Reply-To: <4D8CB167.6080605@redhat.com>
References: <4D8CB167.6080605@redhat.com>
Message-ID: <20110325154840.GI21060@canuck.infradead.org>

On Fri, Mar 25, 2011 at 11:14:47AM -0400, Laine Stump wrote:
> I've been looking around and can't find an authoritative list of the
> API differences between libnl 1.1 and 3.0. Is there such a list? (or
> failing that, 1.1->2.0, and 2.0->3.0)
> 
> Also, it would be useful to have a similar list for 1.0 vs 1.1
> (helpful when trying to make a package work on an older platform
> that is frozen on libnl-1.0 (eg RHEL5 or CentOS 5).

No such list exists. Depending on the range of API used, the differences
are heavy.


From tgraf at infradead.org  Fri Mar 25 11:52:42 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Fri, 25 Mar 2011 11:52:42 -0400
Subject: libnl incorrectly handles the object not found case
In-Reply-To: <4D8CA5C5.5090809@denyall.com>
References: <4D8CA5C5.5090809@denyall.com>
Message-ID: <20110325155242.GK21060@canuck.infradead.org>

On Fri, Mar 25, 2011 at 03:25:09PM +0100, Sitbon Nicolas wrote:
> Removing non existent route (both ipv4 and ipv6) using
> rtnl_route_delete return NLE_FAILURE generic error code. After
> investigation, it seems the linux kernel return -ESRCH in that case
> (see http://lxr.linux.no/linux+v2.6.38/net/ipv6/route.c#L1367). Same
> behaviour apply for removing non existent address. The function
> nl_syserr2nlerr (lib/error.c) which is responsible for translating
> from kernel error to libnl error doesn't handle ESRCH. The problem
> is present at least in version 2.0 and 3.0 of libnl. I propose a
> patch for the 3.0 in attachment.

Applied, thanks!


From arekm at maven.pl  Mon Mar 28 16:47:28 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 28 Mar 2011 22:47:28 +0200
Subject: pkgconfig files for libnl 3.0 libraries
Message-ID: <201103282247.28889.arekm@maven.pl>


Hi,

How 

libnl-cli.so
libnl-genl.so
libnl-nf.so
libnl-route.so

are supposed to be used? I mean there is no pkgconfig files for these, so this 
looks like "don't try to use" these. On the other hand documentation suggests 
otherwise.

So the question is: is there a reason why these libs don't have their pc 
files?

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From tgraf at infradead.org  Tue Mar 29 07:24:44 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Tue, 29 Mar 2011 07:24:44 -0400
Subject: pkgconfig files for libnl 3.0 libraries
In-Reply-To: <201103282247.28889.arekm@maven.pl>
References: <201103282247.28889.arekm@maven.pl>
Message-ID: <20110329112444.GA16004@canuck.infradead.org>

On Mon, Mar 28, 2011 at 10:47:28PM +0200, Arkadiusz Miskiewicz wrote:
> libnl-cli.so
> libnl-genl.so
> libnl-nf.so
> libnl-route.so
> 
> are supposed to be used? I mean there is no pkgconfig files for these, so this 
> looks like "don't try to use" these. On the other hand documentation suggests 
> otherwise.
> 
> So the question is: is there a reason why these libs don't have their pc 
> files?

They are supposed to be used. The reason they don't have .pc files is because
nobody needed them thus far.

Feel free to fix this.


From arekm at maven.pl  Tue Mar 29 07:59:01 2011
From: arekm at maven.pl (=?UTF-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?=)
Date: Tue, 29 Mar 2011 13:59:01 +0200
Subject: [PATCH] Add pkgconfig files for cli/genl/nf/route libraries.
In-Reply-To: <20110329112444.GA16004@canuck.infradead.org>
References: <20110329112444.GA16004@canuck.infradead.org>
Message-ID: <1301399941-16224-1-git-send-email-arekm@maven.pl>

This patch adds pkgconfig (.pc) files for cli/genl/nf/route libraries
allowing to use PKG_CHECK_MODULES() m4 maco for their detection.

Signed-off-by: Arkadiusz Mi?kiwicz <arekm at maven.pl>
---
 Makefile.am           |    5 ++++-
 configure.in          |    3 ++-
 libnl-cli-3.0.pc.in   |   10 ++++++++++
 libnl-genl-3.0.pc.in  |   10 ++++++++++
 libnl-nf-3.0.pc.in    |   10 ++++++++++
 libnl-route-3.0.pc.in |   10 ++++++++++
 6 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 libnl-cli-3.0.pc.in
 create mode 100644 libnl-genl-3.0.pc.in
 create mode 100644 libnl-nf-3.0.pc.in
 create mode 100644 libnl-route-3.0.pc.in

diff --git a/Makefile.am b/Makefile.am
index 07017c8..6c922aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,14 +3,17 @@
 ACLOCAL_AMFLAGS = -I m4
 
 OPT_DIRS =
+PKGCONFIGS =
 
 if ENABLE_CLI
 OPT_DIRS += src
+PKGCONFIGS += libnl-cli-3.0.pc
 endif
 
 SUBDIRS = include lib doc man $(OPT_DIRS)
 
-pkgconfig_DATA = libnl-3.0.pc
+pkgconfig_DATA = libnl-3.0.pc libnl-genl-3.0.pc libnl-nf-3.0.pc \
+		 libnl-route-3.0.pc $(PKGCONFIGS)
 
 sysconfdir = @sysconfdir@/libnl
 sysconf_DATA = etc/pktloc etc/classid
diff --git a/configure.in b/configure.in
index 43150a7..b17b00c 100644
--- a/configure.in
+++ b/configure.in
@@ -44,5 +44,6 @@ AC_CHECK_LIB([m], [pow], [], AC_MSG_ERROR([libm is required]))
 
 AC_CONFIG_FILES([Makefile doc/Doxyfile doc/Makefile lib/Makefile
 	include/Makefile src/Makefile src/lib/Makefile man/Makefile
-	libnl-3.0.pc include/netlink/version.h])
+	libnl-3.0.pc libnl-cli-3.0.pc libnl-genl-3.0.pc libnl-nf-3.0.pc
+	libnl-route-3.0.pc include/netlink/version.h])
 AC_OUTPUT
diff --git a/libnl-cli-3.0.pc.in b/libnl-cli-3.0.pc.in
new file mode 100644
index 0000000..d456675
--- /dev/null
+++ b/libnl-cli-3.0.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-cli
+Description: Command Line Interface library for netlink sockets
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-cli
+Cflags: -I${includedir}
diff --git a/libnl-genl-3.0.pc.in b/libnl-genl-3.0.pc.in
new file mode 100644
index 0000000..4cac98b
--- /dev/null
+++ b/libnl-genl-3.0.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-genl
+Description: Generic Netlink Library
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-genl
+Cflags: -I${includedir}
diff --git a/libnl-nf-3.0.pc.in b/libnl-nf-3.0.pc.in
new file mode 100644
index 0000000..5938001
--- /dev/null
+++ b/libnl-nf-3.0.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-nf
+Description: Netfilter Netlink Library
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-nf
+Cflags: -I${includedir}
diff --git a/libnl-route-3.0.pc.in b/libnl-route-3.0.pc.in
new file mode 100644
index 0000000..d864ea1
--- /dev/null
+++ b/libnl-route-3.0.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-route
+Description: Routing Netlink Library
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-route
+Cflags: -I${includedir}
-- 
1.7.4.2



From arekm at maven.pl  Tue Mar 29 08:21:46 2011
From: arekm at maven.pl (=?UTF-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?=)
Date: Tue, 29 Mar 2011 14:21:46 +0200
Subject: [PATCH v2] Add pkgconfig files for cli/genl/nf/route libraries.
In-Reply-To: <1301399941-16224-1-git-send-email-arekm@maven.pl>
References: <1301399941-16224-1-git-send-email-arekm@maven.pl>
Message-ID: <1301401306-18151-1-git-send-email-arekm@maven.pl>

This patch adds pkgconfig (.pc) files for cli/genl/nf/route libraries
allowing to use PKG_CHECK_MODULES() m4 maco for their detection.

Signed-off-by: Arkadiusz Mi?kiwicz <arekm at maven.pl>
---

Changes:
Requires added

 Makefile.am           |    5 ++++-
 configure.in          |    3 ++-
 libnl-cli-3.0.pc.in   |   11 +++++++++++
 libnl-genl-3.0.pc.in  |   11 +++++++++++
 libnl-nf-3.0.pc.in    |   11 +++++++++++
 libnl-route-3.0.pc.in |   11 +++++++++++
 6 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 libnl-cli-3.0.pc.in
 create mode 100644 libnl-genl-3.0.pc.in
 create mode 100644 libnl-nf-3.0.pc.in
 create mode 100644 libnl-route-3.0.pc.in

diff --git a/Makefile.am b/Makefile.am
index 07017c8..6c922aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,14 +3,17 @@
 ACLOCAL_AMFLAGS = -I m4
 
 OPT_DIRS =
+PKGCONFIGS =
 
 if ENABLE_CLI
 OPT_DIRS += src
+PKGCONFIGS += libnl-cli-3.0.pc
 endif
 
 SUBDIRS = include lib doc man $(OPT_DIRS)
 
-pkgconfig_DATA = libnl-3.0.pc
+pkgconfig_DATA = libnl-3.0.pc libnl-genl-3.0.pc libnl-nf-3.0.pc \
+		 libnl-route-3.0.pc $(PKGCONFIGS)
 
 sysconfdir = @sysconfdir@/libnl
 sysconf_DATA = etc/pktloc etc/classid
diff --git a/configure.in b/configure.in
index 43150a7..b17b00c 100644
--- a/configure.in
+++ b/configure.in
@@ -44,5 +44,6 @@ AC_CHECK_LIB([m], [pow], [], AC_MSG_ERROR([libm is required]))
 
 AC_CONFIG_FILES([Makefile doc/Doxyfile doc/Makefile lib/Makefile
 	include/Makefile src/Makefile src/lib/Makefile man/Makefile
-	libnl-3.0.pc include/netlink/version.h])
+	libnl-3.0.pc libnl-cli-3.0.pc libnl-genl-3.0.pc libnl-nf-3.0.pc
+	libnl-route-3.0.pc include/netlink/version.h])
 AC_OUTPUT
diff --git a/libnl-cli-3.0.pc.in b/libnl-cli-3.0.pc.in
new file mode 100644
index 0000000..501e8ce
--- /dev/null
+++ b/libnl-cli-3.0.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-cli
+Description: Command Line Interface library for netlink sockets
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-cli
+Cflags: -I${includedir}
+Requires: libnl-3.0 libnl-genl-3.0 libnl-nf-3.0 libnl-route-3.0
diff --git a/libnl-genl-3.0.pc.in b/libnl-genl-3.0.pc.in
new file mode 100644
index 0000000..211774b
--- /dev/null
+++ b/libnl-genl-3.0.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-genl
+Description: Generic Netlink Library
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-genl
+Cflags: -I${includedir}
+Requires: libnl-3.0
diff --git a/libnl-nf-3.0.pc.in b/libnl-nf-3.0.pc.in
new file mode 100644
index 0000000..d53bddf
--- /dev/null
+++ b/libnl-nf-3.0.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-nf
+Description: Netfilter Netlink Library
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-nf
+Cflags: -I${includedir}
+Requires: libnl-3.0 libnl-route-3.0
diff --git a/libnl-route-3.0.pc.in b/libnl-route-3.0.pc.in
new file mode 100644
index 0000000..2696e63
--- /dev/null
+++ b/libnl-route-3.0.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libnl-route
+Description: Routing Netlink Library
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lnl-route
+Cflags: -I${includedir}
+Requires: libnl-3.0
-- 
1.7.4.2



From spikey.it at gmail.com  Wed Mar 30 16:53:42 2011
From: spikey.it at gmail.com (Andrea Di Pasquale)
Date: Wed, 30 Mar 2011 22:53:42 +0200
Subject: nl80211 question!
Message-ID: <AANLkTikRojv27wzijfmgo590H7+bQzdvkiGJOM=HYKwM@mail.gmail.com>

Hi guys,
nice to meet you!

I want to work into MLME MAC sublayer with linux wireless stack.
I know that with nl80211 I can to access into it by netlink sockets from
userspace.
So, my question is: does libnl offers API for this work?

Thanks,


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

From henryzhang62 at yahoo.com  Wed Mar 30 17:04:28 2011
From: henryzhang62 at yahoo.com (hong zhang)
Date: Wed, 30 Mar 2011 14:04:28 -0700 (PDT)
Subject: nl80211 question!
In-Reply-To: <AANLkTikRojv27wzijfmgo590H7+bQzdvkiGJOM=HYKwM@mail.gmail.com>
Message-ID: <319068.66882.qm@web161710.mail.bf1.yahoo.com>

Yes. iw is a new? tool for wifi.

--- On Wed, 3/30/11, Andrea Di Pasquale <spikey.it at gmail.com> wrote:


From: Andrea Di Pasquale <spikey.it at gmail.com>
Subject: nl80211 question!
To: libnl at lists.infradead.org
Date: Wednesday, March 30, 2011, 3:53 PM


Hi guys,
nice to meet you!

I want to work into MLME MAC sublayer with linux wireless stack.
I know that with nl80211 I can to access into it by netlink sockets from userspace.
So, my question is: does libnl offers API for this work?

Thanks,


spikey

-----Inline Attachment Follows-----


_______________________________________________
libnl mailing list
libnl at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/libnl



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

From spikey.it at gmail.com  Wed Mar 30 17:13:35 2011
From: spikey.it at gmail.com (Andrea Di Pasquale)
Date: Wed, 30 Mar 2011 23:13:35 +0200
Subject: nl80211 question!
In-Reply-To: <319068.66882.qm@web161710.mail.bf1.yahoo.com>
References: <AANLkTikRojv27wzijfmgo590H7+bQzdvkiGJOM=HYKwM@mail.gmail.com>
	<319068.66882.qm@web161710.mail.bf1.yahoo.com>
Message-ID: <AANLkTinujcW_ffH+0Tjhg6aPkE_4EOCnvS8kctbPeRc7@mail.gmail.com>

Ok, but can I read passively the MLM management frames (Authentication,
Deauthentication & co) ?

Thanks.


2011/3/30 hong zhang <henryzhang62 at yahoo.com>

> Yes. iw is a new  tool for wifi.
>
> --- On *Wed, 3/30/11, Andrea Di Pasquale <spikey.it at gmail.com>* wrote:
>
>
> From: Andrea Di Pasquale <spikey.it at gmail.com>
> Subject: nl80211 question!
> To: libnl at lists.infradead.org
> Date: Wednesday, March 30, 2011, 3:53 PM
>
>
> Hi guys,
> nice to meet you!
>
> I want to work into MLME MAC sublayer with linux wireless stack.
> I know that with nl80211 I can to access into it by netlink sockets from
> userspace.
> So, my question is: does libnl offers API for this work?
>
> Thanks,
>
>
> spikey
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org<http://us.mc1617.mail.yahoo.com/mc/compose?to=libnl at lists.infradead.org>
> http://lists.infradead.org/mailman/listinfo/libnl
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110330/6f4b033a/attachment.html>

From tgraf at infradead.org  Thu Mar 31 07:21:10 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 31 Mar 2011 07:21:10 -0400
Subject: nl80211 question!
In-Reply-To: <AANLkTikRojv27wzijfmgo590H7+bQzdvkiGJOM=HYKwM@mail.gmail.com>
References: <AANLkTikRojv27wzijfmgo590H7+bQzdvkiGJOM=HYKwM@mail.gmail.com>
Message-ID: <20110331112110.GA4133@canuck.infradead.org>

On Wed, Mar 30, 2011 at 10:53:42PM +0200, Andrea Di Pasquale wrote:
> nice to meet you!
> 
> I want to work into MLME MAC sublayer with linux wireless stack.
> I know that with nl80211 I can to access into it by netlink sockets from
> userspace.
> So, my question is: does libnl offers API for this work?

Although libnl currently does not provide a high level interface
for nl80211 you can use the standard generic netlink interface
in the nl-genl library to use the "nl80211" protocol.


From nsitbon at denyall.com  Thu Mar 31 07:28:28 2011
From: nsitbon at denyall.com (Sitbon Nicolas)
Date: Thu, 31 Mar 2011 13:28:28 +0200
Subject: nl80211 question!
In-Reply-To: <20110331112110.GA4133@canuck.infradead.org>
References: <AANLkTikRojv27wzijfmgo590H7+bQzdvkiGJOM=HYKwM@mail.gmail.com>
	<20110331112110.GA4133@canuck.infradead.org>
Message-ID: <4D94655C.6030200@denyall.com>

Le 31/03/2011 13:21, Thomas Graf a ?crit :
> On Wed, Mar 30, 2011 at 10:53:42PM +0200, Andrea Di Pasquale wrote:
>> nice to meet you!
>>
>> I want to work into MLME MAC sublayer with linux wireless stack.
>> I know that with nl80211 I can to access into it by netlink sockets from
>> userspace.
>> So, my question is: does libnl offers API for this work?
> Although libnl currently does not provide a high level interface
> for nl80211 you can use the standard generic netlink interface
> in the nl-genl library to use the "nl80211" protocol.
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl
Actually, the documentation recommends libnl for "wireless layer" 
handling: http://linuxwireless.org/en/developers/Documentation/nl80211 . 
<http://linuxwireless.org/en/developers/Documentation/nl80211>
regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20110331/2eef6f6a/attachment.html>

From tgraf at infradead.org  Thu Mar 31 08:46:02 2011
From: tgraf at infradead.org (Thomas Graf)
Date: Thu, 31 Mar 2011 08:46:02 -0400
Subject: New documentation style
Message-ID: <20110331124602.GB4133@canuck.infradead.org>

Hi!

I have updated the documentation of the core library to use asciidoc
which I believe will lead to better documentation in the future.

See: http://www.infradead.org/~tgr/libnl/doc-git/core.html

Any feedback from a developer POV is very much appreciated.


