-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RemoteHostIP & RemotePort are empty #8
Comments
Yes, this is a regression. I'll see to it some time when I get back in front of my PC next week. |
Thanks a much for your time to fix ip. That works now. Sorry, if they are too noob-like. Following image demonstrates sending packets from host to guest VM and vice versa (that is a previous patch w/o port fix yet): Host: VM:
Very appreciate your answers, when you have time. |
Try listen on
Is this VirtualBox? (No, I see it's VMWare now.) It uses NAT for VM networks by default. Try setting network to bridged and assign IP from your real LAN card subnet.
If your VM is bridged it has "real" IP from your LAN subnet so you can forward directly to it. If forwarding is not working to your real machine probably listener was setup incorrectly on When you start listener on |
Lot of thanks for your detailed explanations! They was very helpful. Everything works. One question: by design, when we are listening for a "localhost" only "preferred" network interface is catched. |
You have to listen to a specific local IP address that is assigned to this second LAN adapter. Since commit 186a4dd you can use I can tweak it to return more info like network name or default gateway address, not only IP and subnet mask as currently impl. |
Is there a method to pass the whole array of IPs (subnet) from the second adapter to listen for? |
No, you can either bind a socket on 127.0.0.1 is the IP address of the local loopback adapter but so is 127.0.0.2 and every other address in 255.0.0.0 subnet so you can listen on (and connect to) all these addresses too. |
Ok, thank you. |
About security:
Is that a bug with RemoteHostIP / RemotePort, so we unable to verify the sender?
The text was updated successfully, but these errors were encountered: