Trying to set up debugging on a 3rd party server, I'm getting the message "failed to connect to the client address 127.0.0.1:7869"

Firstly, I wonder why it says 127.0.0.1 instead of the IP address of the remote server.

Secondly, the help pages that the error message page link to include the following instruction "make sure that /etc/hosts.allow and /etc/hosts.deny do allow connection for DBG service on outgoing port 7869". There's no indication how this should be done - that is, what is the correct command to add to the hosts.allow file. Does anyone have the answer to this?

Thanks

Daniel

You might want to check out this. You'll find more information about the hosts_allow and deny directives there. By default the debugger only allows localhost connections.

Thanks, but I'd already seen that. I've successfully followed all the instructions there and in the pages linked to from the error page I get in the browser when I try to do remote debugging.

The same instruction appears on the page you've directed m e to as on the other one, namely:

make sure that /etc/hosts.allow and /etc/hosts.deny do allow connection for DBG service on outgoing port 7869

All I'm asking is "How do I do that?"

No syntax is provided. What should I write into the /etc/hosts.allow file?

My debugger ini parameters already say debugger.hosts_alllow ALL, but I'm still unable to debug.

Ow sorry!
Well the configuration that the explanation talks about is in the php.ini file:

For example, this is the config on my internal development system:


Notice I've been lazy and just allow connections from all IPs, the firewall on that
machine only allows connections on the debugger port from the internal lan anywayz
Small hint: if you are running php as a module via apache, you have to restart apache after modifying the php.ini file.
And when in doubt, phpinfo() is your friend (it will also tell you the location of the ini file)/

Edit:
(and some extra info now that I read your initial question properly):
The files the error message refers to are actual text files on a linux distribution (in the /etc/ directory) in which you have to specify the hosts that are allowed to connect to the machine. This does not open up the ports in any firewall you might have on the development machine.
Naturally these files do not exist on a windows machine.

Anyway to debug:

* you have to make sure that your local project properties are correct (especially the Root URL and the Remote Root directory), this is something you need to take care of on your development machine.
* modify the php.ini file so that the debugger configuration allows connections from your development machine
* modify the firewall and/or the etc/hosts.* files so that the machine itself actually accepts your connection as well

Thanks, and I already had most of what you say (albeit in dbg.ini not php.ini, but phpinfo() confirms that the dbg.ini file was parsed)

What was missing from my debugger settings in the ini file was the last two lines you provide:
debugger.JIT_enabled=on
debugger.JIT_level=1

I've now added these and rebooted my server (just for good measure).

No change. Still the same error page when I try to debug remotely.

Incidentally, if we're dealing with the settings in the .ini file, why do the help pages talk about /etc/hosts.allow and /etc/hosts.deny? Is that just a red herring?

For the moment, I'm still stuck and still relying on local debugging, which for various reasons is a sub-optimal solution for me.

I haven't yet gone down the SSH route with this setup (though I have it working on another server and another project), because on this particular project I want to have the same setup as a colleague who is doing it without SSH.

Any further help welcome

Daniel

JIT = Just In Time debugging. If I'm not mistaking that allows for the DebugBreak() functionality so it's not really required for a normal debugging session, I just like to be able to browse normally and then let the server break me into debugging (easier sometimes).

The debugging connection has to be allowed on 2 levels:
1) You have to be able to connect to the specified port on the machine itself (nothing to do with php or debugging). This is (amongst others) where the /etc/hosts.* files come in. On a *nix server, you can use these files to specify which IP's are allowed to connect to specific daemons.
a default rule would be something like:
ALL : <your pc's IP> : allow
Which will tell the server to allow connections to all daemons from your PC. Note that if the remote server is in your LAN, you need to use your internal IP there. If it is on the internet, use your external IP. Also, if your server is firewalled, you need to open up port 7869 for traffic.

2) If that is all in working order you can start worrying about the dbg server accepting the connection, but it seems you already have that part down

Perhaps you can try to telnet to the server to test and if required use the DBG Wizard script?

What kind of OS are you running on the debugging server?
As I said, the /etc/ message does not count on a windows machine.

My apologies for the previous replies, I've read your initial request too quickly and thus replied with the wrong stuff.

Blizz

Thanks for your efforts so far.

I have been working with Daniel on this before he posted. We have an identical set-up but mine is working, I even http://bealers.com/2008/01/20/debugging-with-phped-and-dbg/ the steps I had to follow over the weekend in some detail.

To summarise:

* DBG is installed & configured correctly (as far as we can tell)
* Server can connect to client via telnet

We are both running identical (his cloned from mine) Debian Etch virtual machines, AFAIK there is no firewall, I certainly had to make zero changes to /etc/hosts.[allow|deny] though as per your pointer this has now been done correctly for his network and to be sure done a full reboot on server, still no joy.

What we cannot understand is why when we initiate a debug session the error message in browser is:

DBG 3.2.10

Failed to start DBG session


Reason: failed to connect to the client address 127.0.0.1:7869
Not sure what it means? Visit http://www.nusphere.com/dbg/ for troubleshooting.

Debugger request: "394696739764100018@localhost;d=1,p=0,c=1"
Request found in: "query_string"
Target PHP version: "5.2.x"
Server API: "Apache 2.0 Handler"
Extensions API: "220060519"
Modules API:


What *exactly* does the message tell us? Why 127.0.0.1? The debugger is requesting via localhost, is that the servers localhost or is it infact inferring that for some reason Daniel's client is trying to connect to the server on his local machine which is of course wrong.

The client referred to in the error message is that the machine running PhpEd?

I'm wondering if it's a simple name resolution issue so we've checked the URL under project properties and it correctly resolves to his server, we've added it to the hosts file (on server and client) to be sure.

We've given up for now but it would be good to get this solved, any further pointers or clarification would be appreciated.

It seems that for some reason the debugger actually receives the debugging request, but attempts to connect back to the client via the localhost IP (at least that's the impression I get).

Why don't you try it the other way around? The DebugBreak function allows you to initiate a debugging session from the server to the client and
you can specify a client IP as the argument (the argument you can pass follows the same syntax as the DBGSESSID).
So perhaps you can add
DebugBreak ( '1@clientip;d=1' );
to your script. If you run it and a debug session starts, you at least know that all connection stuff is working properly.
Then all we need to find out is why it attempts to connect back to localhost instead of the client IP.
Just a question: You did configure PhpEd to debug using a HTTP/3rdparty server right?

Also another small suggestion perhaps: bealers, if everything is working fine for you, why don't you try to debug on
daniels server with your client?

Dmitri will probably be able to help you out much better when he comes on, I'm not really that good when it comes to remote debugging, I've always used
a duplicate testserver in my own LAN to debug.

This is what makes the difference. It looks like you changed debugger settings and entered localhost in the debugger host setting. It won't do until you use ssh tunnel for the debugging.


in versions before 3.0, dbg shipped with PhpED used tcpwrapper library to check if connection is not prohibited there. It followed the syntax described in man pages hosts_allow(5). The reason why we asked to check that file, is because some system had ALL deny (mostly prohibited) and it did not let dbg to work.
BUT, since dbg version 3.0, it's not supported anymore. It's enough to have debugger.hosts_allow, debugger.hosts_deny and debugger.ports to control what hosts can work with debugger.

I'm sorry for the misleading documentation.

Thanks for this Dmitri.

Yes, changing Tools > Settings > IDE > Run and Debug > Debugger host from localhost to clienthost works, and I now have remote debugging on my new project. Great!

However, the reason why it was previously set to localhost was that I have another ongoing project for which I'm using tunelling to the server.

This means that, now, each time I change from one project to the other, I have to go into my settings and change from localhost to clienthost or vice versa. Is there any way this can be made into a project-specific setting rather than a global setting?

I'll check if we can do something with this in the next major version.