Hi,
I want to given ip address is valid or not?
i have used function inet_addr. but it show 10.23 as a valid address.
can anybody tell why it shows its a valid ip address?

is there any function for it?


thanks,
ravindra

ravindra.csd@gmail.com wrote:
> Hi,
> I want to given ip address is valid or not?
> i have used function inet_addr. but it show 10.23 as a valid address.
> can anybody tell why it shows its a valid ip address?
>
> is there any function for it?
>
>
> thanks,
> ravindra

I believe that inet_addr converts an IP-Address (1.1.1.1) to a binary
digit.

To confirm if a given IP Address is valid, how about try pinging it.

Regards,
Manish

ravindra.csd@gmail.com wrote:

> I want to given ip address is valid or not?
> i have used function inet_addr. but it show 10.23 as a valid address.
> can anybody tell why it shows its a valid ip address?
>
> is there any function for it?

What is your definition of 'valid'? The answer is to test for whatever
you think it is that makes an IP address valid. I can think of at least
five reasonable definitions of 'valid' for an IP address, and how you
would test for each one is different. For example:

1) An IP address is valid if it is well-formed. That is, it consists of
four numbers between 0 and 255 inclusive separated by dots.

2) An IP address is valid if it is well-formed and not in private IP or
experimental address space. So, 192.168.1.2 is not valid.

3) An IP address is valid if it is well-formed and not in private IP or
experimental address space. But private IP space is valid if this
machine has an interface in that network. So 10.0.3.12 is valid if this
machine is 10.0.3.1/24.

4) An IP address is valid if it's currently reachable over the global
Internet. That is, it's well-formed, not private, multicast, reserved,
or experimental, and a route currently exists for it from the vast
majority of providers.

5) An IP address is valid if it's currently operating a server for the
protocol in which I'm interested on the port in which I'm interested.
For example, if I'm an HTTP client, an IP address is only valid if it
has an HTTP server running on port 80.

And so on.

It should be reasonably obvious how you would test for each of these
various definitions of 'valid', but if you need more , tell us what
you really mean and we can give you suggestions.

DS

In article <1159971615.735863.323450@m73g2000cwd.googlegroups .com>, "David Schwartz" <davids@webmaster.com> writes:
>
> ravindra.csd@gmail.com wrote:
>
>> I want to given ip address is valid or not?
>> i have used function inet_addr. but it show 10.23 as a valid address.
>> can anybody tell why it shows its a valid ip address?
>>
>> is there any function for it?
>
> What is your definition of 'valid'? The answer is to test for whatever
> you think it is that makes an IP address valid. I can think of at least
> five reasonable definitions of 'valid' for an IP address, and how you
> would test for each one is different. For example:
>
> 1) An IP address is valid if it is well-formed. That is, it consists of
> four numbers between 0 and 255 inclusive separated by dots.

0) An IP address is valid if it is well-enough-formed. That is, it
consists of:

a. A number between 0 and 2^32-1
b. A number between 0 and 255 a dot and a number between 0 and 2^24-1
c. A number between 0 and 255, a dot, a number between 0 and 255,
a dot and a number between 0 and 2^16-1
d. Four numbers between 0 and 255 inclusive separated by dots.

M:\>ping 10.23
Pinging 10.0.0.23 with 32 bytes of data:

The three TCP stacks that I had immediately available for testing
(on VMS, Solaris and Windows) all accepted dotted decimal addresses
with fewer than 4 numbers specified.

briggs@encompasserve.org wrote:
> In article <1159971615.735863.323450@m73g2000cwd.googlegroups .com>, "David Schwartz" <davids@webmaster.com> writes:
> >
> > ravindra.csd@gmail.com wrote:
> >
> >> I want to given ip address is valid or not?
> >> i have used function inet_addr. but it show 10.23 as a valid address.
> >> can anybody tell why it shows its a valid ip address?
> >>
> >> is there any function for it?
> >
> > What is your definition of 'valid'? The answer is to test for whatever
> > you think it is that makes an IP address valid. I can think of at least
> > five reasonable definitions of 'valid' for an IP address, and how you
> > would test for each one is different. For example:
> >
> > 1) An IP address is valid if it is well-formed. That is, it consists of
> > four numbers between 0 and 255 inclusive separated by dots.
>
> 0) An IP address is valid if it is well-enough-formed. That is, it
> consists of:
>
> a. A number between 0 and 2^32-1
> b. A number between 0 and 255 a dot and a number between 0 and 2^24-1
> c. A number between 0 and 255, a dot, a number between 0 and 255,
> a dot and a number between 0 and 2^16-1
> d. Four numbers between 0 and 255 inclusive separated by dots.
>
> M:\>ping 10.23
> Pinging 10.0.0.23 with 32 bytes of data:
>
> The three TCP stacks that I had immediately available for testing
> (on VMS, Solaris and Windows) all accepted dotted decimal addresses
> with fewer than 4 numbers specified.


You'll find that most systems also accept octal and hex for each
component with the C "0" and "0x" prefix notations. So 001200000027,
012.027, 0x0a000017, 10.0x17, or even 012.0x17 (my eyes! my eyes!) will
work as well.

On Wed, 04 Oct 2006 06:22:31 -0700, ravindra.csd wrote:

> Hi,
> I want to given ip address is valid or not?
> i have used function inet_addr. but it show 10.23 as a valid address.
> can anybody tell why it shows its a valid ip address?
>
> is there any function for it?
>
>
> thanks,
> ravindra

Ravindra,

Socket API system does not provide an API to validate IP address format.
It is left upto programmer to pass correct IP address (in binary format in
network byte order).

Hence you will have to write your code to validate IP address. Other quick
hack can be by using gethostbyaddr() function. From man page of
gethostbyaddr() (slightly modified).

const char *ipstr = "67.28.24.39";
struct in_addr ip;
struct hostent *hp;

if (!inet_aton(ipstr, &ip)) {
perror("Cannot convert IP address to binary format \n");
exit(-1);
}

if ((hp = gethostbyaddr((const char *)&ip, sizeof ip, AF_INET)) == NULL)
perror("Invalid IP address (since it is unresolvable)\n");

This is really (very) bad hack and will result in unnecessary DNS queries.
Use it only if you are checking for few IP addresses.

Cheers,
Tejas Kokje

Tejas Kokje wrote:
> Socket API system does not provide an API to validate IP address format.
> It is left upto programmer to pass correct IP address (in binary format in
> network byte order).


The inet_addr() function validates and translates an ASCII (dotted) IP
address.

robertwessel2@yahoo.com wrote:
> Tejas Kokje wrote:
> > Socket API system does not provide an API to validate IP address format.
> > It is left upto programmer to pass correct IP address (in binary format in
> > network byte order).
>
>
> The inet_addr() function validates and translates an ASCII (dotted) IP
> address.

Well, I kind of agree that inet_addr (and its friend inet_aton) do
validate IP address format. However I don't fully rely on them since
they tend to consider IP address of the type x.x or x.x.x etc as valid.
If original poster is just interested in parsing IP address format and
considers x.x and x.x.x etc as valid, then inet_addr is good enough.
Other wise she/he needs to make sure that there are atleast 4 does in
the IP address string.


Tejas Kokje

Tejas Kokje wrote:
> > The inet_addr() function validates and translates an ASCII (dotted) IP
> > address.
>
> Well, I kind of agree that inet_addr (and its friend inet_aton) do
> validate IP address format. However I don't fully rely on them since
> they tend to consider IP address of the type x.x or x.x.x etc as valid.
> If original poster is just interested in parsing IP address format and
> considers x.x and x.x.x etc as valid, then inet_addr is good enough.
> Other wise she/he needs to make sure that there are atleast 4 does in
> the IP address string.


As several other posts in this thread have pointed out, those other
formats are commonly considered valid, and have clearly defined and
unambiguous meanings, even if their usage is on the rare side.
Arguably they shouldn't be valid (perhaps especially since they're so
rare*), but most applications, since they usually ultimately call
inet_addr() or one of its friends, have the same behavior.

*mostly the odd forms seem to get used to obscure an IP address,
usually for fraudulent purposes.

In article <1160079335.826924.279700@m73g2000cwd.googlegroups .com>,
"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> wrote:

> Tejas Kokje wrote:
> > > The inet_addr() function validates and translates an ASCII (dotted) IP
> > > address.
> >
> > Well, I kind of agree that inet_addr (and its friend inet_aton) do
> > validate IP address format. However I don't fully rely on them since
> > they tend to consider IP address of the type x.x or x.x.x etc as valid.
> > If original poster is just interested in parsing IP address format and
> > considers x.x and x.x.x etc as valid, then inet_addr is good enough.
> > Other wise she/he needs to make sure that there are atleast 4 does in
> > the IP address string.
>
>
> As several other posts in this thread have pointed out, those other
> formats are commonly considered valid, and have clearly defined and
> unambiguous meanings, even if their usage is on the rare side.
> Arguably they shouldn't be valid (perhaps especially since they're so
> rare*), but most applications, since they usually ultimately call
> inet_addr() or one of its friends, have the same behavior.
>
> *mostly the odd forms seem to get used to obscure an IP address,
> usually for fraudulent purposes.

Are those abbreviated formats actually documented in any RFCs? I.e. is
there any specification that says that x.y should be treated
equivalently to x.0.0.y rather than x.y.0.0? The impression I've had is
that an early implementation used a particular parse of these formats,
and it's simply been copied by most other implementations, but there's
nothing that formally requires them to be recognized.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin wrote:
> Are those abbreviated formats actually documented in any RFCs? I.e. is
> there any specification that says that x.y should be treated
> equivalently to x.0.0.y rather than x.y.0.0? The impression I've had is
> that an early implementation used a particular parse of these formats,
> and it's simply been copied by most other implementations, but there's
> nothing that formally requires them to be recognized.


That's been my impression as well. It's hard to find any example of a
syntax for an IP address in the early RFCs. RFC1738 (early URL), comes
pretty close to specifying the "normal" form in the BNF, although
that's way late. DNS resource records (RFC883) and the host table
format RFC952) also require the normal form, although in a somewhat
limiting context.

My theory has been that it was either a misguided desire to be able to
treat the (classful) host number as unit, or to allow the entry of the
IP address as a single hex (or a hex quad) string, or perhaps to more
directly support some of the mappings between IP address and other
network addresses, and then getting a bit carried away.

In article <1160105660.816455.241830@k70g2000cwa.googlegroups .com>,
"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> wrote:

> Barry Margolin wrote:
> > Are those abbreviated formats actually documented in any RFCs? I.e. is
> > there any specification that says that x.y should be treated
> > equivalently to x.0.0.y rather than x.y.0.0? The impression I've had is
> > that an early implementation used a particular parse of these formats,
> > and it's simply been copied by most other implementations, but there's
> > nothing that formally requires them to be recognized.
>
>
> That's been my impression as well. It's hard to find any example of a
> syntax for an IP address in the early RFCs. RFC1738 (early URL), comes
> pretty close to specifying the "normal" form in the BNF, although
> that's way late. DNS resource records (RFC883) and the host table
> format RFC952) also require the normal form, although in a somewhat
> limiting context.
>
> My theory has been that it was either a misguided desire to be able to
> treat the (classful) host number as unit, or to allow the entry of the
> IP address as a single hex (or a hex quad) string, or perhaps to more
> directly support some of the mappings between IP address and other
> network addresses, and then getting a bit carried away.

I think it also may be related to the migration from the old Arpanet to
the Internet. Arpanet had two-part addresses, which were notated as
x/y, where x was the IMP number and y was the port number the host was
connected to on the IMP (IMPs were the analogues of routers on Arpanet).
After the transition to TCP/IP, Arpanet was assigned net 10, and I
believe all the addresses became 10.x.0.y. I think they may have wanted
to be able to enter them as 10.x.y.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

On 5 Oct 2006 20:34:20 -0700, robertwessel2@yahoo.com <robertwessel2@yahoo.com> wrote:
>
> Barry Margolin wrote:
>> Are those abbreviated formats actually documented in any RFCs? I.e. is
>> there any specification that says that x.y should be treated
>> equivalently to x.0.0.y rather than x.y.0.0? The impression I've had is
>> that an early implementation used a particular parse of these formats,
>> and it's simply been copied by most other implementations, but there's
>> nothing that formally requires them to be recognized.

See below for a partial answer.

> That's been my impression as well. It's hard to find any example of a
> syntax for an IP address in the early RFCs. RFC1738 (early URL), comes
> pretty close to specifying the "normal" form in the BNF, although
> that's way late. DNS resource records (RFC883) and the host table
> format RFC952) also require the normal form, although in a somewhat
> limiting context.

This is interesting and a bit scary.

The Single UNIX Specification, Version 2 documents the inet_addr(3) and
inet_ntoa(3) calls as accepting one to four numbers with dots inbetween, and
that 0 means octal and 0x hexadecimal. I assume it's POSIX, too.

But then there's inet_pton(3), which I'm unsure who standardizes (is it from
Paul Vixie, originally?). The Linux man page explicitly says that "certain
legacy hex and octal formats of AF_INET addresses" are rejected, and also
needs a dotted quad, i.e. four numbers.

So, if I pass around an IP address like "127.0.0.010" (as part of an URL,
maybe) I assume these will be normalized into
127.0.0.8 (inet_ntoa, inet_addr)
127.0.0.10 (inet_pton, naive homegrown parsers)

This seems to me to be a possible source of exploits, if e.g. A and B
communicate by something like SIP through a proxy C, which foolishly tries
to interpret and intercept or log whatever they are doing.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!

Jorgen Grahn wrote:
> On 5 Oct 2006 20:34:20 -0700, robertwessel2@yahoo.com <robertwessel2@yahoo.com> wrote:
> >
> > Barry Margolin wrote:
> >> Are those abbreviated formats actually documented in any RFCs? I.e. is
> >> there any specification that says that x.y should be treated
> >> equivalently to x.0.0.y rather than x.y.0.0? The impression I've had is
> >> that an early implementation used a particular parse of these formats,
> >> and it's simply been copied by most other implementations, but there's
> >> nothing that formally requires them to be recognized.
>
> See below for a partial answer.
>
> > That's been my impression as well. It's hard to find any example of a
> > syntax for an IP address in the early RFCs. RFC1738 (early URL), comes
> > pretty close to specifying the "normal" form in the BNF, although
> > that's way late. DNS resource records (RFC883) and the host table
> > format RFC952) also require the normal form, although in a somewhat
> > limiting context.
>
> This is interesting and a bit scary.
>
> The Single UNIX Specification, Version 2 documents the inet_addr(3) and
> inet_ntoa(3) calls as accepting one to four numbers with dots inbetween, and
> that 0 means octal and 0x hexadecimal. I assume it's POSIX, too.


Not unexpected: that's become the accepted practice for inet_addr() and
friends, and this just documents it. It leaves the question as to why
the developed like it did.


> But then there's inet_pton(3), which I'm unsure who standardizes (is it from
> Paul Vixie, originally?). The Linux man page explicitly says that "certain
> legacy hex and octal formats of AF_INET addresses" are rejected, and also
> needs a dotted quad, i.e. four numbers.


Yep, I suspect many parsers (including a few I've written), are much
stricter about format.


> So, if I pass around an IP address like "127.0.0.010" (as part of an URL,
> maybe) I assume these will be normalized into
> 127.0.0.8 (inet_ntoa, inet_addr)
> 127.0.0.10 (inet_pton, naive homegrown parsers)
>
> This seems to me to be a possible source of exploits, if e.g. A and B
> communicate by something like SIP through a proxy C, which foolishly tries
> to interpret and intercept or log whatever they are doing.


That's pretty much correct. Oddly formed IP addresses seem only useful
in obscuring a URL, and indeed, that seems to be where you see them.
I'll grant a minor exception to a straight 32 bit hex number, which
is occasionally useful (but probably not in a URL). The octal format
is particularly unfortunate, since it's really quite ambiguous. '0x'
for hex for some number of parts other that four are pretty blatant,
but the leading zero is to indicate octal is nasty (I've always though
that was a bad design decision, I don't know if K&R invented it for C,
or got it from elsewhere, but they should have thrown it back).