[asterisk-bugs] [Asterisk 0017717]: [patch] dynamic_exclude_static option results in ACL errors

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17717 
====================================================================== 
Reported By:                mmichelson
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   17717
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.8.0-beta1 
JIRA:                       SWP-1951 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-07-26 09:44 CDT
Last Modified:              2010-07-26 21:42 CDT
====================================================================== 
Summary:                    [patch] dynamic_exclude_static option results in ACL
errors
Description: 
As reported on the Asterisk-dev mailing list by Dennis DeDonatis, the
dynamic_exclude_static option in sip.conf will cause error messages to be
printed. Here is my response to the original e-mail on -dev regarding the
subject:

"The error messages are a result of having the "dynamic_exclude_static" 
option enabled in sip.conf. The idea behind the option is to create a 
"contactdeny" ACL for the current peer's IP address so that if another 
endpoint tries to send a REGISTER to Asterisk with that same IP address 
in its contact header, Asterisk will deny the registration attempt.

I took a look at the code in 1.6.2, and I'm convinced this option is not 
working as intended, at  least not in most cases. The problem is that on 
an initial load of chan_sip, the current peer's IP address has not been 
set (it's all 0s) when the host is parsed. The result is that a 
contactdeny of 0.0.0.0/32 is likely getting created most of the time. On 
reloads, the problem may be worse because if you are changing the host 
line for a peer, then the code may end up creating an ACL based on the 
peer's old IP address instead of its new one.

In 1.8.0-beta1, The section is different since we are using the new 
netsock2 API that allows for IPv6 addresses to be used. We attempt to 
get a string representation of the peer's IP address, which like in 
1.6.2 is all 0s at the time the host line is parsed. The result is the 
literal string "(null)." We then try to pass this off to the ACL code, 
which of course says that it is a badly-formatted IP address. The result 
is the trio of messages starting with the getaddrinfo error, leading to 
the "Invalid IP address" warning, and leading then to the "Bad ACL 
entry" error. So it seems like the increased number of error messages in 
1.8.0-beta1 has actually exposed a bug that exists in earlier Asterisks 
as well.

The proper fix in both 1.6.2 and 1.8 is to wait and add the contactdeny 
ACL after the peer's IP address is known to be set to a valid value. 
This may be as easy as moving a block of code lower down in the 
build_peer() function than it currently is."
====================================================================== 

---------------------------------------------------------------------- 
 (0125090) pabelanger (manager) - 2010-07-26 21:42
 https://issues.asterisk.org/view.php?id=17717#c125090 
---------------------------------------------------------------------- 
@DennisD: Check out the latest 1.8 branch and retry your test. The crash
was fixed by https://issues.asterisk.org/view.php?id=17677 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-26 21:42 pabelanger     Note Added: 0125090                          
======================================================================