mTCP NetDrive, corrupt HD image following SYS command

[Steve Hunt]

Hi,

Playing around with the current mTCP NetDrive, and found if I run the SYS command against a virtual hard drive, it corrupts the image.  This only becomes apparent after disconnecting and attempting to reconnect the disk image.  

The error on the PC is:

  Error opening virtual hard drive: hdd20.dsk,

     Bad BPB and file size doesn't match a 160K or 320K DOS 1.x disk

I've got NetDrive server running on a laptop running Windows 10 Pro, version 22H2,

The disk image was created on the Windows laptop, as follows:

  netdrive create hd 20 fat12 HDD20.DSK

The PC, using the virtual hard drive is:

  JB-3300 Panasonic Portable Computer (8088, 4.77 MHz)

  MS-DOS versio 3.30

  Packet drive SMC/WD/IBM Ethernet adapters, version 11.7.3

  mTCP version 2023-03-31

  mTCP Netdrive version 2024-05-23

Attached is a log file produced by NetDrive Serve.

Other mTCP commands appear to work just fine.

Happy to try further test.

All the best,

Steve

[Michael Brutman]

Arg ..  I should have hit "reply to all."

I tried this with PC DOS 2.1 and it worked. DOS 6.x it refused to run SYS against a network drive letter.

Steve sent me the first sector of the image after it was corrupted and it looks like MS-DOS 3.3 wrote garbage where the BIOS Parameter Block should be:

• The first three bytes are a jump, as expected.
• The next 8 bytes are an OEM name, which is expected too.  (It is now MSDOS3.3, it used to be NETDRIVE.)
• The next two bytes are the number of bytes per sector, which is 512 - good.
• After that is the number of sectors per cluster.  8B is too big and not a power of two, so this is broken.
• The next two bytes are a reserved sector count - this is also huge compared to what it should be.
• 0x08 is not a valid number of FAT copies - it should be 1 or 2.
• You get the idea ...

I'm going to try it with PC DOS 3.3 in the next day or two to see if it has the same behavior.

I suspect it is a bug in that version of SYS, as the BPB was good before SYS got to it.  (The bytes that overlaid the BPB look like code.)  The good news is that unless you are trying to make the disk image bootable, you don't need to run SYS against it.

-Mike

[Michael Brutman]

So I came back to this recently and tried to figure out what is going on.  Here is what I found:

• SYS.COM from IBM PC DOS 3.3 will write garbage for the BIOS Parameter Block in sector 0 when used on a disk image that looks like a hard drive.  (The original report came from MS-DOS 3.3, which should be very similar.)
• The garbage bytes are being sent across the wire, so it's not a data corruption issue with NetDrive.
• It will also do the same thing when used on a RAM disk in memory.  (RAM disks are designed to mimic hard drives with respect to the BPB and media descriptor byte in FAT; they are just smaller.)

However, it will correctly transfer the system if a floppy disk image is being used.

In DOS 3.3 Microsoft and IBM introduced the "generic IOCTL" in DOS and device drivers, which is used to get or set block device parameters, format tracks, etc.  My theory is that if SYS.COM looks at the BIOS parameter block or the media descriptor in the FAT and sees a floppy disk format it does the right thing.  But if it sees something different it tries to use the generic IOCTL call and fails.

I tried the generic IOCTL call for myself, first on a real drive supported by the BIOS and then on a NetDrive image.  The real drive responded to the generic IOCTL call as expected.  I don't implement generic IOCTL in the driver, so the IOCTL call failed with the Carry Flag being set.  This is expected.

I then went looking in SYS.COM and found where they do a generic IOCTL call.  And they don't check the Carry Flag ...  which is a major error.

Sure enough, I looked for the bad bytes being written into the BIOS parameter block and I found them at offset 0x849 in the file.  It's code from inside of SYS.COM.  My bytes are different than yours because I'm using the PC-DOS 3.3 variant, but I'm certain you are getting hit with the same bug.

Wrapping it up, DOS 3.3 SYS.COM looks to have a bug when looking at devices using generic IOCTL.  If the device doesn't implement that it plows ahead and writes garbage into the BIOS parameter block of the drive.

-Mike