Wi-Fi® + Bluetooth® + 802.15.4 Knowledge Base

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Wi-Fi® + Bluetooth® + 802.15.4 Knowledge Base

讨论

排序依据:
A network is basically a set of devices connected to one another and communicating using wired or wireless mediums. There are several standard network frameworks defined for wired and wireless communication by IEEE. This post provides information about the IEEE 802 standard and network modes.   802 Standard The 802 standard is a family of IEEE standards dealing with local and metropolitan area networks. The protocol specified in the 802 standard covers lower two layers of the OSI model that are Physical and Data Link layers. In the 802 standard, the Data link layer (Layer 2 of the OSI model) has been divided into two parts Logical Link Control (LLC) and Media Access Control (MAC) as shown in figure below.   Figure 1. Layer architecture   The active 802 standards are listed below.   Table 1. 802 standards description Standard Name Description 802.1 Internetworking It ensures the management of the Local Area Network (LAN) / Metropolitan Area Network (MAN) network and monitors network capabilities. MAC bridging, data encryption/encoding, and network traffic management services are also provided. 802.3 Ethernet Ethernet based technology that is primarily used for LAN, it can also be used for MAN and Wide Area Network (WAN).     802.3 defines the Physical and MAC sublayer of the Data Link layer that is used in wired networks. Uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD) for collision detection. Data rates can be from 10Mbps to 10Gbps. 802.11 WLAN, Wi-Fi Wireless LAN uses high radio frequencies instead of cables to connect the devices in the network. Portability and setup cost is cheaper compared to wired networks but speed and security are better in wired communication. It uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) for collision avoidance. 802.15 WPAN This covers various protocol definitions for the personal area network like Bluetooth, ZigBee & sensors networks.   WLAN and Wi-Fi Introduction Wireless Local Area Network (WLAN) or Wireless LAN, is a network that links two or more devices using wireless communication to form a local area network within a limited area such as a home, campus, and office building. A WLAN can be built on various wireless technologies i.e. Wi-Fi, Infrared. Wi-Fi is a type of WLAN that follows IEEE 802.11 standards and one of the most commonly used WLAN today. Wi-Fi as a name for the standard is a trademark of the Wi-Fi Alliance. Wi-Fi or WLAN networks use radio waves to exchange information between devices. These radio waves are transmitted on specific frequencies - 2.4 GHz and 5 GHz, depending on the 802.11 standard (IEEE 802.11a/b/g/n/ac/ax) that the device uses. A Wi-Fi connection is established using a wireless adapter to create hotspots – areas in the vicinity of a wireless router that is connected to the network and allow users to access internet services. All Wi-Fi versions uses license free bands (ISM bands) across the globe.   Network Modes Ad-Hoc Mode In this mode wireless nodes communicate to peer nodes directly. It does not use Access Point (AP) instead it uses Mesh topology. It is also called peer to peer mode. An ad-hoc wireless network is more cost-effective than its alternative, since it does not require the installation of an AP to operate. In addition, it also needs less time to set up. Figure 2. Ad-Hoc mode   Infrastructure Mode In this mode, devices can communicate with each other first going through AP. In infrastructure mode, the wireless devices can communicate with each other or can communicate with a wired network as it’s communicating through AP. This mode is the most commonly used network mode. Compared to Ad-Hoc wireless networks, infrastructure mode offers the advantages of scale, centralized security management, and improved reach. Infrastructure mode has half throughput compared to Ad-Hoc mode.   Figure 3. Infrastructure mode   Repeater Mode When two wireless host devices have to be connected and the distance between them is long for the direct connection or obstruction is present, at that time repeater mode is used to bridge the gap. Repeater operates at the physical layer of the OSI model. As a Wireless Repeater, an AP node extends the range of the wireless network by repeating the wireless signal of the remote AP. The Ethernet MAC address of the remote AP is required for the AP to act as a wireless range extender. The repeater mode has certain drawbacks. Throughput is reduced by at least 50% as wireless interference is at least doubled. The bandwidth of any device connected to it is halved. This is due to the repeater receiving the signal, processing it, and then rebroadcasting it in both directions, from the router to the device and vice versa. The Repeater must be kept in the range of AP, but not too close to the AP. Distance between AP and repeater depends on the range of the AP and repeater should be kept in such a way that maximum possible area coverage can be achieved.   Figure 4. Repeater mode   Bridge Mode Bridge connects two or more networks to each other. It operates on the Data link layer of the OSI Model. Bridge mode allows the AP to communicate with another AP capable of point-to-point bridging. An example of this is connecting two buildings through a wireless connection.   Figure 5. Bridge mode
查看全文
In 802.11 standards, the connection procedure includes three major steps that shall be performed to make the device part of the Wi-Fi network and communicate in the network. Those three steps are device discovery (scanning), device authentication (checking compatibility-capability etc. before connection) and then finally establishment of connection (Association). Going forward, this post provides details for each step. The message exchange in connection procedure is shown below.   Figure 1. Connection Process in open system   Figure 2. Messages exchange in Connection Process   Figure 2 shows Wi-Fi sniffer log for messages exchange procedure between Client and AP device at the time of connection, here Client device is Xiaomi and AP is Marvell device.   Connection Setup Process 1. Scanning To join any network first client or station needs to find it the network. In the wired network, just plugging the cable or jack will find the network. In the wireless world, this requires identification of the compatible network before joining process can begin. This identification process of the network is referred as scanning. Several parameters are needed in the scanning process. These parameters are BSSType, BSSID, channel list, scantype, MinChannelTime and MaxChannelTime. The parameters are set as default depending upon manufacturer Wi-Fi driver, but it can be modified by the user i.e. if the requirement is for hidden network then we can set scantype parameter as passive scan because the active scan is not useful for the hidden network (networks that do not broadcast their SSID). There are two scanning methods, passive scanning and active scanning. By default, radios perform both the types of scanning on all the channels allowed by the country of operation.  While both the types of scanning are available by default, active scanning is performed only by those channels that are allowed to transmit by regional government regulations. Channels that are not authorized for unlicensed use are excluded from active scanning. Passive scan: In Passive Scanning, WLAN station moves to each channel as per the channel list and waits for beacon frames. Beacon frames are used by the access points (and stations in an IBSS) to communicate or to announce themselves. The access point tries to send the beacon at defined interval that is called Target Beacon Transmission Time (TBTT) Nevertheless, access points are just like the any wireless device in the cell. They cannot send if the network is busy. When the time comes for an AP to send a beacon & the network is busy, the AP will delay its beacon transmission until it can gain access to the media. In 802.11, network is busy or not can be checked using CSMA/CA protocol. In CSMA/CA when a frame is ready, the transmitting device checks whether the channel is idle or busy to avoid the collision. If the channel is busy the transmitting device will wait for random duration and check again whether the channel is idle or not. If channel is idle it will send the frame. The Beacon frame structure is as shown below.   Figure 3. Beacon Frame   Description of mandatory field of a Beacon Frame. Timestamp: After receiving the beacon frame, all the stations update their local clocks with this timestamp. This helps with synchronization. Beacon Interval: Represents the number of Time Units (TUs) between Target Beacon Transmission Times (TBTT). Default value is 100TU (102.4 milliseconds). Capability information: It contains information about capability of the device/network SSID: It contains Service set ID of the network. Supported rates: This field contains information of supported data rates by the access point. Notice that this information is not only used by potential clients during passive scanning but also by clients that are already associated to the BSS. A passive scan generally takes more time, since the client must listen and wait for a beacon versus actively probing to find an AP. Another limitation with a passive scan is that if the client does not wait long enough on a channel, then the client may miss an AP beacon.   Active scan: Discovering the network by scanning all possible channels and listening to beacons is not considered to be very efficient. To enhance this discovery process, stations often use what is called active scanning. In the active scanning mode, stations still go through each channel in turn, but instead of passively listening to the signals from AP, stations send a probe request management frame aimed at asking what network is available on this channel. If any AP or active station in an IBSS is presenting that frequency, they should answer with the probe response frame.   Figure 4. Scanning Methods   Once the probe request is sent by the emitting station, it starts a Probe Timer countdown and waits for answers. This Probe Timer value is usually a lot shorter than a beacon interval. Common values are in the 10-millisecond range. At the end of the timer, the station processes the answers it has received. If no answer was received, the station moves to the next channel (on different frequency) and repeats the same discovery process. The purpose of a probe request is typically to discover APs and their supported networks (SSIDs and/or BSSIDs).   Figure 5. Probe Request/Response Frame   This frame contains mainly two fields, the SSID and the rates supported by the mobile station. Stations that receive Probe Request use the information to determine whether the requesting station can join the network. The Probe Response frame fields are very similar to Beacon frame fields that enable mobile stations to match parameters and join the network.   2. Authentication After having performed a network discovery through the probe request/probe response exchange or by listening to beacons, a station wanting to join a network goes through an authentication process, exchanging authentication frames with the access point. On reception of the authentication frame, AP sends acknowledgement and then Authentication Response. The initial purpose of the ‘authentication’ frames to validate the device type, in other words, verify that the requesting station has proper 802.11 capabilities to join the network. Open system authentication: Information related to capabilities are exchanged between station and AP using Authentication Request. If request is accepted, AP sends “success” in Authentication Response. Shared key authentication: IEEE 802.11-1997 standard included a WEP shared key exchange authentication mechanism Called “Shared Key”. This shared key exchange adds two more frames to the default Open System authentication, resulting in a four-frame exchange. This latter method is called Shared Key authentication, requires the use of WEP encryption, and is not widely used (and not recommended) today. First phase of authentication is described above but when WPA or WPA2 is used then second phase of authentication (i.e. 4-way handshaking process) takes place after the device gets associated. The details regarding Open System authentication and Shared-Key authentication is available in 802.11 security post <Link TBD>.   Figure 6. Authentication frame   As shown above, the Authentication Frame consist of the following fields. Authentication Algorithm Number: 0 for Open System & 1 for Shared Key. Authentication Transaction Sequence Number: Indicate current state of progress. Status Code: 0 for Success & 1for Unspecified failures. Challenge Text: Used in Shared Key Authentication frame.   3. Association If the 802.11 authentication phase completes with a Success result, the station moves to the Association phase. The purpose of this exchange is for the station to join the network and obtain an Association ID [AID]. Association request: The first frame sent in the association phase is from the requesting station to the AP (or a station in an IBSS). This frame is the association request frame and the response of this frame is association response frame. Association request is unicast management frame and is always acknowledged.   Figure 7. Association Request   Association response: Once the Association request is acknowledged, the AP examine each field of the request & verify they all match its own 802.11 parameters (refer Figure 6). In case of parameter mismatch, AP checks whether the difference is a blocking or not and based on that AP sends authentication response. -    If the parameter difference is blocking, then response with status code 1 will be sent (to reject the association). -    In case of non-blocking difference/No difference in the parameters, response with status code 0(success) and AP’s own parameters will be sent to the requesting station. Station must be compatible with the AP’s capability otherwise it will drop the association process and start looking for another AP.   Figure 8. Association Response   Connection Teardown Disassociation: Once a station is associated to an AP, either side can terminate the association at any time by sending a disassociation frame. A station can send Disassociation frame before leaving the current network to roam/join another AP. An AP can send this frame in multiple cases like, if the station tries to use invalid parameters, AP itself under configuration change, hackers attack, etc. The disassociation frame (DA) can be the unicast MAC address of the station to disassociate or a broadcast address if the AP needs to disassociate all the stations in its network. In case of unicast frame, the frame will get acknowledge by receiving station and the broadcast frames are not acknowledged.   Figure 9. Disassociation Frame The Disassociation frame is quite small. It contains only one field “Reason code”. A disassociated station is still authenticated. It can try to re-associate by sending a new Association request frame, keeping its authenticated status. A station roaming to another cell may also choose to use a disassociation frame, to be able to keep its authenticated status and accelerate the process when roaming back to the same cell before its authentication timeout expires.   Figure 10. Disassociation Frame Exchange   This frame is also used when parameters change and the station or the AP needs to renegotiate the communications parameters.   De-authentication: The station or AP can also send a de-authentication frame. This frame is used when all communications are terminated, for example, because the AP has to reboot or because the station stops its Wi-Fi communications. It is also used when a frame is received before authentication has completed. For example, a station trying to send an association request or a data frame before having performed the authentication sequence then station will receive a Deauthentication frame from the AP, indicating that authentication must be performed first. The frame format is same as disassociation frame.   Figure 11. Deauthentication Frame Exchange   Roaming Roaming, in the context of an 802.11 wireless network, is the process of a client moving an established Wi-Fi network association from one access point to another access point within the same Extended Service Set (ESS) without losing connection (e.g. within a defined time interval, usually in the range of a few seconds). The roaming time should be smaller for the better performance. In the roaming process, the mobile device will send the disassociation frame to the previously associated Access Point (AP), and will start re-association process by exchanging 802.11 frames with another access point to which the device wants to connect. The client device scans the another AP then exchange authentication frames after that it will send re-association request, here instead of association re-association request is used and the first 2 steps of connection process remains the same.   Figure 12. Message Exchange in Roaming Process     Figure 13. Roaming representation   Wi-Fi APIs used in Connection and Disconnection process Table below shows some of the available APIs in NXP i.MX RT SDK for connection and disconnection process.   Table 1. APIs Available in SDK API Description Can be called from wifi_send_scan_cmd Used for scanning the available network. It supports only single SSID based scan. We can extend this to a list of multiple SSIDs. Station and AP wlan_add_network Add specific network profile to the list of known networks. Station and AP wlan_remove_network Remove specific network profile from the list of known networks. Station and AP wlan_connect Connect with specific network (AP). Station wlan_disconnect Disconnect the station from network (AP). Station wlan_start_network Start specific network. AP wlan_stop_network Stop specific network. AP   For more details on such APIs refer the document “MCUXpresso_SDK_WLAN_Driver_Reference_Manual.pdf” available at location <SDK Documentation>/docs/wifi.
查看全文
Different 802.11 standards are used in Wi-Fi and they differ in terms of operating frequency and data rates. This post provides information about the different terms used in Wi-Fi, 802.11 standards and the three types of 802.11 MAC frames.   Wi-Fi Standard basic terms Station (STA): Stations comprise of all devices that are connected to the wireless LAN. Station is any device that contains 802.11-compliant MAC and PHY interface to the wireless medium. A station may be a laptop, desktop PC, Access Point (AP) or smartphone. A station may be fixed, mobile or portable. Access Point (AP): An access point is a device that creates a wireless local area network. It has station functionality and provides access to the distribution services via the wireless medium. An access point is a device that allows Wi-Fi clients and Wi-Fi enabled routers to connect to a wired network. Access point connects to a wired router, switch or hub via an Ethernet cable and projects Wi-Fi signal to the defined area. An access point receives data by wired Ethernet, and converts to a 2.4GHz or 5GHz wireless signal. It communicates with nearby wireless clients. In a Wi-Fi network, wireless client communicate to other wireless clients via the AP. Client: A device that connects to a Wi-Fi (wireless) network. Any device that transmits and receives Wi-Fi signals, such as a laptop, printer, smartphone is a Wi-Fi client. Basic Service Set (BSS): A group of stations that are successfully synchronized for 802.11 communications. BSS contains one AP and one or more client stations. In BSS, stations have layer 2 connection with AP and are known as associated. Basic Service Set Identifier (BSSID): All basic service sets can be identified by a 48-bit (6-octet) MAC address known as the Basic Service Set Identifier (BSSID). The BSSID address is the layer 2 identifier of each individual basic service set. Most often the BSSID address is the MAC address of the access point. Distribution System (DS): A system that interconnects a set of basic service sets and integrated Local Area Networks (LANs) to create an Extended Service Set (ESS). It is used to extend wireless network coverage. Extended Service Set (ESS): In extended service set, one or more basic service sets are connected. An extended service set is a collection of multiple access points and their associated clients. Independent Basic Service Set (IBSS): An IBSS consists only of client stations that do peer-to-peer communications. An IBSS is a self-contained network that does not have an access point. SSID/ESSID: The logical network name of an Extended Service Set (ESS) is often called a Service Set Identifier (SSID). This name allows stations to connect to the desired network when multiple independent networks operate in the same physical area. Roaming: It is a process of a client moving from one access point to another access point within the same Extended Service Set (ESS) without losing connection. It is described in detail in 802.11 connection disconnection process post: [802.11] Wi-Fi Connection/Disconnection process .   Below figure shows DS, AP, Station, BSS, SSID, BSSID and ESS. Figure 1. Overview of Distribution system   802.11 Standards / Wi-Fi Generations 802.11 standard defines an over the air communication interface between the wireless base station and clients. The 802.11 family has various specifications and it has been categorized in several versions as shown in table below. Details of Wi-Fi generations with 802.11 specifications   Table 1. Wi-Fi Generation Overview Generation Technology Operating Frequency Data rates - 802.11b 2.4 GHz 1 - 11 Mbps - 802.11a 5 GHz Up to 54 Mbps - 802.11g 2.4 GHz Up to 54 Mbps Wi-Fi 4 802.11n 2.4 and 5 GHz Up to 600 Mbps Wi-Fi 5 802.11ac 2.4 and 5 GHz Up to 3.5 Gbps Wi-Fi 6 802.11ax 2.4 and 5 GHz Up to 9.6 Gbps   802.11b: This technology is focused on achieving higher data rates within the 2.4GHz ISM band and that is achieved by using a different spreading/coding technique called Complementary Code Keying (CCK) and modulation methods using the phase properties of the RF signal. 802.11b devices support data rates of 1, 2, 5.5 and 11 Mbps. 802.11a: This technology uses 5GHz frequency band. It supports data rate up to 54Mbps with the use of a spread spectrum technology called Orthogonal Frequency Division Multiplexing (OFDM). 802.11a can coexist in the same physical space with 802.11b and 802.11g devices as these devices are using different frequency ranges (5GHz and 2.4GHz respectively). 802.11g: This Technology is an enhancement of 802.11b Physical layer to achieve the greater bandwidth yet remain compatible with 802.11 MAC. The technology that was originally defined by the 802.11g amendment is called Extended Rate Physical (ERP), So the term ERP can be used in the place of 802.11g. Data rate differs with different 802.11g PHY technology, there are two mandatory ERP PHYs and two optional ERP PHYs. The First mandatory PHY technology called Extended Rate Physical-OFDM (ERP-OFDM) is used to achieve data rate up to 54Mbps. Second mandatory PHY technology called Extended Rate Physical DSSS (ERP-DSSS/CCK) is used to maintain backward compatibility and achieve data rate up to 11Mbps. ERP-PBCC and DSSS-OFDM are the two optional PHYs. ERP-PBCC PHY offers same data rates as the ERP-DSSS/CCK physical layer. It is used to provide higher performance in the range (the 5.5 and 11 Mbps rates) by using DSSS technology with Packet Binary Convolution Code (PBCC) scheme. DSSS-OFDM PHY is a hybrid combination of DSSS and OFDM. The transmission of packet physical header is done by DSSS, whereas the transmission of packet payload is performed by OFDM. Usage of this physical layer is to cover interoperability aspects. 802.11n: This Technology is an improvement of the 802.11 standard to get the higher throughput. 802.11n has a new operation known as High Throughput (HT) which provides MAC and PHY enhancements to provide data rates up to 600Mbps. 802.11n supports Multiple-Input Multiple-Output (MIMO) technology in unison with OFDM technology. MIMO uses multiple radios and transmitting and receiving antennas called radio chains. It capitalizes on the effects of multipath as opposed to compensating for or eliminating them. Transmit Beamforming can be used in MIMO system to steer beams & provide greater range & throughput. 802.11ac: Wi-Fi certified 802.11ac devices are dual band, operating in both 2.4 GHz and 5 GHz. 802.11ac is built on the foundation of 802.11n. 802.11ac devices use the 5 GHz band, while 802.11n products use the 2.4 GHz frequency band, so 802.11b and 802.11g compatibility can be achieved with 802.11ac. 802.11ac provides high-performance through Multi-User Multiple Input Multiple Output (multi-user MIMO), wider channels, and support for four spatial streams. 802.11ax: Wi-Fi certified 802.11ax provides improved data rates, power efficiency and support for eight spatial streams. Target Wake Time (TWT) feature helps to improve battery performance.   802.11 Frame types 802.11 frames are used for wireless communication and is much more involved because the wireless medium requires several management features and corresponding frame types that are not found in wired networks. There are three major frame types that are discussed below. For details regarding 802.11 layer architecture, please refer to [802.x.x] IEEE 802.x.x and Wi-Fi basics.   Management Frames Management frames are used by wireless stations to join and leave the basic service set. 802.11 management frame is also called Management MAC Protocol Data Unit (MMPDU). It has a MAC header, a frame body, and a trailer. It doesn’t carry any upper layer information. There is no MAC Service Data Unit (MSDU) encapsulated in the MMPDU frame body, it carries only layer 2 information fields and information elements, it does not carry higher layer (Layer 3 to 7 of OSI model) data. A management frame must have fixed length information fields and it may have information elements that are variable in length. Management/MMPDU frame body content depends on the sub type field, based on the sub type field it has payload like Status/Reason code, device capability information etc. Few of the management frames i.e. Beacon, Authentication, Association are described in the Connection setup process post [802.11] Wi-Fi Connection/Disconnection process. Below figure shows management frame structure.   Figure 2. Management Frame structure   Type field available in frame control field, that is set to 00 for the management frame. Management frames have 24-bytes long MAC header and header contains three addresses. DA field is the destination address of the frame, it can be broadcast or unicast depending upon frame subtype. SA field is MAC address of the station transmitting the frame. BSSID is MAC address of AP. Frame body is variable size. Size and content of the body depend on the management frame subtype.   Figure 3. Management Frame   Table 2. Management Frame description Frame SubType SubType Value [B7 B6 B5 B4] Initiator (AP/Station) Association request 0 Station Association response 1 AP Reassociation request 10 Station Reassociation response 11 AP Probe request 100 Station Probe response 101 AP/Station Beacon 1000 AP Announcement Traffic Indication Message (ATIM) 1001 Station (IBSS) Disassociation 1010 AP Authentication 1011 Station Deauthentication 1100 AP/Station Action 1101 AP/Station Action no ack 1110 AP/Station   Control Frames Control frames are associated with the delivery of data and management frames, it does not have a frame body. Control frames contain PHY, preamble, layer 2 header and trailer. Control frames can be transmitted at different data rates as they perform many different functions. All control frames use the same Frame Control field that is shown in the figure below.   Figure 4. Control Frame structure   Figure 5. Control Frame   The type field value for the control frame is 01 and subtype fields identify the function of a frame. Table below shows the different types of control frames.   Table 3. Control Frame description Subtype description Subtype value [B7 B6 B5 B4] Reserved 0000 - 0110 Control wrapper 0111 Block ack request (BlockAckReq) 1000 Block ack (BlockAck) 1001 PS-Poll 1010 RTS 1011 CTS 1100 ACK 1101 CF-End 1110 CF-End and CF-Ack 1111   Data Frames Data frames carry the higher level protocol data in the frame body. Data frames are categorized according to function. Total 15 sub types of data frames are defined in 802.11 standard. Type field value for the data frames is 10. One such distinction is between frame that carries data and frame that does not carry data (perform management function). Figure below shows data frame structure.   Figure 6. Data Frame structure   Figure 7. Data Frame   Each bit of the SubType field available in the frame control field has specific meaning as below. Bit 4 (B4): Changing it from 0 to 1 indicates the data subtype includes +CF-Ack. Bit 5 (B5): Changing it from 0 to 1 indicates the data sub type include +CF-Poll. Bit 6 (B6): Changing it from 0 to 1 indicates that the frame contains no data, specifically, that it contains no Frame Body field. Bit 7 (B7): Changing it from 0 to 1 indicates Quality of Service (QoS) data frame.   Data frames that appear only in the contention-free period can never be used in an IBSS. Below is the list of data frames.   Table 4.Data Frame Details Frame SubType SubType Value B7 B6 B5 B4 Consists Data Contention Free Service Data (simple data frame) 0 Yes No Data + CF-Ack 1 Yes Yes Data + CF-Poll 10 Yes Yes(AP only) Data + CF-Ack + CF-Poll 11 Yes Yes(AP only) Null 100 No It can be contention based and free both CF-Ack 101 No Yes CF-Poll 110 No Yes(AP only) CF-Ack + CF-Poll 111 No Yes(AP only) QoS Data 1000 Yes No QoS Data + CF-Ack 1001 Yes Yes QoS Data + CF-Poll 1010 Yes Yes(AP only) QoS Data + CF-Ack + CF-Poll 1011 Yes Yes(AP only) Qos Null 1100 No It can be contention based and free both QoS CF-Poll 1110 No Yes(AP only) QoS CF-Ack + CF-Poll 1111 No Yes(AP only)   References 802.11 Specification: https://ieeexplore.ieee.org/document/7786995 Certified Wireless Analysis Professional: https://www.oreilly.com/library/view/cwap-certified-wireless/9781118075234/ Community posts [802.x.x] IEEE 802.x.x and Wi-Fi basics   [802.11] Wi-Fi Connection/Disconnection process
查看全文
The article introduces steps on how to build RW612 zigbee source code, it includes the following contents: 1. Introduction 2. Preparation before compilation       2.1 CMake       2.2 Ninja       2.3 ARM GCC tool chain      2.4 Python3      2.5 MCUXPress SDK 3. Building Zibgee Source Code on ubuntu 20.04 host      3.1 Setting up environment      3.2 Compilation steps 4. Compilation on other ubuntu host      4.1 ubuntu 22.04      4.2 ubuntu 24.04 5. Verified ARM GCC Version 6. Programing QSPI Nor Flash   NXP TIC connectivity team  Weidong Sun May-15-2025
查看全文
If you are trying to flash your FRDM-RW612 and one of the following J-Link errors appears: Error 1: ****** Error: Verification failed @ address 0x18000000 Error while programming flash: Verify failed.   Error 2:  ****** Error: Verification failed @ address 0x08000000 Error while programming flash: Verify failed.   This can happen because of different reasons; the one I have addressed is when we flash a RD-RW612-BGA binary into FRDM-RW612. When doing this the board will get locked, and we will no longer be able to write data into the flash until we unlock it.  Please try the following:  1. Get MCUXpresso Secure Provisioning Tool 2. Create a New Workspace and select RW612 3. In Source executable image select i.e. "<path_to\>MCUX_Provi_v9\bin\_internal\data\sample_data\targets\RW612\source_images\frdmrw612_gpio_led_output.s19". Click on the check box of the Configuration Helper message that appeared and click OK. 4. Set your board in ISP mode; Connect the USB cable to your PC via J10 with the ISP (SW3) button pressed. 5. In the options of the tool please select RW612, UART (select the correct PORTx), Plain, Flex SPI NOR - complete FCB, InField shadow regs, No TrustProvi and PyOCD.   6. Click on Build Image 7. Move to Write Image section and click on Write Image 8. Once the example is flashed, the LED in the board should start to blink 9. Power reset your board and try flashing a MCUXpresso SDK hello_world    I hope this helps. Regards, Daniel.  
查看全文
In the context of TF-M(Trusted Firmware-M), BL2 refers to the second stage bootloader. When using TF-M, the BL2 is based on open-source MCUBoot. It is responsible for verifying and loading the secure and non-secure images.  Current configuration of our downstream TF-M examples do not support enabling BL2. The following steps demonstrate how to configure the TF-M project, so that it can be linked directly with MCUBOOT from the upstream repository without enabling BL2.  Before starting, import/clone the downstream ZSDK repo at https://github.com/nxp-zephyr/nxp-zephyr using the release tag  nxp-v4.0.0 .  These steps are using the JLink debug probe. Once the repository is ready build and flash the FRDM-RW612. west init -m https://github.com/nxp-zephyr/nxp-zsdk.git nxp_zephyr cd nxp_zephyr west update   Build and Flash MCUBoot from Downstream west build -b frdm_rw612 -d build-mcuboot bootloader/mcuboot/boot/zephyr –-pristine west flash -d build-mcuboot  After resetting the device, the output will be seen as image below. At this point there isn't any image in the primary or secondary slots, as expected MCUBoot will not find an application to jump to.   Build and Flash TF-M from Downstream Modify secure image Using a text editor of choice locate the following two files in the folder: nxp_zephyr\modules\tee\tf-m\trusted-firmware-m\platform\ext\target\nxp\frdmrw612\partition Open the flash_layout.h header file Edit the FLASH_IMAGE_HEADER_SIZE macro. Since we know that MCUBoot uses a header this will be equal to 0x400. #define FLASH_IMAGE_HEADER_SIZE (0x400) Open the region_defs.h header file  Edit the S_IMAGE_PRIMARY_PARTITION_OFFSET macro. Based on the calculated above, the offset used in this example of the primary image will be 0x20400. #define S_IMAGE_PRIMARY_PARTITION_OFFSET (0x20400) Edit the M_BOOT_FLASH_CONF_START macro. This should be the same as the base address being used in MCUBoot's BOOT_FLASH_ACT_APP. #define M_BOOT_FLASH_CONF_START (0x18020000)  Locate the hardware_init.c source file in: nxp_zephyr\modules\tee\tf-m\trusted-firmware-m\platform\ext\target\nxp\frdmrw612\project_template/s  Edit the SystemInitHook and add the VTOR configuration at the beginning of this function: extern void *__VECTOR_TABLE[]; SCB->VTOR = (uint32_t)&(__VECTOR_TABLE[0]); Locate the CMakeLists.txt to disable the boot header in: nxp_zephyr\modules\tee\tf-m\trusted-firmware-m\platform\ext\target\nxp\frdmrw612 target_compile_definitions(tfm_s PUBLIC BOOT_HEADER_ENABLE=0 )​​ Modify non-secure image Using a text editor of choice locate the following two files in the folder: nxp_zephyr\zephyr\build\tfm\api_ns\platform\partition Open the flash_layout.h header file Edit the FLASH_IMAGE_HEADER_SIZE macro. Since we know that MCUBoot uses a header this will be equal to 0x400. #define FLASH_IMAGE_HEADER_SIZE (0x400) Open the region_defs.h header file  Edit the S_IMAGE_PRIMARY_PARTITION_OFFSET macro. Based on the calculated above, the offset used in this example of the primary image will be 0x20400. #define S_IMAGE_PRIMARY_PARTITION_OFFSET (0x20400) Edit the M_BOOT_FLASH_CONF_START macro. This should be the same as the base address being used in MCUBoot's BOOT_FLASH_ACT_APP. #define M_BOOT_FLASH_CONF_START (0x18020000)  Locate frdm_rw612_rw612_ns.dts in: nxp_zephyr\zsdk\boards\nxp\frdm_rw612  Edit the partitions to accomodate the non-secure image in the correct location according to the shift done in the memory layout. This will move the non-secure image from offset A_0000 to C_0000. partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; /* Note slot 0 has one additional sector, * this is intended for use with the swap move algorithm */ slot0_ns_partition: partition@80C0000 { label = "image-0-nonsecure"; reg = <0x080C0000 0x083C0000>; }; /* This partition is reserved for connectivity firmwares storage * and shouldn't be moved. */ fw_storage: partition@400000 { label = "fw_storage"; reg = <0x400000 0x280000>; read-only; }; }; }; &flexspi { reg = <0x40134000 0x1000>, <0x080C0000 DT_SIZE_M(128)>; };​ Build image Build  image using pristine paramter: west build -b frdm_rw612//ns samples/tfm_integration/psa_crypto/ --pristine Merge Binaries The Zephyr ecosystem does in fact create a tfm_merged.hex. Currently it is not compatible with the modifications made in this guide, so as a short-term solution the following steps will manually merge the two individual binaries that are also generated in the previous build step and are found in the build folder of the project.  tfm_s.bin - Secure image located in nxp_zephyr\zephyr\build\tfm\bin zephyr.bin -Nonsecure image located in nxp_zephyr\zephyr\build\zephyr  Note: This article does not show detailed steps of using the SPSDK command line tool. If detailed steps are needed please refer to spsdk.readthedocs.io. Additionally, the SPSDK is not necessary to merge the binaries, it can also be done manually by pasting the non-secure image at offset shown below in secure image binary. Use the following command to generate the template to merge the binaries. nxpimage utils binary-image get-template -o binary_merge_template.yaml Edit the template. Calculate the offset of the location of the non-secure image using FLASH_S_PARTITION_SIZE from the flash_layout.h header file. In this example the value is 0x9FC00.   Use the following command to merge the binaries. nxpimage utils binary-image merge -c binary_merge_template.yaml -o merged_tfm_demo.bin Place the merged_tfm_demo binary in a known location to easily find and sign it in the following steps.   Sign Binaries There are several options available to sign the image. To avoid downloading additional programs, the following steps use the imgtool.py that can be found in zephyr repository. To sign the binary in the command line use: imgtool sign --version 1.0 --header-size 0x400 --pad-header --slot-size 0x440000 --max-sectors 800 --align 4 --pad --confirm --key "nxp_zephyr\bootloader\mcuboot\root-rsa-2048.pem" "\knownPath\merged_tfm_demo.bin" "\knownPath\signed_tfm_demo.bin"   Flash the TFM Signed binary Using Jlink Since the mcuboot image has already been flashed to the device. Lets flash the signed image using jlink directly. Assuming that Jlink has been installed to your PC. You can find jlink.exe at: C:\Program Files\SEGGER\JLink_V###\JLink.exe To connect to the device. > connect > RW612 > SWD > 4000 The primary slot is at 0x18020000 loadfile "\knownPath\signed_tfm_demo.bin" 0x18020000   Using MCUXpresso for VSCode Copy the signed_tfm_demo.bin to your build/zephyr path of your repository if you stored elsewhere. Right click on the project select Flash the Selected Target   Select the signed_tfm_demo.bin and enter the address to program the binary.In this case it will be 0x18020000 Console Output Reset the device to run the mcuboot application + the tfm demo. *** Booting MCUboot v2.1.0-rc1-233-g346f7374ff44 *** *** Using Zephyr OS build v4.1.0-rc1-35-gc031e127b0fd *** I: Starting bootloader I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Secondary image: magic=bad, swap_type=0x0, copy_done=0x2, image_ok=0x2 I: Boot source: none I: Image index: 0, Swap type: none I: Bootloader chainload address offset: 0x20000 I: Image version: v1.0.0 I: Jumping to the first image slot Booting TF-M v2.1.1 [INF] Beginning TF-M provisioning [WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [Sec Thread] Secure image initializing! Creating an empty ITS flash layout. Creating an empty PS flash layout. [INF][PS] Encryption alg: 0x5500200 [INF][Crypto] Provision entropy seed... [INF][Crypto] Provision entropy seed... complete. *** Booting Zephyr OS build nxp-v4.0.0 *** [00:00:09.058,779] <inf> app: app_cfg: Creating new config file with UID 0x55CFDA7A [00:00:10.092,276] <inf> app: att: System IAT size is: 367 bytes. [00:00:10.092,303] <inf> app: att: Requesting IAT with 64 byte challenge. [00:00:10.097,404] <inf> app: att: IAT data received: 367 bytes. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 D2 84 43 A1 01 26 A0 59 01 23 AA 3A 00 01 24 FF ..C..&.Y.#.:..$. 00000010 58 40 00 11 22 33 44 55 66 77 88 99 AA BB CC DD X@.."3DUfw...... 00000020 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000030 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000040 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000050 EE FF 3A 00 01 24 FB 58 20 A0 A1 A2 A3 A4 A5 A6 ..:..$.X ....... 00000060 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 ................ 00000070 B7 B8 B9 BA BB BC BD BE BF 3A 00 01 25 00 58 21 .........:..%.X! 00000080 01 4E 62 2B 02 F1 1A 68 BD 16 A3 44 CD 21 78 6D .Nb+...h...D.!xm 00000090 41 F6 F0 66 B7 C0 CA B9 CE FF CB 58 2C 70 C2 52 A..f.......X,p.R 000000A0 27 3A 00 01 24 FA 58 20 AA AA AA AA AA AA AA AA ':..$.X ........ 000000B0 BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC ................ 000000C0 DD DD DD DD DD DD DD DD 3A 00 01 24 F8 3A 3B FF ........:..$.:;. 000000D0 FF FF 3A 00 01 24 F9 19 30 00 3A 00 01 24 FE 01 ..:..$..0.:..$.. 000000E0 3A 00 01 24 F7 71 50 53 41 5F 49 4F 54 5F 50 52 :..$.qPSA_IOT_PR 000000F0 4F 46 49 4C 45 5F 31 3A 00 01 25 01 77 77 77 77 OFILE_1:..%.wwww 00000100 2E 74 72 75 73 74 65 64 66 69 72 6D 77 61 72 65 .trustedfirmware 00000110 2E 6F 72 67 3A 00 01 24 FC 73 30 36 30 34 35 36 .org:..$.s060456 00000120 35 32 37 32 38 32 39 2D 31 30 30 31 30 58 40 50 5272829-10010X@P 00000130 EA 50 C2 2A 43 83 D2 48 DC 35 75 36 97 F6 43 4C .P.*C..H.5u6..CL 00000140 98 BA BE 1E 24 F3 F5 23 6A 08 34 2B 0B 59 7A F1 ....$..#j.4+.Yz. 00000150 C6 C3 2E 1B CC E8 57 51 F3 0A C7 99 7E 91 DE FB ......WQ....~... 00000160 18 EE 55 D5 6D 49 D6 D4 6C 3A 3C 5E 9F 7E 47 ..U.mI..l:<^.~G [00:00:10.287,009] <inf> app: Persisting SECP256R1 key as #1 [00:00:10.434,117] <inf> app: Retrieving public key for key #1 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 04 3B E8 D6 DE DF BE 17 E4 C5 EC 80 8E 79 8D DE .;...........y.. 00000010 50 9C A6 28 D1 9D DA 83 E1 90 21 01 0D 17 77 E2 P..(......!...w. 00000020 D6 AD C7 84 11 C1 16 CA 2B 81 4F 58 0E A0 EF 6C ........+.OX...l 00000030 89 CE 9C 3E F7 F2 D3 8D D7 56 FE 3C C0 88 E3 EC ...>.....V.<.... 00000040 49 I [00:00:10.486,689] <inf> app: Calculating SHA-256 hash of value 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 50 6C 65 61 73 65 20 68 61 73 68 20 61 6E 64 20 Please hash and 00000010 73 69 67 6E 20 74 68 69 73 20 6D 65 73 73 61 67 sign this messag 00000020 65 2E e. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 9D 08 E3 E6 DB 1C 12 39 C0 9B 9A 83 84 83 72 7A .......9......rz 00000010 EA 96 9E 1D 13 72 1E 4D 35 75 CC D4 C8 01 41 9C .....r.M5u....A. [00:00:10.535,947] <inf> app: Signing SHA-256 hash 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 C0 01 00 60 0F 91 B2 7C 45 23 27 78 2E DC E4 D5 ...`...|E#'x.... 00000010 EB A3 00 A5 36 AD E3 07 4A 77 F8 8C 8F 53 B2 D5 ....6...Jw...S.. 00000020 A0 D4 87 F6 E9 81 A8 8D 48 6F 41 8A 7E 66 3B D2 ........HoA.~f;. 00000030 43 17 FC 28 BD 48 54 80 0F 85 7A AD EB 6D 7E D7 C..(.HT...z..m~. [00:00:10.582,417] <inf> app: Verifying signature for SHA-256 hash [00:00:10.604,945] <inf> app: Signature verified. [00:00:10.741,295] <inf> app: Destroyed persistent key #1 [00:00:10.747,691] <inf> app: Generating 256 bytes of random data. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 DA CD 89 21 56 F4 0A F8 46 F9 17 1B A2 3F 47 63 ...!V...F....?Gc 00000010 1E DC 08 3E 77 1E 4F 2D 0A 6F 0B 95 FF 12 2E BD ...>w.O-.o...... 00000020 1E CA 6E 0F 07 21 A1 B1 FB E1 EE C6 25 FF 8A 3D ..n..!......%..= 00000030 C3 9E D0 6E E1 DA 2B 44 C3 64 EF D1 DF 9C 41 B1 ...n..+D.d....A. 00000040 26 BE 1E 9A 6A F6 CC 90 1D E1 26 A7 70 A8 90 F9 &...j.....&.p... 00000050 E6 54 EB 08 2B B8 A6 D4 5C 4D B7 0F 2A 60 E3 B2 .T..+...\M..*`.. 00000060 63 99 E6 35 4D C8 A3 32 EA DF BE CD F6 C6 77 7E c..5M..2......w~ 00000070 40 41 7D DB 9C AD 48 96 C6 EA 36 2C 9B F6 62 F5 @A}...H...6,..b. 00000080 55 CE 74 62 83 F2 93 A5 4A 1D 8E 16 0B 7C 0F A7 U.tb....J....|.. 00000090 80 07 0C 35 44 08 EF 45 F8 E3 47 A8 CE 1A 5B C2 ...5D..E..G...[. 000000A0 75 F0 F9 AF E9 4C A7 E8 70 25 0E BC E6 76 70 1E u....L..p%...vp. 000000B0 0D E7 83 51 22 1F 1F B8 05 59 7F B6 B5 E0 43 95 ...Q"....Y....C. 000000C0 9E 2C C7 D1 09 BA FD BF E2 F5 26 97 6B 07 0D 60 .,........&.k..` 000000D0 15 3A 63 32 D8 28 C2 6E 16 31 C9 B1 4E D6 1E B4 .:c2.(.n.1..N... 000000E0 D3 F5 74 78 C0 3E B0 6F E3 98 C8 EE F2 19 ED 99 ..tx.>.o........ 000000F0 A7 39 E2 2E 87 C0 BD A7 C0 03 2C 96 B2 67 50 38 .9........,..gP8 [00:00:10.865,339] <inf> app: Initialising PSA crypto [00:00:10.870,839] <inf> app: PSA crypto init completed [00:00:10.876,564] <inf> app: Persisting SECP256R1 key as #1 [00:00:11.025,601] <inf> app: Retrieving public key for key #1 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 04 D9 A2 50 5E 46 60 72 AC E5 80 10 E6 4D 6D 0D ...P^F`r.....Mm. 00000010 B5 02 AB FC 7A 07 3E 98 74 D4 F0 EC 4F 83 D8 47 ....z.>.t...O..G 00000020 49 D0 A3 E8 0C 14 7E 24 79 A3 15 F6 37 77 4C E1 I.....~$y...7wL. 00000030 48 95 7A A6 78 8A E6 60 32 C8 64 BC B2 0F 55 B4 H.z.x..`2.d...U. 00000040 A4 . [00:00:11.078,458] <inf> app: Adding subject name to CSR [00:00:11.084,291] <inf> app: Adding subject name to CSR completed [00:00:11.090,857] <inf> app: Adding EC key to PK container [00:00:11.097,031] <inf> app: Adding EC key to PK container completed [00:00:11.103,883] <inf> app: Create device Certificate Signing Request [00:00:11.129,706] <inf> app: Create device Certificate Signing Request completed [00:00:11.137,653] <inf> app: Certificate Signing Request: -----BEGIN CERTIFICATE REQUEST----- MIHpMIGQAgEAMC4xDzANBgNVBAoMBkxpbmFybzEbMBkGA1UEAwwSRGV2aWNlIENl cnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2aJQXkZgcqzlgBDm TW0NtQKr/HoHPph01PDsT4PYR0nQo+gMFH4keaMV9jd3TOFIlXqmeIrmYDLIZLyy D1W0pKAAMAoGCCqGSM49BAMCA0gAMEUCIQCvq1EVicUgZyv80QV4T/sqhYiI9jbq 3feb7bcfImCU9QIgAt5ATTnQUan9zKasUVxBeHAdorHo+dW9oj86wdM1v4I= -----END CERTIFICATE REQUEST----- [00:00:11.178,921] <inf> app: Encoding CSR as json [00:00:11.184,360] <inf> app: Encoding CSR as json completed [00:00:11.190,364] <inf> app: Certificate Signing Request in JSON: {"CSR":"-----BEGIN CERTIFICATE REQUEST-----\nMIHpMIGQAgEAMC4xDzANBgNVBAoMBkxpbmFybzEbMBkGA1UEAwwSRGV2aWNlIENl\ncnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2aJQXkZgcqzlgBDm\nTW0NtQKr/HoHPph01PDsT4PYR0nQo+gMFH4keaMV9jd3TOFIlXqmeIrmYDLIZLyy\nD1W0pKAAMAoGCCqGSM49BAMCA0gAMEUCIQCvq1EVicUgZyv80QV4T/sqhYiI9jbq\n3feb7bcfImCU9QIgAt5ATTnQUan9zKasUVxBeHAdorHo+dW9oj86wdM1v4I=\n-----END CERTIFICATE REQUEST-----\n"} [00:00:11.233,581] <inf> app: Done.
查看全文
This article explains how to implement a custom profile from both server and client side using the NXP BLE stack for the RT1060.   Generic Attribute Profile To fully understand the procedure of how to implement a custom profile in this platform, we must understand the BLE basics. The GATT (Generic Attribute Profile) will help us establish in detail the way server and client exchanges data over a BLE connection. All standard BLE profiles are based on GATT and must comply with it to operate correctly. This means that if we want to have a successful connection and data transfer in our application, we must follow all the GATT procedures successfully. GATT roles: Server: This device will store the data to be transported or send and accepts the GATT requests, commands and confirmations from the client. Client: This device will access the data on the remote GATT server with operations such as read, write, notify or indicate. Figure 1. GATT Client-Server model   GATT database defines a type of hierarchy to organize attributes. These are named as Profile, Service, Characteristic and Descriptor. The structure is shown in Figure 2. The profile is a high level definition that determines the behavior of the application as a whole. For example, a Temperature Sensor profile. This profiles are defined by at least one service. The service defines a specific functionality for the device (e.g. battery service). The next level in the structure is the characteristic. The service is defined by one or more characteristics that hold individual measurements, control points or other kind of data. Finally we find descriptors. Characteristics have descriptors that defines how characteristics have to be accessed to read or write information. Figure 2. GATT database structure   Creating a New Profile With the GATT basics understood, we can start developing the code for our custom profile. In this case we will create a potentiometer custom profile. It will read the voltage drop of the potentiometer and send that value to the client every 5 seconds. Please note that in this document we will dismiss all the ADC initialization, the voltage value will be simulated. For time saving purposes, we will use the peripheral_ht and central_ht SDK examples structure to create this project. This means that the peripheral is going to be the server, the device that has the information. And the central will be the client, the device that gets the information. In case you don’t want to start this application from a SDK example, it is highly recommended to keep the same structure as in the examples, so if you would like to add your custom profile to an existing application, you have to prepare the project environment so all the new files where your service is declared is allocated in a specific path and avoid problems in the compiling process. For the case you want to add a new service to your project, it will be needed to create two folders called services and add our service files inside it. The first folder must be in the following route: ${ProjName}/edgefast/bluetooth/include/bluetooth. Inside this folder let´s create a new header file called pot.h. Note that if you are using the examples, you already have these folders so you only need to create the files. In this file we will declare the new UUID´s for our potentiometer service and the service characteristic. In this example we are declarin one profile, one service and one characteristic. To define a 128-bit UUID we are going to be using the macros available in the uuid.h file. The declarations will look like this: #define POTENTIOMETER_SERVICE_UUID 0xAA, 0x1C, 0x12, 0x5E, 0x40, 0xEE, 0xA1, 0xF1, 0xEE, 0xF4, 0x5E, 0xBA, 0x22, 0x33, 0xFF, 0x00 #define POTENTIOMETER_CHARACTERISTIC_UUID 0xAA, 0x1C, 0x12, 0x5E, 0x40, 0xEE, 0xA1, 0xF1, 0xEE, 0xF4, 0x5E, 0xBA, 0x22, 0x33, 0xFF, 0x01 #define POTENTIOMETER_SERVICE BT_UUID_DECLARE_128(POTENTIOMETER_SERVICE_UUID) #define POTENTIOMETER_CHARACTERISTIC BT_UUID_DECLARE_128(POTENTIOMETER_CHARACTERISTIC_UUID)   In this case we are declaring a service with the 128-bit service UUID and a characteristic with its 128-bit characteristic UUID. These macros are helping us to declare a struct bt_uuid according to a specific UUID. The other service folder must be allocated in the following route: ${ProjName}/edgefast/bluetooth/source. Inside this folder we have to create a new source file called pot.c (for simplicity we will use the same #include as in hts.c). There are important configurations and declarations we need to have in this file like the read function callback and the service declaration. It will look something like this: static uint8_t pot_level = 0x01U; /* Read function */ static ssize_t read_plvl(struct bt_conn *conn, const struct bt_gatt_attr *attr, void *buf, uint16_t len, uint16_t offset) { uint8_t lvl = pot_level; pot_level ++; /* Voltage level simulation */ return bt_gatt_attr_read(conn, attr, buf, len, offset, &lvl, sizeof(lvl)); } /* Potentiometer Service Declaration */ BT_GATT_SERVICE_DEFINE(pot, /* Name of the service */ BT_GATT_PRIMARY_SERVICE(POTENTIOMETER_SERVICE), /* Primary sevice UUID */ BT_GATT_CHARACTERISTIC(POTENTIOMETER_CHARACTERISTIC, BT_GATT_CHRC_READ | BT_GATT_CHRC_NOTIFY, BT_GATT_PERM_READ, read_plvl, NULL, NULL), /* Potentiometer characteristic */ BT_GATT_CCC(NULL, BT_GATT_PERM_READ | BT_GATT_PERM_WRITE), /* Client Characteristic Configuration Descriptor */ );   As you can see we have this variable called pot_level. This variable is the one that has the “sensed” voltage drop of the potentiometer. In this case it is a simulated value. Every time a device requests for the voltage value, pot_level­ is increased by 1. We are also defining the potentiometer service with the macro BT_GATT_SERVICE_DEFINE. The name of our service is “pot” and we are defining the properties, permissions and the read callback for our service. We have finished with these two files and there is no need to modify them again. These files are used for both server and client. Finally we need to include the new folder´s to the project path. Once again, note that if you are using the examples, this step is not needed. To do this we have to open the project properties, and go to Settings of the C/C++ Build option. In the MCU C Compiler, we have to select the Includes folder and add the previous two paths. Figure 3. Path including We should be able the compile our service files without problem. Let’s start the server code.   Server: We already have out service declared and now we have to create two new files that are going to handle the connections. We will be basing this part in the peripheral_ht SDK example. The new files should be allocated in the following route: ${ProjName}/source. These files are potentiometer.c and potentiometer.h. In the header file we will declare our potentiometer task, that is going to be our main task: void potentiometer_task(void *pvParameters);   In the source file we will need to include the pot.h and potentiometer.h files and declare some new information. Use peripheral_ht.c as a base. We have to create and define the advertising and response packets, the connection callbacks and functions related to the connection. We are going to start declaring the connection variable: static struct bt_conn *default_conn;   The advertising packet will have the following structure: static const struct bt_data ad[] = { BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)), BT_DATA_BYTES(BT_DATA_UUID128_SOME, POTENTIOMETER_SERVICE_UUID), };   We are creating an advertising packet that is general discoverable and Bluetooth basic rate/enhanced data rate is not supported, we are also including the potentiometer service UUID. The response packet will have the following structure: #define DEVICE_NAME "pot" #define DEVICE_NAME_LEN (sizeof(DEVICE_NAME) - 1) static const struct bt_data sd[] = { BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN), };   The response packet only has the device name, which in this case is pot. static void connected(struct bt_conn *conn, uint8_t error) { char addr[BT_ADDR_LE_STR_LEN]; struct bt_conn_info info; bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr)); if (error) { PRINTF("Failed to connect to %s (err %u)\n\r", addr, error); } else { error = bt_conn_get_info(conn, &info); /* Getting connection info */ if(error) { PRINTF("Failed to get info\n\r"); return; } default_conn = conn; PRINTF("Connected to: %s\n\r", addr); } } static void disconnected(struct bt_conn *conn, uint8_t reason) { PRINTF("Disconnected (reason 0x%02x/n", reason); if(default_conn) { bt_conn_unref(default_conn); default_conn = NULL; } } static struct bt_conn_cb conn_callbacks = { .connected = connected, .disconnected = disconnected, };   Let’s keep up with the code. The connected function is going to run when a device is successfully connected to our server, and the disconnected function is going to restore the connection to NULL every time a device gets disconnected. static void bt_ready(int error) { char addr_s[BT_ADDR_LE_STR_LEN]; bt_addr_le_t addr = {0}; size_t count = 1; if (error) { PRINTF("Bluetooth init failed (error %d)\n", error); return; } PRINTF("Bluetooth initialized\n\r"); bt_conn_cb_register(&conn_callbacks); /*Start advertising*/ error = bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd)); if (error) { PRINTF("Advertising failed to start (error %d)\n", error); return; } bt_id_get(&addr, &count); bt_addr_le_to_str(&addr, addr_s, sizeof(addr_s)); PRINTF("Advertising as %s\n\r", addr_s); } void potentiometer_task(void *pvParameters) { int error, result; PRINTF("BLE POTENITOMETER [Server] Custom Profile Running...\n\r"); error = bt_enable(bt_ready); if(error) { PRINTF("Bluetooth init failed (error %d)\n\r", error); return; } while(1) { } }   In the main task, we are going to initialize the BLE components, and then bt_ready is going to run. If the BLE initialization was correct, the advertising will start using the previous advertising and response packets. We will use xTaskCreate to create our new potentiometer task in the main file. Notice that this is the only task created in the main file. The server is done, we can get connected to it and start to receive the potentiometer voltage. But as we want two boards connected working in each role, we will also need to modify the code for the client. In the app_config.h file there should be the following macro defined. #define CONFIG_BT_PERIPHERAL 1​   Client: To create the Client part, we will be basing on the central_ht SDK example. We need to create a new file to handle the connections and initializations like we did before in the server. This file is going to have some similar functions to potentiometer.c. I will be using the same name for simplicity purposes. We need to import the potentiometer service by adding the the pot.c and pot.h files we did on previous steps. First thing to do is create the new variables. static struct bt_conn *default_conn; static struct bt_uuid_128 uuid = BT_UUID_INIT_128(0); static struct bt_gatt_discover_params discover_params; static struct bt_gatt_read_params read_params; static uint8_t connection_success; static uint8_t data_received;   Using central_h.c as reference, we need to modify some functions as it follows: static uint8_t read_func(struct bt_conn *conn, uint8_t err, struct bt_gatt_read_params *params, const void *data, uint16_t length) { if ((data != NULL) && (err == 0)) { data_received = *(uint8_t*)data; PRINTF("Read successful - Pot voltage level: %d\n\r", data_received); } else { PRINTF("Read Failed\n\r"); } return BT_GATT_ITER_STOP; } static int bt_get_pot_lvl(void) { return bt_gatt_read(default_conn, &read_params); } static uint8_t discover_func(struct bt_conn *conn, const struct bt_gatt_attr *attr, struct bt_gatt_discover_params *params) { int32_t err; if (!attr) { PRINTF("Discover complete, No attribute found \n\r"); (void)memset(params, 0, sizeof(*params)); return BT_GATT_ITER_STOP; } if (bt_uuid_cmp(discover_params.uuid, POTENTIOMETER_SERVICE) == 0) { /* Potentiometer service discovered */ /* Next, Potentiometer characteristic */ PRINTF("POT service UUID found: 0x"); for(int i = 0; i<sizeof(BT_UUID_128(POTENTIOMETER_SERVICE)->val) ; i += sizeof(uint16_t)) { PRINTF("%X", uuid.val[i]); PRINTF("%X", uuid.val[i + 1]); } PRINTF("\n\r"); memcpy(&uuid, POTENTIOMETER_CHARACTERISTIC, sizeof(uuid)); discover_params.uuid = &uuid.uuid; discover_params.start_handle = attr->handle + 1; discover_params.type = BT_GATT_DISCOVER_CHARACTERISTIC; err = bt_gatt_discover(conn, &discover_params); if (err) { PRINTF("Discover failed (err %d)\n\r", err); } } else if(bt_uuid_cmp(discover_params.uuid, POTENTIOMETER_CHARACTERISTIC) == 0) { PRINTF("POT characteristic UUID found: 0x"); for(int i = 0; i<sizeof(BT_UUID_128(POTENTIOMETER_CHARACTERISTIC)->val) ; i += sizeof(uint16_t)) { PRINTF("%X", uuid.val[i]); PRINTF("%X", uuid.val[i + 1]); } PRINTF("\n\n\r"); /* Read Potentiometer */ read_params.func = read_func; read_params.handle_count = 0; /* Selects the UUID characteristic handle */ read_params.by_uuid.start_handle = 0x0001; read_params.by_uuid.end_handle = 0xffff; read_params.by_uuid.uuid = &uuid.uuid; /* Potentiometer characteristic */ err = bt_gatt_read(conn, &read_params); if(err) { PRINTF("Read failed (err %d)\n\r", err); } else { connection_success = 1; } return BT_GATT_ITER_STOP; } return BT_GATT_ITER_STOP; }   The read_func function is going to be the callback for the read parameters. The bt_get_pot_level function is going to use the read parameters to read the potentiometer value. The discover_func function is going to find every advertising device in the advertising channel. In this function we are going to force the connection to the potentiometer service, so if there is one device advertising with the potentiometer service UUID, we will verify if it has the characteristic we are interested in. In this case the potentiometer charactersic, and if this device also has this characteristic, we are going to read the data. static void connected(struct bt_conn *conn, uint8_t conn_err) { char addr[BT_ADDR_LE_STR_LEN]; int32_t err; bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr)); if (conn_err) { PRINTF("Failed to connect to %s (err %u)\n\r", addr, conn_err); bt_conn_unref(default_conn); default_conn = NULL; /* Restart scanning */ scan_start(); return; } PRINTF("Connected to peer: %s\n\r", addr); if (conn == default_conn) { memcpy(&uuid, POTENTIOMETER_SERVICE, sizeof(uuid)); discover_params.uuid = &uuid.uuid; discover_params.func = discover_func; discover_params.start_handle = 0x0001; discover_params.end_handle = 0xffff; discover_params.type = BT_GATT_DISCOVER_PRIMARY; /* Start service discovery */ err = bt_gatt_discover(default_conn, &discover_params); if (err) { PRINTF("Discover failed(err %d)\n\r", err); } else { PRINTF("Starting service discovery\n\r"); } } } ​   In the device_scanned function we are going to create a connection with the server, so we need to compare the UUID we are scanning and check if there is a device with the potentiometer service UUID. static bool device_scanned(struct bt_data *data, void *user_data) { bt_addr_le_t *addr = user_data; struct bt_uuid_128 uuid_temp; int err; int i; char dev[BT_ADDR_LE_STR_LEN]; bool continueParse = true; /* return true to continue parsing or false to stop parsing */ switch (data->type) { case BT_DATA_UUID16_SOME: break; case BT_DATA_UUID16_ALL: break; case BT_DATA_UUID128_SOME: { if (data->data_len % sizeof(uint16_t) != 0U) { PRINTF("AD malformed\n\r"); return true; } uuid_temp.uuid.type = BT_UUID_TYPE_128; for(i = 0; i < data->data_len ; i += sizeof(uint32_t)) { uuid_temp.val[i] = data->data[i]; uuid_temp.val[i + 1] = data->data[i + 1]; uuid_temp.val[i + 2] = data->data[i + 2]; uuid_temp.val[i + 3] = data->data[i + 3]; } /* Search for the Potentiometer Service in the advertising data */ if ((bt_uuid_cmp(&uuid_temp.uuid, POTENTIOMETER_SERVICE) == 0)) { /* found the Potentiometer service - stop scanning */ err = bt_le_scan_stop(); if (err) { PRINTF("Stop LE scan failed (err %d)\n", err); break; } bt_addr_le_to_str(addr, dev, sizeof(dev)); PRINTF("Found device: %s\n\r", dev); /* Send connection request */ err = bt_conn_le_create(addr, BT_CONN_LE_CREATE_CONN, BT_LE_CONN_PARAM_DEFAULT, &default_conn); if (err) { PRINTF("Create connection failed (err %d)\n", err); scan_start(); } continueParse = false; break; } break; } /*CASE UUDI128_SOME*/ default: { break; } } return continueParse; }   The device_found stays very similar to the example, we are just deleting the PRINTF’s functions because we don’t want to see every device found, we are just interested in our server. static void device_found(const bt_addr_le_t *addr, int8_t rssi, uint8_t type, struct net_buf_simple *ad) { /* We're only interested in connectable events */ if (type == BT_GAP_ADV_TYPE_ADV_IND || type == BT_GAP_ADV_TYPE_ADV_DIRECT_IND) { bt_data_parse(ad, device_scanned, (void *)addr); } } ​   The scan_start and disconnected stays the same. static int scan_start(void) { struct bt_le_scan_param scan_param = { .type = BT_LE_SCAN_TYPE_PASSIVE, .options = BT_LE_SCAN_OPT_NONE, .interval = BT_GAP_SCAN_FAST_INTERVAL, .window = BT_GAP_SCAN_FAST_WINDOW, }; return bt_le_scan_start(&scan_param, device_found); } static void disconnected(struct bt_conn *conn, uint8_t reason) { PRINTF("Disconnected reason 0x%02x\n\r", reason); int32_t err; connection_success = 0; if (default_conn != conn) { return; } bt_conn_unref(default_conn); default_conn = NULL; /* Restart scanning */ err = scan_start(); if (err) { PRINTF("Scanning failed to start (err %d)\n\r", err); } else { PRINTF("Scanning started\n\r"); } }   The bt_ready is almost the same. static void bt_ready(int error) { if (error) { PRINTF("Bluetooth init failed (error %d)\n\r", error); return; } PRINTF("Bluetooth initialized\n\r"); bt_conn_cb_register(&conn_callbacks); /*Scan Starting*/ error = scan_start(); if(error) { PRINTF("Scanning failed to start (error %d)\n\r", error); return; } PRINTF("Scanning started\n\r"); }   The last thing we are going to modify is the potentiometer task. We are going to read the potentiometer value every 5 seconds. void potentiometer_task(void *pvParameters) { int error, result; PRINTF("BLE POTENITOMETER [Client] Custom Profile Running...\n\r"); error = bt_enable(bt_ready); if(error) { PRINTF("Bluetooth init failed (error %d)\n\r", error); return; } while(1) { vTaskDelay(pdMS_TO_TICKS(5000)); if(connection_success) { error = bt_get_pot_lvl(); } } }   Finally, we need to add some macros to enable some scanning and discover functions, please confirm you do have them defined in the preprocessor or another file like app_config.h : #define CONFIG_BT_OBSERVER 1 #define CONFIG_BT_CENTRAL 1 #define CONFIG_BT_GATT_CLIENT 1   Please take in mind that if there are other BT macros defined in the app_config.h file that weren’t mentioned in this article, the example may not run as expected. Additional modifications might be needed to make it work.   Testing To test this application we are going to use the following: 2 x RT1060 EVK (Client and Server) AW-CM358-uSD (88W8987) AW-AM457-uSD (IW416)   Take in mind that to run BT and BLE applications there might be some connections or reworking needed in your board and wireless module. For more information take a look to the Hardware Rework Guide for EdgeFast BT PAL document. It is important to take in mind the version of EVK that we will be using since there might be some differences in the supported modules. In this case, the test is with the A revision of the RT1060 EVK.   Figure 4.  Server and client application running   Figure 5. Terminal output of the server (IW416)   Figure 6. Terminal output of the client (88W8987)
查看全文
The document is for 88w9098 users who is running lower version of linux kernel. just a reference for them. Driver version:      PCIE-WLAN-UART-BT-9098-U16-X86-17.68.1.p81-17.26.1.p81-MXM5X17277_V0V1-MGPL   NXP global CAS connectivity team Weidong Sun 12-29-2021
查看全文
802.11 Security This post covers the following topics: 802.11 authentication processes Open System Authentication Shared Key Authentication Encryption methods Wired Equivalent Privacy (WEP) Temporal Key Integrity Protocol (TKIP) Cipher Block Chaining Message Authentication Code (CBC-MAC) Protocol or CCM mode protocol (CCMP) WPA/WPA2/WPA3 Robust Security Network (RSN) 802.1X authorization framework Extensible Authentication Protocol (EAP) 4-way handshake process Authentication Authentication is the second step required for connecting to the 802.11 Basic Service Set (BSS). Authentication and association must occur between Access Point (AP) and client. The 802.11 authentication establishes an initial connection between the client and the access point, basically validating or authenticating that the station (STA) is a valid 802.11 device for AP. The 802.11 standard specifies two methods for the authentication: Open System authentication and Shared Key authentication. Open System authentication: In this type of authentication, client and AP exchange authentication frames, total two frames exchange in this process. It occurs after a client STA detects an Access Point (AP) by either passive or active scanning. The client node that wants to join the network initiates the authentication process by sending first message. The first message contains the sending node’s 802.11 capabilities. In the response, authentication result is received. If the authentication is successful, then the client and AP will be declared mutually authenticated. The client cannot make the association request if it is not authenticated. Once the Open System authentication and association is successful, the client becomes a member of the BSS. Figure 1. Open System authentication Wired Equivalent Privacy (WEP) encryption is optional with Open System authentication. For data privacy, WEP encryption can be used with Open System Authentication. In other words, WEP is not used as part of the Open System authentication process, but WEP encryption can be used to provide data security after a successful authentication and association. Shared Key Authentication: Shared Key authentication utilizes four authentication messages exchange between client and AP. Shared Key authentication uses WEP encryption to authenticate the client. The four authentication messages are described below. The client sends the authentication request to the AP. The AP sends a clear-text challenge to the client station using an authentication response frame. The client station then encrypts the clear-text challenge and sends it back to the AP by using the frame body of the authentication frame. The AP decrypts the station’s response and compares it to the challenge text. If it matches, the AP will send the final authentication frame to the client and confirms the successful authentication. Once the Shared Key authentication is successful, the same static process will be used to encrypt the 802.11 data frames. This Shared Key authentication has security risks. If someone captures the clear-text challenge phrase and then captures the encrypted challenge phrase in the response frame, then could potentially derive the static WEP key. If the static WEP key is compromised, now all the data frames can be decrypted. Figure 2. Shared Key Authentication WLAN Encryption Methods The 802.11 standards define three encryption methods. These methods are used to encrypt the MAC Service Data Unit (MSDU) payload of the data frame. 802.11i specification divides security algorithm in two types that are Robust Security Network Association (RSNA) and Pre-RSNA. RSNA: This type of security algorithm consists of two protocols for the data confidentiality, as mentioned below. Temporal Key Integrity Protocol (TKIP) Counter Mode with Cipher Block Chaining Message Authentication Code (CBC-MAC) Protocol or CCM mode Protocol (CCMP) Both of these protocols are discussed in detail in later section of this post. Pre-RSNA: This type of security consists of authentication methods as mentioned below. Wired Equivalent Privacy (WEP) 802.11 entity authentication WEP: Wired Equivalent Privacy protocol works on second layer of the OSI model. It utilizes RC4 algorithm for the encryption. Originally in 802.11 standard, 64-bit WEP and 128-bit WEP were defined as supported encryption methods. Figure 3. WEP Encryption Process WEP encryption process is explained below. WEP Concatenates Initialization Vector (IV) and Secret Static key, the combination of the same is used as seed to Pseudo random number generator, as a result of this the keystream is generated. WEP runs Cyclic Redundancy Check (CRC) on plain-text that generates Integrity Check Value (ICV). Cipher text is generated after applying RC4 c to the generated Key stream and ICV. The final encrypted message is made by attaching the IV in front of the Cipher text. TKIP: As the security failures found in WEP, enhancement of WEP is introduced and that is known as TKIP. As per the 802.11i specification, TKIP uses 128 bits long key for encryption. TKIP is a combination of various algorithms wrapping WEP to offer the best security that can be obtained for the WEP-based devices. Below algorithms are added to WEP: New Initialization Vector sequencing to protect against replay attacks. A cryptographic 64-bit Message Integrity Check (MIC also called Michael) for the integrity of data. Per-packet key mixing (secret key and IV) function to de-correlate IVs from weak keys. Rekeying mechanism to provide fresh encryption. In WEP, Secret Static key has to be set manually so refreshing/rekeying is not the scope there, but in TKIP key rekeying mechanism is there, and that is why it can dynamically modify the keys within wireless LANs. This dynamic key is Pairwise Transient Key (PTK) for unicast traffic and Group Temporal Key (GTK) for multicast/broadcast traffic generated through 4-way handshake. Refer section 4-way handshake for more details. CCMP: Counter mode with Cipher-Block Chaining Message Authentication Code protocol (CCMP) is mandatory for RSN compliance. The AES Counter with CBC-MAC (CCM) process uses the same key for encrypting the MSDU payload and provides for a cryptographic integrity check. WEP and TKIP use RC4 and CCM uses the AES block cipher. Although AES is capable of using different key sizes, but when it is implemented as part of the CCMP encryption method, CCM combines the Counter mode (CTR) and Cipher-Block Chaining Message Authentication Code (CBC-MAC) for data confidentiality and for authentication and integrity respectively. New temporal key for every session, and a unique nonce value for each frame protected by a given temporal key is required by CCM, it also uses a 48-bit packet number (PN) for this purpose. Reusing the PN with the same temporal key nullifies all security guarantees. WPA/WPA2/WPA3: Wi-Fi Protected Access (WPA) is the evaluation of WEP. Wi-Fi Protected Access 2 (WPA2) is improvisation for WPA, and same way WPA3 is improvised version of WPA2. WPA is introduced by Wi-Fi alliance in order to achieve better security in network. WPA: When WEP was used, it was relatively easy to break the security, so the Wi-Fi Alliance developed WPA to give network connections an additional layer of security. The WPA certification only required support for TKIP/RC4 dynamic encryption key generation, but the numbers of attacks were done on TKIP. The Beck-Tews attack can recover the MIC and the plain text from an encrypted packet; it can also inject forged frames. These attacks are not used to recover the encryption key but instead are used to recover the MIC checksum that is used for packet integrity. These exploits can usually be prevented by changing TKIP settings as keying intervals on a WLAN controller or AP, or the better solution is to stop using TKIP and upgrade to CCMP with AES. WPA2: The Wi-Fi Alliance revised the previous WPA specification to WPA2, to ensure better security incorporated the CCMP/AES cipher. So, the only practical difference between WPA and WPA2 has to do with the encryption cipher. WPA and WPA2 both use the Pre-Shared Key (PSK) authentication method; however, WPA specifies TKIP/RC4 encryption, and WPA2 specifies CCMP/AES. WPA2 integrates the AES algorithm in CCMP, providing more reliable security compared to previous encryption methods. WPA2 is backward compatible with WPA and it supports 802.1X/EAP authentication or pre-shared keys. WPA and WPA2 have two options for authentication, the personal mode and the enterprise mode. Personal Mode: The personal mode is based on key-sharing to avoid installing an authentication server, so it’s used for Small Office Home Office (SOHO) cases. Enterprise Mode: The enterprise mode is based on using an authentication server (802.1X/EAP frameworks) such as RADIUS in order to offer access control. Note: WPA is vulnerable to attacks in both, personal and enterprise modes. WPA3: WPA3 is the latest generation of Wi-Fi security and provides cutting-edge protocols for security. It has been built on the bases of the WPA2, to simplify security in Wi-Fi. Previous versions of WPA uses PSK authentication method but WPA3 uses Simultaneous Authentication of Equals (SAE). Because of SAE WPA3-Personal networks that are configured with weak/simple passphrase are not that easy to crack using attack like brute-force. In case someone determines/guess the passphrase, it is not possible to examine the exchange and get the session keys; so even if passphrase is guessed, snoop on someone’s WAP3-Personal traffic is not possible. WPA3 is backward compatible with WPA2 devices, it is a mandatory for Wi-Fi CERTIFIED devices. There are two versions of WPA3: WPA3-Personal WPA3-Enterprise WPA3-Personal: This version provides password-based authentication, even when users choose short or weak passwords good security is maintained. It doesn’t require an authentication server and is the basic protocol for home users and small businesses use. Uses 128-bit encryption. Makes use of a Simultaneous Authentication of Equals (SAE) handshake that protects against brute force attacks. Incorporates Forward Secrecy means that a new set of encryption keys are generated every time a WPA3 connection is made, so if the initial password is compromised, security won’t be compromised. WPA3-Enterprise: WPA3 Personal and WPA3-Enetrprise don’t have much difference but the Enterprise version is more secure compared to Personal version. As the enterprise version is focused on large enterprises and protect more sensitive data compare to SOHO cases. 192-bit security mode, this optional mode specifies configuration for cryptographic component to maintain overall network security. WPA3 Personal is not the most secure option but it is easier to deploy and use than the WPA3 Enterprise. Robust Security Network (RSN) Robust security network association requires two 802.11 stations to establish procedures to authenticate and associate with each other and create dynamic encryption keys through the 4-Way Handshake process. Any two stations must share dynamic encryption keys that are unique between those two stations. CCMP/AES encryption is the mandatory encryption method, and TKIP/RC4 is an optional encryption method. When RSN security associations are used within a BSS, there are two keys that both the devices install. Each client has unique encryption key that is shared with the access point. That key is Pairwise Transient Key (PTK) used to encrypt unicast traffic. There is a Group Temporal Key (GTK) shared between all the associated devices with the AP. It is used to encrypt multicast and broadcast traffic. All the client stations have undergone a unique RSNA process called the 4-Way Handshake, this process will be discussed in detail later in this post. Refer Figure 4 below for the better understanding of key sharing between the AP and clients.   Figure 4. RSN security in BSS RSN security in IBSS The 802.11 standard also defines a WLAN topology known as an Independent Basic Service Set (IBSS). In this topology multiple client stations in one physical area communicating in an ad-hoc pattern. All the stations within the IBSS goes through the 4-Way Handshaking process with each other, because of peer to peer communication within the IBSS. Each station has the unique dynamic TKIP/RC4 or a CCMP/AES PTK; when the station connects to another station within the IBSS the same key is shared between them. Each stations defines its own GTK, the same is used for broadcast/multicast transmissions within the IBSS. Each station will use the 4-Way Handshake process or the Group Key Handshake to generate GTK and distribute it to the peer stations. To seed the 4-way handshake, PSK authentication is used within the IBSS. So, whenever a client joins the IBSS, (for both the traffic types, unicast and multicast/broadcast). Refer to Figure 5 below that represents RSN in an IBSS. Figure 5. RSN security in IBSS RSNIE: Robust Security Network Information Element (RSNIE) is a field present in 802.11 management frame, this field is used to identify RSN security. An information element is an optional field of variable length that can be found in like beacon management frames, probe response frames, association request frames, and re-association request frames. For details on different frames refer the [802.11] Wi-Fi Basic concepts. The RSN information element indicates if the authentication used is 802.1X/EAP or pre-shared key (PSK). 802.1X authorization framework The 802.1X is a port based access control standard which provides an authorization framework. The Authorization Framework involves three components to ensure only valid users and devices can access the network: Supplicant, Authenticator, and Authentication Server. In 802.1X framework, Extensible Authentication Protocol (EAP) is used to validate users at layer 2 (of OSI model). Supplicant: A host with software requests authentication and access to network. Authentication server verifies authentication credentials that are unique for each supplicant. Laptop or wireless handheld device trying to access the network is used as supplicant in WLAN. Supplicant can communicate with authentication server using EAP protocol. The supplicant is not allowed to communicate with the upper layers (layer 3 to 7 of OSI model) until authentication server (at layer 2) validates supplicant’s identity. Authenticator: Traffic is allowed or blocked to pass through Authenticator’s port. Authenticator allows Authentication traffic to pass through it, while all other traffic is allowed after supplicant’s identity is verified. The authenticator maintains two virtual ports. Uncontrolled port: Used for EAP traffic. Controlled port: Used for all other traffic. Initially, only port that is open and passing traffic is the uncontrolled port. A successful 802.1X authentication opens controller port so that other traffic can traverse the network. Usually, AP or a WLAN controller is used as the authenticator in WLAN. The authenticator plays intermediator role by passing messages between supplicant and the authentication server. Authentication server provides guest list services to authenticator. When AP or WLAN controller is configured as authenticator, one should consider authenticator as authentication server. Authentication Server: Credentials of the supplicant (requesting access and notifies the authenticator) is validated by Authentication server. User database is maintained by authentication server, or external user database(s)can be requested to authenticate user credentials. EAP authentication protocol is used to communicate between the authentication server and the supplicant. The 802.1X standard defines the authentication server as a RADIUS server, when configuring a RADIUS server, you need to be able to point the authentication server back in the direction of the authenticator.  Figure 6. Components of 802.1X   EAP Extensible Authentication Protocol(EAP) is a layer 2 (of OSI model) protocol. Some EAP are proprietary and others are standards. EAP-MD5 provides only one-way authentication, while EAP TLS, EAP-LEAP provide two-way authentication (also called mutual authentication). Mutual authentication requires that the client credentials are validated by authentication server and that the validity of the authentication server is authenticated by supplicant. EAP protocol is used within an 802.1X framework. The EAP messages are encapsulated in EAP over LAN (EAPOL) frames. EAPOL is used between the supplicant and the authenticator, but the EAPOL encapsulation is translated to EAP in RADIUS between the authenticator and the authentication server, as described in Figure 6. EAPOL messages are described below.   Table 1. EAPOL Message Description Packet type Name Description 0000 0000 EAP-Packet This is an encapsulated EAP frame. The majority of EAP frames are EAP-Packet frames. 0000 0001 EAPOL-Start This is an optional frame that the supplicant can use to start the EAP process. 0000 0010 EAPOL-Logoff This frame terminates an EAP session and shuts down the virtual ports. Hackers sometimes use this frame for denial-of-service (DoS) attacks. 0000 0011 EAPOL-Key This frame is used to exchange dynamic keying information. For example, it is used during the 4-Way Handshake. 0000 0100 EAPOL- Encapsulated - ASF- Alert This frame is used to send alerts, such as Simple Network Management Protocol (SNMP) traps to the virtual ports. Supplicant and the authentication server use the EAP protocol to communicate with each other at layer 2. An is between the Supplicant and Authentication server devices. When the controlled port is open, upper layers 3–7 of the OSI model can pass the traffic through it. Once the controlled port is open DHCP is used for Dynamic IP addressing. Figure 7 shows generic EAP message exchange process. Figure 7. Generic EAP messages exchange flow 4-Way Handshake The 4-Way Handshake exchange four EAPOL-Key frame messages between authenticator and supplicant, that is used to generate Pairwise Transient Keys (PTK) for encryption of unicast transmissions and a Group Temporal Key (GTK) for encryption of broadcast/multicast transmissions. Terminologies used in 4-way handshake are listed below. AP/Authenticator Nonce (Anonce): Random number generated by authenticator. Station/Supplicant Nonce (SNonce): Random number generated by supplicant. Master Session Key (MSK): First key that is generated during the 802.1X/EAP authentication or derived from PSK authentication. This key information is sent via a secure channel from Authenticating Server to Authenticator. Pairwise Master Key (PMK): This key is generated based on MSK (PMK is first 256bits (0-255) of MSK) and will be used as one of the input to generate the PTK.PSK (Pre-Shared Key) will be the PMK for the WPA2/PSK security. Group Master Key(GMK): This key is also generated from the MSK and is used to generate the GTK. Authenticator device creates this key and refreshes it at the configured time interval to reduce the risk of GMK being compromised. Pairwise Transient Key(PTK): This key is used to encrypt unicast traffic between the AP and a client station. This key is unique between a client and AP. It is generated using below equation. PTK = PRF (PMK + ANonce + SNonce + MAC Address of Authenticator + MAC Address of Supplicant) Here, PRF is a pseudo-random function that applies to all the input. Group Temporal Key(GTK): As PTK is used to encrypt unicast traffic, GTK is the key used to encrypt multicast and broadcast traffic between clients and AP. For each access point different GTK will be there, and with be shared with devices connected to AP. This key is derived on Authenticator and shared with supplicant during 4-way handshake (Message 3). Figure 8 below shows message exchange in 4-way handshake. Figure 8. 4-Way Handshake message exchange In the case of PSK, 4-Way handshake starts just after Open System Authentication and if it is 802.1X/EAP, 4-way handshake starts once EAP authentication is completed. Figure 9 shows the sniffer log of the 4-Way Handshake process, here Marvell device is authenticator, and Xiaomi device is supplicant. Each message exchanged in this process is described below in detail. Figure 9. Key Exchange Procedures in 4-Way Handshake Message 1: This message is sent from authenticator to supplicant. It carries ANonce. Once supplicant receives this message it can generate the PTK. Message 2: This message is sent from supplicant to authenticator. As the supplicant generated the PTK, now it will send SNonce to AP(authenticator), so this second message carries SNonce, RSN information element capabilities and Message Integrity Check (MIC) is set. The MIC is used to check that the received message is not corrupted. Once authenticator receives this message it will generate the PTK, validate MIC and generate GTK. Message 3: This message is sent from authenticator to supplicant. It carries ANonce, Authenticator’s RSN information element capabilities and MIC is set. GTK is also delivered and it is encrypted using PTK. This message is for supplicant to install temporal keys. Message 4: This message is sent from supplicant to authenticator. Final EAPOL-Key frame is sent to authenticator to confirm that temporal keys have been installed. Once this process gets completed all the messages after that will be encrypted using PTK or GTK (based on unicast or broadcast message).
查看全文
HCI Application is a Host Controller Interface application which provides a serial communication to interface with the KW40/KW41/KW3x/QN9080 BLE radio part.   It enables the user to have a way to control the radio through serial commands.   The format of the HCI Command Packet is composed by the following parts.   Figure 1. HCI Command Packet   Each command is assigned a 2 byte Opcode which is divided into two fields, called the OpCode Group Field (OGF) and OpCode Command Field (OCF).   The OGF uses the upper 6 bits of the Opcode, while the OCF corresponds to the remaining 10 bits.   The OGF of 0x3F is reserved for vendor-specific debug commands. The organization of the opcodes allows additional information to be inferred without fully decoding the entire Opcode.    For further information regarding this, please check the BLUETOOTH SPECIFICATION Version 5.0 | Vol 2, Part E, 5.4 EXCHANGE OF HCI-SPECIFIC INFORMATION.    This document will guide you through the implementation of custom HCI commands in the KW36, but it can be applied as well for the rest of the NXP Bluetooth LE MCU’s that support HCI.   The following changes were made and tested in the FREEDOM KW38 and will generate a continuous with both channel and power configurable.      You will need to perform the following changes to the HCI black box demo.   Modify the hci_transport.h public constants and macros section by adding:       #define gHciCustomCommandOpcodeUpper (0xFC90) #define gHciCustomCommandOpcodeLower (0xFC00) #define gHciInCustomVendorCommandsRange(x) (((x) <= gHciCustomCommandOpcodeUpper) && \ ((x) >= gHciCustomCommandOpcodeLower))‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍       In this case, the opcodes 0xFC90 to 0xFC00 are not used by our stack. These opcodes meet the requirements for vendor specific commands (OCF = 3F).   Then you will need to declare the handler for the custom command.       void Hcit_InstallCustomCommandHandler(hciTransportInterface_t mCustomInterfaceHandler);‍‍‍‍‍         In the  hcit_serial_interface.c modify the following :   Add in the private memory declarations section       static hciTransportInterface_t mCustomTransportInterface = NULL;‍‍‍‍‍     Change the Hcit_SendMessage as it is shown:       static inline void Hcit_SendMessage(void) { uint16_t opcode = 0; /* verify if this is an event packet */ if(mHcitData.pktHeader.packetTypeMarker == gHciEventPacket_c) { /* verify if this is a command complete event */ if(mHcitData.pPacket->raw[0] == gHciCommandCompleteEvent_c) { /* extract the first opcode to verify if it is a custom command */ opcode = mHcitData.pPacket->raw[3] + (mHcitData.pPacket->raw[4] << 8); } } /* verify if command packet */ else if(mHcitData.pktHeader.packetTypeMarker == gHciCommandPacket_c) { /* extract opcode */ opcode = mHcitData.pPacket->raw[0] + (mHcitData.pPacket->raw[1] << 8); } if(gHciInCustomVendorCommandsRange(opcode)) { if(mCustomTransportInterface) { mCustomTransportInterface( mHcitData.pktHeader.packetTypeMarker, mHcitData.pPacket, mHcitData.bytesReceived); } } else { /* Send the message to HCI */ mTransportInterface( mHcitData.pktHeader.packetTypeMarker, mHcitData.pPacket, mHcitData.bytesReceived); } MEM_BufferFree( mHcitData.pPacket ); mHcitData.pPacket = NULL; mPacketDetectStep = mDetectMarker_c; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍       Implement the registration of the handler     void Hcit_InstallCustomCommandHandler(hciTransportInterface_t mCustomInterfaceHandler) { OSA_EXT_InterruptDisable(); mCustomTransportInterface = mCustomInterfaceHandler; OSA_EXT_InterruptEnable(); return; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍        Once those changes are done, we will need to modify the  hci_black_box.c with the following changes.    Add the files to support HCI Custom commands.       #include "hci_transport.h" #include "fsl_xcvr.h"‍‍‍‍‍‍‍‍‍‍       Define the custom commands, in this case, we will create some to turn ON/OFF the continuous wave as well as to set up the channel and power.        //@CC custom command #define CUSTOM_HCI_CW_EVENT_SIZE (0x04) #define CUSTOM_HCI_EVENT_SUCCESS (0x00) #define CUSTOM_HCI_EVENT_FAIL (0x01) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍     Also, adding some app auxiliar variables      static uint16_t channelCC = 2402; static uint8_t powerCC = 0x3E;       Create the custom event packet        uint8_t eventPacket[6] = {gHciCommandCompleteEvent_c, CUSTOM_HCI_CW_EVENT_SIZE, 1, 0, 0, 0 };‍‍‍‍‍       In the main_task() after the BleApp_Init() register the callback for the custom commands.       /* Initialize peripheral drivers specific to the application */ BleApp_Init(); //Register the callback for the custom commands. Hcit_InstallCustomCommandHandler(BleApp_CustomCommandsHandle);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍       Once that it’s added, add the handler for the command       bleResult_t BleApp_CustomCommandsHandle(hciPacketType_t packetType, void* pPacket, uint16_t packetSize) { uint16_t opcode = 0; uint8_t error=0; switch(packetType) { case gHciCommandPacket_c: opcode = ((uint8_t*)pPacket)[0] + (((uint8_t*)pPacket)[1] << 8); if (opcode >= 0xfc00 & opcode <= 0xfc50) { channelCC = 2400+(opcode - 0xfc00); eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else if (opcode <= 0xfc70) { powerCC = (opcode-0xfc50)*2; if (gXcvrSuccess_c ==XCVR_ForcePAPower(powerCC) eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; else eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } else if (opcode == 0xfc80) { if (gXcvrSuccess_c == XCVR_DftTxCW(channelCC*1000000)) { eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } else if(opcode == 0xfc90) { XCVR_ForceTxWd(); /* Initialize the PHY as BLE */ XCVR_Init(BLE_MODE, DR_1MBPS); eventPacket[5] = CUSTOM_HCI_EVENT_SUCCESS; } else { eventPacket[5] = CUSTOM_HCI_EVENT_FAIL; } eventPacket[3] = (uint8_t)opcode; eventPacket[4] = (uint8_t)(opcode >> 8); Hcit_SendPacket(gHciEventPacket_c, eventPacket, sizeof(eventPacket)); break; default: break; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍}     The format of this HCI command is: 01 XX FC 00 Where: When 0<=XX<=50: set the transmitting channel. The transmitting frequency is (2400+XX (in hexadecimal) )*1000MHz When 50<xx<70: set the transmitting power. 51 is the minimum Tx power and 69 corresponds to the maximum Tx power. When XX = 80: start the CW transmission When XX = 90: Stop the CW transmission   For example, if you want to transmit a CW on the frequency 2420MHz at maximum frequency, you should send the following command: 01 14 FC 00 01 69 FC 00 01 80 FC 00   whenever you want to change the channel or Tx power, please stop the ongoing Tx first by sending 01 90 FC 00 Then repeat the previous step.   If you want to add some parameter to it, please consider that the fourth byte of the packet will correspond to the number of parameters to enter and you will need to indicate it there. 
查看全文
This document summary BT classical RF parameters and give examples of nxp wif&bt product Bluetooth rf test and results analysis. The document includes:  Introduction BT key parameters Test Procedure & Result Analysis
查看全文
Learn how to bring Wi-Fi connectivity to Zephyr’s projects based on the FRDM-RW612 board. This guide walks you through adapting the Ethernet-based mqtt_publisher sample to work over Wi-Fi using Zephyr v4.2.0. You'll explore the built-in wifi/shell example, configure the networking stack, and create a custom shell command to control MQTT publishing. Perfect for developers building IoT applications that need seamless cloud communication over wireless networks.
查看全文
Hardware : i.MX8MN-EVK Wi-Fi module on the board is 88W8987. Software: BSP is i.MX Yocto Linux BSP L6.12.3_1.0.0.   Topics: Introduction of Wi-Fi driver configuration file : wifi_mod_para.conf  How to load the Wi-Fi driver How to configure the WPA2/WPA3  5G/2G connection How to use wpa_supplicant to connect to the AP Introduction of some wpa_supplicant.conf parameters    
查看全文
Hardware board : NXP i.MX8MN-EVK  Wi-Fi module on the board is 88W8987. Software : BSP is i.MX Yocto Linux BSP L6.12.3_1.0.0.   Topic: Wi-Fi driver configuration :  wifi_mod_para.conf file How to load the Wi-Fi driver How to use hostapd to configure the 2G connection (uap0) How to start the uap0 2G connection How to use hostapd to configure the 5G connection (uap0) How to start the uap0 5G connection uap0 + ethernet connection    
查看全文
The article will introduce the following contents. No.1 Preparation          1. Ubuntu 20.04 Host          2. Downloading Mass Market Driver(FP92)source code No.2 For ARM Platform          1. Toolchain For cross compilation          2. Linux Kernel source code of target board          3. Building Linux Kernel source code of target board          4. Building NXP Wi-Fi Mass Market Driver source code No.3 For X86 Platform          1. Compilation on different ubuntu version 1.1 Ubuntu 16.04 LTS 1.2 Ubuntu 18.04 LTS 1.3 Ubuntu 20.04 LTS 1.4 Ubuntu 22.04 LTS         2. Cross Compilation on Ubuntu 20.04 LTS 2.1 Linux kernel 4.9 2.2 Linux kernel 5.10 2.3 Linux kernel 6.12 No.4 Conclusion     NXP TIC Connectivity Team Weidong Sun Apr-18-2025
查看全文
The article described steps on how to enable SDIO Wi-Fi & Bluetooth on M.2 interface. The main contents are like below: ========================= 1. Introduction  2. Steps            2.1 Board Configurations            ① BoardConfig.mk            ② evk_8mp.mk            ③ SharedBoardConfig.mk            ④ imx8mp_gki.fragment           2.2 Wi-Fi & Bluetooth Configurations            ① wifi_mod_para.conf            ② bt_vendor.conf            ③ vendor_interface.cc  3. Building & Downloading images to i.MX8MP-EVK          3.1 Building images          3.2 Downloading images  4. Running Android images to verify Wi-Fi & Bluetooth  =========================   For other versions of Android bsp or SDIO Wi-Fi/BT on M.2, same steps.   NXP TIC Connectivity Team, Weidong Sun    
查看全文
The article introduces steps on how to transmit files between IW612 Bluetooth and remote devices on linux platform.   NXP TIC Connectivity Team Weidong Sun
查看全文
The article introduces the following contents related to 88W9098. 1. Introduction     1.1 Software Tools     1.2 Hardware Tools     1.3 Diagram of connections 2. Configurations     2.1 Loading Wi-Fi driver     2.2 Connecting external AP          2.2.1 mlan0 to external AP with 5G          2.2.2 mmlan0 to Mobile with 2.4G 2.3 Configuring iptables 2.4 DHCP service on ethernet 3. Wi-Fi Bridge Verification     3.1 Verification of Ethernet to mlan0     3.2 Verification of Ethernet to mmlan0   NXP TIC Connectivity Team Weidong Sun  
查看全文
Previously, we discussed how to compile the SDK_2.16 zigbee source code. The article is here: https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/NXP-Wi-Fi-amp-Bluetooth-Product-Building-RW612-Zigbee-Source/ta-p/2097613 The latest SDK zigbee source code compilation method is different. The author conducted an experiment and recorded the relevant steps for users' reference. In the article, we will discuss the following contents.  1. Introduction 2. Preparation before compilation                 2.1 CMake                 2.2 Ninja                 2.3 ARM GCC tool chain                 2.4 Python3                 2.5 West                 2.6 MCUXPress SDK 3. Building Zibgee Source Code on ubuntu 20.04 host                 3.1 Setting up environment                 3.2 Building coordinator                 3.3 Building mcu bootloader                 3.4 Building router 4. Verified ARM GCC Version 5. Programing QSPI Nor Flash   NXP TIC Connectivity Team Weidong Sun June-09-2025  
查看全文