Hello,

I have a Microsoft digitally signed NDIS IM driver that installs from
a location on the HDD ( suppose C:\Program Files\Kit\ ). The driver
installs ok with no popups.
Then the driver is removed.
If the kit is moved to a different place on the HDD and the driver is
reinstalled from that location, a popup appears asking the user to
locate the driver on the HDD, expecting the driver binary file to be
in the previous location ( such as C:\Program Files\Kit\ ). If you
press "browse", the implicit path in the file dialog starts in the new
location, however.
This happens on Vista, and the driver has it's own binary ( exe file )
that installs the driver.
My problem is: how can I get rid of the file dialog box?

Thanks.
Cristi.

Hi everyone,
I've written a simple intermediate driver for basic packet filtering.
It seems it's working well, but now i want to add another
functionality. I can already modify the content of a packet and send
it to the lower miniport adapter, what i want to add is the
possibility to re-route the packet through the kernel routing table.
For example i might modify the destination IP Address, such that, in
order to reach its destination, the packet must be routed through a
different interface. Is there a way to perform this task within my
intermediate driver? Should i write an upper-level driver?
Thank you,
                 Federico Menarini

We are writing an app for Vista that needs to connect to wireless
networks that
supports 802.1X authentication but no encryption.
The EAP Host framework that we use for PEAP, etc. (in conjuction
with the Auto configuration API) does not support this (requires
encryption)

I have the following questions:
1>Can I implement this using a native 802.11 IHV extension dll ? The
IHV
extension installation documentation on MSDN suggests modifying the
INF for
the WLAN adapter. We don't have our own WLAN adapter. Do we need an
adapter
to work with an IHV ?

2>Or, Do we need to use some sort of a protocol driver(like rawether
for Vista) in this case if we
want to use our supplicant software to handle the EAP handshake
packets at
the authentication stage and handover the rest of the process to MS
Autoconfiguration service ?

3> What other alternatives might be able to accomplish the goal of
using
WLAN auto config to connect to a network that uses 802.1x for
authentication
and no encryption?

Will highly appreciate any info on this.

It's a little dangerous to have drivers in program files, isn't it?
What if that drive isn't available early enough during boot? I've
never tried what you suggest, but if you simply drop the file in the
standard drivers directory (see Passthru's inf), you shouldn't have
this problem.

On May 2, 2007, at 4:45 AM, Cristi wrote:

> Hello,
>
> I have a Microsoft digitally signed NDIS IM driver that installs from
> a location on the HDD ( suppose C:\Program Files\Kit\ ). The driver
> installs ok with no popups.
> Then the driver is removed.
> If the kit is moved to a different place on the HDD and the driver is
> reinstalled from that location, a popup appears asking the user to
> locate the driver on the HDD, expecting the driver binary file to be
> in the previous location ( such as C:\Program Files\Kit\ ). If you
> press "browse", the implicit path in the file dialog starts in the new
> location, however.
> This happens on Vista, and the driver has it's own binary ( exe file )
> that installs the driver.
> My problem is: how can I get rid of the file dialog box?
>
> Thanks.
> Cristi.
>
>
>
> ----------------------
>
> Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
>
> Yahoo! Groups Links
>
>
>

Turn on IP routing (there's a usermode IPHLPAPI call for it IIRC) and
just indicate the packet up. The host will route it automatically.

   -sd

On May 2, 2007, at 6:22 AM, dgtfm84 wrote:

> Hi everyone,
> I've written a simple intermediate driver for basic packet filtering.
> It seems it's working well, but now i want to add another
> functionality. I can already modify the content of a packet and send
> it to the lower miniport adapter, what i want to add is the
> possibility to re-route the packet through the kernel routing table.
> For example i might modify the destination IP Address, such that, in
> order to reach its destination, the packet must be routed through a
> different interface. Is there a way to perform this task within my
> intermediate driver? Should i write an upper-level driver?
> Thank you,
>                 Federico Menarini
>
>
>
> ----------------------
>
> Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
>
> Yahoo! Groups Links
>
>
>

----- Original Message -----

From: Cristi

To: discussion-pcausa@yahoogroups.com

Sent: Wednesday, May 02, 2007 2:45 AM

Subject: [discussion-pcausa] NDIS im driver first installation location in vista

Hello,

I have a Microsoft digitally signed NDIS IM driver that installs from
a location on the HDD ( suppose C:\Program Files\Kit\ ). The driver
installs ok with no popups.
Then the driver is removed.
If the kit is moved to a different place on the HDD and the driver is
reinstalled from that location, a popup appears asking the user to
locate the driver on the HDD, expecting the driver binary file to be
in the previous location ( such as C:\Program Files\Kit\ ). If you
press "browse", the implicit path in the file dialog starts in the new
location, however.
This happens on Vista, and the driver has it's own binary ( exe file )
that installs the driver.
My problem is: how can I get rid of the file dialog box?

Thanks.
Cristi.

Do you remove the INF files of the IM driver upon uninstallation (using SetupOEMUninstallInf())?
 
Have a nice day
GV
 
 

----- Original Message -----

From: Cristi

To: discussion-pcausa@yahoogroups.com

Sent: Wednesday, May 02, 2007 2:45 AM

Subject: [discussion-pcausa] NDIS im driver first installation location in vista

Hello,

I have a Microsoft digitally signed NDIS IM driver that installs from

a location on the HDD ( suppose C:\Program Files\Kit\ ). The driver

installs ok with no popups.

Then the driver is removed.

If the kit is moved to a different place on the HDD and the driver is

reinstalled from that location, a popup appears asking the user to

locate the driver on the HDD, expecting the driver binary file to be

in the previous location ( such as C:\Program Files\Kit\ ). If you

press "browse", the implicit path in the file dialog starts in the new

location, however.

This happens on Vista, and the driver has it's own binary ( exe file )

that installs the driver.

My problem is: how can I get rid of the file dialog box?

Thanks.

Cristi.

We have a security product and after instalation we want to mark
certain executable files as trusted. First by checking the digital
signature and if this is verified we store the MD5 signature. How can
be verified the digital signature?
Thanks,

Sorin

--- In discussion-pcausa@yahoogroups.com, Steve Dispensa
<dispensa@...> wrote:
>
> I don't know how offhand. I'd almost certainly try to do it from user
> mode, though. Just out of curiosity, what are you trying to do?
>
> On Apr 27, 2007, at 1:41 AM, Sorin Vinturis wrote:
>
> > But how can I determine that form code. Is there a function that I
> > could use?
> >
> > --
> > Sorin
> >
> >
> > ----- Original Message ----
> > From: Steve Dispensa <dispensa@...>
> > To: discussion-pcausa@yahoogroups.com
> > Sent: Thursday, April 26, 2007 6:22:14 PM
> > Subject: Re: [discussion-pcausa] Microsoft digital signature
> >
> > Right-click it and click properties. There will be a digital
> > signatures tab.
> >
> >
> > On Apr 26, 2007, at 9:47 AM, Sorin Vinturis wrote:
> >
> >> Hello everybody!
> >>
> >> Does anyone know how can one determine if a file is digitally
> >> signed by Microsoft?
> >> Thanks!
> >>
> >> --
> >> Sorin
> >>
> >>
> >> Ahhh...imagining that irresistible "new car" smell?
> >> Check out new cars at Yahoo! Autos.
> >
> >
> >
> > Ahhh...imagining that irresistible "new car" smell?
> > Check out new cars at Yahoo! Autos.
>

hi guys,

thanks for the suggestions: I use SetupCopyOEMInf once for the
protocol and once for the miniport inf. I do not use
SetupUninstallOEMInf to uninstall, I just call the INetCfgComponent,
INetCfgClassSetup and INetCfgClass methods to uninstall ( very much
inspired from snetcfg sample from microsoft WDK )

--- In discussion-pcausa@yahoogroups.com, "Gianluca Varenni"
<gianluca.varenni@...> wrote:
>
> Do you remove the INF files of the IM driver upon uninstallation
(using SetupOEMUninstallInf())?
>
> Have a nice day
> GV
>
>
>   ----- Original Message -----
>   From: Cristi
>   To: discussion-pcausa@yahoogroups.com
>   Sent: Wednesday, May 02, 2007 2:45 AM
>   Subject: [discussion-pcausa] NDIS im driver first installation
location in vista
>
>
>   Hello,
>
>   I have a Microsoft digitally signed NDIS IM driver that installs from
>   a location on the HDD ( suppose C:\Program Files\Kit\ ). The driver
>   installs ok with no popups.
>   Then the driver is removed.
>   If the kit is moved to a different place on the HDD and the driver is
>   reinstalled from that location, a popup appears asking the user to
>   locate the driver on the HDD, expecting the driver binary file to be
>   in the previous location ( such as C:\Program Files\Kit\ ). If you
>   press "browse", the implicit path in the file dialog starts in the new
>   location, however.
>   This happens on Vista, and the driver has it's own binary ( exe file )
>   that installs the driver.
>   My problem is: how can I get rid of the file dialog box?
>
>   Thanks.
>   Cristi.
>

----- Original Message -----

From: Cristi

To: discussion-pcausa@yahoogroups.com

Sent: Thursday, May 03, 2007 12:48 AM

Subject: [discussion-pcausa] Re: NDIS im driver first installation location in vista

hi guys,

thanks for the suggestions: I use SetupCopyOEMInf once for the
protocol and once for the miniport inf. I do not use
SetupUninstallOEMInf to uninstall, I just call the INetCfgComponent,
INetCfgClassSetup and INetCfgClass methods to uninstall ( very much
inspired from snetcfg sample from microsoft WDK )

--- In discussion-pcausa@yahoogroups.com, "Gianluca Varenni"
<gianluca.varenni@...> wrote:
>
> Do you remove the INF files of the IM driver upon uninstallation
(using SetupOEMUninstallInf())?
>
> Have a nice day
> GV
>
>
> ----- Original Message -----
> From: Cristi
> To: discussion-pcausa@yahoogroups.com
> Sent: Wednesday, May 02, 2007 2:45 AM
> Subject: [discussion-pcausa] NDIS im driver first installation
location in vista
>
>
> Hello,
>
> I have a Microsoft digitally signed NDIS IM driver that installs from
> a location on the HDD ( suppose C:\Program Files\Kit\ ). The driver
> installs ok with no popups.
> Then the driver is removed.
> If the kit is moved to a different place on the HDD and the driver is
> reinstalled from that location, a popup appears asking the user to
> locate the driver on the HDD, expecting the driver binary file to be
> in the previous location ( such as C:\Program Files\Kit\ ). If you
> press "browse", the implicit path in the file dialog starts in the new
> location, however.
> This happens on Vista, and the driver has it's own binary ( exe file )
> that installs the driver.
> My problem is: how can I get rid of the file dialog box?
>
> Thanks.
> Cristi.
>

--- In discussion-pcausa@yahoogroups.com, Steve Dispensa
<dispensa@...> wrote:
>
> Turn on IP routing (there's a usermode IPHLPAPI call for it IIRC) and
> just indicate the packet up. The host will route it automatically.
>
>   -sd
>
>

Great, I was missing the IPHLPAPI call (if anyone is interested, it's
named "EnableRouter")! Now I have another problem... avoiding loops. I
need a way to "mark" the packet i reroute, so that i will not reroute
again when i'll receive it. I've tried to use the ProtocolReserved and
MiniportReserved fields without any luck, every packet I receive has
such fields zeroed. Is there a way to mark a packet? Thank you again!

Can you give me an example of what kind of routing loop you're
talking about here? What kind of packet transformation are you doing?
If you have an IM driver, you could always reversibly change the
source address before you give it to Windows, and when you see it
come back down, change it back. As long as you precisely un-do your
changes, you shouldn't break much.

Still, the whole idea sounds like a bit of a hack. Can't you trust
your rewriting rules and your host's routing table to not get into a
loop? IP has a TTL for this reason; that will handle loops for you
quite nicely.

   -sd

On May 3, 2007, at 1:14 PM, dgtfm84 wrote:

> --- In discussion-pcausa@yahoogroups.com, Steve Dispensa
> <dispensa@...> wrote:
>>
>> Turn on IP routing (there's a usermode IPHLPAPI call for it IIRC) and
>> just indicate the packet up. The host will route it automatically.
>>
>>   -sd
>>
>>
>
> Great, I was missing the IPHLPAPI call (if anyone is interested, it's
> named "EnableRouter")! Now I have another problem... avoiding loops. I
> need a way to "mark" the packet i reroute, so that i will not reroute
> again when i'll receive it. I've tried to use the ProtocolReserved and
> MiniportReserved fields without any luck, every packet I receive has
> such fields zeroed. Is there a way to mark a packet? Thank you again!
>
>
>
> ----------------------
>
> Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
>
> Yahoo! Groups Links
>
>
>

Off the top of my head, I'd look at CryptoAPI. I have never done
this, so there may be a shortcut, but basically it's a matter of
figuring out exactly how PE files are signed, fishing out the
signature, re-computing the hash, etc. Surely there's a way to do
this automatically, but like I said, I've never really looked. Maybe
someone else can chime in.

   -sd

On May 3, 2007, at 6:58 AM, svinturis wrote:

> We have a security product and after instalation we want to mark
> certain executable files as trusted. First by checking the digital
> signature and if this is verified we store the MD5 signature. How can
> be verified the digital signature?
> Thanks,
>
> Sorin
>
> --- In discussion-pcausa@yahoogroups.com, Steve Dispensa
> <dispensa@...> wrote:
>>
>> I don't know how offhand. I'd almost certainly try to do it from user
>> mode, though. Just out of curiosity, what are you trying to do?
>>
>> On Apr 27, 2007, at 1:41 AM, Sorin Vinturis wrote:
>>
>>> But how can I determine that form code. Is there a function that I
>>> could use?
>>>
>>> --
>>> Sorin
>>>
>>>
>>> ----- Original Message ----
>>> From: Steve Dispensa <dispensa@...>
>>> To: discussion-pcausa@yahoogroups.com
>>> Sent: Thursday, April 26, 2007 6:22:14 PM
>>> Subject: Re: [discussion-pcausa] Microsoft digital signature
>>>
>>> Right-click it and click properties. There will be a digital
>>> signatures tab.
>>>
>>>
>>> On Apr 26, 2007, at 9:47 AM, Sorin Vinturis wrote:
>>>
>>>> Hello everybody!
>>>>
>>>> Does anyone know how can one determine if a file is digitally
>>>> signed by Microsoft?
>>>> Thanks!
>>>>
>>>> --
>>>> Sorin
>>>>
>>>>
>>>> Ahhh...imagining that irresistible "new car" smell?
>>>> Check out new cars at Yahoo! Autos.
>>>
>>>
>>>
>>> Ahhh...imagining that irresistible "new car" smell?
>>> Check out new cars at Yahoo! Autos.
>>
>
>
>
>
> ----------------------
>
> Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
>
> Yahoo! Groups Links
>
>
>

My IM driver actually passes the whole packet to a userspace
application. The application can modify, drop or accept the packet,
thus the driver has no control over the modifications. The problem
here is that when i pass the packet up, i receive it back and send it
to the application again, creating an infinite loop. I have thought of
using the GetBestInterface function from the userspace application,
and passing the id of the interface to be used to the driver, so the
out interface is known and i don't need to reroute it. But this should
bring a lot of overhead... Surely there is a better solution (and less
hackish than the one you mentioned, which should work anyway).

--- In discussion-pcausa@yahoogroups.com, Steve Dispensa
<dispensa@...> wrote:
>
> Can you give me an example of what kind of routing loop you're
> talking about here? What kind of packet transformation are you doing?
> If you have an IM driver, you could always reversibly change the
> source address before you give it to Windows, and when you see it
> come back down, change it back. As long as you precisely un-do your
> changes, you shouldn't break much.
>
> Still, the whole idea sounds like a bit of a hack. Can't you trust
> your rewriting rules and your host's routing table to not get into a
> loop? IP has a TTL for this reason; that will handle loops for you
> quite nicely.
>
>   -sd

To answer this my old brain needs to know where the packet originated
(received from wire or an intercepted send?) and so forth.

Thomas F. Divine


> -----Original Message-----
> From: discussion-pcausa@yahoogroups.com [mailto:discussion-
> pcausa@yahoogroups.com] On Behalf Of dgtfm84
> Sent: Friday, May 04, 2007 2:01 PM
> To: discussion-pcausa@yahoogroups.com
> Subject: [discussion-pcausa] Re: Re-routing a packet
>
> My IM driver actually passes the whole packet to a userspace
> application. The application can modify, drop or accept the packet,
> thus the driver has no control over the modifications. The problem
> here is that when i pass the packet up, i receive it back and send it
> to the application again, creating an infinite loop. I have thought of
> using the GetBestInterface function from the userspace application,
> and passing the id of the interface to be used to the driver, so the
> out interface is known and i don't need to reroute it. But this should
> bring a lot of overhead... Surely there is a better solution (and less
> hackish than the one you mentioned, which should work anyway).
>
> --- In discussion-pcausa@yahoogroups.com, Steve Dispensa
> <dispensa@...> wrote:
> >
> > Can you give me an example of what kind of routing loop you're
> > talking about here? What kind of packet transformation are you doing?
> > If you have an IM driver, you could always reversibly change the
> > source address before you give it to Windows, and when you see it
> > come back down, change it back. As long as you precisely un-do your
> > changes, you shouldn't break much.
> >
> > Still, the whole idea sounds like a bit of a hack. Can't you trust
> > your rewriting rules and your host's routing table to not get into a
> > loop? IP has a TTL for this reason; that will handle loops for you
> > quite nicely.
> >
> >   -sd
>
>
>
> ----------------------
>
> Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
>
> Yahoo! Groups Links
>
>
>

Sure... Right now i'm working on intercepted sends. Then i will move
to packets received from wire, but it think it will be easier.
What i basically do now is:
1) A userspace applications sends a packet.
2) My driver intercepts it and passes it to a second userspace
application.
3) This application modifies the packet and sends it back to the IM
driver.
4) The driver passes the packet down to the miniport the packet was
originally intended to be forwarded.

My problem now is that the application number 2 might have changed the
destination IP address, so i should pass the packet to another interface.
I hope i have cleared things up a bit...

--- In discussion-pcausa@yahoogroups.com, "Thomas F. Divine"
<tdivine@...> wrote:
>
> To answer this my old brain needs to know where the packet originated
> (received from wire or an intercepted send?) and so forth.
>
> Thomas F. Divine
>
>
> > -----Original Message-----
> > From: discussion-pcausa@yahoogroups.com [mailto:discussion-
> > pcausa@yahoogroups.com] On Behalf Of dgtfm84
> > Sent: Friday, May 04, 2007 2:01 PM
> > To: discussion-pcausa@yahoogroups.com
> > Subject: [discussion-pcausa] Re: Re-routing a packet
> >
> > My IM driver actually passes the whole packet to a userspace
> > application. The application can modify, drop or accept the packet,
> > thus the driver has no control over the modifications. The problem
> > here is that when i pass the packet up, i receive it back and send it
> > to the application again, creating an infinite loop. I have thought of
> > using the GetBestInterface function from the userspace application,
> > and passing the id of the interface to be used to the driver, so the
> > out interface is known and i don't need to reroute it. But this should
> > bring a lot of overhead... Surely there is a better solution (and less
> > hackish than the one you mentioned, which should work anyway).
> >
> > --- In discussion-pcausa@yahoogroups.com, Steve Dispensa
> > <dispensa@> wrote:
> > >
> > > Can you give me an example of what kind of routing loop you're
> > > talking about here? What kind of packet transformation are you
doing?
> > > If you have an IM driver, you could always reversibly change the
> > > source address before you give it to Windows, and when you see it
> > > come back down, change it back. As long as you precisely un-do your
> > > changes, you shouldn't break much.
> > >
> > > Still, the whole idea sounds like a bit of a hack. Can't you trust
> > > your rewriting rules and your host's routing table to not get into a
> > > loop? IP has a TTL for this reason; that will handle loops for you
> > > quite nicely.
> > >
> > >   -sd
> >
> >
> >
> > ----------------------
> >
> > Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
> >
> > Yahoo! Groups Links
> >
> >
> >
>

I think you can make some improvements.

Drivers like the PCAUSA "Packet Redirector" have two handles for each
binding.

One handle is on the lower "protocol-edge" of the binding; writes on the
protocol handle go on the wire and reads on the protocol handle fetch
packets from the wire. The second handle is on the upper "miniport-edge" of
the binding; writes on the miniport handle inject packets "up-the-stack"
where they appear to higher levels as if they were received from the
network; reads on the miniport handle intercept packets as they are being
sent from higher levels to the real miniport.

This is illustrates at the URL:

http://pcausa.com/pcasim/packetredir.htm

If multiple NICs are present, then the user-mode application has a pair of
handles for each miniport binding.

Having done this the application now has complete flexibility on where to
intercept or inject packets. If the packet was intercepted and mangled on
one binding it can inject the mangled packet on a different binding in any
direction.

The application would, of course, have to know which interface to use. That
information needs to be kept somewhere and keeping it in user-space would
seem to be simplify the driver logic.

Here I use the term "reads" and "writes" loosely. These could easily be
IOCTL calls.

Hope this helps.

Thomas F. Divine


> -----Original Message-----
> From: discussion-pcausa@yahoogroups.com [mailto:discussion-
> pcausa@yahoogroups.com] On Behalf Of dgtfm84
> Sent: Friday, May 04, 2007 6:07 PM
> To: discussion-pcausa@yahoogroups.com
> Subject: [discussion-pcausa] Re: Re-routing a packet
>
> Sure... Right now i'm working on intercepted sends. Then i will move
> to packets received from wire, but it think it will be easier.
> What i basically do now is:
> 1) A userspace applications sends a packet.
> 2) My driver intercepts it and passes it to a second userspace
> application.
> 3) This application modifies the packet and sends it back to the IM
> driver.
> 4) The driver passes the packet down to the miniport the packet was
> originally intended to be forwarded.
>
> My problem now is that the application number 2 might have changed the
> destination IP address, so i should pass the packet to another
> interface.
> I hope i have cleared things up a bit...
>
> --- In discussion-pcausa@yahoogroups.com, "Thomas F. Divine"
> <tdivine@...> wrote:
> >
> > To answer this my old brain needs to know where the packet originated
> > (received from wire or an intercepted send?) and so forth.
> >
> > Thomas F. Divine
> >
> >
> > > -----Original Message-----
> > > From: discussion-pcausa@yahoogroups.com [mailto:discussion-
> > > pcausa@yahoogroups.com] On Behalf Of dgtfm84
> > > Sent: Friday, May 04, 2007 2:01 PM
> > > To: discussion-pcausa@yahoogroups.com
> > > Subject: [discussion-pcausa] Re: Re-routing a packet
> > >
> > > My IM driver actually passes the whole packet to a userspace
> > > application. The application can modify, drop or accept the packet,
> > > thus the driver has no control over the modifications. The problem
> > > here is that when i pass the packet up, i receive it back and send
> it
> > > to the application again, creating an infinite loop. I have thought
> of
> > > using the GetBestInterface function from the userspace application,
> > > and passing the id of the interface to be used to the driver, so
> the
> > > out interface is known and i don't need to reroute it. But this
> should
> > > bring a lot of overhead... Surely there is a better solution (and
> less
> > > hackish than the one you mentioned, which should work anyway).
> > >
> > > --- In discussion-pcausa@yahoogroups.com, Steve Dispensa
> > > <dispensa@> wrote:
> > > >
> > > > Can you give me an example of what kind of routing loop you're
> > > > talking about here? What kind of packet transformation are you
> doing?
> > > > If you have an IM driver, you could always reversibly change the
> > > > source address before you give it to Windows, and when you see it
> > > > come back down, change it back. As long as you precisely un-do
> your
> > > > changes, you shouldn't break much.
> > > >
> > > > Still, the whole idea sounds like a bit of a hack. Can't you
> trust
> > > > your rewriting rules and your host's routing table to not get
> into a
> > > > loop? IP has a TTL for this reason; that will handle loops for
> you
> > > > quite nicely.
> > > >
> > > >   -sd
> > >

Hi all, I'm approaching in the development of windows drivers and I'm
trying to modify the passthru driver provided in the Windows Driver
Development Kit.

In particular I have some problems in memory allocation. I have to
memorize into the passthru driver packets received from driver
Tcpip.sys before sending them through the NIC.  Once I have memorized
the bytes of the packets I can send them, but I have also to operate
into the allocated zone of memory modifying its content.

I don't know if I can use the function malloc() to allocate a zone of
memory into the driver because I try to use it but when I build the
driver I have the error unresoved external symbol _imp_malloc
It is possible to create a pointer to an array of pointers to memorize
the packets before sending it? If yes, can I use the function malloc()
to allocate memory?

I read also that the routine ExAllocatePool() is used to allocate pool
memory in windows drivers. Can I use it to memorize a large quantity
of bytes before sending  it  through  the NIC? If yes, what is  the
type of pool memory I have to allocate, non paged or paged? I read
that the system can only allocate buffers larger than PAGE_SIZE from
nonpaged pool in multiples of PAGE_SIZE but I don't understand what is
the value of PAGE_SIZE.

Is there anyone that can help me?

Thank you,

Chiara

First you are talking a lot of memory here depending on the NIC.  Think
carefully about the design, do you really need to hold the complete packet?
If so for how long?

There is no malloc in the kernel, instead there are a number of allocation
routines the most common is ExAllocatePool.   Now when you say a large
amount of memory how much?  The kernel address space can be limited to 1GB
and there is a lot of things that have to fit in that space.

ExAllocatePool can allocate any size piece of memory (within the limits of
available memory and address space) there is no restriction on allocating
PAGE_SIZE or greater.  PAGE_SIZE is the size of one page in the memory
management hardware, for x86 that is 4096 bytes.  You probably were reading
if you want things aligned on a PAGE (for DMA purposes) you have to
allocate more that a PAGE_SIZE.

I would strongly recomend you take a class on driver development.  If you
cannot, get the "Windows Internals" book by Russinovich and Solomon and
read it throughly, then read Walter Oney's "Programming the Windows Driver
Model, Second Edition", before trying to go forward with any windows driver
development.

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

----- Original Message -----
From: "c_togni" <tchiara81@...>
To: <discussion-pcausa@yahoogroups.com>
Sent: Saturday, May 05, 2007 7:14 AM
Subject: [discussion-pcausa] Memory allocation in windows driver


Hi all, I'm approaching in the development of windows drivers and I'm
trying to modify the passthru driver provided in the Windows Driver
Development Kit.

In particular I have some problems in memory allocation. I have to
memorize into the passthru driver packets received from driver
Tcpip.sys before sending them through the NIC.  Once I have memorized
the bytes of the packets I can send them, but I have also to operate
into the allocated zone of memory modifying its content.

I don't know if I can use the function malloc() to allocate a zone of
memory into the driver because I try to use it but when I build the
driver I have the error unresoved external symbol _imp_malloc
It is possible to create a pointer to an array of pointers to memorize
the packets before sending it? If yes, can I use the function malloc()
to allocate memory?

I read also that the routine ExAllocatePool() is used to allocate pool
memory in windows drivers. Can I use it to memorize a large quantity
of bytes before sending  it  through  the NIC? If yes, what is  the
type of pool memory I have to allocate, non paged or paged? I read
that the system can only allocate buffers larger than PAGE_SIZE from
nonpaged pool in multiples of PAGE_SIZE but I don't understand what is
the value of PAGE_SIZE.

Is there anyone that can help me?

Thank you,

Chiara




__________ NOD32 2242 (20070505) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

I have to hold the complete packet until I have memorized its content
in an allocated zone of memory. I can send it as soos as I have
memorized it.
I have to allocate a space of about 255 kBytes.
I think I could use the routine ExAllocatePool() with the options
NonPagedPool. Is it correct?

Thanks,

Chiara


--- In discussion-pcausa@yahoogroups.com, "Don Burn" <burn@...> wrote:
>
> First you are talking a lot of memory here depending on the NIC.  Think
> carefully about the design, do you really need to hold the complete
packet?
> If so for how long?
>
> There is no malloc in the kernel, instead there are a number of
allocation
> routines the most common is ExAllocatePool.   Now when you say a large
> amount of memory how much?  The kernel address space can be limited
to 1GB
> and there is a lot of things that have to fit in that space.
>
> ExAllocatePool can allocate any size piece of memory (within the
limits of
> available memory and address space) there is no restriction on
allocating
> PAGE_SIZE or greater.  PAGE_SIZE is the size of one page in the memory
> management hardware, for x86 that is 4096 bytes.  You probably were
reading
> if you want things aligned on a PAGE (for DMA purposes) you have to
> allocate more that a PAGE_SIZE.
>
> I would strongly recomend you take a class on driver development.
If you
> cannot, get the "Windows Internals" book by Russinovich and Solomon and
> read it throughly, then read Walter Oney's "Programming the Windows
Driver
> Model, Second Edition", before trying to go forward with any windows
driver
> development.
>
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> ----- Original Message -----
> From: "c_togni" <tchiara81@...>
> To: <discussion-pcausa@yahoogroups.com>
> Sent: Saturday, May 05, 2007 7:14 AM
> Subject: [discussion-pcausa] Memory allocation in windows driver
>
>
> Hi all, I'm approaching in the development of windows drivers and I'm
> trying to modify the passthru driver provided in the Windows Driver
> Development Kit.
>
> In particular I have some problems in memory allocation. I have to
> memorize into the passthru driver packets received from driver
> Tcpip.sys before sending them through the NIC.  Once I have memorized
> the bytes of the packets I can send them, but I have also to operate
> into the allocated zone of memory modifying its content.
>
> I don't know if I can use the function malloc() to allocate a zone of
> memory into the driver because I try to use it but when I build the
> driver I have the error unresoved external symbol _imp_malloc
> It is possible to create a pointer to an array of pointers to memorize
> the packets before sending it? If yes, can I use the function malloc()
> to allocate memory?
>
> I read also that the routine ExAllocatePool() is used to allocate pool
> memory in windows drivers. Can I use it to memorize a large quantity
> of bytes before sending  it  through  the NIC? If yes, what is  the
> type of pool memory I have to allocate, non paged or paged? I read
> that the system can only allocate buffers larger than PAGE_SIZE from
> nonpaged pool in multiples of PAGE_SIZE but I don't understand what is
> the value of PAGE_SIZE.
>
> Is there anyone that can help me?
>
> Thank you,
>
> Chiara
>
>
>
>
> __________ NOD32 2242 (20070505) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>

You need to study NDIS memory functions more carefully. NDIS has a variety
of memory allocation routines that can be used instead of the Ex routines.
Although the NDIS routines are sometimes just a wrapper around the Ex
routines it is best to use the NDIS routines in a NDIS driver whenever
possible.

There are several issues here.

What are you going to do with the memorized packet content? Do you want to
log it to disk? Do you want to pass the information to a companion user-mode
application? How many "memorized packets" do you need to keep at any time?

All of these factors will make a difference in what routines you will want
to use.

Thomas F. Divine


> -----Original Message-----
> From: discussion-pcausa@yahoogroups.com [mailto:discussion-
> pcausa@yahoogroups.com] On Behalf Of c_togni
> Sent: Monday, May 07, 2007 8:17 AM
> To: discussion-pcausa@yahoogroups.com
> Subject: [discussion-pcausa] Re: Memory allocation in windows driver
>
>
> I have to hold the complete packet until I have memorized its content
> in an allocated zone of memory. I can send it as soos as I have
> memorized it.
> I have to allocate a space of about 255 kBytes.
> I think I could use the routine ExAllocatePool() with the options
> NonPagedPool. Is it correct?
>
> Thanks,
>
> Chiara
>
>
> --- In discussion-pcausa@yahoogroups.com, "Don Burn" <burn@...> wrote:
> >
> > First you are talking a lot of memory here depending on the NIC.
> Think
> > carefully about the design, do you really need to hold the complete
> packet?
> > If so for how long?
> >
> > There is no malloc in the kernel, instead there are a number of
> allocation
> > routines the most common is ExAllocatePool.   Now when you say a
> large
> > amount of memory how much?  The kernel address space can be limited
> to 1GB
> > and there is a lot of things that have to fit in that space.
> >
> > ExAllocatePool can allocate any size piece of memory (within the
> limits of
> > available memory and address space) there is no restriction on
> allocating
> > PAGE_SIZE or greater.  PAGE_SIZE is the size of one page in the
> memory
> > management hardware, for x86 that is 4096 bytes.  You probably were
> reading
> > if you want things aligned on a PAGE (for DMA purposes) you have to
> > allocate more that a PAGE_SIZE.
> >
> > I would strongly recomend you take a class on driver development.
> If you
> > cannot, get the "Windows Internals" book by Russinovich and Solomon
> and
> > read it throughly, then read Walter Oney's "Programming the Windows
> Driver
> > Model, Second Edition", before trying to go forward with any windows
> driver
> > development.
> >
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> > Remove StopSpam to reply
> >
> > ----- Original Message -----
> > From: "c_togni" <tchiara81@...>
> > To: <discussion-pcausa@yahoogroups.com>
> > Sent: Saturday, May 05, 2007 7:14 AM
> > Subject: [discussion-pcausa] Memory allocation in windows driver
> >
> >
> > Hi all, I'm approaching in the development of windows drivers and I'm
> > trying to modify the passthru driver provided in the Windows Driver
> > Development Kit.
> >
> > In particular I have some problems in memory allocation. I have to
> > memorize into the passthru driver packets received from driver
> > Tcpip.sys before sending them through the NIC.  Once I have memorized
> > the bytes of the packets I can send them, but I have also to operate
> > into the allocated zone of memory modifying its content.
> >
> > I don't know if I can use the function malloc() to allocate a zone of
> > memory into the driver because I try to use it but when I build the
> > driver I have the error unresoved external symbol _imp_malloc
> > It is possible to create a pointer to an array of pointers to
> memorize
> > the packets before sending it? If yes, can I use the function
> malloc()
> > to allocate memory?
> >
> > I read also that the routine ExAllocatePool() is used to allocate
> pool
> > memory in windows drivers. Can I use it to memorize a large quantity
> > of bytes before sending  it  through  the NIC? If yes, what is  the
> > type of pool memory I have to allocate, non paged or paged? I read
> > that the system can only allocate buffers larger than PAGE_SIZE from
> > nonpaged pool in multiples of PAGE_SIZE but I don't understand what
> is
> > the value of PAGE_SIZE.
> >
> > Is there anyone that can help me?
> >
> > Thank you,
> >
> > Chiara
> >
> >

1. On the target system, create a directory for the driver files. If your device installation application installs an application, the driver files should be stored in a subdirectory of the application directory.
2. Copy all files in the driver package from the distribution media to the directory created in Step 1. The driver package includes the driver or drivers, the INF file, the catalog file, and so forth.
3. Call SetupCopyOEMInf (described in Platform SDK documentation), specifying the INF file in the directory created in Step 1. Specify SPOST_PATH for the OEMSourceMediaType parameter and specify NULL for the OEMSourceMediaLocation parameter. SetupCopyOEMInf copies the INF file for the driver package into the %windir%\Inf directory on the target system and directs SetupAPI to store the source location of the INF file in its list of preprocessed INF files. SetupCopyOEMInf also processes the catalog file, so the PnP manager will install the driver the next time it recognizes a device listed in the INF file.

Is your driver properly signed? You should sign both the .cat and the .sys file. PnP won't auto-install an unsigned driver if the device class has a WHQL program, which yours obviously does.

 -sd

On May 16, 2007, at 4:04 AM, Richard Zhang wrote:

Dear all,
        I have one question about Preinstalling Driver Files, I need to install driver file before plugging in (USB) hardware on Windows XP.  From the DDK document, it has the following description (quote from DDK): 

To preinstall driver files, your device installation application should follow these steps:

1. On the target system, create a directory for the driver files. If your device installation application installs an application, the driver files should be stored in a subdirectory of the application directory.
2. Copy all files in the driver package from the distribution media to the directory created in Step 1. The driver package includes the driver or drivers, the INF file, the catalog file, and so forth.
3. Call SetupCopyOEMInf (described in Platform SDK documentation), specifying the INF file in the directory created in Step 1. Specify SPOST_PATH for the OEMSourceMediaType parameter and specify NULL for the OEMSourceMediaLocation parameter. SetupCopyOEMInf copies the INF file for the driver package into the %windir%\Inf directory on the target system and directs SetupAPI to store the source location of the INF file in its list of preprocessed INF files. SetupCopyOEMInf also processes the catalog file, so the PnP manager will install the driver the next time it recognizes a device listed in the INF file.

When the user plugs in the device, the PnP manager recognizes the device, finds the INF file copied by SetupCopyOEMInf, and installs the drivers copied in Step 2. (For more information about copying INF files, see Copying INFs.)

At this moment, i checked the inf file in the direcotry %windir%\Inf, there was a new inf file named oemxx.inf which was matched with the driver's.

After doing the above steps, and plug in the USB hardware device, then the system pops "find new hardware device" window and let the user select the driver directory to install this driver.

Why doesn't the PnP manager recognizes the device?

Any comments will be apprecaited!

Richard

---

抢注雅虎免费邮箱-3.5G容量！附件！

Folks,
Is there a place in the system (Windows Server 2003) to see why TCPIP
stack is dropping certain data pkts? I confirmed this with netstat
statistics. Basically, I have a kernel mode NDIS driver where I
intercept pkts and send it to my user mode app (which does some stuff)
and sends it back via the driver to local TCPIP stack. This behaviour
only happens for certain data pkts and it happens in bursts.

I am looking to see if there any log files or something which tell us
why the stack is dropping pkts (e.g because of checksum errors,
fragmentation errors, no resources, etc.)

Any info on this is appreciated.
Thanks,
Sanjay

Hi,

When result of OID_GEN_PHYSICAL_MEDIUM is 9(Native802.11),
How do I request searching network and authenticating with rawether-
driver? (Vista OS)

Do RawetherV6.0 product have Ndis6 native functions?

When do you release the new version(rawetherV6.0)?
(Would it be possible to give me an availability date?)

Thank you.

No logs that I know of. Can you give us an idea of the data rates
involved? And of the CPU load on the box? Also, how's nonpaged pool
looking? Maybe there's a leak in your IM driver or something?

   -sd


On May 18, 2007, at 11:30 AM, sanjayc.rm wrote:

> Folks,
> Is there a place in the system (Windows Server 2003) to see why TCPIP
> stack is dropping certain data pkts? I confirmed this with netstat
> statistics. Basically, I have a kernel mode NDIS driver where I
> intercept pkts and send it to my user mode app (which does some stuff)
> and sends it back via the driver to local TCPIP stack. This behaviour
> only happens for certain data pkts and it happens in bursts.
>
> I am looking to see if there any log files or something which tell us
> why the stack is dropping pkts (e.g because of checksum errors,
> fragmentation errors, no resources, etc.)
>
> Any info on this is appreciated.
> Thanks,
> Sanjay
>
>
>
> ----------------------
>
> Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
>
> Yahoo! Groups Links
>
>
>

Unfortunately, there are two problems:

1.) Rawether is based on using NDIS protocol drivers.
2.) The Microsoft Vista architecture prohibits NDIS protocol drivers from
performing the operations that you want to do.

This is because on Vista Microsoft has inserted a NDIS filter between NDIS
protocols and the actual Native 802.11 miniports. Their Native Wi-Fi filter
does not allow any NDIS protocol driver to perform the important functions
that you are trying to do.

So, even when Rawether V6.0 with complete NDIS 6 support is released it will
do no more than the current Rawether release with respect to Native 802.11.

You can try using the new Vista Native Wi-Fi API from Microsoft to perform
the work. Perhaps it is sufficient.

Other solutions that may be available in the future involve inserting
filters below the Microsoft Native Wi-Fi roadblock. A prototype of such a
driver is called "PCAGizmo" and can be examined at the URL:

http://pcausa.com/Utilities/PCAGizmo/PCAGizmo.htm

Thomas F. Divine


> -----Original Message-----
> From: discussion-pcausa@yahoogroups.com [mailto:discussion-
> pcausa@yahoogroups.com] On Behalf Of chandlershin
> Sent: Monday, May 21, 2007 10:06 PM
> To: discussion-pcausa@yahoogroups.com
> Subject: [discussion-pcausa] When do you release the rawetherV6.0?
>
> Hi,
>
> When result of OID_GEN_PHYSICAL_MEDIUM is 9(Native802.11),
> How do I request searching network and authenticating with rawether-
> driver? (Vista OS)
>
> Do RawetherV6.0 product have Ndis6 native functions?
>
> When do you release the new version(rawetherV6.0)?
> (Would it be possible to give me an availability date?)
>
> Thank you.
>
>
>
> ----------------------
>
> Copyright (c) 1999-2006 Printing Communications Assoc., Inc. (PCAUSA)
>
> Yahoo! Groups Links
>
>
>