Bug 1477206

Summary:	ip -6 addrlabel return incorrect error message
Product:	Red Hat Enterprise Linux 7	Reporter:	Jaroslav Aster <jaster>
Component:	iproute	Assignee:	Phil Sutter <psutter>
Status:	CLOSED ERRATA	QA Contact:	Jaroslav Aster <jaster>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.4-Alt	CC:	atragler, mcermak
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	iproute-4.11.0-2.el7a	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1100271	Environment:
Last Closed:	2017-11-09 11:25:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jaroslav Aster 2017-08-01 13:16:35 UTC

This issue was fixed in rhel-6 and rhel-7. Rhel-alt-7.4 still has this issue. It is a regression against rhel-7.4.

+++ This bug was initially created as a clone of Bug #1100271 +++

The same problem in rhel7, tested with iproute-3.10.0-13.el7
+++ This bug was initially created as a clone of Bug #1034049 +++

Description of problem:
ip -6 addrlabel return incorrect error message

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. ip -6  addrlabel add prefix 1.1.1.1/24 label 123
2.
3.

Actual results:
Error: an inet prefix is expected rather than "1.1.1.1/24".


Expected results:
Error: an inet6 prefix is expected rather than "1.1.1.1/24".

Additional info:


--- Additional comment from Hangbin Liu on 2013-11-25 20:34:03 EST ---

How about correct the address message at the same time

diff --git a/lib/utils.c b/lib/utils.c
index 4e9c719..eb92414 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -487,7 +487,7 @@ int get_addr(inet_prefix *dst, const char *arg, int family)
                exit(1);
        }
        if (get_addr_1(dst, arg, family)) {
-               fprintf(stderr, "Error: an inet address is expected rather than \"%s\".\n", arg);
+               fprintf(stderr, "Error: an %s address is expected rather than \"%s\".\n", (family == AF_INET6 ? "inet6" : "inet") ,arg);
                exit(1);
        }
        return 0;
@@ -500,7 +500,7 @@ int get_prefix(inet_prefix *dst, char *arg, int family)
                exit(1);
        }
        if (get_prefix_1(dst, arg, family)) {
-               fprintf(stderr, "Error: an inet prefix is expected rather than \"%s\".\n", arg);
+               fprintf(stderr, "Error: an %s prefix is expected rather than \"%s\".\n", (family == AF_INET6 ? "inet6" : "inet") ,arg);
                exit(1);
        }
        return 0;

Comment 2 Phil Sutter 2017-08-01 14:34:39 UTC

Hi Jaroslav,

(In reply to Jaroslav Aster from comment #0)
> This issue was fixed in rhel-6 and rhel-7. Rhel-alt-7.4 still has this
> issue. It is a regression against rhel-7.4.

Following upstream commit broke my fix again:

commit 334af761433685d90790545eb705bfe03ae9d43d
Author: Marco Varlese <marco.varlese>
Date:   Sun Mar 27 10:45:51 2016 -0700

    fix get_addr() and get_prefix() error messages
    
    An attempt to add invalid address to interface would print "???" string
    instead of the address family name.
    
    For example:
    $ ip address add 256.10.166.1/24 dev ens8
    Error: ??? prefix is expected rather than "256.10.166.1/24".
    
    $ ip neighbor add proxy 2001:db8::g dev ens8
    Error: ??? address is expected rather than "2001:db8::g".
    
    With this patch the output will look like:
    $ ip address add 256.10.166.1/24 dev ens8
    Error: inet prefix is expected rather than "256.10.166.1/24".
    
    $ ip neighbor add proxy 2001:db8::g dev ens8
    Error: inet6 address is expected rather than "2001:db8::g".
    
    Signed-off-by: Przemyslaw Szczerbik <przemyslawx.szczerbik>
    Signed-off-by: Marco Varlese <marco.varlese>

I'll try to come up with a solution which solves the problem they tried to fix as well.

Thanks, Phil

Comment 3 Phil Sutter 2017-08-01 16:46:01 UTC

Fix submitted upstream: https://www.mail-archive.com/netdev@vger.kernel.org/msg180281.html

Comment 4 Phil Sutter 2017-08-04 07:06:16 UTC

Upstream accepted:

commit 34705c807a38909247d1bb29ccdffe42e5c1dab3
Author: Phil Sutter <phil>
Date:   Tue Aug 1 18:36:11 2017 +0200

    Really fix get_addr() and get_prefix() error messages
    
    Both functions take the desired address family as a parameter. So using
    that to notify the user what address family was expected is correct,
    unlike using dst->family which will tell the user only what address
    family was specified.
    
    The situation which commit 334af76143368 tried to fix was when 'ip'
    would accept addresses from multiple families. In that case, the family
    parameter is set to AF_UNSPEC so that get_addr_1() may accept any valid
    address.
    
    This patch introduces a wrapper around family_name() which returns the
    string "any valid" for AF_UNSPEC instead of the three question marks
    unsuitable for use in error messages.
    
    Tests for AF_UNSPEC:
    
    | # ip a a 256.10.166.1/24 dev d0
    | Error: any valid prefix is expected rather than "256.10.166.1/24".
    
    | # ip neighbor add proxy 2001:db8::g dev d0
    | Error: any valid address is expected rather than "2001:db8::g".
    
    Tests for explicit address family:
    
    | # ip -6 addrlabel add prefix 1.1.1.1/24 label 123
    | Error: inet6 prefix is expected rather than "1.1.1.1/24".
    
    | # ip -4 addrlabel add prefix dead:beef::1/24 label 123
    | Error: inet prefix is expected rather than "dead:beef::1/24".
    
    Reported-by: Jaroslav Aster <jaster>
    Fixes: 334af76143368 ("fix get_addr() and get_prefix() error messages")
    Signed-off-by: Phil Sutter <phil>

Comment 8 errata-xmlrpc 2017-11-09 11:25:03 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:3172