<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Subject: Re[2]: CIPE-Win32, device driver for WIN98
From: Dmitry Basko <dbasko,AT,rainbow,DOT,by>
Date: Wed, 18 Jun 2003 18:02:31 +0300
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <200306131112.28356.dwilson@ibl.bm>
Organization: Rainbow Technologies
References: <7322473687.20030613164836@rainbow.by><200306131112.28356.dwilson@ibl.bm>
Reply-to: Dmitry Basko <dbasko,AT,rainbow,DOT,by>

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>

-- 
Best regards,
Dmitry Basko                            dbasko,AT,rainbow,DOT,by


<< | Thread Index | >> ]    [ << | Date Index | >> ]