[asterisk-dev] [Code Review]: Fix FastAGI To Properly Check For A Connection

[elguero]

> On Feb. 21, 2013, 11:57 a.m., Sean Bright wrote:
> > /branches/11/res/res_agi.c, line 1458
> > <https://reviewboard.asterisk.org/r/2330/diff/3/?file=33542#file33542line1458>
> >
> >     It bothers me that this returns an agi_result.  Return an int here instead - 0 on success, 1 on error.  Then you can simplify the call to handle_connection() later on.

That is what I get for over thinking things... sheesh... I had it that way and changed it right before submitting the patch...

Changed.


> On Feb. 21, 2013, 11:57 a.m., Sean Bright wrote:
> > /branches/11/res/res_agi.c, line 1469
> > <https://reviewboard.asterisk.org/r/2330/diff/3/?file=33542#file33542line1469>
> >
> >     Space after the 'while'

Done


- elguero


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


On Feb. 20, 2013, 6:29 p.m., elguero wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2330/
> -----------------------------------------------------------
> 
> (Updated Feb. 20, 2013, 6:29 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> When adding IPv6 support to FastAGI, it appears that the intent was to have the ability to check all addresses resolved for a host since we might receive an IPv4 address and an IPv6 address.  We attempt to create a socket() and issue a connect() and then continue on if that succeeds.  The problem, though, is that we set the flag O_NONBLOCK, which is fine, but then do not handle EINPROGRESS after the call to connect(); we ignore it.  We then break out of the loop and continue on.  We later on call ast_poll(), which succeeds but we never check if we have a connection or not on the socket level.  Therefore, we then proceed to send data to the host address that we think is setup and it fails.  We then check errno and see that we have "Connection refused".
> 
> The reporter came across this issue when using "localhost" which resolved to 127.0.0.1 and ::1 but his daemon was only listening on 127.0.0.1.  The IPv6 address was being returned first in the list of addresses resolved.
> 
> When I was trying to recreate this situation, my system always returned 127.0.01 first.  So, this issue can be random, depending on the setup, configuration and which address is returned first in the list of addresses.
> 
> This patch does the following:
> 
> * Handle EINPROGRESS
>   - Move the call to ast_poll() up into the loop that is determining which host address to connect to.
>   - Check the results on the socket level after calling ast_poll().
> * Continue to the next address if the above fails
> 
> 
> This addresses bug ASTERISK-21065.
>     https://issues.asterisk.org/jira/browse/ASTERISK-21065
> 
> 
> Diffs
> -----
> 
>   /branches/11/res/res_agi.c 381425 
> 
> Diff: https://reviewboard.asterisk.org/r/2330/diff
> 
> 
> Testing
> -------
> 
> Tested this on a dev box.
> Reporter tested this in his environment and confirmed that it was working as intended.
> 
> 
> Thanks,
> 
> elguero
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130221/47f8dddb/attachment.htm>