[Bro] string to address issue w/ is_v6_addr

[Mike Dopheide]

Thanks for the background!   Looks like what I need is is_valid_ip() from
base/utils/addrs.bro.

Problem was I was starting with a string that could be an IP or could be a
hostname.

-Dop

On Wed, Apr 1, 2015 at 1:08 PM, Siwek, Jon <jsiwek at illinois.edu> wrote:

>
> > On Apr 1, 2015, at 12:03 PM, Mike Dopheide <dopheide at gmail.com> wrote:
> >
> > This confused me for quite some time this morning so I thought I'd
> share.  The script should make it clear, but when attempting to take a url
> string and test to see if it's a valid address, the output from to_addr
> creates a 'valid' ipv6 address.
> >
> > Is that a requirement for some reason internally?
>
> to_addr() returning the unspecified IPv6 address on failure to convert an
> IP string to Bro’s address type is just an arbitrary choice.
> Alternatively, it could return the unspecified IPv4 address, 0.0.0.0, but
> that doesn’t really save anything — internally Bro’s address values all use
> a full 128 bits (IPv4 uses the "IPv4-mapped IPv6” representation).  It
> could also return a record type:
>
>         type opt_addr: record { a: addr &optional; };
>
> or
>
>         type opt_addr: record { a: addr; success: bool; };
>
> Where in the first, it only sets the field if the conversion succeeded,
> but failure to check for that fields existence before accessing is
> potentially more problematic than failure to check for [::].   In either,
> it’s adding another data type the user has to remember or lookup how to use.
>
> So that’s the backstory of why [::] is the failure indicator.  One could
> also argue that using the unspecified IPv6 address (or IPv4) as a return
> value makes it ambiguous to try to parse “::” (or “0.0.0.0”) as the input
> string and I’d be on board w/ that and vote to switch to one of the
> return-a-record styles.
>
> Anyway, from the example you gave, did you just mean to use
> “lookup_hostname” instead of “to_addr” ?
>
> - Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150401/85683cb0/attachment.html