[OpenSER-Users] How to check if $rd lies in an IP range

Josh Mahonin jmahonin at cbnco.com
Tue Mar 25 15:06:01 CET 2008


Hi,

I tried responding over the weekend, but I think my mail server ate the
message, apologies if you receive duplicates.

Thank you both Sergio and Daniel-Constantin, I was hoping someone else
had encountered a similar problem!  I like the idea of transforming and
netmasking - I'm new to OpenSER, but don't mind contributing back to the
community - if I was to create some sort of check_netmask /
check_iprange function, is there a particular module, or core source
file that this function would fit well in?

Regards,

Josh

Daniel-Constantin Mierla wrote:
> Hello,
>
> it is another way, a bit more complex in the config file, but does not
> require to execute external scripts.
>
> All you need is to play with transformations and arithmetic operations
> in the config file. The idea is to convert to integer the IP addresses
> apply bitmask and compare. Transformations that help:
> - http://www.openser.org/dokuwiki/doku.php/transformations:devel#s.int
> -
> http://www.openser.org/dokuwiki/doku.php/transformations:devel#s.select_index_separator
>
>
> For example:
> $rd = 23.34.56.78
>
> To get second number (34) as integer $(rd{s.select,1,.}{s.int})
>
> You transform the four parts in numbers, multiply each with the proper
> value, make the sum and apply the bitwise 'and' operation with the mask.
>
> Should get what you need.
>
> Cheers,
> Daniel
>
>
> On 03/21/08 03:41, Sergio Gutierrez wrote:
>> Hi Josh.
>>
>> An approach we used is execute an external script through function
>> exec_msg; the script receives as argument the source ip address, and
>> by external means, it checks whether it belongs to a particular
>> subnet, defined on a table in database or a file; we used PHP and a
>> table in MySQL with the reference subnets.
>>
>> The script should return 0 or 1; when returns 0, exec_msg returns
>> true, and when it returns 1; exec_msg returns false, so you can check
>> it into an if statement.
>>
>> Hope it helps.
>>
>> Best regards.
>>
>> Sergio Gutiérrez.
>>
>> On Thu, Mar 20, 2008 at 4:34 PM, Josh Mahonin <jmahonin at cbnco.com
>> <mailto:jmahonin at cbnco.com>> wrote:
>>
>>     Hi folks,
>>
>>     In my setup, I've got two disjoint subnets (call then A and B) that
>>     cannot communicate directly to each other, but devices on each can
>>     both
>>     communicate to my OpenSER server and Asterisk box (both on their own
>>     subnet, C).  There is no NAT involved, so I only want to use
>> rtpproxy
>>     when it's the case that device from subnet A attempts to call a
>> device
>>     on subnet B, or vice-versa.
>>
>>     I would ideally not like to use rtp proxy for communication
>>     between A-C
>>     and A-B (this will enable RTP media between both subnets, but that
>>     solution will not scale very well...)
>>
>>     I'm attempting do something like this:
>>
>>     if (src_ip == a.b.c.d/24 && dst_ip == w.x.y.z/24)
>>        use rtp proxy
>>
>>     But unfortunately, on an INVITE, after a lookup, dst_ip is set to
>> the
>>     OpenSER server.  The pseudovariable $rd is set to the value I'd
>>     like to
>>     check against, but it complains loudly when I attempt to substitute
>>     dst_ip for $rd.
>>
>>     Is there any way to use avp_check() or the like to verify that the
>>     value
>>     in $rd lies in a given subnet?  I don't want to match just one IP,
>>     but a
>>     whole range.  I found a similar question on the SER mailing list
>> asked
>>     several years ago, with no response.
>>
>>     Thanks,
>>
>>     Josh
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.openser.org <mailto:Users at lists.openser.org>
>>     http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>   





More information about the sr-users mailing list