lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <555F9BC8.1040509@ahsoftware.de>
Date:	Fri, 22 May 2015 23:12:40 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Cong Wang <cwang@...pensource.com>
CC:	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	netdev <netdev@...r.kernel.org>, Thomas Graf <tgraf@...g.ch>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v2 0/7] netns: ease netlink use with a lot of
 netns

Am 22.05.2015 um 23:04 schrieb Cong Wang:
> On Fri, May 22, 2015 at 1:50 PM, Alexander Holler <holler@...oftware.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ