Re: Kconfig warnings on latest GIT

2007-05-11 Thread Johannes Berg
On Fri, 2007-05-11 at 10:22 +0900, Simon Horman wrote: Actually, it was with ARCH=ia64. I have a feeling that you can get it to show up quite easily with anything other than ARCH=powerpc. Ick, I didn't know that drivers/macintosh was now included for all arches! Hmm. That's a bit of a problem.

Re: Kconfig warnings on latest GIT

2007-05-14 Thread Johannes Berg
Simon, I don't think that this is quite right, or at least it isn't quite the same as before. Yeah, I think you're right. I think that was is below will toggle SYS_SUPPORTS_APM_EMULATION when PMAC_APM_EMU is selected, which I think is what you want. Is it also neccessary to add a

Re: Kconfig warnings on latest GIT

2007-05-14 Thread Johannes Berg
On Mon, 2007-05-14 at 09:24 -0500, Kumar Gala wrote: this was my fix which looks pretty much the same. [...] Great, thanks. johannes signature.asc Description: This is a digitally signed message part

Re: [RTNETLINK]: Remove remains of wireless extensions over rtnetlink

2007-05-22 Thread Johannes Berg
the removal in the first place, Acked-by: Johannes Berg [EMAIL PROTECTED] johannes signature.asc Description: This is a digitally signed message part

Re: Generic netlink interface help

2007-05-25 Thread Johannes Berg
On Thu, 2007-05-24 at 09:43 +, Samuel Ortiz wrote: You probably want to use the libnl library. The latest SVN code has support for generic netlink: http://people.suug.ch/~tgr/libnl/ Huh. I just looked at it and I don't understand anything. What's the point with

Re: Generic netlink interface help

2007-05-27 Thread Johannes Berg
On Sat, 2007-05-26 at 00:18 +0200, Thomas Graf wrote: This area is still work in progress but the basic idea is that like in kernel context, the application defines its set of commands and assigns message parsers for each command. Ok, but why? For when we get asynchronous events from the

Re: Generic netlink interface help

2007-05-27 Thread Johannes Berg
On Sun, 2007-05-27 at 15:50 +0200, Rodolfo Giometti wrote: Is that written by using the libnl or not? Can you please send to me it, or just a portion of it, in order to better understand how I can send messages to the kernel? It's written in python without using libnl:

Re: [PATCH] cfg80211: fix signed macaddress in sysfs

2007-06-04 Thread Johannes Berg
On Mon, 2007-06-04 at 00:06 +0200, David Lamparter wrote: Fix signedness mixup making mac addresses show up strangely (like 00:11:22:33:44:ffaa) in /sys/class/ieee80211/*/macaddress. Huh, my mistake, patch looks good. Do we care for this in .22 still? Acked-by: Johannes Berg [EMAIL

Re: [PATCH] NET: Multiqueue network device support.

2007-06-12 Thread Johannes Berg
On Mon, 2007-06-11 at 08:23 -0400, jamal wrote: On Mon, 2007-11-06 at 13:58 +0200, Patrick McHardy wrote: Thats not true. Assume PSL has lots of packets, PSH is empty. We fill the PHL queue until their is no room left, so the driver has to stop the queue. Sure. Packets stashed on the

wireless userspace MLME and generic netlink vs. multicast (was: Re: [Take 2] mac80211 IEEE802.11e/WMM code cleanup)

2007-06-17 Thread Johannes Berg
[if you haven't seen the rest of the thread skip down to the === mark] On Sat, 2007-06-16 at 15:16 -0700, Michael Wu wrote: I don't think the implementation details are much of a problem. It's just a bit of message bouncing which is trivial. Except of course when you consider wext, but

Re: wireless userspace MLME and generic netlink vs. multicast (was: Re: [Take 2] mac80211 IEEE802.11e/WMM code cleanup)

2007-06-18 Thread Johannes Berg
On Mon, 2007-06-18 at 10:08 +0800, Zhu Yi wrote: OK. This is the key of the discussion. I agree. Do we take wpa_supplicant the only implementation of userspace MLME or even decision making (ie. DLS config) daemon? I think it's a combination of these facts. I don't think DLS decision

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-19 Thread Johannes Berg
On Mon, 2007-06-18 at 11:01 -0400, jamal wrote: Ok, by inspection (sorry, still dont have much time) - your kernel code is sending to group 1; i.e genlmsg_multicast(skb, 0, 1, GFP_ATOMIC); you need to change that to send to your assigned id, i.e: genlmsg_multicast(skb, 0,

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-20 Thread Johannes Berg
[took off acpi list] On Tue, 2007-06-19 at 12:20 -0400, jamal wrote: There is one default mcast group per entity. Most users only need that one. Ok. That's definitely a bug in nl80211 as we have it in development right now. Btw, what happens if the group id gets larger than 31? If you need

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-22 Thread Johannes Berg
On Thu, 2007-06-21 at 11:47 -0400, jamal wrote: On Wed, 2007-20-06 at 13:25 +0200, Johannes Berg wrote: Ok. That's definitely a bug in nl80211 as we have it in development right now. Sorry, have never looked at that code. No worries, I was just stating that. You can use setsockopt

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-26 Thread Johannes Berg
On Mon, 2007-06-25 at 13:08 -0400, jamal wrote: Why do you think that would be hard? It'd basically just mean replacing the netlink_capable(sock, NL_NONROOT_RECV) calls with a call that actually tests depending on the group(s) it wants. I think it could be done. You will need to have

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-26 Thread Johannes Berg
/netlink/genetlink.c2007-06-26 00:39:26.985732308 +0200 @@ -3,6 +3,7 @@ * * Authors:Jamal Hadi Salim * Thomas Graf [EMAIL PROTECTED] + * Johannes Berg [EMAIL PROTECTED] */ #include linux/module.h @@ -13,6

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-26 Thread Johannes Berg
On Tue, 2007-06-26 at 09:33 -0400, jamal wrote: On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote: I wonder if we should hold off on this API until we've worked out the multicast issue. I think we can fix all the code in one shot later. Yes, we could fix the code in the kernel

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-28 Thread Johannes Berg
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote: On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote: I wonder if we should hold off on this API until we've worked out the multicast issue. Even if the ACPI thing goes in first, you will have to change a few others that are existing

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 07:17 -0400, jamal wrote: No, the controller is the only other generic netlink multicast user according to what I've found. :) Scanning the code - true ;- Iam a little suprised that the task accounting folks didnt use it to periodically dump stats. :) Because of

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 07:48 -0400, jamal wrote: sure - if you rush you can make it into Daves 2.6.23; then both can conform at the same time. Yeah, I'll have to see whether I can make that. If not, no big deal either. Ok :) Though I'm not sure I understood the suggestion of sending just

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote: Do multicast groups have to have a seperate name? Or would it suffice to have them associated with the genl family and be able to find out the starting group number? In that case something like struct genl_mc_groups { struct

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 14:48 +0200, Patrick McHardy wrote: Hmm, another thought: since we have 32 bits for group numbers and 16 bits for families we could just reserve 16 bits for groups within each family. Or do we get trouble with that because in some place there's a group bitmap or

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote: Do multicast groups have to have a seperate name? Or would it suffice to have them associated with the genl family and be able to find out the starting group number? In that case something like struct genl_mc_groups { struct

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote: a) i.e other than the reserved group for controller (which you seem to be taking care of), every other genetlink user has to explicitly register when they need a mcast group. Hm. I'm starting to dislike the dynamic registration the more I think

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 15:11 +0200, Patrick McHardy wrote: Hm. I'm starting to dislike the dynamic registration the more I think about it. Now when a group is unregistered I'd have to unbind everybody who's currently using it... At least when I want to enforce root/non-root binds which is

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 15:23 +0200, Patrick McHardy wrote: I'm not sure that the only sensible thing to do is right, we do allow dynamic registration of netlink families and do the module reference thing anyway (admittedly, I never liked that and the autoloading part very much). I guess it

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 15:44 +0200, Patrick McHardy wrote: How about for now I only allow dynamic registration (no unregistration) and just send out when new groups are registered, and also give userspace a list of registered mc groups when they ask for a family description? That should

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
] + * Johannes Berg [EMAIL PROTECTED] */ #include linux/module.h @@ -13,6 +14,7 @@ #include linux/string.h #include linux/skbuff.h #include linux/mutex.h +#include linux/bitmap.h #include net/sock.h #include net/genetlink.h @@ -42,6 +44,16 @@ static void

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 16:05 +0200, Johannes Berg wrote: + mc_groups = + kzalloc(mc_groups_bits/BITS_PER_LONG + 1, + GFP_KERNEL); + if (!mc_groups) + return

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-06-29 Thread Johannes Berg
On Fri, 2007-06-29 at 16:19 +0200, Johannes Berg wrote: Uh huh, this reallocation is buggy. Fixed version below. More breakage, sorry about the patch-spam. Btw, I notice that the bug we talked about isn't present in practice since we have no multicast users except for the always-present

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-07-02 Thread Johannes Berg
On Sat, 2007-06-30 at 11:32 -0400, jamal wrote: +static void genl_unregister_mc_group(struct genl_multicast_group *grp) +{ + /* +* TODO: fix multicast group re-use by clearing the bit +* for this group in all genetlink sockets. +*/ + clear_bit(grp-id,

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-07-02 Thread Johannes Berg
On Mon, 2007-07-02 at 14:56 +0200, Patrick McHardy wrote: For information that belongs together logically a struct is fine. Ok. The main reason to use nested attributes is when you only have a single attribute to store your data in (for example TCA_OPTIONS for qdiscs). In that case a nested

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-07-02 Thread Johannes Berg
On Mon, 2007-07-02 at 16:38 +0200, Patrick McHardy wrote: Do I understand you correctly in that you prefer the way I did it now? Yes. Alright, then I'll rework the event generation to not include the whole family info and repost with that tomorrow or so. If I find time I might actually

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

2007-07-03 Thread Johannes Berg
On Mon, 2007-07-02 at 16:48 +0200, Johannes Berg wrote: If I find time I might actually fix the unregistration bug too, but I have a feeling digging in the socket code might take more time than I have right now. Hmm. I started digging into the af_netlink.c code and realised that the whole

[PATCH] netlink: allocate group bitmaps dynamically

2007-07-03 Thread Johannes Berg
Allow changing the number of groups for a netlink family after it has been created. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- include/linux/netlink.h |1 net/netlink/af_netlink.c | 61 +++ 2 files changed, 47 insertions(+), 15

[PATCH] netlink: allow removing multicast groups

2007-07-03 Thread Johannes Berg
Allow kicking listeners out of a multicast group when necessary (for example if that group is going to be removed.) Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- include/linux/netlink.h |1 + net/netlink/af_netlink.c | 47 ++- 2 files

[PATCH] generic netlink: dynamic multicast groups

2007-07-03 Thread Johannes Berg
Introduce API to dynamically register and unregister multicast groups. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Some hackish modifications to iproute2's genl command confirm that it does indeed work. include/linux/genetlink.h | 13 +++ include/net/genetlink.h | 22 + net

Re: [PATCH] netlink: allocate group bitmaps dynamically

2007-07-03 Thread Johannes Berg
On Tue, 2007-07-03 at 14:05 +0200, Patrick McHardy wrote: --- wireless-dev.orig/net/netlink/af_netlink.c 2007-07-03 00:10:31.617889695 +0200 +++ wireless-dev/net/netlink/af_netlink.c 2007-07-03 00:31:30.267889695 +0200 @@ -316,8 +316,11 @@ netlink_update_listeners(struct sock

Re: [PATCH] netlink: allocate group bitmaps dynamically

2007-07-03 Thread Johannes Berg
On Tue, 2007-07-03 at 16:11 +0200, Patrick McHardy wrote: - nlk-groups = kzalloc(NLGRPSZ(groups), GFP_KERNEL); - if (nlk-groups == NULL) + if (nlk-ngroups = groups) + return 0; + + new_groups = krealloc(nlk-groups, NLGRPSZ(groups), GFP_KERNEL); + if (new_groups == NULL)

Re: [PATCH] ACPI: export acpi events via generic netlink

2007-07-04 Thread Johannes Berg
On Tue, 2007-06-19 at 11:40 +0800, Zhang Rui wrote: +/* attributes of acpi_genl_family */ +enum { + ACPI_GENL_ATTR_UNSPEC, + ACPI_GENL_ATTR_EVENT, /* ACPI event info needed by user space */ + __ACPI_GENL_ATTR_MAX, +}; +#define ACPI_GENL_ATTR_MAX (__ACPI_GENL_ATTR_MAX - 1) +

multicasting netlink messages to groups 31 from userspace

2007-07-04 Thread Johannes Berg
Hey, Looking through the code that uses NL_NONROOT_SEND I just realised that it's impossible to send multicast messages from userspace to multicast groups with IDs higher than 31. That's not really good given that everywhere else we handle multicast groups up to 2^32-1 :/ Unfortunately, I

[PATCH] netlink: allocate group bitmaps dynamically

2007-07-04 Thread Johannes Berg
Allow changing the number of groups for a netlink family after it has been created, use RCU to protect the listeners bitmap keeping netlink_has_listeners() lock-free. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- include/linux/netlink.h |1 net/netlink/af_netlink.c | 86

Re: multicasting netlink messages to groups 31 from userspace

2007-07-04 Thread Johannes Berg
On Wed, 2007-07-04 at 16:04 +0400, Evgeniy Polyakov wrote: On Tue, Jul 03, 2007 at 09:51:25PM +0200, Johannes Berg ([EMAIL PROTECTED]) wrote: Does anybody have any better ideas? Why don't you want to reserve a set of bits in group number, which means 'allow to work with unpriveledged

Re: multicasting netlink messages to groups 31 from userspace

2007-07-04 Thread Johannes Berg
On Wed, 2007-07-04 at 16:12 +0200, Patrick McHardy wrote: Johannes Berg wrote: Hey, Looking through the code that uses NL_NONROOT_SEND I just realised that it's impossible to send multicast messages from userspace to multicast groups with IDs higher than 31. That's not really good

Re: multicasting netlink messages to groups 31 from userspace

2007-07-04 Thread Johannes Berg
On Wed, 2007-07-04 at 16:30 +0200, Patrick McHardy wrote: [...] The kernel doesn't have any multicast listeners (yet). Right. I wonder if thats really a good idea to use multicast for device configuration. Unicast transmissions from userspace to kernel are reliable when you don't use

[RFC 2/3] netlink: allow removing multicast groups

2007-07-04 Thread Johannes Berg
Allow kicking listeners out of a multicast group when necessary (for example if that group is going to be removed.) Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- include/linux/netlink.h |1 + net/netlink/af_netlink.c | 47 ++- 2 files

[RFC 0/3] netlink/generic netlink multicast group rework

2007-07-04 Thread Johannes Berg
This is just a repost of the patches that I posted previously because they were buried deeply in the ACPI thread and I'm hoping that now other people will also take a look. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED]

[RFC 1/3] netlink: allocate group bitmaps dynamically

2007-07-04 Thread Johannes Berg
Allow changing the number of groups for a netlink family after it has been created, use RCU to protect the listeners bitmap keeping netlink_has_listeners() lock-free. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- include/linux/netlink.h |1 net/netlink/af_netlink.c | 86

[RFC 3/3] generic netlink: dynamic multicast groups

2007-07-04 Thread Johannes Berg
Introduce API to dynamically register and unregister multicast groups. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- include/linux/genetlink.h | 13 +++ include/net/genetlink.h | 22 + net/netlink/genetlink.c | 190 -- 3 files changed

Re: multicasting netlink messages to groups 31 from userspace

2007-07-04 Thread Johannes Berg
On Wed, 2007-07-04 at 16:48 +0200, Patrick McHardy wrote: Yes, although in both cases you have no guarantee how long its going to take, someone else could be flooding the receive queue. For userspace this is more likely to be a real problem though since the kernel will keep processing the

Re: multicasting netlink messages to groups 31 from userspace

2007-07-04 Thread Johannes Berg
On Wed, 2007-07-04 at 17:00 +0200, Patrick McHardy wrote: Not by itself probably but a user could DoS your wireless connectivity this way. Hmm, if anything then not the connectivity but rather the MLME i.e. it won't do roaming properly maybe. Maybe we should then have a way to say that

Re: [PATCH] ACPI: export acpi events via generic netlink

2007-07-05 Thread Johannes Berg
On Thu, 2007-07-05 at 16:24 +0800, Zhang Rui wrote: I missed the discussion about the multicast issues. You don't need to reserve a family and group ID for ACPI. I'll rework this on your patches.:) I don't want to hold you, don't worry, I can handle it as well. But I don't know when these

[PATCH] skbuff: remove export of static symbol

2007-07-05 Thread Johannes Berg
skb_clone_fraglist is static so it shouldn't be exported. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- net/core/skbuff.c |1 - 1 file changed, 1 deletion(-) --- wireless-dev.orig/net/core/skbuff.c 2007-07-05 11:30:15.265640003 +0200 +++ wireless-dev/net/core/skbuff.c 2007-07-05

Re: multicasting netlink messages to groups 31 from userspace

2007-07-06 Thread Johannes Berg
On Thu, 2007-07-05 at 15:37 +0200, Patrick McHardy wrote: Earlier filtering makes sense, especially for userspace. The other part exceeds my wireless knowledge :) No worries. I'll see if I can come up with a way to do earlier filtering, but it's not actually required for the functionality. And

Re: multicasting netlink messages to groups 31 from userspace

2007-07-06 Thread Johannes Berg
On Thu, 2007-07-05 at 09:53 -0400, jamal wrote: This email captures the essence of the thread, so let me start here. I dont know if i read well enough all the details, but i think i have a good grasp of the discusion. :) The DoS issue is applicable IMO to any IPC. i.e if i have access to

Re: [PATCH] CXGB3: Replace kcalloc(1,...) with kmalloc() in cxgb3_offload.c.

2007-07-08 Thread Johannes Berg
On Sun, 2007-07-08 at 05:39 -0400, Robert P. J. Day wrote: - t = kcalloc(1, sizeof(*t), GFP_KERNEL); + t = kcalloc(sizeof(*t), GFP_KERNEL); ^ I don't think that's going to work, and shouldn't it probably use kzalloc instead of kmalloc (as you wrote in subject) johannes

Re: [PATCH 2.6.18] WE-21 support (core API)

2006-09-01 Thread Johannes Berg
On Thu, 2006-08-31 at 10:12 -0700, Jean Tourrilhes wrote: And I strongly disagree with your disagrement ;-) You're of course free to do that :) But let me explain. I'm sorry to say it like this, but I hope my work will not be impacted by vaporware. How many drivers are currently

Re: [PATCH 2.6.18] WE-21 support (core API)

2006-09-01 Thread Johannes Berg
On Thu, 2006-08-31 at 19:57 +0200, Michael Buesch wrote: It is. Nobody says different. I think with mainline Johannes meant the wireless-dev tree. Merging nl80211 with softmac would indeed not make sense to me, too. Actually, I do say different. I want softmac to be a consumer of nl80211 too,

Re: [GENL]: Provide more information to userspace about registered genl families

2006-09-01 Thread Johannes Berg
On Fri, 2006-09-01 at 08:22 -0400, jamal wrote: Seems you may be talking about capabilities more than filtering? yes, I had sort of thought filtering would be that, but now that you say it I get the point :) Sorry, I havent had time to look at that code (is it in Daves tree?); No, it's not

Re: [GENL]: Provide more information to userspace about registered genl families

2006-09-03 Thread Johannes Berg
jamal wrote: Could you point me to it? I can look at it over the weekend. I posted it here on netdev, look for nl80211. It may be we need to add another feature to genl to accomodate this. Example by setting a flag to indicate supportability. However, it does sound like this is something

Re: Loop detected - calling function from different modules

2006-09-04 Thread Johannes Berg
Frank, could anyone please give me a hints how dev_queue_xmit() is using tx data queue (HAL_TX_QUEUE_DATA) to transmit data queue. actually I want to use data queue for sending beacon frame, ofcourse not real implementation but for an experiment, a research purpose.. It's probably *far*

Re: BUG in bcm32xx-d80211: sleeping function called with irq's disabled

2006-09-04 Thread Johannes Berg
On Sun, 2006-09-03 at 10:30 -0500, Larry Finger wrote: The patch fixes the problem on my machine. Should I add my name to the signed-off-by list? put Acked-by, you didn't write any of the code and are not passing it on in this case so you don't need to sign it off I guess :) johannes --

Re: [PATCH 2.6.18] WE-21 support (core API)

2006-09-04 Thread Johannes Berg
On Sat, 2006-09-02 at 02:47 +0200, Michael Buesch wrote: And we don't need all this stuff on these devices? OK, nl80211 can easily be made optional, too. Not the whole of nl80211, but I guess some parts for event reporting etc. could be made optional and the functions tiny do-nothing inlines.

Re: [PATCH 2.6.18] WE-21 support (core API)

2006-09-04 Thread Johannes Berg
Uh, please don't strip me from the CC list :) WE-netlink is optional. And WE-ioctl could be made optional (still on the todo list). You can also disable WE-event and WE-iwspy for further footprint reduction. The real question is: Why does removing WE-event reduce footprint? I guess the

Re: [RFC] Alternate WE-21 support (core API)

2006-09-07 Thread Johannes Berg
On Wed, 2006-09-06 at 16:55 -0400, John W. Linville wrote: Is this patch acceptable to the group? Does it make things better? Or worse? Did I leave-out anything that should still go in? Did I take too much? Looks good to me. johannes - To unsubscribe from this list: send the line

Re: roaming support for d80211 stack

2006-09-07 Thread Johannes Berg
On Tue, 2006-09-05 at 17:42 -0700, Mohamed Abbas wrote: Are there any one working on roaming support for d80211 stack? I'm not aware of anyone working on it, but I used to think there was some support. I guess that isn't true then if you need to ask that question :) johannes - To unsubscribe

Re: [RFC] Alternate WE-21 support (core API)

2006-09-11 Thread Johannes Berg
On Fri, 2006-09-08 at 09:13 -0700, Jean Tourrilhes wrote: And I don't believe nl80211 will address legacy driver and non-802.11 hardware. It'd help if you'd tell me what in WE specifically addresses non-802.11 legacy hardware. I don't really see anything that is completely orthogonal. johannes

Re: [PATCH] softmac: Update MAINTAINERS entry

2006-09-13 Thread Johannes Berg
On Tue, 2006-09-12 at 23:37 +0100, Daniel Drake wrote: This mailing list has been deactivated. Eh, and I was so sure I'd checked the maintainers file before deactivating the list. Sorry about that. Acked-by: Johannes Berg [EMAIL PROTECTED] - To unsubscribe from this list: send the line

Re: [RFC] Alternate WE-21 support (core API)

2006-09-13 Thread Johannes Berg
On Tue, 2006-09-12 at 09:17 -0700, Jean Tourrilhes wrote: I was initially very negative towards the WPA API (WPA + extended scan), because it's so complex. I went back and forth with Jouni trying to simplify it, but we did not manage to gain much. I trust that Jouni did the best he

[RFC] genetlink custom attribute type

2006-09-14 Thread Johannes Berg
attribute with a fixed type|length|value structure defined in IEEE 802.11 which ought to be checked when passing an IE from userspace. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- wireless-dev.orig/include/net/netlink.h 2006-09-13 22:06:09.979647141 +0200 +++ wireless-dev/include/net

Re: ieee80211 and devices which decrypt in hardware

2006-09-14 Thread Johannes Berg
On Wed, 2006-09-13 at 18:35 -0400, Daniel Drake wrote: + /* If the device does decryption but leaves the IV in place then we: +* need to kill it. */: + if (!can_be_decrypted (fc IEEE80211_FCTL_PROTECTED)): + hdrlen += 4;: That might work, unless there

Re: [RFC] genetlink custom attribute type

2006-09-14 Thread Johannes Berg
On Thu, 2006-09-14 at 10:14 +0200, Thomas Graf wrote: Looks good, we have to watch the size of struct nla_policy though. This bumps the size from 4 bytes to 16 bytes on 64bit architectures which might become a problem since we always use ATTR_MAX sized arrays. Yes, I'm aware of that, but I

[RFC 1/3] cfg80211/nl80211 core

2006-09-14 Thread Johannes Berg
the NLA_PUT_FLAG patch I did: http://marc.theaimsgroup.com/?l=linux-netdevm=115650333420169w=2 Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- wireless-dev.orig/net/Kconfig 2006-09-13 22:05:53.359647141 +0200 +++ wireless-dev/net/Kconfig2006-09-13 22:06:10.529647141 +0200 @@ -250,6 +250,9

[RFC 2/3] make d80211 use cfg80211

2006-09-14 Thread Johannes Berg
-by: Johannes Berg [EMAIL PROTECTED] --- wireless-dev.orig/net/d80211/Kconfig2006-09-13 22:06:09.209647141 +0200 +++ wireless-dev/net/d80211/Kconfig 2006-09-13 22:06:12.559647141 +0200 @@ -3,6 +3,7 @@ config D80211 select CRYPTO select CRYPTO_ARC4 select CRYPTO_AES

[RFC 3/3] cfg80211 thoughts on configuration

2006-09-14 Thread Johannes Berg
This is some preliminary code how I'm currently thinking (and that might change radically :) ) configuration might look like. It uses the patch I previously posted to make genetlink attributes custom-definable. --- wireless-dev.orig/include/linux/nl80211.h 2006-09-13 22:06:10.539647141 +0200

Re: more nl80211 stuff

2006-09-14 Thread Johannes Berg
On Thu, 2006-09-14 at 09:41 -0400, Dan Williams wrote: Can you describe a bit more what the scope of each of nl80211 and cfg80211 is? Not sure I entirely understand the split and where the line is drawn. Basically, I figured that cfg80211 is the kernel-internal interface and nl80211 is just

RE: [RFC 2/3] make d80211 use cfg80211

2006-09-15 Thread Johannes Berg
Simon, Does the packet injection allow hostapd to use nl80211 instead of the wlan0ap interface to send management frames? It's intended that it does that, yes. Important features for this include requesting a transmit status - i.e. the ability for hostapd/wpa_supplicant to know if the

Re: [RFC 3/3] cfg80211 thoughts on configuration

2006-09-20 Thread Johannes Berg
On Wed, 2006-09-20 at 08:33 +0200, Thomas Graf wrote: I think I brought this up already, it's a lot easier to understand things if you keep it symmetric, i.e. NL80211_CMD_GET_CONFIG triggers sending a NL80211_CMD_NEW_CONFIG. Yes, I think you did :) I'll do that as soon as I get around to

Re: [PATCH 5/7] d80211: indicate if unassociate/radio off status

2006-09-22 Thread Johannes Berg
On Thu, 2006-09-21 at 16:30 -0400, Dan Williams wrote: That's kind a hole in the WE API. In this case, I think, SIOCGIWAP should always return the BSSID of the current association, or none if there is no association. I was never sure if it was a hole or just a lack of clearly defined

Re: [PATCH] d80211: use list_for_each_entry{,_safe}

2006-09-22 Thread Johannes Berg
This patch changes (hopefully!) all occurrences in d80211 of list_for_each to list_for_each_entry (and _safe variants where they were used before). Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- This is the respun patch including no locking changes at all. --- wireless-dev.orig/net/d80211

Re: [PATCH 1/7] d80211: add SIOCSIWTXPOW, SIOCGIWTXPOW, SIOCSIWPOWER and SIOCGIWPOWER

2006-09-22 Thread Johannes Berg
On Fri, 2006-09-22 at 08:24 -0500, Larry Finger wrote: That project is on hold now, but I'm willing to share the information I have and to participate in further developments. The database seems useful, maybe nl80211 could subsume the userspace interface? johannes - To unsubscribe from

Re: [PATCH 1/7] d80211: add SIOCSIWTXPOW, SIOCGIWTXPOW, SIOCSIWPOWER and SIOCGIWPOWER

2006-09-25 Thread Johannes Berg
On Fri, 2006-09-22 at 08:54 -0500, Larry Finger wrote: That sounds perfect as nl80211 seems to be the coming userspace client. Let me know how to help. I'll have to read up on what it actually needs to provide first :) johannes - To unsubscribe from this list: send the line unsubscribe

Re: [PATCH,RFT] ieee80211: Move IV/ICV stripping into ieee80211_rx

2006-09-25 Thread Johannes Berg
might need some changes. Acked-by: Johannes Berg [EMAIL PROTECTED] johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/3] cfg80211/nl80211 core

2006-09-25 Thread Johannes Berg
On Fri, 2006-09-22 at 17:48 +0200, Jiri Benc wrote: On Thu, 14 Sep 2006 12:49:23 +0200, Johannes Berg wrote: There should be support for notifications, but we need to figure out if we remove the sysfs based add/remove virtual interface thing completely or allow the driver to create

Re: bcm43xx driver unstable behaviour (and linux wireless is junk btw)

2006-09-25 Thread Johannes Berg
On Sun, 2006-09-24 at 16:18 +1000, Benjamin Herrenschmidt wrote: So what are the chances of getting this dscape stack merged, let's say... for 2.6.19 ? 0 Or we'll get yet another full release with barely working wireless ? yes. Many locking issues in d80211 to still sort out. Basically,

Re: bcm43xx driver unstable behaviour (and linux wireless is junk btw)

2006-09-25 Thread Johannes Berg
On Mon, 2006-09-25 at 19:58 +1000, Benjamin Herrenschmidt wrote: Doh ! Scary... locking is hard ... if the stuff was written without locking in mind in the first place, it might end up being a nightmare... Yeah, I've actually suggested rewriting it from its own pieces :) But Jiri says he

Re: [RFC] genetlink custom attribute type

2006-09-25 Thread Johannes Berg
On Wed, 2006-09-20 at 08:24 +0200, Thomas Graf wrote: I think its best to use your patch for now and see where this leads to. Alright, should I repost with a proper [PATCH] subject or is it good to take as-is? :) johannes - To unsubscribe from this list: send the line unsubscribe netdev in the

[PATCH] genetlink custom attribute type

2006-09-26 Thread Johannes Berg
attribute with a fixed type|length|value structure defined in IEEE 802.11 which ought to be checked when passing an IE from userspace. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- wireless-dev.orig/include/net/netlink.h 2006-09-13 22:06:09.979647141 +0200 +++ wireless-dev/include/net

Re: [PATCH] ieee80211: quiet TKIP and CCMP replay messages for identical TSCs

2006-09-26 Thread Johannes Berg
the message when there are major differences in the TSC's. Hey, that seems like a good idea to get rid of the messages no one wants to see (in the retransmit case) but still warn if someone is really messing with it. Acked-by: Johannes Berg [EMAIL PROTECTED] johannes - To unsubscribe from

Re: [PATCH] genetlink custom attribute type

2006-09-26 Thread Johannes Berg
On Tue, 2006-09-26 at 11:44 +0200, Thomas Graf wrote: Thinking it over I'm still not completely happy with this. A small subset of all the validation tasks is simply too complex to be put into the policy. The validation of your type value array is such a case, address fields with variable

Re: [patch 09/11] b44: fix eeprom endianess issue

2006-09-26 Thread Johannes Berg
On Mon, 2006-09-25 at 19:59 -0400, Jeff Garzik wrote: Seems like a better solution would be to remove the manual swap from the caller of b44_read_eeprom(). No. You're not looking at the problem from the right angle. The thing is that Broadcom decided to store the EEPROM data as an array of

Re: [patch 09/11] b44: fix eeprom endianess issue

2006-09-27 Thread Johannes Berg
On Tue, 2006-09-26 at 13:00 -0400, Jeff Garzik wrote: False. It's already fixed endian. It's just not the endian you like. No, that's where you're wrong. It isn't fixed endian. It's CPU endian, and the thing overlays a u8 array over CPU endian, hence it's not fixed. johannes - To unsubscribe

Re: softmac mtu

2006-09-28 Thread Johannes Berg
On Wed, 2006-09-27 at 19:17 +0200, matthieu castet wrote: 2304, I think, as that's synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */ Yes but if it is bigger the frame get framented at the 802.11 layer : in theory we could put mtu (IP max packet size) a big as we want

[RFC] cfg80211 and nl80211

2006-09-28 Thread Johannes Berg
-off-by: Johannes Berg [EMAIL PROTECTED] --- This is the I think nl80211 is the future if I don't have to do it all by myself -- johill release. Please take the time to read at least the stuff before the patch. There should be support for notifications, but that isn't currently done as I'm

Re: [PATCH] softmac: Fix WX and association related races

2006-09-28 Thread Johannes Berg
On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote: I'd buy that argument. When the driver gets the deauth message, shouldn't it be sending an IWAP 00:00:00:00:00:00 wireless event to userspace? I thought we did that since a long time now, didn't you actually develop the initial patch?

Re: [PATCH] softmac: Fix WX and association related races

2006-09-28 Thread Johannes Berg
On Thu, 2006-09-28 at 10:37 -0400, Dan Williams wrote: Yes, I think I did. My point here wasn't that the driver is _not_ sending those messages (it almost certainly is), but what's _implied_ by those messages. Namely that, if you're using a tool like wpa_supplicant and/or NM, when you get a

Re: softmac mtu

2006-09-28 Thread Johannes Berg
On Thu, 2006-09-28 at 17:35 +0200, Michael Buesch wrote: I am pretty sure this is the maximum _fragment_ size. But then why does it talk of MPDU and MSDU? from 802.11: synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */ synonym sMaxMpduLng Integer = /* max octets in an

Re: [PATH] Allow mtu bigger than 1500 for ieee80211

2006-09-29 Thread Johannes Berg
On Thu, 2006-09-28 at 19:57 +0200, matthieu castet wrote: + if ((new_mtu 68) || (new_mtu IEEE80211_DATA_LEN)) + return -EINVAL; What's with that lower limit, why 68? johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL

Re: [PATH] Allow mtu bigger than 1500 for ieee80211

2006-09-29 Thread Johannes Berg
On Fri, 2006-09-29 at 11:30 +0200, Joerg Roedel wrote: On Fri, Sep 29, 2006 at 09:38:21AM +0200, Johannes Berg wrote: On Thu, 2006-09-28 at 19:57 +0200, matthieu castet wrote: + if ((new_mtu 68) || (new_mtu IEEE80211_DATA_LEN)) + return -EINVAL; What's with that lower

Re: [RFC] cfg80211 and nl80211

2006-10-02 Thread Johannes Berg
James, Good points. Just a few comments. The EEPROM contents typically represent the configuration and operating parameters which have been tested and certified to be operational. These would represent the only settings which a user can operate with and still be covered by existing

  1   2   3   4   5   6   7   8   9   10   >