RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1950587 - "ip address add" gives "Error: any valid prefix is expected rather than" when ipv4 address has 8 or 9 with additional zero in front
Summary: "ip address add" gives "Error: any valid prefix is expected rather than" when...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: iproute
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: Andrea Claudi
QA Contact: Mingyu Shi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-17 02:57 UTC by Zhiqiang Fang
Modified: 2021-04-17 16:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-04-17 16:55:06 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Zhiqiang Fang 2021-04-17 02:57:42 UTC 
Description of problem:

When IPv4 address contains 08 or 09 or 008 or 009, "ip address add" command fails with error "Error: any valid prefix is expected rather than".

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

RHEL DISTRO=RHEL-8.3.1-updates-20210330.1

# uname -r
4.18.0-240.22.1.el8_3.x86_64

# rpm -qa | grep iproute
iproute-5.3.0-5.el8.x86_64
iproute-tc-5.3.0-5.el8.x86_64



How reproducible:

[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.01/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.02/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.03/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.04/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.05/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.06/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.07/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.08/24 dev ens8f0
Error: any valid prefix is expected rather than "1.1.1.08/24".  <<<------08
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.09/24 dev ens8f0
Error: any valid prefix is expected rather than "1.1.1.09/24".  <<<------09
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.010/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.011/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.02.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.03.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.04.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.05.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.06.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.07.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.08.11/24 dev ens8f0
Error: any valid prefix is expected rather than "1.1.08.11/24".  <<<------08
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.09.11/24 dev ens8f0
Error: any valid prefix is expected rather than "1.1.09.11/24".  <<<------09
[root@wsfd-advnetlab36 ls-lr]# 
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.08.9.11/24 dev ens8f0
Error: any valid prefix is expected rather than "1.08.9.11/24".  <<<------08
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.09.9.11/24 dev ens8f0
Error: any valid prefix is expected rather than "1.09.9.11/24".  <<<------09
[root@wsfd-advnetlab36 ls-lr]# ip a a 08.8.8.8/24 dev ens8f0
Error: any valid prefix is expected rather than "08.8.8.8/24".  <<<------08
[root@wsfd-advnetlab36 ls-lr]# ip a a 09.8.8.8/24 dev ens8f0
Error: any valid prefix is expected rather than "09.8.8.8/24".  <<<------09
[root@wsfd-advnetlab36 ls-lr]# ip a a 07.8.8.8/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# 

[root@wsfd-advnetlab36 ls-lr]# ip a a 1.003.11.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.007.11.11/24 dev ens8f0
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.008.11.11/24 dev ens8f0
Error: any valid prefix is expected rather than "1.008.11.11/24".  <<<------008
[root@wsfd-advnetlab36 ls-lr]# ip a a 1.009.11.11/24 dev ens8f0
Error: any valid prefix is expected rather than "1.009.11.11/24".  <<<------009






Steps to Reproduce:
1.
2.
3.

Actual results:

Command "ip address add" fails with error
"Error: any valid prefix is expected rather than" 

Expected results:

The command can be executed successfully.


Additional info:
Comment 1 Andrea Claudi 2021-04-17 16:55:06 UTC 
Hi Zhiqiang, and thanks for reporting this.
As far as it can sound strange, this is the expected behaviour of "ip add address".

Follow me down the rabbit hole.

The function responsible for IPv4 address parsing is get_addr_ipv4(), in lib/utils.c. As you can see, it uses strtoul to parse the IPv4 address from string to four integers, stored in the ap[] array. strtoul returns an unsigned long integer and takes three arguments: a pointer to the string to be parsed, a pointer to store the remainder of the string after the parsing, and the arithmetic base of the unsigned long int to be returned.
Now, looking at the man page, if the base is zero, the number is normally parsed in decimal base, unless the string starts with "0x" (in that case the number will be parsed in base 16), or "0" (in that case the number will be parsed in base 8). This is precisely our case: as soon as you put "0" in front of one of the ipv4 address octects, ip takes it as octal. That is the reason why you can parse "07", but not "08", which is meaningless in base 8. Indeed, if you use "011", you will find it working and converted in "9" in the assigned IP address.

This seems an obvious issue and trivial to fix, simply replacing "0" in strtoul with "10". However, there is an historical reason for iproute to operate in such way. Many years ago, 4.2BSD introduced the inet_aton function to parse ipv4 addresses, which worked exactly in the same way as iproute: you can specify an IPv4 address using exadecimal or octal notation, and expect it to work flawlessly. That function is now the de facto standard for the textual representation of ipv4 addresses[1], and even if there is a inet_pton POSIX equivalent which only work in base 10, we cannot easily change the behaviour of this function without expecting to break who-knows-how-many scripts out there.

For this reason I'm gonna close this as NOTABUG. And thanks for making me discover this interesting story! :)

[1] https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02, page 5
Note You need to log in before you can comment on or make changes to this bug.