| To: | Dmitry Basko <dbasko,AT,rainbow,DOT,by> |
| Subject: | Re: Re[2]: CIPE-Win32, device driver for WIN98 |
| From: | Damion Wilson <dwilson,AT,ibl,DOT,bm> |
| Date: | Wed, 18 Jun 2003 12:07:00 -0300 |
| Cc: | cipe-l,AT,inka,DOT,de |
| In-reply-to: | <41116981062.20030618180231@rainbow.by> |
| References: | <7322473687.20030613164836@rainbow.by> <200306131112.28356.dwilson@ibl.bm> <41116981062.20030618180231@rainbow.by> |
Good work ! Is the same binary driver still able to load on NT ? The service stuff in cipsrvr will first have to be yanked out, be cause Win9x doesn't support it. I think that you'll have to play around with the entropy stuff, too, which is used for key generation. DKW On Wednesday 18 June 2003 12:02 pm, Dmitry Basko wrote: > Hello Damion, > I'd like to inform you and other concerned members of our community > about current state of porting CIPE driver on WIN98. With several > changes in the inf file, source code (at the present moment were done > only the most necessary ones) of the driver I was able to install CIPE > drv on WIN98. OS recognizes it, the virtual NIC looks like any other > NIC to the system (as viewed in the Network Control Panel), IP address > is set up. For testing purposes I wrote a small console application (idea > was taken from CipeTapIO module), it reads (asynchronously) packets from > drv cyclically. In case, if there is ARP request (ping 192.168.200.3 -n 1), > it receives next MAC from the driver (CIPE_IOCTL_GET_LASTMAC) and forms ARP > reply, using this MAC and MAC of virtual adapter (received with > CIPE_IOCTL_GET_MAC). So, when later I check ARP table (arp -a) I see a new > record, like "192.168.200.3 08:00:58:00:00:02".. Therefore I think the > first step is done. Driver reads and writes packets > successfully. The next step will be implementation of fake ping reply. As I > understand, Damion, it will prove the conceptual workability CIPE drv > on WIN98 in current implementation.(although it seems fake ARP reply > already proved it). I should admit, at present moment it does not work > stable - > sometimes OS hangs (WIN98 is running inside of virtual machine,in > different time intervals, like 5 minutes, 7 minutes and so on), having > IRP_MJ_READ pending. But ok, this is another story, lets go step by > step. > May I hope when the driver is ready someone will have a look at user space > living software (aka service on WIN2K)? Sure, I can do it myself, but > because of the lack of free time any help would be very appreciated. > > <It would be even better if we could make the one binary driver > <do both architectures, but my initial feeling was that it would have to be > <a separate build. > My current feeling is that this is possible (different branches of > code can be selected depending on result of IoIsWdmVersionAvailable in > case of one binary, or with different definitions, for example > CreateTapDevice :: for WIN98 USERDEVICEDIR \\??\\, for WINK2 USERDEVICEDIR > \\DosDevices\\) at least at the level of the source code. What I see now, > NDIS calls for WIN98 are functions, NDIS calls for WIN2K and higher are > macroses. More clear it will be a little bit later. > > PS: Damion, from time to time I feel a necessity to ask you about > driver implementation's details. Should I direct these questions to > the mailing list (I am not sure that majority is interesting in > this)or is any way to address them right you? (your mail box is not > reachable). > > DW> Right on just about everything. > DW> I knew when I wrote the driver that it "should" be portable to Win9x. > It just DW> wasn't high enough on the list of priorities to get going on > it. Then DW> Microsoft finally made it clear that the NT kernel was the way > forward... > > DW> There is probably more porting work in the service, especially as there > are DW> suspected timing issues with packet handling in usermode (polling > behaviour) DW> on Win9x. > > DW> The NDIS miniport part is reasonably straightforward, however the > driver DW> supports two device types at the same time, the other being the > TAP device. DW> This behaviour is NOT WDM kosher. > > DW> If you do the port, please preserve the interface to the FIFO device. > DW> DKW > > DW> On Friday 13 June 2003 10:48 am, Dmitry Basko wrote: > >> Hello, > >> I am currently thinking about possibility to change CIPE-WIN32 driver > >> model as a first step of porting the driver on WIN98. At present this > >> driver is NT layered one (as I understand), I am interesting in > >> possibility to convert it to WDM (VXD excluded from the beginning).. > >> According Microsoft's specification about difference of NDIS miniport > >> implementations for WIn98 and WIN2 I see that current > >> driver does not use any incompatible functions. The common idea how it > >> works is very clear also. But I have several questions and would like > >> to hear opinion of other members of this mailing list.. > >> 1. In case of WDM who will be a PDO for our FDO? I mean, what PDO's > >> pointer I will get in AddDevice? I made a small investigation (WIN2K) > >> about behaivior of the current implementation of CIPE. The driver > >> creates two device objects: one is created by NDIS, second one is > >> created in the function > >> CreateTapDevice . The NDIS owned device object is attached to PDO, > >> created PnP manager during enumeration of "root" bus (I would say that > >> it looks like WDM !?!?, although at the beginning of the letter I > >> intentionally called it NT layered model). It manages 28 IRP types > >> (full range of IRP_MJ_XXX) and has next attributes: DO_DIRECT_IO, > >> DO_POWER_PAGABLE. (Note, that second device object does not have this > >> attribute, does not attached any PDO and has only DO_DIRECT_IO is > >> present. This means, that Power Manager calls the driver at IRQL > >> DISPATCH_LEVEL)(I understand this situation in the following way: we > >> hooked DISPATCH TABLE of NDIS owned DO, so does it mean that every > >> time when PowerManager calls NDIS owned DO, it calls IRP at IRQL > >> PASSIVE_LEVEL, and every time when it calls second DO it calls it at > >> IRQL DISPATCH_LEVEL?). In this case this place must be corrected > >> during porting - WDM for WIN98 has always to be called by Power > >> Manager at IRQL PASSIVE_LEVEL. > >> 2. Our virtual adapter is not a real physical device on the bus, which > >> can be enumerated by real bus driver. It seems inf file has to be > >> changed in order to declare that our device is a "software" enumerated > >> adapter, and than PnP manager should enumerate our driver itself > >> through its pseudo "root" bus driver (not clear, will it be enough > >> that we declare that our driver belongs NET class?)So, this part has > >> to be checked additionally. > >> > >> DDK98 says: To create and test an NDIS miniport driver, refer to the > >> Windows╝ 2000 DDK documentation. A miniport driver created in this > >> manner is binary compatible and will run on both the Windows 2000 and > >> Windows╝ 98 operating systems. Also, I have read that WIN98 supports > >> NDIS5. > >> > >> May be someone has any additional points about porting the driver on > >> WIN98? Any suggestions, comments are very appreciated. > > DW> -- > DW> Message sent by the cipe-l,AT,inka,DOT,de mailing list. > DW> Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body > DW> Other commands available with "help" in body to the same address. > DW> CIPE info and list archive: > <URL:http://sites.inka.de/~bigred/devel/cipe.html>