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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 9 Sep 2017 22:28:00 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Roman Mashak <mrv@...atatu.com>,
        "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 Sat, Sep 9, 2017 at 11:15 AM, Nikolay Aleksandrov
<nikolay@...ulusnetworks.com> wrote:
> 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>
>>>> ---
>

[snip]

>>>
>>> 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.

yes agree. It will add too much clutter to the monitor output too.

Powered by blists - more mailing lists