wireless vs. network namespaces (part II)

wireless vs. network namespaces (part II)

[Johannes Berg]

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

Eric,

You wrote, over a year ago:

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

and I was just thinking of doing exactly that :)

When looking into it, though, I noticed that you can generate some
breakage with wireless and network namespaces: you can move a wireless
netdev to a different namespace and then things will break down because
we internally use init_net to find it.

What I'd like to do in wireless is not allow moving netdevs between
namespaces, but rather move entire hardware devices between namespaces,
I see little value and great pain in trying to support virtual
interfaces from a single physical device showing up in different
namespaces, but I do see value in binding a physical device (wiphy) to a
namespace.

As far as I understand, to disallow moving them, I should set the
NETIF_F_NETNS_LOCAL flag on all devices, although that is sort of a
misnomer then because I'd be using it to indicate 'cannot switch
namespace'. 

To really support this though, it seems we need to
 * put the wiphy list into struct net (this is currently a simple
   list_head, no fancy hashing)
 * give each struct wiphy a backpointer to the struct net, like netdev
   in the netdev struct
 * ensure that all netdevs created for this wiphy will have the right
   netns.

The latter part I'm unsure on, alloc_netdev_mq seems to always use
init_net so I can't put them into the right namespace to start with, but
because they're all "in there together" I can't allow switching
namespaces either.. Ideas?

johannes

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

Re: wireless vs. network namespaces (part II)

[Eric W. Biederman]

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

> Eric,
>
> You wrote, over a year ago:
>
>> 2) Advanced routing.  Where someone is doing some weird thing like 
>>    testing sending packets and receiving them on the same machine.
>
> and I was just thinking of doing exactly that :)

Sounds like a fun way to test the wireless stack.
Have both a client and an access point on the same box talking
to each other ;)

> When looking into it, though, I noticed that you can generate some
> breakage with wireless and network namespaces: you can move a wireless
> netdev to a different namespace and then things will break down because
> we internally use init_net to find it.

> What I'd like to do in wireless is not allow moving netdevs between
> namespaces, but rather move entire hardware devices between namespaces,
> I see little value and great pain in trying to support virtual
> interfaces from a single physical device showing up in different
> namespaces, but I do see value in binding a physical device (wiphy) to a
> namespace.

At the moment I don't understand the distinction very well.  Why do we
have both a wireless master device and a wireless device that we
actually use?

In the wired ethernet world there is a lot of value in moving just
a vlan interface or just one mac address with mac vlan into a network
namespace.  Allowing full speed access to the hardware that can do
just about anything while functionally restricting what user space
can do with the hardware.

> As far as I understand, to disallow moving them, I should set the
> NETIF_F_NETNS_LOCAL flag on all devices, although that is sort of a
> misnomer then because I'd be using it to indicate 'cannot switch
> namespace'. 

In this case yes.   It is designed for devices like the loo back
device and other virtual devices that we use for creating virtual
devices.  Although the recent support for creating new network
devices with netlink removes much of the need for the second use case.

It was also designed to handle the case if we do find a network
device that just can't handle being moved between network namespaces.

> To really support this though, it seems we need to
>  * put the wiphy list into struct net (this is currently a simple
>    list_head, no fancy hashing)

Reasonable.

>  * give each struct wiphy a backpointer to the struct net, like netdev
>    in the netdev struct

Reasonable

>  * ensure that all netdevs created for this wiphy will have the right
>    netns.
>
> The latter part I'm unsure on, alloc_netdev_mq seems to always use
> init_net so I can't put them into the right namespace to start with, but
> because they're all "in there together" I can't allow switching
> namespaces either.. Ideas?

alloc_netdev_mq doesn't register the device, so it is a matter of simply
changing the network device pointer after allocation and before registration.

We do this by default when we dynamically create network devices using
netlink.  see rtnl_create_link for an example.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless vs. network namespaces (part II)

[Johannes Berg]

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

On Sat, 2008-09-27 at 18:39 -0700, Eric W. Biederman wrote:

> Sounds like a fun way to test the wireless stack.
> Have both a client and an access point on the same box talking
> to each other ;)

Pretty much. Or mesh networking :)

> > When looking into it, though, I noticed that you can generate some
> > breakage with wireless and network namespaces: you can move a wireless
> > netdev to a different namespace and then things will break down because
> > we internally use init_net to find it.
> 
> > What I'd like to do in wireless is not allow moving netdevs between
> > namespaces, but rather move entire hardware devices between namespaces,
> > I see little value and great pain in trying to support virtual
> > interfaces from a single physical device showing up in different
> > namespaces, but I do see value in binding a physical device (wiphy) to a
> > namespace.
> 
> At the moment I don't understand the distinction very well.  Why do we
> have both a wireless master device and a wireless device that we
> actually use?

The wireless "master" device is just a hack in mac80211, the actual
thing you'd want would be having all interfaces that are on the same
physical hardware to be in one namespace.

> In the wired ethernet world there is a lot of value in moving just
> a vlan interface or just one mac address with mac vlan into a network
> namespace.  Allowing full speed access to the hardware that can do
> just about anything while functionally restricting what user space
> can do with the hardware.

Right, except that wireless really is different in that for one you
can't really usefully have multiple virtual interfaces unless you're
making an AP (and I think it's unlikely you'd want that in an AP, and
even if I'm not willing to support it, it'd be rather complicated); also
you could use each of the interfaces to manipulate PHY parameters like
the channel it's operating on etc. You can still of course operate
software-implemented VLANs on top for different namespaces, but since so
far no hardware that does this in hw/fw has shown up I don't see the
point.

> > As far as I understand, to disallow moving them, I should set the
> > NETIF_F_NETNS_LOCAL flag on all devices, although that is sort of a
> > misnomer then because I'd be using it to indicate 'cannot switch
> > namespace'. 
> 
> In this case yes.   It is designed for devices like the loo back
> device and other virtual devices that we use for creating virtual
> devices.  Although the recent support for creating new network
> devices with netlink removes much of the need for the second use case.
> 
> It was also designed to handle the case if we do find a network
> device that just can't handle being moved between network namespaces.

Ok.

> >  * ensure that all netdevs created for this wiphy will have the right
> >    netns.
> >
> > The latter part I'm unsure on, alloc_netdev_mq seems to always use
> > init_net so I can't put them into the right namespace to start with, but
> > because they're all "in there together" I can't allow switching
> > namespaces either.. Ideas?
> 
> alloc_netdev_mq doesn't register the device, so it is a matter of simply
> changing the network device pointer after allocation and before registration.
> 
> We do this by default when we dynamically create network devices using
> netlink.  see rtnl_create_link for an example.

Ok. So I guess I'd want to write a wrapper for registering the netdev
that puts it into the right namespace for the wireless hardware and sets
the NETIF_F_NETNS_LOCAL flag.

I'll have to experiment a bit I guess.

Thanks,
johannes

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

Re: wireless vs. network namespaces (part II)

[Eric W. Biederman]

>> >  * ensure that all netdevs created for this wiphy will have the right
>> >    netns.
>> >
>> > The latter part I'm unsure on, alloc_netdev_mq seems to always use
>> > init_net so I can't put them into the right namespace to start with, but
>> > because they're all "in there together" I can't allow switching
>> > namespaces either.. Ideas?
>> 
>> alloc_netdev_mq doesn't register the device, so it is a matter of simply
>> changing the network device pointer after allocation and before registration.
>> 
>> We do this by default when we dynamically create network devices using
>> netlink.  see rtnl_create_link for an example.
>
> Ok. So I guess I'd want to write a wrapper for registering the netdev
> that puts it into the right namespace for the wireless hardware and sets
> the NETIF_F_NETNS_LOCAL flag.

> I'll have to experiment a bit I guess.

So you are looking at using NETIF_F_NETNS_LOCAL to indicate that you can't move
one of the devices?

There is an UNREGISTER_NETDEV event and a REGISTER_NETDEV event sent when a device
is moved between namespaces.  See:  dev_change_net_namespace.

I think you would want to look onto those and move one network device when you
move the other, without using NETIF_F_NETNS_LOCAL.

Deletion and creation we have definitely done with paired veth devices.  I haven't
looked at the migration case, but I with a little bit of guarding against recursion
it looks like it probably can be handled.  

Say trigger when your parnter device calls REGISTER_NETDEV in a different network
namespace?

Eric

Re: wireless vs. network namespaces (part II)

[Johannes Berg]

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

On Sun, 2008-09-28 at 22:44 -0700, Eric W. Biederman wrote:

> So you are looking at using NETIF_F_NETNS_LOCAL to indicate that you can't move
> one of the devices?

Yes.

> There is an UNREGISTER_NETDEV event and a REGISTER_NETDEV event sent when a device
> is moved between namespaces.  See:  dev_change_net_namespace.

Yeah, I know.

> I think you would want to look onto those and move one network device when you
> move the other, without using NETIF_F_NETNS_LOCAL.
> 
> Deletion and creation we have definitely done with paired veth devices.  I haven't
> looked at the migration case, but I with a little bit of guarding against recursion
> it looks like it probably can be handled.  
> 
> Say trigger when your parnter device calls REGISTER_NETDEV in a different network
> namespace?

Well, the's no inherent limit on the number of sibling devices, but
various conditions that the core code cannot fulfil because mac80211
also creates this master netdev (though it doesn't actually matter much
which ns it is in I guess). Right now I feel this is just too much to
ask. If anything, then I might want to allow moving a whole radio
("struct wiphy") at some point.

johannes

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

Re: wireless vs. network namespaces (part II)

[Luis R. Rodriguez]

On Sun, Sep 28, 2008 at 12:40:51AM -0700, Johannes Berg wrote:
> On Sat, 2008-09-27 at 18:39 -0700, Eric W. Biederman wrote:
> > In the wired ethernet world there is a lot of value in moving just
> > a vlan interface or just one mac address with mac vlan into a network
> > namespace.  Allowing full speed access to the hardware that can do
> > just about anything while functionally restricting what user space
> > can do with the hardware.
> 
> Right, except that wireless really is different in that for one you
> can't really usefully have multiple virtual interfaces unless you're
> making an AP

Well it may be possible later in STA too, but that is just me looking at
a crystal ball.

> (and I think it's unlikely you'd want that in an AP, and
> even if I'm not willing to support it, 

You mean AP VLANs? I thought you added that code already. I don't
follow.

  Luis

Re: wireless vs. network namespaces (part II)

[Johannes Berg]

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

On Mon, 2008-09-29 at 12:03 -0700, Luis R. Rodriguez wrote:

> > Right, except that wireless really is different in that for one you
> > can't really usefully have multiple virtual interfaces unless you're
> > making an AP
> 
> Well it may be possible later in STA too, but that is just me looking at
> a crystal ball.

Well, it _is_ possible, but not standards compliant ;) Stefano is, I
think, the only person who has ever tested my firmware patch.

> > (and I think it's unlikely you'd want that in an AP, and
> > even if I'm not willing to support it, 
> 
> You mean AP VLANs? I thought you added that code already. I don't
> follow.

Well, I don't see a point in allowing them in different network
namespaces.

johannes

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