In my experience mTCP DHCP client code is rather resilient and works with all kinds of DHCP servers. I'd connect another computer to the switch and run Wireshark on it to see whether the DHCP packets sent by mTCP actually appear on the wire. If you can't see them and the card has more than one cabling option, one thing to consider here is media detection. I have an SMC card which only works with media auto-detection - if I choose twisted pair, which is what I have connected, it won't send anything. No idea why it's like that.

I've messed with those options, having the card set to autodetection and having it set to RJ-45 connection. None of those options worked. I will try Wireshark though and see if I can see the packets running down the line.

You’re sure your DHCP server is working at all?

It's gotta be because things are connected to my network and when I do ipconfig /all on a modern machine my home DHCP server is listed as the one my computer is connected to.

Now that I re-read the screen capture, it says that the card is actually receiving packets. What happens if you just configure a static IP? Pick some unused address from the DHCP pool, set same netmask as on your modern machine and see if you can ping it then.

I did that and put all of that stuff in the config file and I pinged it and got nothing. I'll check the file again in the morning, it's late right now.

I've never experienced problems with mTCP itself.
All the problems I saw were caused by bad hardware, configuration, or drivers.

What packet driver you're using?
For many cards, there are two drivers: one provided by the manufacturer, and the other from Crynwr.
And you can try ODI and NDIS drivers, with appropriate shims.

Also, you should disable full-duplex - it needs either NWay (which your card is unlikely to support), or a managed switch with the port manually set to full-duplex (and I don't think your switch is managed).

long shot, but are you sure the packet driver loads successfully/correctly? can you show us a screen of it loading? I hope you're not getting FF:FF:FF... as a mac address.

Some quick comments and things to try:

• Use a static configuration for mTCP. This is done in the mTCP configuration file; the documentation has a section on it. You do not want to do this through your DHCP server because that still requires more code to work correctly. Using a static configuration in the mTCP configuration file removes all of that complexity and lets you get closer to the problem. See the PDF documentation for how to do this. If you still can't get things to work with a static network configuration then you know it's not a DHCP problem.
• Ensure you are using the right netmask and gateway settings.
• Plug into the same switch/router that your other machines are to isolate/eliminate factors such as a flaky network switch.
• Use the PKTTOOL program to see what packets you are receiving.
• If all else fails, send me a trace. Use the instructions in the PDF documentation to collect a full packet trace. mTCP is detecting that packets are being received, which is a good sign - but they could still be corrupted, and hence not recognizable. A trace will give me a lot to work with.

In general, I post my email address all over because I want people to send me bug and problem reports. Don't be shy - I'm surprised at how few people actually send me bug reports. Most problems turn out to be hardware related, but I have fixed a few bugs recently. (None affecting DHCP ...)

On a side note, the next version of mTCP gets released tomorrow. Fixes include a Telnet emulation bugs, a mostly rewritten HTGET program, and flow control fixes to the TCP library for crappy connections. That last fix will help FTP sessions that time out and don't recover.

Mike

mbbrutman wrote on 2019-12-31, 17:03:

On a side note, the next version of mTCP gets released tomorrow. Fixes include a Telnet emulation bugs, a mostly rewritten HTGET program, and flow control fixes to the TCP library for crappy connections. That last fix will help FTP sessions that time out and don't recover.

Ooh, I am interested in this. I have noticed that on certain machines FTP is inexplicably slow to do anything like a directory listing.

I've seen that too, but it's usually on the host side. Windows 7 with proftpd was particularly bad - it was always a 2 second delay just to see a directory listing or start a file transfer.

This change will probably have more impact when using FTP to a remote site on the Internet. The general problem was that when a packet is dropped it will be re-transmitted, but the spec is ambiguous about the other packets that were sent after the dropped packet but not acknowledged yet. Some implementations will resend everything from the point of the dropped packet forward, and some will assume that once the dropped packet is resent all is good. The later case was killing mTCP.

I solved it by playing with the TCP receive window; it now scales up and down as required under lossy conditions. It's a dramatic improvement and will keep those large file transfers from dying unexpectedly because of a lost packet.

I am working on mTCP again now, and I used PKTTOOL to see the incoming packets, and I got this. I also have a screen of the packet driver initalizing. When it was initializing, I had no media connected, but I fixed this later. I also hooked the computer up to an Ethernet cable not going into the switch and nothing different happened. I also have all of the static IP parameters in the config file set correctly I think. The only driver software I am running for this network card is the packet driver on the original D-Link setup disk. I had other drivers on the card before, but they didn't help my situation with mTCP as it only uses the packet driver.

That's pretty good news - you are receiving packets and PKTTOOL can figure out that they are ARP, IPv4, and IPv6 packets, so the packets are not totally borked.

I'd suggest sending me your mTCP config file and a packet trace. Use something like PING to test with. To get a packet trace:

set LOGFILE=tcplog.txt
set DEBUGGING=255

Then run PING against a few machines, including your gateway. Full instructions are in the PDF file. Send the resulting logfile and mTCP configuration file to me and I'll try to see what is broken. (Keep using the static configuration in the mTCP configuration file; we should debug PING first.)

I have that card here but I don't have it installed at the moment. I'll see if I can test it today.

I can't seem to get PING to work, it says my DHCP lease has expired, even though I have the static config set up in the config file. I'll send you an email with the config file.

There was an acceleration feature I had to disable in the diagnostics for the packet driver to work. I'll give you more details when I'm at home.

mbbrutman wrote on 2019-12-31, 19:51:

That's pretty good news - you are receiving packets and PKTTOOL can figure out that they are ARP, IPv4, and IPv6 packets, so the […]
Show full quote

That's pretty good news - you are receiving packets and PKTTOOL can figure out that they are ARP, IPv4, and IPv6 packets, so the packets are not totally borked.

I'd suggest sending me your mTCP config file and a packet trace. Use something like PING to test with. To get a packet trace:

set LOGFILE=tcplog.txt
set DEBUGGING=255

Then run PING against a few machines, including your gateway. Full instructions are in the PDF file. Send the resulting logfile and mTCP configuration file to me and I'll try to see what is broken. (Keep using the static configuration in the mTCP configuration file; we should debug PING first.)

I have that card here but I don't have it installed at the moment. I'll see if I can test it today.

I emailed you the config file.

I took a look at the configuration file and the traces. Your machine is sending ARP requests that are never being answered. Incoming packets look fine, but I'm betting that your card (or a bad cable) are preventing sent packets from getting off the machine.

This is completely consistent with DHCP ignoring you. You are not being ignored - the packets are probably not getting out.

To prove this you'll need to run wireshark, TCP dump, or something like those. I'd just swap with a different card and see if that works better. (If you can find a different, compatible packet driver that would be something to test as well.)

gdjacobs wrote on 2019-12-31, 20:10:

There was an acceleration feature I had to disable in the diagnostics for the packet driver to work. I'll give you more details when I'm at home.

When you are at home, I would like to hear about that feature, because it might be what is holding me back. Also, a little update, I swapped to an unused cable, and I get no different results

Tested the packet driver from the D-Link site. Nothing. Here's all of my configuration settings: