Questions about 802.11b WEP keys and wireless NIC cards

Questions about 802.11b WEP keys and wireless NIC cards

Post by Jim Howar » Sat, 18 Oct 2003 00:51:48



Howdy.

I'm writing an application that uses the PCAUSA rawether tool to set various
settings on 802.11b wireless cards.  Rawether (amoung many other things)
lets user level programs get and set network adapter card properties
described by the various NDIS OID values.

For purposes of this question, I am working with 802.11b infrastructure mode
using WEP authentication as you would find in a home or small office.  No
server based authentication is used, I'm working with the access points and
wireless adapters you would purchase at Best Buy.

I am able to get and set SSIDs on most wireless cards, and am able to set
WEP keys for most wireless cards, but I am running into some anomalies.  In
particular, when I set the WEP key with my application, the settings usually
do not persist through a reset, but when I use WZC or the OEM setup utility
to set values then the WEP keys and SSID settings persist through resets,
even if I disable WZC and the OEM setup before I reset.  I'm trying to
figure out why this is happening.

Here are some questions I have about WEP based on the IEEE guidelines for
802.11 network adapters (
http://www.microsoft.com/whdc/hwdev/tech/network/802x/80211_netadapte... )
:

1)  Under OID_802_11_ADD_WEP it talks about global and per client keys.  I'm
a little hazy on what these terms mean.  I talk it that a global key is the
WEB key that we usually use with garden variety access points. Are there
access points that support a different key for each client ("per client"?).

2)  When setting a value for OID_802_11_ADD_WEP the guideline says about the
NDIS_802_11_WEP keyindex value: "Specifies which key to add or remove. The
global keys are represented by values of zero to n. When bit 31 is set to 1,
it indicates the key used to transmit to the access point. When bit 30 is
set to 1, it indicates that the key is a per-client key". What is this all
about? In my experiments, setting bit 31 of the key index seems to make no
difference, and setting bit 30 causes the call to fail.

2)  The standard says "When this OID sets the same index twice, the miniport
driver should overwrite the previous WEP key at that index".  What does that
mean in practice?  What is the difference in adapter behavior if I only set
the wep key an a particular once or twice?

Besides making a valid call to OID_802_11_ADD_WEP and turning WEP on by
setting  Ndis802_11WEPEnabled to  Ndis802_11WEPEnabled,  is there anything
else I should do to make the WEP key persist through a reset?

Any hints will be very welcome.

 
 
 

Questions about 802.11b WEP keys and wireless NIC cards

Post by Larry Cawle » Sun, 19 Oct 2003 01:11:12


responses inline....

---
Larry Cawley


Quote:> Howdy.

> I'm writing an application that uses the PCAUSA rawether tool to set
various
> settings on 802.11b wireless cards.  Rawether (amoung many other things)
> lets user level programs get and set network adapter card properties
> described by the various NDIS OID values.

> For purposes of this question, I am working with 802.11b infrastructure
mode
> using WEP authentication as you would find in a home or small office.  No
> server based authentication is used, I'm working with the access points
and
> wireless adapters you would purchase at Best Buy.

> I am able to get and set SSIDs on most wireless cards, and am able to set
> WEP keys for most wireless cards, but I am running into some anomalies.
In
> particular, when I set the WEP key with my application, the settings
usually
> do not persist through a reset, but when I use WZC or the OEM setup
utility
> to set values then the WEP keys and SSID settings persist through resets,
> even if I disable WZC and the OEM setup before I reset.  I'm trying to
> figure out why this is happening.

> Here are some questions I have about WEP based on the IEEE guidelines for
> 802.11 network adapters (

http://www.microsoft.com/whdc/hwdev/tech/network/802x/80211_netadapte... )
Quote:> :

> 1)  Under OID_802_11_ADD_WEP it talks about global and per client keys.
I'm
> a little hazy on what these terms mean.  I talk it that a global key is
the
> WEB key that we usually use with garden variety access points. Are there
> access points that support a different key for each client ("per

client"?).

Global is the key for broadcast and muilticast traffic.  Per Client key is
for encryption Unicast traffic.

Quote:

> 2)  When setting a value for OID_802_11_ADD_WEP the guideline says about
the
> NDIS_802_11_WEP keyindex value: "Specifies which key to add or remove. The
> global keys are represented by values of zero to n. When bit 31 is set to
1,
> it indicates the key used to transmit to the access point. When bit 30 is
> set to 1, it indicates that the key is a per-client key". What is this all
> about? In my experiments, setting bit 31 of the key index seems to make no
> difference, and setting bit 30 causes the call to fail.

See above answer to #1.  The driver is likely treating these as one set of
keys.  The bit 30 failure is the driver / hardware not fully supporting
broadcast and unicast key sets.

Quote:

> 2)  The standard says "When this OID sets the same index twice, the
miniport
> driver should overwrite the previous WEP key at that index".  What does
that
> mean in practice?  What is the difference in adapter behavior if I only
set
> the wep key an a particular once or twice?

It means what it says :-)  For example if you set WEP key 1 and then set WEP
key 1 again, the LAST key set will be the one in use.

Quote:

> Besides making a valid call to OID_802_11_ADD_WEP and turning WEP on by
> setting  Ndis802_11WEPEnabled to  Ndis802_11WEPEnabled,  is there anything
> else I should do to make the WEP key persist through a reset?

The RESET issue is a driver or hardware problem.  The driver / hardware has
to have a way to re-plumb the keys after a Reset to assure they remain in
place.  This particular driver / hardware is not doing that...

- Show quoted text -

Quote:

> Any hints will be very welcome.


 
 
 

Questions about 802.11b WEP keys and wireless NIC cards

Post by Pavel A » Sun, 19 Oct 2003 02:12:40





> > Besides making a valid call to OID_802_11_ADD_WEP and turning WEP on by
> > setting  Ndis802_11WEPEnabled to  Ndis802_11WEPEnabled,  is there anything
> > else I should do to make the WEP key persist through a reset?

> The RESET issue is a driver or hardware problem.  The driver / hardware has
> to have a way to re-plumb the keys after a Reset to assure they remain in
> place.  This particular driver / hardware is not doing that...

Actually the Microsoft's 802.11 document  contradicts itself on reset behavior:
(IEEE 802.11 Network Adapter Design Guidelines for Windows XP, May-03)

In description of OID_802_11_ADD_KEY :
"All keys set through this OID for any BSSID should be discarded immediately after any of the
following events: ....
When the NIC is disabled or reset"

Later, it says:
"A driver receiving an NDISReset should save the current state of the NIC, reset the device, and
reconfigure the original state, including keys"

So? Save or discard?  (and btw, what is NDISReset  - MiniportReset? )

Regards,
--PA

 
 
 

Questions about 802.11b WEP keys and wireless NIC cards

Post by Jim Howar » Sun, 19 Oct 2003 02:25:01


Thanks very much for the replies.  WRT to resets, my problem is that when I
use the documented OIDs I have to reset the WEP keys after a reset.

Windows Zero Configuration service, on the other hand, is able to restore
the adapter's WEP keys on its own after a reset.  Is it possible that WZC is
violating the Microsoft guidance and storing the WEP keys in the filesystem
somewhere?

thanks,

Jim

 
 
 

Questions about 802.11b WEP keys and wireless NIC cards

Post by Jim Howar » Sun, 19 Oct 2003 02:37:15


I think I found the answer on my own.  The card OEM is storing the WEP keys
in the clear in the driver's registry settings.  I wonder how widespread
this practice is?

Jim


Quote:> Thanks very much for the replies.  WRT to resets, my problem is that when
I
> use the documented OIDs I have to reset the WEP keys after a reset.

> Windows Zero Configuration service, on the other hand, is able to restore
> the adapter's WEP keys on its own after a reset.  Is it possible that WZC
is
> violating the Microsoft guidance and storing the WEP keys in the
filesystem
> somewhere?

> thanks,

> Jim

 
 
 

Questions about 802.11b WEP keys and wireless NIC cards

Post by Pavel A » Sun, 19 Oct 2003 02:50:41



> Windows Zero Configuration service, on the other hand, is able to restore
> the adapter's WEP keys on its own after a reset.  Is it possible that WZC is
> violating the Microsoft guidance and storing the WEP keys in the filesystem
> somewhere?

WZC stores settings for configured connections in registry under HKCU/Software/Microsoft/WZC.
Microsoft document only specifies behavior of MAC drivers, so it is not applicable to the  WZC
service or OEM utility.
A *driver* that stores the keys in registry or file does violate the guidance.

Regards,
 -PA

 
 
 

Questions about 802.11b WEP keys and wireless NIC cards

Post by Larry Cawle » Thu, 23 Oct 2003 07:23:21


You are correct in that these are contradicting statements.  In reality, if
you do not restore the keys after a Reset, you won't pass the reset tests in
HCT because if you don't get the keys set you cannot estabilsh a link.

So in reality, the keys need to be 'saved' for reset situations.  They can
be saved in memory though, not in persistent storage (registry, files,
etc.).






> > > Besides making a valid call to OID_802_11_ADD_WEP and turning WEP on
by
> > > setting  Ndis802_11WEPEnabled to  Ndis802_11WEPEnabled,  is there
anything
> > > else I should do to make the WEP key persist through a reset?

> > The RESET issue is a driver or hardware problem.  The driver / hardware
has
> > to have a way to re-plumb the keys after a Reset to assure they remain
in
> > place.  This particular driver / hardware is not doing that...

> Actually the Microsoft's 802.11 document  contradicts itself on reset
behavior:
> (IEEE 802.11 Network Adapter Design Guidelines for Windows XP, May-03)

> In description of OID_802_11_ADD_KEY :
> "All keys set through this OID for any BSSID should be discarded

immediately after any of the
Quote:> following events: ....
> When the NIC is disabled or reset"

> Later, it says:
> "A driver receiving an NDISReset should save the current state of the NIC,

reset the device, and

- Show quoted text -

Quote:> reconfigure the original state, including keys"

> So? Save or discard?  (and btw, what is NDISReset  - MiniportReset? )

> Regards,
> --PA

 
 
 

Questions about 802.11b WEP keys and wireless NIC cards

Post by Pavel A » Thu, 23 Oct 2003 10:33:11


Thanks, Larry.

Recently I had had obsessive idea of using same service (WZC or 3rd party app)
that creates the connection initially: the driver will pend reset, send
disconnect & key update indications up, so the managing app will set SSID, keys and so on.
When connection is ready, driver completes reset.
This naive solution is however not feasible - because during reset NDIS won't pass set/query
requests to the miniport.
So... got back to the reality ;)

Regards,
 --PA


> You are correct in that these are contradicting statements.  In reality, if
> you do not restore the keys after a Reset, you won't pass the reset tests in
> HCT because if you don't get the keys set you cannot estabilsh a link.

> So in reality, the keys need to be 'saved' for reset situations.  They can
> be saved in memory though, not in persistent storage (registry, files,
> etc.).







> > > > Besides making a valid call to OID_802_11_ADD_WEP and turning WEP on
> by
> > > > setting  Ndis802_11WEPEnabled to  Ndis802_11WEPEnabled,  is there
> anything
> > > > else I should do to make the WEP key persist through a reset?

> > > The RESET issue is a driver or hardware problem.  The driver / hardware
> has
> > > to have a way to re-plumb the keys after a Reset to assure they remain
> in
> > > place.  This particular driver / hardware is not doing that...

> > Actually the Microsoft's 802.11 document  contradicts itself on reset
> behavior:
> > (IEEE 802.11 Network Adapter Design Guidelines for Windows XP, May-03)

> > In description of OID_802_11_ADD_KEY :
> > "All keys set through this OID for any BSSID should be discarded
> immediately after any of the
> > following events: ....
> > When the NIC is disabled or reset"

> > Later, it says:
> > "A driver receiving an NDISReset should save the current state of the NIC,
> reset the device, and
> > reconfigure the original state, including keys"

> > So? Save or discard?  (and btw, what is NDISReset  - MiniportReset? )

> > Regards,
> > --PA

 
 
 

1. OT-basic questions about 802.11b and 802.11g

You need to hook a computer to the router to configure it, but once it
has been configured, does it still need to be hooked up to a computer?
can you just hook the DSL modem directly to the router?

Is there any advantage to setting up a 802.11G network over a 802.11b
network at home with my DSL?

2. Wuauboot, wuauclt, Icsmgr

3. 3Com AirConnect Wireless 802.11b pcmica network card

4. how to change the extension of a file?

5. Problem with XP and 802.11b Wireless PCMCIA card.

6. desktop shortcut

7. Installing Belkin PCI 802.11b Wireless Network Card

8. What's the difference between MFC's Dynamic Creation and C++'s new?

9. Wireless 802.11b PC Card?

10. Configuring 802.11b WEP

11. WEP / 802.11b Encryption XP Pro

12. 802.11b, XP, and WEP

13. ActiveSync over 802.11b card, conflict with onboard network card