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
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
On Fri, 2007-06-07 at 12:53 +0200, Johannes Berg wrote:
The genetlink stuff defintely makes sense. I'll have a closer look at
your patches this weekend.
Thanks. I know Zhang Rui will definitely appreciate that too :)
Patrick - please add an ACK from me when you review. The patches
look
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.
To just pick on mentioned issues on the thread which i picked up:
- i think it is fairly usable by netlink to be used as an
Johannes Berg wrote:
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
jamal wrote:
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 :/
Yes, this
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
On Tue, Jul 03, 2007 at 09:51:25PM +0200, Johannes Berg ([EMAIL PROTECTED])
wrote:
Does anybody have any better ideas?
Hi Johannes.
Why don't you want to reserve a set of bits in group number, which means
'allow to work with unpriveledged users', that bits should not cross existing
users
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
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
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 given that
everywhere else we handle multicast groups up to 2^32-1
Johannes Berg wrote:
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
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
Johannes Berg wrote:
On Wed, 2007-07-04 at 16:30 +0200, Patrick McHardy wrote:
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 MSG_DONTWAIT. For multicasts
doing the same would mean
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
Johannes Berg wrote:
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
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
17 matches
Mail list logo
