I have a website which I have developed on my local PC, but which has been deployed on 3 different remote servers under 3 different domain names. I can successfully fire up the debugger on two of these domains, but the 3rd keeps failing with:

failed to connect to the client at 80.177.120.119:7869, please make sure that IDE is running (which it is!).

When I use the Project Properties Settings Wizard the "Checking PHP installation" panel shows all green ticks, but when I go on to the next stage to check the debugger it immediately comes up with:

UPnP: Port mapping error 0x80004005, please wait.

All are looked after by the same sysadmin guy, and he swears that all three domains are setup up in exactly the same way. The server firewall has been set up for port 7869 to allow outbound TCP connections, and my IP address has been added to the "debugger.hosts_allow" list in the php.ini file.

I am using PhpED 6.2 (build 6234) with debugger version 4.2.11.
I am connecting through a Linksys router which has UPnP enabled.
Synchronisation between project tree and website is donre through other tools.
Web server document root matches project root directory.
I do not connect to the server using SSH.

Any ideas on how I can resolve this issue?

Do you run Windows XP on the client machine? If so, you have to install uPnP client first.
Don't forget about firewall on the client machine - it has to allow incoming 7869 and all ports involved in upnp.

Yes, I am running Windows XP machine. Yes, I have checked that UPnP is installed. No, it does not make any difference.

Of course it makes difference. Without uPnp client, dbglistener can't change portmapping on your router.
If you still get an error, you have to update your Windows firewall -- add rules and allow certain ports:
Open firewall settings, Exceptions tab, and find uPnP Framework and make sure it's checked.
Also you have to ENABLE exceptions on the main tab.

If you can't find uPnP framework settings, you can create one with the following properties:
TCP/2869 Scope: Subnet
UDP/1900 Scope: Subnet

Also take into account that linksys (cisco) may update its portmapping settings very very slowly -- up 2 minutes or even more.

When I said "it doesn't make a difference" I meant that my problems still appears whether UPnP is installed or not.

I don't use Windows Firewall as I use Norton Internet security instead.

I don't see how this can be a firewall issue anyway as I can successfully debug 2 other remote sites. If there was an incorrect setting at my end surely I would not be able to debug *ANY* remote site.

If you can debug any remote hosts out of your local network and you don't use ssh tunnel, it means that port mapping already works for you.

Regarding firewalls, Windows' one still works until you explicitly disable it. For example. If it works, you have to check and update its settings
As of Norton, it's still the same, you have to add TCP port 2869 and UDP port 1900.
With correct settings in firwalls, you won't get the error XXXX you posted here as a subject.

I have tried updating Norton's firewall for the following:
1) Allow inbound UDP connections on port 1900 from any computer.
2) Allow inbound TCP connections on port 2869 (should that be 7869?) from any computer.

I am still getting te same error.

I have just looked at the Norton firewall log after trying to debug 2 of these sites, and I see a slight difference. THis is waht I saw after a debug session worked on one site:

Rule "allow inbound TCP connections on port 7869 (for DBG debugger)" permitted (74.204.188.31, port 7869), inbound TCP connection.

Strange, because when I run dbg-wizard.php it shows the server IP address as 74.204.188.125.

When the debug session fails to start on the other site the Norton log shows this:

Rule "allow inbound TCP connections on port 7869 (for DBG debugger)" permitted communication.

Strange, because it does not show the IP address of the remote server.

I'm not a networking or firewall guy, so I can't tell if this is significant or not.

Tony, it's your server and just two addresses. Isn't it very easy to setup firewall _AND_ linux SE (if you run linux on your server) tp allow connections FROM server to the CLIENT machine? Yes, in this direction - from SERVER where dbg module starts connection TO your client machine where dbgLISTENER is running.
In this way there are FOUR things to check:
-SE Linux (if your run Linux) on your server
-server's firewall
-client firewall
-router (if any) in between

If server and client are on different networks - they are connected through the router. In this case you either use ssh tunneling and in this case you'll see connections from localhost (127.0.0.1) or use port mapping and this case you'll see connections from your router.

The Linux server is *NOT* running Linux SE. Although the sysadmin assured me that he had opened up port 7869 in the firewall for outbound connections he later discovered that the hosting company, UKFast, had blocked all but the standard ports. He got them to unblock it and asked me to try again. This time I found that I could debug all the sites on my desktop, but nothing at all on my laptop.

I checked the firewall log on my router, but it showed nothing. It was, after all, allowing inbound connections to my desktop.

I adjusted the firewall (Norton Internet Security) to log any connection attempts on port 7869, and it showed that such attempts were being received from the remote server, and that they were being allowed through. In spite of all this the DbgListener log was showing nothing. I eventually noticed that the "Enable IPv6" option was checked on, so I turned it off and tried again. All of a sudden everything sprang into life and I could debug all my remote sites from my laptop! What a relief!

Can anybody explain why the "Enable IPv6" option would prevent the listener from acting upon received conections?