On Mon, 2007-03-12 at 10:56 -0700, Jean Tourrilhes wrote:
I did that in the e-mail to Jouni. The problem is that most
people are unfamiliar with decoding iwevents, so can't grasp the
explanation.
Basically, for iwpoint, we have an outer lenght and an inner
length. If they don't
On Tue, Mar 13, 2007 at 08:42:05PM +0100, Johannes Berg wrote:
On Mon, 2007-03-12 at 10:56 -0700, Jean Tourrilhes wrote:
I did that in the e-mail to Jouni. The problem is that most
people are unfamiliar with decoding iwevents, so can't grasp the
explanation.
Basically, for
On Sun, Mar 11, 2007 at 06:40:01PM +0100, Johannes Berg wrote:
On Fri, 2007-03-09 at 13:35 -0800, Jean Tourrilhes wrote:
It's not as bad as it look like. All userspace programs
nowadays use either the iwlib or wpa_supplicant. For example,
NetworkManager gets its stuff through
On Mon, Mar 12, 2007 at 10:56:39AM -0700, Jean Tourrilhes wrote:
I would guess that others use iwlib like that too.
Which others ? The applications that process scan results can
be counted on your fingers. And if you count the one actively
developped, you can use one hand.
Quick
On Mon, Mar 12, 2007 at 10:21:49AM -0800, Jouni Malinen wrote:
On Mon, Mar 12, 2007 at 10:56:39AM -0700, Jean Tourrilhes wrote:
I would guess that others use iwlib like that too.
Which others ? The applications that process scan results can
be counted on your fingers. And if you
On Fri, 2007-03-09 at 13:35 -0800, Jean Tourrilhes wrote:
It's not as bad as it look like. All userspace programs
nowadays use either the iwlib or wpa_supplicant. For example,
NetworkManager gets its stuff through wpa_supplicant, and kdenetwork
uses iwlib. So, in essence, there is only
I'm still not convinced that papering over the problem in userspace is a
real solution.
johannes
Just my 2 cents. I support this. What are the options? I see only
two:
1. Use different magic numbers for 32 bit and 64 bit structures. A
flag is an alternative, but will be more difficult to
On Sunday 11 March 2007 21:11, Ulrich Kunitz wrote:
I'm still not convinced that papering over the problem in userspace is a
real solution.
johannes
Just my 2 cents. I support this. What are the options? I see only
two:
1. Use different magic numbers for 32 bit and 64 bit
On Thu, Mar 08, 2007 at 11:35:26PM +0100, Johannes Berg wrote:
On Thu, 2007-03-08 at 14:11 -0800, Jean Tourrilhes wrote:
First possiblity, we could stick with this band-aid
permanently.
It sucks for various reasons, one for example being that I don't even
understand your recognition
On Fri, Mar 09, 2007 at 01:35:31PM -0800, Jean Tourrilhes wrote:
It's not as bad as it look like. All userspace programs
nowadays use either the iwlib or wpa_supplicant. For example,
NetworkManager gets its stuff through wpa_supplicant, and kdenetwork
uses iwlib. So, in essence, there
On Fri, Mar 09, 2007 at 03:19:22PM -0800, Jouni Malinen wrote:
On Fri, Mar 09, 2007 at 01:35:31PM -0800, Jean Tourrilhes wrote:
It's not as bad as it look like. All userspace programs
nowadays use either the iwlib or wpa_supplicant. For example,
NetworkManager gets its stuff through
On Tue, 2007-03-06 at 18:03 -0800, Jean Tourrilhes wrote:
Ok, please check the patch attached. I don't have a box to
test that on, and on my 32 bit kernel it is not even compiled, but I
believe I got everything all right.
Don't I wish it was that easy... Granted, that does seem to fix
On Thu, 2007-03-08 at 15:39 +0100, Johannes Berg wrote:
Now, I don't know what gcc for ia64 does and I don't have a cross
compiler to check, but on powerpc it does this.
As expected, the same happens on x86_64 (thanks to Michael Wu for the
debug dump):
1e13: Abbrev Number: 17
On Thu, 2007-03-08 at 15:39 +0100, Johannes Berg wrote:
Oh, btw, this also means that we have an information leak on 64-bit
kernels. Those alignment bytes aren't ever cleared or anything, they
come right from the stack since most users of this just use a struct
iw_event on the stack which is
On Thu, Mar 08, 2007 at 03:39:07PM +0100, Johannes Berg wrote:
On Tue, 2007-03-06 at 18:03 -0800, Jean Tourrilhes wrote:
Ok, please check the patch attached. I don't have a box to
test that on, and on my 32 bit kernel it is not even compiled, but I
believe I got everything all right.
On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:
A proper fix would involve forcing the alignement in the
kernel. Unfortunately, that would break 64bit-64bit configs. I think
I can build a workaround for this in iwlib.
Not easily I think. You'd have to get something that has a
On Thu, Mar 08, 2007 at 08:08:29PM +0100, Johannes Berg wrote:
On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:
A proper fix would involve forcing the alignement in the
kernel. Unfortunately, that would break 64bit-64bit configs. I think
I can build a workaround for this in
On Thu, 2007-03-08 at 11:13 -0800, Jean Tourrilhes wrote:
I'm looking into that. The good thing is that we have
redundant information, so we can check that things don't match. It's a
bit more complex because some of those take variable parameters.
Yeah, and it also only happens with
On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:
A proper fix would involve forcing the alignement in the
kernel. Unfortunately, that would break 64bit-64bit configs. I think
I can build a workaround for this in iwlib.
Actually, other tools like network manager, wpa supplicant
On Thu, Mar 08, 2007 at 08:27:22PM +0100, Johannes Berg wrote:
On Thu, 2007-03-08 at 10:49 -0800, Jean Tourrilhes wrote:
A proper fix would involve forcing the alignement in the
kernel. Unfortunately, that would break 64bit-64bit configs. I think
I can build a workaround for this in
On Thu, Mar 08, 2007 at 08:40:01PM +0100, Johannes Berg wrote:
On Thu, 2007-03-08 at 11:34 -0800, Jouni Malinen wrote:
Yes, workaround in just iwlib is not enough. If the only possible
solution is user space workaround, it better be documented (and
communicated to maintainers of user
On Thu, 2007-03-08 at 14:11 -0800, Jean Tourrilhes wrote:
This is exactly what I was pointing out earlier. Well,
actually, there may be ways of fixing it in the kernel, but that would
be real ugly, and I don't want to go there.
Yeah, it would be extremely ugly and involve a lot of
On Thu, 8 Mar 2007 14:11:28 -0800 Jean Tourrilhes wrote:
On Thu, Mar 08, 2007 at 08:40:01PM +0100, Johannes Berg wrote:
On Thu, 2007-03-08 at 11:34 -0800, Jouni Malinen wrote:
Yes, workaround in just iwlib is not enough. If the only possible
solution is user space workaround, it
On Thu, Mar 08, 2007 at 02:17:56PM -0800, Randy Dunlap wrote:
On Thu, 8 Mar 2007 14:11:28 -0800 Jean Tourrilhes wrote:
Third possibility : we declare 32 bit userspace on 64 bit
kernel as not supported and advise users to get a 64 bit
userspace. The number of bug report on that issue
From: Randy Dunlap [EMAIL PROTECTED]
Date: Thu, 8 Mar 2007 14:17:56 -0800
I think that this is not actually an option since
powerpc64 is all 32-bit userspace.
Maybe some other arch-es are like this also (?).
sparc64 is like this too
-
To unsubscribe from this list: send the line unsubscribe
On Thu, 2007-03-08 at 14:11 -0800, Jean Tourrilhes wrote:
First possiblity, we could stick with this band-aid
permanently.
It sucks for various reasons, one for example being that I don't even
understand your recognition code but all userspace programs that use
wext will have to include
On Thu, 2007-03-08 at 14:30 -0800, Jean Tourrilhes wrote:
Then, I assume that the powerpc64 must be using a magic
version of iwconfig to configure wireless interfaces, because I only
ever got one other bug report on the issue. They should have sent the
patch to Johannes, because now I
On Thu, Mar 08, 2007 at 11:22:06PM +0100, Johannes Berg wrote:
On Thu, 2007-03-08 at 14:11 -0800, Jean Tourrilhes wrote:
This is exactly what I was pointing out earlier. Well,
actually, there may be ways of fixing it in the kernel, but that would
be real ugly, and I don't want to go
On Thu, 2007-03-08 at 14:17 -0800, Randy Dunlap wrote:
I think that this is not actually an option since
powerpc64 is all 32-bit userspace.
Maybe some other arch-es are like this also (?).
I think all other architectures except x86_64 and maybe ia64 would
prefer to stay 32-bit for performance
Hi,
Wtf! After struggling with some strange problems with zd1211rw (see some
other mail) I decided to think again about what could possibly cause all
the other problems I'm having with it. The kernel seems fine, but iw*
userspace continually segfaults! And it also seems to be not
reproducible for
On Tue, 2007-03-06 at 02:27 +0100, Johannes Berg wrote:
Actually, I think it may have the same bug, it seems to be operating
with iw_point (or at least its size) too
I'm told that the code that uses it is only internal and the size isn't
part of the userspace interface which makes this wrong.
On Tue, Mar 06, 2007 at 02:27:26AM +0100, Johannes Berg wrote:
Hi,
Wtf! After struggling with some strange problems with zd1211rw (see some
other mail) I decided to think again about what could possibly cause all
the other problems I'm having with it. The kernel seems fine, but iw*
On Tuesday 06 March 2007 18:13, Jean Tourrilhes wrote:
On Tue, Mar 06, 2007 at 02:27:26AM +0100, Johannes Berg wrote:
Hi,
Wtf! After struggling with some strange problems with zd1211rw (see some
other mail) I decided to think again about what could possibly cause all
the other problems
On Tue, Mar 06, 2007 at 07:43:06PM +0100, Michael Buesch wrote:
Yep, and it's even in fs/compat_ioctl.c. Hint, hint ;-)
Ok, it is wrapping the following ioctls:
HANDLE_IOCTL(SIOCGIWRANGE, do_wireless_ioctl)
HANDLE_IOCTL(SIOCSIWSPY, do_wireless_ioctl)
HANDLE_IOCTL(SIOCGIWSPY,
34 matches
Mail list logo
