[OpenSIPS-Users] nathelper function for ipv6

Bogdan-Andrei Iancu bogdan at opensips.org
Fri Apr 6 04:18:04 EDT 2018


Thanks Pasan for testing. I just did the backports.

Let me know if there are any issue with the ipv6 tests here.

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam

On 04/06/2018 05:54 AM, Pasan Meemaduma wrote:
> Hi Bogdan,
>
> We applied your patch and it fixed the issue. Thank you.
>
>
> On Thursday, April 5, 2018, 6:16:17 PM GMT+5:30, Bogdan-Andrei Iancu 
> <bogdan at opensips.org> wrote:
>
>
> Hi Pasan,
>
> I found some issues in how IPs are checked for AF_INET6. Could you 
> test this fix:
> https://github.com/OpenSIPS/opensips/commit/a69f6de764cefab7cb7179b2f439780e74082461
>
> Thanks and regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>    http://www.opensips.org/events/Summit-2018Amsterdam
> On 04/05/2018 01:24 PM, Pasan Meemaduma wrote:
>> Hi Bogdan,
>>
>> I just tried, and it still returns true. I have put my debug line below,
>>
>> Call: Request from NAT IP - From=xxx 
>> from_uri=sip:xxxxx at voip2.exetel.com.au Auth_user=xx Request=xx 
>> IP=2400:A240:0:1:6000:0:0:2 Via=2400:a240:0:1:6000::2 ID=545589626
>>
>>
>>
>> Surprisingly I have another ipv6 address tested and it fails the nat 
>> test and behave appropriately. I'll dump both request contents as below,
>>
>> not working one - nat_uac_test returns true
>>
>>
>> U 2018/04/05 15:06:20.982169 2400:a240:0:1:6000::2:5060 -> 
>> 240x:xx00:1d:f0::1:88:5060
>> INVITE sip:0x12345678 at xx.xx.com.xx SIP/2.0.
>> Via: SIP/2.0/UDP [2400:a240:0:1:6000::2]:5060;branch=z9hG4bK1610101366.
>> Contact: <sip:0xx0x0x0xx@[2400:A240:0:1:6000:0:0:2]>.
>>
>> working one - nat_uac_test returns false
>>
>> U 2018/04/05 15:11:11.480156 2406:3400:0:8:c5c9:bd6:4b95:7a5e:5060 -> 
>> 240x:xx00:1d:f0::1:88:5060
>> INVITE sip:0x12345678 at xx.xx.com.xx SIP/2.0.
>> Via: SIP/2.0/UDP 
>> [240x:xx00:0:8:c5c9:bd6:4b95:7a5e]:5060;branch=z9hG4bK566727241.
>> Contact: <sip:0x80x0xxxx@[240x:xx00:0:8:C5C9:BD6:4B95:7A5E]>.
>>
>>
>> Only difference I can spot is the second ipv6 address is in fully 
>> stretch format and mine in summarize format as below, Not sure if its 
>> related.
>>
>>
>> 2400:a240:0:1:6000::2
>> 240x:xx00:0:8:c5c9:bd6:4b95:7a5e
>>
>> Let me know if you need anything else.
>> On Thursday, April 5, 2018, 3:37:24 PM GMT+5:30, Bogdan-Andrei Iancu 
>> <bogdan at opensips.org> <mailto:bogdan at opensips.org> wrote:
>>
>>
>> Hi Pasan,
>>
>> 19 is 16 + 2 +1 (as tests) :
>>
>> /1/- Contact header field is searched for occurrence of RFC1918 / 
>> RFC6598 addresses.//
>> /2/- the "received" test is used: address in Via is compared against 
>> source IP address of signaling//
>> /16/- test if the source port is different from the port in Via
>>
>> 2 and 16 is checking IP versus IP, so they are not affected by v4 
>> versus v6.
>>
>> On test 1 I see no checks on v4 or v6 - it simply checks the IP (as 
>> raw bytes) against the know ipv4 private classes.
>>
>> Could you try to remove the test 1 (use 18) and see if the test still 
>> returns true ?
>>
>> Regards,
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    http://www.opensips-solutions.com
>> OpenSIPS Summit 2018
>>    http://www.opensips.org/events/Summit-2018Amsterdam
>> On 04/05/2018 06:58 AM, Pasan Meemaduma via Users wrote:
>>> Hi Guys,
>>>
>>> Are nathelper module functions ipv6 safe ? I'm getting true for nat 
>>> test with following call for an ipv6 address which is a globally 
>>> unique unicast address.
>>>
>>> nat_uac_test("19")
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180406/5221e288/attachment-0001.html>


More information about the Users mailing list