skip to Main Content

I know there are a lot of posts on the internet about this subject, but I have been debugging this over two days now and I don’t seem to get any further.

The setup
I have a (pretty old) Vagrant box on my work laptop that’s been setup mostly by a former collegae. Everything seems to be still working for me and my collegaes so we don’t have had any reason to setup a completely new one.

The Vagrant box contains a Centos installation on which we develop websites.

The host machine is Windows 10.

The problem
When in the office, connected to the physical network (by cable), I can use XDebug without any problems. I enable XDebug from my Firefox browser plugin and XDebug on Centos then connects to PHPStorm on Windows, so I can step through code.

However, when at home, on WIFI (I don’t have a cable) XDebug just won’t work.

The XDebug log on the Vagrant machine currently states the following:

I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to 10.10.10.1:9000.
E: Time-out connecting to client. :-(

Research
In many posts I read that the Vagrant host address should be something like 10.0.2.2. As far as my information goes in our case it has always been 10.10.10.1.

I also read that from the Vagrant box you should check the host IP by using netstat. The host IP would be the default Gateway.

At home (while on WIFI) I tested this and the output was:

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.220.2   0.0.0.0         UG        0 0          0 ens32
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens34
192.168.56.0    0.0.0.0         255.255.255.0   U         0 0          0 ens34
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 ens32

Here the default Gateway is “192.168.220.2”. So I tried to set that IP for xdebug, by manually setting XDebug’s remote_host to 192.168.220.2 and disabling remote_connect_back

Now the log says:

I: Connecting to configured address/port: 192.168.220.2:9000.
W: Creating socket for '192.168.220.2:9000', poll success, but error: Operation now in progress (29).
E: Could not connect to client. :-(
Log closed at 2020-01-26 08:19:34

From other posts I understood that this is in fact worse and the IP-address is just wrong, because it should be an internal IP-adress like 10.10.10.1

Edit 1: I tested this today while in the office, connected to the physical network. XDebug works as expected, but the output of netstat is the same for the Gateway, so this probably has nothing to do with it:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.220.2   0.0.0.0         UG        0 0          0 ens32
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens34
172.24.1.0      0.0.0.0         255.255.255.0   U         0 0          0 ens34
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 ens32

Edit 2: While in the office, I now also tested XDebug while on WIFI (by disconnecting the physical network cable) and then XDebug no longer works. So the problem does not seem to be specific to my home network, but rather to being on physical network VS WIFI.

PHPStorm says I’m fine
PHPStorm has this xdebug validate screen in the settings. Trying that passes everything with green checks. Appearently that validation doesn’t validate enough?

Interesting to note
Simultaneously I was also trying to mount a Samba share from Windows into my Vagrant box. I wanted to experiment with that setup, but just like XDebug the mount command is unable to reach the host machine.

Edit: I tested this today while in the office on the physical network and this then doesn’t work either. So we can probably forget about this for now as this seems to be a completely different issue.

Edit 27-01: I thought I fixed the problem, but this only worked when on WIFI at the office. At home, it still doesn’t work.
The fix in the office was fiddling with IP routes in the Centos server.

Edit 29-01:
I still don’t have this working, but after several tests I think I can state that the VM can reach the host:
ping 10.10.10.1 works
nmap -p 9000 10.10.10.1 seems to tell me that it can reach the port

Besides that today I found out that when PHPStorm is not listening on port 9000, the XDebug log file says:
“Creating socket for ‘192.168.220.2:9000’, poll success, but error: Operation now in progress (29).”
But when PHPStorm is listening for a connection the XDebug log says:
“Remote address found, connecting to 10.10.10.1:9000”

The fact that the errormessage on the VM’s side changes when the state of the host changes, makes me believe that the connection is coming through.

That would mean that – for some reason – PHPStorm simply is unable to handle the incoming connection. The only reason for that I could think of is that PHPStorm may not be able to talk back to the VM?? Does that sound plausible? And if so, how to further investigate this?

2

Answers


  1. The following phrase seems to indicate that a connection is made.

    W: Creating socket for '192.168.220.2:9000', poll success, but error: Operation now in progress (29).
    

    Are you sure that it is PhpStorm that is listening on port 9000 locally? And that your Vagrant box can talk to it?

    Let’s find out the first one: In a shell on your host (which runs Windows in both cases, I presume), run:

    C:> netstat -a -b
    

    And make sure that it is the PhpStorm process that is listening on port 9000.
    If it is something else, change the port in the PhpStorm config to something else (say 9003), and make that same port the value for the xdebug.remote_port setting in php.ini. The turn off “listening for debugging connections” in PhpStorm, and turn it back on again.

    Secondly, test whether the Vagrant box can talk to that port

    Login or Signup to reply.
  2. I had a similar issue and for me it was an issue with the host machine network profile. It was not discoverable in the private network on allowing it for discover in the private network it did worked.

    Below is the configuration in my Windows host machine after which it did worked.

    Network Profile Configuration

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search