On Fri, 2007-09-14 at 09:31 -0600, Eric W. Biederman wrote: > > Now that the network namespace work is in net-2.6.24, I'm wondering how > > wireless will be handling this. Is there any benefit at all to a > > wireless device supporting network namespaces? > > Good question. Network namespaces are designed as a general tool > so if we can support network namespaces in the wireless stack without > killing ourselves there should be value in it. Right. > > Should we, for now, set the new NETIF_F_NETNS_LOCAL flag for all > > mac80211 devices? > > > > If we do want to support moving, then we'll have to make cfg80211 > > (preferably, though mac80211 might be easier at first) migrate *all* > > virtual interfaces associated with the same wiphy because otherwise > > we'll get into trouble when moving one virtual interface and then > > somebody in the other namespace changes its operating channel. > > Ok. This appears at least to be an atomicity issue and possibly more. Yeah, good point, it'd have to move them all at once. > I don't currently understand the way the wireless interfaces interact > well enough to make a judgement call. > > There are two basic usage models I can currently think of. > 1) Super chroot. Where a group of processes has distinct mount, > network, uts, ipc, and pid namespaces. So in this case on the > inside we will only see processes that only belong to our own > network namespace. So in this scenario you get whatever the person > who sets up the environment gives you. > > If one of the network devices only allows access to a subset of > the wireless networking (say just sending packets but not > controlling the radio aspects) I can see and advantage in only > having that device in the restricted network namespace. Right now, there's no way to disallow that, but yes, I can see value in it as well. > 2) Advanced routing. Where someone is doing some weird thing like > testing sending packets and receiving them on the same machine. Not sure I see a point in that with wireless. > Currently creation of a network namespace requires CAP_SYS_ADMIN > and for device movement we only require CAP_NET_ADMIN. So these are > all privileged operations. So the scenario you are concerned about > may just be a "don't do that then". Ok. Sounds good to me. All the radio config requires CAP_SYS_ADMIN as well. > If this doesn't give you enough information to make the call can > you describe for me how the separation of wireless network interfaces > work? Well, basically what we have is one physical device that sends/receives packets. We have multiple options then: * some hardware (no drivers at this time) support multiple virtual devices to associate to multiple different access points, each has a different MAC address too * more importantly, if you have an access point you can put any group of associated stations into a sort of VLAN based on which encryption keys they use for multicast traffic. Each of these VLANs shows up as a local device as well. * Then there's some things like having a monitor interface that sees all traffic etc. but that's not too interesting. * You could have an AP along with a WDS device to enable bridging between multiple APs over wireless, not really interesting either in this context I can mainly see the first and the second points having value in separation. With the first, pending drivers that have multi-MAC address support you could give each namespace one device that can associate to some different AP [1]. And then you could have VLANs on an AP where each VLAN "ends" in a different namespace. johannes [1] though actually, right now, they couldn't associate to the same AP without having weird bugs in mac80211... I have plans to fix this though.
Attachment:
signature.asc
Description: This is a digitally signed message part
