NetDrive and "packetint ..."

[Stuart]

Hi,

I'm trying to set up my system (a diskless thin client!) to use mTCP netdrive. 

Everything works fine if my mtcp.cfg packetint line contains just one interrupt number (i.e. "packetint 0x60"), but as soon as I add a second interrupt to allow mTCP and other programs to operate at the same time as netdrive (i.e. "packetint 0x60, 0x65"), all mTCP programs (including netdrive) just fail with "Init: Could not setup packet driver, are the configured interrupts correct? Configured packet driver interrupt: 0x%X"

(Clearly an issue with the printf arguments there...)

The following line says:

"Configured NetDrive shim interrupt: 0x65"

(So some part of the code obviously understands it...)

Seems like it's not understanding the packetint line correctly? Or I'm misunderstanding the documentation?

Thanks,

Stuart

[Michael Brutman]

The printf is definitely a bug.

Did you update all of the programs?  Also, what version are you running?

--
You received this message because you are subscribed to the Google Groups "mTCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtcp+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mtcp/aecfbc60-3576-4e81-8f2b-7c49d85066f9n%40googlegroups.com.

[Michael Brutman]

Hi Stuart,

I'm going to assume you are running the newest code, and your  PACKETINT  line looks correct.

I think you have something else installed at software interrupt 0x65, which is why everything is breaking.  mTCP is trying to see if what is there is a packet driver at that software interrupt and it is not responding as a packet driver, so it is not usable.  Try a different, secondary packet interrupt number and it should work.

If you want to dive deeper, you can use DEBUG.COM to see what is there:

C:\DEBUG

-D 0:180

0000:0180 00 00 00 00 00 00 00 00 00 00 00 00 B1 02 C5 0A

0000:0190 00 00 00 00 00 00 00 00 00 00 00 00 A0 02 9F 02

My PACKETINT line specifies 0x63 and 0x65.  The first bolded addresses are my primary packet driver at 0x63.  The second bolded addresses shows 0x65 is unused, which is what it should be.  If there was something there I would see the error you are reporting.

I see the source of the printf bug and I'll get that fixed.  I'll also make the error message more obvious.  Let me know when you get it working.

-Mike

[Stuart]

Thanks for the help!

Yes, I am using the most recent versions of all the mTCP components (2025-01-10). Looking at that area of the IVT in DEBUG shows the repeating pattern "9E CD 00 F0" (I think that's the address F000:CD9E; in the BIOS segment?) in nearly every entry. This includes the vector successfully used by the packet driver (0x60) when I boot without loading it, so I doubt these entries are actually used by anything. Perhaps it's some remnant of the PXE boot process?

If I use a little DEBUG script to clear a few of those IVT entries during boot, everything seems to work just fine...

[Michael Brutman]

Ok, great - that's an unusual problem.

The only other machine I've seen that does something like that with the default interrupt vector addresses is a PCjr, which I explicitly handled in the code.  What kind of machine is this and what version of DOS are you using?

-Mike

[Stuart]

It's a Wyse "SX0" (model S10) thin client (based on the NSC/AMD Geode embedded platform; a ~350Mhz Pentium-like CPU). Running MS-DOS 6.22.

Just a little project of mine to see what such a system can do. Obviously it was never intended to run anything apart from the RDP/ICA client it has built into its ROM, but since it's possible to enable PXE network boot, getting it to boot a DOS floppy image over the network and use NetDrive for a "hard drive" opens it up pretty well. It can run Windows 3.1 to and, with a bit of messing around with PKTMUX this morning, I've got Trumpet Winsock to work (it seems the NetDrive "pass-through" isn't quite good enough for its needs). Only issue is that having Trumpet loaded makes NetDrive a lot slower, but I can cope with it; I really expected it not to work at all. NetDrive is a pretty impressively robust piece of software!

[Michael Brutman]

Thanks, it has been a fun project.

There is probably something I can improve, as normal packet drivers figure out how to handle the default value in the interrupt vector table.  I considered "looking through" the address to see if there was an immediate IRET instruction, but that actually failed on the PCjr because it does some other things too before getting to the IRET.

The other shortcoming that you ran into is that I did a minimal amount of work to enable the mTCP programs to piggyback on the NetDrive device driver.  My reasoning was based on "minimal" usually equates to "less surface area for bugs."  I'll improve it as time goes on, but for more complex uses pktmux is the way to go.

Regards,

Mike

--

You received this message because you are subscribed to the Google Groups "mTCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtcp+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/mtcp/fb1dfab5-d65a-42e1-ab55-8bb7c9aa7409n%40googlegroups.com.