Forum

  • I am confused about something.

    I looked at a sniffer trace between 802.11b and 802.11b AP.

    The client showed ShortPreamble=False, the AP showed ShortPreamble=True

    Yet the client was able to associate.

    Based on what I am reading in the CWAP book, I would think that the Association Response would give a status code of "can't support short preambles".

    What am I missing/or presuming to understand.....

  • I need to edit my question:

    The client has ShortPreamble=True, the AP has ShortPreamble=False, and it associates.

    In looking at the Capabilities Field, if the AP does not allow Short Preambles, then I am presuming the user should be able to associate.

    What is am I misunderstanding???


    react302 Escribió:

    I am confused about something.

    I looked at a sniffer trace between 802.11b and 802.11b AP.

    The client showed ShortPreamble=False, the AP showed ShortPreamble=True

    Yet the client was able to associate.

    Based on what I am reading in the CWAP book, I would think that the Association Response would give a status code of "can't support short preambles".

    What am I missing/or presuming to understand.....

  • Hi react302:

    You are correct. The standard carefully describes the meaning of the "short preamble" bit in the capability field of management frames from clients and from access points. The standard sternly warns about how stations based on the long-only PHY cannot demodulate frames with short preamble.

    The standard leaves to the access point vendor when to deny association because of a mismatch and when to accept association but deny use of short preamble for all stations in the BSS.

    And on page 177 of the CWAP study guide, the phrase "of the 802.11g standard" should be deleted (section 18.2.2.2 is actually found in the 802.11b amendment).

    I hope this helps. Thanks. /criss

  • Criss,

    First of all, thanks for all the assistance you have been giving me.

    The CWAP book states that 802.11g standard made support for long and short preambles as mandatory, such as "long or short preambles are ok" (pg 224).

    I looked at one of the Amilabs traces for 802.11g and there is one trace (80211g auth fail due to no support of short preamble) where the client can not associate because he does not support short preambles.

    This opens up my next question:

    If the client is a 802.11g and only can do long preambles, according to his capability field, and the 802.11g AP has ShortPreamble support (which I think means it can do both, not just short, then can you explain why the 802.11g can not associate. He gets status code 19.

    Or is again, up to the vendor, as you stated in a previous email to me.

    Thanks

    Steve

  • The standard carefully describes the meaning of the "short preamble" bit in the capability field of management frames from clients and from access points. The client for itself says either "I can do short." or "I can not do short." The access point for the BSS says "All clients of this BSS must use short." or "All clients of this BSS must use long."

    The standard sternly warns about how older stations based solely on the long preamble PHY cannot transmit or receive the newer frames with short preamble. The implications for interoperability of multiple BSSs sharing a channel are dire but largely not spelled out and instead left to the imaginations of the analyst.

    All DSSS, HR/DSSS, and ERP PHYs can transmit and receive the older long preamble.

    DSSS PHYs cannot "do" short preamble, and neither read nor set the Short_Preamble bit of the capability field in management frames transmitted or received. DSSS PHYs blindly use long preamble. Regardless, protocol analyzers will likely decode the zero in that bit coming from DSSS stations as though it was purposely set.

    HR/DSSS PHYs may implement short preamble but do not have to. If they do not then they operate blindly with long preamble. Like DSSS such a HR/DSSS access point will blindly require "All clients of this BSS must use long." HR/DSSS PHYs that do implement short preamble then have to decide what policy to take when detecting not_short_capable PHYs.

    ERP PHYs must implement short preamble. They are all short_capable.

    When an access point in a using_short_here BSS gets an association request from a not_short_capable client it can either deny the association, or accept association and signal all clients in the BSS to use only long preamble. The standard offers this choice only indirectly then leaves it to the imagination of the reader and vendor regarding what course to take.

    One might think that a new access point denying association for old clients could be a complete solution, but it is not. Two BSSs operating in the same channel and space, one using only short and the other only long (because it includes some PHYs that can do only long), will not interoperate as is intended. The long_only PHYs will sense the RF energy from the short preamble frames but demodulate nothing. Virtual carrier sense (NAV) will not work as intended. Havoc may, or may not, ensue.

    It behooves a modern access point then to detect long preamble operating in the channel and sacrifice its own BSS performance by conforming to long.

    The good news is that with the passage of time the old equipment will be encountered less often. The mixed news is that when the old equipment is encountered the more modern likely response of a BSS is to go all_long_here. This accomplishes compatibility and reliability (good) at a cost of definite performance reduction (sad). (This is very similar to the challenges of ERP and nonERP stations interoperating at the cost of protection mechanisms.)

    Concerning your "next question", all ERP clients can do short preamble, so I have no explanation for why a trace would show one being denied association for not supporting short.

    I hope this helps. Thanks. /criss

Page 1 of 1
  • 1