mOBSCENE wrote:Just realized you are actually the developer of mTCP :-) Nice of you to reply here! […]
Show full quote
Just realized you are actually the developer of mTCP 😀 Nice of you to reply here!
I am using the latest version of mTCP (2015-07-05). It seems that whenever there's an incoming packet, my computer freezes. Also, all outgoing packets are only counting towards the "Sending errors" (when I use PING.EXE to an unavailable IP address), when viewing the stats with PKTTOOL.EXE. All other counters remain at 0.
IRQ on packet driver is correct (confirmed by 3Com setup, which also passes all diagnostic tests). And since I have zero issues transmitting/receiving packets using the TCP tools from Microsoft, it must be an issue with the packet driver on my end (perhaps related to shared memory, I don't know). Tried a clean boot (no other drivers loaded), different INT setup's for the packet driver, but all with the same result. The mTCP debug log shows parts of a packet being received at the end of the logfile, just before my computer freezes completely.
Since I'm kind of desperate to get this working, I am going to try some other NIC's (just ordered an Intel PRO/1000 GT and an Intel PRO/100B from eBay).
As for EtherDFS: my main feature request would be an option to unload EtherDFS from memory. For the purpose of enabling/disabling network access completely, without requiring a reboot. This way we can continue to play our conventional memory hungry games directly. That would really be great 😀
I rarely get bug reports so I have to go looking for them. 😀
It's good that the Microsoft tools work; that indicates that the hardware and cabling are good. So then the packet driver or mTCP are at fault. You can try one of the WATTCP utilities to see if the behavior is any different. If a WATTCP based program and mTCP both fail then you know where the problem is.
There are four possible things to consider when loading the packet driver. The hardware interrupt, I/O ports, and the memory window (if used) have to match the hardware exactly. If the hardware interrupt is wrong you won't get incoming packets. If the I/O ports are wrong then you probably don't even get the correct MAC address reported when you load the driver. And if a memory window is used it has to be be correct or your data will be garbled.
The fourth item is the software interrupt - that's the handler that the packet driver installs for mTCP or other applications to use.
None of these can have conflicts. If you share an IRQ on an ISA system you will get spurious interrupts or the wrong interrupt handler will be processing your network card interrupts. It's not supported unless you know for certain that the other piece of hardware is not generating interrupts and there is no installed interrupt handler for that interrupt yet. PCI is different; sharing is allowed, but I have no idea how that works in a DOS environment, so just make sure it is unique.
I/O ports and memory windows ... basically the same problem. You can't deal with conflicts. The hardware will not work.
The software interrupt just has to be one that is not already in use. You can use debug.com to examine them and see what is already in use or not. Experimenting with random ones between 0x60 and 0x7F is generally; they are not used too often so try 0x61 or 0x62. Software interrupts are first come, first served for assignment so on a cleanly booted system with few device drivers or TSRs they should all be available.
I've used mTCP to debug bad hardware before. It happens. Given that your hardware works with the Microsoft utils you should snoop around their settings to see what IRQ, I/O ports and memory window they use. Also, your packet driver executable might be borked; try a version from another driver disk/Zip file.