SAE Authentication time not affected

[sritam2]

Dear All,

I am trying to form the mesh network using SAE authentication in a very busy channel (channel 6 - 2437 Mhz). I am keeping the channel busy with data traffic by downloading torrent files from internet via router set at channel 6. But still the authentication time (calculated from time stamps of wpa_supplicant) is not affected even though the channel is very busy. It takes the same time compared to the authentication time when the channel was free (near by access points, routers, other devices were all off).

How is this possible?? Even if the channel is heavily loaded with network traffic, the authentication time required for new node to become part of MBSS is still unaffected ?? Any reason for that?
Is it that authentication traffic is given more priority than normal data traffic ??

Please help me in clearing this doubt of mine.

Thanks and Regards,
Sritam.

[chunyeow]

Try to understanding the mesh peering and mesh authentication procedures by
looking into the standard. Currently, the implementation is based on the
passive scanning or detecting beacon frame (usually sent with lowest Tx
rate) to trigger the mesh authentication and peering. Else you need to dig
into the code to understand more.

[zhejunli]

@sritam2 :I believe it is because the Management/Control packets have higher priority than Data packets. Eg. Ath9k supports 10 queues and data packets use Q0 which is lowest priority. This makes Mgt/Ctl packets have higher chance to be sent both inside chip and in he air, by DCF mechanism.

[chunyeow]

In additional to this, the tx rate used by those management/ctrl frame is more robust and usually set to lowest data rate. On Feb 17, 2018 2:13 AM, "zhejunli" <[email protected]> wrote: @sritam2 <https://github.com/sritam2> :I believe it is because the Management/Control packets have higher priority than Data packets. Eg. Ath9k supports 10 queues and data packets use Q0 which is lowest priority. This makes Mgt/Ctl packets have higher chance to be sent both inside chip and in he air, by DCF mechanism. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBewr3M8fwRpAQka6T-nGGDER2bSsLVks5tVcU6gaJpZM4ONdu_> .