Monitoring WiFi connect/disconnect events in NDIS IM driver

NTDEV
1

Hi All

In my NDIS Intermediate driver I would like to monitor when the WiFi
miniport is associated with access points. Currently the driver uses media
connect/disconnect indications that are sent by the miniport driver.

This solution works fine with several different 802.11 cards, but I found
that Cisco 350 wireless card behaves in a very different way.

Two examples:

  1. If the WLAN card is configured using Cisco management application and
    then the system is rebooted, the network is connected automatically after
    the reboot, but no NDIS_STATUS_MEDIA_CONNECT indication is sent. In some way
    Windows knows that the network is connected and the icon in the system tray
    shows as “connected”.

  2. When the control over the WLAN card is passed from the Cisco management
    application to WZC service, the network is disconnected, but no
    NDIS_STATUS_MEDIA_DISCONNECT indication is sent. Again Windows is in some
    way notified that the network is disconnected and the network connection
    icon in the system tray changes to “disconnected”.

Is there any other way to monitor connect/disconnect events?

Thanks,

Gregory

2

“Gregory Dardyk” wrote in message news:xxxxx@ntdev…
> Hi All
>
> In my NDIS Intermediate driver I would like to monitor when the WiFi
> miniport is associated with access points. Currently the driver uses media
> connect/disconnect indications that are sent by the miniport driver.
>
> This solution works fine with several different 802.11 cards, but I found
> that Cisco 350 wireless card behaves in a very different way.
>
> Two examples:
>
> 1. If the WLAN card is configured using Cisco management application and
> then the system is rebooted, the network is connected automatically after
> the reboot, but no NDIS_STATUS_MEDIA_CONNECT indication is sent. In some way
> Windows knows that the network is connected and the icon in the system tray
> shows as “connected”.
>
> 2. When the control over the WLAN card is passed from the Cisco management
> application to WZC service, the network is disconnected, but no
> NDIS_STATUS_MEDIA_DISCONNECT indication is sent. Again Windows is in some
> way notified that the network is disconnected and the network connection
> icon in the system tray changes to “disconnected”.
>
> Is there any other way to monitor connect/disconnect events?

Poll ?

–PA

3

Gregory,

WHDC once had a document covering 802.11 media connect behavior; in a five
second search of the site I did not find a link right away but it may still
be hanging around. The title was “IEEE 802.11 Network Adapter Design
Guidelines for Windows XP” and the document name was
“80211_network_adapter.doc” You may have some luck finding it up there or
finding that the information was published into the DDK docs.

In particular, Media Sense behavior for all NICs behaves consitently with
what you have observed for (1). The *assumption* by NDIS (and by protocols)
is that a NIC is connected to the medium unless the NIC indicates otherwise.
A NIC should not indicate a media connect immediately after initialization
if it is connected (and has not indicated media disconnect). If a NIC is
disconnected, it *should* indicate disconnect within some short period after
initialization (5 seconds, if I recall correctly).

That, however, is NIC behavior from NDIS’s point of view. As a protocol
driver the only way to find out the media state when you bind to an adapter
is to query it. From that point forward, your protocol can expect to
recieve status indications when media state changes.

As for (2): Are any other IM drivers bound below you and above the NIC
(like an IM driver doing something with 802.11 provisioning or link
management)?

I have worked with this NIC often with IM drivers and have not observed
anything exotic about the Media Status indications or Media Sense support
implemented by the driver. All that, however, might have changed with a
recent driver update, however.

You should always be able to query the current media status. Try scheduling
a miniport timer to query the media status of the bound adapter every few
seconds as a debugging aid. You should not need to poll the status in a
production IM driver. Perhaps this would help you determine where things
are breaking.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory Dardyk
Sent: Monday, May 29, 2006 12:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Monitoring WiFi connect/disconnect events in NDIS IM driver

Hi All

In my NDIS Intermediate driver I would like to monitor when the WiFi
miniport is associated with access points. Currently the driver uses media
connect/disconnect indications that are sent by the miniport driver.

This solution works fine with several different 802.11 cards, but I found
that Cisco 350 wireless card behaves in a very different way.

Two examples:

  1. If the WLAN card is configured using Cisco management application and
    then the system is rebooted, the network is connected automatically after
    the reboot, but no NDIS_STATUS_MEDIA_CONNECT indication is sent. In some way
    Windows knows that the network is connected and the icon in the system tray
    shows as “connected”.

  2. When the control over the WLAN card is passed from the Cisco management
    application to WZC service, the network is disconnected, but no
    NDIS_STATUS_MEDIA_DISCONNECT indication is sent. Again Windows is in some
    way notified that the network is disconnected and the network connection
    icon in the system tray changes to “disconnected”.

Is there any other way to monitor connect/disconnect events?

Thanks,

Gregory

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> WHDC once had a document covering 802.11 media connect behavior; in a five
> second search of the site I did not find a link right away but it may still
> be hanging around. The title was “IEEE 802.11 Network Adapter Design
> Guidelines for Windows XP” and the document name was
> “80211_network_adapter.doc” You may have some luck finding it up there or
> finding that the information was published into the DDK docs.

This document has been merged into the DDK (WDK).
Get the latest: WDK beta 2.

—PA

5

This is off-topic, but refers to the poster.

David, are you running some strange email client, ISP or other such
software? I’ve noticed over the past year that ALL emails from you cause a
very strange error when I try to delete them with my anti-spam software. I
have to use my ISP’s web interface to clean your postings from my inbox. No
one else causes that problem.

Any idea??
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David R. Cattley
Sent: Monday, May 29, 2006 4:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Monitoring WiFi connect/disconnect events in NDIS IM
driver

Gregory,

WHDC once had a document covering 802.11 media connect behavior; in a five
second search of the site I did not find a link right away but it may still
be hanging around. The title was “IEEE 802.11 Network Adapter Design
Guidelines for Windows XP” and the document name was
“80211_network_adapter.doc” You may have some luck finding it up there or
finding that the information was published into the DDK docs.

In particular, Media Sense behavior for all NICs behaves consitently with
what you have observed for (1). The *assumption* by NDIS (and by protocols)
is that a NIC is connected to the medium unless the NIC indicates otherwise.
A NIC should not indicate a media connect immediately after initialization
if it is connected (and has not indicated media disconnect). If a NIC is
disconnected, it *should* indicate disconnect within some short period after
initialization (5 seconds, if I recall correctly).

That, however, is NIC behavior from NDIS’s point of view. As a protocol
driver the only way to find out the media state when you bind to an adapter
is to query it. From that point forward, your protocol can expect to
recieve status indications when media state changes.

As for (2): Are any other IM drivers bound below you and above the NIC
(like an IM driver doing something with 802.11 provisioning or link
management)?

I have worked with this NIC often with IM drivers and have not observed
anything exotic about the Media Status indications or Media Sense support
implemented by the driver. All that, however, might have changed with a
recent driver update, however.

You should always be able to query the current media status. Try
scheduling a miniport timer to query the media status of the bound adapter
every few seconds as a debugging aid. You should not need to poll the
status in a production IM driver. Perhaps this would help you determine
where things are breaking.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

–
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory Dardyk
Sent: Monday, May 29, 2006 12:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Monitoring WiFi connect/disconnect events in NDIS IM
driver

Hi All

In my NDIS Intermediate driver I would like to monitor when the WiFi
miniport is associated with access points. Currently the driver uses media
connect/disconnect indications that are sent by the miniport driver.

This solution works fine with several different 802.11 cards, but I found
that Cisco 350 wireless card behaves in a very different way.

Two examples:

  1. If the WLAN card is configured using Cisco management application and
    then the system is rebooted, the network is connected automatically after
    the reboot, but no NDIS_STATUS_MEDIA_CONNECT indication is sent. In some way
    Windows knows that the network is connected and the icon in the system tray
    shows as “connected”.

  2. When the control over the WLAN card is passed from the Cisco management
    application to WZC service, the network is disconnected, but no
    NDIS_STATUS_MEDIA_DISCONNECT indication is sent. Again Windows is in some
    way notified that the network is disconnected and the network connection
    icon in the system tray changes to “disconnected”.

Is there any other way to monitor connect/disconnect events?

Thanks,

Gregory

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

One clarification here on the protocol querying the connect status
(OID_GEN_MEDIA_CONNECT_STATUS):

When a protocol above an IM driver (like TCP/IP) queries the status,
this query (in my experience) does NOT go thru the IM driver but rather
directly to the miniport driver (this is not the case for most OIDs that
I’ve seen). So your only option seems to be querying it yourself from
your IM driver.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, May 29, 2006 5:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Monitoring WiFi connect/disconnect events in NDIS
IM driver

Gregory,

WHDC once had a document covering 802.11 media connect behavior; in a
five second search of the site I did not find a link right away but it
may still be hanging around. The title was “IEEE 802.11 Network Adapter
Design Guidelines for Windows XP” and the document name was
“80211_network_adapter.doc” You may have some luck finding it up there
or finding that the information was published into the DDK docs.

In particular, Media Sense behavior for all NICs behaves consitently
with what you have observed for (1). The *assumption* by NDIS (and by
protocols) is that a NIC is connected to the medium unless the NIC
indicates otherwise. A NIC should not indicate a media connect
immediately after initialization if it is connected (and has not
indicated media disconnect). If a NIC is disconnected, it *should*
indicate disconnect within some short period after initialization (5
seconds, if I recall correctly).

That, however, is NIC behavior from NDIS’s point of view. As a protocol
driver the only way to find out the media state when you bind to an
adapter is to query it. From that point forward, your protocol can
expect to recieve status indications when media state changes.

As for (2): Are any other IM drivers bound below you and above the NIC
(like an IM driver doing something with 802.11 provisioning or link
management)?

I have worked with this NIC often with IM drivers and have not observed
anything exotic about the Media Status indications or Media Sense
support implemented by the driver. All that, however, might have
changed with a recent driver update, however.

You should always be able to query the current media status. Try
scheduling a miniport timer to query the media status of the bound
adapter every few seconds as a debugging aid. You should not need to
poll the status in a production IM driver. Perhaps this would help you
determine where things are breaking.

Good Luck,

Dave Cattley

Consulting Engineer

Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory Dardyk
Sent: Monday, May 29, 2006 12:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Monitoring WiFi connect/disconnect events in NDIS IM
driver

Hi All

In my NDIS Intermediate driver I would like to monitor when the WiFi
miniport is associated with access points. Currently the driver uses
media connect/disconnect indications that are sent by the miniport
driver.

This solution works fine with several different 802.11 cards, but I
found that Cisco 350 wireless card behaves in a very different way.

Two examples:

  1. If the WLAN card is configured using Cisco management application and
    then the system is rebooted, the network is connected automatically
    after the reboot, but no NDIS_STATUS_MEDIA_CONNECT indication is sent.
    In some way Windows knows that the network is connected and the icon in
    the system tray shows as “connected”.

  2. When the control over the WLAN card is passed from the Cisco
    management application to WZC service, the network is disconnected, but
    no NDIS_STATUS_MEDIA_DISCONNECT indication is sent. Again Windows is in
    some way notified that the network is disconnected and the network
    connection icon in the system tray changes to “disconnected”.

Is there any other way to monitor connect/disconnect events?

Thanks,

Gregory

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

David:

Thanks for your help. I assumed that a NIC will always send an indication
after initialization. Apparently, that was a wrong assumption, though it
worked with most of the NICs.

Paul:

Thanks for the tip. I tried to sniff in my driver for such polling but got
nothing. Do you know how do these queries get to the miniport?

I also have another question. In my driver I tried to cause the miniport to
disconnect from the current network. Normally it is done by sending an
OID_802_11_DISASSOCIATE set request and then an OID_802_11_SSID set request.
It works with most NICs except the same Cisco card. It just ignores both
requests. Is there another way to cause a NIC do disconnect from a network?

Thanks a lot,

Gregory

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Paul Benware
Sent: Tuesday, May 30, 2006 6:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Monitoring WiFi connect/disconnect events in NDIS IM
driver

One clarification here on the protocol querying the connect status
(OID_GEN_MEDIA_CONNECT_STATUS):

When a protocol above an IM driver (like TCP/IP) queries the status, this
query (in my experience) does NOT go thru the IM driver but rather directly
to the miniport driver (this is not the case for most OIDs that I’ve seen).
So your only option seems to be querying it yourself from your IM driver.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, May 29, 2006 5:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Monitoring WiFi connect/disconnect events in NDIS IM
driver

Gregory,

WHDC once had a document covering 802.11 media connect behavior; in a five
second search of the site I did not find a link right away but it may still
be hanging around. The title was “IEEE 802.11 Network Adapter Design
Guidelines for Windows XP” and the document name was
“80211_network_adapter.doc” You may have some luck finding it up there or
finding that the information was published into the DDK docs.

In particular, Media Sense behavior for all NICs behaves consitently with
what you have observed for (1). The *assumption* by NDIS (and by protocols)
is that a NIC is connected to the medium unless the NIC indicates otherwise.
A NIC should not indicate a media connect immediately after initialization
if it is connected (and has not indicated media disconnect). If a NIC is
disconnected, it *should* indicate disconnect within some short period after
initialization (5 seconds, if I recall correctly).

That, however, is NIC behavior from NDIS’s point of view. As a protocol
driver the only way to find out the media state when you bind to an adapter
is to query it. From that point forward, your protocol can expect to
recieve status indications when media state changes.

As for (2): Are any other IM drivers bound below you and above the NIC
(like an IM driver doing something with 802.11 provisioning or link
management)?

I have worked with this NIC often with IM drivers and have not observed
anything exotic about the Media Status indications or Media Sense support
implemented by the driver. All that, however, might have changed with a
recent driver update, however.

You should always be able to query the current media status. Try scheduling
a miniport timer to query the media status of the bound adapter every few
seconds as a debugging aid. You should not need to poll the status in a
production IM driver. Perhaps this would help you determine where things
are breaking.

Good Luck,

Dave Cattley

Consulting Engineer

Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gregory Dardyk
Sent: Monday, May 29, 2006 12:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Monitoring WiFi connect/disconnect events in NDIS IM driver

Hi All

In my NDIS Intermediate driver I would like to monitor when the WiFi
miniport is associated with access points. Currently the driver uses media
connect/disconnect indications that are sent by the miniport driver.

This solution works fine with several different 802.11 cards, but I found
that Cisco 350 wireless card behaves in a very different way.

Two examples:

  1. If the WLAN card is configured using Cisco management application and
    then the system is rebooted, the network is connected automatically after
    the reboot, but no NDIS_STATUS_MEDIA_CONNECT indication is sent. In some way
    Windows knows that the network is connected and the icon in the system tray
    shows as “connected”.

  2. When the control over the WLAN card is passed from the Cisco management
    application to WZC service, the network is disconnected, but no
    NDIS_STATUS_MEDIA_DISCONNECT indication is sent. Again Windows is in some
    way notified that the network is disconnected and the network connection
    icon in the system tray changes to “disconnected”.

Is there any other way to monitor connect/disconnect events?

Thanks,

Gregory

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

“Simon Lator” wrote in message news:xxxxx@ntdev…
> I tried to sniff in my driver for such polling but got
> nothing. Do you know how do these queries get to the miniport?

Just poll the miniport yourself. Send the request.

> I also have another question. In my driver I tried to cause the miniport to
> disconnect from the current network. Normally it is done by sending an
> OID_802_11_DISASSOCIATE set request and then an OID_802_11_SSID set request.
> It works with most NICs except the same Cisco card. It just ignores both
> requests. Is there another way to cause a NIC do disconnect from a network?

Hmm. Too many problems with one card. Ask their support for a compliant driver?

–PA