mTCP updates coming soon: Send me your bug reports

[mbbrutman]

I don't have a recommendation on a good memory tester. There are a few old ones that run in DOS but I don't think they are particularly effective. When things are really bad I break out the DRAM testing device which can test 64K and 256K DRAMs; it works pretty well, but it doesn't work for my later systems with use SIMMs. If the system is new enough memtest86 is a good alternative.

I doubt that your IRQ configuration has an impact on the checksum errors, other than the general observation that RealTek engineers were not taking much pride in their work. ;-0

I uploaded the updated FTP.EXE file to http://www.brutman.com/mTCP/ftp.exe . It just makes it easier to see the number of checksum errors by printing out a line of statistics at the end of a program. I've tested it as best I can, but since I'm not getting any checksum errors it is always 0.

The paper you linked was a good read. Not detecting a checksum error every 1 in 16 million packets can seem like a lot of data, but even my short sessions transferring I was receiving on the order of 100,000 packets and generating an equal amount. For a real machine like an ISP gateway 16 million packets goes by pretty quick. The paper is 20 years old now so the scale of the problem might be different; hardware might be more reliable but we send many more packets now.

[Eudimorphodon]

Most of the RAM in my machine is actually SRAM instead of DRAM. I'd be more enthused about blaming RAM if the machine were acting flakey in other ways, though. As noted, I've been exercising it pretty hard and it's been working great since I swapped out the evil CF card.

(The reason I was running Checkit's RAM test over and over again was I've actually experienced massive hard disk corruption before that traced to bad RAM, which primed me to suspect that before the disk. Apple Power Macs are the %^$&ing worst when it comes to being picky about RAM... but it's hit me on a PC as well.)

I do doubt the IRQ config per se is an issue, the only hail Mary in my mind would be that maybe there's some issue with that hacked generic NE2000 driver that the Realtek-supplied driver won't have. The RTL8019AS is "ne2000 compatible", but phrases like "xxx compatible" often have asterisks behind them.

[maxtherabbit]

Recursive mget is not going to happen any time soon - for reasonably sized directory hierarchies it can work but if somebody goes bananas there is a deeply nested tree of files memory becomes an issue very fast, and dealing with out of memory situations gracefully is a pain. My work-around is to use zip files, and yes, I know this doesn't work unless you have room for the zip file already.

Preserving timestamps should be doable. That's just an optional capability I can add.

maxtherabbit: What does the output from the packet driver loading look like after the soft reset? Nothing mTCP does can survive a reboot, but there might be some crappy state left in the card that is not being flushed out. You might want to try a different version of the packet driver. (Also, send me a trace of when it fails.)

just wanted to say that switching from the crynwr packet driver to the 3com one fixed the warm boot issue!

[fjk61011]

Hi,

Some editors (such as EDIT) make it very easy to leave whitespace around. Whitespace shouldn't matter, so a warning might be more annoying than helpful.

Yes, I used EDIT to change sample.cfg and I get two white space warnings.

[Chuck(G)]

Over the weekend, I decided to give mTCP a go on an old XT clone that I have.

I installed an Artisoft AE-3 in the system (DMA 2, port 0x320) and used the NE2000 packet driver from this site.

Even without running anything other than the packet driver, the machine hangs when the first packet comes in (within a few seconds of initializing the driver).

Obviously, there's a problem with the driver; does anyone have any suggestions? This is a fully-populated machine, so the options for changing IRQ or port addresses are somewhat limited.

FWIW, the same setup works fine using MSLANMAN, so it isn't the hardware.

[Eudimorphodon]

I installed an Artisoft AE-3 in the system (DMA 2, port 0x320) and used the NE2000 packet driver from this site.

I assume by DMA you mean IRQ.

Have you tried the NE2000 driver from this thread instead? It works with an 8019AS on IRQ2 in my Tandy 1000.

[maxtherabbit]

Is there a crynwyr or however you spell it packet driver for NE2000?

[Eudimorphodon]

Is there a crynwyr or however you spell it packet driver for NE2000?

The one linked in that thread is a version of the crywyr ne2000 driver with patches to work in 8-bit slots.

[Chuck(G)]

Yes, IRQ, not DMA. I'll give the linked one a go and report back.

[ibmapc]

Over the weekend, I decided to give mTCP a go on an old XT clone that I have.

I installed an Artisoft AE-3 in the system (DMA 2, port 0x320) and used the NE2000 packet driver from this site.

Even without running anything other than the packet driver, the machine hangs when the first packet comes in (within a few seconds of initializing the driver).

Obviously, there's a problem with the driver; does anyone have any suggestions? This is a fully-populated machine, so the options for changing IRQ or port addresses are somewhat limited.

FWIW, the same setup works fine using MSLANMAN, so it isn't the hardware.

Have you tried a V20 in that machine? I had a similar issue with my Intel EitherExprees card. The Crynwr driver would hang the machine as Mtcp was starting. When I switched to a V20, problem went away. Then later, I found a modified version of the packet driver that worked with the 8088.