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:   Sun, 10 Sep 2017 14:18:47 -0400
From:   Roman Mashak <mrv@...atatu.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>,
        "stephen\@networkplumber.org" <stephen@...workplumber.org>,
        "netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

Nikolay Aleksandrov <nikolay@...ulusnetworks.com> writes:

> On 10/09/17 16:38, Roman Mashak wrote:

[...]

>> Since VLAN info is already in link messages, there is no other option but
>> dump it in monitor or "bridge link show". Yes, the output may be lengthy
>
> To make sure there's no misunderstanding - on GETLINK the vlan info is _not_
> dumped by default (not compressed or otherwise).

Yes, I understand it, I was referring to link events in the previous
comment. However, why not to report compressed vlans for GETLINK by
default if show_details is true, this would be consistent with events monitor.

It seems to be more clear and intuitive from the user's perspective, the
same set of command line options for \monitor' or 'show' commands.

> It is only dumped compressed on port notifications, that is why I suggested to
> use the already present flag (-compressvlans, -c) in order to include that info
> when monitoring or dumping link info, so people watching for the port flags
> (show_details) would not suddenly start getting a lot more and it makes sense
> to dump it only on specific request.
>
>> and hard to digest for a human, that is why I put it under "show_details"
>> kludge - if one is requesting details, he/she should be prepared for
>> large volumes of data to be shown :)
>> 
>> As Nikolay suggested, it'll make sense to request compressed
>> output by default, this will be addresses in v2 patch.
>> 
>> [...]
>>