ReactoOS Network Infrastructure

26 Nov 03 I have finished cleaning up the tditest.sys driver, which I am going to use as a base to test my work on UDP and TCP going forward. It now builds and runs correctly under Windows 2000 SP4 with a checked kernel, hal, ndis, tdi, and tcpip, with full driver verifier, and the only PREfast warnings are from some stupid macros in tdi.h. Next step is to see what happens to it under ReactOS.

20 Nov 03 I've begun work on the TDI side of TCP/IP. Casper has already gotten most of this working, so what I'm doing at the moment is clean-up and updating. There were a couple of slightly wrong structs that I've fixed, and at the moment I have the tditest.sys driver building with the windows DDK and loading onto a checked windows 2000 computer. Verification with ReactOS is next.

I still need people to test cards and stuff. I have two functions (marked with *'s) that I'm going to implement next, which will allow the Intel EtherExpress Pro 100 card to load. If you want your card to work, get the Windows driver for it and run depends.exe on it. See if it imports any functions from ndis.sys that are not on this list below, and mail me with the results. Thanks to Jonathon Wilson and Gerard Gatineau for help with Intel and 3Com, respectively. 1 Nov 03 Well, I've been massively distracted with header issues, Jan's Cc patch, etc, and I've hardly had any time to work on networking. I did commit a fix for the 8-ping limit, which I introduced while fixing IRQL problems surrounding the SendPackets handler. Oh well...

23 Oct 03 I have been chasing dma issues around over the last few days. My changes in my last commit broke slave DMA in the process of fixing busmaster DMA. I have committed fixes and am resuming working on the 8-ping limit.

I have heard rumors that the RTL8139 driver loads as well. The API list shows that most of the important NDIS functions for Ethernet cards have been implemented, so some day soon we'll be turning the corner, such that cards will be more likely to work than not. I can't wait. :)

Note: I still need registry information for the 3Com card, as well as any other cards that anyone might have. I am particularly interested in NDIS4 and NDIS5 drivers, and even more particularly in drivers designed for Windows 2000. Send 'em if you got 'em.

20 Oct 03 I've committed the patch to get the 3com driver (3c90x) loading - please give it a try and send feedback. I don't have one of these cards, and I suspect that something (packet indications, dma, etc) is probably broken. Also, I need registry information for this driver, similar to what's in hivesys.inf for the AMD PCNet driver. Please either send me a diff or just commit it when you get a chance. Also, please note that or own pcnet driver and ne2k driver are both disabled at the moment due to continuing development. One last thing - we still have the 8-ping limit, as the DMA patches did not solve the problem. I'll be looking into that problem next, along with bug reports for the 3Com support.

12/19/03 I've been working on the 3Com driver for a few days, and it requires new and improved DMA machinery. I've coded a few ndis support functions and tweaked ntoskrnl and the hal a bit. I should have an intermediate patch later tonight, and hopefully we'll have 3Com support in a couple of days. I decided to do the 3Com work first because I am suspicious that the packet weirdness I mentioned in my last update is related to the DMA stuff that I wound up haveing to re-code for 3Com. Also: the load order bugs I mentioned in my last update seem to be corrected now.

12/14/03 NDIS has a couple of bugs relating to work items that I really need to sort out before moving on to more interesting things. At the moment, you only get about 5 pings back and forth into ROS before it starts behaving weirdly - duplicate packets, failed responses, etc. After I get that sorted out, I think I'll try to get the 3Com NIC driver to load. I'll need someone with real hardware to test that, so please e-mail me if you are willing to try. Also: My recent patch seems to have caused some of you trouble with regard to load order. Filip Navara and I are working together to get the load order problem solved, and Filip has code on a private branch that fixes these bugs. In the meantime: if you get a system crash during boot in ndis or tcpip, please disable ndis and tcpip in the registry (set Start to 0x4 in bootdata/hivesys.inf for both ndis.sys and tcpip.sys). I'll post when this is cleared up.

10/12/03 The OEM PCNet driver (i.e. the VMWare driver) is now fully functional and is responding to ARPs and pings. I just made a really big commit with about 3 weeks of work in it, so let me know if there are any problems. I think I'm going to do some NDIS clean-up next, followed by perhaps taking a look at one or two more NIC drivers, and then it's on to TCP/IP. You can get the latest patch with VMWare support here.

9/23/03 After taking nearly a week off to work on... work... I'm back in business and am troubleshooting two current roadblocks. The first is that my own pcnet driver does not seem to get initialized correctly - every received packet causes an interrupt with receive error bits set. The second problem is that the OEM driver for the pcnet card is able to correctly receive exactly one packet, but the receive interrupt never seems to get re-enabled. I'm also currently working on that.

9/16/03 I'm finished with all of the basic functions of the reactos pcnet driver, and i'm pleased to say that it does interrupt for each packet received. Now it's on to bug-fixing. Woo hoo...

9/14/03 I've fixed a bunch of little bugs in the protocol->miniport transmission path, but for some reason, the oem driver never re-enables interrupts on the nic after the first packet is received. I think I'm going to switch back to coding on my pcnet driver for a bit until I figure this out. The good news is that DMA seems to be working in both directions, as we are able to send and receive packet(s) - the arp for the reply address is showing up on the network now.

9/12/03 Having figured out the interrupting problem, I've been spending the last few days working out the deserialized send and receive paths that the oem driver uses. So far pings are getting up to TCP/IP and the arp request for the ping reply is getting down into the miniport's SendPackets handler. Work continues.

9/9/03 In case anyone is interested, here are the specs to the pcnet chip that I'm implementing.

9/7/03 I am continuing to fight with the vmware pcnet driver. It turns out that VMWare doesn't support 32-bit programming of their emulated PCNet card, meaning that it doesn't actually fit the spec of the chip it claimes to be. C'est la vie... At this point it's interrupting sometimes but it's not interrupting on packet reception, which I think is due to incorrect programming of the chip.

9/5/03 I've just released lots of new changes over the last 24 hours. Please let me know if there are any build problems. This should be enough support to get the off-the-shelf pcnet driver working, and I'll be testing it in the next couple of days to see if I can get it to ping. Then it's back to coding on ros's pcnet driver. I have put the pcnet driver in CVS but I haven't wired it into the build system yet. You can check it out by cd'ing into reactos/drivers/net/dd/pcnet and typing 'make'. It's only about 1/2 done still and doesn't do much atm.

9/4/03 I have committed some of the outstanding patches. The API list has been updated. Once I get some minor details sorted out, I'll commit the rest of this stuff. I also still have a patch from Royce Mitchell III that I need to apply that handles some utility functions.

9/3/03 I have gotten to the bottom of the non-interrupting NIC problem. It seems that NdisMRegisterIoPortRange was (is) broken. I've begun making forward progress on the ReactOS pcnet driver. Once it's complete and functional, I'll be going back to the off-the-shelf VMWare NIC. Then I've had a request to look at a 3Com NIC driver.

9/1/03 Happy labor day. Still no interrupts from the AMD card; obviously something dumb is going on here. Updated sources for the pcnet driver are below. It still doesn't do much other than initialize the card and register an ISR, but that should be enough to make it at least interrupt. It's not.

8/31/03 I have begun implementing an AMD PCNet driver that will support the VMWare NIC, among others. I'm hoping this will help me find why the vendor-supplied binary isn't working, but also, we will need this anyway, because you can't expect people to download drivers for unsupported NICs when they can't get on the network in the first place! For the curious, the work-in-progress driver is [not here any more - in cvs].

8/29/03 I've been fighting with hardware-level stuff for days now. I think I have enough of the DMA interface implemented at this point, but for some reason the VMWare NIC isn't firing interrupts under ROS. I'm currently troubleshooting. When that problem is cleared up, and assuming the DMA stuff works (along with the rest of the ndis code paths), we should be able to ping the VMWare nic. That is the point at which I will submit my next patch for testing and commit.

ReactOS Network Infrastructure

News

Overview

Ndis.sys

Drivers

Documentation

Links