• Hi.

    SSID is required and used in several attacks
    => Disabling beaconing frames is 1 way of hiding yr SSID

    upon auth and association, is the SSID being transmitted in the data frames transmitted to and fro the AP and clients?
    If this is so, Netstumbler would easily pick up the SSID?
    Too easy for attacker?

    Is there any way to prevent Netstumbler or Sniffer from picking up the SSID? Can we encrypt the SSID using any tools? Any layer2 encryption tools [Hardware or Software] available for this?

    Thank you very much.

  • All,

    How does one remove SSID from beacon and initialization vector (IV) so that it cannot be picked up in plain/unencrypted text?

  • Almost every vendor has a click-box in their GUI that allows you to remove the SSID from beacons and probe response frames. You will only have "weak IVs" if you have WEP enabled. If you have WPA/WPA2 enabled, you don't have to worry about that. You can't "disable IVs"


  • So even though you have WPA2 installed on an enterprise (Cisco), you cannot take the SSID out of the IV at all?

  • The SSID isn't in the IV.

    The SSID is a field in beacons, probe response frames, and several other management frames. The beacon can be removed from beacons and probe response frames by configuring the WLAN controller (or autonomous AP) that way in the CLI or GUI. Almost every vendor has this ability. It's also non-standard (not in compliance with 802.11-2007).

    The IV is the header part of the encryption wrapper when using WEP, TKIP, or CCMP. The data payload is encrypted, and an IV is placed before it (inside the payload section of the data frame). There is also a trailer.

    WEP = 4 octets for header (IV), 4 octets for trailer (ICV)

    TKIP = 8 octets for header (IV, ext IV), 12 octets for trailer (MIC - 8, ICV - 4)

    CCMP = 8 octets for header (IV, ext IV), 8 octets for trailer (MIC)


Page 1 of 1
  • 1