Am 22.05.2015 um 23:04 schrieb Cong Wang:
On Fri, May 22, 2015 at 1:50 PM, Alexander Holler <hol...@ahsoftware.de> wrote:
Am 08.05.2015 um 14:02 schrieb Eric W. Biederman:


So I am dense.  I have read through the patches and I don't see where
you tag packets from other network namespaces with a network namespace
id.


Me too,

I've recently written a little tool called snetmanmon (source is
available at github) to monitor and handle network related events
by using rtnetlink.

Having seen this patch series (thanks!), I've played with it.

I've applied the patch series to v4.1-rc4.

Maybe I'm using or holding it wrong, but I've some comments.

First I think if NETLINK_LISTEN_ALL_NSID is enabled, a dump
of the interfaces through RTM_GETLINK together with NLM_F_DUMP and
NLM_F_REQUEST should return all interfaces of all reachable namespaces.

Next, if NETLINK_LISTEN_ALL_NSID is enabled, I receive RTM_NEWLINK
but without any indication of the namespace. E.g. if I do
         ip netns add netns1
         ip netns exec netns1 brctl addbr br0
the RTM_NEWLINK for br0 (received in the root ns, not netns1) doesn't
have the attribute IFLA_LINK_NETNSID.


Bridge doesn't have an underlying link, so no LINK_NETNSID. LINK_NETNSID
is only added when its underlying link is in a different netns.

I'm using "link" similiar as interface. Maybe I've no idea what the attribute LINK:NETSID really means, but I've understood it as the one attribute which indicates the namespace an interface (or link), br0 in my example, lives in.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to