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
