OS: Windows 7.0
Web Server: IIS 7 on local machine
PHP: 5.3.6
============
Ok, this problem has me totally frustrated.

I upgraded PHPEd from 5.9 to 6.0 and since the upgrade the debugger fails at start-up with

DBG 4.0.5

Failed to start DBG session


Reason: connection to the client at ::1:7869 is not allowed in php configuration
Not sure what it means? Visit http://www.nusphere.com/dbg/ for troubleshooting.

The C:\Program Files\PHP\php.ini shows the following debugger settings:

I un-installed/installed PHPEd 6.0 - 3 times now - and it still fails with the same error.
- There are no nasty grams from the Settings Wizard and all tests shows green checkmarks
- dbg-wizard.php is installed at my root folder (WordPress)
- PHPINFO shows C:\Program Files\PHP\php.ini as the correct location form the .ini file and it shows Zend Scripting Language posted at the top as well as the DBG PHP debugger of 4.0.5

Is this possibly a McAfee Security Firewall setting issue? If so, does the NuSphere executable require a Program Permission change to "FULL" as opposed to the current setting of "OUTGOING"? Are there any debugger executables that require the same settings (add to firewall program permissions)?

You've got an IPv6 localhost address ::1 showing. IPv6 support is new with PhpED 6, so it probably started using it automatically because you have it enabled.

It doesn't sound like the firewall is anything to do with the problem, because the dbg module is communicating then rejecting you. A firewall block probably would not have shown that Failed to start DBG session message.

I didn't realise you could load both dbg-php-5.2.dll and dbg-php-5.3.dll at the same time. Does that actually work? It doesn't really make sense because a php.ini should be targetted towards a specific version of PHP. For example, a 5.2 php.ini will often set safe mode, a 5.3 will not allow safe mode and also 5.3 normally requires an explicit time zone setting.

Maybe try adding ::1 to your hosts_allow (but leave the 127.0.0.1 there as well) and consider removing whichever dbg you don't need.

Well, I added localhost and ::1 to allowed_hosts but now I have a different error message (maybe bad syntax in directive). I discovered that I can execute dbg-wizard.php as a helper script to look at the settings and below are the settings used by debug.

Well ::1 is definitely the localhost address and the version of DBG is correct, so something strange going on. I have IPv6 on my PhpED 6 test system, but not Apache so I can't test the problem.

I had a search around and couldn't find anything indicating how to specify an IPv6 address to DBG. Originally it was obviously receiving and displaying your ::1, so strange it won't allow that to be specified in the php.ini, unless it needs wrapping in [::1] brackets or quotes or something.

Square brackets are valid with IPv6 so that addresses don't look like URLs, so maybe try using that. Hmm, if hosts_allow suports domain names, then [::1] actually has a reasonable chance of working.

Failing that, try reporting to NuSphere support and when you get a fix, please post it back here

I called NuSphere Support like last Thursday and I am still waiting for a return phone call. I will try your advice of enclosing the directive in brackets. This same version is installed on my Windows XP desktop and it works just fine with IIS 6.

EDIT: Brackets added to directive and the same error message as before: Reason: failed to resolve client address [::1]

I just had a quick play and hosts_allow does not allow the bracketed convention, as it causes the address parsing to fail and rejects any subsequent addresses.

For example debugger.hosts_allow=[::1] 192.168.1.9 means 192.168.1.9 no longer works, but it does not give an error for [::1].

Are you working in a safe/private network? If so, you could always try debugger.hosts_allow=ALL until NuSphere respond. Bearing in mind router firewalls would normally block port 7869, you could probably run like that long term.

Did you phone or use the online support? You might find online support gets to someone quicker.

Hopefully Dmitri will have a look soon, as he will probably have a quick answer.

First, I submitted an email about the problem and then a follow-up phone call. I tried the ALL directive just a minute ago (IIS7 stopped/started) and it did nothing. I am working on my laptop w/Windows 7.0/IIS 7 - no network involved.

Even if working standalone on a laptop, you are still using network.

Maybe try disabling IPv6 for now.

If you go into Manage network connections, right-click Local Area Connection, then in the list of items (normally near the bottom) you should see Internet Protocol Version 6. Untick that on the left (probably don't uninstall it, although you can choose to do that and re-install it later) then click OK.

I'm not sure if IIS will automatically update sites for the loss of the IPv6 address, so you could possibly do a restart just to ensure everything sees just the IPv4.

You can then try using the debugger again. This time it should use IPv4 and localhost will be back to 127.0.0.1

try to set Debugger Settings->Override client Address->Client Addres to 127.0.0.1

YESSSS!! That solved the problem. Thanks so much Dimitri!

you're welcome

I had the exact same thing on a new machine... thanks to this forum the problem is fixed now. Ironically the documentation where the error page links to suggest not enabling overriding the client address