Should be tcp:// not tcp:\\ since \ is an escape character and will end up being evaluated to tcp:\

How about a local IP do they work?

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

If that doesn't work, try configuring PHP using
--disable-ipv6

In reply to the 3 comments since my last reply.

1) Excuse my typo, so tried again on the tcp with "//" and got an errno with "0" and errstr with "Error 0".  The fsockopen() instruction at php.net showed that this meant an error had occur before the fsockopen().  So, tried the "127.0.0.1" without the "tcp://" and got the original error, with "66" and "Addr family not supported by protocol".  You know, I did this one test by using the terminal emulator and use the telnet command, "telnet www.google.com 80" and was able to connected successfully and receive data from it.

2) Recompiled the latest CVS snapshot and still get the same error message.

3) Again, recompiled the latest CVS snapshot with "--disable-ipv6" option and still get this same error message.

Now I'm a little concern about how much of a time will be spend on this or whether would this be dragged on like months and months or something.

Scott

Are you 100% sure you made a clean build after reconfiguring php ? (make clean ; make)

If yes, please try building latest php5 snapshot as a cli to test your script; it has some runtime intelligence to detect systems with broken network stacks.

Yea, it is a clean build.  Tried it again with php5 beta 4 from the php.net website.  Don't see any CVS links for that.  Still get the error but it's a different errors.  I can not make sense out of this one.

--snip--
Content-type: text/html
X-Powered-By: PHP/5.0.0b4

!#/usr/local/bin/php

<br />
<b>Warning</b>:  fsockopen() [<a href='function.fsockopen'>function.fsockopen</a>]: unable to connect to www.google.com:80 (Unknown error) in <b><<file path omitted by me>></b> on line <b>7</b><br />


268976720
--snip--

The output, "268976720" is the output by $errstr...  Oddly, no displayed $errno...

I tried the --disable-ipv6 option and ran the configure, it showed that IP V6 Support is found during the configuration.  Thought you may want to know because I'm not sure if this may help.

Further notice...  I noticed the PHP version 4.3.1 on an another AIX machine does have this same problem with the fsockopen().  So, it could be between 4.2.3 and 4.3.1 when it all of a sudden just don't work.

You have to delete config.cache when you reconfigure. Otherwise the change will NOT be noted. So please try again..

Please do NOT paste configure outputs here unless asked for.
And this bug is about PHP 4, not PHP 5 so try the correct snaphot. (PHP 5 beta 4 is too old already anyway)

I will try this myself on an AIX machine.

I tried the latest PHP 4 snapshot from CVS yesterday, unzipped it, out came the directory name, "php4-STABLE-200403081230", build it and still get the error code of 66 with error string of "Addr family not supported by protocol".

Let me know what you got and of what further homework assignment do I need to do.  By the way, I'm using the R/S6000.

Works fine for me with latest stable CVS snapshot on AIX 4.3.3.

Exactly what configure line did you use? 

The configure options I use are 

--snip--
./configure --disable-ipv6
--snip--

Try this:

# rm config.cache ; ./configure --disable-all --disable-cgi

And use the CLI binary for testing.

I'm also concerned that you may not actually be testing against 4.3... One of the error messages you noted in your original report "php_hostconnect: connect failed in ..." only appears in PHP >prior< to version 4.3.0.  As of the 4.3 branch that message contains noticably different text.

This discrepency doesn't necessary speak to the fact that the error is occuring.  But it raises a question as to whether there are "lingering ghosts" of the prior version.  Perhaps creating a conflict with 4.3 which leads to the emergence of the error.

Can you conirm that (after the copious number of recompiles you've been asked for) you're still getting that specific error message in your output?

It'd also be interresting to see if the sockets extension behaves in the same way:

<?php
  $socket = socket_create(AF_INET, SOCK_STREAM, 0);
  var_dump($socket);
  var_dump(socket_connect($socket, 'www.google.com', 80));
?>

or (for a slight variation:

<?php
  $socket = socket_create(AF_INET, SOCK_STREAM, getprotobyname("tcp"));
  var_dump($socket);
  var_dump(socket_connect($socket, 'www.google.com', 80));
?>

Of course, you'll need to ./configure --enable-sockets  in order to try these tests.

In response to sniper@php.net's comment...  Removed the config.cache, rebuild PHP with "./configure --disable-all --disable-cgi", ran the test script using CLI and still get this same error message.

--snip--
!#/usr/local/bin/php

Warning: fsockopen(): unable to connect to www.google.com:80 in <<file path omitted by me>> on line 6

66

Addr family not supported by protocol
--snip--

It had been observed that during most of those compilation using "make" I saw this warning messages.  I don't think this is related to socket stuffs but thought you may would to know.

-snip--
        gcc  -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend  -I/usr/local/src3/php4-STABLE-200403081230/TSRM  -O2  -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c -o ext/standard/file.o  && echo > ext/standard/file.lo
/usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c: In function `zif_fgetcsv':
/usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2308: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type
/usr/local/src3/php4-STABLE-200403081230/ext/standard/file.c:2373: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type
        gcc  -Iext/standard/ -I/usr/local/src3/php4-STABLE-200403081230/ext/standard/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend  -I/usr/local/src3/php4-STABLE-200403081230/TSRM  -O2  -c /usr/local/src3/php4-STABLE-200403081230/ext/standard/filestat.c -o ext/standard/filestat.o  && echo > ext/standard/filestat.lo
--snip--

In response to pollita@php.net's comment...

>>whether there are "lingering ghosts" of 
>>the prior version.
Could be, I wouldn't deny it.  The error message you saw in the original report was the output from the website.  The ./configure command line was 

--snip--
./configure --with-apache=../apache_1.3.27 --with-ibm-db2=/usr/lpp/db2_06_01 --with-openssl --with-mcrypt --with-curl --without-mysql --enable-track-vars
--snip--

Since then, I found that I can produce this error through the CLI, so I did away with the website and use CLI instead because it is alot quicker to recompile than it is with PHP and webserver.  Since then there have been a numerous recompiling as instructed by this bug report.

>>Can you confirm that you're still getting that 
>>specific error message in your output?
I can confirm that the "php_hostconnect" does not exist anymore.  I am unable to reproduce this "php_hostconnect" error this time.  I don't remember what I did to make this happen.  All I know is that it was as result of fiddling around with the wording in the fsockopen()'s parameter arguements to find out what work and what doesn't.

>>Of course, you'll need to ./configure --enable-sockets  
>>in order to try these tests.
Okay, did the favor and recompile it with "./configure --enable-sockets" configure line.  Saw two warning messages, one from above and other is

--snip--
        gcc  -Iext/sockets/ -I/usr/local/src3/php4-STABLE-200403081230/ext/sockets/ -DPHP_ATOM_INC -I/usr/local/src3/php4-STABLE-200403081230/include -I/usr/local/src3/php4-STABLE-200403081230/main -I/usr/local/src3/php4-STABLE-200403081230 -I/usr/local/src3/php4-STABLE-200403081230/Zend -I/usr/local/src3/php4-STABLE-200403081230/ext/xml/expat  -I/usr/local/src3/php4-STABLE-200403081230/TSRM  -O2  -c /usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c -o ext/sockets/sockets.o  && echo > ext/sockets/sockets.lo
/usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c: In function `php_strerror':
/usr/local/src3/php4-STABLE-200403081230/ext/sockets/sockets.c:350: warning: assignment makes pointer from integer without a cast
--snip--

Ran the sample test of the codes you posted, I included both by the way.  Ran it through the CLI and here's the response I got...

--snip--
Content-type: text/html
X-Powered-By: PHP/4.3.5RC4-dev

!#/usr/local/bin/php

resource(1) of type (Socket)
bool(true)

resource(2) of type (Socket)
bool(true)
--snip--

Oh I forgot!  I did the "rm config.cache" and "make clean" before using this configure line, "./configure --enable-sockets".

First off, thanks for being so patient and helpful.  I'd like to ask you to apply a small patch which introduces several debug watchpoints.  Then compile, run your test script, and post the results (they'll be a bit on the verbose side).

http://169.229.135.175/test/27509-diff.txt

Not a  problem!  Been wanting the fsockopen() to work, so my company's website can function once again.  

Applied the patch and went through the programmer's ritual (compiling) all over again.  Out came the result, believe it or not, it's the same end result.   

--snip--
Content-type: text/html
X-Powered-By: PHP/4.3.5RC4-dev

!#/usr/local/bin/php

resource(1) of type (Socket)
bool(true)
resource(2) of type (Socket)
bool(true)
--snip--

Look like the four functions, "php_host_connect(***)", 
"php_network_getaddress(***)", "php_connect_nonb(***)" and 
"dump_stock_state(***)" wasn't reached and executed.

I did open up the network.c and 27509-diff.txt with the editor and check to see if the patch was applied correctly and I can confirm that the patch was insteed applied.  :-(

Sorry, I wanted you to run a test with fsockopen(), not the socket_* extension.  (Believe it or not they're completely different implementations even though they do the same thing)

<?php
  $fp = fsockopen('www.exmaple.com', 80);
?>

Please run that one against the version you've already patched and compiled.

Here's the response I got...  It's also the same with the host, "www.example.com" instead of "www.google.com".

--snip--
Content-type: text/html
X-Powered-By: PHP/4.3.5RC4-dev

!#/usr/local/bin/php

getaddresses
  GETADDRINFO method
  defaulting to AF_INET(2)  hints.ai_family = 0
  got result
    sai->ai_family = 2
  returning from getaddresses: n = 1
php_network_getaddresses returned 1
Creating socket of type 0 (AF_INET = 2)
  socket() returned: -1
<br />
<b>Warning</b>:  fsockopen(): unable to connect to www.google.com:80 in <b>/home/website/emarket/test_fsockopen_shell.sh</b> on line <b>6</b><br />

66

Addr family not supported by protocol
--snip--

That's..... I think "messed up" is the technical term.

I see two major problems here.

1) hints.ai_family is being reset by code that should be excluded by having used the --disable-ipv6 switch.

2) getaddrinfo() is returning a structure that, while it contains a top-level field insisting it's an AF_INET address.  Contains a sockaddr child structure with an ai_family of PF_UNSPEC.  So when php_hostconenect gets it, it tries creating a socket with an "unspecified" address family.  No wonder it's unsupported eh?

Let's go down this road:  

First, undo that patch, download a new tarball if necessary.  Heck, might as well grab the latest CVS snapshot.  Though if you reuse your current tree with a restored main/network.c you'll need to be sure and run `make clean`.

Next, run a normal ./configure with the --disable-ipv6 switch.

Now, BEFORE running make, edit main/php_config.h and check that HAVE_IPV6 is in fact, not defined.  If it is defined, comment it out (And let us know in your feedback).

Next, look for HAVE_GETADDRINFO in the same file.  Make sure it is also undefined. (I expect that it will be defined, so you'll need to comment it out)

Finally, run make, and try out the fsockopen test.

With the latest CVS tarball and the configure line, "./configure --disable-ipv6".  After configuring and before the make compilation.  The main/php_config.h showed ...

--snip--
/* Whether to enable IPv6 support */
/* #undef HAVE_IPV6 */
--snip--

So far, so good.  Again, checking for ...

--snip--
/* Define if you have the getaddrinfo function */
#define HAVE_GETADDRINFO 1
--snip--

So, it is already defined as you expected.  So, replacing it with "/* #define HAVE_GETADDRINFO 1 */".

Then on to make and installing.  So far, so good.  Then ran the fsockopen() test..  The result look good..

--snip--
Content-type: text/html
X-Powered-By: PHP/4.3.5RC4-dev

!#/usr/local/bin/php

0
--snip--

Then tested with the "Example 1. fsockopen() Example" from http://us3.php.net/manual/en/function.fsockopen.php and it work like a charm.

Let me know when the fix is made and get checked into the CVS for 4.3.4 build/branch and for 5.0 build/branch.  I'll be happy to do a few more testing if you need me to.

Is it still possible for me to use the ipv6 enabled later on?

I'd say "give it a shot".  The problem is sounding very much like a brokenness in the getaddrinfo() implementation rather than the IPv6 stack.

I'll see what can be done about building a getaddrinfo test into the ./configure process so that it's automatically disabled if it proves itself unreliable.

I want to discuss this with some people before making any commits, in the mean time I encourage you to try different settings with/without HAVE_IPV6 and with/without HAVE_GETADDRINFO.  Work in your normal ./configure options (i.e.: --with-apxs, --enable-ftp, --with-sqlite, etc...) as well.

I've committed an extended check to configure.in but it didn't make it into the 3/12/04 00:30 GMT snapshot.  You'll need to wait for the 3/12/04 02:30 GMT snapshot.

When you get a change to try that out, run ./configure (with whatever options you'd normally use).  after configure completes, check your main/php_config.h for the HAVE_GETADDRINFO line.  

If it's still defined (despite the revised check) then email me a copy of your config.log file.  Otherwise all should be well, go ahead and `make` and test out fsockopen().

Even if it works, reply back saying so, that way I can merge the change to the PHP5 branch and close this bug out.

Downloaded the CVS snapshot "php4-STABLE-200403121830" and did the configure line with the common options I use for Apache, like openssl, odbc, etc.  This time, I left out the "--disable-ipv6" option.  So far so good, re-checked the file, "main/php_config.h" for "HAVE_IPV6" and "HAVE_GETADDRINFO".  So far, so good.  The "HAVE_GETADDRINFO" is comment out as expected with the recent fix.  Went on to make and install PHP and test the fsockopen().  So far so good.  (Just want to test it just in case :-) ).  Then tried again with the same configure line but include the "--disable-ipv6".  So far so good with the "HAVE_GETADDRINFO" commented out and "HAVE_IPV6" with a value of "0".  The fix you checked in is working great!!  You got it!

Great, let's close it then :)

Yea!  Thanks for your time and patience with this bug too.