> > > On 8/31/18 10:19 AM, Lorenzo Bianconi wrote: > > >> On 8/31/18 5:43 AM, Lorenzo Bianconi wrote: > > >>> When moving a veth device to another namespace, userspace receives a > > >>> RTM_DELLINK message indicating the device has been removed from current > > >>> netns. However, the other peer does not receive a netlink event > > >>> containing new values for IFLA_LINK_NETNSID and IFLA_LINK veth > > >>> attributes. > > >>> Fix that behaviour sending to userspace a RTM_NEWLINK message in the > > >>> peer > > >>> namespace to report new IFLA_LINK_NETNSID/IFLA_LINK values > > >>> > > >> > > >> A newlink message is generated in the new namespace. What information is > > >> missing from that message? > > >> > > > > > > Hi David, > > > > > > let's assume we have two veth paired devices (veth0 and veth1) on inet > > > namespace. When moving a veth1 to another namespace, userspace is notified > > > with RTM_DELLINK event on inet namespace to indicate that veth1 has been > > > moved to another namespace. However some userspace applications > > > (e.g. NetworkManager), listening for events on inet namespace, are > > > interested > > > in veth1 ifindex in the new namespace. This patch sends a new RTM_NEWLINK > > > event > > > in inet namespace to provide new values for IFLA_LINK_NETNSID/IFLA_LINK > > > > This is in init namespace > > $ ip li set veth2 netns foo > > > > $ ip monitor > > Deleted 20: veth2@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc > > noop state DOWN group default > > link/ether c6:d0:d6:c5:23:7d brd ff:ff:ff:ff:ff:ff new-netns foo > > new-ifindex 20 > > > > It shows the new namespace in the delete message. >
Hi David, I was thinking about the commit 38e01b30563a and then I realized I misread the code yesterday. The commit 38e01b30563a provides all relevant info but it emits the event for veth1 (the device moved in the new namespace). An userspace application will not receive that message if it filters events for just a specific device (veth0 in this case) despite that some device properties have changed (since veth0 and veth1 are paired devices). To fix that behavior in veth_notify routine I emits a RTM_NEWLINK event for veth0. Regards, Lorenzo
