«

I have a problem and I don´t know who can help me.
I have a process that call two threads(ThreadFirst and ThreadSecond).
Each thread makes query to some OIDs of my wireless card (NDIS
5.1).ThreadFirst and ThreadSecond run OK. After that I call to another
thread:ThreadThird. ThreadThird uses IOCTL_NDISPROT_INDICATE_STATUS.

The problem is the following:
If I set a trigger, for example to -25dBm and the query to
OID_802_11_RSSI returns -45dBm, ThreadFirst and ThreadSecond work ok.

If I set a trigger, for example to -75dBm and the query to
OID_802_11_RSSI returns -45dBm also,then ThreadThird works ok but
ThreadFirst and ThreadSecond stop.

The questions are:
How does IOCTL_NDISPROT_INDICATE_STATUS work?
Is IOCTL_NDISPROT_INDICATE_STATUS blocking?

Please, it´s very important and urgent

> How does IOCTL_NDISPROT_INDICATE_STATUS work?

Well, why don't you check the NDISPROT source code in the DDK?

> Is IOCTL_NDISPROT_INDICATE_STATUS blocking?

The IRP keeps pending until it either gets canceled or the network card
driver (NDIS miniport) actually indicates some status.

Are you saying your threads that simply query some OIDs "stop"?

Stephan
---
noe wrote:
> I have a problem and I don´t know who can help me.
> I have a process that call two threads(ThreadFirst and ThreadSecond).
> Each thread makes query to some OIDs of my wireless card (NDIS
> 5.1).ThreadFirst and ThreadSecond run OK. After that I call to another
> thread:ThreadThird. ThreadThird uses IOCTL_NDISPROT_INDICATE_STATUS.
>
> The problem is the following:
> If I set a trigger, for example to -25dBm and the query to
> OID_802_11_RSSI returns -45dBm, ThreadFirst and ThreadSecond work ok.
>
> If I set a trigger, for example to -75dBm and the query to
> OID_802_11_RSSI returns -45dBm also,then ThreadThird works ok but
> ThreadFirst and ThreadSecond stop.
>
> The questions are:
> How does IOCTL_NDISPROT_INDICATE_STATUS work?
> Is IOCTL_NDISPROT_INDICATE_STATUS blocking?
>
> Please, it´s very important and urgent

Check the NDISPROT source code in the DDK?
Where? In files.h??


Stephan, I´m developing an application and I want to do
query/set/indication operations from user mode to some OIDs of my
wireless card (NDIS5.1). My threads are always query some OIDs (for
example OID_802_11_RSSI) and they run ok, but when I call
IOCTL_NDISPROT_INDICATE_STATUS the threads stop if RSSI>the value that
I set in the OID_802_11_RSSI_TRIGGER and then my application is hung or
blocked .Then, Can´t I do indication operation in the same application
where I do query operation?Do you understand me? I hope yes.


Stephan Wolf [MVP] ha escrito:

> > How does IOCTL_NDISPROT_INDICATE_STATUS work?
>
> Well, why don't you check the NDISPROT source code in the DDK?
>
> > Is IOCTL_NDISPROT_INDICATE_STATUS blocking?
>
> The IRP keeps pending until it either gets canceled or the network card
> driver (NDIS miniport) actually indicates some status.
>
> Are you saying your threads that simply query some OIDs "stop"?
>
> Stephan
> ---
> noe wrote:
> > I have a problem and I don´t know who can help me.
> > I have a process that call two threads(ThreadFirst and ThreadSecond).
> > Each thread makes query to some OIDs of my wireless card (NDIS
> > 5.1).ThreadFirst and ThreadSecond run OK. After that I call to another
> > thread:ThreadThird. ThreadThird uses IOCTL_NDISPROT_INDICATE_STATUS.
> >
> > The problem is the following:
> > If I set a trigger, for example to -25dBm and the query to
> > OID_802_11_RSSI returns -45dBm, ThreadFirst and ThreadSecond work ok.
> >
> > If I set a trigger, for example to -75dBm and the query to
> > OID_802_11_RSSI returns -45dBm also,then ThreadThird works ok but
> > ThreadFirst and ThreadSecond stop.
> >
> > The questions are:
> > How does IOCTL_NDISPROT_INDICATE_STATUS work?
> > Is IOCTL_NDISPROT_INDICATE_STATUS blocking?
> >
> > Please, it´s very important and urgent

noe wrote:
> Check the NDISPROT source code in the DDK?
> Where? In files.h??

=> "...\src\network\ndis\ndisprot\"

Order the latest DDK here for only the cost of shipping:

http://www.microsoft.com/ddk

Stephan

I have looked at "...\src\network\ndis\ndisprot\" lots times but I
don´t find a how IOCTL_NDISPROT_INDICATE_STATUS works.

I have the last DDK: Windows Server 2003 SP1 DDK.
Please, can you answer the las question?:
.....Can I do query/set/indication operations in the same
application......?

Stephan Wolf [MVP] ha escrito:

> noe wrote:
> > Check the NDISPROT source code in the DDK?
> > Where? In files.h??
>
> => "...\src\network\ndis\ndisprot\"
>
> Order the latest DDK here for only the cost of shipping:
>
> http://www.microsoft.com/ddk
>
> Stephan

noe wrote:
> ....Can I do query/set/indication operations in the same
> application......?

Since you AFAIK can have multiple outstanding IRPs, the answer should
be yes, you can.

Tom, Max, Eliyas, others: Right?

Stephan

I don't think it is possible. Wireless cards are under 100% control of WZC
service, and your code will be meddling into its affairs. So, no reliable ways
of doing this.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

"Stephan Wolf [MVP]" <> wrote in message
news: ups.com...
> noe wrote:
>> ....Can I do query/set/indication operations in the same
>> application......?
>
> Since you AFAIK can have multiple outstanding IRPs, the answer should
> be yes, you can.
>
> Tom, Max, Eliyas, others: Right?
>
> Stephan
>
I would avoid calling the NDISPROT query and set routines concurrently from
different threads.

Within the driver both query and set go to one blocking routine that has
only one (1) resource available to pass the request to a lower-level driver.
(i.e., there is only one NDIS_REQUEST structure used for all user-mode
requests). The user's requests are never queued. Instead they block until
the request is complete. I don't see code in the driver that actually checks
to see if there is one request already in progress if a second request was
made from a second thread before the first finished.

If fact, it does look to me that the second request (from a second thread)
could overwrite parameters saved by the driver related to the first request.
If so (and it looks that way), then in some cases making the second request
before the first completed would clobber the first (and amlost certainly the
second as well).

Simply put: NDISPROT was intended to be used by a simple application (WZC)
that made one query or set at a time.

Now the Status operation is different. The status change IRP will be queued
until status changes. So, the user-mode caller will be blocked until status
changes. No status change - then blocked forever.

The OP should examine the NDISPROT code. It is fairly easy to follorw.

Good luck,

Thomas F. Divine

It should work. My guess is that your app has not opened the device for
overlapped I/O. Read this tip for more info:
http://www.microsoft.com/whdc/driver...rlappedIo.mspx

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/driver/kernel/KB-drv.mspx

Eliyas Yakub [MSFT] wrote:
> It should work. My guess is that your app has not opened the device for
> overlapped I/O. Read this tip for more info:
> http://www.microsoft.com/whdc/driver...rlappedIo.mspx

Interesting to see three completely different answers (Tom=no,
Eliyas=yes, Max=N/A).

Max is probably right in that setting OID_802_11_RSSI_TRIGGER should
only be done by one application, i.e. usually the XP+ built-in WZC.

Eliyas is probably right in that there can be multiple concurrent IOCTL
request outstanding.

Tom, well, I checked the NDISPROT sources (DDK build 3790.1830) and
think all used resources are on the stack and thus there should not be
any contention. Also, if there are several user-mode threads passing
IOCTLs to the driver, these are handled independently and one should
not block the other(s).

Also, in general, NDIS should be able to handle any number of OID
requests from protocol(s) to miniport(s). The only restriction is that
OID requests are passed in a serualized manner, one after the other, to
the miniport. [This is due to historical reasons as the
NdisMQueryInformationComplete() and NdisMSetInformationComplete()
functions do not allow the miniport to tell NDIS *which* request is
complete - so it can only be the last one.]

Bottom line: I guess the OPs approach should work if he follows Eliyas'
advice to open the device for overlapped I/O. However, I am not sure as
to whether he will experience any race conditions with WZC for the
OID_802_11_RSSI_TRIGGER.

Stephan