Bug 1477206 - ip -6 addrlabel return incorrect error message
ip -6 addrlabel return incorrect error message
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iproute (Show other bugs)
7.4-Alt
All Linux
medium Severity medium
: rc
: ---
Assigned To: Phil Sutter
Jaroslav Aster
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-01 09:16 EDT by Jaroslav Aster
Modified: 2017-11-09 06:25 EST (History)
2 users (show)

See Also:
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 06:25:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:3172 normal SHIPPED_LIVE iproute enhancement update 2017-11-09 11:12:24 EST

  None (edit)
Description Jaroslav Aster 2017-08-01 09:16:35 EDT
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 10:34:39 EDT
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@intel.com>
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@intel.com>
    Signed-off-by: Marco Varlese <marco.varlese@intel.com>

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 12:46:01 EDT
Fix submitted upstream: https://www.mail-archive.com/netdev@vger.kernel.org/msg180281.html
Comment 4 Phil Sutter 2017-08-04 03:06:16 EDT
Upstream accepted:

commit 34705c807a38909247d1bb29ccdffe42e5c1dab3
Author: Phil Sutter <phil@nwl.cc>
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@redhat.com>
    Fixes: 334af76143368 ("fix get_addr() and get_prefix() error messages")
    Signed-off-by: Phil Sutter <phil@nwl.cc>
Comment 8 errata-xmlrpc 2017-11-09 06:25:03 EST
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

Note You need to log in before you can comment on or make changes to this bug.