• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 5 answers
  • Subscribers 41 subscribers
  • Views 827 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3235S: Reading Vendor Specific IE in Wi-Fi Beacon

Michael Zeng
Prodigy 140 points
Part Number: CC3235S
We want to inquire if the CC3235S and corresponding SDK supports this feature?
Our application is to read drone Remote ID data that is broadcast over Wi-Fi beacons. The international standard for drone Remote ID requires the actual data payload be contained in the Vendor Specific Information Element (Vendor Specific IE). Does the chip and SDK support reading the data contained in the Vendor Specific IE field in Wi-Fi beacons?
If not, is there another dual-band Wi-Fi chip that satisfies this requirement?
 
Thank you.
  • 0
    TI__Guru 63006 points

    You can get and parse the entire beacon in a transceiver mode (see chapter 13 in the programmer's guide).

    You can't get the information in a standard station mode.

  • 0 in reply to Kobi Leibovitch
    Prodigy 140 points

    Thank you, this is incredibly helpful. Reading through chapter 13 of the programmer's guide, I had a few more questions, would you be able to answer?

    Could you elaborate on the difference between SL_SOCK_RAW and SL_DOCK_DGRAM (section 13.3.1)?

    Since the transceiver mode only supports receiving from one channel at a time, if we want to develop a sniffer application that needs to scan multiple Wi-Fi channels, would we need to manually change channel periodically using sl_SetSockOpt()? What is the frequency at which we can switch channels? Is there a Wi-Fi sniffer sample that exists that uses transceiver mode?

    How should we determine whether need long or short preamble mode? Does the preamble mode impact receiving or only transmitting?

    What data rate is needed to scan for Wi-Fi beacons?

    Thank you again for your help.

    Michael

  • 0 in reply to Michael Zeng
    TI__Guru 63006 points

    you can also refer to chapters 6.5.3 and 6.5.4 that gives more info on the different raw modes.

     SL_SOCK_DGRAM (SL_AF_RF) sending and  receiving data packets (of specific Transport Layer protocol) on specific 802.11 channel when the device is not connected to the AP.

    With RAW socket you'll get all the packets (not just data) on a certain channel. If you want to see beacons this should be your choice.

    When using a transceiver socket, You need to switch the channel by the application. Since beacons are typically sent every 100-200 msec, this is probably the time you would like to scan each channel.

    Beacon are typically sent with one of the lower rates but you don't need to set the preamble mode and data rate for RX. Everything on the channel will be intercepted. The exact rate used is specified in the 8-byte proprietary header (SlTransceiverRxOverHead_t) that prefixes the packet.     

  • 0 in reply to Kobi Leibovitch
    Prodigy 140 points

    I see. Thank you! I just have one remaining question--if we want to scan all the channels in the 2.4 GHz band and 5.0 GHz band (that is 100+ channels), and we stay on each channel for ~100 msec, that means it would take a long time to cycle through every channel, which is unideal.

    Is there any Wi-Fi chip or any solution to be able to cycle through the channels faster, or to be able to receive on multiple channels (given that our goal is still to read the Vendor Specific IE of every beacon)?

  • 0 in reply to Michael Zeng
    TI__Guru 63006 points

    no. this is how scan is being performed (channel by channel). in total there are 44 channels (14 + 30) - so a full scan cycle may take less than 5 sec (assuming at least 102.4ms per channel).

    If you want to accelerate the cycle, you can use active scan (at least in non DFS channels) which mean you send a broadcast probe request and can expect  probe responses immediately after

    (in the 5GHz DFS and optional channels such as channels 12-14 - you are not allowed to transmit until you identify at least couple of beacons on the channel).

     

  • 0 in reply to Kobi Leibovitch
    Prodigy 140 points

    I see. Thank you for the response. Is it possible to do active scans in transceiver mode? If not, is it possible to use another mode that does active scans, request for the vendor specific information element in the probe request, and be able to read the vendor specific information element of the probe response?

    In addition, what makes you say there are 14+30 channels? Looking at the Wikipedia table of WLAN channels, I see channels 32-177 in the 5 GHz band that are available in the US. Is it that there are 30 different 5 GHz channels that are non-overlapping? I am not an expert in Wi-Fi so I could be wrong.

    For the 2.4 GHz band, is it possible to only scan channels 1, 6, and 11 (and still be able to receive any beacons that are broadcast on any of the 2.4 GHz channels)? I read that channels 1, 6, and 11 are non-overlapping but cover almost the entire frequency range.

    Also, I saw your response from the other thread (thank you for that). Are you able to elaborate more on SL_SOCK_RAW vs SL_SOCK_DGRAM? I'll keep all my future questions on this thread.

  • 0 in reply to Michael Zeng
    TI__Guru 63006 points

    When using transceiver mode (Domain is set to SL_AF_RF): 

    – SL_SOCK_RAW – Indicates an L1 mode raw socket (no respect for 802.11 medium access policy - CCA)

    – SL_SOCK_DGRAM – Indicates an L2 mode raw socket (respecting 802.11 medium access policies).

    You should be able to use both to get the beacons and probe responses and to transmit probe requests (for active scan). I believe you should prefer SL_SOCK_DGRAM  if you want to send the probe requests (as you will want the 802.11 Clear Channel Assessment functionality to be active). 

    See the following to find the 5G channels supported:

    /*
        - SL_WLAN_GENERAL_PARAM_OPT_SCAN_PARAMS_5G:
    \code
        SlWlanScanParam5GCommand_t ScanParamConfig5G;
        _u16 Option = SL_WLAN_GENERAL_PARAM_OPT_SCAN_PARAMS_5G;
        _u16 OptionLen = sizeof(SlWlanScanParam5GCommand_t);
        // 5.0G channels bits order: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132,
        //                          136, 140, 144, 149, 153, 157, 161, 165, 169, 184, 188, 192, 196 
        
        ScanParamConfig5G.ChannelsMask = 0x0000000F; // Select ChannelsMask for channels 36, 40, 44, 48 
        ScanParamConfig5G.RssiThreshold = -70;
        sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, Option, OptionLen, (_u8 *)&ScanParamConfig5G);
    \endcode
    <br>
*/

    if you only scan channels 1, 6, 11 - you may miss beacons on other channels as there will be a significant drop in RSSI (specifically in the non-adjacent channels such as 3,4,8,9). It is up to you to decide if the behavior is good enough for you.

  • 0 in reply to Kobi Leibovitch
    Prodigy 140 points

    Thank you Kobi. Do you know how to implement active scanning such that any probe responses that are returned to the scanner would contain the vendor specific IE, and such that I would be able to access the vendor specific IE data?

    In section 4.7.1 of the programming guide, I did find this: "Scan policy – Setting the scan policy triggers an immediate active scan (with no connection purpose), and the scan is performed on the enabled channels with a desired interval between scan cycles.", but it seems like the scan results do not contain the vendor specific IE.

    In addition, I'm not sure if you could answer this question, but in case you can help: Do all Wi-Fi devices respond to probe requests? In my specific application, I am trying to scan for Wi-Fi beacons broadcast by "broadcast modules", whose only job is to broadcast beacons and does not need to ever receive data or make a connection. Is it pointless to do an active scan on these devices?

  • 0 in reply to Michael Zeng
    TI__Guru 63006 points

    As we said before, if the regular scan results doesn't include the information you are looking for - you will need the transceiver mode to get the beacon (or probe response) to the host.

    Typically the probe responses contain all the information of a beacon. In some cases you should add vendor specific IE in the probe to get vendor-specific IE in the responses.

    As you mentioned, i can't comment about "broadcast modules". I don't think there is a standard for this and guess it depends on a specific implementation. If you know what you are looking for, you should be able to get more info from the vendor.

     

  • 0 in reply to Kobi Leibovitch
    Prodigy 140 points

    I'll try to clarify my question:

    I understand that the probe response should contain all the information of a beacon, including the vendor specific IE (in some cases, only if you add vendor specific IE to the probe request), but I'm still unsure about how to implement the software for this.

    This is the progress I've made so far: I've found that the programming guide shows that this command will do an active scan (section 4.7.3):

    Status = sl_WlanPolicySet(SL_WLAN_POLICY_SCAN, SL_WLAN_SCAN_POLICY(1,1),
(_u8*)&intervalInSeconds,sizeof(intervalInSeconds));

    And, the programming guide shows that this command will get the scan results:

    SlWlanExtNetworkEntry_t netExtEntries[30];
_i16 resultsCount = sl_WlanGetExtNetworkList(0,30,&netExtEntries[0]);

    However, according to the documentation for SlWlanExtNetworkEntry_t, this doesn't contain vendor specific IEs. In addition, neither of these functions have a feature to add vendor specific IE to the probe request.

    Am I looking at the wrong functions? What function should use that will add vendor specific IE to the probe request? What function should I use to retrieve vendor specific IEs from an active scan?

  • 0 in reply to Michael Zeng
    Guru 79985 points

    Hi Michael,

    No. As Kobi said you two times before, you cannot use internal scan API (sl_WlanGetExtNetworkList() or sl_WlanGetExtNetworkListEx()). You need to program scan routine by yourself using transceiver mode.

    Jan