netdev - Re: [iproute2 net-next v2 0/3] ip netconf improvements

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]

Date:   Wed, 5 Apr 2017 08:18:12 -0400
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org, nicolas.dichtel@...nd.com
Subject: Re: [iproute2 net-next v2 0/3] ip netconf improvements

On 4/4/17 5:39 PM, Stephen Hemminger wrote:
> On Tue, 4 Apr 2017 17:07:31 -0400
> David Ahern <dsa@...ulusnetworks.com> wrote:
> 
>> On 3/23/17 10:51 PM, David Ahern wrote:
>>> Currently, ip netconf only shows data for ipv4 and ipv6 for dumps
>>> and just ipv4 for device requests. Improve the user experience by
>>> using the new kernel patch to dump all address families that have
>>> registered. For example, if mpls_router module is loaded then mpls
>>> values are displayed along with ipv4 and ipv6.
>>>
>>> If the new feature is not supported (new iproute2 on older kernel)
>>> the kernel returns the nlmsg error EOPNOTSUPP which can be trapped
>>> and fallback to existing behavior.
>>>
>>> v2
>>> - fixed index conversion in patch 3 per nicholas' comment
>>>
>>> David Ahern (3):
>>>   netlink: Add flag to suppress print of nlmsg error
>>>   ip netconf: Show all address families by default in dumps
>>>   ip netconf: show all families on dev request
>>>
>>>  include/libnetlink.h |  1 +
>>>  ip/ipnetconf.c       | 36 +++++++++++++++++++++++++-----------
>>>  lib/libnetlink.c     |  3 ++-
>>>  3 files changed, 28 insertions(+), 12 deletions(-)
>>>   
>>
>> Hi Stephen: any comments? are you ok with this change?
> 
> I was holding off until all the upstream commits went through. Other than
> that fine.
> 

I'm not aware of any kernel commits that not in net-next, so I think we
good to go on the kernel side.