27 Apr
2011
27 Apr
'11
12:50 p.m.
Hi, AFAIK SR doesn't provide a way to binary compare two IPv6 (correct
me if I'm wrong). About IPv4 comparison, I assume it's compared as a
string:
if ($rd == "1.2.3.4")
so it works. But in case of IPv6 it would not work as the same IPv6
could take different (but equivalent) representations:
"1080:0000:0000:0000:0008:0800:200C:417A"
"1080:0:0:0:8:800:200C:417A"
"1080::8:800:200C:417A"
I'd like to add a function to perform IPv6 binary comparison (as I've
already coded it in a personal project), could you please tell me in
which module should it take place? I mean something as:
--------------------------------------------------------------------------
compare_ips(ip1, ip2)
Returns 1 if both IP's are two equal IPv4 or two equal IPv6.
Returns -1 if both IP's are valid but not equal.
Returns -2 if at least one give IP is not a valid IPv4 or IPv6.
Parameters:
- ip1: An string of pv containing a IPv4 or IPv6 in text representation.
- ip2: An string of pv containing a IPv4 or IPv6 in text representation.
--------------------------------------------------------------------------
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
27 Apr
27 Apr
12:59 p.m.
2011/4/27 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
I'd like to add a function to perform IPv6 binary
comparison (as I've
already coded it in a personal project), could you please tell me in
which module should it take place?
I wouldn't like to include it in utils module as it's becoming an ugly
mix of functions:
4.1. http_query(url, result)
4.2. xcap_auth_status(watcher_uri, presentity_uri)
4.3. is_int(pvar)
and the code becomes ugly with so many unrelated and mixed variables
and functions.
Perhaps would it make sense a new module "ip_utils"? I would also
include more methods as:
- is_valid_ip(IP)
- is_valid_ipv4(IP)
- is_valid_ipv6(IP)
So, is it ok if I create a new module called "ip_utils"?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:56 p.m.
Iñaki Baz Castillo writes:
So, is it ok if I create a new module called
"ip_utils"?
inaki,
i vote against creating yet another utils module. since you are
comparing texts, put it is texops module.
if one address is ipv4 and the other ipv6 representation of ipv4 address
(i think there is one), will the comparison return true?
-- juha
3:33 p.m.
2011/4/27 Juha Heinanen <jh(a)tutpro.com>om>:
i vote against creating yet another utils module.
since you are
comparing texts, put it is texops module.
Hi Juha, I'm coding functions to check wheter the given string/pv is a
IPv4, IPv6, IPv6_reference, compare IP's and so. It can be used to
check a string obtained from a DB or whatever, not just from the SIP
message. Also note that checking $si (message source IP) has nothing
to do with textops module.
In fact, I'm thinking right now that the most suitable solution would
be create a library providing such functions so any other module could
internally use them (i.e. LCR for a future IPv6 addition). Opinions?
if one address is ipv4 and the other ipv6
representation of ipv4 address
(i think there is one), will the comparison return true?
No, it would return false. I don't see the point in comparing a IPv4
against its IPv6 representation and returning true, is it really
useful for our scenarios?
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:44 p.m.
Iñaki Baz Castillo writes:
i don't know, since i have not used ipv6 myself in sip router.
-- juha
In fact, I'm thinking right now that the most
suitable solution would
be create a library providing such functions so any other module could
internally use them (i.e. LCR for a future IPv6 addition). Opinions?
ip_addr.h already has ip_addr_cmp function. may be it could be enhanced
to also compare ipv6 addresses.
if one address
is ipv4 and the other ipv6 representation of ipv4 address
(i think there is one), will the comparison return true?
No, it would return false. I don't see the point in comparing a IPv4
against its IPv6 representation and returning true, is it really
useful for our scenarios?
4:15 p.m.
2011/4/27 Juha Heinanen <jh(a)tutpro.com>om>:
I'll take a look to it and comment later. Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
In fact,
I'm thinking right now that the most suitable solution would
be create a library providing such functions so any other module could
internally use them (i.e. LCR for a future IPv6 addition). Opinions?
ip_addr.h already has ip_addr_cmp function. may be it could be enhanced
to also compare ipv6 addresses.
5:05 p.m.
ip_addr.h
already has ip_addr_cmp function. may be it could be enhanced
to also compare ipv6 addresses.
I'll take a look to it and comment later. Thanks.
3:24 p.m.
Iñaki Baz Castillo writes:
Hi Juha. After reviewing it, it seems that ip_addr.h
just contains
functions to operate with IP/socket structs rather than text
representations, so it's not exactly what I need.
So please let me initially create a module "ipops" with the suggested
functions. Later we can discuss how to move it into a library or
ip_addr.h.
i still don't like the idea of having yet another module. if you
operate on text (as you say in above), i don't see what is wrong with
textops module or existing utils module.
-- juha
28 Apr
28 Apr
10:55 a.m.
On Wednesday 27 April 2011, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
Hello,
i like to also not see much more of this small utility modules, in the end its
just a text operation, as you've said.
Another question, have you thought about extending the existing "equals"
operator that it works also for IPv6 address? Just like for IPv4 addresses
where it already understands network masks, e.g.:
if ($si == 192.168.1.1/32) {..}
if ($si == 192.168.1.1) {..}
it could do this binary comparison inside as well for v6.
Henning
Hi Juha. After reviewing it, it seems that
ip_addr.h just contains
functions to operate with IP/socket structs rather than text
representations, so it's not exactly what I need.
So please let me initially create a module "ipops" with the suggested
functions. Later we can discuss how to move it into a library or
ip_addr.h.
i still don't like the idea of having yet another module. if you
operate on text (as you say in above), i don't see what is wrong with
textops module or existing utils module.
11:27 a.m.
2011/4/28 Henning Westerholt <henning.westerholt(a)1und1.de>de>:
Hello,
i like to also not see much more of this small utility modules, in the end its
just a text operation, as you've said.
Ok. I'm coding it right now in a new module but just for testing
purposes (which is easier than modify existing core parts).
Another question, have you thought about extending the
existing "equals"
operator that it works also for IPv6 address? Just like for IPv4 addresses
where it already understands network masks, e.g.:
if ($si == 192.168.1.1/32) {..}
if ($si == 192.168.1.1) {..}
it could do this binary comparison inside as well for v6.
Interesting. However, in case the second argument is a pv (i.e.
retrieved from a DB) "equal" operator would not work as expected, am I
right?
This is the reason I'm coding a function "compare_ips" which allow
IPv4, IPv6, IPv6-reference (string or pv).
Maybe another function could be created: is_ip_in(IP, NETWORK)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:35 a.m.
On 4/28/11 11:27 AM, Iñaki Baz Castillo wrote:
2011/4/28 Henning
Westerholt<henning.westerholt(a)1und1.de>de>:
As mentioned in previous email, not even the above syntax should work as
expected -- it would be a surprise, maybe due to ser enhancements. But a
pseudo-variable in the left side implies string or integer comparison.
But for sure when it is a PV in the right side, then it is not working.
Btw, when was the idea that IP comparison is string comparison thrown
here, I missed any email?!? To be sure the comparison is done right,
then the string with the IPs have to be converted to binary and the
results compared.
Cheers,
Daniel
Hello,
i like to also not see much more of this small utility modules, in the end its
just a text operation, as you've said.
Ok. I'm coding it right now in a
new module but just for testing
purposes (which is easier than modify existing core parts).
Another question, have you thought about
extending the existing "equals"
operator that it works also for IPv6 address? Just like for IPv4 addresses
where it already understands network masks, e.g.:
if ($si == 192.168.1.1/32) {..}
if ($si == 192.168.1.1) {..}
it could do this binary comparison inside as well for v6.
Interesting. However, in
case the second argument is a pv (i.e.
retrieved from a DB) "equal" operator would not work as expected, am I
right? This is the reason I'm coding a function
"compare_ips" which allow
IPv4, IPv6, IPv6-reference (string or pv).
Maybe another function could be created: is_ip_in(IP, NETWORK)
11:53 a.m.
2011/4/28 Daniel-Constantin Mierla <daniel(a)kamailio.org>rg>:
Btw, when was the idea that IP comparison is string
comparison thrown here,
I missed any email?!? To be sure the comparison is done right, then the
string with the IPs have to be converted to binary and the results compared.
The point is that IPv4 comparisons are valid as a pure string
comparison. Note that being strict, the following IPv4 is not valid:
"1.2.3.04"
See RFC 5954 "Essential Correction for IPv6 ABNF and URI Comparison in
RFC 3261":
IPv4address = dec-octet "." dec-octet "." dec-octet
"." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
So comparing two IPv4 as pure strings would work (except if you want
to perform network comparison with mask and so).
Obviously under IPv6 binary comparison is needed (this is what my
function does).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:02 p.m.
2011/4/28 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Obviously under IPv6 binary comparison is needed (this
is what my
function does).
Let me a related question:
An IPv6 looks like "1080::8:800:200C:417A", but when using it in a URI
it must be set as IPv6-reference (between [ ]):
[1080::8:800:200C:417A]
Imagine I do:
$rd = "1080::8:800:200C:417A";
$dd = "1080::8:800:200C:417A";
$rd = "[1080::8:800:200C:417A]";
$dd = "[1080::8:800:200C:417A]";
Would SR handle correctly all these cases?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:10 p.m.
On 4/28/11 12:02 PM, Iñaki Baz Castillo wrote:
2011/4/28 Iñaki Baz Castillo<ibc(a)aliax.net>et>:
you have to give the proper format,
enclosed in square brackets. The
assignments above are just string value settings.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Obviously under IPv6 binary comparison is needed
(this is what my
function does).
Let me a related question:
An IPv6 looks like "1080::8:800:200C:417A", but when using it in a URI
it must be set as IPv6-reference (between [ ]):
[1080::8:800:200C:417A]
Imagine I do:
$rd = "1080::8:800:200C:417A";
$dd = "1080::8:800:200C:417A";
$rd = "[1080::8:800:200C:417A]";
$dd = "[1080::8:800:200C:417A]";
Would SR handle correctly all these cases?
12:18 p.m.
2011/4/28 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Thanks for clarify it.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Imagine I do:
$rd = "1080::8:800:200C:417A";
$dd = "1080::8:800:200C:417A";
$rd = "[1080::8:800:200C:417A]";
$dd = "[1080::8:800:200C:417A]";
Would SR handle correctly all these cases?
you have to give the proper format, enclosed in square brackets. The
assignments above are just string value settings.
12:05 p.m.
On 4/28/11 11:53 AM, Iñaki Baz Castillo wrote:
2011/4/28 Daniel-Constantin
Mierla<daniel(a)kamailio.org>rg>:
yes, that was the point to compare
network addresses with mask,
otherwise '==' can be used for string comparisons, no matter what it is
inside, ip address, username, a.s.o.
Cheers,
Daniel
Btw, when was the idea that IP comparison is
string comparison thrown here,
I missed any email?!? To be sure the comparison is done right, then the
string with the IPs have to be converted to binary and the results compared.
The
point is that IPv4 comparisons are valid as a pure string
comparison. Note that being strict, the following IPv4 is not valid:
"1.2.3.04"
See RFC 5954 "Essential Correction for IPv6 ABNF and URI Comparison in
RFC 3261":
IPv4address = dec-octet "." dec-octet "." dec-octet
"." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
So comparing two IPv4 as pure strings would work (except if you want
to perform network comparison with mask and so).
Obviously under IPv6 binary comparison is needed (this is what my
function does).
12:10 p.m.
On 4/28/11 11:53 AM, Iñaki Baz Castillo wrote:
2011/4/28 Daniel-Constantin
Mierla<daniel(a)kamailio.org>rg>:
yes, that was the point to be able
compare network addresses with mask,
otherwise '==' can be used for string comparisons, no matter what it is
inside, ip address, username, a.s.o.
Cheers,
Daniel
Btw, when was the idea that IP comparison is
string comparison thrown here,
I missed any email?!? To be sure the comparison is done right, then the
string with the IPs have to be converted to binary and the results compared.
The
point is that IPv4 comparisons are valid as a pure string
comparison. Note that being strict, the following IPv4 is not valid:
"1.2.3.04"
See RFC 5954 "Essential Correction for IPv6 ABNF and URI Comparison in
RFC 3261":
IPv4address = dec-octet "." dec-octet "." dec-octet
"." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
So comparing two IPv4 as pure strings would work (except if you want
to perform network comparison with mask and so).
Obviously under IPv6 binary comparison is needed (this is what my
function does).
2:31 p.m.
Am 28.04.2011 11:53, schrieb Iñaki Baz Castillo:
2011/4/28 Daniel-Constantin Mierla
<daniel(a)kamailio.org>rg>:
but it works. E.g
INVITE sip:0900123455@1.2.3.004
works with Kamailio. Thus when making string based checks you do not
have to rely on valid or not. Thus, I never would do IPv4 comparisons
with "string" comparisons if one of the values is user provided, e.g.
if ($rd == "1.2.3.4") {
sl_send_reply("403","not allowed");
exit;
}
would fail to detect the above request.
regards
Klaus
Btw, when was the idea that IP comparison is
string comparison thrown here,
I missed any email?!? To be sure the comparison is done right, then the
string with the IPs have to be converted to binary and the results compared.
The point is that IPv4 comparisons are valid as a pure string
comparison. Note that being strict, the following IPv4 is not valid:
"1.2.3.04"
3:02 p.m.
2011/4/28 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
but it works. E.g
INVITE sip:0900123455@1.2.3.004
Right. In RFC 3261 that is a valid IPv4, but RFC 5954 updates RFC 3261
BNF grammar.
works with Kamailio. Thus when making string based
checks you do not
have to rely on valid or not. Thus, I never would do IPv4 comparisons
with "string" comparisons if one of the values is user provided, e.g.
if ($rd == "1.2.3.4") {
sl_send_reply("403","not allowed");
exit;
}
would fail to detect the above request.
Right.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:50 p.m.
2011/4/28 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2011/4/28 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Just to give more information, inet_pton() function (in arpa/inet.h)
does NOT allow "1.2.3.004" as valid IPv4.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
but it works. E.g
INVITE sip:0900123455@1.2.3.004
Right. In RFC 3261 that is a valid IPv4, but RFC 5954 updates RFC 3261
BNF grammar.
11:56 a.m.
On Thursday 28 April 2011, Daniel-Constantin Mierla wrote:
Hi Daniel,
i did another closer check in our cfgs, indeed we use it only with src_ip. For
the $si we use regular expression operator, which surely works as expected.
Thanks for the clarification,
Henning
Interesting.
However, in case the second argument is a pv (i.e.
retrieved from a DB) "equal" operator would not work as expected, am I
right?
As mentioned in previous email, not even the above syntax should work as
expected -- it would be a surprise, maybe due to ser enhancements. But a
pseudo-variable in the left side implies string or integer comparison.
But for sure when it is a PV in the right side, then it is not working.
11:29 a.m.
On 4/28/11 10:55 AM, Henning Westerholt wrote:
On Wednesday 27 April 2011, Juha Heinanen wrote:
It is not text comparison and textops
has the purpose of working on
generic text, not on conceptual attributes, otherwise siptutils and many
other modules can be just merged there.
Note that the module will be extended to do dns queries and provide the
result (very likely through PV) to configuration file. Then it gets
messy reusing the code of another module. Also for checking network
addresses there must be binary operations behind.
Iñaki Baz Castillo writes:
Hello,
i like to also not see much more of this small utility modules, in the end its
just a text operation, as you've said. Hi Juha. After reviewing it, it seems that
ip_addr.h just contains
functions to operate with IP/socket structs rather than text
representations, so it's not exactly what I need.
So please let me initially create a module "ipops" with the suggested
functions. Later we can discuss how to move it into a library or
ip_addr.h.
i still don't like the idea of having yet another module. if you
operate on text (as you say in above), i don't see what is wrong with
textops module or existing utils module. Another question, have you thought about extending the
existing "equals"
operator that it works also for IPv6 address? Just like for IPv4 addresses
where it already understands network masks, e.g.:
if ($si == 192.168.1.1/32) {..}
This is not working, if you have a pseudo-variable
in the right side,
then it is string comparison. The IP/Net address comparison with '=='
works only for the keywords like src_ip, dst_ip, snd_ip, to_ip - look
where is used comp_ip() in route.c .
So a new module is very appropriate and cleaner in my opinion -- there
is no need to load unnecessary code when not needed as part of existing
module -- and here is a clear group of many potential extensions. At the
end of the day, there is no conflict to decide here, it is up to
developer how it prefers to add a new thing, since it is his time and
his copyright. A new ipops (or dnsops) module will get in at some time,
for sure when I am going to implement the planned DNS stuff.
Cheers,
Daniel
if ($si == 192.168.1.1) {..}
it could do this binary comparison inside as well for v6.
Henning
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
27 Apr
27 Apr
12:59 p.m.
Hello,
you can use cfgutils or siputils.
I plan to add some more IP/dns related functions for config usage (no
timelines yet, though):
- netmask comparison using pseudo-variables
- dns resolver for querying and accessing the result in config
So starting a new module like 'ipops' might be a good solution, as well.
Cheers,
Daniel
On 4/27/11 12:50 PM, Iñaki Baz Castillo wrote:
Hi, AFAIK SR doesn't provide a way to binary
compare two IPv6 (correct
me if I'm wrong). About IPv4 comparison, I assume it's compared as a
string:
if ($rd == "1.2.3.4")
so it works. But in case of IPv6 it would not work as the same IPv6
could take different (but equivalent) representations:
"1080:0000:0000:0000:0008:0800:200C:417A"
"1080:0:0:0:8:800:200C:417A"
"1080::8:800:200C:417A"
I'd like to add a function to perform IPv6 binary comparison (as I've
already coded it in a personal project), could you please tell me in
which module should it take place? I mean something as:
--------------------------------------------------------------------------
compare_ips(ip1, ip2)
Returns 1 if both IP's are two equal IPv4 or two equal IPv6.
Returns -1 if both IP's are valid but not equal.
Returns -2 if at least one give IP is not a valid IPv4 or IPv6.
Parameters:
- ip1: An string of pv containing a IPv4 or IPv6 in text representation.
- ip2: An string of pv containing a IPv4 or IPv6 in text representation.
--------------------------------------------------------------------------
Thanks.
1:04 p.m.
2011/4/27 Daniel-Constantin Mierla <daniel(a)kamailio.org>rg>:
I plan to add some more IP/dns related functions for
config usage (no
timelines yet, though):
- netmask comparison using pseudo-variables
- dns resolver for querying and accessing the result in config
So starting a new module like 'ipops' might be a good solution, as well.
Ok, let me then start "ipops" module :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4755
days inactive
4756
days old
23 comments
6 participants
participants (6)
-
Daniel-Constantin Mierla -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Juha Heinanen -
Klaus Darilion