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

elguero reviewboard at asterisk.org
Wed Feb 20 18:29:35 CST 2013

This is an automatically generated e-mail. To reply, visit:

(Updated Feb. 20, 2013, 6:29 p.m.)

Review request for Asterisk Developers.


* Break out a block of code into its own function
* Handle EINTR properly like it was done before the patch


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 and ::1 but his daemon was only listening on  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:

  - 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.

Diffs (updated)

  /branches/11/res/res_agi.c 381425 

Diff: https://reviewboard.asterisk.org/r/2330/diff


Tested this on a dev box.
Reporter tested this in his environment and confirmed that it was working as intended.



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

More information about the asterisk-dev mailing list