inet_pton and cidr addreses - TCP-IP

This is a discussion on inet_pton and cidr addreses - TCP-IP ; I'm changing a program to use the sockets API extended for IPv6 and have run into an issue changing from inet_addr() to inet_pton(). inet_addr() accepts addresses with the cidr form with the mask length on the end, as in "192.168.1.100/24". ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: inet_pton and cidr addreses

  1. inet_pton and cidr addreses

    I'm changing a program to use the sockets API extended for IPv6 and have
    run into an issue changing from inet_addr() to inet_pton(). inet_addr()
    accepts addresses with the cidr form with the mask length on the end, as in

    "192.168.1.100/24".

    However, inet_pton() returns a 0 for that, indicating that "src does not
    contain a character string representing a valid network address in the
    specified address family."

    How is one supposed to handle IP literal addresses of this form with the
    new API?

    thanks
    Chris

  2. Re: inet_pton and cidr addreses

    In article ,
    chris cross wrote:

    >I'm changing a program to use the sockets API extended for IPv6 and have
    >run into an issue changing from inet_addr() to inet_pton(). inet_addr()
    >accepts addresses with the cidr form with the mask length on the end, as in
    >
    > "192.168.1.100/24".
    >
    >However, inet_pton() returns a 0 for that, indicating that "src does not
    > contain a character string representing a valid network address in the
    >specified address family."
    >
    >How is one supposed to handle IP literal addresses of this form with the
    >new API?



    The man pages I have for inet_addr() say nothing about accepting a CIDR
    block. They say that inet_addr() is of type in_addr_t. If inet_addr()
    accepted an address and a netmask or CIDR block size, how would its
    answer for 192.168.1.0/24 differ from its answer for 192.168.1.0/28?
    How would it return the netmask in addition to the address?

    Note also that "192.168.1.100/24" is not a valid CIDR block, because
    100 is not divisible by 256.

    I guess you might have a special inet_addr() that yields 0xc0a80100
    for "192.168.1.100/24" and 0xc0a80164 for "192.168.1.100/30" and
    "192.168.1.100" (assuming a big-endian system). I wouldn't like it.

    There are similar problems with inet_pton(). Its answer is a single
    struct in_addr or "some other internal binary representation, in
    network byte order." There is no place for it to give a netmask.


    Vernon Schryver vjs@rhyolite.com

  3. Re: inet_pton and cidr addreses

    On Thu, 05 Jun 2008 21:39:57 -0400, Barry Margolin wrote:

    > In article ,
    > vjs@calcite.rhyolite.com (Vernon Schryver) wrote:
    >
    >> In article , chris cross
    >> wrote:
    >>
    >> >I'm changing a program to use the sockets API extended for IPv6 and
    >> >have run into an issue changing from inet_addr() to inet_pton().
    >> >inet_addr() accepts addresses with the cidr form with the mask length
    >> >on the end, as in
    >> >
    >> > "192.168.1.100/24".
    >> >
    >> >However, inet_pton() returns a 0 for that, indicating that "src does
    >> >not
    >> > contain a character string representing a valid network address in
    >> > the
    >> >specified address family."
    >> >
    >> >How is one supposed to handle IP literal addresses of this form with
    >> >the new API?

    >>
    >>
    >> The man pages I have for inet_addr() say nothing about accepting a CIDR
    >> block. They say that inet_addr() is of type in_addr_t. If inet_addr()
    >> accepted an address and a netmask or CIDR block size, how would its
    >> answer for 192.168.1.0/24 differ from its answer for 192.168.1.0/28?
    >> How would it return the netmask in addition to the address?

    >
    > I just tried this on my Mac OS X 10.5.3 system, and inet_addr() returns
    > INADDR_NONE when I give it CIDR notation, indicating a malformed
    > address.
    >
    > Maybe the OP's version simply reads until it gets something that's not
    > part of a valid address, so it ignores the "/24" (similar to the way
    > atoi() works).


    To the OP: What Vernon and Barry imply but don't say outright, your
    program is buggy. Fix the program first, then convert.

    M4

  4. Re: inet_pton and cidr addreses

    Thanks for everyone's comments. It made me take a closer look at the
    legacy code I was changing. It in fact was locating the '/' and storing
    a 0 there, lopping off the mask before calling inet_addr().

    thanks again for your help
    Chris

  5. Re: inet_pton and cidr addreses

    On Fri, 6 Jun 2008 01:10:46 +0000 (UTC), Vernon Schryver wrote:
    > In article ,
    > chris cross wrote:
    >
    >>I'm changing a program to use the sockets API extended for IPv6 and have
    >>run into an issue changing from inet_addr() to inet_pton(). inet_addr()
    >>accepts addresses with the cidr form with the mask length on the end, as in

    ....

    > The man pages I have for inet_addr() say nothing about accepting a CIDR
    > block. They say that inet_addr() is of type in_addr_t.


    We discussed the surprising "flexibility" of inet_addr() back in 2006,
    in and around this posting:

    Message-ID: <1161827431.568005.96160@f16g2000cwb.googlegroups.c om>

    Nothing about a.b.c.d/e IIRC, but it might still be interesting reading for
    "criss cross".

    /Jorgen

    --
    // Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!

+ Reply to Thread