NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
Connection to the client address <address> is not allo


Joined: 08 Aug 2010
Posts: 8
Reply with quote
OS: Windows 7.0
Web Server: IIS 7 on local machine
PHP: 5.3.6
============
Ok, this problem has me totally frustrated. Confused

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:
Code:
[PHP_EXIF]
zend_extension="C:\Program Files\PHP\ext\dbg-php-5.2.dll"
zend_extension="C:\Program Files\PHP\ext\dbg-php-5.3.dll"
[debugger]
debugger.JIT_enabled=Off
debugger.JIT_level=3
debugger.hosts_deny=ALL
debugger.hosts_allow=127.0.0.1
debugger.ports=7869
extension=php_exif.dll

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)?
View user's profileFind all posts by eclerkinSend private message
Guru master

Joined: 24 Jul 2009
Posts: 716
Reply with quote
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.
View user's profileFind all posts by plugnplaySend private message


Joined: 08 Aug 2010
Posts: 8
Reply with quote
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.

Code:
I assume that you placed me in the root directory of your web server and on your PhpED machine pointed your browser to me - like this: <URL of your web site>/dbg-wizard.php

I see that:

PHP Version:  5.3.6
Web Server:  Microsoft-IIS/7.5
Server Name:  localhost
Platform:  WINNT/x86_NTS_VC9
Your Client IP Address:  127.0.0.1
Your Server IP Address:  127.0.0.1
Port:  80
Your Web Server is on the same machine with PhpED   
Path to website files:  c:\inetpub\wwwroot\wordpress\
Document Root is:  c:\inetpub\wwwroot\
Your PHP.INI file is:  C:\Program Files\PHP\php.ini
PHP extensions directory is:  C:\Program Files\PHP\ext
DBG (PHP DEBUGGER) Version 4.0.5 is   INSTALLED


Code:
[PHP_EXIF]
zend_extension="C:\Program Files\PHP\ext\dbg-php-5.3.dll"
[debugger]
debugger.JIT_enabled=Off
debugger.JIT_level=3
debugger.hosts_deny=ALL
debugger.hosts_allow=127.0.0.1 ::1
debugger.ports=7869, 10000/16
extension=php_exif.dll


Code:
DBG 4.0.5

Failed to start DBG session


Reason: failed to resolve client address [::1]
Not sure what it means? Visit http://www.nusphere.com/dbg/ for troubleshooting.


Debugger request:   "407213611195100007;d=1,p=0,c=1"
Request found in:   "query_string"
Target PHP version: "5.3.x"
Server API:         "CGI/FastCGI"
Extensions API:     "220090626"
Modules API:        "20090626"
PHP API:            "20090626"


Last edited by eclerkin on Mon Jun 27, 2011 7:39 pm; edited 1 time in total
View user's profileFind all posts by eclerkinSend private message
Guru master

Joined: 24 Jul 2009
Posts: 716
Reply with quote
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. Wink

Failing that, try reporting to NuSphere support and when you get a fix, please post it back here Smile
View user's profileFind all posts by plugnplaySend private message


Joined: 08 Aug 2010
Posts: 8
Reply with quote
plugnplay wrote:
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. Wink

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


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]
View user's profileFind all posts by eclerkinSend private message
Guru master

Joined: 24 Jul 2009
Posts: 716
Reply with quote
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.
View user's profileFind all posts by plugnplaySend private message


Joined: 08 Aug 2010
Posts: 8
Reply with quote
plugnplay wrote:
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.
View user's profileFind all posts by eclerkinSend private message
Guru master

Joined: 24 Jul 2009
Posts: 716
Reply with quote
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
View user's profileFind all posts by plugnplaySend private message
Site Admin

Joined: 13 Jul 2003
Posts: 7875
Reply with quote
try to set Debugger Settings->Override client Address->Client Addres to 127.0.0.1

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 08 Aug 2010
Posts: 8
Reply with quote
dmitri wrote:
try to set Debugger Settings->Override client Address->Client Addres to 127.0.0.1

YESSSS!! That solved the problem. Thanks so much Dimitri!
View user's profileFind all posts by eclerkinSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 7875
Reply with quote
you're welcome

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website
Veteran

Joined: 06 Jun 2007
Posts: 289
Location: Vancouver, Canada
Reply with quote
I had the exact same thing on a new machine... thanks to this forum the problem is fixed now. Smile Ironically the documentation where the error page links to suggest not enabling overriding the client address Shocked

_________________
Smile
View user's profileFind all posts by annoSend private messageVisit poster's website
Connection to the client address <address> is not allo
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 1 of 1  

  
  
 Reply to topic