Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: ospf{,6}d: replace inet_aton with inet_pton
To:
Theo de Raadt <deraadt@openbsd.org>, Tom Smyth <tom.smyth@wirelessconnect.eu>, tech <tech@openbsd.org>
Date:
Thu, 22 Aug 2024 16:32:49 +0100

Download raw body.

Thread
  • Claudio Jeker:

    ospf{,6}d: replace inet_aton with inet_pton

  • On 2024/08/22 16:06, Claudio Jeker wrote:
    > On Thu, Aug 22, 2024 at 07:51:04AM -0600, Theo de Raadt wrote:
    > > Tom Smyth <tom.smyth@wirelessconnect.eu> wrote:
    > > 
    > > > so Arista and Cisco say area id is a 32 bit value  0-(2^32)-1   expressed as a number
    > > > or dotted decimal IP 
    > > 
    > > Sure, but "dotted decimal IP" is a pretty vague term, because everyone inherited
    > > the same flawed pre-cidr conversion functions.  That vagueness is the problem.
    > > 
    > > So therefore it seems more important that we know it isn't used in practice.
    > > That seems to have been checked, and I think we can rush ahead now.  Also,
    > > if someone runs into this, their non-strict area can easily be edited into a
    > > the strict numeric form, so there's no real hazard here, the whole 32-bit numeric
    > > range remains useable.
    > 
    > Yes, the question is if people use an area id of 1.2 or 1.2.3 and expect it to
    > work. ospfd now longer accepts those and that is good so.
    > 
    > I think common practice is to use 0.0.0.0 or 0 and other areas as a.b.c.d
    > at least that is what I have seen.
    
    0.0.0.0, 0, 51, and other areas as a.b.c.d. :-)
    
    
    
  • Claudio Jeker:

    ospf{,6}d: replace inet_aton with inet_pton