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." <(E-Mail Removed)>
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" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed).. .
>> 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
>
|
Linear Mode
