I have written a C application to run on a small wireless network (linksys router). The application uses named pipes. When the server is a Win 7 machine and the client is a XP (Pro, SP3) machine the named pipes connection works fine and the app runs perfectly. However, when I swap roles and make the server the XP machine and the client the Win 7 machine, the pipe fails.
I have tried turning off the firewall on the XP machine and that doesn't solve the problem.
File and print sharing between the two machines works fine.
Any suggestions would be most gratefully accepted.
Related
I'm developing a command line (in Golang) which interacts with Docker. It works fine on Linux & Mac, although I have a bug when I try to make it work with Windows 10, but I don't have a Windows 10 laptop available.
What are my solutions ? I've tried the nested virtualization, but Hyper-v (which is used by Docker Desktop) is not able to start in my Windows virtual machine (created with VirtualBox which obviously doesn't support thise use case).
The Cloud providers don't seem to support this use case either, I'm kind of stucked.
recently we have problems with our Ubuntu SMB shares connecting from WIN 10 1903. ON one PC (complete separate net and new PCs updated) we can see with smbstatus -version that it uses smb3_11 with encryption. That work fine from our WIN 10 1903 PC also. But on another system net with other PCs, it handles protocol SMB3_02 without encryption. And we can not connect the ubuntu share from our WIN 10 1903 PCs at all. Can anyone here explain how we can force to handle SMB3_11 ?
Thanks
EDIT: I have made a protocol for SMB connection, and here you can see the not working and a working protocol. Could this be of an unsupported NIC?
I am trying to run commands on the cmd prompt of my windows xp mode virtual machine from my main computer which is in windows 7. I've tried to look at the name of the windows xp mode computer which is virtualXP-63912, so i tried : "psexec \\virtualXP-63912 cmd" but it doesn't work. Any ideas of how I can get this to work?
As seen here, you need to change your VM from 'NAT' mode, which allows for web access but no local network connectivity (which is what you need to be able to psexec or run remote powershell commands on your XP mode VM, and also to be able to access the \computername\admin$ share, which is what PSExec uses for remoting) to NIC mode, which will bridge your VM to the network, and give it a local routable IP address.
In short, open the Windows XP Mode console, select your XP Mode Vm and go to settings, then change the network setting to bridged, as discussed in this post from Microsoft on the issue.
Finally, if I may suggest it, move off of XP Mode. It's not supported well these days and the new replacement, Hyper-V for Windows 8.0 and above is built-in to the desktop OS and is much, much more feature filled. You can copy and paste from your desktop into a VM, and run machines with Linux, even OSX on your Windows machine.
We have been using a program called knock.exe successfully under Windows XP to knock on some set of ports which will then allow a connection to be established via ssh on another port to a remote machine. This program worked fine under Windows XP, but under Windows 7 it takes a lot longer to run (gives no error messages) and I am unable to connect to the remote machine.
If i run knock.exe inside a VM not running Windows 7 then connect using SSH from the Windows 7 machine, then it works.
Note that when running the port knocking application from Windows 7, the events get through to the remote machine because there is logging with the ip address of the local machine on the remote machine running knockd (linux).
I have also tried using knock7 from sourceforge with no success.
I have tried many other variations such as setting compatibility mode, and other port knocking applications with no success.
It seems like this is a change in the Windows 7 behaviour (possibly introduced in Vista) from the Windows XP behaviour.
It would be better to not have to run a VM just to do port knocking.
Any suggestions would be much appreciated.
Thanks!
use cygwin version of knock.exe
Currently I am working on signing a 64-bit driver for a USB tool which is used to scan areas of the skin.
My setup is like this:
DTM Controller and DTM Studio are
running on a Server machine (Windows
Server 2003 R2 SP2)
DTM Client running on a Client Machine (Windows 7 64-bit)
I have managed to run tests on the client, using DTM Studio, but I get a couple of errors and I´m not sure why but I have some ideas.
The failures I encounter are the following:
Run INFTest against a single INF
RunJob – Copy of CHKINF and INFTest Library Job
Could not find user specified INF files. Bailing out...
Could not expand user supplied list of infs into individual filenames.
Sleep Stress With IO
RunJob – Sleep_Stress_With_IO .
Device has issues and not ready for test. Device Problem Code is: 28
Disable Enable With IO
RunJob – Disable_Enable_With_IO
Device has issues and not ready for test. Device Problem Code is: 28
Common Scenario Stress With IO
Execute_Device_Status_Check_Script
Device has issues and not ready for test. Device Problem Code is: 28
When I located the INF file in DTM Studio and added the tests I received the error: „No devices using the specified driver“. This is off course correct as the machine running the DTM Client (Windows 7 64-bit) does not have the driver installed for the USB tool.
So my question is:
Do i need to install the driver for the USB tool on the client machine?
If that is needed then the client machine must run a different version of Windows which brings to me my next question:
Can I run Logo tests successfully for a Windows 7 64-bit OS when the Client (running DTM Client) is set up using a different OS?
I managed to answer my questions:
Do I need to i install the driver for the USB tool on the client machine?
Yes this is needed.
Can I run Logo tests successfully for a Windows 7 64-bit OS when the Client (running DTM Client) is set up using a different OS?
No. The client machine must be set up using the target OS.