Userspace tools: Roadmap?

Userspace tools: Roadmap?

[Dan E]

Looking at some of the Linux Wireless website pages it appears as though
"iw" is meant to be the successor to the older pre-mac80211 userspace
tools.  In that category we have ifconfig, iproute2, iwconfig and
iwpriv.  For an AP there's also hostapd and wpa_supplicant.  Probably
some others I've missed, not to mention Network Manager.  I can see how
configuration and setup wouldn't necessarily be limited to "iw" using
nl/cfg80211, but in the short term is that the tool of choice for
migrating the functionality of the old tools to the new mac80211
infrastructure?

Here's my situation: I'm developing a driver for an old 80211 b/g
chipset.  It's ancient by modern standards.  It operates only in the 2.4
GHz band, it doesn't have any mesh capabilities, it has a "broken"
EEPROM, it supports only single RX and TX queues, and it's an ASIC
design that doesn't use firmware.  It has no "turbo" modes.  The company
that manufactured it went bust in 2005.  It was used in a wide array of
soho routers and access points several years ago but never caught on as
a very popular" chip.

I want to write, from scratch, a mac80211 driver for this chipset using
information I've gained over the last few years from specs and reverse
engineering the binary-only driver that shipped with it (with a Linux
2.4.18 kernel).  I have the framework of the driver set up and working. 
It loads, detects and initializes the hardware on the PCI bus, reads the
hardware MAC address, sets up the TX and RX queues, and registers with
the mac80211 stack.  I see devices wmaster0 and wlan0 when I modprobe
the driver.  So far, so good.  Eventually I want to support AP and
MONITOR modes, too, but STA mode seems to be in a more advanced state
right now so I am starting with that.

Userspace tools.  I want to proceed as if Wireless Extensions never
existed.  Is that even possible?  For instance, how do I command a
channel change from userspace?  iw doesn't have that.  Should it?  Or do
I need to drop back to iwconfig?  Is iw the preferred command-line way
to do everything the old tools did, but using nl/cfg80211 instead of
ioctls?  When we get to AP mode, will hostapd be re-written to speak
nl/cfg80211, or is a new config tool needed?  The same questions apply
to wpa_supplicant.

In general, what's the way forward for new userspace tools?  nl80211 and
cfg80211 are a given, I understand that, but what's the recommended
approach from the perspective of a developer looking to make a clean
break from Wireless Extensions with a new cleanroom driver written from
scratch with no pre-existing baggage to worry about?  Start making
additions to iw's capabilities?  Adapt some other existing tool to use
nl/cfg80211, or write something completely new?

I've been following linux wireless developments since the big Summit of
'06, but this is my first attempt at jumping in.  Getting a handle on
the "big picture view" of what everything is going to look like when
mac80211 is a mature implementation is a bit difficult.  I've noticed a
lot of recent changes to the Linux Wireless website.  All good stuff but
not very comprehensive in scope.  I realize nobody likes to write
documentation :)

If somone could answer only 1 question (okay, it's a two-parter) the one
I would most like answered is this:  How does one, from userspace, ask
the driver to switch to a specific channel, and what callback(s) from
mac80211 should my driver expect to receive as a result?  I think my
driver can handle the task of changing the channel on the hardware and
manage all the housekeeping that goes along with that; I just don't get
how to issue that command from userspace.

TIA for any help, advice, pointers, flames, etc.

--
Dan

-- 
http://www.fastmail.fm - Send your email first class

Re: Userspace tools: Roadmap?

[Rami Rosen]

Hello,

> will hostapd be re-written to speak
> nl/cfg80211, or is a new config tool needed?

  Just one little thing, regarding hostapd:

You can use hostapd with nl80211.

Adding this entry:
 driver=nl8021
to hostapd.conf will cause it to work with nl80211 API
(driver_nl80211.c)

You should also build hostapd with
CONFIG_DRIVER_NL80211 set in the Makefile.

This is a known way to work with hostapd and master mode; see for example,
http://acx100.erley.org/nl80211_master_mode.html

(BTW, I am using the latest git of hostapd, but it could be relevant
also for older versions).

Regarding iw:  I think that adding support for changing
channel in iw is possible and that there is no inherent reason not to
do so. Are there any other things you should do with iw which do not
exist (and exist with iwcofig) ?

Regards,
Rami Rosen





On Mon, Dec 8, 2008 at 1:29 AM, Dan E <trg_info@mailhaven.com> wrote:
> Looking at some of the Linux Wireless website pages it appears as though
> "iw" is meant to be the successor to the older pre-mac80211 userspace
> tools.  In that category we have ifconfig, iproute2, iwconfig and
> iwpriv.  For an AP there's also hostapd and wpa_supplicant.  Probably
> some others I've missed, not to mention Network Manager.  I can see how
> configuration and setup wouldn't necessarily be limited to "iw" using
> nl/cfg80211, but in the short term is that the tool of choice for
> migrating the functionality of the old tools to the new mac80211
> infrastructure?
>
> Here's my situation: I'm developing a driver for an old 80211 b/g
> chipset.  It's ancient by modern standards.  It operates only in the 2.4
> GHz band, it doesn't have any mesh capabilities, it has a "broken"
> EEPROM, it supports only single RX and TX queues, and it's an ASIC
> design that doesn't use firmware.  It has no "turbo" modes.  The company
> that manufactured it went bust in 2005.  It was used in a wide array of
> soho routers and access points several years ago but never caught on as
> a very popular" chip.
>
> I want to write, from scratch, a mac80211 driver for this chipset using
> information I've gained over the last few years from specs and reverse
> engineering the binary-only driver that shipped with it (with a Linux
> 2.4.18 kernel).  I have the framework of the driver set up and working.
> It loads, detects and initializes the hardware on the PCI bus, reads the
> hardware MAC address, sets up the TX and RX queues, and registers with
> the mac80211 stack.  I see devices wmaster0 and wlan0 when I modprobe
> the driver.  So far, so good.  Eventually I want to support AP and
> MONITOR modes, too, but STA mode seems to be in a more advanced state
> right now so I am starting with that.
>
> Userspace tools.  I want to proceed as if Wireless Extensions never
> existed.  Is that even possible?  For instance, how do I command a
> channel change from userspace?  iw doesn't have that.  Should it?  Or do
> I need to drop back to iwconfig?  Is iw the preferred command-line way
> to do everything the old tools did, but using nl/cfg80211 instead of
> ioctls?  When we get to AP mode, will hostapd be re-written to speak
> nl/cfg80211, or is a new config tool needed?  The same questions apply
> to wpa_supplicant.
>
> In general, what's the way forward for new userspace tools?  nl80211 and
> cfg80211 are a given, I understand that, but what's the recommended
> approach from the perspective of a developer looking to make a clean
> break from Wireless Extensions with a new cleanroom driver written from
> scratch with no pre-existing baggage to worry about?  Start making
> additions to iw's capabilities?  Adapt some other existing tool to use
> nl/cfg80211, or write something completely new?
>
> I've been following linux wireless developments since the big Summit of
> '06, but this is my first attempt at jumping in.  Getting a handle on
> the "big picture view" of what everything is going to look like when
> mac80211 is a mature implementation is a bit difficult.  I've noticed a
> lot of recent changes to the Linux Wireless website.  All good stuff but
> not very comprehensive in scope.  I realize nobody likes to write
> documentation :)
>
> If somone could answer only 1 question (okay, it's a two-parter) the one
> I would most like answered is this:  How does one, from userspace, ask
> the driver to switch to a specific channel, and what callback(s) from
> mac80211 should my driver expect to receive as a result?  I think my
> driver can handle the task of changing the channel on the hardware and
> manage all the housekeeping that goes along with that; I just don't get
> how to issue that command from userspace.
>
> TIA for any help, advice, pointers, flames, etc.
>
> --
> Dan
>
> --
> http://www.fastmail.fm - Send your email first class
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

On Sun, 2008-12-07 at 18:29 -0500, Dan E wrote:
> Looking at some of the Linux Wireless website pages it appears as though
> "iw" is meant to be the successor to the older pre-mac80211 userspace
> tools.  In that category we have ifconfig, iproute2, iwconfig and
> iwpriv.  For an AP there's also hostapd and wpa_supplicant.  Probably
> some others I've missed, not to mention Network Manager.  I can see how
> configuration and setup wouldn't necessarily be limited to "iw" using
> nl/cfg80211, but in the short term is that the tool of choice for
> migrating the functionality of the old tools to the new mac80211
> infrastructure?

Not really, in the short term, you still are using iwconfig (wireless
extensions) with anything but hostapd.

> Here's my situation: [snip]

nice

> Userspace tools.  I want to proceed as if Wireless Extensions never
> existed.  Is that even possible?

No, it's not.

>   For instance, how do I command a
> channel change from userspace?  iw doesn't have that.  Should it?

Yes, it should, and nl80211 even supports it, but iw itself doesn't yet.
That's fairly easy to fix, too, but then iw won't support actually
telling mac80211 to scan and associate etc.

> Or do
> I need to drop back to iwconfig?  

For now.

> Is iw the preferred command-line way
> to do everything the old tools did, but using nl/cfg80211 instead of
> ioctls?

Not _yet_.

>   When we get to AP mode, will hostapd be re-written to speak
> nl/cfg80211, or is a new config tool needed?  The same questions apply
> to wpa_supplicant.

That's already been done. The plan is to keep wext compatibility around
though, obviously, so iwconfig will work in the foreseeable future.

> In general, what's the way forward for new userspace tools?  nl80211 and
> cfg80211 are a given, I understand that, but what's the recommended
> approach from the perspective of a developer looking to make a clean
> break from Wireless Extensions with a new cleanroom driver written from
> scratch with no pre-existing baggage to worry about?  Start making
> additions to iw's capabilities?  Adapt some other existing tool to use
> nl/cfg80211, or write something completely new?

If you're writing a mac80211-based driver, there's no point where you
could possibly get in touch with the userspace API. You're writing the
driver completely to mac80211's internal driver API, and mac80211
completely shields you from the userspace API. You'll never interact
with either wireless extensions or nl80211.

> If somone could answer only 1 question (okay, it's a two-parter) the one
> I would most like answered is this:  How does one, from userspace, ask
> the driver to switch to a specific channel, and what callback(s) from
> mac80211 should my driver expect to receive as a result?  

iwconfig wlan0 channel 7

then mac80211 calls your _ops->config() with the channel flag. Have you
looked at the mac80211 book and the other documentation on
http://wireless.kernel.org/?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[Dan E]

On Mon, 08 Dec 2008 09:13:13 +0100, "Johannes Berg"
<johannes@sipsolutions.net> said:
> 
> Not really, in the short term, you still are using iwconfig (wireless
> extensions) with anything but hostapd.

Ugh.  I was afraid you were going to say that.

> > Userspace tools.  I want to proceed as if Wireless Extensions never
> > existed.  Is that even possible?
> 
> No, it's not.

My fault for assuming too much about the urgency to get away from WE.

> Yes, it should, and nl80211 even supports it, but iw itself doesn't yet.
> That's fairly easy to fix, too, but then iw won't support actually
> telling mac80211 to scan and associate etc.

Right.  I had a few early problems with iw.  For instance, the Linux
Wireless web pages say you need "at least" libnl-1.0-pre8, but it won't
build with libnl-1.2 or 2.0.  I had to go with libnl-1.1 to make it
happy.  iw seems to be like a redheaded stepchild.

> If you're writing a mac80211-based driver, there's no point where you
> could possibly get in touch with the userspace API. You're writing the
> driver completely to mac80211's internal driver API, and mac80211
> completely shields you from the userspace API. You'll never interact
> with either wireless extensions or nl80211.
> 
> > If somone could answer only 1 question (okay, it's a two-parter) the one
> > I would most like answered is this:  How does one, from userspace, ask
> > the driver to switch to a specific channel, and what callback(s) from
> > mac80211 should my driver expect to receive as a result?  
> 
> iwconfig wlan0 channel 7
> 
> then mac80211 calls your _ops->config() with the channel flag. Have you
> looked at the mac80211 book and the other documentation on
> http://wireless.kernel.org/?

That's what I thought but I wasn't seeing any callbacks at all through
my ieee80211_ops pointers.  I did see the channel frequency change with
'iwconfig wlan0', but no callbacks.  My fault, again, for not RTFM.  I
haven't gotten to the point yet on my driver where I expect 'ip link set
up dev wlan0' (or 'ifconfig wlan0 up', if you prefer) and now I see
that's why the config callback never happened.  If I had RTFM I might
have noticed adding 'commit' at the end of the iwconfig command would
have done it without the 'up'.

Thanks for the info, Johannes.  It answers a lot of my questions.

--
Dan

-- 
http://www.fastmail.fm - Access your email from home and the web

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

On Mon, 2008-12-08 at 18:18 -0500, Dan E wrote:

> > > Userspace tools.  I want to proceed as if Wireless Extensions never
> > > existed.  Is that even possible?
> > 
> > No, it's not.
> 
> My fault for assuming too much about the urgency to get away from WE.

Well, nobody seems to really want to work on replacing already working
features... I have a patch for scanning with iw though.

> > Yes, it should, and nl80211 even supports it, but iw itself doesn't yet.
> > That's fairly easy to fix, too, but then iw won't support actually
> > telling mac80211 to scan and associate etc.
> 
> Right.  I had a few early problems with iw.  For instance, the Linux
> Wireless web pages say you need "at least" libnl-1.0-pre8, but it won't
> build with libnl-1.2 or 2.0.  I had to go with libnl-1.1 to make it
> happy.  iw seems to be like a redheaded stepchild.

There's libnl 1.2 and 2.0? That's news to me! Patches welcome. Sorry, I
guess it needs 1.0 or 1.1, will fix the page.

> That's what I thought but I wasn't seeing any callbacks at all through
> my ieee80211_ops pointers.  I did see the channel frequency change with
> 'iwconfig wlan0', but no callbacks.  My fault, again, for not RTFM.  I
> haven't gotten to the point yet on my driver where I expect 'ip link set
> up dev wlan0' (or 'ifconfig wlan0 up', if you prefer) and now I see
> that's why the config callback never happened.  

Ah. Yes, if the hw isn't started mac80211 won't try to configure it :)

> If I had RTFM I might
> have noticed adding 'commit' at the end of the iwconfig command would
> have done it without the 'up'.

No, it wouldn't, commit is pointless, don't worry about it, you'll never
need to use it with mac80211.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[pat-lkml]

Johannes Berg wrote:
> On Mon, 2008-12-08 at 18:18 -0500, Dan E wrote:
> There's libnl 1.2 and 2.0? That's news to me! Patches welcome. Sorry, I
> guess it needs 1.0 or 1.1, will fix the page.
> 
following is a patch that gets iw working with the development versions
of libnl.  I keep it uptodate at: http://wireless.erley.org/

The Makefile changes may not be the 'best' way to do it, but it works
for me.

Pat Erley

---

diff --git a/Makefile b/Makefile
index df59b51..1bc8310 100644
--- a/Makefile
+++ b/Makefile
@@ -10,10 +10,11 @@ MKDIR ?= mkdir -p
 INSTALL ?= install
 CC ?= "gcc"

-CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
`pkg-config --cflags libnl-1`
+NLVERSION = 2.0
+CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
`pkg-config --cflags libnl-$(NLVERSION)`
 CFLAGS += -O2 -g
-LDFLAGS += `pkg-config --libs libnl-1`
-NLVERSION = 1.0
+LDFLAGS += `pkg-config --libs libnl-$(NLVERSION)`
+LIBS += -lnl -lnl-genl -lnl-nf -lnl-route

 OBJS = iw.o info.o phy.o interface.o station.o util.o mpath.o reg.o
mesh.o genl.o
 ALL = iw
@@ -29,7 +30,7 @@ endif
 all: version_check $(ALL)

 version_check:
-	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-1; then echo
"You need at least libnl version $(NLVERSION)"; exit 1; fi
+	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-$(NLVERSION);
then echo "You need at least libnl version $(NLVERSION)"; exit 1; fi


 version.h: version.sh
@@ -42,7 +43,7 @@ version.h: version.sh

 iw:	$(OBJS)
 	@$(NQ) ' CC  ' iw
-	$(Q)$(CC) $(LDFLAGS) $(OBJS) -o iw
+	$(Q)$(CC) $(LDFLAGS) $(OBJS) $(LIBS) -o iw

 check:
 	$(Q)$(MAKE) all CC="REAL_CC=$(CC) CHECK=\"sparse -Wall\" cgcc"
diff --git a/iw.c b/iw.c
index 5859180..11af7d6 100644
--- a/iw.c
+++ b/iw.c
@@ -29,7 +29,7 @@ static int nl80211_init(struct nl80211_state *state)
 {
 	int err;

-	state->nl_handle = nl_handle_alloc();
+	state->nl_handle = nl_socket_alloc();
 	if (!state->nl_handle) {
 		fprintf(stderr, "Failed to allocate netlink handle.\n");
 		return -ENOMEM;
@@ -41,8 +41,7 @@ static int nl80211_init(struct nl80211_state *state)
 		goto out_handle_destroy;
 	}

-	state->nl_cache = genl_ctrl_alloc_cache(state->nl_handle);
-	if (!state->nl_cache) {
+	if (genl_ctrl_alloc_cache(state->nl_handle, &(state->nl_cache))) {
 		fprintf(stderr, "Failed to allocate generic netlink cache.\n");
 		err = -ENOMEM;
 		goto out_handle_destroy;
@@ -60,7 +59,7 @@ static int nl80211_init(struct nl80211_state *state)
  out_cache_free:
 	nl_cache_free(state->nl_cache);
  out_handle_destroy:
-	nl_handle_destroy(state->nl_handle);
+	nl_socket_free(state->nl_handle);
 	return err;
 }

@@ -68,7 +67,7 @@ static void nl80211_cleanup(struct nl80211_state *state)
 {
 	genl_family_put(state->nl80211);
 	nl_cache_free(state->nl_cache);
-	nl_handle_destroy(state->nl_handle);
+	nl_socket_free(state->nl_handle);
 }

 __COMMAND(NULL, NULL, NULL, 0, 0, 0, CIB_NONE, NULL);

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Mon, 2008-12-08 at 18:52 -0500, pat-lkml wrote:
> Johannes Berg wrote:
> > On Mon, 2008-12-08 at 18:18 -0500, Dan E wrote:
> > There's libnl 1.2 and 2.0? That's news to me! Patches welcome. Sorry, I
> > guess it needs 1.0 or 1.1, will fix the page.
> > 
> following is a patch that gets iw working with the development versions
> of libnl.  I keep it uptodate at: http://wireless.erley.org/
> 
> The Makefile changes may not be the 'best' way to do it, but it works
> for me.

Thanks, I think you even sent me that once before already, but that
breaks with distro versions of libnl. I guess distros will end up
shipping 1.1 as libnl1 like debian does for a while?

Is there any particular reason you need libnl from git? You could just
check out 1.1, no?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[pat-lkml]

Johannes Berg wrote:
> On Mon, 2008-12-08 at 18:52 -0500, pat-lkml wrote:
>> Johannes Berg wrote:
>>> On Mon, 2008-12-08 at 18:18 -0500, Dan E wrote:
>>> There's libnl 1.2 and 2.0? That's news to me! Patches welcome. Sorry, I
>>> guess it needs 1.0 or 1.1, will fix the page.
>>>
>> following is a patch that gets iw working with the development versions
>> of libnl.  I keep it uptodate at: http://wireless.erley.org/
>>
>> The Makefile changes may not be the 'best' way to do it, but it works
>> for me.
> 
> Thanks, I think you even sent me that once before already, but that
> breaks with distro versions of libnl. I guess distros will end up
> shipping 1.1 as libnl1 like debian does for a while?
> 
> Is there any particular reason you need libnl from git? You could just
> check out 1.1, no?
The reason I'm using git for everything in there is just because I have
it working.  Once master mode is in a released mainline, and stable
packages are released for all of the packages involved, I'll take the
time to revise a new copy of the document that links to 'good' versions,
and get it hosted on something more capable/dependable than my home dsl
line.  Also, someone else may have pushed a similar patch to you, as I
have not sent one upstream.

As far as distros bundling libnl, I know gentoo is shipping 1.1, and am
guessing it will be the version standardized on.

Pat

Re: Userspace tools: Roadmap?

[pat-lkml]

Attached is a newer 'better' version based off of how hostapd is
handling this.  This patch adds an option, CONFIG_LIBNL20, which enables
LIBNL20 compatibility.  I haven't ever been able to get iw to build with
libnl-1.0 or libnl-1.1 on my system, so I haven't been able to test
that, but it should work.

Signed-off-by: Pat Erley <pat-lkml@erley.org>

---
diff --git a/Makefile b/Makefile
index df59b51..a10f72f 100644
--- a/Makefile
+++ b/Makefile
@@ -10,14 +10,25 @@ MKDIR ?= mkdir -p
 INSTALL ?= install
 CC ?= "gcc"

-CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
`pkg-config --cflags libnl-1`
+CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
 CFLAGS += -O2 -g
-LDFLAGS += `pkg-config --libs libnl-1`
-NLVERSION = 1.0
+NLVERSION = 2.0

 OBJS = iw.o info.o phy.o interface.o station.o util.o mpath.o reg.o
mesh.o genl.o
 ALL = iw

+ifeq ($(NLVERSION), 2.0)
+CFLAGS += `pkg-config --cflags libnl-2.0` -DCONFIG_LIBNL20
+LDFLAGS += `pkg-config --libs libnl-2.0`
+LIBS += -lnl -lnl-genl -lnl-nf -lnl-route
+NLTESTVERSION = 2.0
+else
+CFLAGS += `pkg-config --cflags libnl-1`
+LDFLAGS += `pkg-config --libs libnl-1.0`
+LIBS += -lnl
+NLTESTVERSION = 1
+endif
+
 ifeq ($(V),1)
 Q=
 NQ=true
@@ -29,7 +40,7 @@ endif
 all: version_check $(ALL)

 version_check:
-	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-1; then echo
"You need at least libnl version $(NLVERSION)"; exit 1; fi
+	@if ! pkg-config --atleast-version=$(NLVERSION)
libnl-$(NLTESTVERSION); then echo "You need at least libnl version
$(NLVERSION)"; exit 1; fi


 version.h: version.sh
@@ -42,7 +53,7 @@ version.h: version.sh

 iw:	$(OBJS)
 	@$(NQ) ' CC  ' iw
-	$(Q)$(CC) $(LDFLAGS) $(OBJS) -o iw
+	$(Q)$(CC) $(LDFLAGS) $(OBJS) $(LIBS) -o iw

 check:
 	$(Q)$(MAKE) all CC="REAL_CC=$(CC) CHECK=\"sparse -Wall\" cgcc"
diff --git a/iw.c b/iw.c
index afae643..7038973 100644
--- a/iw.c
+++ b/iw.c
@@ -23,6 +23,13 @@
 #include "iw.h"
 #include "version.h"

+#ifdef CONFIG_LIBNL20
+/* libnl 2.0 compatibility code */
+#define nl_handle_alloc_cb nl_socket_alloc_cb
+#define nl_handle_alloc nl_socket_alloc
+#define nl_handle_destroy nl_socket_free
+#endif /* CONFIG_LIBNL20 */
+
 static int debug = 0;

 static int nl80211_init(struct nl80211_state *state)
@@ -40,9 +47,12 @@ static int nl80211_init(struct nl80211_state *state)
 		err = -ENOLINK;
 		goto out_handle_destroy;
 	}
-
+#ifdef CONFIG_LIBNL20
+	if (genl_ctrl_alloc_cache(state->nl_handle, &(state->nl_cache))) {
+#else
 	state->nl_cache = genl_ctrl_alloc_cache(state->nl_handle);
 	if (!state->nl_cache) {
+#endif
 		fprintf(stderr, "Failed to allocate generic netlink cache.\n");
 		err = -ENOMEM;
 		goto out_handle_destroy;

Re: Userspace tools: Roadmap?

[Pavel Roskin]

On Thu, 2008-12-11 at 23:58 -0500, pat-lkml wrote:
> Attached is a newer 'better' version based off of how hostapd is
> handling this.  This patch adds an option, CONFIG_LIBNL20, which enables
> LIBNL20 compatibility.  I haven't ever been able to get iw to build with
> libnl-1.0 or libnl-1.1 on my system, so I haven't been able to test
> that, but it should work.
...
> +ifeq ($(NLVERSION), 2.0)
> +CFLAGS += `pkg-config --cflags libnl-2.0` -DCONFIG_LIBNL20
> +LDFLAGS += `pkg-config --libs libnl-2.0`
> +LIBS += -lnl -lnl-genl -lnl-nf -lnl-route
> +NLTESTVERSION = 2.0
> +else
> +CFLAGS += `pkg-config --cflags libnl-1`
> +LDFLAGS += `pkg-config --libs libnl-1.0`

I think you mean "libnl-1" without ".0" here.

> +LIBS += -lnl
> +NLTESTVERSION = 1
> +endif

It would be better to have a variable for pkg-config name of the
library, that is "libnl-1" or "libnl-2.0".

LDCONFIG and LIBS could both be derived from pkg-config by using
--libs-only-l, --libs-only-other and --libs-only-L.  --libs-only-l goes
to LIBS, --libs-only-L goes to LDFLAGS and I guess --libs-only-other
could go to LDFLAGS as well.

>  version_check:
> -	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-1; then echo
> "You need at least libnl version $(NLVERSION)"; exit 1; fi
> +	@if ! pkg-config --atleast-version=$(NLVERSION)
> libnl-$(NLTESTVERSION); then echo "You need at least libnl version
> $(NLVERSION)"; exit 1; fi

I would consider autodetection for libnl version here if it's not too
hard.

> +#ifdef CONFIG_LIBNL20
> +/* libnl 2.0 compatibility code */
> +#define nl_handle_alloc_cb nl_socket_alloc_cb
> +#define nl_handle_alloc nl_socket_alloc
> +#define nl_handle_destroy nl_socket_free
> +#endif /* CONFIG_LIBNL20 */

Please use macros with arguments to ensure their correct number.

>From my experience with external Linux drivers (MadWifi in particular),
it's easier to follow the current API and provide compatibility for the
old API, not the other way around.  This way, it's easier to track
further API changes.  Also, the new API is usually easier to understand.

> +#ifdef CONFIG_LIBNL20
> +	if (genl_ctrl_alloc_cache(state->nl_handle, &(state->nl_cache))) {
> +#else
>  	state->nl_cache = genl_ctrl_alloc_cache(state->nl_handle);
>  	if (!state->nl_cache) {
> +#endif

Perhaps you could provide a compatibility genl_ctrl_alloc_cache() macro
for libnl1 and avoid this ifdef?

-- 
Regards,
Pavel Roskin

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 107 bytes --]

Thanks for the review, Pavel.

I agree with all you've said, Pat, care to make a new patch?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[pat-lkml]

Johannes Berg wrote:
> Thanks for the review, Pavel.
> 
> I agree with all you've said, Pat, care to make a new patch?
> 
> johannes

Pavel reviewed a newer version for me while I was at work today.  I
didn't post it to the list as I didn't have access to this account.  I'm
going to implement the new set of changes and try to submit a new patch
some time tonight.  One question, is it preferred to make the code use
the new API and add compatibility to make it use the old API, or vice
versa?  I've written a function that uses the new
genl_ctrl_alloc_cache(arg1, &arg2) syntax wrapped in the old arg2 =
genl_ctrl_alloc_cache(arg1) syntax already, but based on Pavel's
suggestions, it seems it's preferred to go the other way?

Pat

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On Fri, 2008-12-12 at 17:37 -0500, pat-lkml wrote:
> Johannes Berg wrote:
> > Thanks for the review, Pavel.
> > 
> > I agree with all you've said, Pat, care to make a new patch?
> > 
> > johannes
> 
> Pavel reviewed a newer version for me while I was at work today.  I
> didn't post it to the list as I didn't have access to this account.  I'm
> going to implement the new set of changes and try to submit a new patch
> some time tonight.  One question, is it preferred to make the code use
> the new API and add compatibility to make it use the old API, or vice
> versa?  I've written a function that uses the new
> genl_ctrl_alloc_cache(arg1, &arg2) syntax wrapped in the old arg2 =
> genl_ctrl_alloc_cache(arg1) syntax already, but based on Pavel's
> suggestions, it seems it's preferred to go the other way?

I think I'd prefer using the new version as well, even though then you
have to make up a bogus return value, but it seems easier just so we can
at some point just remove the compat code for the old version. Maybe.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[pat-lkml]

This converts iw to use libnl-2, and adds compatibility with libnl-1.
There is not currently a good way to detect the libnl version during
compilation, as the versioning in the netlink/version.h is defined as a
string "2.0" rather than a major and a minor number, so we must detect
it in the Makefile.

Signed-off-by: Pat Erley <pat-lkml@erley.org>

---

I'm still not very familiar with Makefile magic, so if there's a better
way to do what I'm doing in the Makefile, just let me know.  Also, I'm
preparing a similar patch for crda.

---

diff --git a/Makefile b/Makefile
index df59b51..a87e9a0 100644
--- a/Makefile
+++ b/Makefile
@@ -10,14 +10,28 @@ MKDIR ?= mkdir -p
 INSTALL ?= install
 CC ?= "gcc"

-CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
`pkg-config --cflags libnl-1`
+CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
 CFLAGS += -O2 -g
-LDFLAGS += `pkg-config --libs libnl-1`
-NLVERSION = 1.0

 OBJS = iw.o info.o phy.o interface.o station.o util.o mpath.o reg.o
mesh.o genl.o
 ALL = iw

+NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
+NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
+
+ifeq ($(NL1FOUND),Y)
+NLLIBNAME = libnl-1
+endif
+
+ifeq ($(NL2FOUND),Y)
+CFLAGS += -DCONFIG_LIBNL20
+LIBS += -lnl-genl
+NLLIBNAME = libnl-2.0
+endif
+
+LDFLAGS += `pkg-config --libs $(NLLIBNAME)`
+CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
+
 ifeq ($(V),1)
 Q=
 NQ=true
@@ -29,8 +43,15 @@ endif
 all: version_check $(ALL)

 version_check:
-	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-1; then echo
"You need at least libnl version $(NLVERSION)"; exit 1; fi
-
+ifeq ($(NL2FOUND),Y)
+	@echo "Found libnl-2.0"
+else
+ifeq ($(NL1FOUND),Y)
+        @echo "Found libnl-1"
+else
+	$(error No libnl found)
+endif
+endif

 version.h: version.sh
 	@$(NQ) ' GEN  version.h'
@@ -42,7 +63,7 @@ version.h: version.sh

 iw:	$(OBJS)
 	@$(NQ) ' CC  ' iw
-	$(Q)$(CC) $(LDFLAGS) $(OBJS) -o iw
+	$(Q)$(CC) $(LDFLAGS) $(OBJS) $(LIBS) -o iw

 check:
 	$(Q)$(MAKE) all CC="REAL_CC=$(CC) CHECK=\"sparse -Wall\" cgcc"
diff --git a/iw.c b/iw.c
index afae643..03ffbb9 100644
--- a/iw.c
+++ b/iw.c
@@ -23,13 +23,24 @@
 #include "iw.h"
 #include "version.h"

+#ifndef CONFIG_LIBNL20
+/* libnl 2.0 compatibility code */
+
+#define nl_socket_alloc(_h) nl_handle_alloc(_h)
+#define nl_socket_free(_h)  nl_handle_destroy(_h)
+#define compat_genl_ctrl_alloc_cache(_nl_handle, _nl_cache) \
+        return (_nl_cache = genl_ctrl_alloc_cache(_nl_handle)) == null
+
+#define genl_ctrl_alloc_cache(_h) compat_genl_ctrl_alloc_cache(_h)
+#endif /* CONFIG_LIBNL20 */
+
 static int debug = 0;

 static int nl80211_init(struct nl80211_state *state)
 {
 	int err;

-	state->nl_handle = nl_handle_alloc();
+	state->nl_handle = nl_socket_alloc();
 	if (!state->nl_handle) {
 		fprintf(stderr, "Failed to allocate netlink handle.\n");
 		return -ENOMEM;
@@ -41,8 +52,7 @@ static int nl80211_init(struct nl80211_state *state)
 		goto out_handle_destroy;
 	}

-	state->nl_cache = genl_ctrl_alloc_cache(state->nl_handle);
-	if (!state->nl_cache) {
+	if (genl_ctrl_alloc_cache(state->nl_handle, &(state->nl_cache))) {
 		fprintf(stderr, "Failed to allocate generic netlink cache.\n");
 		err = -ENOMEM;
 		goto out_handle_destroy;
@@ -60,7 +70,7 @@ static int nl80211_init(struct nl80211_state *state)
  out_cache_free:
 	nl_cache_free(state->nl_cache);
  out_handle_destroy:
-	nl_handle_destroy(state->nl_handle);
+	nl_socket_free(state->nl_handle);
 	return err;
 }

@@ -68,7 +78,7 @@ static void nl80211_cleanup(struct nl80211_state *state)
 {
 	genl_family_put(state->nl80211);
 	nl_cache_free(state->nl_cache);
-	nl_handle_destroy(state->nl_handle);
+	nl_socket_free(state->nl_handle);
 }

 __COMMAND(NULL, NULL, NULL, 0, 0, 0, CIB_NONE, NULL);

Re: Userspace tools: Roadmap?

[pat-lkml]

Crap, please ignore, attached the wrong patch.

pat-lkml wrote:
> This converts iw to use libnl-2, and adds compatibility with libnl-1.
> There is not currently a good way to detect the libnl version during
> compilation, as the versioning in the netlink/version.h is defined as a
> string "2.0" rather than a major and a minor number, so we must detect
> it in the Makefile.
> 
> Signed-off-by: Pat Erley <pat-lkml@erley.org>
> 
> ---
> 
> I'm still not very familiar with Makefile magic, so if there's a better
> way to do what I'm doing in the Makefile, just let me know.  Also, I'm
> preparing a similar patch for crda.
> 
> ---
> 
> diff --git a/Makefile b/Makefile
> index df59b51..a87e9a0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -10,14 +10,28 @@ MKDIR ?= mkdir -p
>  INSTALL ?= install
>  CC ?= "gcc"
> 
> -CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
> -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
> `pkg-config --cflags libnl-1`
> +CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
> -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
>  CFLAGS += -O2 -g
> -LDFLAGS += `pkg-config --libs libnl-1`
> -NLVERSION = 1.0
> 
>  OBJS = iw.o info.o phy.o interface.o station.o util.o mpath.o reg.o
> mesh.o genl.o
>  ALL = iw
> 
> +NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
> +NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
> +
> +ifeq ($(NL1FOUND),Y)
> +NLLIBNAME = libnl-1
> +endif
> +
> +ifeq ($(NL2FOUND),Y)
> +CFLAGS += -DCONFIG_LIBNL20
> +LIBS += -lnl-genl
> +NLLIBNAME = libnl-2.0
> +endif
> +
> +LDFLAGS += `pkg-config --libs $(NLLIBNAME)`
> +CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
> +
>  ifeq ($(V),1)
>  Q=
>  NQ=true
> @@ -29,8 +43,15 @@ endif
>  all: version_check $(ALL)
> 
>  version_check:
> -	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-1; then echo
> "You need at least libnl version $(NLVERSION)"; exit 1; fi
> -
> +ifeq ($(NL2FOUND),Y)
> +	@echo "Found libnl-2.0"
> +else
> +ifeq ($(NL1FOUND),Y)
> +        @echo "Found libnl-1"
> +else
> +	$(error No libnl found)
> +endif
> +endif
> 
>  version.h: version.sh
>  	@$(NQ) ' GEN  version.h'
> @@ -42,7 +63,7 @@ version.h: version.sh
> 
>  iw:	$(OBJS)
>  	@$(NQ) ' CC  ' iw
> -	$(Q)$(CC) $(LDFLAGS) $(OBJS) -o iw
> +	$(Q)$(CC) $(LDFLAGS) $(OBJS) $(LIBS) -o iw
> 
>  check:
>  	$(Q)$(MAKE) all CC="REAL_CC=$(CC) CHECK=\"sparse -Wall\" cgcc"
> diff --git a/iw.c b/iw.c
> index afae643..03ffbb9 100644
> --- a/iw.c
> +++ b/iw.c
> @@ -23,13 +23,24 @@
>  #include "iw.h"
>  #include "version.h"
> 
> +#ifndef CONFIG_LIBNL20
> +/* libnl 2.0 compatibility code */
> +
> +#define nl_socket_alloc(_h) nl_handle_alloc(_h)
> +#define nl_socket_free(_h)  nl_handle_destroy(_h)
> +#define compat_genl_ctrl_alloc_cache(_nl_handle, _nl_cache) \
> +        return (_nl_cache = genl_ctrl_alloc_cache(_nl_handle)) == null
> +
> +#define genl_ctrl_alloc_cache(_h) compat_genl_ctrl_alloc_cache(_h)
> +#endif /* CONFIG_LIBNL20 */
> +
>  static int debug = 0;
> 
>  static int nl80211_init(struct nl80211_state *state)
>  {
>  	int err;
> 
> -	state->nl_handle = nl_handle_alloc();
> +	state->nl_handle = nl_socket_alloc();
>  	if (!state->nl_handle) {
>  		fprintf(stderr, "Failed to allocate netlink handle.\n");
>  		return -ENOMEM;
> @@ -41,8 +52,7 @@ static int nl80211_init(struct nl80211_state *state)
>  		goto out_handle_destroy;
>  	}
> 
> -	state->nl_cache = genl_ctrl_alloc_cache(state->nl_handle);
> -	if (!state->nl_cache) {
> +	if (genl_ctrl_alloc_cache(state->nl_handle, &(state->nl_cache))) {
>  		fprintf(stderr, "Failed to allocate generic netlink cache.\n");
>  		err = -ENOMEM;
>  		goto out_handle_destroy;
> @@ -60,7 +70,7 @@ static int nl80211_init(struct nl80211_state *state)
>   out_cache_free:
>  	nl_cache_free(state->nl_cache);
>   out_handle_destroy:
> -	nl_handle_destroy(state->nl_handle);
> +	nl_socket_free(state->nl_handle);
>  	return err;
>  }
> 
> @@ -68,7 +78,7 @@ static void nl80211_cleanup(struct nl80211_state *state)
>  {
>  	genl_family_put(state->nl80211);
>  	nl_cache_free(state->nl_cache);
> -	nl_handle_destroy(state->nl_handle);
> +	nl_socket_free(state->nl_handle);
>  }
> 
>  __COMMAND(NULL, NULL, NULL, 0, 0, 0, CIB_NONE, NULL);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

On Fri, 2008-12-12 at 18:42 -0500, pat-lkml wrote:
> Crap, please ignore, attached the wrong patch.

That looked pretty good to me, except that it's on top of your previous
patch. :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[pat-lkml]

This converts iw to use libnl-2, and adds compatibility with libnl-1.
There is not currently a good way to detect the libnl version during
compilation, as the versioning in the netlink/version.h is defined as a
string "2.0" rather than a major and a minor number, so we must detect
it in the Makefile.

Signed-off-by: Pat Erley <pat-lkml@erley.org>

---

I'm still not very familiar with Makefile magic, so if there's a better
way to do what I'm doing in the Makefile, just let me know.  Also, I'm
preparing a similar patch for crda.  I'm not 100% certain on the
libnl-1.1 compatibility part as I can't get iw to build with libnl-1.1
on my system.  However, with and without this patch error out in an
identical manner

---

diff --git a/Makefile b/Makefile
index df59b51..5b359f3 100644
--- a/Makefile
+++ b/Makefile
@@ -10,14 +10,28 @@ MKDIR ?= mkdir -p
 INSTALL ?= install
 CC ?= "gcc"

-CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
`pkg-config --cflags libnl-1`
+CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
 CFLAGS += -O2 -g
-LDFLAGS += `pkg-config --libs libnl-1`
-NLVERSION = 1.0

 OBJS = iw.o info.o phy.o interface.o station.o util.o mpath.o reg.o
mesh.o genl.o
 ALL = iw

+NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
+NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
+
+ifeq ($(NL1FOUND),Y)
+NLLIBNAME = libnl-1
+endif
+
+ifeq ($(NL2FOUND),Y)
+CFLAGS += -DCONFIG_LIBNL20
+LIBS += -lnl-genl
+NLLIBNAME = libnl-2.0
+endif
+
+LDFLAGS += `pkg-config --libs $(NLLIBNAME)`
+CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
+
 ifeq ($(V),1)
 Q=
 NQ=true
@@ -29,8 +43,15 @@ endif
 all: version_check $(ALL)

 version_check:
-	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-1; then echo
"You need at least libnl version $(NLVERSION)"; exit 1; fi
-
+ifeq ($(NL2FOUND),Y)
+	@echo "Found libnl-2.0"
+else
+ifeq ($(NL1FOUND),Y)
+	@echo "Found libnl-1"
+else
+	$(error No libnl found)
+endif
+endif

 version.h: version.sh
 	@$(NQ) ' GEN  version.h'
@@ -42,7 +63,7 @@ version.h: version.sh

 iw:	$(OBJS)
 	@$(NQ) ' CC  ' iw
-	$(Q)$(CC) $(LDFLAGS) $(OBJS) -o iw
+	$(Q)$(CC) $(LDFLAGS) $(OBJS) $(LIBS) -o iw

 check:
 	$(Q)$(MAKE) all CC="REAL_CC=$(CC) CHECK=\"sparse -Wall\" cgcc"
diff --git a/iw.c b/iw.c
index afae643..e9cc7f6 100644
--- a/iw.c
+++ b/iw.c
@@ -23,13 +23,24 @@
 #include "iw.h"
 #include "version.h"

+#ifndef CONFIG_LIBNL20
+/* libnl 2.0 compatibility code */
+
+#define nl_socket_alloc(_h) nl_handle_alloc(_h)
+#define nl_socket_free(_h)  nl_handle_destroy(_h)
+#define compat_genl_ctrl_alloc_cache(_nl_handle, _nl_cache) \
+        (_nl_cache = genl_ctrl_alloc_cache(_nl_handle)) == NULL
+
+#define genl_ctrl_alloc_cache(_h,_i) compat_genl_ctrl_alloc_cache(_h,_i)
+#endif /* CONFIG_LIBNL20 */
+
 static int debug = 0;

 static int nl80211_init(struct nl80211_state *state)
 {
 	int err;

-	state->nl_handle = nl_handle_alloc();
+	state->nl_handle = nl_socket_alloc();
 	if (!state->nl_handle) {
 		fprintf(stderr, "Failed to allocate netlink handle.\n");
 		return -ENOMEM;
@@ -41,8 +52,7 @@ static int nl80211_init(struct nl80211_state *state)
 		goto out_handle_destroy;
 	}

-	state->nl_cache = genl_ctrl_alloc_cache(state->nl_handle);
-	if (!state->nl_cache) {
+	if (genl_ctrl_alloc_cache(state->nl_handle, &(state->nl_cache))) {
 		fprintf(stderr, "Failed to allocate generic netlink cache.\n");
 		err = -ENOMEM;
 		goto out_handle_destroy;
@@ -60,7 +70,7 @@ static int nl80211_init(struct nl80211_state *state)
  out_cache_free:
 	nl_cache_free(state->nl_cache);
  out_handle_destroy:
-	nl_handle_destroy(state->nl_handle);
+	nl_socket_free(state->nl_handle);
 	return err;
 }

@@ -68,7 +78,7 @@ static void nl80211_cleanup(struct nl80211_state *state)
 {
 	genl_family_put(state->nl80211);
 	nl_cache_free(state->nl_cache);
-	nl_handle_destroy(state->nl_handle);
+	nl_socket_free(state->nl_handle);
 }

 __COMMAND(NULL, NULL, NULL, 0, 0, 0, CIB_NONE, NULL);

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Fri, 2008-12-12 at 18:48 -0500, pat-lkml wrote:
> This converts iw to use libnl-2, and adds compatibility with libnl-1.
> There is not currently a good way to detect the libnl version during
> compilation, as the versioning in the netlink/version.h is defined as
> a
> string "2.0" rather than a major and a minor number, so we must detect
> it in the Makefile.
> 
> Signed-off-by: Pat Erley <pat-lkml@erley.org>

Ok, I've committed a slightly different version of this (corrected the
type, and made the compat code static inlines), can you verify it still
works against 2.0?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[pat-lkml]

Johannes Berg wrote:
> On Fri, 2008-12-12 at 18:48 -0500, pat-lkml wrote:
>> This converts iw to use libnl-2, and adds compatibility with libnl-1.
>> There is not currently a good way to detect the libnl version during
>> compilation, as the versioning in the netlink/version.h is defined as
>> a
>> string "2.0" rather than a major and a minor number, so we must detect
>> it in the Makefile.
>>
>> Signed-off-by: Pat Erley <pat-lkml@erley.org>
> 
> Ok, I've committed a slightly different version of this (corrected the
> type, and made the compat code static inlines), can you verify it still
> works against 2.0?
> 
> johannes
Yep, works fine with 2.0

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Fri, 2008-12-12 at 19:10 -0500, pat-lkml wrote:
> Johannes Berg wrote:
> > On Fri, 2008-12-12 at 18:48 -0500, pat-lkml wrote:
> >> This converts iw to use libnl-2, and adds compatibility with libnl-1.
> >> There is not currently a good way to detect the libnl version during
> >> compilation, as the versioning in the netlink/version.h is defined as
> >> a
> >> string "2.0" rather than a major and a minor number, so we must detect
> >> it in the Makefile.
> >>
> >> Signed-off-by: Pat Erley <pat-lkml@erley.org>
> > 
> > Ok, I've committed a slightly different version of this (corrected the
> > type, and made the compat code static inlines), can you verify it still
> > works against 2.0?

> Yep, works fine with 2.0

Alright, thanks for the patch and testing!

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[Dan E]

On Tue, 09 Dec 2008 00:26:41 +0100, "Johannes Berg"
<johannes@sipsolutions.net> said:
> There's libnl 1.2 and 2.0? That's news to me! Patches welcome. Sorry, I
> guess it needs 1.0 or 1.1, will fix the page.

Well at http://people.suug.ch/~tgr/libnl/ it still only lists 1.1 but
the git repository shows a clear move to 2.0 (forget I mentioned 1.2,
that was my own tracking label).  The code had a bunch of commits in
October.  In retrospect, if I just downloaded the 1.1 tarball from that
webpage instead of using the git HEAD everything would have been fine. 
Patches can probably wait until 2.0 is officially released.

> 
> > That's what I thought but I wasn't seeing any callbacks at all through
> > my ieee80211_ops pointers.  I did see the channel frequency change with
> > 'iwconfig wlan0', but no callbacks.  My fault, again, for not RTFM.  I
> > haven't gotten to the point yet on my driver where I expect 'ip link set
> > up dev wlan0' (or 'ifconfig wlan0 up', if you prefer) and now I see
> > that's why the config callback never happened.  
> 
> Ah. Yes, if the hw isn't started mac80211 won't try to configure it :)
> 
> > If I had RTFM I might
> > have noticed adding 'commit' at the end of the iwconfig command would
> > have done it without the 'up'.
> 
> No, it wouldn't, commit is pointless, don't worry about it, you'll never
> need to use it with mac80211.

When I reboot, modprobe the driver, and do 'iwconfig wlan0 channel 9
commit' the .config callback does run.  If I leave off the 'commit' it
does not.  I'm trying to validate as many callbacks as I can before
moving on to the next step, enabling the interface.

An additional question, if I may... Is wlan0 considered a "virtual
interface" or does that term only apply to additional interfaces created
with iw?  The whole vif thing has me a little confused.

Thanks for the help.

--
Dan

-- 
http://www.fastmail.fm - Accessible with your email software
                          or over the web

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

On Mon, 2008-12-08 at 19:43 -0500, Dan E wrote:

> When I reboot, modprobe the driver, and do 'iwconfig wlan0 channel 9
> commit' the .config callback does run.  If I leave off the 'commit' it
> does not.  

Strange. But .start also runs, right? Something must be turning up the
interface.

> I'm trying to validate as many callbacks as I can before
> moving on to the next step, enabling the interface.
> 
> An additional question, if I may... Is wlan0 considered a "virtual
> interface" or does that term only apply to additional interfaces created
> with iw?  The whole vif thing has me a little confused.

Yes, wlan0 is a virtual interface too, the first one.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[Dan E]

On Tue, 09 Dec 2008 01:51:43 +0100, "Johannes Berg"
<johannes@sipsolutions.net> said:
> On Mon, 2008-12-08 at 19:43 -0500, Dan E wrote:
> 
> > When I reboot, modprobe the driver, and do 'iwconfig wlan0 channel 9
> > commit' the .config callback does run.  If I leave off the 'commit' it
> > does not.  
> 
> Strange. But .start also runs, right? Something must be turning up the
> interface.

Eh, no you are right.  It doesn't run.  iwconfig was giving me an error
message that I mistook for one of my callback printk debugging calls.  I
jumped to the wrong conclusion.

> > I'm trying to validate as many callbacks as I can before
> > moving on to the next step, enabling the interface.
> > 
> > An additional question, if I may... Is wlan0 considered a "virtual
> > interface" or does that term only apply to additional interfaces created
> > with iw?  The whole vif thing has me a little confused.
> 
> Yes, wlan0 is a virtual interface too, the first one.

So I should expect the callbacks (e.g. .add_interface and
.remove_interface) when wlan0 gets created?

I cannot thank you enough for your help here.  I'm finally starting to
feel like I can get beyond a few mental blocks I've had regarding the
underlying framework, and start concentrating on the real driver
workings.

--
Dan

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Mon, 2008-12-08 at 20:01 -0500, Dan E wrote:

> > Strange. But .start also runs, right? Something must be turning up the
> > interface.
> 
> Eh, no you are right.  It doesn't run.  iwconfig was giving me an error
> message that I mistook for one of my callback printk debugging calls.  I
> jumped to the wrong conclusion.

Heh ok.

> > > An additional question, if I may... Is wlan0 considered a "virtual
> > > interface" or does that term only apply to additional interfaces created
> > > with iw?  The whole vif thing has me a little confused.
> > 
> > Yes, wlan0 is a virtual interface too, the first one.
> 
> So I should expect the callbacks (e.g. .add_interface and
> .remove_interface) when wlan0 gets created?

Yes. Well, no. You only get those callbacks once the interface is set
UP.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Userspace tools: Roadmap?

[David Shwatrz]

Hello,

I tried to understand the following but could not:

>>   For instance, how do I command a
>> channel change from userspace?  iw doesn't have that.  >Should it?

>Yes, it should, and nl80211 even supports it, but iw itself >doesn't yet.
>That's fairly easy to fix, too, but then iw won't support actually
>telling mac80211 to scan and associate etc.

Can you please explain why addition of channel changing in iw will
cause iw to not be able to support scanning and association ?
(wireless-tools has all this options).

Regards,
DavidS



On Mon, Dec 8, 2008 at 10:13 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sun, 2008-12-07 at 18:29 -0500, Dan E wrote:
>> Looking at some of the Linux Wireless website pages it appears as though
>> "iw" is meant to be the successor to the older pre-mac80211 userspace
>> tools.  In that category we have ifconfig, iproute2, iwconfig and
>> iwpriv.  For an AP there's also hostapd and wpa_supplicant.  Probably
>> some others I've missed, not to mention Network Manager.  I can see how
>> configuration and setup wouldn't necessarily be limited to "iw" using
>> nl/cfg80211, but in the short term is that the tool of choice for
>> migrating the functionality of the old tools to the new mac80211
>> infrastructure?
>
> Not really, in the short term, you still are using iwconfig (wireless
> extensions) with anything but hostapd.
>
>> Here's my situation: [snip]
>
> nice
>
>> Userspace tools.  I want to proceed as if Wireless Extensions never
>> existed.  Is that even possible?
>
> No, it's not.
>
>>   For instance, how do I command a
>> channel change from userspace?  iw doesn't have that.  Should it?
>
> Yes, it should, and nl80211 even supports it, but iw itself doesn't yet.
> That's fairly easy to fix, too, but then iw won't support actually
> telling mac80211 to scan and associate etc.
>
>> Or do
>> I need to drop back to iwconfig?
>
> For now.
>
>> Is iw the preferred command-line way
>> to do everything the old tools did, but using nl/cfg80211 instead of
>> ioctls?
>
> Not _yet_.
>
>>   When we get to AP mode, will hostapd be re-written to speak
>> nl/cfg80211, or is a new config tool needed?  The same questions apply
>> to wpa_supplicant.
>
> That's already been done. The plan is to keep wext compatibility around
> though, obviously, so iwconfig will work in the foreseeable future.
>
>> In general, what's the way forward for new userspace tools?  nl80211 and
>> cfg80211 are a given, I understand that, but what's the recommended
>> approach from the perspective of a developer looking to make a clean
>> break from Wireless Extensions with a new cleanroom driver written from
>> scratch with no pre-existing baggage to worry about?  Start making
>> additions to iw's capabilities?  Adapt some other existing tool to use
>> nl/cfg80211, or write something completely new?
>
> If you're writing a mac80211-based driver, there's no point where you
> could possibly get in touch with the userspace API. You're writing the
> driver completely to mac80211's internal driver API, and mac80211
> completely shields you from the userspace API. You'll never interact
> with either wireless extensions or nl80211.
>
>> If somone could answer only 1 question (okay, it's a two-parter) the one
>> I would most like answered is this:  How does one, from userspace, ask
>> the driver to switch to a specific channel, and what callback(s) from
>> mac80211 should my driver expect to receive as a result?
>
> iwconfig wlan0 channel 7
>
> then mac80211 calls your _ops->config() with the channel flag. Have you
> looked at the mac80211 book and the other documentation on
> http://wireless.kernel.org/?
>
> johannes
>

Re: Userspace tools: Roadmap?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Thu, 2009-01-15 at 09:52 +0200, David Shwatrz wrote:

> >>   For instance, how do I command a
> >> channel change from userspace?  iw doesn't have that.  >Should it?
> 
> >Yes, it should, and nl80211 even supports it, but iw itself >doesn't yet.
> >That's fairly easy to fix, too, but then iw won't support actually
> >telling mac80211 to scan and associate etc.
> 
> Can you please explain why addition of channel changing in iw will
> cause iw to not be able to support scanning and association ?
> (wireless-tools has all this options).

Eh, no, I worded that wrongly, I meant that it currently _doesn't_
support scan/associate. And nor does nl80211, so that's not easy to fix
(well, scan is WIP)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]