[asterisk-dev] [Code Review]: Truncate host:port when checking SIP domains and make the URI parsing API more explicit about returning host:port and not a domain

Terry Wilson reviewboard at asterisk.org
Tue Nov 8 21:52:49 CST 2011



> On Nov. 8, 2011, 7:56 p.m., Simon Perreault wrote:
> > /branches/1.8/channels/chan_sip.c, line 14417
> > <https://reviewboard.asterisk.org/r/1574/diff/1/?file=21661#file21661line14417>
> >
> >     This will fail with IPv6 address literals.
> >     
> >     e.g. "[2001:db8::1]:1234"
> >     
> >     You need to check for brackets. (Unless I'm mistaken about this function's expected input range, in which case this should be documented in the doxygen comments.)
> >     
> >     Isn't there code in netsock2.c that already does this?
> 
> Terry Wilson wrote:
>     Actually, it would work fine on the example you gave because I am using 'strrchr' not 'strchr'. Where it would fail, though, would be if the function was used on an IPv6 address with no port. Brackets wouldn't make much difference either way. I will check to see if I use it somewhere where we might get such an address. I probably do.
>     
>     There appears to be a get_domain() function in chan_sip.c, but it looks like it would treat the first unbracketed ':' as a port demarcation and set it to NULL as well, which would be bad. We might want to check and make sure it is never used on something that might be an IPv6 address as well.
>     
>     I may be missing the netsock2 code you are talking about. I suppose we could parse the host:port into an ast_sockaddr with PARSE_PORT_IGNORE then print it back out, but that sounds like a lot of overhead. I can keep looking at it. If you run into the function you are thinking of, please let me know.

Actually, I did miss the netsock function. ast_sockaddr_split_hostport(). It is so accurately named, I couldn't help but miss it. :-)


- Terry


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1574/#review4740
-----------------------------------------------------------


On Nov. 8, 2011, 7:41 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1574/
> -----------------------------------------------------------
> 
> (Updated Nov. 8, 2011, 7:41 p.m.)
> 
> 
> Review request for Asterisk Developers and wdoekes.
> 
> 
> Summary
> -------
> 
> In reviewing https://reviewboard.asterisk.org/r/1533/ I noticed that going from 1.4 to 1.8, setting domain=x.x.x.x stopped matching when receiving a request to x.x.x.x. The reason is that the parse_uri function returns host:port in what was labeled the "domain" variable in 1.8 when in 1.4 the parsing was done in each individual function and the port truncated manually. For example, peer->fromdomain could be set to a host:port, even though it is specifically split into peer->fromdomain and peer->fromport other places in the code.
> 
> We can't change the parsing function because sometimes we actually use the host:port form of the result (as in when passing it to ast_sockaddr_resolve_first), so we need to do the truncation manually when appropriate. This patch does two things: 1) it renames the "domain" variables in the API functions to "hostport" to more accurately reflect what we are really returning and 2) implements a truncate_hostport function and uses it where appropriate.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 343673 
>   /branches/1.8/channels/sip/include/reqresp_parser.h 343673 
>   /branches/1.8/channels/sip/include/sip.h 343673 
>   /branches/1.8/channels/sip/reqresp_parser.c 343673 
> 
> Diff: https://reviewboard.asterisk.org/r/1574/diff
> 
> 
> Testing
> -------
> 
> Ran the SIP unit tests and SIP-related testsuite tests and saw no difference in behavior. Set domain=127.0.0.1 and verified register requests started working.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111109/5fb28381/attachment.htm>


More information about the asterisk-dev mailing list