I have 3 DOS machines that used to be able to communicate with a Windows NT Server VM but won't now. I have several Wireshark captures of attempts at filesharing, both successful (in the past) and failed (of late).
I also have the original physical Windows NT server that the VM is supposed to replace. The physical server is still working for some reason. I've attached a Wireshark capture of failed attempt at requesting files from the VM and then a successful attempt to get files from the physical server.
IMPORTANT NOTE - To access the Wireshark capture file, rename the zipped file to remove the .txt extension and leave the file ending with .pcap
All of the machines involved are part of a Presstek press laser imaging system. There are 3 DOS machines that control several lasers apiece, a Windows NT Server that stores the data to be imaged, and a Windows 95 VM that coordinates the imaging process.
I'm trying to replace the original Windows NT data server with a similar VM. The DOS machines can't seem to communicate with the NT Server VM anymore.
DOS Machine 1: ICU_1 or Intel-Hf_5c:9d:b3
DOS Machine 2: ICU_2 or Intel-Hf_5c:80:1d
DOS Machine 3: ICU_3 or Intel-Hf_5c:80:a0
Windows NT Server (Physical): DI_SERVER2 or 192.168.172.179 or Adaptec_1A:78:f0
Windows NT Server (VirtualBox VM): DI-SERVER3 or 192.168.172.110 or CadmusCo_f9:6a:4c
Windows 95 (VMware VM): Prism_VM or 192.168.172.113 or Vmware_96:7b:50
The problem looks to me like the DOS machines cannot resolve the name of the NT Server VM (packets 461-566). I don't know how to fix that. I've tried all I can think of and google. I have no idea what might have changed in our environment that might caused this.
The capture included shows the Prism_VM telling the DOS machines to start imaging from DI-Server3 (VM). The DOS machines edit some log files on Prism_VM, and then try to find DI-Server 3. They fail name resolution, give up, and write the failure to the logs on Prism_VM. At this point I restart the imaging process using the physical data server instead (DI_server2). The process starts all over again and instead of failing name resolution the capture ends in the middle of the DOS machines happily requesting and receiving data from the physical data server.