Search Linux Wireless

Re: wireless vs. network namespaces (part II)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux