WPA and QOS

[Chris]

Archived from groups: microsoft.public.windows.networking.wireless (More info?)

I have been experiencing a number ofproblems on Windows XP with
various wirelesss solutions where the connection is lost periodically
and a key absent message is displayed. The only to reset the
connection is to remove or diale the card and start again.

I have run all the updates recommended by a number of wireless sites
including Micrsoft's and have even tried using the various release
candidates for sp2. In addition I have upgraded my network card and
access point drivers/firmware to the latest verison.

The problem appears to be worse with 802.11g clients and initial tests
indicate that disavling qos resolves this problem.

Does anyone know if this is a known problem with qos given that the
802.11e standard has not yet been ratified and therefore presumably is
either not implemented in the microsoft configuration utily or is
partially implemented causing problem with the interaction of the
miniport schedular? or is it something more fundamental to do with
the network card drivers compatability with the winsock2 and gqos
api's?

Something else I have been thinking of is, is there a problem with
802.1p proritisation which is causing a problem with the rekeying
mechanism of wpa?

Sorry for the disjointed comments but I haven't been able to find any
definative answer (been escalated to the highest level within one
vendor in an attemot to determine the problem) to this one so anyone
with any ideas please reply.

Best regards

Chris

 

[Guest]

Archived from groups: microsoft.public.windows.networking.wireless (More info?)

If I understand your concerns correct - you worry about possible
reordering of .1x packets due to priority (802.1p).
Maybe... however WPA is possible without 802.1x, so at least
in this case 802.1p isn't relevant.
Do you enable .1x ?

"Chris" <cralph@ntlworld.com> wrote in message
news:tu6me0po82ti0d96pt50ts5nar52u5bvlb@4ax.com...
> I have been experiencing a number ofproblems on Windows XP with
> various wirelesss solutions where the connection is lost periodically
> and a key absent message is displayed. The only to reset the
> connection is to remove or diale the card and start again.
>
> I have run all the updates recommended by a number of wireless sites
> including Micrsoft's and have even tried using the various release
> candidates for sp2. In addition I have upgraded my network card and
> access point drivers/firmware to the latest verison.
>
> The problem appears to be worse with 802.11g clients and initial tests
> indicate that disavling qos resolves this problem.
>
> Does anyone know if this is a known problem with qos given that the
> 802.11e standard has not yet been ratified and therefore presumably is
> either not implemented in the microsoft configuration utily or is
> partially implemented causing problem with the interaction of the
> miniport schedular? or is it something more fundamental to do with
> the network card drivers compatability with the winsock2 and gqos
> api's?
>
> Something else I have been thinking of is, is there a problem with
> 802.1p proritisation which is causing a problem with the rekeying
> mechanism of wpa?
>
> Sorry for the disjointed comments but I haven't been able to find any
> definative answer (been escalated to the highest level within one
> vendor in an attemot to determine the problem) to this one so anyone
> with any ideas please reply.
>
> Best regards
>
> Chris

 

[Chris]

Archived from groups: microsoft.public.windows.networking.wireless (More info?)

I am using qos on my network with gqos aware apps such as
videoconferencing and voip and assumed at first that the same would be
true for my wireless extensions. 802.1x prioritisation is currently
provided through the qos service and gateways/routers.

I don't necessarilly need qos on my wireless devices right now so I
have disabled it and the key absent problem has gone.

The problem is essentially solved (I think) I would just like to
understand why the problem exists and of course in order to develop my
current systems into a true wireless voip network I will need qos to
work at some time in the future but I assume that this will happen
with the ratification of the 802.11e standard.

What I am trying to understand is where the problem is. Is it a
problem with 802.1p prioritisation levels interacting with the unicast
and or multicast/broadcast rekeying causing one or other to fail? If
so, then how do I go about proving this?

Or is it somehting more fundamental to do with the interaction of the
network card packet driver/wpa modules and the winsock2 gqos api?

Or possibly something completly different that I haven't taken into
account..........


chris




On Wed, 7 Jul 2004 03:12:03 +0300, "Pavel A." <pavel_a@geeklife.com>
wrote:

>If I understand your concerns correct - you worry about possible
>reordering of .1x packets due to priority (802.1p).
>Maybe... however WPA is possible without 802.1x, so at least
>in this case 802.1p isn't relevant.
>Do you enable .1x ?
>
>"Chris" <cralph@ntlworld.com> wrote in message
>news:tu6me0po82ti0d96pt50ts5nar52u5bvlb@4ax.com...
>> I have been experiencing a number ofproblems on Windows XP with
>> various wirelesss solutions where the connection is lost periodically
>> and a key absent message is displayed. The only to reset the
>> connection is to remove or diale the card and start again.
>>
>> I have run all the updates recommended by a number of wireless sites
>> including Micrsoft's and have even tried using the various release
>> candidates for sp2. In addition I have upgraded my network card and
>> access point drivers/firmware to the latest verison.
>>
>> The problem appears to be worse with 802.11g clients and initial tests
>> indicate that disavling qos resolves this problem.
>>
>> Does anyone know if this is a known problem with qos given that the
>> 802.11e standard has not yet been ratified and therefore presumably is
>> either not implemented in the microsoft configuration utily or is
>> partially implemented causing problem with the interaction of the
>> miniport schedular? or is it something more fundamental to do with
>> the network card drivers compatability with the winsock2 and gqos
>> api's?
>>
>> Something else I have been thinking of is, is there a problem with
>> 802.1p proritisation which is causing a problem with the rekeying
>> mechanism of wpa?
>>
>> Sorry for the disjointed comments but I haven't been able to find any
>> definative answer (been escalated to the highest level within one
>> vendor in an attemot to determine the problem) to this one so anyone
>> with any ideas please reply.
>>
>> Best regards
>>
>> Chris
>