SvarDOS community forum

Hey! I have a machine with SvarDOS on it and and 3Com 3C509 ISA NIC. I got the packet driver (crynwr) loaded in my autoexec.bat, and upon boot I get a message displaying my MAC address. I was under the impression that for pkgnet to work I just needed to load the correct packet driver for my NIC, but when I issue a "pkgnet search", for example, it just says:

> Configuring through DHCP.. failed

Could I get some help debugging? Cheers!

Hi, it looks like your PC cannot obtain a DHCP lease. Either the packet driver you used is not compatible with your NIC, or your LAN has no DHCP service, or your NIC is misconfigured, or you have some kind of cabling issue. I suppose you checked already your cabling and made sure your DHCP service responds correctly. 3COM NICs originally came with a proprietary driver and a configuration tool (3C5x9CFG) that was able to set various settings of the NIC, like the expected carrier speed, half/full duplex mode, preferred connector, etc. As a first step I'd recommend getting the 3COM driver disks for your card, playing with the NIC configuration tool and try the official 3COM driver. A quick google search suggests you might find the necessary tools here: http://www.win3x.org/win3board/viewtopic.php?t=281 Mateusz

Hey Mateusz, thanks for this info! So first off I can confirm that my card works. I've been having trouble with 32bit operating systems on my machine, but I was able to get a 16bit Linux system called ELKS installed. I was able to spin up an http server and copy a file from my PC to another system, do dns resolution, etc. I'm a bit hesitatnt to try 3C5x9CFG as I've read elsewhere that it's a bit buggy and has even bricked some cards. My big question is whether a packet driver should be all I need. I used the one for 3c509 that I found here: http://crynwr.com/drivers/00index.html. Unpacked it, put it in autoexec.bat, set its interrupt to 0x60, booted, and the driver reported a valid MAC address (not 00 or FF repeating). I had previously tried FreeDOS with some MS management utility, and there etherdfs worked but dhcp didn't. At that point I got annoyed at FreeDOS being overly complex and decided that SvarDOS might be simpler to work with. If it comes to it I might try the configuration tool, but I was hoping there were some other utilities/tests I could perform to debug what's going on with the stack. As previously mentioned the packet driver gets a MAC address, and pkgnet complains about dhcp but doesn't complain about the packet driver. So would this be enough evidence to suggest that pkgnet sees the required network stack but the device isn't doing anything? My goal is also to understand the network stack a little better too, hence trying to clarify if it pkgnet should "just work" if there is a functioning packet driver.

I do not know about any specific issues with 3C5x9CFG, I used it a lot of times with my 3C509 cards and never had any issues. The fact that pkgnet does not complain about the packet driver does not mean that the packet driver actually works, it just means that pkgnet is able to detect the packet driver interface. However, if you say that etherdfs works for you, then the packet driver + NIC combo is confirmed to work, which is good news, and likely no 3C5x9CFG actions are needed. For the sake of the experiment you might still want to try the official packet driver from 3COM, but again if etherdfs works, then the packet driver works and your cabling is fine. The question is why you are unable to get a DHCP lease. I assume you do have a DHCP server in your LAN (probably embedded in your internet router). To eliminate the DHCP issue you could try setting a static address via wattcp.cfg. The idea is simply to create a short wattcp file with such content: my_ip = 192.168.0.5 netmask = 255.255.255.0 nameserver = 8.8.8.8 gateway = 192.168.0.1 Of course you have to substitute the values accordingly to your LAN configuration. Then, you need to set an WATCFG.CFG environment variable that would point to the directory that contains your WATTCP.CFG file, for example if your WATTCP.CFG is in the root directory of your C: drive, then the env variable would be this: SET WATTCP.CFG=C:\ It is possible that your system already has such environment variable, as well as a sample WATTCP.CFG file - you can check it with the "SET" command (or look into your autoexec.bat). About the general working of the network stack: PKGNET comes with a TCP/IP stack, provided by the WATT32 library embedded into the PKGNET.EXE binary. To figure what IP configuration to use, it looks for the WATTCP.CFG env variable and tries to read the WATTCP.CFG file it points to. Once the WATT32 library knows its IP configuration, it relies on the packet driver to send and receive Ethernet frames. In other words, you should not need anything more than PKGNET and a packet driver, assuming that your NIC and physical network work fine. Note that you may also try the PING command (which also relies on WATT32) to see if it behaves any differently. It is not part of the core SvarDOS installation, so you need to install the PING.SVP package first. You can download the PING v2.2 package here: http://svardos.org/?p=repo Mateusz

Thank you for this! Getting closer :) With wattcp.cfg I get DNS resolution failed. When I try ping, I get

> Load error: no DPMI - Get csdpmi*b.zip

I tried the cswdpmi and got a segfault. I'm trying to figure out hxdpmi but there are a LOT of options. It looks like DPMI has to do with memory management - is there perhaps just some setting I'm missing in config.sys? Or any other guidance you can provide about setting up a DPMI provider?

Also to clarify - ping no longer compliains about a lack of DPMI but that is what segfaults. cwsdpmi seems to start up fine with `cwsdpmi.exe -p` in my autoexc. Also tried with JEMMEX and I get the same symptom

It is weird that ping segfaults for you. Is your computer a 386 by any chance? I recall dealing with a Watt32 bug years ago, that made it crash on pre-486 computers. Perhaps the ping application is still linked with this 386-buggy version of the library. It's also sad that ping is a 32-bit application, one day I should definitely recompile it to 16-bit, but that's another matter. This also makes me remember that I really should address the #63 issue at some point. :/ https://github.com/SvarDOS/bugz/issues/63 Anyway - pkgnet no longer fails on DHCP for you, but on DNS resolution. This is not good news, because it does not mean that it works somehow better - it simply fails on the next step that requires actually receiving a packet. Watt32 is basically doing this: 1. load wattcp.cfg configuration 2. acquire a DHCP lease (if DHCP is enabled) 3. resolve the IP address of the target FQDN (DNS query) 4. connect (TCP handshake) Before, it was failing on step 2. Since you configured a static IP address this step is being skipped and it fails on step 3 now. But root cause is likely the same: for some reason your PC (NIC / packet driver / whatever) fails to communicate with the external world. One question: do you confirm 100% that EtherDFS works for you in your current setup, with your current cabling and packet driver? Because it all points out that your PC is unable to either send or receive Ethernet frames, but if so then EtherDFS also should not be able to work. Mateusz

Today I made an ARP-probing tool, that I named ARPCHK. It's here: http://mateusz.fr/arpchk/ (also available in SvarDOS packages) ARPCHK is able to send an ARP query to a specified host (in the same LAN it is in) and displays the result. It needs only a packet driver, nothing else. It's a relatively simple tool, took me only a couple of hours to create. It works perfectly in my DOSEMU setup, but I did not test it in real hardware. Hopes are high that it should help debugging basic connectivity issues - with it you will know whether or not your DOS host is able to communicate with its default gateway (ie. your home router), without any doubts about DHCP, DNS, or what not. Mateusz

Ok, so for etherdfs I'm seeing the same thing. From what I read when I tested etherdfs last, basically if you dont' have an etherdfs server as long as it reports no server found your packet driver is probably working. I took it a step further this time and tried to set up an etherdfs server on my Linux machine. On my SvarDOS machine it failed auto-discovery but monted a driver when I provided my Linux machine's MAC. However, when I tried to list the files in my mounted etherdfs drive it said "File not found". arpcheck gave the following output: ``` C:\>arpchk/arpchk.exe 192.168.1.200 192.168.1.1 packet driver found at int 0x60 my MAC is 00:A0:24:EC:73:84 checking for IP collision... sending ARP broadcast: WHO-HAS 192.168.1.1...? TIMEOUT: NO REPLY RECEIVED ``` I wanted to be a bit more thorough here and test a different driver. I believe this is an official 3com NDIS driver from Microsoft, as well as a DIS to packet driver interface: https://karellen.blogspot.com/2012/04/basic-networking-with-freedos.html I was able to get all of those files installed and I get all the right messages on boot. arpchk gives me the exact same output as with the crynwr packet driver, including the same MAC. pkgnet gives me the exact same message about DNS resolution failing. I can start looking at the official 3com driver next. As I mentioned previously, it seems strange that DOS is unhappy with the NIC (with two different drivers even) whereas ELKS Linux works perfectly fine with it. Let me know what to try next, and thank you so much for diving deep with me on this!

Good. So: - ARPCHK fails because it does not receive any ARP answer from your router - pkgnet fails because it does not receive any DNS answer (which it does not even sends, because surely it fails earlier at the ARP-resolution stage, but simply reports it as a DNS issue) - etherdfs fails because it cannot communicate with your Linux server We can conclusively say that your NIC is either mute or deaf. I have no experience with NDIS drivers and the necessary packet driver shim. My own 509 NICs all work with the official 3COM packet driver. I really think you should try it, esp. since I do not see what else you could try. I have provided a link earlier. Since your hardware and wiring work correctly with Linux, it is obviously a software issue. Maybe Linux reconfigures the 509 NIC correctly before using it, while the packet driver does not (because it expects the NIC to be preconfigured with 3C5X9CFG.EXE). Have you checked if your NIC has a carrier? I assume it is connected to an ethernet switch - most switches have LEDs that show the status for each of their port (possibly with multiple colors, like for example OFF=no carrier YELLOW=100Mbps GREEN=1Gbps). IIRC the 3C509 NIC itself also has a carrier/status diode, but it might be hard to see since it is located at the rear of the computer. In the event that you have no carrier negotiated, you'd have to fiddle with the 3C5X9CFG tool to try switching the card into different modes (10 Mbps / 100 Mbps / Full Duplex / Half Duplex / Transceiver type), until you see a carrier appearing (illuminated LED on your Ethernet switch). If, however, you do have a carrier, then the issue might be a software conflict, like the I/O address or IRQ of your 3COM card colliding with some other ISA card. It is not a problem for a plug-and-play-aware OS like Linux, because modern OSes take care to reconfigure all plug-and-play cards at boot time as to avoid collisions. DOS does no such thing and expects that your system is already properly set. Both the I/O and IRQ of the 509 card can be configured manually with the 3C5X9CFG utility. Long story short: use the official 3COM packet driver + 3C5X9CFG tool, observe the carrier LED on your NIC and/or switch, and see what happens. :-) Mateusz

Welp, I have great news! I don't know what the 3COM installer did, but when I did the install not only did the official driver work but I got the crynwr packet driver to work perfectly! pkgnet now works and arpchk succeeds! Thank you so much for all of your help Mateusz, I learned a lot through all of this and I'm glad that we have all of this in writing for the next person who gets stuck configuring their 3COM card :) Have a happy new year

The installer probably didn't do much, it is more likely that the proprietary driver initialized the card "the right way", so it works with everything now. Good to know. Happy new year, and happy DOS networking ;-) Mateusz