wireless vs. network namespaces

wireless vs. network namespaces

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

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?

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.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: wireless vs. network namespaces

[Eric W. Biederman]

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:

> 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.

> 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.

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.

2) Advanced routing.  Where someone is doing some weird thing like 
   testing sending packets and receiving them on the same machine.

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".

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?

Eric

Re: wireless vs. network namespaces

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3904 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]