Le 02/10/2017 à 13:11, Jason A. Donenfeld a écrit : > On Mon, Oct 2, 2017 at 11:32 AM, Nicolas Dichtel > <nicolas.dich...@6wind.com> wrote: >> 1. Move the process to netns B, open the netlink socket and move back the >> process to netns A. The socket will remain in netns B and you will receive >> all >> netlink messages related to netns B. >> >> 2. Assign a nsid to netns B in netns A and use NETLINK_LISTEN_ALL_NSID on >> your >> netlink socket (see iproute2). > > Both of these seem to rely on the process knowing where the device is > being moved and having access to that namespace. I don't think these > two things are a given though. Unless I'm missing something? I didn't understand correctly. Your control process cannot monitor or control an interface which is in a unkown/hidden netns. But x-netns interfaces are special. We already add a way to identify peer netns for this kind of interfaces. If an handler get_link_net was added to the rtnl_link_ops of the tun driver, it will help to identify netns A when you are in netns B. But you need the opposite. I already try a patch to advertise via netlink the dst netns when an interface moves to a new netns. I think that it is valid for x-netns interfaces. As soon as you can identify the dst netns, your problem is solved, right?
Nicolas
