URGENT: HELP with IOCTL_NDISPROT_INDICATE_STATUS

Discussion in 'Wireless Networking' started by noe, May 4, 2006.

  1. noe

    noe Guest

    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, May 4, 2006
    #1
    1. Advertising

  2. > 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
     
    Stephan Wolf [MVP], May 4, 2006
    #2
    1. Advertising

  3. noe

    noe Guest

    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, May 4, 2006
    #3
  4. 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
     
    Stephan Wolf [MVP], May 4, 2006
    #4
  5. noe

    noe Guest

    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, May 4, 2006
    #5
  6. 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
     
    Stephan Wolf [MVP], May 4, 2006
    #6
  7. 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
     
    Maxim S. Shatskih, May 4, 2006
    #7
  8. "Stephan Wolf [MVP]" <> wrote in message
    news:...
    > 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
     
    Thomas F. Divine [DDK MVP], May 4, 2006
    #8
  9. Eliyas Yakub [MSFT], May 4, 2006
    #9
  10. 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/tips/OverlappedIo.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
     
    Stephan Wolf [MVP], May 4, 2006
    #10
  11. "Maxim S. Shatskih" wrote:
    > 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.


    "Non-destructive" OID queries (get various statistics) should not interfere
    with WZC.
    However RSSI trigger indication can be "destructive" because driver
    stores only one threshold value;
    the previous one will be overwritten.

    ( btw, Ndisprot blocks the INDICATE_STATUS request until any status
    indication, not just the RSSI).

    Regards,
    --PA
     
    =?Utf-8?B?UGF2ZWwgQS4=?=, May 4, 2006
    #11
  12. "Stephan Wolf [MVP]" <> wrote in message
    news:...
    > 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/tips/OverlappedIo.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).
    >


    You're right, Stephan. :-(

    Thomas

    > 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
    >
     
    Thomas F. Divine [DDK MVP], May 4, 2006
    #12
  13. Actually NdisMQueryInformationComplete() /etc. not taking a request
    parameter is the effect and not the cause. We contemplated removing request
    serialization from NDIS 6 but eventually scratched the idea. The main reason
    was that if two concurrent requests for the same OID tried to set
    conflicting parameters, it would be difficult for NDIS to know which one was
    processed by the miniport driver last. This and in the interest of keeping
    driver development simple, we stayed with serializing the requests. We did
    not see any obvious benefit in sending multiple concurrent requests to the
    driver.

    -ali

    --
    This posting is provided "AS IS" with no warranties, and confers no rights.


    "Stephan Wolf [MVP]" <> wrote in message
    news:...

    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.]
     
    Alireza Dabagh [MS], May 5, 2006
    #13
  14. noe

    noe Guest

    Uffff I think I am lost.You say requests, IRP, etc....but I only
    program the application. I don´t program the driver.I
    I want to query some OIDs and at the same time send
    IOCTL_NDISPROT_INDICATE_STATUS that indicate me when the signal
    strength is < than the threshold.


    Alireza Dabagh [MS] ha escrito:

    > Actually NdisMQueryInformationComplete() /etc. not taking a request
    > parameter is the effect and not the cause. We contemplated removing request
    > serialization from NDIS 6 but eventually scratched the idea. The main reason
    > was that if two concurrent requests for the same OID tried to set
    > conflicting parameters, it would be difficult for NDIS to know which one was
    > processed by the miniport driver last. This and in the interest of keeping
    > driver development simple, we stayed with serializing the requests. We did
    > not see any obvious benefit in sending multiple concurrent requests to the
    > driver.
    >
    > -ali
    >
    > --
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
    > "Stephan Wolf [MVP]" <> wrote in message
    > news:...
    >
    > 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.]
     
    noe, May 5, 2006
    #14
  15. noe wrote:
    > Uffff I think I am lost.You say requests, IRP, etc....but I only
    > program the application. I don´t program the driver.I
    > I want to query some OIDs and at the same time send
    > IOCTL_NDISPROT_INDICATE_STATUS that indicate me when the signal
    > strength is < than the threshold.


    Don't worry, this thread kind of started to discuss internals of NDIS.

    The interesting part for you is that your approach should actually work
    *if* you open the handle to the device correctly, i.e. as already
    mentioned by Eliyas
    (http://www.microsoft.com/whdc/driver/tips/OverlappedIo.mspx).

    Stephan
     
    Stephan Wolf [MVP], May 5, 2006
    #15
  16. Thanks Ali, it's always good to hear and know some background info!

    Stephan
    ---
    Alireza Dabagh [MS] wrote:
    > Actually NdisMQueryInformationComplete() /etc. not taking a request
    > parameter is the effect and not the cause. We contemplated removing request
    > serialization from NDIS 6 but eventually scratched the idea. The main reason
    > was that if two concurrent requests for the same OID tried to set
    > conflicting parameters, it would be difficult for NDIS to know which one was
    > processed by the miniport driver last. This and in the interest of keeping
    > driver development simple, we stayed with serializing the requests. We did
    > not see any obvious benefit in sending multiple concurrent requests to the
    > driver.
    >
    > -ali
     
    Stephan Wolf [MVP], May 5, 2006
    #16
  17. noe

    noe Guest

    Thanks Stephan, but I don´t understand some questions.
    1)I have opened my device for overlapped I/O but I don´t known how to
    inform to user mode when the signal is < that trigger. My code is
    below.I have only the struct NDISPROT_INDICATE_STATUS in nuiouser.h but
    I don´t have the definitions of its fields.I don´t find it in the
    documentation.

    2)Anothers questions about IOCTLs and IRPs:
    *Each call DeviceIoControl with IOCTL_NDISPROT_QUERY/SET_OID_VALUE or
    IOCTL_NDISPROT_INDICATE_STATUS generate a IRP in kernel mode??

    *Is I/O request the same that if I do query/set in my wireless card?

    *I have read in the web about I/O Manager (there is a lot of and
    complicated information), but can you tell me how the I/O Manager
    manage the IRPs? Does I/O Manager handle the IRPs one to one?

    Sthepan, you told me :" The IRP keeps pending until it either gets
    canceled ot the network card driver (NDIS miniport) actually indicates
    some status", but, Doesn´t that IRP block others IRPs when I do for
    example a query?

    Thomas told me :"The status change IRP will be queued until status
    changes", but where?in the I/O stack location?


    ///////////////////////////////
    typedef struct _NDISPROT_INDICATE_STATUS
    {
    ULONG IndicatedStatus; // NDIS_STATUS
    ULONG StatusBufferOffset; // from start of this
    struct
    ULONG StatusBufferLength; // in bytes
    } NDISPROT_INDICATE_STATUS, *PNDISPROT_INDICATE_STATUS;


    My code.
    ///////////////////////////////////////
    void CDLLNDISApp::IndicateStatusAsinc(HANDLE hAndle_ndisprotocol)
    {

    OVERLAPPED OverlapCall;

    OverlapCall.Offset=0;
    OverlapCall.OffsetHigh=0;

    OverlapCall.hEvent=CreateEvent(NULL,
    FALSE,
    TRUE,
    NULL);

    CHAR BufferStatus[1024];
    PNDISPROT_INDICATE_STATUS pIndicateStatus;
    pIndicateStatus = (PNDISPROT_INDICATE_STATUS)BufferStatus;

    bl = DeviceIoControl(hAndle_ndisprotocol,

    IOCTL_NDISPROT_INDICATE_STATUS,

    pIndicateStatus,sizeof(NDISPROT_INDICATE_STATUS),
    BufferStatus, 1024,
    &dwReturned,
    &OverlapCall);


    return;
    }
    //////////////////////////////////////////
    Stephan Wolf [MVP] ha escrito:

    > Thanks Ali, it's always good to hear and know some background info!
    >
    > Stephan
    > ---
    > Alireza Dabagh [MS] wrote:
    > > Actually NdisMQueryInformationComplete() /etc. not taking a request
    > > parameter is the effect and not the cause. We contemplated removing request
    > > serialization from NDIS 6 but eventually scratched the idea. The main reason
    > > was that if two concurrent requests for the same OID tried to set
    > > conflicting parameters, it would be difficult for NDIS to know which one was
    > > processed by the miniport driver last. This and in the interest of keeping
    > > driver development simple, we stayed with serializing the requests. We did
    > > not see any obvious benefit in sending multiple concurrent requests to the
    > > driver.
    > >
    > > -ali
     
    noe, May 8, 2006
    #17
  18. noe wrote:
    > *Each call DeviceIoControl with IOCTL_NDISPROT_QUERY/SET_OID_VALUE or
    > IOCTL_NDISPROT_INDICATE_STATUS generate a IRP in kernel mode??


    Yes.

    > *Is I/O request the same that if I do query/set in my wireless card?


    I/O Control (IOCTL) is a general mechanism used in (AFAIK) all
    operating systems to allow communication between applications
    (user-mode) and drivers (kernel-mode).

    Query/set requests to a network interface card (NIC) is the NDIS
    mechanism for communication between an NDIS protocol driver and an NIDS
    miniport (i.e. network card) driver. So this is all hapenning in
    kernel-mode only.

    Unfortunately, NDIS (the Network Interface Driver Specification)
    originally did not provide a mechamism that would allow some
    application to send IOCTLs to an NDIS miniport.

    Although NdisMRegisterDevice() has been added in IIRC NDIS 5.0, this is
    only for "private" IOCTLs between the miniport and application of some
    NIC vendor.

    Still there is no NDIS mechanism that would allow an application to
    send OID query/set requests to an NDIS miniport.

    Thus, MS wrote a sample NDIS protocol driver, namely NDISUIO, some
    years ago. This protocol driver at its upper edge provides an IOCTL
    interface that can be used by applications via DeviceIoControl(). OID
    requests can now be "wrapped" in an IOCTL and at its lower edge, the
    protocol driver forwards these OID requests to NDIS, which in turn
    forwards them to the respective NDIS miniport.

    appl. -IOCTL-> NDISUIO -OID query-(NDIS)-> miniport

    In XP, NDISUIO is used to establish a communication between the
    wireless zero configuration (WZC) and WLAN drivers.

    Thus, the original NDISUIO sample from the DDK can no longer be
    installed on XP (as it is already there). Consequently, MS renamed the
    NDISUIO sample to NDISPROT, which is what you find in the DDK today.
    NDISPROT can coexist with NDISUIO.

    > Sthepan, you told me :" The IRP keeps pending until it either gets
    > canceled ot the network card driver (NDIS miniport) actually indicates
    > some status", but, Doesn´t that IRP block others IRPs when I do for
    > example a query?


    AFAIK, no, it doess not block. But that probably also depends on how
    you open the NDISPROT device from your application. (I am not an IOCTL
    expert).

    > Thomas told me :"The status change IRP will be queued until status
    > changes", but where?in the I/O stack location?


    AFAIK, NDISPROT tells the system "this IRP is pending until I
    explicitly complete it". Later, when the status information arrives
    from the miniport, NDISPROT completes the IRP. At this point, your
    application will return from DeviceIoControl() or, if it is an
    overlapped I/O, the associated event will bet set. [I might be slightly
    wrong here wrt terminology etc.]

    See also

    "NDIS User Mode I/O (NDISUIO) Version Dependencies"
    http://www.ndis.com/pcakb/KB01010301.htm

    HTH, Stephan
     
    Stephan Wolf [MVP], May 11, 2006
    #18
  19. >Thus, the original NDISUIO sample from the DDK can no longer be
    >installed on XP (as it is already there). Consequently, MS renamed the
    >NDISUIO sample to NDISPROT, which is what you find in the DDK today.
    >NDISPROT can coexist with NDISUIO.


    Too bad MS did not choose to document the interface to the OS-provided NDISUIO
    in Windows NT family. All these tricks with NDISPROT look dirty.

    The better way would be:
    - to document at least some of the interface for OS-provided NDISUIO
    - always provide this NDISUIO for all future OSes
    - and publish the source in the DDK like the Serial source is published
    - maybe the next more advanced versions will be source-less and with new
    interfaces, but backward-compatible.

    Windows CE goes exactly this way. NDISUIO is a standard OS component there.

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation

    http://www.storagecraft.com
     
    Maxim S. Shatskih, May 11, 2006
    #19
  20. Maxim S. Shatskih wrote:
    > Windows CE goes exactly this way. NDISUIO is a standard OS component there.


    Unfortunately, there are just so many differences between CE and
    NT-based Windows. That was the case even for NDIS (the API), which I
    deem completely confusing and perfect nonsense as there was only a
    subset of NDIS available in CE. I however think that has changed for CE
    5+.

    Stephan
     
    Stephan Wolf [MVP], May 11, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jones

    help! help! help! Very urgent!

    Jones, Dec 7, 2003, in forum: Computer Information
    Replies:
    0
    Views:
    420
    Jones
    Dec 7, 2003
  2. Security Advisory

    !!URGENT!! Tor Vulnerability Discovered !!URGENT!!

    Security Advisory, Aug 6, 2007, in forum: Computer Security
    Replies:
    1
    Views:
    992
    http://tinyurl.com/23k3dt@$NIFF-deeply.ahh
    Aug 11, 2007
  3. Urgent: Help Us Help Other

    , Dec 21, 2003, in forum: A+ Certification
    Replies:
    0
    Views:
    309
  4. pooja
    Replies:
    0
    Views:
    1,214
    pooja
    Mar 3, 2009
  5. Griffin
    Replies:
    0
    Views:
    657
    Griffin
    Aug 27, 2010
Loading...

Share This Page