Perhaps the mis-detected link type is a clue? I've never tried one of these in DOS (except the older ISA ones), perhaps the HW has some issues that Windows driver works around but the DOS one is too dumb for that. If you have an older 10Mb/s hub try connecting that between the card and your current network hardware, chances are the DOS driver was written for older Realtek cards and defaults to 10Mb/s for some reason.

I don't think it's the case the driver was written for older cards because there are separate packet driver .COMs for the older 8029 (driver dated 1995) and the newer 8139 (driver dated 2000)

PnP hardware and DOS can always be fun... I'd guess resource allocation may be an issue. Given it sometimes does and sometimes doesn't work, it could be worth checking which resources (hw address, DOS IRQ and software interrupt) you're using in the one case and which in the other.

Note by the way that the 8139B and C are subtly different so potentially there could be driver differences there, although I'm not aware of any different drivers being available.

I've found a workaround. I'm not sure whether it's my specific card being old or the W98 drivers being strange, but it seems that when W98 shuts down, it leaves the card in a bad state. (Possibly in the EEPROM - it persists over a reboot, so where else would it be I guess?)

Using the Realtek diagnostics tool RSET8139 in DOS, I can view and write a new EEPROM configuration to the board. If I set the card's Medium Type to 'Auto Detect', it'll set the Flow Control to 'Nway Flow Control Enable'. After writing those settings to the EEPROM, the packet driver correctly determines the link type and all the MTCP suite tools work perfectly.

I also get a lot of 'Fail Count' for the 'I/O Register' on the On Board Diagnostics sometimes - not sure what to make of that. When the card's EEPROM is rewritten, that goes away.

The RTSPKT from http://www.georgpotthast.de/sioux/packet.htm is 3.40. The one from Realtek https://www.realtek.com/en/component/zoo/cate … et-pci-software is 3.44. I didn't notice any difference between the two.

Did you try a cold reboot? As in, cut power for at least a few seconds? Recently I've read in some 3Com docs that some mobos do not properly reset ISA bus during warm reboot, that can leave cards in semi-initialized state that some drivers do not expect. But it should go away with cold reboot, so if it doesn't your theory is correct and it's something in the EEPROM data being messed up by Windows driver.

I'll try it. 😀 Does that apply here though since this is a PCI card?

Edit - no difference.

Your are bumping into a common problem with device drivers ... to be on the safe side a device driver should reset the device before touching it, and should assume that nothing is correct. The DOS packet driver is probably not doing that because the poor junior-level programmer who is assigned to maintain the 20+ year old packet driver is just testing on a PC that he boots cold each time they update the code, which is about once every five years.

Warm boot vs. cold boot makes a difference for the BIOS areas. There is a reset signal on the ISA bus, but who knows what the card is actually doing with it.

You also could have a legitimately bad card. Or there is a timing problem in the packet driver code and it's not waiting long enough for the card to do something. So many people don't check return codes or verify that the hardware is in the state it is supposed to be in ...

MrD wrote on 2021-05-30, 14:00:

I'll try it. 😀 Does that apply here though since this is a PCI card?

Edit - no difference.

if the windows driver somehow messes with the eeprom of the nic, it's normal that a cold boot won't change a thing.