git:master: modules_k/nathelper: Add is_rfc1918(ip_addr) function to test ip_addr for rfc1918addresses.
Module: sip-router Branch: master Commit: 411de126aa30dd67663b790df7aaa9b303189be5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=411de126...
Author: Alex Hermann alex@speakup.nl Committer: Alex Hermann alex@speakup.nl Date: Tue Jul 19 15:24:11 2011 +0200
modules_k/nathelper: Add is_rfc1918(ip_addr) function to test ip_addr for rfc1918addresses.
---
modules_k/nathelper/README | 46 ++++++++++++++++---------- modules_k/nathelper/doc/nathelper_admin.xml | 13 +++++++ modules_k/nathelper/nathelper.c | 18 ++++++++++ 3 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/modules_k/nathelper/README b/modules_k/nathelper/README index a911951..7497492 100644 --- a/modules_k/nathelper/README +++ b/modules_k/nathelper/README @@ -64,8 +64,9 @@ Ovidiu Sas 5.4. add_rcv_param([flag]), 5.5. fix_nated_register() 5.6. nat_uac_test(flags) - 5.7. add_contact_alias() - 5.8. handle_ruri_alias() + 5.7. is_rfc1918(ip_address) + 5.8. add_contact_alias() + 5.9. handle_ruri_alias()
6. Exported Pseudo Variables
@@ -131,8 +132,9 @@ Chapter 1. Admin Guide 5.4. add_rcv_param([flag]), 5.5. fix_nated_register() 5.6. nat_uac_test(flags) - 5.7. add_contact_alias() - 5.8. handle_ruri_alias() + 5.7. is_rfc1918(ip_address) + 5.8. add_contact_alias() + 5.9. handle_ruri_alias()
6. Exported Pseudo Variables
@@ -235,7 +237,7 @@ modparam("nathelper", "natping_interval", 10)
4.2. ping_nated_only (integer)
- If this variable is set then only contacts that have “behind_NAT” flag + If this variable is set then only contacts that have "behind_NAT" flag in user location database set will get ping.
Default value is 0. @@ -310,7 +312,7 @@ modparam("nathelper", "sipping_bflag", 7) feature, you have to set this parameter. The SIP request pinging will be used only for requests marked so.
- Default value is “NULL”. + Default value is "NULL".
Example 1.7. Set sipping_from parameter ... @@ -322,7 +324,7 @@ modparam("nathelper", "sipping_from", "sip:pinger@siphub.net") The parameter sets the SIP method to be used in generating the SIP requests for NAT ping purposes.
- Default value is “OPTIONS”. + Default value is "OPTIONS".
Example 1.8. Set sipping_method parameter ... @@ -340,7 +342,7 @@ Note
The string must be a complete SDP line, including the EOH (\r\n).
- Default value is “a=nortpproxy:yes\r\n”. + Default value is "a=nortpproxy:yes\r\n".
Example 1.9. Set nortpproxy_str parameter ... @@ -355,8 +357,9 @@ modparam("nathelper", "nortpproxy_str", "a=sdpmangled:yes\r\n") 5.4. add_rcv_param([flag]), 5.5. fix_nated_register() 5.6. nat_uac_test(flags) - 5.7. add_contact_alias() - 5.8. handle_ruri_alias() + 5.7. is_rfc1918(ip_address) + 5.8. add_contact_alias() + 5.9. handle_ruri_alias()
5.1. fix_nated_contact()
@@ -373,15 +376,15 @@ if (search("User-Agent: Cisco ATA.*") {fix_nated_contact();}; 5.2. fix_nated_sdp(flags [, ip_address])
Alters the SDP information in orer to facilitate NAT traversal. What - changes to be performed may be controled via the “flags” parameter. + changes to be performed may be controled via the "flags" parameter.
Meaning of the parameters is as follows: * flags - the value may be a bitwise OR of the following flags: - + 0x01 - adds “a=direction:active” SDP line; + + 0x01 - adds "a=direction:active" SDP line; + 0x02 - rewrite media IP address (c=) with source address of the message or the provided IP address (the provide IP address take precedence over the source address). - + 0x04 - adds “a=nortpproxy:yes” SDP line; + + 0x04 - adds "a=nortpproxy:yes" SDP line; + 0x08 - rewrite IP from origin description (o=) with source address of the message or the provided IP address (the provide IP address take precedence over the source address). @@ -476,7 +479,14 @@ fix_nated_register(); This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
-5.7. add_contact_alias() +5.7. is_rfc1918(ip_address) + + Determines if the address in the parameter is an rfc1918 address. The + parameter allows pseudo-variables usage. + + This function can be used from ANY_ROUTE. + +5.8. add_contact_alias()
Adds ;alias=ip:port parameter to contact URI containing received ip:port if contact uri ip:port does not match received ip:port. @@ -495,7 +505,7 @@ fix_nated_register(); }; ...
-5.8. handle_ruri_alias() +5.9. handle_ruri_alias()
Checks if Request URI has alias param and if so, removes it and sets $du based on its value. Note that this means that routing of request is @@ -576,16 +586,16 @@ $ kamctl fifo nh_enable_ping 1
Chapter 2. Frequently Asked Questions
- 2.1. What happend with “rtpproxy_disable” parameter? + 2.1. What happend with "rtpproxy_disable" parameter? 2.2. Where can I find more about Kamailio? 2.3. Where can I post a question about this module? 2.4. How can I report a bug?
2.1.
- What happend with “rtpproxy_disable” parameter? + What happend with "rtpproxy_disable" parameter?
- It was removed as it became obsolete - now “rtpproxy_sock” can take + It was removed as it became obsolete - now "rtpproxy_sock" can take empty value to disable the rtpproxy functionality.
2.2. diff --git a/modules_k/nathelper/doc/nathelper_admin.xml b/modules_k/nathelper/doc/nathelper_admin.xml index 4d7947b..f01a4c7 100644 --- a/modules_k/nathelper/doc/nathelper_admin.xml +++ b/modules_k/nathelper/doc/nathelper_admin.xml @@ -552,6 +552,19 @@ fix_nated_register();
<section> <title> + <function>is_rfc1918(ip_address)</function> + </title> + <para> + Determines if the address in the parameter is an rfc1918 address. + The parameter allows pseudo-variables usage. + </para> + <para> + This function can be used from ANY_ROUTE. + </para> + </section> + + <section> + <title> <function moreinfo="none">add_contact_alias()</function> </title> <para> diff --git a/modules_k/nathelper/nathelper.c b/modules_k/nathelper/nathelper.c index bc3784a..ad9954f 100644 --- a/modules_k/nathelper/nathelper.c +++ b/modules_k/nathelper/nathelper.c @@ -289,6 +289,7 @@ static int handle_ruri_alias_f(struct sip_msg *, char *, char *); static int pv_get_rr_count_f(struct sip_msg *, pv_param_t *, pv_value_t *); static int pv_get_rr_top_count_f(struct sip_msg *, pv_param_t *, pv_value_t *); static int fix_nated_sdp_f(struct sip_msg *, char *, char *); +static int is_rfc1918_f(struct sip_msg *, char *, char *); static int extract_mediaip(str *, str *, int *, char *); static int alter_mediaip(struct sip_msg *, str *, str *, int, str *, int, int); static int fix_nated_register_f(struct sip_msg *, char *, char *); @@ -378,6 +379,9 @@ static cmd_export_t cmds[] = { {"add_rcv_param", (cmd_function)add_rcv_param_f, 1, fixup_uint_null, 0, REQUEST_ROUTE }, + {"is_rfc1918", (cmd_function)is_rfc1918_f, 1, + fixup_spve_null, 0, + ANY_ROUTE }, {0, 0, 0, 0, 0, 0} };
@@ -1272,6 +1276,20 @@ nat_uac_test_f(struct sip_msg* msg, char* str1, char* str2)
}
+static int +is_rfc1918_f(struct sip_msg* msg, char* str1, char* str2) +{ + str address; + + if(fixup_get_svalue(msg, (gparam_p)str1, &address)!=0 || address.len==0) + { + LM_ERR("invalid address parameter\n"); + return -2; + } + + return (is1918addr(&address) == 1) ? 1 : -1; +} + #define ADD_ADIRECTION 0x01 #define FIX_MEDIP 0x02 #define ADD_ANORTPPROXY 0x04
Hi Alex,
I wonder if does not make more sense to have this function in the new ipops module:
http://kamailio.org/docs/modules/devel/modules/ipops.html
Cheers, Daniel
On 7/22/11 6:38 PM, Alex Hermann wrote:
Module: sip-router Branch: master Commit: 411de126aa30dd67663b790df7aaa9b303189be5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=411de126...
Author: Alex Hermannalex@speakup.nl Committer: Alex Hermannalex@speakup.nl Date: Tue Jul 19 15:24:11 2011 +0200
modules_k/nathelper: Add is_rfc1918(ip_addr) function to test ip_addr for rfc1918addresses.
modules_k/nathelper/README | 46 ++++++++++++++++---------- modules_k/nathelper/doc/nathelper_admin.xml | 13 +++++++ modules_k/nathelper/nathelper.c | 18 ++++++++++ 3 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/modules_k/nathelper/README b/modules_k/nathelper/README index a911951..7497492 100644 --- a/modules_k/nathelper/README +++ b/modules_k/nathelper/README @@ -64,8 +64,9 @@ Ovidiu Sas 5.4. add_rcv_param([flag]), 5.5. fix_nated_register() 5.6. nat_uac_test(flags)
5.7. add_contact_alias()5.8. handle_ruri_alias()
5.7. is_rfc1918(ip_address)5.8. add_contact_alias()5.9. handle_ruri_alias() 6. Exported Pseudo Variables@@ -131,8 +132,9 @@ Chapter 1. Admin Guide 5.4. add_rcv_param([flag]), 5.5. fix_nated_register() 5.6. nat_uac_test(flags)
5.7. add_contact_alias()5.8. handle_ruri_alias()
5.7. is_rfc1918(ip_address)5.8. add_contact_alias()5.9. handle_ruri_alias()
- Exported Pseudo Variables
@@ -235,7 +237,7 @@ modparam("nathelper", "natping_interval", 10)
4.2. ping_nated_only (integer)
- If this variable is set then only contacts that have “behind_NAT” flag
If this variable is set then only contacts that have "behind_NAT" flag in user location database set will get ping.
Default value is 0.
@@ -310,7 +312,7 @@ modparam("nathelper", "sipping_bflag", 7) feature, you have to set this parameter. The SIP request pinging will be used only for requests marked so.
- Default value is “NULL”.
Default value is "NULL".
Example 1.7. Set sipping_from parameter ...
@@ -322,7 +324,7 @@ modparam("nathelper", "sipping_from", "sip:pinger@siphub.net") The parameter sets the SIP method to be used in generating the SIP requests for NAT ping purposes.
- Default value is “OPTIONS”.
Default value is "OPTIONS".
Example 1.8. Set sipping_method parameter ...
@@ -340,7 +342,7 @@ Note
The string must be a complete SDP line, including the EOH (\r\n).
- Default value is “a=nortpproxy:yes\r\n”.
Default value is "a=nortpproxy:yes\r\n".
Example 1.9. Set nortpproxy_str parameter ...
@@ -355,8 +357,9 @@ modparam("nathelper", "nortpproxy_str", "a=sdpmangled:yes\r\n") 5.4. add_rcv_param([flag]), 5.5. fix_nated_register() 5.6. nat_uac_test(flags)
- 5.7. add_contact_alias()
- 5.8. handle_ruri_alias()
5.7. is_rfc1918(ip_address)
5.8. add_contact_alias()
5.9. handle_ruri_alias()
5.1. fix_nated_contact()
@@ -373,15 +376,15 @@ if (search("User-Agent: Cisco ATA.*") {fix_nated_contact();}; 5.2. fix_nated_sdp(flags [, ip_address])
Alters the SDP information in orer to facilitate NAT traversal. What
- changes to be performed may be controled via the “flags” parameter.
changes to be performed may be controled via the "flags" parameter.
Meaning of the parameters is as follows:
- flags - the value may be a bitwise OR of the following flags:
+ 0x01 - adds “a=direction:active” SDP line;
+ 0x01 - adds "a=direction:active" SDP line; + 0x02 - rewrite media IP address (c=) with source address of the message or the provided IP address (the provide IP address take precedence over the source address).
+ 0x04 - adds “a=nortpproxy:yes” SDP line;
+ 0x04 - adds "a=nortpproxy:yes" SDP line; + 0x08 - rewrite IP from origin description (o=) with source address of the message or the provided IP address (the provide IP address take precedence over the source address).@@ -476,7 +479,14 @@ fix_nated_register(); This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
-5.7. add_contact_alias() +5.7. is_rfc1918(ip_address)
- Determines if the address in the parameter is an rfc1918 address. The
- parameter allows pseudo-variables usage.
- This function can be used from ANY_ROUTE.
+5.8. add_contact_alias()
Adds ;alias=ip:port parameter to contact URI containing received ip:port if contact uri ip:port does not match received ip:port.@@ -495,7 +505,7 @@ fix_nated_register(); }; ...
-5.8. handle_ruri_alias() +5.9. handle_ruri_alias()
Checks if Request URI has alias param and if so, removes it and sets $du based on its value. Note that this means that routing of request is@@ -576,16 +586,16 @@ $ kamctl fifo nh_enable_ping 1
Chapter 2. Frequently Asked Questions
- 2.1. What happend with “rtpproxy_disable” parameter?
2.1. What happend with "rtpproxy_disable" parameter? 2.2. Where can I find more about Kamailio? 2.3. Where can I post a question about this module? 2.4. How can I report a bug?
2.1.
What happend with “rtpproxy_disable” parameter?
What happend with "rtpproxy_disable" parameter?
It was removed as it became obsolete - now “rtpproxy_sock” can take
It was removed as it became obsolete - now "rtpproxy_sock" can take empty value to disable the rtpproxy functionality.2.2.
diff --git a/modules_k/nathelper/doc/nathelper_admin.xml b/modules_k/nathelper/doc/nathelper_admin.xml index 4d7947b..f01a4c7 100644 --- a/modules_k/nathelper/doc/nathelper_admin.xml +++ b/modules_k/nathelper/doc/nathelper_admin.xml @@ -552,6 +552,19 @@ fix_nated_register();
<section> <title> + <function>is_rfc1918(ip_address)</function> + </title> + <para> + Determines if the address in the parameter is an rfc1918 address. + The parameter allows pseudo-variables usage. + </para> + <para> + This function can be used from ANY_ROUTE. + </para> + </section> + + <section> + <title> <function moreinfo="none">add_contact_alias()</function> </title> <para> diff --git a/modules_k/nathelper/nathelper.c b/modules_k/nathelper/nathelper.c index bc3784a..ad9954f 100644 --- a/modules_k/nathelper/nathelper.c +++ b/modules_k/nathelper/nathelper.c @@ -289,6 +289,7 @@ static int handle_ruri_alias_f(struct sip_msg *, char *, char *); static int pv_get_rr_count_f(struct sip_msg *, pv_param_t *, pv_value_t *); static int pv_get_rr_top_count_f(struct sip_msg *, pv_param_t *, pv_value_t *); static int fix_nated_sdp_f(struct sip_msg *, char *, char *); +static int is_rfc1918_f(struct sip_msg *, char *, char *); static int extract_mediaip(str *, str *, int *, char *); static int alter_mediaip(struct sip_msg *, str *, str *, int, str *, int, int); static int fix_nated_register_f(struct sip_msg *, char *, char *); @@ -378,6 +379,9 @@ static cmd_export_t cmds[] = { {"add_rcv_param", (cmd_function)add_rcv_param_f, 1, fixup_uint_null, 0, REQUEST_ROUTE }, + {"is_rfc1918", (cmd_function)is_rfc1918_f, 1, + fixup_spve_null, 0, + ANY_ROUTE }, {0, 0, 0, 0, 0, 0} };
@@ -1272,6 +1276,20 @@ nat_uac_test_f(struct sip_msg* msg, char* str1, char* str2)
}
+static int +is_rfc1918_f(struct sip_msg* msg, char* str1, char* str2) +{
- str address;
- if(fixup_get_svalue(msg, (gparam_p)str1,&address)!=0 || address.len==0)
- {
LM_ERR("invalid address parameter\n");return -2;- }
- return (is1918addr(&address) == 1) ? 1 : -1;
+}
- #define ADD_ADIRECTION 0x01 #define FIX_MEDIP 0x02 #define ADD_ANORTPPROXY 0x04
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2011/7/29 Daniel-Constantin Mierla miconda@gmail.com:
I wonder if does not make more sense to have this function in the new ipops module:
I could make a new function in the iopos module to detect IP's in such range.
On Friday 29 July 2011, Daniel-Constantin Mierla wrote:
I wonder if does not make more sense to have this function in the new ipops module:
It could fit there, although it is used for NAT detection and the nathelper module already has the necessary infrastructure to check for those addresses. I don't like duplicating those in another module.
On 7/29/11 4:00 PM, Alex Hermann wrote:
On Friday 29 July 2011, Daniel-Constantin Mierla wrote:
I wonder if does not make more sense to have this function in the new ipops module:
It could fit there, although it is used for NAT detection and the nathelper module already has the necessary infrastructure to check for those addresses. I don't like duplicating those in another module.
Indeed there is kind of "conflict of interests" here. Maybe the ipops can get a slightly different implementation, where the match can be, based on parameters, restricted to a network address match. I thought would be useful in non-nat-travesal cases, where nathelper is not loaded.
Cheers, Daniel
On Friday 29 July 2011, Daniel-Constantin Mierla wrote:
On 7/29/11 4:00 PM, Alex Hermann wrote: Indeed there is kind of "conflict of interests" here. Maybe the ipops can get a slightly different implementation, where the match can be, based on parameters, restricted to a network address match. I thought would be useful in non-nat-travesal cases, where nathelper is not loaded.
IMHO general ip to netmask matching should belong in ipops. For now i still believe the check for rfc1918 addresses is more suitable for nathelper. As long as the function is available, i don't care very much where it is, i just hope the code duplication will stop at one point.
2011/7/29 Daniel-Constantin Mierla miconda@gmail.com:
Indeed there is kind of "conflict of interests" here. Maybe the ipops can get a slightly different implementation, where the match can be, based on parameters, restricted to a network address match. I thought would be useful in non-nat-travesal cases, where nathelper is not loaded.
I've already implemented it in ipops module. The function (not commited yet) is called "ip_is_rfc1918()" not to conflict with "is_rfc1918()" function in nathelper module (I'd really would like *namespaces* for separating module functions!) :)
Is it ok if I commit it?
On Friday 29 July 2011, Iñaki Baz Castillo wrote:
Indeed there is kind of "conflict of interests" here. Maybe the ipops can get a slightly different implementation, where the match can be, based on parameters, restricted to a network address match. I thought would be useful in non-nat-travesal cases, where nathelper is not loaded.
I've already implemented it in ipops module. The function (not commited yet) is called "ip_is_rfc1918()" not to conflict with "is_rfc1918()" function in nathelper module (I'd really would like *namespaces* for separating module functions!) :)
Is it ok if I commit it?
Hi Iñaki,
i saw that you just commited it. Does the new function does implement the same functionality as the one in nathelper?
Best regards,
Henning
2011/8/1 Henning Westerholt henning.westerholt@1und1.de:
i saw that you just commited it. Does the new function does implement the same functionality as the one in nathelper?
Basically yes, it allows passing an string or pv and returns true if the given IP is a private IP according to RFC 1918.
I think it's useful to also have this function in ipops module as no all the deployments require nathelper features, but of course maybe other people don't think the same.
Cheers.
On Monday 01 August 2011, Iñaki Baz Castillo wrote:
2011/8/1 Henning Westerholt henning.westerholt@1und1.de:
i saw that you just commited it. Does the new function does implement the same functionality as the one in nathelper?
Basically yes, it allows passing an string or pv and returns true if the given IP is a private IP according to RFC 1918.
I think it's useful to also have this function in ipops module as no all the deployments require nathelper features, but of course maybe other people don't think the same.
Hi Iñaki,
ok, understand. I think we should not introduce two functions with similar names and the same behaviour in two modules. Even worse, both use different implementations (table matching vs. ragel parser). So one commit should be reverted.
A generic is_rfc1918 function in ipops would be nice, but the nathelper module also needs this test internally. What about move one of the parsers to the library dir, and then just including it from both modules?
Best regards,
Henning
2011/8/1 Henning Westerholt henning.westerholt@1und1.de:
ok, understand. I think we should not introduce two functions with similar names and the same behaviour in two modules. Even worse, both use different implementations (table matching vs. ragel parser). So one commit should be reverted.
I agree.
A generic is_rfc1918 function in ipops would be nice, but the nathelper module also needs this test internally. What about move one of the parsers to the library dir, and then just including it from both modules?
It would be nice. Is there an already existing library file in which such function would fit well?
On Monday 01 August 2011, Iñaki Baz Castillo wrote:
2011/8/1 Henning Westerholt henning.westerholt@1und1.de:
ok, understand. I think we should not introduce two functions with similar names and the same behaviour in two modules. Even worse, both use different implementations (table matching vs. ragel parser). So one commit should be reverted.
I agree.
A generic is_rfc1918 function in ipops would be nice, but the nathelper module also needs this test internally. What about move one of the parsers to the library dir, and then just including it from both modules?
It would be nice. Is there an already existing library file in which such function would fit well?
Hi Iñaki,
i don't think so. But you could simply add a new small library, there are several small ones like dtrie or shm_regexp.
Best regards,
Henning
Hello,
On 8/1/11 6:31 PM, Henning Westerholt wrote:
On Monday 01 August 2011, Iñaki Baz Castillo wrote:
2011/8/1 Henning Westerholthenning.westerholt@1und1.de:
ok, understand. I think we should not introduce two functions with similar names and the same behaviour in two modules. Even worse, both use different implementations (table matching vs. ragel parser). So one commit should be reverted.
I agree.
A generic is_rfc1918 function in ipops would be nice, but the nathelper module also needs this test internally. What about move one of the parsers to the library dir, and then just including it from both modules?
It would be nice. Is there an already existing library file in which such function would fit well?
Hi Iñaki,
i don't think so. But you could simply add a new small library, there are several small ones like dtrie or shm_regexp.
if it is just about one function with no external dependencies (I guess nathelper version does not have any), better add it in core in ip_addr.{c,h}. Probably it is used in modules_s/nathelper as well.
Cheers, Daniel
2011/8/1 Daniel-Constantin Mierla miconda@gmail.com:
if it is just about one function with no external dependencies (I guess nathelper version does not have any), better add it in core in ip_addr.{c,h}. Probably it is used in modules_s/nathelper as well.
ok, I'll will take a look when I get some time.
On Friday 29 July 2011, Alex Hermann wrote:
On Friday 29 July 2011, Daniel-Constantin Mierla wrote:
I wonder if does not make more sense to have this function in the new ipops module:
It could fit there, although it is used for NAT detection and the nathelper module already has the necessary infrastructure to check for those addresses. I don't like duplicating those in another module.
Hi Alex,
i came to the same conclusion looking to the nathelper module some days ago.
Best regards,
Henning
-
Alex Hermann -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo