netdev - Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

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:   Sat, 9 Sep 2017 21:15:24 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Roman Mashak <mrv@...atatu.com>
Cc:     "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH iproute2 3/3] bridge: request vlans along with link
 information

On 09/09/17 20:23, Jamal Hadi Salim wrote:
> On 17-09-09 12:24 PM, Roopa Prabhu wrote:
>> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak <mrv@...atatu.com> wrote:
>>> Signed-off-by: Roman Mashak <mrv@...atatu.com>
>>> ---
>>>   bridge/link.c | 16 +++++++++++++---
>>>   1 file changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/bridge/link.c b/bridge/link.c
>>> index 60200f1..9e4206f 100644
>>> --- a/bridge/link.c
>>> +++ b/bridge/link.c
>>> @@ -461,9 +461,19 @@ static int brlink_show(int argc, char **argv)
>>>                  }
>>>          }
>>>
>>> -       if (rtnl_wilddump_request(&rth, PF_BRIDGE, RTM_GETLINK) < 0) {
>>> -               perror("Cannon send dump request");
>>> -               exit(1);
>>> +       if (show_details) {
>>> +               if (rtnl_wilddump_req_filter(&rth, PF_BRIDGE, RTM_GETLINK,
>>> +                                            (compress_vlans ?
>>> +                                             RTEXT_FILTER_BRVLAN_COMPRESSED :
>>> +                                             RTEXT_FILTER_BRVLAN)) < 0) {
>>> +                       perror("Cannon send dump request");
>>> +                       exit(1);
>>> +               }
>>
>> vlan information is already available with `bridge vlan show`. any
>> specific reason why you want it in
>> the link dump output ?
>>
>>
>> The problem is this might just make the link dump larger and also add
>> too much clutter into the regular link dump output. iproute2 detailed
>> dump is already a bit hard to interpret. And without compression by
>> default, vlan info can just take over the link dump output. It will be
>> hard to look for other link attributes after that :). We deploy with
>> thousands of vlans and without compression even bridge vlan default
>> output is already hard to interpret.
>>
> 
> Agree we should be turning on this stuff by default. i.e default stays
> compressed; otherwise it a huge dump.

I think this should be dumped with the getlink request only on some additional
flag. The getlink does not include these by default.

> 
> Having said that there is a lot of mess with this stuff.
> The bridge link events _already send this IFLA_AF_SPCE info_
> so not much choice  there but to print it.

Right, on NEWLINK per port notification you'll get the compressed vlan info.

> At minimal we need that part because unfortunately there is no
> vlanfilter event in existence which will send us summaries of just
> vlans added to a port i.e both use XXXLINK.

But let's either add a new flag or use -compressvlans to print it when monitoring/showing
link otherwise people who are monitoring only the port flags will start getting lists
with vlans. Even compressed these can still be quite long and confusing, especially
when monitoring.

> In general, the XXXLINK interface with these master devices (bridge,
> bond etc) continues to get messy. Recently started seeing events with
> devices claiming to be of KIND_slave etc on the bridge and bond devices;
> yet at the same time my wireless card events are also showing up on the
> bridge link even though it is not enslaved there..
> 
> cheers,
> jamal
> 
>> Can you please paste a sample default detailed output with your patch
>> with a few hundred vlans ?
>>
>