FTP Server: Freezes when I try to quit

35 views
Skip to first unread message

matthias mauritz

unread,
Oct 10, 2023, 5:52:40 AM10/10/23
to mTCP
Hi everyone :),

First of all I would like to say mTCp is great and I really appreciate all the time/love invested into it. 

I am however running into one small issue.

Whenever I try to quit the ftp server on my dos (regardless if I transferred something or not) the dos freezes and the "shutdown requested" message stays on screen forever - I then manually have to send the shutdown command via Vmware player.

My system: (running on a virtual machine)
- HP w/ intel i3 @ 3.7GHz
- Windows 10 v.22H2
-FTP client: WinSCP
- VMWare Player 15
- MS-Dos 6.20
   -> with 16MB Ram, 1 cpu

I was previously running on VMware player 16 however, in the docs it says everything was up and running with VMware player 15 so I swapped over. 

Interestingly, the ftpserver quit as expected on the first boot of it in VMware player 15.
I did not transfer anything over.

Then as a second test, I transfered over a small file, which worked as expected however, the system then froze up and left me at "shutdown requested".

I wonder if anyone has encountered the same problem?

Thank you very much,
Matthias 

matthias mauritz

unread,
Oct 10, 2023, 5:55:09 AM10/10/23
to mTCP
Forgot to mention I am using:
mTCp v.2023-03-31
PCNTPK.COM as my NIC driver 

Message has been deleted

matthias mauritz

unread,
Oct 10, 2023, 8:47:18 AM10/10/23
to mTCP
Attached is a tracefile 
mtcp_trace.txt

Michael Brutman

unread,
Oct 10, 2023, 11:16:31 AM10/10/23
to mTCP
Matthias,

Nobody else is reporting something like this, but this week we now have two reports of things that should not be happening.  I suspect a "disturbance in the force." ;-0

The trace file looks truncated and I suspect that is because the virtual machine froze before the trace log was fully written to disk.  Please take another trace, but this time use "SET DEBUGGING=0x80FF" ...  the extra bit will cause the FTP server to flush the disk buffers after each trace message is written.  It also includes the packet data, so please send the trace directly to me to avoid exposing a password.  Also run CHKDSK before you start because you did have a hard freeze/crash.

Other notes:
  • VMWare 15 and 16 are both fine.  I'm using 16 but I used 15 for years.
  • The PCNTPK packet driver is fine as well.
  • Do you have any power saving or other device drivers in your DOS config.sys ?

-Mike

Message has been deleted

matthias mauritz

unread,
Oct 11, 2023, 3:24:30 AM10/11/23
to mTCP
Hi Mike,
I removed the last message as it superfluous.
Also, please ignore the tracefile I sent you - I was hasty.

In my autoexec.bat I found the line:
lh c:\bin\spooler.com /0 /C 
after commenting that out, the ftpsrv worked like a charm

Thanks,
Matthias

Michael Brutman

unread,
Oct 11, 2023, 10:25:59 AM10/11/23
to mTCP
Can you send me the spooler.com program and any readme or text file that comes with it?

Assuming it is a print spooler, it probably hooked the timer interrupt.  mTCP programs also hook the timer interrupt.  In this case the FTP server comes last, so it hooks the timer interrupt and then chains to the next code, which will be the spooler, which then in turn finally calls the BIOS code for updating the tick counter.  When the FTP server (or any mTCP program) ends, it removes itself putting the spooler back at the top of the chain.

This should not be a problem so I'd like to understand what is causing the bad interaction between the two.

(Ping is a special case; besides hooking the timer interrupt, it also reprograms it to run faster.  But the hooking/unhooking part is the same; ping just sees more interrupts and filters only the expected number to the rest of the chain.)


-Mike

Reply all
Reply to author
Forward
0 new messages