netdev - Re: [PATCH iproute2] ip route: Make name of protocol 0 consistent

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: <465f8d0a-9d22-6c8a-b3c5-0d7575911db3@cumulusnetworks.com>
Date:   Tue, 7 Feb 2017 10:00:04 -0700
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH iproute2] ip route: Make name of protocol 0 consistent

On 2/6/17 4:03 PM, David Ahern wrote:
>> This doesn't look like a good solution, you loose the value of unspec.
>>
>> Just to clarify. You added a custom protocol value to netlink.
>> And then you are using upstream iproute2 source to display the value.
> 
> no. I am saying the string displayed for protocol '0' is changing. This
> is all within iproute2 code and files; it has 2 strings for protocol 0:
> 
> lib/rt_names.c:
> static char *rtnl_rtprot_tab[256] = {
>         [RTPROT_UNSPEC]   = "none",
> 
> and the rt_protos file above shows "unspec"
> 
> The presence of a custom protocol triggers the rt_protos file to be read:
> 
> const char *rtnl_rtprot_n2a(int id, char *buf, int len)
> {
>         if (id < 0 || id >= 256) {
>                 snprintf(buf, len, "%u", id);
>                 return buf;
>         }
>         if (!rtnl_rtprot_tab[id]) {
>                 if (!rtnl_rtprot_init)
>                         rtnl_rtprot_initialize();
> 
> 
> Reading the file changes the string in rtnl_rtprot_tab for
> RTPROT_UNSPEC. Both string values -- "none" and "unspec" come from
> iproute2, so my point is that string is inconsistent within iproute2.
> 

You rejected the patch in patchworks. Do you understand my point above?
This is an iproute2 problem. It is the existence of a custom protocol
that triggers the iproute2 bug.