Bug 176661 - Can't set IP addresses 192.168.2.0?[89]
Can't set IP addresses 192.168.2.0?[89]
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: net-tools (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-28 20:13 EST by sj1
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.60-65
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-30 05:47:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
net-tools-1.60-strip_zeros.patch (1.08 KB, patch)
2006-01-05 04:35 EST, Radek Vokal
no flags Details | Diff

  None (edit)
Description sj1 2005-12-28 20:13:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716

Description of problem:
When I say
    ifconfig eth0 192.168.2.099
or any last component with first digit 0 and last digit 8 or 9
I get the message
    unknown host



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


How reproducible:
Always

Steps to Reproduce:
1. ifconfig eth0 192.168.2.099
2.
3.
  

Actual Results:  unknown host

Expected Results:  (no message)

Additional info:
Comment 1 Radek Vokal 2005-12-29 17:20:36 EST
Really strange. Fixed in rawhide, I've added a function to strip all leading zeros. 
Comment 2 Bernd Eckenfels 2005-12-31 14:00:59 EST
it is not strange, it is RFC conformat: ip addresses are interpreted as octals
if they have leading zero. I dont like this behaviour eighter, but I wont change
it upstream. The lesson from this bug is: never pad ip addresses with zeros, it
is not right :)

# /sbin/ifconfig lo 011.011.011.011
# /sbin/ifconfig lo
lo        Link encap:Local Loopback
          inet addr:9.9.9.9  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
...
# ping 011.011.011.011
PING 011.011.011.011 (9.9.9.9) 56(84) bytes of data.
Comment 3 Radek Vokal 2006-01-01 17:48:10 EST
Thanks for showing me this :)
Comment 4 Bernd Eckenfels 2006-01-01 23:49:26 EST
Oh and yes, the error message should be different.
Comment 5 Radek Vokal 2006-01-02 04:44:40 EST
Closing the bug as NOTABUG to have a correct status on this (the proposed patch
won't be applied). The error message is correct when you know the context ... 
Comment 6 Bernd Eckenfels 2006-01-04 18:58:06 EST
We just have a small discussion, because the leading zero = octal semantic is
not from a rfc but traditional unix libs. inet_ntop() does not allow this syntax
and ip addr interprets it decimally. I tend to also disalloy  leading zeros
because they are not disambiquous enough ->  this will match the bahavour of
recent ip tools which use inet_ntop.
Comment 7 Radek Vokal 2006-01-05 04:35:41 EST
Created attachment 122811 [details]
net-tools-1.60-strip_zeros.patch

So do you vote for changing the current behaviour to a decimal input? Ok,
here's my proposed patch, if you don't have any objections I will include it to
rawhide net-tools. Basically it just strips leading zeros from the IP adress to
make inet_resolve happy.
Comment 8 Bernd Eckenfels 2006-01-05 18:30:21 EST
No, I would reject ip addresses with leading zeros (or with 0x prefix) as syntax
errors and only allow

0
[1-9][0-9]
1[0-9][0-9]
2[0-4][0-9]
25[0-5]

as the exactly four components. Because if you strip the zeros, this will cause
different behavour without an error message. I think I will just use inet_ntop()
in lib/inet.c


Comment 9 sj1 2006-03-25 14:44:40 EST
No fix has happened, to my knowledge.  The bug is still in Fedora Core 5.
Bernd Eckenfels agreed that octal addresses are not in the RFC (see comment
number six), even though he asserted that in comment number 2, and he even
suggested a fix (see comment number 8).  I am guessing the problem is that
this bug was classified as NOTABUG (see comment number 5), which closed it.
I hereby request it be reopened (or whatever the term is), and fixed.
Thank you.
Comment 10 Radek Vokal 2006-03-27 08:06:01 EST
I thought we agreed that this should be kept like it is, it's based on what
inet_addr accepts.

<cite>
All numbers supplied as parts in IPv4 dotted decimal notation may be decimal,
octal, or hexadecimal, as specified in the ISO C standard (that is, a leading 0x
or 0X implies hexadecimal; otherwise, a leading '0' implies octal; otherwise,
the number is interpreted as decimal).
</cite>
Comment 11 sj1 2006-03-27 13:39:28 EST
If you (Radek) thought it should be kept as it is, that would certainly explain
why it was kept as it is.  Instead, I thought we had agreed that it should be
changed/fixed.  Specifically, I thought that Bernd had agreed, in comment six.

He said (the newer library?) "inet_ntop() does not allow this syntax and ip addr
interprets it decimally" (only).  He also said that "leading zeros" "are not
disambiquous enough" and that "recent ip tools" "use inet_ntop" which I
interpreted as a vote/agreement to (have you?) patch net-tool's ifconfig from
using inet_addr to using inet_ntop instead (or whatever the details are, I don't
understand C and C libraries and haven't looked at the source).

I thought that you (Radek) had agreed also, and had proposed a fix (in comment
seven) which Bernd then commented on, in comment eight.  But nothing was ever
posted after that so I just assumed that some fix was happening and would (in
time) appear, in Fedora Core 5.  But it didn't.  Thus my recent query.

I admit that if ifconfig is phased out and never used again (say in Fedora 6 or
Knoppix 5) it won't matter to me if it is ever fixed or not.  I do not have a
good feeling as to whether that is likely or not.

Thank you.
Comment 12 Bernd Eckenfels 2006-03-27 16:19:22 EST
Well, I dont think it is a bug (perhaps it is missing documentation), but I
would accept a patch which removes the octal/hex interpretation.  Which means 
192.168.2.08 would  become an illegal address.
Comment 13 Bernd Eckenfels 2006-03-27 16:19:53 EST
Well, I dont think it is a bug (perhaps it is missing documentation), but I
would accept a patch which removes the octal/hex interpretation.  Which means 
192.168.2.07 would  become an illegal address.
Comment 14 sj1 2006-03-28 01:10:11 EST
Fine.  If you intentionally wrote it that way, I can understand why you don't
consider it a bug.

As I pointed out in my private email message to you both (4 January 2006) I did
not find the word "octal" in RFC1166 ("Internet Numbers") (or base-eight or hex
or anything else), but I did find a mention saying "dotted decimal notation will
be used" and giving an example of "128.009.000.032, or 128.9.0.32" -- which you
claimed to be an error in the RFC itself.  If you are willing to consider the
RFC in error I can understand why you did it your way instead.

Rather than do it your way again, and disallow all leading zeros, why not change
net-tool's "ifconfig" so that it behaves the way that the utility "ip" does?

I have not made an exhaustive check but in these three test cases "ip" accepted
the address: "ip address add 192.168.1.07 dev eth0" and "ip address add
192.168.1.08 dev eth0" and "ip address add 192.168.1.09 dev eth0" (adding the
addresses 192.168.1.7, 192.168.1.8, and 192.168.1.9, respectively).

Why not patch "ifconfig" to behave like "ip" (until it is replaced by "ip" in
the various system-configuration scripts and removed from use, if that is to be
its fate).

Thank you.
Comment 15 Radek Vokal 2006-03-28 02:00:20 EST
(In reply to comment #14)
> I have not made an exhaustive check but in these three test cases "ip" accepted
> the address: "ip address add 192.168.1.07 dev eth0" and "ip address add
> 192.168.1.08 dev eth0" and "ip address add 192.168.1.09 dev eth0" (adding the
> addresses 192.168.1.7, 192.168.1.8, and 192.168.1.9, respectively).
> 
> Why not patch "ifconfig" to behave like "ip" (until it is replaced by "ip" in
> the various system-configuration scripts and removed from use, if that is to be
> its fate).

That's what I proposed in comment #4. The attached patch removes leading zeros
and sets IP address as 'ip' does. I think Bernd would rather see a warning
instead of setting an ip. Would be great to create a voting here, I'm open to
any solution (also the most simple one, keeping it like it is).

Comment 16 Bernd Eckenfels 2006-03-28 02:40:06 EST
Since current ifconfig will set ".011" to .9 it is no good idea to change this
behaviour: there might be actual users for it. If we remove this special
behaviour of 0 and 0x prefix, then ifconfig must fail with a error message and
not accept it.
Comment 17 Bernd Eckenfels 2006-03-28 02:42:02 EST
BTW: i did not write it, this is more than 10 year old code.
Comment 18 Radek Vokal 2006-03-28 02:51:19 EST
(In reply to comment #16)
Ok, than let's keep it as NOTABUG. You admit there should be someone out there
who relies on this option (Yes, it's a crazy world). I will add a note to
ifconfig that it accepts addresses in this form (eg. the note from inet_addr) to
prevent confusion. 
Comment 19 sj1 2006-03-30 04:53:04 EST
OK, if you're going to keep the current behavior I have two suggestions.
Add to your documentation that it is not RFC-compliant and therefore its
use is discouraged and may go away (since if nothing else, when ifconfig
goes away so will the non-conforming behavior).  And second, you might be
thinking of whether you want to insert code such that if anybody actually
does type "011" when a "9" would do (for example) it secretly sends email
off to me or you saying something like "ha, ha, told you somebody used it"
(no, I'm not serious about the second suggestion).
Comment 20 Radek Vokal 2006-03-30 05:47:50 EST
Ok, you've got it. net-tools-1.60-65 in rawhide. I choose the first option, the
second one is already implemented ;) 

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