fopen on all URLs has started hanging

Telnet-ing into port 80 gets the same results as PHP.

Local addresses work when you GET / HTTP/1.0

Internet addresses connect, but do not return data.

[rstaveley@mims2 bin]$ telnet 126.110.15.101 80
Trying 126.110.15.101...
Connected to 126.110.15.101.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
....etc... Success :-)

[morrell@mims2 bin]$ telnet 192.0.32.10 80
Trying 192.0.32.10...
Connected to 192.0.32.10.
Escape character is '^]'.
GET / HTTP/1.0

[Nothing :-(]

Select allOpen in new window

I get the same with google.com and example.com. OK with cURL. Not OK with PHP or indeed telnet to PORT 80. I see it connect and send data and get nothing back.

is your port 80 outbound open check the server configuration it could also be php configuration

> is your port 80 outbound open

Yes, it works with cURL. You can see it connect with telnet too, but no data comes back.

> it could also be php configuration

Any ideas? I must say that the telnet test suggests that it isn't only PHP which is failing to open URL streams. It sounds like Perl's LWP and cURL work reliably, but PHP and using telnet by hand is somehow getting clobbered by the switch.

Lynx also works.

The following lower level PHP also doesn't work:

<?php
$fp = fsockopen("www.example.com", 80, $errno, $errstr, 30);
if (!$fp) {
    echo "$errstr ($errno)<br />\n";
} else {
    $out = "GET / HTTP/1.1\r\n";
    $out .= "Host: www.example.com\r\n";
    $out .= "Connection: Close\r\n\r\n";
    fwrite($fp, $out);
    while (!feof($fp)) {
        echo fgets($fp, 128);                                                }
    }
    fclose($fp);
}

Select allOpen in new window

...Hmm actually that last PHP does work, but not always

have you checked apache log whats going on there in error log as well access log

No clues there, alas. I'm doing most of my testing with the CLI. There is no information in the apache log though, when I test with a web page.

i guess thats the limit of command line, since when you experienced this problem did it start today or its been happening for a while

Couple of days. I've no doubt that the switch is what's changed. It is a SuSE system, and I notice that the YAST package manager is also unable to fetch from sources, so I can't install php5-curl to see if the PHP cURL library is the way to go with this. Otherwise there is a lot of code to edit.

[rstaveley@mims2 bin]$  curl -L -I http://example.com
HTTP/1.1 200 OK
Date: Tue, 13 Apr 2010 23:11:43 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
ETag: "24ec5-1b6-4059a80bfd280"
Accept-Ranges:  none
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

Verbose:

[rstaveley@mims2 bin]$ curl -v -L -I http://example.com
* About to connect() to example.com port 80
*   Trying 192.0.32.10... connected
* Connected to example.com (192.0.32.10) port 80
> HEAD / HTTP/1.1
> User-Agent: curl/7.15.1 (x86_64-suse-linux) libcurl/7.15.1 OpenSSL/0.9.8a zlib/1.2.3 libidn/0.6.0
> Host: example.com
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Tue, 13 Apr 2010 23:13:28 GMT
Date: Tue, 13 Apr 2010 23:13:28 GMT
< Server: Apache/2.2.3 (CentOS)
Server: Apache/2.2.3 (CentOS)
< Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
< ETag: "24ec5-1b6-4059a80bfd280"
ETag: "24ec5-1b6-4059a80bfd280"
< Accept-Ranges:  none
Accept-Ranges:  none
< Content-Length: 438
Content-Length: 438
< Connection: close
Connection: close
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8

* Closing connection #0

I think your problem is related to something called SELinux.  As root try typing:
setenforce 0
as root on the command line and then trying your php script.

Nice idea. I read that AppArmor is SuSE's equivalent of SELinux. I've just tried disabling it as indicated below, but it doesn't fix the problem.

mims2:/etc/security # /etc/init.d/boot.apparmor stop
Unloading AppArmor profiles                                          done
mims2:/etc/security # chkconfig -d boot.apparmor
boot.apparmor             0:off  1:off  2:off  3:off  4:off  5:off  6:off

Select allOpen in new window

These were helpful suggestions, but the solution lay in having an engineer sort out the switch ... though my own "low level" implementation was not too bad as a stop-gap. It looks like the switch was set up to be intollerant of the high-level implementation. Perhaps the low-level approach is quicker? We'll never know. Thanks for the help anyway, chaps.