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?
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
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
Related
I got a webserver running on my Mac on localhost:3000 and I am trying to set a local DNS with dnsmasq and to be able to access that DNS from local devices (iPhone / iPad) for test purpose.
I followed this previous post:
iPhone: add entry to /etc/hosts without jailbreaking
I am looking to redirect all *.localhost here
dnsmasq.conf:
/etc/resolver/localhost:
dig google.com:
The Mac Network DNS config:
On my phone, on the same network, adding the Mac Local IP as DNS:
Wi-Fi is connected to xxxxxx and has the IP address 192.168.1.11.
I am able to connect to myapp.localhost:3000 successfully on the Mac but getting Server cannot be found on the iPhone.
Must be missing something there.
EDIT #0: 2021/07/08
netstat -anvp tcp | grep '\b192.168.1.11.53\b' output:
open a terminal and use netstat to check if your dnsmasq is open on 192.168.1.11
if the result is similar to
root#dns-01:~# sudo netstat -tnlp
tcp 0 0 127.0.0.1:53 0.0.0.0:* OUÇA 13376/dnsmasq
it means that it will only accept queries from the local machine, not from your network.
to query from your network you must see something like
tcp 0 0 192.168.1.11:53 0.0.0.0:* OUÇA 13376/dnsmasq
or
tcp 0 0 0.0.0.0:53 0.0.0.0:* OUÇA 104287/dnsmasq
I have a vagrant box with xdebug installed, running on OSX, but Im struggling to get the Atom xdebug plugin (php-debug) to connect to it.
I pasted the phpinfo(); data into the xdebug validation site and it said all was good. And you can see all the xdebug settings.
I have mapped port 9000 in the vagrant file.
config.vm.network :forwarded_port, guest: 9000, host: 9000
The vagrant box has host only network that exposes 192.168.10.100 as the IP of the server.
And I've tried all manner of different xdebug options, the ones on the ATOM plugin site suggest..
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart=true
But that is a slightly confusing as remote_connect_back=1 means xdebug will ignore the remote_host setting - so not sure why both are in there - neither work.
I've restarted apache / php after each time I change the options, and check they are loaded with phpinfo();
If I check who is listening on port 9000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Atom\x20H 10656 Matt 28u IPv6 0x321cb0a96ba5b593 0t0 TCP *:cslistener (LISTEN)
VBoxHeadl 10889 Matt 19u IPv4 0x321cb0a981a71433 0t0 TCP *:cslistener (LISTEN)
You can see both vagrant (virtual box) and Atom. Although Atom is IPv6 which is odd....
But enabling the debugger in ATOM, setting a breakpoint and hitting the site, nothing happens - ATOM never connects.
Any ideas? Anyone got this to work?
But that is a slightly confusing as remote_connect_back=1 means xdebug will ignore the remote_host setting
You are correct -- that option is not needed there -- it better be set to 0
xdebug.remote_host=127.0.0.1
This is wrong (unless you will be doing debugging via SSH tunnel). It must be an IP where debug client (Atom in your case) is running. It's xdebug who connects to client and NOT other way around: https://xdebug.org/docs/remote
This also means that the IP must be as seen from that Vagrant machine. Possibly the easiest way of getting it -- look at what $_SERVER['REMOTE_ADDR'] has.
I have mapped port 9000 in the vagrant file.
config.vm.network :forwarded_port, guest: 9000, host: 9000
You do not need to expose 9000 port in Vagrant -- nobody will be connecting to it (like you do with port 80 for web server) -- it's xdebug from VM/guest OS will be connecting outside to your "real"/host OS.
If anything -- you should be allowing outgoing connections on that port instead of incoming.
If I check who is listening on port 9000
This one means that Atom is unable to receive incoming xdebug connection over TCPv4 .. which xdebug will try to use by default (unless you specify IPv6 address in xdebug.remote_host).
If anything -- collect xdebug log (xdebug.remote_log) and see where it tries to connect etc.
#LazyOne already answered this question, but issue I had was caused by antivirus (MCAfee) which was blocking incoming traffic. Maybe this will help someone in the future.
my host OS is window7;
my guest OS is centos7 is runing on virtualbox;
i hope share centos7's files for window7 via samba server;
the samba server is runing in the centos7;
when centos7 connect network with "Bridged networking" or "Host-only networking" ;
Assuming that the centos7 IP is 10.254.254.254;
i can Configuring a-network-driver for window7,like "\\10.254.254.254\www",it is working;
now,i only want to use "Network Address Translation Service (experimental)" for the centos7; but i still want to share centos7's files for window7 via "samba server";
i can Configuring port forwarding with NAT,like that:
hostIP:port <= guestIP:port
0.0.0.0:80 <= 10.254.254.2:80
127.0.0.2:22 <= 10.254.254.2:22
now i can visit my web : http://192.168.1.8 or http://127.0.0.2;
and connect the ssh server: 127.0.0.2:22
it working;
but,if i Configuring the smb port forwarding with NAT,like:
127.0.0.2:445 <= 10.254.254.2:445 (it not working)
127.0.0.2:139 <= 10.254.254.2:139 (it working)
i know i can not re-bind the 445 port for "centos's" smb server;
so, i can not share file via "\\127.0.0.2\www";
then,i google,some one say:"window smb server and client port is 445";
now i think:"can i change the window's port of 445 to anyother number,4450?5555?",if it can,i can Configuring the smb port forwarding with NAT,like:
127.0.0.2:4450 <= 10.254.254.2:445
127.0.0.2:1390 <= 10.254.254.2:139
i had try :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters
Value Name: SmbDeviceEnabled
Type: REG_DWORD
Value Data: 0
and then restart window7, but the "netstat -p TCP -noba" still show me:
[svchost.exe] TCP 0.0.0.0:445
try change port to 5555,and restart,but fail,the port still show me 445
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Smb]
"SessionPort"=dword:0000022b
"DatagramPort"=dword:0000022b
any idea ?
thank you!
Because of this problem cannot be solved;
I am using the following solutions now:
1 rebuid my nginx service from nginx-source,to add webDAV mod;
2 share centos7's files via nginx-webDAV service;
why?
because i found:
when i use "host-only" and "NAT" for centos,They are all the LAN IP address ;
when the guest os's ip setting like that:
the interface of "host-only":
IPDDR=10.254.254.254, and my host os don't sharing my WIFI for it,
so it can't connect to WAN,
becuase i only want it share me centos's files ;
the interface of "NAT" :
ipddr=10.0.0.2,it can connect to WAN,
for the other services,like:ssh/web/mysql, and so on;
then ssh/web/mysql don't know connect to which GATEWAY.
maybe i can write some "route" to fix it,but it is a big bad thing;
I have been trying in the past few days to build and run a very simple network to no avail (most of the network I try to build is borrowed from extServer example). No matter my configuration in terms of IP addresses, routes etc. I cannot seem to make it work.
I have seen many people struggling with it, but have not found any solutions posted anywhere. The readme file in the Emulation folder of INET is more confusing than helpful.
Hence, I would like your help in making the following simple network work and, hopefully, even make it (the post) a tutorial for others as well.
The network I want to build (could not be simpler):
External Server <----> [ext0] ROUTER [ppp0] <----> [ppp0] Standard Host
My setup:
Software:
OMNET++ 4.6 with PCAP enabled.
INET Integration head (includes several features that I like).
OS:
Xubuntu in VirtualBox as a guest which hosts OMNET++. The reason for using Virtualbox is that my Host Win 7 machine refuses to run any external interface example with the error "cSocketRTScheduler: couldn't set socketopt for raw socket.". I modified the source a bit and used WSAGetLastError function, which resolved the issue as "The requested address is not valid in its context.".
Back to VirtualBox :)
Xubuntu has one network interface set to Host-only networking with IP address 10.0.0.1 and netmask 255.255.255.0 .
Standard Host Setup in omnetpp.ini:
**.server.numTcpApps = 1
**.server.tcpApp[*].typename = "TCPSinkApp"
**.server.tcpApp[*].localAddress = "172.0.1.111"
**.server.tcpApp[*].localPort = 10021
The standard host is using the same server.mrt from extServer example.
The router.mrt is as follows:
ifconfig:
# interface 1 to server
name: ppp0
inet_addr: 172.0.1.100
Mask: 255.255.255.0
MTU: 1500
POINTTOPOINT MULTICAST
# interface 2 to external server (real network interface)
name: ext0
inet_addr: 10.0.0.2
Mask: 255.255.255.0
MTU: 1500
POINTTOPOINT MULTICAST
ifconfigend.
route:
#Destination Gateway Genmask Flags Metric Iface
172.0.1.111 172.0.1.100 255.255.255.255 H 0 ppp0
10.0.0.1 10.0.0.2 255.255.255.255 H 0 ext0
0.0.0.0 * 0.0.0.0 G 0 ext0
routeend.
Any ideas on how to make this network work are really welcome as, should it work, I want to expand it later. Also, I would greatly appreciate it if any suggestions are in step-by-step style.
Thank you in advance.
I'm trying to set up a transparent proxy on my Mac OS X Lion (10.7.5), so I can use mitmproxy (to intercept SSL traffic from android applications). I followed the steps in the mitmproxy docs for setting up port forwarding with pf on Mac OS X, and they all went without any errors:
$ sudo sysctl -w net.inet.ip.forwarding=1
Password:
net.inet.ip.forwarding: 0 -> 1
$ sudo pfctl -f pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
But it doesn't seem to have had any effect. When I go to websites in my browser, it makes a direct request, and doesn't go through the port I specified. Here is the pf.conf file (en1 is my wifi):
rdr on en1 inet proto tcp to any port 80 -> 127.0.0.1 port 4500
rdr on en1 inet proto tcp to any port 443 -> 127.0.0.1 port 4500
Thanks for stopping by the IRC channel today. I've tracked this down, and the basic issue is that the rdr rules apply to inbound traffic. This means that they will NOT redirect traffic coming from the box itself. If you think about it, this is inevitable: we can't distinguish between an outbound connection from a non-mitmproxy app, and an outbound connection from mitmproxy itself. We can use route-to to send the traffic to lo0 and then redirect it, but that causes an infinite loop where mitmproxy's own outbound connections are also redirected back to mitmproxy.
Because I know a bit about your use case, I would suggest exploring ways to do this with VirtualBox. A plan of attack would be to set the VirtualBox network up in bridge mode, and then use a pf rule with a match on the source address to redirect traffic to mitmproxy. That should do what you want, and not cause singularities in time and space due to infinite redirection.
Please drop by the IRC channel again if you need a further hand with this.
Did you try net.inet.ip.scopedroute=0? From http://lucumr.pocoo.org/2013/1/6/osx-wifi-proxy/:
Now currently if you finish that above setup you will notice that
nothing actually works. The cause for this is a Bug in the OS X kernel
that requires flipping the net.inet.ip.scopedroute flag to 0. I am not
entirely sure what it does, but the internet reports that it breaks
network sharing through the user preferences. In any case it fixes
ipfw based forwarding so you can flip it with sysctl:
$ sudo sysctl -w net.inet.ip.scopedroute=0
Unfortunately in OS X Lion this flag can actually not be flipped from
userspace so you need to set it as boot parameter and then restart
your computer. You can do this by editing the
/Library/Preferences/SystemConfiguration/com.apple.Boot.plist file
(continued...)
You are using the port 4500 instead the default port 8080.
Do you start mitmproxy with the port specification?: mitmproxy -T --host -p 4500
Did you follow the steps to set the certificate in the Android device? http://mitmproxy.org/doc/certinstall/android.html
Another problem could be the gateway on your android phone: Preferences - Wifi - Hold on the network you are using - Edit network - Advanced options - Set as gateway the ip of your machine with mitmproxy.
By the way I have the same warning with No ALTQ function but it works.