Error: Timeout waiting for Connect message response.

[Brian Collins]

Hi,

I have had netdrive working properly in the past, connected to a .DSK image on an rPI on my LAN, but it's been a few months, and I've switched to a new mobo and network card (Intel Pro/100+) DOS side.

I found a packet driver that seems to work, but I cannot seem to connect to a .DSK image using netdrive anymore. I have an rPI named orion and my DOS machine on my LAN.

On the Raspberry Pi side, I created a new .DSK file to test this further, using:

netdrive create hd 256 fat16b TEST.DSK

which gives:

Specified MB: 256, Filesystem: FAT16B
Bytes per sector: 512, Sectors: 524288, Data sectors: 523743, Cluster size: 8 sectors
Reserved sectors: 1, FAT copies: 2, Sectors per FAT: 256
Root directory entries: 512, Sectors for root directory: 32
TEST.DSK disk image created.

Then I serve it up, using:

netdrive serve

On the DOS side, I've loaded NETDRIVE.SYS from CONFIG.SYS, it reports that I should use drive E. I load my packet driver for my Intel Pro/100+, at 0x60, it reports everything is fine, shows the MAC address etc, and then I run DHCP, and it reports everything looks good as well.

I'm able to ping other machines on my network, even connect via netdrive to hugedisk.dsk on brutman.com, so it would _seem_ as if everything is fine. However, I am unable to connect to my local image above, using:

netdrive connect orion:2002 TEST.DSK e:

This is the output:

NetDrive deviced opened, IOCTL_read return code: 8 02C4:0020 02C4:1752

Resolving orion, press [ESC] to abort.

Server ip address is: 192.168.1.17

Next hop address: D8:3A...

Error: Timeout waiting for Connect message response.

I should mention, I get that exact same IOCTL return code when I am able to successfully connect to hugedisk.dsk on brutman.com.

The last bit of data is the server running on orion. It actually sees the connection request, and it appears normal on that side:

Server settings:                                                                                                        
Image directory: /home/bcollins/mTCP_NetDrive_2024-08-16_Servers/linux_arm

Max session length: 0 minutes, Session timeout: 0 minutes, Max active sessions: 20

Session scoped writes directory: /home/bcollins/mTCP_NetDrive_2024-08-16_Servers/linux_arm

Listening on port 2002                                                                                                
                                                                                                                       
Use the "help" command to get help                                                                                      
2025-01-19 12:17:06 New Session: 62137, Addr: 192.168.1.37:19055, Protocol: 2, Image: TEST.DSK (RW) Journal type: No Jou (output clipped)

I'm just not sure how to diagnose and troubleshoot further. This timeout occurs on both the Oct 2024 release and the new Jan 2025 release. Any ideas? Thanks,

Brian

[Michael Brutman]

The IOCTL return code is expected to be the same for a given drive letter.  Those two fields are segments and offsets.  You can ignore those.

So if I understand correctly, the current device driver works and connects to the public server, but not to a server in your house.  And your server side is seeing the connect message, but the NETDRIVE.EXE program is reporting a timeout which means it never got a response from the server.

The only difference here is that when connecting to the public server the UDP packets are going through your router (and many others), but when talking to orion everything is local.  If the DOS machine can talk to the gateway it should not have a problem with other machines on your network.

NetDrive won't respond to ping packets at all (ICMP) but it will respond to ARP packets.  So try this experiment:

1. Connect to fat12.dsk on the public server.  That sets up networking in the device driver.
2. Ping the DOS machine from orion.  You won't get a response, but the DOS machine will respond to ARP.
3. Run "arp -n" and look for an entry for your DOS machine.  You should have both the IP address and MAC address in the table.  If they are there and correct that confirms that orion has seen the DOS machine on the network.
4. Run netdrive status e: (or whatever your drive letter is) to see the number of ARP replies the DOS machine has sent.  It will be at least one because it responded to the gateway.  It should increase by 1 for every new machine that tries to ping it too.

You mention this happens with the Oct 2024 and Jan 2025 releases.  What about the August code?  While the server code has changed since August, it was mostly clean-up and better error handling.  The protocol between the server and the client hasn't changed since Aug 2024 so the current device driver should work against an August 2024 server, but you should test both the August device driver and server to be sure.

-Mike

[Brian Collins]

Interesting, thanks for the tips. I figured there was some local setup error, since it works on the remote disk image, and now I think I see what it is.

In doing the steps below, I noticed I had two network interfaces, and completely forgot that, in addition to the wired interface, it's still using the default WiFi one.

When I disable the WiFi, and set everything up to only use the wired interface, all works as expected.

When running netdrive on orion, it was able to receive the request from DOS, but I'm guessing it was replying on the WiFi interface, which is why DOS never received it, since DOS is only the wired network. Anyway that's my current thinking.

I'd still like to understand exactly what's going on here, but it's clearly not an mTCP problem, so I'll investigate further on my own. Anyway, sorry for the bother!

Brian

[Michael Brutman]

Interesting ..  I keep forgetting that RaspPis have two possible interfaces.  And yes, that's the problem.  I recreated it here, and it might be something I can fix in the server.

I recreated it on my RaspPi and the DOS machine sends the request as expected, but the reply comes back with the IP address of the other interface which causes the timeout.  If you pick the correct IP address/interface up front you never notice a problem.

I did not have the server explicitly bind to a specific interface; I wouldn't know which one to use.  And in general even on a machine with two interfaces it is not a problem because they are on two different subnets and the routing takes care of this.  This is only an issue when one machine has two interfaces on the same subnet.

-Mike

[Brian Collins]

I'm glad you were able to replicate, yeah it totally makes sense that the server wouldn't know which interface to bind to.

I ended up using the pi as a gateway and yeah making a dedicated subnet for this stuff, so my 4-port "retro PC" network switch has my 4 old machines plus the pi, and the pi handles forwarding, and DHCP as well, via dnsmasq.

Everything's working again, thanks for your help!