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.
2011/4/27 Iñaki Baz Castillo ibc@aliax.net:
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 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
2011/4/27 Juha Heinanen jh@tutpro.com:
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 writes:
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?
i don't know, since i have not used ipv6 myself in sip router.
-- juha
2011/4/27 Juha Heinanen jh@tutpro.com:
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.
I'll take a look to it and comment later. Thanks.
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.
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.
Regards.
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
On Wednesday 27 April 2011, Juha Heinanen wrote:
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.
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
2011/4/28 Henning Westerholt henning.westerholt@1und1.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)
On 4/28/11 11:27 AM, Iñaki Baz Castillo wrote:
2011/4/28 Henning Westerholthenning.westerholt@1und1.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?
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
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)
2011/4/28 Daniel-Constantin Mierla daniel@kamailio.org:
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).
2011/4/28 Iñaki Baz Castillo ibc@aliax.net:
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?
On 4/28/11 12:02 PM, Iñaki Baz Castillo wrote:
2011/4/28 Iñaki Baz Castilloibc@aliax.net:
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?
you have to give the proper format, enclosed in square brackets. The assignments above are just string value settings.
Cheers, Daniel
2011/4/28 Daniel-Constantin Mierla miconda@gmail.com:
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.
Thanks for clarify it.
On 4/28/11 11:53 AM, Iñaki Baz Castillo wrote:
2011/4/28 Daniel-Constantin Mierladaniel@kamailio.org:
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).
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
Obviously under IPv6 binary comparison is needed (this is what my function does).
On 4/28/11 11:53 AM, Iñaki Baz Castillo wrote:
2011/4/28 Daniel-Constantin Mierladaniel@kamailio.org:
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).
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
Obviously under IPv6 binary comparison is needed (this is what my function does).
Am 28.04.2011 11:53, schrieb Iñaki Baz Castillo:
2011/4/28 Daniel-Constantin Mierla daniel@kamailio.org:
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"
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
2011/4/28 Klaus Darilion klaus.mailinglists@pernau.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.
2011/4/28 Iñaki Baz Castillo ibc@aliax.net:
2011/4/28 Klaus Darilion klaus.mailinglists@pernau.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.
Just to give more information, inet_pton() function (in arpa/inet.h) does NOT allow "1.2.3.004" as valid IPv4.
On Thursday 28 April 2011, Daniel-Constantin Mierla wrote:
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.
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
On 4/28/11 10:55 AM, Henning Westerholt wrote:
On Wednesday 27 April 2011, Juha Heinanen wrote:
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.
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.
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.
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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.
2011/4/27 Daniel-Constantin Mierla daniel@kamailio.org:
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 :)