[asterisk-dev] [Code Review] IPv6 in Asterisk

[Mark Michelson]

> On 2010-07-07 14:08:14, Mark Michelson wrote:
> > /trunk/main/rtp_engine.c, lines 415-439
> > <https://reviewboard.asterisk.org/r/743/diff/6/?file=11400#file11400line415>
> >
> >     There are many places where ast_rtp_instance_get_local_address() and ast_rtp_instance_get_remote_address() are called using uninitialized ast_sockaddr structures. This means that the ast_sockaddr_cmp() call uses the uninitialized values when comparing.
> >     
> >     Personally, I don't see the point of doing the comparison. We should just unconditionally set the address.
> 
> Simon Perreault wrote:
>     The return value is used elsewhere to know if the address changed, so we can't change the behaviour.
>     
>     Fixed in r274684.

The fix you committed in r274684 is not enough to fix this problem. The reason is that most of the time the ast_sockaddr passed into these functions was created on the stack with no initial values set. This means that ast_sockaddr_isnull() will almost always return false, thus causing the use of uninitialized values that I had complained of earlier. The only way I know to get around this is to find all cases where you are creating an ast_sockaddr structure on the stack and then either call ast_sockaddr_setnull() on the structure prior to calling these RTP functions, or initialize the ast_sockaddr structures to be all 0s at the time of their creation.


> On 2010-07-07 14:08:14, Mark Michelson wrote:
> > /trunk/main/netsock2.c, lines 490-499
> > <https://reviewboard.asterisk.org/r/743/diff/6/?file=11399#file11399line490>
> >
> >     There are several pointer errors here.
> >     
> >     The memcpy should be:
> >     
> >     memcpy(&addr->ss, sin, sizeof(*sin));
> >     
> >     and the final line should be:
> >     
> >     addr->len = sizeof(*sin);
> 
> Simon Perreault wrote:
>     Right. These were introduced with the refactoring. Fixed in r274682.

There's still a problem here after r274682. You still have the second parameter of the memcpy as &sin. It should just be sin.


> On 2010-07-07 14:08:14, Mark Michelson wrote:
> > /trunk/main/http.c, lines 992-1005
> > <https://reviewboard.asterisk.org/r/743/diff/6/?file=11397#file11397line992>
> >
> >     You need to set the address family of tmp and tmp2 to AF_INET or else ast_sockaddr_from_sin() will complain.
> 
> Simon Perreault wrote:
>     This is intentional. __ast_http_load() uses address families as a flag. It sets them only when the sockets are enabled in the configuration. We wanted to preserve the overall behaviour.

Hm, I see now. It's still possible to avoid the warning messages though. You can set the address family to AF_INET here initially. Then, lower in the function, there is an if (enabled) check. Add an else case that clears the address families.

Yes, I know that this doesn't actually cause any real problems other than warning messages, but the average Asterisk user will become alarmed by such warning messages and we'll likely get many e-mails and issue reports if they are present.


- Mark


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


On 2010-07-07 15:12:58, Simon Perreault wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/743/
> -----------------------------------------------------------
> 
> (Updated 2010-07-07 15:12:58)
> 
> 
> Review request for Asterisk Developers and Mark Michelson.
> 
> 
> Summary
> -------
> 
> This is the port of Asterisk to IPv6.
> 
> 
> This addresses bug 17565.
>     https://issues.asterisk.org/view.php?id=17565
> 
> 
> Diffs
> -----
> 
>   /trunk/addons/chan_ooh323.c 274492 
>   /trunk/apps/app_externalivr.c 274492 
>   /trunk/channels/chan_dahdi.c 274492 
>   /trunk/channels/chan_gtalk.c 274492 
>   /trunk/channels/chan_h323.c 274492 
>   /trunk/channels/chan_iax2.c 274492 
>   /trunk/channels/chan_jingle.c 274492 
>   /trunk/channels/chan_mgcp.c 274492 
>   /trunk/channels/chan_multicast_rtp.c 274492 
>   /trunk/channels/chan_sip.c 274492 
>   /trunk/channels/chan_skinny.c 274492 
>   /trunk/channels/chan_unistim.c 274492 
>   /trunk/channels/sip/dialplan_functions.c 274492 
>   /trunk/channels/sip/include/dialog.h 274492 
>   /trunk/channels/sip/include/globals.h 274492 
>   /trunk/channels/sip/include/reqresp_parser.h 274492 
>   /trunk/channels/sip/include/sip.h 274492 
>   /trunk/channels/sip/reqresp_parser.c 274492 
>   /trunk/include/asterisk/acl.h 274492 
>   /trunk/include/asterisk/config.h 274492 
>   /trunk/include/asterisk/dnsmgr.h 274492 
>   /trunk/include/asterisk/netsock2.h PRE-CREATION 
>   /trunk/include/asterisk/rtp_engine.h 274492 
>   /trunk/include/asterisk/tcptls.h 274492 
>   /trunk/main/acl.c 274492 
>   /trunk/main/app.c 274492 
>   /trunk/main/config.c 274492 
>   /trunk/main/dnsmgr.c 274492 
>   /trunk/main/http.c 274492 
>   /trunk/main/manager.c 274492 
>   /trunk/main/netsock2.c PRE-CREATION 
>   /trunk/main/rtp_engine.c 274492 
>   /trunk/main/tcptls.c 274492 
>   /trunk/res/res_fax.c 274492 
>   /trunk/res/res_rtp_asterisk.c 274492 
>   /trunk/res/res_rtp_multicast.c 274492 
> 
> Diff: https://reviewboard.asterisk.org/r/743/diff
> 
> 
> Testing
> -------
> 
> See test report on the mantis issue.
> 
> 
> Thanks,
> 
> Simon
> 
>