Bug 176661

Really strange. Fixed in rawhide, I've added a function to strip all leading zeros. 

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.

Thanks for showing me this :)

Oh and yes, the error message should be different.

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 ... 

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.

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.

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

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.

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>

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.

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.

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.

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.

(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).

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.

BTW: i did not write it, this is more than 10 year old code.

(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. 

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).

Ok, you've got it. net-tools-1.60-65 in rawhide. I choose the first option, the
second one is already implemented ;)