When receiving an INVITE over a specific LTE carrier, I'm seeing 'c=IN IP4 192.0.0.4' in SDP, which isn't technically a RFC1918 or RFC6598 IP address and thus nat_uac_test(8) fails. What elegant workaround can be done to catch such specific cases? Thanks.
You could do something like below to check specifically for that case and override the uac test. if (sdp_get_line_startswith("$avp(cline)", "c=")) $var(sdp_contact_host) = $(avp(cline){re.subst,/c=IN IP4 (.+)/\1/}); if (is_in_subnet("$avp(sdp_contact_host)", "192.0.0.0/29")) .........
Convoluted solution for an abnormal problem, but it works, thanks! On Wed, Mar 21, 2018 at 12:08 PM, John Petrini <jpetrini@coredial.com> wrote:
You could do something like below to check specifically for that case and override the uac test.
if (sdp_get_line_startswith("$avp(cline)", "c=")) $var(sdp_contact_host) = $(avp(cline){re.subst,/c=IN IP4 (.+)/\1/});
if (is_in_subnet("$avp(sdp_contact_host)", "192.0.0.0/29")) .........
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Wed, Mar 21, 2018 at 11:05:15AM -0400, Sergiu Pojoga wrote:
When receiving an INVITE over a specific LTE carrier, I'm seeing 'c=IN IP4 192.0.0.4' in SDP, which isn't technically a RFC1918 or RFC6598 IP address and thus nat_uac_test(8) fails.
Looking at the table at the bottom of https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... Should't the check be updated to include 192.0.0.0/29? It is explicitly defined for NAT and has the exact same properties as RFC1918 and RFC6598 addresses.
If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29 I think that's a great idea.
On Thu, Mar 22, 2018 at 04:23:18PM -0400, John Petrini wrote:
If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29 I think that's a great idea.
Don't know if I got every use in the source tree of private nets, but following diff should do the trick. This net can be used for ip4<->ipv6<->ipv4 NAT translations. So 6TO4-RELAY in ipops fits better than PRIVATE. But is simply indicates NAT transversal for the nathelper module. I'm to lazy^W^Wdon't have the time to figure out how to do the appropriate git magic. diff --git a/src/modules/ipops/detailed_ip_type.c b/src/modules/ipops/detailed_ip_type.c index a37c4aacc..529645e99 100644 --- a/src/modules/ipops/detailed_ip_type.c +++ b/src/modules/ipops/detailed_ip_type.c @@ -41,6 +41,7 @@ static ip4_node IPv4ranges[IPv4RANGES_SIZE] = { { 0xc0586300, "6TO4-RELAY", 0xffffff00 }, // 192.88.99.0/24 { 0xc0000200, "TEST-NET", 0xffffff00 }, // 192.0.2/24 { 0xc0000000, "RESERVED", 0xffffff00 }, // 192.0.0/24 + { 0xc0000000, "6TO4-RELAY", 0xfffffff8 }, // 192.0.0.0/29 { 0xc0a80000, "PRIVATE", 0xffff0000 }, // 192.168/16 { 0xa9fe0000, "LINK-LOCAL", 0xffff0000 }, // 169.254/16 { 0xc6120000, "RESERVED", 0xfffe0000 }, // 198.18/15 diff --git a/src/modules/nat_traversal/nat_traversal.c b/src/modules/nat_traversal/nat_traversal.c index ead4c696f..710d281f5 100644 --- a/src/modules/nat_traversal/nat_traversal.c +++ b/src/modules/nat_traversal/nat_traversal.c @@ -258,6 +258,7 @@ static NetInfo rfc1918nets[] = { {"172.16.0.0", 0xac100000UL, 0xfff00000UL}, {"192.168.0.0", 0xc0a80000UL, 0xffff0000UL}, {"100.64.0.0", 0x64400000UL, 0xffc00000UL}, // include rfc6598 shared address space as technically the same for our purpose + {"192.0.0.0", 0xc0000000UL, 0xfffffff8UL}, // include rfc7335 IPv4 Service Continuity Prefix {NULL, 0UL, 0UL} }; @@ -2156,4 +2157,4 @@ int mod_register(char *path, int *dlflags, void *p1, void *p2) { sr_kemi_modules_add(sr_kemi_nat_traversal_exports); return 0; -} \ No newline at end of file +} diff --git a/src/modules/nathelper/nathelper.c b/src/modules/nathelper/nathelper.c index a45588a50..935c981ee 100644 --- a/src/modules/nathelper/nathelper.c +++ b/src/modules/nathelper/nathelper.c @@ -148,6 +148,7 @@ static struct { {"172.16.0.0", 0, 0xffffffffu << 20}, {"192.168.0.0", 0, 0xffffffffu << 16}, {"100.64.0.0", 0, 0xffffffffu << 22}, /* rfc6598 - cg-nat */ + {"192.0.0.0", 0, 0xffffffffu << 3}, /* rfc7335 - IPv4 Service Continuity Prefix */ {NULL, 0, 0} }; /* clang-format on */
On Fri, Mar 23, 2018 at 10:43:05AM +0100, Daniel Tryba wrote:
On Thu, Mar 22, 2018 at 04:23:18PM -0400, John Petrini wrote:
If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29 I think that's a great idea. ... I'm to lazy^W^Wdon't have the time to figure out how to do the appropriate git magic.S
Hi, It's been a while, had the chance to notice only now a live case involving rfc7335 private IPs. It appears as though either nat_uac_test() or more likely fix_nated_sdp() doesn't catch the 192.0.0.0/29 subnet as private. Added a comment including sip dump example to the closed PR, if someone has the desire to look into it, https://github.com/kamailio/kamailio/pull/1488 Thanks, --Sergiu On Fri, Mar 23, 2018 at 7:30 AM Daniel Tryba <d.tryba@pocos.nl> wrote:
On Fri, Mar 23, 2018 at 10:43:05AM +0100, Daniel Tryba wrote:
On Thu, Mar 22, 2018 at 04:23:18PM -0400, John Petrini wrote:
If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29 I think that's a great idea. ... I'm to lazy^W^Wdon't have the time to figure out how to do the appropriate git magic.S
I lied: https://github.com/kamailio/kamailio/pull/1488
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello, better create a new issue, rather than adding comments to old merged PRs or closed issues, because they do not pop up in front on the web portal and likely the code has changed. In the new issue/PR, you can reference the old one if there are relevant details. Cheers, Daniel On 07.04.20 17:25, Sergiu Pojoga wrote:
Hi,
It's been a while, had the chance to notice only now a live case involving rfc7335 private IPs. It appears as though either nat_uac_test() or more likely fix_nated_sdp() doesn't catch the 192.0.0.0/29 <http://192.0.0.0/29> subnet as private.
Added a comment including sip dump example to the closed PR, if someone has the desire to look into it, https://github.com/kamailio/kamailio/pull/1488
Thanks, --Sergiu
On Fri, Mar 23, 2018 at 7:30 AM Daniel Tryba <d.tryba@pocos.nl <mailto:d.tryba@pocos.nl>> wrote:
On Fri, Mar 23, 2018 at 10:43:05AM +0100, Daniel Tryba wrote: > On Thu, Mar 22, 2018 at 04:23:18PM -0400, John Petrini wrote: > > If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29 <http://192.0.0.0/29> > > I think that's a great idea. ... > I'm to lazy^W^Wdon't have the time to figure out how to do the > appropriate git magic.S
I lied: https://github.com/kamailio/kamailio/pull/1488
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda
Hi Daniel, Voilà: https://github.com/kamailio/kamailio/issues/2277 Thanks, --Sergiu On Tue, Apr 7, 2020 at 11:31 AM Daniel-Constantin Mierla <miconda@gmail.com> wrote:
Hello,
better create a new issue, rather than adding comments to old merged PRs or closed issues, because they do not pop up in front on the web portal and likely the code has changed. In the new issue/PR, you can reference the old one if there are relevant details.
Cheers, Daniel On 07.04.20 17:25, Sergiu Pojoga wrote:
Hi,
It's been a while, had the chance to notice only now a live case involving rfc7335 private IPs. It appears as though either nat_uac_test() or more likely fix_nated_sdp() doesn't catch the 192.0.0.0/29 subnet as private.
Added a comment including sip dump example to the closed PR, if someone has the desire to look into it, https://github.com/kamailio/kamailio/pull/1488
Thanks, --Sergiu
On Fri, Mar 23, 2018 at 7:30 AM Daniel Tryba <d.tryba@pocos.nl> wrote:
On Fri, Mar 23, 2018 at 10:43:05AM +0100, Daniel Tryba wrote:
On Thu, Mar 22, 2018 at 04:23:18PM -0400, John Petrini wrote:
If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29 I think that's a great idea. ... I'm to lazy^W^Wdon't have the time to figure out how to do the appropriate git magic.S
I lied: https://github.com/kamailio/kamailio/pull/1488
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hi there, To finalize this matter, any chance this gets backported to stable branches now that the new nathelper nat_addr_mode modparam has been tested? Thanks. --Sergiu On Tue, Apr 7, 2020 at 11:52 AM Sergiu Pojoga <pojogas@gmail.com> wrote:
Hi Daniel,
Voilà: https://github.com/kamailio/kamailio/issues/2277
Thanks, --Sergiu
On Tue, Apr 7, 2020 at 11:31 AM Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
better create a new issue, rather than adding comments to old merged PRs or closed issues, because they do not pop up in front on the web portal and likely the code has changed. In the new issue/PR, you can reference the old one if there are relevant details.
Cheers, Daniel On 07.04.20 17:25, Sergiu Pojoga wrote:
Hi,
It's been a while, had the chance to notice only now a live case involving rfc7335 private IPs. It appears as though either nat_uac_test() or more likely fix_nated_sdp() doesn't catch the 192.0.0.0/29 subnet as private.
Added a comment including sip dump example to the closed PR, if someone has the desire to look into it, https://github.com/kamailio/kamailio/pull/1488
Thanks, --Sergiu
On Fri, Mar 23, 2018 at 7:30 AM Daniel Tryba <d.tryba@pocos.nl> wrote:
On Fri, Mar 23, 2018 at 10:43:05AM +0100, Daniel Tryba wrote:
On Thu, Mar 22, 2018 at 04:23:18PM -0400, John Petrini wrote:
If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29 I think that's a great idea. ... I'm to lazy^W^Wdon't have the time to figure out how to do the appropriate git magic.S
I lied: https://github.com/kamailio/kamailio/pull/1488
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello, Thanks for the testing, done for 5.3 branch. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: sr-users <sr-users-bounces@lists.kamailio.org> On Behalf Of Sergiu Pojoga Sent: Thursday, April 23, 2020 9:14 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org> Subject: Re: [SR-Users] nat_uac_test(8) Hi there, To finalize this matter, any chance this gets backported to stable branches now that the new nathelper nat_addr_mode modparam has been tested? Thanks. --Sergiu On Tue, Apr 7, 2020 at 11:52 AM Sergiu Pojoga <pojogas@gmail.com<mailto:pojogas@gmail.com>> wrote: Hi Daniel, Voilà: https://github.com/kamailio/kamailio/issues/2277 Thanks, --Sergiu On Tue, Apr 7, 2020 at 11:31 AM Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>> wrote: Hello, better create a new issue, rather than adding comments to old merged PRs or closed issues, because they do not pop up in front on the web portal and likely the code has changed. In the new issue/PR, you can reference the old one if there are relevant details. Cheers, Daniel On 07.04.20 17:25, Sergiu Pojoga wrote: Hi, It's been a while, had the chance to notice only now a live case involving rfc7335 private IPs. It appears as though either nat_uac_test() or more likely fix_nated_sdp() doesn't catch the 192.0.0.0/29<http://192.0.0.0/29> subnet as private. Added a comment including sip dump example to the closed PR, if someone has the desire to look into it, https://github.com/kamailio/kamailio/pull/1488 Thanks, --Sergiu On Fri, Mar 23, 2018 at 7:30 AM Daniel Tryba <d.tryba@pocos.nl<mailto:d.tryba@pocos.nl>> wrote: On Fri, Mar 23, 2018 at 10:43:05AM +0100, Daniel Tryba wrote:
On Thu, Mar 22, 2018 at 04:23:18PM -0400, John Petrini wrote:
If you're asking if nat_uac_test should be updated to check for 192.0.0.0/29<http://192.0.0.0/29> I think that's a great idea. ... I'm to lazy^W^Wdon't have the time to figure out how to do the appropriate git magic.S
I lied: https://github.com/kamailio/kamailio/pull/1488 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
participants (5)
-
Daniel Tryba -
Daniel-Constantin Mierla -
Henning Westerholt -
John Petrini -
Sergiu Pojoga