On 07/30/10 08:21 PM, Ethan Quach wrote:
On 07/30/10 10:07, Dave Miner wrote:
On 07/30/10 07:03 AM, [email protected] wrote:
Hi Dave,
My apologies, I don't believe I sent a follow-up to this input. Please
see below.
Thank you,
Clay
On Wed, 21 Jul 2010, Dave Miner wrote:
On 07/21/10 08:13 PM, [email protected] wrote:
Reading the comments in the modification, this seems misguided. We
don't need to provide for a non-CIDR notation at all; users who for
some reason desire to set this to a single address can always use
/32.
They can use a /32 but unfortunately the underlying SMF data type also
supports either an IP or a CIDR notated network address.
Just because the underlying SMF type allows for that doesn't mean you
have to accept all possibilities. Or, perhaps make a single address an
implicit /32 and then the algorithm applies, but I still think that's
less than ideal.
I agree they can use a /32 but it's easy enough to support a straight IP
as well; many folks have thought of a straight IP in testing these bits
before trying a CIDR notation.
So you are making absence of a prefix imply a /32? OK, but ensure the
documentation covers this.
Also, the range checking is necessary for the CIDR notated values.
(E.g.
is network 192.168.0.1/24 in the range of 0.0.0.0/0; though perhaps
I'm
missing something?)
Range checking is implicit in AND'ing two addresses against a prefix
length and comparing for equality of the results. Really, that's all
you have to do.
I agree that AND'ing would be easier, however, I haven't gotten a good
handle on KSH93 alternative bases, for example, they seem a bit off:
ad...@opensolaris:~$ typeset -i2 a=192168001001
ad...@opensolaris:~$ print $a
2#1111111111111111111111111111111110111110000110101111110111101001
ad...@opensolaris:~$ bc -l
obase=2
192168001001
10110010111110000110101111110111101001
Perhaps I'm missing something as to why this doesn't match. (Overflow?)
For now we have working code but in the future, it might reasonably be
made more simple for maintainability or just converted into Python as
desired where this can be made much more straightforward.
Perhaps you shouldn't try to do multi-base math at 5:00 AM. You of
course need to convert each octet individually, not by concatenating
them as one number. The hex version is C0A80101, which is:
11000000101010000000000100000001
Really, this shouldn't take much; there's already a get_network
function in installadm-common.sh. Perhaps you can just use it with a
simple string comparison of results.
I think this would work. However to use get_network, the netmask
needs to be in hex format. Given that we are starting with a CIDR
prefixlen (bits) form of a netmask, we'd have to convert that to hex
to be able to use it.
I was talking to Clay about this offline. The simplest way to do this
would be a single call to bc(1) to convert the bit form to hex from, then
do as you suggested above.
This would enable the removal of the new calculate_net_addrs()
function altogether.
Does this sound reasonable?
Mostly, though I think get_network() can easily be adapted to do this
conversion internally. The point here is to not have two functions that
do essentially the same thing.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
