I try to run program in Delphi7 and XP as virtual machine, the program include client and server and requires socket connections, but every time I try to run it, always showing error message like below.
I have already opened the scktsrvr.exe and I'm sure the port is right at both sides. The program need call the local port.
What confused me is that I tried with same environment and operation with my real PC and it works fine.
So I have no idea why I just can't run the program in a virtual machine. Or is there anything I should do if I want to use socket connections in a virtual machine?
Have found root cause, because of the setting of my client program.
I should set the server IP as local IP of my client program so it can connect the server part.
It's nothing about the virtual machine at all, though I don't need to do previous action in the real machine.
Whatever it has been solved.
Related
I have a flask app running on a remote WINDOWS server (this server has a fixed ip address) which is not on my local network. The flask app is used to return some json data. The app works fine when I try to access the data while being logged into the remote server through request module in Python. However, when I try to run the same script on my personal laptop (which is not on the same network as the remote windows server), I get an error. However, when I try to ping the remote server from windows command prompt, I get the answer back. Can somebody tell in which direction should I go? I have no experience with web / api development.
response = requests.get("http://127.0.0.1:5000/product/1)
But instead of the local ip address, if I substitute the remote ip address, I don't get anything back.
Ok, so the problem lied with the remote firewall, it was blocking incoming connections. The moment I switched off the firewall, everything started working.
I'm trying to debug a Drupal 7 app with Xdebug. My app resides remotely in a server with Ubuntu running Apache.
In Netabeans, I started a proyect with "Application From Remote Server", connected with SFTP.
In the remote server I have installed Xdebug as zend_extension, also i configured xdebug.remote_connect_back=1, xdebug.remote_autostart=1, etc... I've tried everything with no luck.
The log from Xdebug has entries like this one:
Log opened at 2014-12-24 13:01:31
I: Checking remote connect back address.
I: Remote address found, connecting to 181.175.73.24:9000
E: Time-out connecting to client. :-(
Log closed at 2014-12-24 13:01:32
Based on the log it seems that my computer is not visible from outside on port 9000. But port 9000 in my laptop is opened, listening, with Netbeans, that's what happens when a debug sessions starts.
I think it's a problem with my ISP. My IP is not only for me, so I can't manage it's ports or other configuration. I think my PC is not visible from outside.
So, the question is, how can I avoid this limitation? What could I debug my APP from my computer on a remote server?
Every answer is welcome. Using a program, using a service, both... I tried using pagekite but honestly I couldn't find a configuration that works for me.
Thanks everyone.
PD: I don't want Xdebug alternatives that don't do step by step debugging.
PD2: My Xdebug config is attached.
remote_connect_back won't do it for you, it just tries to connect to the public ip, it's nothing magic.
Can you ssh on the remote server ? You might want to try port forwarding over a reverse ssh tunnel.
Full details from the creator of xdebug:
http://derickrethans.nl/debugging-with-xdebug-and-firewalls.html
I am working on some start-up (pre-logon) code for Windows 7, and would like to be able to debug it (if only to see how it really works, as Microsoft's documentation is terrible).
My environment is VirtualBox on a Linux host, with three Windows VMs (a Windows 2008 domain controller, a Windows 7 dev machine, and a Windows 7 test machine), and I'd like to be able to debug the startup process of the test machine remotely from the dev machine using a virtual serial connection two virtual machines.
[I have, in another life, debugged Linux kernel drivers in one linux VM from another using VMware workstation on a Windows host so I know that this sort of thing is potentially doable.]
I've seen people using windbg to debug Windows in a VirtualBox VM from the host, but I need to do it from a second guest (because my host is non-Windows). Has anyone figured out how to do that?
Edit:
I had tried the obvious approach before I posted. I created a virtual serial port in each VM configuration and attached them both to the same host pipe, to be created by the dev VM (debugger) and used by the test VM (debugee). I then ran
bcdedit /dbgsettings serial debugport:1 baudrate:115200
bcdedit /debug {current} on
in the test VM and shut it down. Ran windbg in the dev VM selected kernel debugging (on the correct serial port) and restarted the test VM. Some messages appeared about not having any symbols available and the test VM hung.
I have since found this article: http://www.benjaminhumphrey.co.uk/remote-kernel-debugging-windbg-virtualbox/ which (although that guy is using a Windows host) seems to describe exactly the method I'd tried, but his test VM doesn't hang. The output I get in the wndbg window is the same as his, but stops before the line staring "Windows XP Kernel ..."
I'm now less sure that this problem is related to VirtualBox and more unsure as to whether I'm using windbg correctly. Any help would be appreciated.
Another Edit I have tried attaching the virtual serial port of the Test VM to a host file, and I get some debugging output in the file. I have tried setting the virtual serial ports of the two VMs to point to a host pipe and running a terminal (rather than WinDbg) in the Dev VM, and I get debugging information in the terminal.
I think I've now determined that this is definitely a problem with WinDbg rather than VirtualBox (I'll remove the virtualbox tag and replace it with windbg) but I'm not sure why WinDbg isn't talking.
More information:
I've just upgrade Upgrading to VirtualBox 4.2.4 (not sure whether the version matters) and have looked at this again.
I rebuilt the test VM and was more patient!
It now seems that the test VM is running - and I do eventually get some output in the windbg window - but it takes about 15 minutes for the debuggee OS to boot! This is clearly not useful for day-to-day kernel debugging. I have no idea why this should be so slow ... there is no perceptible slowdown if I run a simple terminal in the dev VM instead of windbg (though, of course, the debug information is then mostly garbage).
Any ideas?
I realize this is one helluva necro, but...
Have you tried setting up the debugee for kernel-mode network debugging? I'm thinking that the slowdown is in a large part because serial is so g.d. slow.
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439346%28v=vs.85%29.aspx
If/when M$ decides to rot away that link, these parts of above article are what you need to do to get this set up:
Setting Up the Target Computer
To set up the target computer, follow these steps:
Verify that the target computer has a supported network adapter.
Connect the supported adapter to a network hub or switch using standard CAT5 or better network cable. Do not use a crossover cable, and do not use a crossover port in your hub or switch.
In an elevated Command Prompt window, enter the following commands, where w.x.y.z is the IP address of the host computer, and n is a port number of your choice:
bcdedit /debug on
bcdedit /dbgsettings net hostip:w.x.y.z port:n
bcdedit will display an automatically generated key. Copy the key and store it on a removable storage device like a USB flash drive. You will need the key when you start a debugging session on the host computer.
Note We strongly recommend that you use an automatically generated key. However, you can create your own key as described later in the Creating Your Own Key section.
If there is more than one network adapter in the target computer, use Device Manager to determine the PCI bus, device, and function numbers for the adapter you want to use for debugging. Then in an elevated Command Prompt window, enter the following command, where b, d, and f are the bus number, device number, and function number of the adapter:
bcdedit /set "{dbgsettings}" busparams b.d.f
Reboot the target computer.
And to connect to it, use the following steps:
Using WinDbg
On the host computer, open WinDbg. On the File menu, choose Kernel Debug. In the Kernel Debugging dialog box, open the Net tab. Enter your port number and key. Click OK.
You can also start a session with WinDbg by opening a Command Prompt window and entering the following command, where n is your port number and Key is the key that was automatically generated by bcdedit when you set up the target computer:
windbg -k net:port=n,key=Key
If you are prompted about allowing WinDbg to access the port through the firewall, allow WinDbg to access the port for all the different network types.
Using KD
On the host computer, open a Command Prompt window. Enter the following command, where n is your port number and Key is the key that was automatically generated by bcdedit when you set up the target computer:
kd -k net:port=n,key=Key
If you are prompted about allowing KD to access the port through the firewall, allow KD to access the port for all the different network types.
I am working on a server/client based project. I almost finished my server side code.
I develop the server app in EclipseCDT on Ubuntu Desktop, and everything just works fine.
But when deploy my app to a Ubuntu Server (I tried Server 10.04/10.10), the server app can start normally (waiting for connection), but the same client just cannot connect to the server.
I use Socket for receiving and sending data to/from the client.
Peter
P.S.: if I install sudo apt-get install ubuntu-desktop on my server machine, then everything works fine again.
===========================================================================
New Findings from the source code:
LabelStartBlocking:
int newScoketId = ::accept(socketId, 0, 0); // socketId == 3 ::accept is define in socket.h
// waiting for connection
LabelResume: // if new connection coming
// Do something with newSocketId
The behavior difference between Ubuntu Desktop and Server is:
On Ubuntu Desktop version, when the server starts, it is blocked at LabelStartBlocking with the socket routine ::accept; and then if a new connection arrives, the server will resume at LabelResume and create a new socket connection using the return value newSocketId;
However, on Ubuntu Server version, when the server starts, it is also blocked at LabelStartBlocking with the socket routine ::accept, but if a new connection arrives, the server won't resume at LabelResume, and the new socket connection CANNOT be created.
Can you guys help me out?
Peter
Thanks for your attention.
I finally figured it out.
If there are more than one IP addresses for the same hostname (/etc/hosts), the old code will fail.
Example /etc/hosts file:
127.0.0.1 localhost YourHostName
10.50.10.251 YourHostName
I traced the calling stack, and I found that, the IP address (10.50.10.251) passed to the program is translated into hostname, and then later the hostname is translated back to IP address (for binding), but a DIFFERENT one, that's why my server program cannot accept any client connection.
Hope it helps if any others have the similar issue.
Peter
I am writing a script that powers on a system via network. And then i need to run a few commands on the other host. How do I know whether the system has powered on?
My programming language is Perl and the target host is RHEL5.
Is there any kernel interrupt or network boot information that indicates the system has powered on and the os has loaded?
[In a different scenario] I was also wondering just in case if i just switch on my Machine manually. when is it exactly said to have powered on. and when is the OS is supposed to have booted completely for a network related operation such as executing a network command there. What if the system is on DHCP how would a remote system then search for this machine [i guess it is possible via mac address. but if i am wrong ].
If I have missed out any info please feel free to ask me. If you have any suggestions to make the task easier please surface them :)
thanx
imkin
Well, I'd say the system is booted when it can perform the request you've made of it. That is, the sshd daemon is running. That's booted sufficiently for your purposes (I assume - substitute for whatever daemon you really need).
So, I'd send the power-on signal, and check back every 15-30 seconds to see if I could connect. If I've failed to connect within whatever is a reasonable time for that machine (2 minutes or 5 minutes or whatever), then I'd send an alert to the IT support team. Well, I'd send it to myself first, and only once I've investigated a few failures or so and found them to all be legitimate would I start sending it directly to IT.
DHCP is kind of a different question. You'd have to start learning about broadcasting, or having a daemon on that machine "call home" during boot to register its current IP address. And it would have to "call home" every time a DHCP renewal changed its IP address. This is decidedly more convoluted. Try to avoid DHCP on such server machines if at all possible.
On the rebooting machine you can install a script in your crontab with the special #reboot assertion (see man 5 crontab). That script could send a notification of some kind to the other machine, notifying it that it's up now.
I think checking for sshd sounds like a good approach.
As for the DHCP problem: if the other computer is on the same subnet you can look it up by MAC address using Net::ARP.
How about adding a script to the remote machine which gets run on startup to have it tell you when it is ready.