PDA

View Full Version : Help setting up mTcp



8008guy
December 1st, 2017, 06:10 PM
Hi,

I have an 486 system that I am trying to set up mTcp on. Iím using a NE2000 compatible ether net card. I am using the Crynwr packet driver (v 11.4.3) running from my autoexec.bat. I call it by NE2000 0x60

When it loads it shows that the software interrupt is 0x60, Interrupt number 0x9, and the I/O port is 0x300. It then gives me my MAC address.

In my mtcp.cfg file I have the packetint set to 0x60, I also have my ip address information hard coded. In the mTcp log file it shows all of the correct IP configuration information. ip,netmask,gw, and nameserver.

When I ping an a machine in my network I get ďTimeout waiting for ARP response.Ē From the mTcp ping client. I know itís a good address as I can ping the same address from any machine in my network.

Using tcpdump on another machine both running on the same Ethernet hub (NOT A SWITCH) I can see the ARP requests going out and the queried machine answers the ARP request . For some reason the mTcp stack does not appear to be receiving the ARP reply.

I know the Ethernet cable is good. I tested it physically with a cable tester. I can also see the traffic LED on the Ethernet card flashing. And outbound traffic reaches my sniffer.

Iíve also tried a different Ethernet card.

Any tips would be really appreciated. Might I have an issue with the HW int 0x9?

Cheers,

len

Caluser2000
December 1st, 2017, 09:14 PM
Run the dhcp program. It'll set the network values in tcp.cfg. This sorted a problem I was having.

Is the SET MTCPCFG = C:\mtcp\tcp.cfg set in the autoexec.bat file?

mbbrutman
December 1st, 2017, 09:37 PM
If you are able to send packets but it looks like you can not receive packets then it is almost always a problem with the selected hardware IRQ. If the hardware IRQ for the packet driver is not set correctly then incoming packets never make it to the packet driver, and then never make it to mTCP.

Please double check our hardware interrupt number and look for conflicts. On a 486 system IRQ 9 should be safe to use.

8008guy
December 2nd, 2017, 05:59 AM
If you are able to send packets but it looks like you can not receive packets then it is almost always a problem with the selected hardware IRQ. If the hardware IRQ for the packet driver is not set correctly then incoming packets never make it to the packet driver, and then never make it to mTCP.

Please double check our hardware interrupt number and look for conflicts. On a 486 system IRQ 9 should be safe to use.

That's what I was thinking, it's just been decades since I was "expert" with these systems. I thought it would be easier to get this going on a newer machine before I set it up on my 5150 or 5155... I still need to fine a suitable 8 bit ethernet card.

In any case, being dumber that I was in the 80's, how can I tell what HW interrupts are currently used by the system. I pretty much have standard HW in the system. (IDE, two serial, VGA) With a NE2000 can I force it to use a different INT?

What 8 bit ethernet cards are you guys using in your PC/XT systems? 305's?

len

8008guy
December 2nd, 2017, 07:14 AM
GOT IT!!!

Thanks to you Linus for the miracle of Linux. I pulled the ethernet card in my bench Linux system to detect the current configuration of the card. It told me that the card was set up on INT 10. With the addition of an 0xA on my dos driver init I am now cooking with gas! So much to remember.

Now I'm off to find cards for the older PC's.!

Thanks for your responses guys. It helps to kick start and old brain.

len

glitch
December 2nd, 2017, 07:45 AM
Yeah, a lot of the crynwr drivers will initialize with the wrong IRQ, and you get exactly what you've described. FWIW, Linux kernel modules will too, sometimes, especially if you let them autoprobe.

Caluser2000
December 2nd, 2017, 09:59 AM
Nice to see another mTCP user. Well done.

8008guy
December 2nd, 2017, 01:56 PM
Nice to see another mTCP user. Well done.

Thomas Byers (DRI)- "You'll have a million people using the A> [MS-DOS prompt] forever. You'll have five million using [nongraphic] menu systems such as Topview, Concurrent PC-DOS, Desq, and those types. But there'll be 50 to 100 million using the iconic-based interfaces."

It's heartwarming to have a community to help out.

As to your Thomas Byers quote... Although not the A> prompt, it you count the zillions of Linux prompts he may have way underestimated those who spend their lives at a command prompt. (As I do.)

A few weeks ago I built an 1802 membership card. I've designed a nice little interface around a Raspberry Pi 3 that interfaces to the M.C. When I was writing the software, which is ncurses based, I remembered how fast the non mouse/icon driven interfaces were. The functionality is not M$ word by any means, but for a simple tool it just works. I have always tried to tell others how inefficient it is to take your hands off the keyboard to grab the mouse, few understand.

Long live the "A>"

len

8008guy
December 14th, 2017, 05:12 PM
YEA!!! Got my 5155 connected to the Internet with mTCP! Thank you to Glitch for all the help, not to mention a second XT-IDE.

I got a matching 5.25 IBM drive off ebay to replace the screwy drive someone previously had crammed in the lower slot. I also completely dissembled the keyboard to fix the non-working ':' key, was a real problem trying to change drives, although the "alt" keypad got me though for a few tests.

Very very cool little computer.

Now back to do networking on the 5150.

Cheers all!

len

8008guy
December 16th, 2017, 06:14 PM
Another success tonight! I got the 5150 connected to the Internet with mTcp.

I used htget to download Tetris and played a game.

Just feels like magic.

len

mbbrutman
December 16th, 2017, 06:32 PM
That's the intent ... it should just work.

Enjoy,
Mike

8008guy
December 17th, 2017, 02:58 PM
That's the intent ... it should just work.

Enjoy,
Mike

And that it does, thank you!

len

dieymir
December 18th, 2017, 12:37 AM
Just for the record. I had this very same error message:

“Timeout waiting for ARP response.”

when trying to link two 386s using MTCP. Both worked with a Linux machine but not between them. After lot of tinkering, network card swapping, sniffering (yes, there was network traffic between them), ... I noticed that I have explicity configured MTU on one of them (1500 bytes) but not on the another one (576 bytes). After configuring the MTU on both sides to match, all started to work just fine. I suppose that it worked with Linux because PMTUD is implemented on its TCP/IP stack.

mbbrutman
December 18th, 2017, 07:39 AM
ARP responses are less than 200 bytes; MTU being too small should not have affected ARP in any way.

Were the two machines directly connected or was there a hub or router in between them? I have seen cases where directly connected machines can't talk because of slight incompatibilities but with a third device between them everything is fine.

dieymir
December 18th, 2017, 08:55 AM
Yes, there is a switch between them. I know that it seems odd but everything is connected to the same switch. These were the symptoms:

* Linux server to any of the vintage pcs -> worked
* Connection between vintage pcs -> did not work

everything connected to the same switch. Cards in full duplex mode (putting them in half duplex did not solve the problem). As soon as I changed the mtu to 1500 on both vintage pcs it started to work. Maybe the problem is with the switch itself. It's a D-LINK 8 ports @ 1Gbps, I do not remember the exact model and I do not have it here to check.

glitch
December 18th, 2017, 09:31 AM
I've had random problems out of cheaper gigabit switches when using them with 10baseT hardware, everything from vintage cards with AUI transceivers through modern embedded stuff like SIP or IAX ATAs. Zero problems out of "enterprise grade" stuff (Cisco, Brocade/Foundry, etc.). I think I've eliminated all of the problem consumer gear stuff.

FWIW, most of the "blue metal box" Netgear stuff seems to be OK.

8008guy
December 18th, 2017, 09:50 AM
I got rid of my netgear switch because it was putting out a LOT of EMI that I was picking up on my Radio (Ham) in the HF spectrum. The cisco switch I am now using seems to be much quieter.

glitch
December 18th, 2017, 10:20 AM
I got rid of my netgear switch because it was putting out a LOT of EMI that I was picking up on my Radio (Ham) in the HF spectrum. The cisco switch I am now using seems to be much quieter.

Yeah, my core stuff is now Cisco (2960G and 2940, soon to replace the 2960G with a 3560E), but occasionally I use a little standalone switch for test setups. Used enterprise stuff is the way to go IMO, it's cheap if you wait long enough, and it's built to a much higher standard.