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

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>


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