On Fri, 2011-03-04 at 11:06 -0800, Javier Cardona wrote: > On Fri, Mar 4, 2011 at 3:37 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Thu, 2011-03-03 at 19:11 -0800, Thomas Pedersen wrote: > >> From: Javier Cardona <javier@xxxxxxxxxxx> > > > > [...] > > > > If you manage stations in userspace, then this code is unnecessary. > > That'd be a big win in my eyes. The only thing the kernel would need to > > know is not to create station entries, right? > > If userspace manages only rsn mesh stations then we do still need > this. That would be my preference: only require an authentication > daemon if you intend to join a secure mesh. In the same way that you > can connect to an open AP without a daemon. > Would you object to this approach? No, I wouldn't, but I don't see why you'd still need this? I'm not sure exactly how all this works, but conceptually, is there anything wrong with this: * when creating the mesh, you'd say "this is a secure mesh" * when an auth frame is received, you just pass it to userspace, as you already have * userspace is responsible for adding/removing stations * the kernel doesn't need to parse RSN since if it's a secure mesh it will know because userspace said it was Actually, looking at your patch in more detail, it would seem like it allows somebody to hijack the mesh by pretending it is an open network. If the RSN IE isn't present, mesh_neighbour_update() gets passed false for the rsn_enabled parameter -- even if the mesh should be secure -- and then the peer would be allowed to join just because it said it didn't support RSN. Surely in that case it shouldn't be allowed to join? Maybe I'm not reading this correctly. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
