iw packaging

iw packaging

[Johannes Berg]

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

Hi,

I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
because I think the tool is now actually usable in a limited way, unlike
before where it would never properly report errors etc.

Anyone want to pick it up for the various distros?

johannes

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

Re: iw packaging

[Stefanik Gábor]

On Tue, Sep 16, 2008 at 10:29 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Hi,
>
> I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
> because I think the tool is now actually usable in a limited way, unlike
> before where it would never properly report errors etc.
>
> Anyone want to pick it up for the various distros?
>
> johannes
>

In fact, we have picked it up long ago for BackTrack 4. I will mail
Mati Aharoni (irc:muts) to update to this release tag (currently, a
customized version is included).

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: iw packaging

[Pavel Roskin]

On Tue, 2008-09-16 at 22:29 +0200, Johannes Berg wrote:
> Hi,
> 
> I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
> because I think the tool is now actually usable in a limited way, unlike
> before where it would never properly report errors etc.
> 
> Anyone want to pick it up for the various distros?

Sorry for diverting the thread, but the current git head (which is
tagged as 0.9.1) is broken.

$ ./iw 
Usage:  ./iw [options] command
Options:
        --debug         enable netlink debugging
        --version       show version
Commands:
        list
        Segmentation fault (core dumped)

Debugging shows:

82              fprintf(stderr, "Commands:\n");
(gdb) 
Commands:
83              for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
(gdb) p __start___cmd
$1 = {section = 0x0, name = 0x403d02 "info", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
  nl_msg_flags = 0, idby = CIB_PHY, handler = 0x402403 <handle_info>}
(gdb) p *(&__start___cmd + 1)
$2 = {section = 0x0, name = 0x0, args = 0x0, cmd = 4209927, nl_msg_flags = 0, idby = CIB_NONE, 
  handler = 0x30000000001}
(gdb)

That means, __start___cmd points to "info".  The next command has no
name (and appears to be a complete mess).  The clever section trick
doesn't seem to work properly.

I'm using Fedora 9 x86_64 with all updates.

-- 
Regards,
Pavel Roskin

Re: iw packaging

[Johannes Berg]

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

On Tue, 2008-09-16 at 16:50 -0400, Pavel Roskin wrote:

> Sorry for diverting the thread, but the current git head (which is
> tagged as 0.9.1) is broken.
> 
> $ ./iw 
> Usage:  ./iw [options] command
> Options:
>         --debug         enable netlink debugging
>         --version       show version
> Commands:
>         list
>         Segmentation fault (core dumped)
> 
> Debugging shows:
> 
> 82              fprintf(stderr, "Commands:\n");
> (gdb) 
> Commands:
> 83              for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
> (gdb) p __start___cmd
> $1 = {section = 0x0, name = 0x403d02 "info", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
>   nl_msg_flags = 0, idby = CIB_PHY, handler = 0x402403 <handle_info>}
> (gdb) p *(&__start___cmd + 1)
> $2 = {section = 0x0, name = 0x0, args = 0x0, cmd = 4209927, nl_msg_flags = 0, idby = CIB_NONE, 
>   handler = 0x30000000001}
> (gdb)
> 
> That means, __start___cmd points to "info".  The next command has no
> name (and appears to be a complete mess).  The clever section trick
> doesn't seem to work properly.

Strange. It's supposed to work, it's documented that way, and it's
working fine here... Ideas anyone?

johannes

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

Re: iw packaging

[Johannes Berg]

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

On Tue, 2008-09-16 at 23:11 +0200, Johannes Berg wrote:

> > 83              for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
> > (gdb) p __start___cmd
> > $1 = {section = 0x0, name = 0x403d02 "info", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
> >   nl_msg_flags = 0, idby = CIB_PHY, handler = 0x402403 <handle_info>}
> > (gdb) p *(&__start___cmd + 1)
> > $2 = {section = 0x0, name = 0x0, args = 0x0, cmd = 4209927, nl_msg_flags = 0, idby = CIB_NONE, 
> >   handler = 0x30000000001}
> > (gdb)
> > 
> > That means, __start___cmd points to "info".  The next command has no
> > name (and appears to be a complete mess).  The clever section trick
> > doesn't seem to work properly.

Hmm. can you send the output of

nm iw | grep __cmd

objdump -h iw
(only the __cmd section part is fine)

and
objdump -j __cmd -s iw

johannes

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

Re: iw packaging

[Pavel Roskin]

On Tue, 2008-09-16 at 23:15 +0200, Johannes Berg wrote:
> On Tue, 2008-09-16 at 23:11 +0200, Johannes Berg wrote:
> 
> > > 83              for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
> > > (gdb) p __start___cmd
> > > $1 = {section = 0x0, name = 0x403d02 "info", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
> > >   nl_msg_flags = 0, idby = CIB_PHY, handler = 0x402403 <handle_info>}
> > > (gdb) p *(&__start___cmd + 1)
> > > $2 = {section = 0x0, name = 0x0, args = 0x0, cmd = 4209927, nl_msg_flags = 0, idby = CIB_NONE, 
> > >   handler = 0x30000000001}
> > > (gdb)
> > > 
> > > That means, __start___cmd points to "info".  The next command has no
> > > name (and appears to be a complete mess).  The clever section trick
> > > doesn't seem to work properly.
> 
> Hmm. can you send the output of
> 
> nm iw | grep __cmd

I recompiled iw with optimization, so the addresses may be different.

$ nm iw | grep __cmd
0000000000403d40 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_NONE
0000000000403d80 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_PHY
0000000000403f00 r __cmd_handle_interface_addNL80211_CMD_NEW_INTERFACECIB_NETDEV
0000000000403f40 r __cmd_handle_interface_addNL80211_CMD_NEW_INTERFACECIB_PHY
0000000000403ec0 r __cmd_handle_interface_delNL80211_CMD_DEL_INTERFACECIB_NETDEV
0000000000403e80 r __cmd_handle_interface_infoNL80211_CMD_GET_INTERFACECIB_NETDEV
0000000000403e00 r __cmd_handle_interface_meshidNL80211_CMD_SET_INTERFACECIB_NETDEV
0000000000403e40 r __cmd_handle_interface_setNL80211_CMD_SET_INTERFACECIB_NETDEV
0000000000404080 r __cmd_handle_mpath_dumpNL80211_CMD_GET_MPATHCIB_NETDEV
0000000000404140 r __cmd_handle_mpath_getNL80211_CMD_DEL_MPATHCIB_NETDEV
0000000000404180 r __cmd_handle_mpath_getNL80211_CMD_GET_MPATHCIB_NETDEV
0000000000404100 r __cmd_handle_mpath_setNL80211_CMD_NEW_MPATHCIB_NETDEV
00000000004040c0 r __cmd_handle_mpath_setNL80211_CMD_SET_MPATHCIB_NETDEV
0000000000403dc0 r __cmd_handle_nameNL80211_CMD_SET_WIPHYCIB_PHY
00000000004041c0 r __cmd_handle_reg_setNL80211_CMD_REQ_SET_REGCIB_NONE
0000000000403f80 r __cmd_handle_station_dumpNL80211_CMD_GET_STATIONCIB_NETDEV
0000000000404000 r __cmd_handle_station_getNL80211_CMD_DEL_STATIONCIB_NETDEV
0000000000404040 r __cmd_handle_station_getNL80211_CMD_GET_STATIONCIB_NETDEV
0000000000403fc0 r __cmd_handle_station_setNL80211_CMD_SET_STATIONCIB_NETDEV
0000000000403d40 A __start___cmd
00000000004041f0 A __stop___cmd

> objdump -h iw
> (only the __cmd section part is fine)

15 __cmd         000004b0  0000000000403d40  0000000000403d40  00003d40  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

> and
> objdump -j __cmd -s iw

$ objdump -j __cmd -s iw

iw:     file format elf64-x86-64

Contents of section __cmd:
 403d40 00000000 00000000 75384000 00000000  ........u8@.....
 403d50 00000000 00000000 01000000 00030000  ................
 403d60 00000000 00000000 c01d4000 00000000  ..........@.....
 403d70 00000000 00000000 00000000 00000000  ................
 403d80 00000000 00000000 7a384000 00000000  ........z8@.....
 403d90 00000000 00000000 01000000 00000000  ................
 403da0 01000000 00000000 c01d4000 00000000  ..........@.....
 403db0 00000000 00000000 00000000 00000000  ................
 403dc0 88384000 00000000 8c384000 00000000  .8@......8@.....
 403dd0 91384000 00000000 02000000 00000000  .8@.............
 403de0 01000000 00000000 50224000 00000000  ........P"@.....
 403df0 00000000 00000000 00000000 00000000  ................
 403e00 88384000 00000000 65394000 00000000  .8@.....e9@.....
 403e10 6c394000 00000000 06000000 00000000  l9@.............
 403e20 02000000 00000000 c0224000 00000000  ........."@.....
 403e30 00000000 00000000 00000000 00000000  ................
 403e40 88384000 00000000 ac384000 00000000  .8@......8@.....
 403e50 75394000 00000000 06000000 00000000  u9@.............
 403e60 02000000 00000000 a0264000 00000000  .........&@.....
 403e70 00000000 00000000 00000000 00000000  ................
 403e80 00000000 00000000 7a384000 00000000  ........z8@.....
 403e90 00000000 00000000 05000000 00000000  ................
 403ea0 02000000 00000000 c0254000 00000000  .........%@.....
 403eb0 00000000 00000000 00000000 00000000  ................
 403ec0 00000000 00000000 82394000 00000000  .........9@.....
 403ed0 00000000 00000000 08000000 00000000  ................
 403ee0 02000000 00000000 b0224000 00000000  ........."@.....
 403ef0 00000000 00000000 00000000 00000000  ................
 403f00 86394000 00000000 90394000 00000000  .9@......9@.....
 403f10 98394000 00000000 07000000 00000000  .9@.............
 403f20 02000000 00000000 20234000 00000000  ........ #@.....
 403f30 00000000 00000000 00000000 00000000  ................
 403f40 86394000 00000000 90394000 00000000  .9@......9@.....
 403f50 98394000 00000000 07000000 00000000  .9@.............
 403f60 01000000 00000000 20234000 00000000  ........ #@.....
 403f70 00000000 00000000 00000000 00000000  ................
 403f80 c3384000 00000000 933a4000 00000000  .8@......:@.....
 403f90 00000000 00000000 11000000 00030000  ................
 403fa0 02000000 00000000 e0284000 00000000  .........(@.....
 403fb0 00000000 00000000 00000000 00000000  ................
 403fc0 c3384000 00000000 88384000 00000000  .8@......8@.....
 403fd0 d83a4000 00000000 12000000 00000000  .:@.............
 403fe0 02000000 00000000 502c4000 00000000  ........P,@.....
 403ff0 00000000 00000000 00000000 00000000  ................
 404000 c3384000 00000000 82394000 00000000  .8@......9@.....
 404010 983a4000 00000000 14000000 00000000  .:@.............
 404020 02000000 00000000 20284000 00000000  ........ (@.....
 404030 00000000 00000000 00000000 00000000  ................
 404040 c3384000 00000000 a63a4000 00000000  .8@......:@.....
 404050 983a4000 00000000 11000000 00000000  .:@.............
 404060 02000000 00000000 20284000 00000000  ........ (@.....
 404070 00000000 00000000 00000000 00000000  ................
 404080 2e3c4000 00000000 933a4000 00000000  .<@......:@.....
 404090 00000000 00000000 15000000 00030000  ................
 4040a0 02000000 00000000 d02f4000 00000000  ........./@.....
 4040b0 00000000 00000000 00000000 00000000  ................
 4040c0 2e3c4000 00000000 88384000 00000000  .<@......8@.....
 4040d0 603c4000 00000000 16000000 00000000  `<@.............
 4040e0 02000000 00000000 20324000 00000000  ........ 2@.....
 4040f0 00000000 00000000 00000000 00000000  ................
 404100 2e3c4000 00000000 343c4000 00000000  .<@.....4<@.....
 404110 603c4000 00000000 17000000 00000000  `<@.............
 404120 02000000 00000000 20324000 00000000  ........ 2@.....
 404130 00000000 00000000 00000000 00000000  ................
 404140 2e3c4000 00000000 82394000 00000000  .<@......9@.....
 404150 983a4000 00000000 18000000 00000000  .:@.............
 404160 02000000 00000000 102f4000 00000000  ........./@.....
 404170 00000000 00000000 00000000 00000000  ................
 404180 2e3c4000 00000000 a63a4000 00000000  .<@......:@.....
 404190 983a4000 00000000 15000000 00000000  .:@.............
 4041a0 02000000 00000000 102f4000 00000000  ........./@.....
 4041b0 00000000 00000000 00000000 00000000  ................
 4041c0 0d3d4000 00000000 88384000 00000000  .=@......8@.....
 4041d0 113d4000 00000000 1b000000 00000000  .=@.............
 4041e0 00000000 00000000 80334000 00000000  .........3@.....

-- 
Regards,
Pavel Roskin

Re: iw packaging

[Johannes Berg]

On Tue, 2008-09-16 at 17:23 -0400, Pavel Roskin wrote:
> On Tue, 2008-09-16 at 23:15 +0200, Johannes Berg wrote:
> > On Tue, 2008-09-16 at 23:11 +0200, Johannes Berg wrote:
> > 
> > > > 83              for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
> > > > (gdb) p __start___cmd
> > > > $1 = {section = 0x0, name = 0x403d02 "info", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
> > > >   nl_msg_flags = 0, idby = CIB_PHY, handler = 0x402403 <handle_info>}
> > > > (gdb) p *(&__start___cmd + 1)
> > > > $2 = {section = 0x0, name = 0x0, args = 0x0, cmd = 4209927, nl_msg_flags = 0, idby = CIB_NONE, 
> > > >   handler = 0x30000000001}
> > > > (gdb)
> > > > 
> > > > That means, __start___cmd points to "info".  The next command has no
> > > > name (and appears to be a complete mess).  The clever section trick
> > > > doesn't seem to work properly.
> > 
> > Hmm. can you send the output of
> > 
> > nm iw | grep __cmd
> 
> I recompiled iw with optimization, so the addresses may be different.

Oh I'm on powerpc anyway :)

> 0000000000403d40 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_NONE
> 0000000000403d80 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_PHY

Ok that looks fine.

I think what may be happening is that alignment is somehow messing
things up. Can you please try the patch below?

johannes

diff --git a/iw.c b/iw.c
index 672c516..14bb2d1 100644
--- a/iw.c
+++ b/iw.c
@@ -74,13 +74,19 @@ static void nl80211_cleanup(struct nl80211_state *state)
 static void usage(const char *argv0)
 {
 	struct cmd *cmd;
+	int i = 0;
 
 	fprintf(stderr, "Usage:\t%s [options] command\n", argv0);
 	fprintf(stderr, "Options:\n");
 	fprintf(stderr, "\t--debug\t\tenable netlink debugging\n");
 	fprintf(stderr, "\t--version\tshow version\n");
 	fprintf(stderr, "Commands:\n");
-	for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
+
+	do {
+		cmd = &__start___cmd[i];
+		i++;
+		if (cmd >= &__stop___cmd)
+			break;
 		switch (cmd->idby) {
 		case CIB_NONE:
 			fprintf(stderr, "\t");
@@ -100,7 +106,7 @@ static void usage(const char *argv0)
 			fprintf(stderr, "\n");
 			break;
 		}
-	}
+	} while (1);
 }
 
 static void version(void)
@@ -151,7 +157,7 @@ static int handle_cmd(struct nl80211_state *state,
 	struct nl_cb *cb = NULL;
 	struct nl_msg *msg;
 	int devidx = 0;
-	int err;
+	int err, i = 0;
 	const char *command, *section;
 
 	if (argc <= 1 && idby != CIB_NONE)
@@ -176,7 +182,11 @@ static int handle_cmd(struct nl80211_state *state,
 	argc--;
 	argv++;
 
-	for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
+	do {
+		cmd = &__start___cmd[i];
+		i++;
+		if (cmd >= &__stop___cmd)
+			break;
 		if (cmd->idby != idby)
 			continue;
 		if (cmd->section) {
@@ -197,7 +207,7 @@ static int handle_cmd(struct nl80211_state *state,
 		if (argc && !cmd->args)
 			continue;
 		break;
-	}
+	} while (1);
 
 	if (cmd == &__stop___cmd)
 		return 1;
diff --git a/iw.h b/iw.h
index c9d9052..71db6b9 100644
--- a/iw.h
+++ b/iw.h
@@ -45,7 +45,7 @@ struct cmd {
 	__COMMAND(#section, #name, args, cmd, flags, idby, handler)
 #define TOPLEVEL(name, args, cmd, flags, idby, handler)		\
 	__COMMAND(NULL, #name, args, cmd, flags, idby, handler)
-extern struct cmd __start___cmd;
+extern struct cmd __start___cmd[];
 extern struct cmd __stop___cmd;
 
 int mac_addr_a2n(unsigned char *mac_addr, char *arg);

Re: iw packaging

[Pavel Roskin]

On Tue, 2008-09-16 at 23:38 +0200, Johannes Berg wrote:

> I think what may be happening is that alignment is somehow messing
> things up. Can you please try the patch below?

The patch doesn't help:

$ ./iw 
Usage:  ./iw [options] command
Options:
        --debug         enable netlink debugging
        --version       show version
Commands:
        list
        Segmentation fault (core dumped)

(gdb) p __start___cmd
$1 = 0x403d20
(gdb) p *__start___cmd
$2 = {section = 0x0, name = 0x403865 "list", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
  nl_msg_flags = 768, idby = CIB_NONE, handler = 0x401da0 <handle_info>}
(gdb) p __start___cmd[0]
$3 = {section = 0x0, name = 0x403865 "list", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
  nl_msg_flags = 768, idby = CIB_NONE, handler = 0x401da0 <handle_info>}
(gdb) p __start___cmd[1]
$4 = {section = 0x0, name = 0x0, args = 0x0, cmd = 4208746, nl_msg_flags = 0, idby = CIB_NONE, 
  handler = 0x1}
(gdb) p &__start___cmd[0]
$5 = (struct cmd *) 0x403d20
(gdb) p &__start___cmd[1]
$6 = (struct cmd *) 0x403d50

$ nm iw | grep __cmd |sort
0000000000403d20 A __start___cmd
0000000000403d20 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_NONE
0000000000403d60 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_PHY
0000000000403da0 r __cmd_handle_nameNL80211_CMD_SET_WIPHYCIB_PHY
...

The next command is at 0x403d60, but the code expects it at 0x403d50.
gdb confirms it:

(gdb) p *(struct cmd *) 0x403d60
$1 = {section = 0x0, name = 0x40386a "info", args = 0x0, cmd = NL80211_CMD_GET_WIPHY, 
  nl_msg_flags = 0, idby = CIB_PHY, handler = 0x401da0 <handle_info>}
(gdb) p *(struct cmd *) 0x403da0
$2 = {section = 0x403878 "set", name = 0x40387c "name", args = 0x403881 "<new name>", 
  cmd = NL80211_CMD_SET_WIPHY, nl_msg_flags = 0, idby = CIB_PHY, 
  handler = 0x402230 <handle_name>}
(gdb)

-- 
Regards,
Pavel Roskin

Re: iw packaging

[Johannes Berg]

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

On Tue, 2008-09-16 at 17:48 -0400, Pavel Roskin wrote:

> $ nm iw | grep __cmd |sort
> 0000000000403d20 A __start___cmd
> 0000000000403d20 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_NONE
> 0000000000403d60 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_PHY
> 0000000000403da0 r __cmd_handle_nameNL80211_CMD_SET_WIPHYCIB_PHY
> ...
> 
> The next command is at 0x403d60, but the code expects it at 0x403d50.

I suspected as much, but right now I don't know how to fix that. I'd
have thought the rules here would be just like in an array but clearly I
was wrong.

This would probably "fix" it, but it's ugly:

--- a/iw.h
+++ b/iw.h
@@ -35,6 +35,7 @@ struct cmd {
        int (*handler)(struct nl_cb *cb,
                       struct nl_msg *msg,
                       int argc, char **argv);
+       void *dummy[0] __attribute__((__aligned__(0x40)));
 };
 
 #define __COMMAND(sect, name, args, nlcmd, flags, idby, handler)       \


johannes

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

Re: iw packaging

[Johannes Berg]

On Tue, 2008-09-16 at 23:56 +0200, Johannes Berg wrote:
> On Tue, 2008-09-16 at 17:48 -0400, Pavel Roskin wrote:
> 
> > $ nm iw | grep __cmd |sort
> > 0000000000403d20 A __start___cmd
> > 0000000000403d20 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_NONE
> > 0000000000403d60 r __cmd_handle_infoNL80211_CMD_GET_WIPHYCIB_PHY
> > 0000000000403da0 r __cmd_handle_nameNL80211_CMD_SET_WIPHYCIB_PHY
> > ...
> > 
> > The next command is at 0x403d60, but the code expects it at 0x403d50.
> 
> I suspected as much, but right now I don't know how to fix that. I'd
> have thought the rules here would be just like in an array but clearly I
> was wrong.

My brother suggested this workaround, can you try? Works here.

diff --git a/iw.c b/iw.c
index 672c516..bba3e6f 100644
--- a/iw.c
+++ b/iw.c
@@ -71,6 +71,11 @@ static void nl80211_cleanup(struct nl80211_state *state)
 	nl_handle_destroy(state->nl_handle);
 }
 
+__COMMAND(NULL, NULL, NULL, 0, 0, CIB_NONE, NULL);
+__COMMAND(NULL, NULL, NULL, 1, 0, CIB_NONE, NULL);
+
+static int cmd_size;
+
 static void usage(const char *argv0)
 {
 	struct cmd *cmd;
@@ -80,7 +85,10 @@ static void usage(const char *argv0)
 	fprintf(stderr, "\t--debug\t\tenable netlink debugging\n");
 	fprintf(stderr, "\t--version\tshow version\n");
 	fprintf(stderr, "Commands:\n");
-	for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
+	for (cmd = &__start___cmd; cmd < &__stop___cmd;
+	     cmd = (struct cmd *)((char *)cmd + cmd_size)) {
+		if (!cmd->handler)
+			continue;
 		switch (cmd->idby) {
 		case CIB_NONE:
 			fprintf(stderr, "\t");
@@ -176,7 +184,10 @@ static int handle_cmd(struct nl80211_state *state,
 	argc--;
 	argv++;
 
-	for (cmd = &__start___cmd; cmd < &__stop___cmd; cmd++) {
+	for (cmd = &__start___cmd; cmd < &__stop___cmd;
+	     cmd = (struct cmd *)((char *)cmd + cmd_size)) {
+		if (!cmd->handler)
+			continue;
 		if (cmd->idby != idby)
 			continue;
 		if (cmd->section) {
@@ -258,6 +269,7 @@ int main(int argc, char **argv)
 	int err;
 	const char *argv0;
 
+	cmd_size = abs((long)&__cmd_NULL1CIB_NONE - (long)&__cmd_NULL0CIB_NONE);
 	/* strip off self */
 	argc--;
 	argv0 = *argv++;

Re: iw packaging

[Pavel Roskin]

On Wed, 2008-09-17 at 00:14 +0200, Johannes Berg wrote:

> My brother suggested this workaround, can you try? Works here.

It's working for me on x86_64 and i386.

-- 
Regards,
Pavel Roskin

Re: iw packaging

[Johannes Berg]

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

On Tue, 2008-09-16 at 19:20 -0400, Pavel Roskin wrote:
> On Wed, 2008-09-17 at 00:14 +0200, Johannes Berg wrote:
> 
> > My brother suggested this workaround, can you try? Works here.
> 
> It's working for me on x86_64 and i386.

Great. I'd committed it anyway since I was pretty confident it would and
have also already tagged 0.9.2.

johannes

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

Re: iw packaging

[Jochen Friedrich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Berg schrieb:

> I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
> because I think the tool is now actually usable in a limited way, unlike
> before where it would never properly report errors etc.
> 
> Anyone want to pick it up for the various distros?

In Debian, iw seems to be already packaged as part of aircrack-ng which now needs
to be packaged seperately.

Thanks,
Jochen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSNDe7MP9a9GOLSE6AQJlswf+LDjAb3SlDtij+nm6AdO6fAYzDbNCIfzX
tyeI34pQ2KhquO15eMsmgZ5dIIr+SDcnUDRlMJ1m7zgoCdV+qy1Jiw273u9A+fqo
OFoD3BWA3lfCRu4tpgTQMz8X6/6FjAdF/krnTxu/NMynzjhWemo9pzvnG6p6uOxb
j1WhSC03pnqNtkZF8iKvzAk11Mr+yYx2kS9A9dBVlpQV5F/iBPDZOPintIAIscyt
kw/ZgZB3vV750F3RFYWApZjgmyx/XQZQr95Pur7lUye1vFZTh5ptLzREiR6LQV4y
KuXFHeZ3TWHWhnZptJPxqQz8HFhZoqsV97Vyht/Tbrrkp8/Wy4Z6rA==
=WyMX
-----END PGP SIGNATURE-----

Re: iw packaging

[Johannes Berg]

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

On Wed, 2008-09-17 at 12:41 +0200, Jochen Friedrich wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Johannes Berg schrieb:
> 
> > I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
> > because I think the tool is now actually usable in a limited way, unlike
> > before where it would never properly report errors etc.
> > 
> > Anyone want to pick it up for the various distros?
> 
> In Debian, iw seems to be already packaged as part of aircrack-ng which now needs
> to be packaged seperately.

Yeah, it's also a pre-release version that the aircrack developers are
distributing. I'm not very happy with that and have filed a bug against
aircrack-ng (but it seems to not have gone through yet)

johannes

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

Re: iw packaging

["Adam Cécile (Le_Vert)"]

Hello Johannes,

I'm aware of this issue. It has been done to have a fully working=20
aircrack-ng for lenny release.
I'll package iw seperatly once lenny has been released.

Regards, Adam.

Johannes Berg a =E9crit :
> On Wed, 2008-09-17 at 12:41 +0200, Jochen Friedrich wrote:
>  =20
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Johannes Berg schrieb:
>>
>>    =20
>>> I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
>>> because I think the tool is now actually usable in a limited way, u=
nlike
>>> before where it would never properly report errors etc.
>>>
>>> Anyone want to pick it up for the various distros?
>>>      =20
>> In Debian, iw seems to be already packaged as part of aircrack-ng wh=
ich now needs
>> to be packaged seperately.
>>    =20
>
> Yeah, it's also a pre-release version that the aircrack developers ar=
e
> distributing. I'm not very happy with that and have filed a bug again=
st
> aircrack-ng (but it seems to not have gone through yet)
>
> johannes
>  =20

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw packaging

[Johannes Berg]

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

On Wed, 2008-09-17 at 13:05 +0200, "Adam Cécile (Le_Vert)" wrote:
> Hello Johannes,
> 
> I'm aware of this issue. It has been done to have a fully working 
> aircrack-ng for lenny release.
> I'll package iw seperatly once lenny has been released.

Cool, thanks. Note that I think that one of the small command syntax
changes I made might be breaking aircrack-ng, not sure how to handle
that. They should've just used nl80211 directly if you ask me.

johannes

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

Re: iw packaging

["Adam Cécile (Le_Vert)"]

Johannes Berg a =C3=A9crit :
> On Wed, 2008-09-17 at 13:05 +0200, "Adam C=C3=A9cile (Le_Vert)" wrote=
:
>  =20
>> Hello Johannes,
>>
>> I'm aware of this issue. It has been done to have a fully working=20
>> aircrack-ng for lenny release.
>> I'll package iw seperatly once lenny has been released.
>>    =20
>
> Cool, thanks. Note that I think that one of the small command syntax
> changes I made might be breaking aircrack-ng, not sure how to handle
> that. They should've just used nl80211 directly if you ask me.
>
> johannes
>  =20
Why not having a talk with aircrack-ng main developper ?
I'm sure he would be happy to work with you and avoid having a patched=20
version of iw.

Thomas d'Otreppe: tdotreppe@aircrack-ng.org
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw packaging

[Johannes Berg]

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

On Wed, 2008-09-17 at 13:11 +0200, "Adam Cécile (Le_Vert)" wrote:

> Why not having a talk with aircrack-ng main developper ?
> I'm sure he would be happy to work with you and avoid having a patched 
> version of iw.

Because I have no idea who to contact and figured that they'd notice
quickly enough? :)


Thomas, since people seem to be relying on iw more and more (I had been
hoping somebody else would take it and transform it into something
usable) I have gone ahead and cleaned up the code, made a few
modifications to it and released it as version 0.9 (and a few 0.9.x
fixes, my bad).

There are two changes that might interest you:
 * removing interfaces now works like this:
     iw dev monitor0 del
   I didn't feel inclined to keep the old syntax because it's rather
   ugly but if this is a big problem for you I can add a hidden command
   so you can continue doing "iw dev monitor0 interface del".
 * if you've been using
     iw dev wmaster0 interface add monitor0 type monitor
   this will stop working in future kernel releases, the master
   interface really is no good for actually configuring wireless and we
   want to get rid of it completely in the medium term. I suspect you
   have been using
     iw dev wlan0 interface add monitor0 type monitor
   which will continue to work.

johannes

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

Re: iw packaging

[Johannes Berg]

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

On Wed, 2008-09-17 at 13:18 +0200, Johannes Berg wrote:

>  * removing interfaces now works like this:
>      iw dev monitor0 del
>    I didn't feel inclined to keep the old syntax because it's rather
>    ugly but if this is a big problem for you I can add a hidden command
>    so you can continue doing "iw dev monitor0 interface del".

I've gone ahead and done that since anyway who knows what else is
already relying on this...

johannes

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

Re: iw packaging

[Stefanik Gábor]

On Wed, Sep 17, 2008 at 1:18 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2008-09-17 at 13:11 +0200, "Adam C=E9cile (Le_Vert)" wrote:
>
>> Why not having a talk with aircrack-ng main developper ?
>> I'm sure he would be happy to work with you and avoid having a patch=
ed
>> version of iw.
>
> Because I have no idea who to contact and figured that they'd notice
> quickly enough? :)
>
>
> Thomas, since people seem to be relying on iw more and more (I had be=
en
> hoping somebody else would take it and transform it into something
> usable) I have gone ahead and cleaned up the code, made a few
> modifications to it and released it as version 0.9 (and a few 0.9.x
> fixes, my bad).
>
> There are two changes that might interest you:
>  * removing interfaces now works like this:
>     iw dev monitor0 del
>   I didn't feel inclined to keep the old syntax because it's rather
>   ugly but if this is a big problem for you I can add a hidden comman=
d
>   so you can continue doing "iw dev monitor0 interface del".
>  * if you've been using
>     iw dev wmaster0 interface add monitor0 type monitor
>   this will stop working in future kernel releases, the master
>   interface really is no good for actually configuring wireless and w=
e
>   want to get rid of it completely in the medium term. I suspect you
>   have been using
>     iw dev wlan0 interface add monitor0 type monitor
>   which will continue to work.
>
> johannes
>

By the way, currently I am the one maintaining the mac80211/nl80211
support in aircrack-ng.

Using iw was an intentional decision, as the airmon-ng command (used
to set interfaces into monitor mode/create monitor interfaces
automatically) is a Bash script, meaning that it can't access nl80211
directly. Rewriting airmon-ng in C is a 2.0 goal, and it definitely
won't make 1.0. (I will try to push it into 1.1, but it's mostly
Thomas' decision to allow it or not.)
Prior to 2.6.24, it was possible to create/remove interfaces using
sysfs, but this feature was removed from 2.6.24, "in favor of
nl80211", which I interpreted to apply to Bash scripts as "in favor of
iw".

The actual code used in aircrack-ng for adding interfaces is:
IW_ERROR=3D`iw dev $iface interface add $MONDEV type monitor 2>&1 | gre=
p
"nl80211 not found"`
where $iface is the interface supplied by the user (not the associated
master), while $MONDEV is a generated interface name, which is
generated by the following method:
1. The value of the $MON_PREFIX variable ("mon" by default) is taken.
2. A number (starting with 0) is appended to $MON_PREFIX, and the
resulting interface is checked for existence. If it does exist, the
number is incremented.
3. When the first nonexistent interface is found, it is written to $MON=
DEV.

So, the actual command used, for example, is:
iw dev wlan0 interface add mon0 type monitor

Similarly, the code used for removing interfaces is
IW_ERROR=3D`iw dev "$iface" interface del 2>&1 | grep "nl80211 not foun=
d"`
If I interpret your mail correctly, then this should be changed to:
IW_ERROR=3D`iw dev "$iface" del 2>&1 | grep "nl80211 not found"`

Will the same syntax change be made for the add feature? I mean this:
iw dev wlan0 add mon0 type monitor

Also, the following syntax would be even better:
iw --add mon0 --dev=3Dwlan0 --type=3Dmonitor
or:
iw -dwlan0 -tmonitor add mon0

Or at least allowing stuff like this:
iw type monitor add mon0 dev wlan0

The purpose of the customized version of iw used by aircrack-ng is to
allow it to compile on 2.6.24 without having to install mismatching
kernel headers, and to enable installing iw without git (this second
point is moot now that there are official tarballs). The only major
changes are the removal of .config dependency and the use of a local
nl80211.h. A "make install" feature was also added, as many users may
be uncomfortable with copying binaries around.
An experimental branch of aircrack-ng contains a slightly different
version, which also has these additional changes:
-Mesh support has been removed (as I couldn't get it compile with
-Wall -Werror, which is a requirement for inclusion into aircrack-ng)
-It was renamed to nl80211-ng (to avoid overwriting the full iw binary)
-It is built by aircrack-ng's own make system, with no extra makefile.
-The help text was changed, as this version is specifically expected
to be used through airmon-ng. (It essentially acts as a bridge between
the C-only nl80211 and airmon-ng, a Bash script.)

These were needed because there was no true "release" of iw, and its
development was focused on implementing all new features in the
bleeding-edge wireless-testing kernel, with little focus on backwards
compatibility with released kernels.

--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw packaging

[Johannes Berg]

On Wed, 2008-09-17 at 22:19 +0200, Stefanik G=C3=A1bor wrote:

> So, the actual command used, for example, is:
> iw dev wlan0 interface add mon0 type monitor

that seems fine.

> Similarly, the code used for removing interfaces is
> IW_ERROR=3D`iw dev "$iface" interface del 2>&1 | grep "nl80211 not fo=
und"`
> If I interpret your mail correctly, then this should be changed to:
> IW_ERROR=3D`iw dev "$iface" del 2>&1 | grep "nl80211 not found"`

I don't know why you insist on that grep, it should exit with a non-zer=
o
status code.... but you can use both forms, I added the invisible alias=
=2E

> Will the same syntax change be made for the add feature? I mean this:
> iw dev wlan0 add mon0 type monitor

No. What are you adding?

> Also, the following syntax would be even better:
> iw --add mon0 --dev=3Dwlan0 --type=3Dmonitor
> or:
> iw -dwlan0 -tmonitor add mon0
>=20
> Or at least allowing stuff like this:
> iw type monitor add mon0 dev wlan0

No. All of those are gross and not very object oriented.

> An experimental branch of aircrack-ng contains a slightly different
> version, which also has these additional changes:
> -Mesh support has been removed (as I couldn't get it compile with
> -Wall -Werror, which is a requirement for inclusion into aircrack-ng)

That's an extremely stupid requirement as warnings may pop up on variou=
s
platforms which you cannot anticipate, making it hard for users.


Anyway, you're free to fork it and do whatever you like that aircrack-n=
g
needs, but please don't call it iw and don't encourage debian to ship i=
t
as 'iw'.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw packaging

[Davide Pesavento]

$ make
 GEN  version.h
 CC   iw.o
 CC   info.o
info.c: In function 'print_phy_handler':
info.c:108: error: 'NL80211_ATTR_SUPPORTED_IFTYPES' undeclared (first
use in this function)
info.c:108: error: (Each undeclared identifier is reported only once
info.c:108: error: for each function it appears in.)
make: *** [info.o] Error 1

I guess I have to build iw against >=2.6.27-rcX kernel headers, right?

Re: iw packaging

[Stefanik Gábor]

On Wed, Sep 17, 2008 at 11:46 PM, Davide Pesavento <davidepesa@gmail.com> wrote:
> $ make
>  GEN  version.h
>  CC   iw.o
>  CC   info.o
> info.c: In function 'print_phy_handler':
> info.c:108: error: 'NL80211_ATTR_SUPPORTED_IFTYPES' undeclared (first
> use in this function)
> info.c:108: error: (Each undeclared identifier is reported only once
> info.c:108: error: for each function it appears in.)
> make: *** [info.o] Error 1
>
> I guess I have to build iw against >=2.6.27-rcX kernel headers, right?
>

That's exactly why I branched for aircrack-ng. Maybe we should use our
own copy of nl80211.h, as shipping with headers that are different
from/incompatible with the sources is not something that most distros
will do.

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: iw packaging

[Johannes Berg]

On Wed, 2008-09-17 at 23:46 +0200, Davide Pesavento wrote:
> $ make
>  GEN  version.h
>  CC   iw.o
>  CC   info.o
> info.c: In function 'print_phy_handler':
> info.c:108: error: 'NL80211_ATTR_SUPPORTED_IFTYPES' undeclared (first
> use in this function)
> info.c:108: error: (Each undeclared identifier is reported only once
> info.c:108: error: for each function it appears in.)
> make: *** [info.o] Error 1
> 
> I guess I have to build iw against >=2.6.27-rcX kernel headers, right?

Actually this one is new in wireless-testing, I have a branch you can
build against 2.6.27 but it's not very up-to-date.

Any ideas how to handle this are welcome. Should it just ship the header
file? I'd prefer not to, otoh doing it isn't really harmful because when
adding a new command clearly you need to edit iw sources.

johannes

Re: iw packaging

[Stefanik Gábor]

On Wed, Sep 17, 2008 at 11:52 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2008-09-17 at 23:46 +0200, Davide Pesavento wrote:
>> $ make
>>  GEN  version.h
>>  CC   iw.o
>>  CC   info.o
>> info.c: In function 'print_phy_handler':
>> info.c:108: error: 'NL80211_ATTR_SUPPORTED_IFTYPES' undeclared (first
>> use in this function)
>> info.c:108: error: (Each undeclared identifier is reported only once
>> info.c:108: error: for each function it appears in.)
>> make: *** [info.o] Error 1
>>
>> I guess I have to build iw against >=2.6.27-rcX kernel headers, right?
>
> Actually this one is new in wireless-testing, I have a branch you can
> build against 2.6.27 but it's not very up-to-date.
>
> Any ideas how to handle this are welcome. Should it just ship the header
> file? I'd prefer not to, otoh doing it isn't really harmful because when
> adding a new command clearly you need to edit iw sources.
>
> johannes
>
>

IMO that's the best thing to do - in fact, that's exactly why I
branched. Distros likely won't ship kernel headers that don't match
the kernel binaries and sources. (This is likely why Debian is
shipping my branched version, rather than the official.)

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: iw packaging

[Luis R. Rodriguez]

T24gV2VkLCBTZXAgMTcsIDIwMDggYXQgMjo1OCBQTSwgU3RlZmFuaWsgR8OhYm9yIDxuZXRyb2xs
bGVyLjNkQGdtYWlsLmNvbT4gd3JvdGU6Cj4gT24gV2VkLCBTZXAgMTcsIDIwMDggYXQgMTE6NTIg
UE0sIEpvaGFubmVzIEJlcmcKPiA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3JvdGU6Cj4+
IE9uIFdlZCwgMjAwOC0wOS0xNyBhdCAyMzo0NiArMDIwMCwgRGF2aWRlIFBlc2F2ZW50byB3cm90
ZToKPj4+ICQgbWFrZQo+Pj4gIEdFTiAgdmVyc2lvbi5oCj4+PiAgQ0MgICBpdy5vCj4+PiAgQ0Mg
ICBpbmZvLm8KPj4+IGluZm8uYzogSW4gZnVuY3Rpb24gJ3ByaW50X3BoeV9oYW5kbGVyJzoKPj4+
IGluZm8uYzoxMDg6IGVycm9yOiAnTkw4MDIxMV9BVFRSX1NVUFBPUlRFRF9JRlRZUEVTJyB1bmRl
Y2xhcmVkIChmaXJzdAo+Pj4gdXNlIGluIHRoaXMgZnVuY3Rpb24pCj4+PiBpbmZvLmM6MTA4OiBl
cnJvcjogKEVhY2ggdW5kZWNsYXJlZCBpZGVudGlmaWVyIGlzIHJlcG9ydGVkIG9ubHkgb25jZQo+
Pj4gaW5mby5jOjEwODogZXJyb3I6IGZvciBlYWNoIGZ1bmN0aW9uIGl0IGFwcGVhcnMgaW4uKQo+
Pj4gbWFrZTogKioqIFtpbmZvLm9dIEVycm9yIDEKPj4+Cj4+PiBJIGd1ZXNzIEkgaGF2ZSB0byBi
dWlsZCBpdyBhZ2FpbnN0ID49Mi42LjI3LXJjWCBrZXJuZWwgaGVhZGVycywgcmlnaHQ/Cj4+Cj4+
IEFjdHVhbGx5IHRoaXMgb25lIGlzIG5ldyBpbiB3aXJlbGVzcy10ZXN0aW5nLCBJIGhhdmUgYSBi
cmFuY2ggeW91IGNhbgo+PiBidWlsZCBhZ2FpbnN0IDIuNi4yNyBidXQgaXQncyBub3QgdmVyeSB1
cC10by1kYXRlLgo+Pgo+PiBBbnkgaWRlYXMgaG93IHRvIGhhbmRsZSB0aGlzIGFyZSB3ZWxjb21l
LiBTaG91bGQgaXQganVzdCBzaGlwIHRoZSBoZWFkZXIKPj4gZmlsZT8gSSdkIHByZWZlciBub3Qg
dG8sIG90b2ggZG9pbmcgaXQgaXNuJ3QgcmVhbGx5IGhhcm1mdWwgYmVjYXVzZSB3aGVuCj4+IGFk
ZGluZyBhIG5ldyBjb21tYW5kIGNsZWFybHkgeW91IG5lZWQgdG8gZWRpdCBpdyBzb3VyY2VzLgo+
Pgo+PiBqb2hhbm5lcwo+Pgo+Pgo+Cj4gSU1PIHRoYXQncyB0aGUgYmVzdCB0aGluZyB0byBkbyAt
IGluIGZhY3QsIHRoYXQncyBleGFjdGx5IHdoeSBJCj4gYnJhbmNoZWQuIERpc3Ryb3MgbGlrZWx5
IHdvbid0IHNoaXAga2VybmVsIGhlYWRlcnMgdGhhdCBkb24ndCBtYXRjaAo+IHRoZSBrZXJuZWwg
YmluYXJpZXMgYW5kIHNvdXJjZXMuIChUaGlzIGlzIGxpa2VseSB3aHkgRGViaWFuIGlzCj4gc2hp
cHBpbmcgbXkgYnJhbmNoZWQgdmVyc2lvbiwgcmF0aGVyIHRoYW4gdGhlIG9mZmljaWFsLikKClBl
b3BsZSB3YW50aW5nIHRvIHRlc3QgYmxlZWRpbmcgZWRnZSBhbmQgbm90IGNvbXBpbGUgdGhlaXIg
b3duIGtlcm5lbApzaW1wbHkgY2FuIHVzZSBjb21wYXQtd2lyZWxlc3MgY3JhcCBhbmQgdGhhdCBo
YXMgaXRzIG93biBubDgwMjExLmguIFdlCmNhbiBtb2RpZnkgaXcgdG8gbGV0IENPTVBBVF9UUkVF
IGJlIGRlZmluZWQgYW5kIGlmIHNvIGxvb2sgdGhlcmUKZmlyc3QuIFRoaXMgaXMgd2hhdCBDUkRB
IGRvZXMgZm9yIGV4YW1wbGUuCgpJIGRvbid0IHNlZSB3aHkgcGFja2FnZXMgc2hvdWxkIHNoaXAg
dGhlaXIgb3duIG5sODAyMTEuaCB1bmxlc3MgeW91CmFyZSByZXBsYWNpbmcgb3IgcHJvdmlkaW5n
IGEgbmV3IGNmZzgwMjExLmtvLgoKICBMdWlzCg==

Re: iw packaging

[Stefanik Gábor]

On Thu, Sep 18, 2008 at 12:03 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> People wanting to test bleeding edge and not compile their own kernel
> simply can use compat-wireless crap and that has its own nl80211.h. We
> can modify iw to let COMPAT_TREE be defined and if so look there
> first. This is what CRDA does for example.
>
> I don't see why packages should ship their own nl80211.h unless you
> are replacing or providing a new cfg80211.ko.
>
>  Luis
>

We want distros to ship iw, and for that we must not require using
extra files from a development repository.

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: iw packaging

[Johannes Berg]

On Thu, 2008-09-18 at 00:06 +0200, Stefanik G=C3=A1bor wrote:

> We want distros to ship iw, and for that we must not require using
> extra files from a development repository.

"Must not" is a pretty strong wording. I'll wait for comments from
somebody actually doing packaging and ignore you, thanks.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw packaging

[Johannes Berg]

On Wed, 2008-09-17 at 23:58 +0200, Stefanik G=C3=A1bor wrote:

> IMO that's the best thing to do - in fact, that's exactly why I
> branched.=20

It's not a good thing to do at all, in fact, it would be a possible
compromise only if I'd be willing to maintain that, which I've decided
against, it's another step to take when adding a new command, and it's
not hard to copy in a header file and patch iw.

>  (This is likely why Debian is
> shipping my branched version, rather than the official.)

I think you're deluded. If you'd read the bug report it's because they
didn't know better and nobody told them.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw packaging

[Marcel Holtmann]

Hi Johannes,

> I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
> because I think the tool is now actually usable in a limited way, unlike
> before where it would never properly report errors etc.

do you have a kernel.org account? If yes, it would be nice if you can
create tarballs and put them there. If not, I can do it for you if you
want me to.

Regards

Marcel

Re: iw packaging

[Johannes Berg]

Hi Marcel,

> > I've just tagged iw version 0.9 (and 0.9.1 after a small build fix)
> > because I think the tool is now actually usable in a limited way, unlike
> > before where it would never properly report errors etc.
> 
> do you have a kernel.org account? If yes, it would be nice if you can
> create tarballs and put them there. If not, I can do it for you if you
> want me to.

No, I don't, though I guess I could get one if I asked. So far I haven't
really seen a need for tarballs since gitweb creates them so easily :)
Do you think it'd be worthwhile? I can probably automate that easily on
wireless.kernel.org...

johannes

Re: iw packaging

[Johannes Berg]

On Wed, 2008-09-17 at 18:43 +0200, Johannes Berg wrote:

> Do you think it'd be worthwhile? I can probably automate that easily on
> wireless.kernel.org...

Since it's trivial, I'm now creating release tarballs for every tag on
http://wireless.kernel.org/iw/.

johannes

Re: iw packaging

[Luis R. Rodriguez]

On Wed, Sep 17, 2008 at 11:06 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2008-09-17 at 18:43 +0200, Johannes Berg wrote:
>
>> Do you think it'd be worthwhile? I can probably automate that easily on
>> wireless.kernel.org...
>
> Since it's trivial, I'm now creating release tarballs for every tag on
> http://wireless.kernel.org/iw/.

The right URL is this though:

http://wireless.kernel.org/download/iw/

  Luis

Re: iw packaging

[Marcel Holtmann]

Hi Johannes,

> > Do you think it'd be worthwhile? I can probably automate that easily on
> > wireless.kernel.org...
> 
> Since it's trivial, I'm now creating release tarballs for every tag on
> http://wireless.kernel.org/iw/.

to make it easier for the packager, I would propose to remove the "v" in
front of the version number.

I know you use that for your tags and using git-describe is so great,
but for packaging the extra character is just in the way.

Otherwise, thanks for putting these up.

Regards

Marcel

Re: iw packaging

[Johannes Berg]

On Thu, 2008-09-18 at 01:36 +0200, Marcel Holtmann wrote:
> Hi Johannes,
> 
> > > Do you think it'd be worthwhile? I can probably automate that easily on
> > > wireless.kernel.org...
> > 
> > Since it's trivial, I'm now creating release tarballs for every tag on
> > http://wireless.kernel.org/iw/.
> 
> to make it easier for the packager, I would propose to remove the "v" in
> front of the version number.
> 
> I know you use that for your tags and using git-describe is so great,
> but for packaging the extra character is just in the way.

That's pretty simple. git-describe isn't even involved, this is my
script now:

#!/bin/sh

cd /home/wireless/www/download/iw/
export GIT_DIR=/home/johannes/git/iw.git/

for tag in $(git tag) ; do
        ver=${tag#v}
        archive=iw-$ver.tar.bz2
        if test -f $archive ; then
                continue
        fi
        git-archive --format=tar --prefix=iw-$ver/ $tag | bzip2 > $archive
done


johannes

Re: iw packaging

[Thomas d'Otreppe]

Hi Johannes,

I talked to Stefanik G=E1bor some time ago and we came to the conclusio=
n
that we can now get rid of our version of iw and use yours. Excuse me
for the late answer, I have been quite busy these days (and still
busy). I don't have a specific date for removal but it will be done
for aircrack-ng 1.0 (final).

Regards,

Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iw packaging

[Helmut Schaa]

Am Dienstag, 16. September 2008 22:29:22 schrieb Johannes Berg:
> Anyone want to pick it up for the various distros?

Just updated the SUSE package to 0.9.4.

Thanks,
Helmut

Re: iw packaging

[Davide Pesavento]

2008/9/16 Johannes Berg <johannes@sipsolutions.net>:
> Anyone want to pick it up for the various distros?

I've written an ebuild for Gentoo and attached it to bug #238879.
https://bugs.gentoo.org/show_bug.cgi?id=238879

Regards,
Davide