Member Avatar for MVied

In this management software I'm working on, I've built a messenger for the employees to use to IM each other. Recently we moved to a brand new server and upgraded from PHP4 to PHP5. Now the instant messenger won't work. I've opened port 7357, which is the port it uses on both the firewall on the server (Ubuntu Hardy Heron v8.04 using Ubuntu Firewall) and on the gateway router. I even went as far as to disable the server firewall and allow any traffic through any port from any source to any destination on the gateway router and I still get a Connection refused (111) error from the script. Does anyone have any experience with this that could give me a few tips?

Many thanks,
MVied

  • 1 Contributor
  • 1 Reply
  • 106 Views
  • 13 Hours Discussion Span
  • Latest Post Latest Post by MVied

Dani AI

Generated

Good to see you tracked it down, . For others who hit silent socket failures after moving a service or upgrading PHP, the cause is often something outside the app code. The checklist below covers quick, practical checks that commonly catch the “silly” root causes.

First, confirm the target process is actually listening on the expected interface and port, and test reachability from the web host. Useful commands:

ss -tlnp
# or, if netstat is available
netstat -tlnp

# from the PHP host, test the remote endpoint:
nc -vz TARGET_HOST TARGET_PORT
# or
telnet TARGET_HOST TARGET_PORT

A tiny PHP test can isolate whether PHP can open the socket at all (replace HOST and PORT):

<?php
$fp = fsockopen('tcp://HOST', PORT, $errno, $errstr, 5);
if (!$fp) { echo "$errstr ($errno)\n"; } else { echo "Connected\n"; fclose($fp); }
?>

Other less-obvious things to verify:

  • PHP configuration: disable_functions can block socket functions. Check via php -i | grep disable_functions or phpinfo(). See the PHP ini docs for details: disable_functions.
  • Service binding: some daemons bind only to localhost or to an IPv6 address. Confirm the daemon is listening on the expected IP family and interface (use ss/netstat output).
  • Local security layers: AppArmor/SELinux profiles or local permissions may prevent connections. Ubuntu AppArmor docs: AppArmor wiki.
  • Hostname resolution: try connecting by IP to rule out DNS or /etc/hosts mapping issues.

For the socket side of things the PHP manual for fsockopen is a handy reference: fsockopen — Manual. These steps catch the non-code problems that often look like mysterious socket failures.

Member Avatar for MVied

I've solved my own problem and it had nothing to do with coding, firewalls, or the router. =P

I'm silly.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.