Dmitri,

Your old friend Bill here... I just switched from an old Win2000 development machine to an XP system. At the same time, I upgraded to PhpED 5. Now I can't get remote debugging to work on my G5 Mac. Any help would be most appreciated.

Thanks.

Bill

Here are the relevant details.

Error message:

I can telnet from 10.15.192.106 to 10.15.192.241:7869, and I have verified the listener on 10.15.192.241 sees the connection when I do.

I have turned off every proxy setting I can find, on both machines.

traceroute from 10.15.192.106 to 10.15.192.241 results in:


Other relevant details:

The server is set up to use ports 80, 443 and 6000. I get the same error with all of them.

Client Setup:

WinXP Pro Version 2002 Service Pack 2
PhpED 5.0.1 (5029)
PHP DBG Listener 3.2.1

Server Setup:

PowerPC Mac G5
OS X 10.4.9
PHP 5.2.0

php.ini Settings:

phpinfo() results:

On further testing, I find that the problem only occurs when trying to connect to the site that uses port 6000. The areas that use ports 80 and 443 do work.

I installed dbg-wizard in both the standard (port 443) and nonstandard (port 6000) directories. The results indicate that for port 6000, the wizard thinks that PhpED and the webserver are on the same machine, while on port 443 it thinks they're on different machines. Here's the output:

Port 6000



Port 443



When I added 10.15.192.106 to debugger.hosts_allow in php.ini, the error "Debugger request" entry on the error pages changes from "393115555623000024;d=1,p=0,c=1" to "393115558563500025@clienthost;d=1,p=0,c=0".

Now I'm really confused.

Bill

to work with 10.15.192.106 machine you have to update your php.ini:
debugger.hosts_allow=10.15.192.241 10.15.192.106


you need dvg 3.2.3 in order to work with phped 5.0.1 (build 5028 and higher)


Seems you're using http proxy for 443 and 80 ports.

I've done both things and restarted the webserver, but continue to get the same error.





I've confirmed again that when I telnet 7869 from the server to 10.15.192.241 that the listener opens a connection. The debugger window, however, still shows that it can't make a connection.

Hi Bill,

It may appear (and we got many reports) that under some environments Apache can not open outgoing connections. Please check your firewall, /etc/hosts.deny and /etc/hosts.allow. It worth to try to run fsockopen('10.15.192.241', 7869, errno, errstr) from php and check the resulting errstr and errno.

Hi Dmitri,

OLD: I tried the fsockopen() routine and got an error number of 61 -- no error string. Does that help?

NEW: My original test was conducted remotely. Now that I'm back in the office, I tried again. The fsock() test does work.

What's odd is that nothing has changed on the server (10.15.192.106) side. The changes are on the machine that runs PhpEd -- I've moved to a new machine running XP instead of Win2000, and moved to v5 of PhpEd. (Of course, I did have to upgrade the debugger module on 10.15.192.106.)

If we can't resolve this, can you suggest what configuration I should go back to so I can start debugging again?

Thanks.

Bill

Hi Dmitri,

While it would be extremely nice to be able to debug on my development server, it's ultimately necessary that I be able to do so on my production server, which is a Quad-Intel XServe. Unfortunately, there doesn't seem to be an OS X Intel debug module yet.

I've traded some emails with your colleague Yury about having me compile the module for you. He suggested we might need to delay for a couple of weeks because most of Nusphere's engineers are on holiday. Is there any way we could do this sooner? Until we get remote debugging working on one or the other of my machines, I'm stuck back in the dark ages, adding "print" lines to my code to see what's going on.

Let me know what you think.

Bill

Network error 61 means "Connection refused" (read firewall rejected it)


Please check if you still can do it and 10.15.192.241 is the same machine where you tried to fsockopen() to open socket to:
fsockopen("10.15.192.241", 7869, $errno, $errstr, 10);


It may make sense, because XP comes with firewall, whereas Win2K does not.


as soon as you get fsockopen to work against your client machine and dbglistener sees it, you'll be able to debug too. Verify your server firewall, your client machine firewall and all firewalls in between.


There are some performance issues with debugger in all 3.2.x versions up to 3.2.3. I'd recommend you to wait for 3.2.5 when the problems will be fixed.

I'm sorry, he was correct

Hi Dmitri...


I've verified that dbglistener does see fsockopen(), and I can telnet from 10.15.192.106 to 10.15.192.241, and that dbglistener sees that, too. Unfortunately, I still get this:


As I mentioned in my second post on this thread, it seems that on port 6000 the debugger sees 10.15.192.106 as the client, instead of 10.15.192.241 as it does with other ports.

At first I thought it might be related to Firefox's default port blocking, so I added port 7869 to network.security.ports.banned override. That didn't help, so I tried Explorer and get identical results.


I've verified that Windows Firewall is disabled. And just in case, I tried adding a service entry in the Advanced settings to allow port 7869 traffic I also tried checking everything in the ICMP advanced settings tab.

Bill

Per our conversation by email, it appeared that there was HTTP proxy server.
After correct Debugger Host was specified in the debugger settings (tools->settings->debugger), it started working fine.