无线连接知识库

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

Wireless Connectivity Knowledge Base

讨论

排序依据:
The High Power board design files can be found on the JN5189 product webpage, in the JN-RD-6054-JN5189 Design Files. More precisely, the reference manual and the design files are attached to this article (OM15072-2_MOD_EXT_AMP_QFN40_PCB2467-2.0.zip and JN-RM-2078-JN5189-Module-Development_1V4.pdf) Some guidance is available here. The RF performances are presented in the attached test report (powerpoint file). The FCC/IC Certificates or Declarations of conformity are in the article "Certificates/Declarations of conformity (nxp community)".  
查看全文
The radio certification has been performed on JN5189, QN9090 and K32W products. The certificates or declaration of conformity are available in attached files.   And click here to know more on the best way to build a PCB the first time right with K32W061, QN9090 or JN5189 ! 
查看全文
Please find here all the information needed to build your own PCB based on K32W061/041(AM/A), QN9090/9030(T) or JN5189/5188(T). Your first task before to send any inquiry to NXP support is to fill the K32W Design In CHECK LIST available in this ticket.   K32W061 Manufacturing package  Find here all the product pages, most of the HW documents are in the corresponding platforms web pages: K32W061/041 (AM/A) QN9090/9030(T) JN5189/5188(T)   The K32W EVK getting started webpage: IOT_ZTB-DK006 Get started page (nxp.com) IoT_ZTB getting started manual (nxp.com)   HW: HW design consideration : JN-RM-2078-JN5189-Module-Development_1V4.pdf (see attached file) JN-RM-2079-QN9090-Module-Development_1V0.pdf (see attached file) JN-RM-2080-K32W-Module-Development_1V0.pdf (see attached file)   Radio: RF report:  JN5189: https://www.nxp.com/docs/en/application-note/AN12154.pdf (nxp.com) QN9090: https://www.nxp.com/docs/en/nxp/application-notes/AN12610.pdf (nxp.com) K32W: https://www.nxp.com/docs/en/application-note/AN12798.pdf (nxp.com) Antenna: https://www.nxp.com/docs/en/application-note/AN2731.pdf (nxp.com)   Low Power Consumption:  JN5189: https://www.nxp.com/docs/en/application-note/AN12898.pdf (nxp.com) QN9090: https://www.nxp.com/docs/en/application-note/AN12902.pdf (nxp.com) K32W: https://www.nxp.com/docs/en/application-note/AN12846.pdf (nxp.com) A power calculator tool is available here: https://community.nxp.com/t5/Connectivity-Support-QN-JN-KW/QN9090-Bluetooth-LE-Power-Profile-Calculator-Tool/ta-p/1209602 SW tools: Customer Module Evaluation Tool  (nxp.com) Bluetooth Low Energy Certification Tool (nxp.com) K32W041/K32W061/QN9090(T)/QN9030(T) Bluetooth Low Energy Certification Tool User's Guide (nxp.com)     Certification: Certificates/Declarations of conformity (nxp community)  
查看全文
Based on i.MX8MN-EVK And Linux 5.4.70_2.3.0 BSP As an example of NXP Bluetooth Bluetooth application, this article describes how to use Bluetooth to realize file transfer between windows PC and i.MX8MN-EVK (linux), and between Android mobile phone and i.MX8MN-EVK. The test architecture used in this example is as follows: The following steps are for the application example: Step 1 Preparation  --Downloading DEMO Image For i.MX8MN-EVK  --Downloading uuu tool  --Compiling L5.4.70_2.3.0 BSP for i.MX8MN-EVK  --Copying rootfs to the DEMO Image directory  --Modifying example_kernel_emmc.uuu as uuu programming script  --Programming images to i.MX8MN-EVK board  Booting i.MX8MN-EVK board Step 2 Loading WIFI/BT driver and Enable Bluetooth Step 3 File Transter between Windows 10 PC and i.MX8MN-EVK board Step 4 File Transter between Android Mobile and i.MX8MN-EVK board [Summary] More detailed information, see attachment, please!
查看全文
The homologation requirements in China (MIIT [2002]353) obviously are planned (end of December 2022) to be sharpened (MIIT publication from 2021-01-27: “Notice on Matters Related to Radio Management in the 2400MHz, 5100MHz and 5800MHz Bands”).   A modification register is need on the KW38 and KW36 to pass the new Chinese  requirement with acceptable margin: PA_RAMP_SEL value must be set to 0x02h (2us) instead of 0x01h (1us default value) Modification SW: XCVR_TX_DIG_PA_CTRL_PA_RAMP_SEL(2) in the nxp_xcvr_common_config.c All the details are in the attached file.   Note: This SW modification is for China country only.
查看全文
In the process of practical application, customers often need the combination of ble + NFC. At present, our IOT-DK006 is the only development board with NFC module. But the NFC example is not perfect. So we porting the library of NFC reader- PN7150, to support KW series microcomputer so that KW series can handle the demand of ble + NFC function. Now I will introduce you how to port the NFC lib to KW. 1 PN7150 Introduction PN7150 is the high-performance version of PN7120, the plug’n play NFC solution for easy integration into any OS environment, reducing Bill of Material (BOM) size and cost. PN71xx controllers are ideal for home-automation applications such as gateways and work seamlessly with NFC connected tags. 2 Tools hardware:FRDM-KW36,PN7150 , some wire software:mcuxpresso11.3 package:NXP-NCI MCUXpresso example Project This package contains the nfc library and example that we need. We will refer the ‘NXPNCI-K64F_example’ firstly. Sdk version: 2.2.8, Example: frdmkw36_rtos_examples_freertos_i2c  3 Steps Hardware part:We need connect the PN7150 to KW36 like the picture. Although we can connect the PN7150 to board through the ardunio connector, the pin’s voltage is not enough to drive the PN7150. So we need a wire connected to U1 to get 3.3V.   PN7150 FRDM-KW36 VBAT/PVDD 3.3V VANT 5V GND GND IRQ PTA16 VEN PTC15 SCL PTB0,I2C0 SDA PTB1,I2C0 Software part:We should add the nfc library and directory into our project. You can check the following picture to know what file is necessary. If you want to know how to add directory into our project, you can refer this link. The red line shows what file we need. Please notice that when we add file path into the mcuxpresso configuration, we also need add the path into ‘Path and Symbols’ .   We need add some macro into ‘Preprocessor’.   We copy the NXPNCI-K64F_example’s main file content into our ‘freertos_i2c.c’. Next, we need modify the file pin_mux.c, tml.c and board.h   In file board.h,add the following macro. Don't forget to enable the pin clock. /* NXPNCI NFC related declaration */ #define BOARD_NXPNCI_I2C_INSTANCE I2C0 #define BOARD_NXPNCI_I2C_BAUDRATE (100000) #define BOARD_NXPNCI_I2C_ADDR       (0x28) #define BOARD_NXPNCI_IRQ_PORTIRQn PORTA_IRQn #define BOARD_NXPNCI_IRQ_GPIO     (GPIOA) #define BOARD_NXPNCI_IRQ_PORT     (PORTA) #define BOARD_NXPNCI_IRQ_PIN      (16U) #define BOARD_NXPNCI_VEN_GPIO     (GPIOC) #define BOARD_NXPNCI_VEN_PORT     (PORTC) #define NXPNCI_VEN_PIN            (5U)     In file pin_mux.c, add head file ‘board.h’. Add the following code in function ’ BOARD_InitPins’. The step is to configure the VEN, IRQ and I2C0. This example contains the I2C1’s code, you can comment them.     /* Initialize NXPNCI GPIO pins below */   /* IRQ and VEN PIN_MUX Configuration */   PORT_SetPinMux(BOARD_NXPNCI_IRQ_PORT, BOARD_NXPNCI_IRQ_PIN, kPORT_MuxAsGpio);   PORT_SetPinMux(BOARD_NXPNCI_VEN_PORT, NXPNCI_VEN_PIN, kPORT_MuxAsGpio);   /* IRQ interrupt Configuration */   NVIC_SetPriority(BOARD_NXPNCI_IRQ_PORTIRQn, 6);   EnableIRQ(BOARD_NXPNCI_IRQ_PORTIRQn);   PORT_SetPinInterruptConfig(BOARD_NXPNCI_IRQ_PORT, BOARD_NXPNCI_IRQ_PIN, kPORT_InterruptRisingEdge);   Finally, in file tml.c, modify PORTC_IRQHandler as PORTA_IRQHandler We finished all steps. 4 Results We use ntag to test the reading and writing operation.   When the tag is closed to the PN7150, we will get the following message.   The text recording is ‘VER=03’. Next, we will modify the text recording We need add the new macro to preprocessor.   We can modify the variable NDEF_MESSAGE in function task_nfc_reader to modify the text recording.   Then we download the program again. We will see the original text ‘VER=03’ and the text has been modified. Then we read the tag again. We will see the new text.   If we want to send the larger text, what should we do? We need modify the macro ‘ADD’. When only 4 characters are sent, ‘ADD’ is 0. And every additional character is added, the ‘ADD’ will add. We modify the tag as ‘Ver=03’, and we have two more characters. So ‘ADD’ needs to be defined as 2   It firstly shows the text ‘Test’. Then it will show the new text ‘Ver=03’. Other tags’ reading and writing operation can be enabled by defining some macro.      
查看全文
[Summary]        This article demonstrates two ways to compile the driver for x86 linux kernel: Compile the driver for 4.19.35 kernel. Compile the current kernel of the driver for ubuntu 16.04.        If setting CROSS_COMPILE and ARCH, the driver can be generated with make command, but the bin_sd8978 subdirectory will not be generated. The utility needs to be compiled separately. Only for x86 arch, when compiling the driver using make build, the bin_sd8978 directory will be generated. Users need to pay attention to this.     3. For USB drivers of IW416, The usb.h in the original ubuntu 16.04 kernel has no update, struct usb_interface structure, lack of pm_usage_cnt members, so we must update the ubuntu kernel. More detaled information, see attachment, please!
查看全文
       The article describes how to integrate 88W8997 PCIE to Linux 5.4.24_2.1.0 based on i.MX8MM-EVK platform, and how to solve issues encountered during the integration. [Contents] Chapter 1 Connections & environments Connections Environments Hardware devices Software M.2 NGFF KEY E interface on i.MX8MM-EVK Chapter 2 Preparation For Software        2.1 Cross Compile Toolchain        2.2 Demo Image for iMX8MM-EVK        2.3 L5.4.21_2.1.0 kernel source code        2.4 88W8997 PCIe Driver source code        2.5 uuu manufacturing Tool Chapter 3 Steps For Integration        2.1 Cross compiling L5.4.21_2.1.0 kernel source code Copying Image to Demo Image directory On windows 2.2 Cross compiling 88W8997 PCIe driver Copying mlan.ko & pcie8xxx.ko to windows directory Copying Firmware to windows to windows directory 2.3 Burning Linux Images to iMX8MM-EVK board        2.4 Copying .ko and firmware files to iMX8MM-EVK board via MobaXterm        2.5 Loading 88W8997 driver Chapter 4 Troubleshooting        4.1 PCIe card can’t be found via lspci command        4.2 Errors on MSI interrupt when using PCIe Switch AW-CM276MA (88W8997 Inside)  
查看全文
This article describes the detailed steps for integrating 88W8801 to i.MX6ULL-EVK and L5.4.70_2.3.0. If you are not proficient in compiling Linux BSP for I.MX platform, you can refer to this link: https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/WiFi-BT-Integretion-Linux-BSP-compilation-for-iMX-platform/ta-p/1277199 For more detailed information, see attachment, please!  
查看全文
This article describes how to compile the Linux BSP of the i.MX platform under ubuntu 18.04, 20.04 LTS and debian-10. This is a necessary step to integrate WIFI/BT to the I.MX platform. See the attachment for detailed steps.
查看全文
This article describes how to use the tcpdump tool to capture wireless network data packets. The test block diagram is as follows: For more detailed information, See attachment,please!   NXP CAS-TIC Wireless MCU team Weidong Sun
查看全文
This example of custom profile uses the Temperature Sensor and Temperature Collector examples as a base, so it can be easily modified. Both examples are in the SDK, so this document explains how to add the Humidity profile, and how to modify the code to get the Humidity Sensor and Collector working. Introduction Generic Attribute Profile (GATT) establishes in detail how to exchange all profile and user data over a BLE connection. GATT deals only with actual data transfer procedures and formats. All standard BLE profiles are based on GATT and must comply with it to operate correctly. This makes GATT a key section of the BLE specification, because every single item of data relevant to applications and users must be formatted, packed, and sent according to the rules. GATT defines two roles: Server and Client. The GATT server stores the data transported over the Attribute Protocol (ATT) and accepts Attribute Protocol requests, commands and confirmations from the GATT client. The GATT client accesses data on the remote GATT server via read, write, notify, or indicate operations. Notify and indicate operations are enabled by the client but initiated by the server, providing a way to push data to the client. Notifications are unacknowledged, while indications are acknowledged. Notifications are therefore faster, but less reliable.  GATT Database establishes a hierarchy to organize attributes. These are the Profile, Service, Characteristic and Descriptor. Profiles are high level definitions that define how services can be used to enable an application and Services are collections of characteristics. Descriptors defined attributes that describe a characteristic value.    To define a GATT Database several macros are provided by the GATT_DB API in the Freescale BLE Stack, which is part KW38 SDK. Server (Sensor)  First, we need to use the Temperature Sensor project as a base, to create our Humidity Custom Profile Server (Sensor). BLE SIG profiles To know if the Profile or service is already defined in the specification, you have to look for in Bluetooth SIG profiles and check in the ble_sig_defines.h file (${workspace_loc:/${ProjName}/bluetooth/host/interface) if this is already declared in the code. In our case, the service is not declared, but the characteristic of the humidity is declared in the specification. Then, we need to check if the characteristic is already included in ble_sig_defines.h. Since, the characteristic is not included, we need to define it as shown next:   /*! Humidity Charactristic UUID */ #define gBleSig_Humidity_d 0x2A6F   GATT Database The Humidity Sensor is going to have the GATT Server, because is going to be the device that has all the information for the GATT Client. On the Temperature Sensor demo have the Battery Service and Device Information, so you only have to change the Temperature Service to Humidity Service    In order to create the demo we need to define or develop a service that has to be the same as in the GATT Client, this is declared in the gatt_uuid128.h.If the new service is not the same, they will never be able to communicate each other. All macros, function or structure in SDK have a common template which helps the application to act accordingly. Hence, we need to define this service in the gatt_uuid128.h as shown next:    /* Humidity */ UUID128(uuid_service_humidity, 0xfe ,0x34 ,0x9b ,0x5f ,0x80 ,0x00 ,0x00 ,0x80 ,0x00 ,0x10 ,0x00 ,0x02 ,0x00 ,0xfa ,0x10 ,0x10)   All the Service and Characteristics is declared in gattdb.h. Descriptors are declared after the Characteristic Value declaration but before the next Characteristic declaration. In this case the permission is the CharPresFormatDescriptor that have specific description by the standard. The Units of the Humidity Characteristic is on Percentage that is 0x27AD. Client Characteristic Configuration Descriptor (CCCD) is a descriptor where clients write some of the bits to activate Server notifications and/or indications.   PRIMARY_SERVICE_UUID128(service_humidity, uuid_service_humidity) CHARACTERISTIC(char_humidity, gBleSig_Humidity_d, (gGattCharPropNotify_c)) VALUE(value_humidity, gBleSig_Humidity_d, (gPermissionNone_c), 2, 0x00, 0x25) DESCRIPTOR(desc_humidity, gBleSig_CharPresFormatDescriptor_d, (gPermissionFlagReadable_c), 7, 0x0E, 0x00, 0xAD, 0x27, 0x00, 0x00, 0x00) CCCD(cccd_humidity)   After that, create a folder humidity in the next path ${workspace_loc:/${ProjName}/bluetooth/profiles. Found the temperature folder, copy the temperature_service.c and paste inside of the humidity folder with another name (humidity_service.c). Then go back and look for the interface folder, copy temperature_interface.h and change the name (humidity_interface.h) in the same path. You need to include the path of the created folder. Project properties>C/C+ Build>Settings>Tool Settings>MCU C Compiler>Includes: Humidity Interface The humidity_interface.h file should have the following code. The Service structure has the service handle, and the initialization value.   /*! Humidity Service - Configuration */ typedef struct humsConfig_tag { uint16_t serviceHandle; int16_t initialHumidity; } humsConfig_t; /*! Humidity Client - Configuration */ typedef struct humcConfig_tag { uint16_t hService; uint16_t hHumidity; uint16_t hHumCccd; uint16_t hHumDesc; gattDbCharPresFormat_t humFormat; } humcConfig_t;   Humidity Service At minimum on humidity_service.c file, should have the following code. The service stores the device identification for the connected client. This value is changed on subscription and non-subscription events.   /*! Humidity Service - Subscribed Client*/ static deviceId_t mHums_SubscribedClientId;   The initialization of the service is made by calling the start procedure. This function is usually called when the application is initialized. In this case is on the BleApp_Config().   bleResult_t Hums_Start(humsConfig_t *pServiceConfig) { mHums_SubscribedClientId = gInvalidDeviceId_c; /* Set the initial value of the humidity characteristic */ return Hums_RecordHumidityMeasurement(pServiceConfig->serviceHandle, pServiceConfig->initialHumidity); }   On stop function, the unsubscribe function is called.   bleResult_t Hums_Stop(humsConfig_t *pServiceConfig) { /* Stop functionality by unsubscribing */ return Hums_Unsubscribe(); } bleResult_t Hums_Unsubscribe(void) { /* Unsubscribe by invalidating the client ID */ mHums_SubscribedClientId = gInvalidDeviceId_c; return gBleSuccess_c; }   The subscribe function will be used in the main file, to subscribe the GATT client to the Humidity service.   bleResult_t Hums_Subscribe(deviceId_t clientDeviceId) { /* Subscribe by saving the client ID */ mHums_SubscribedClientId = clientDeviceId; return gBleSuccess_c; }   Depending on the complexity of the service, the API will implement additional functions. For the Humidity Sensor only have a one characteristic. The measurement will be saving on the GATT database and send the notification to the client. This function will need the service handle and the new value as input parameters.   bleResult_t Hums_RecordHumidityMeasurement(uint16_t serviceHandle, int16_t humidity) { uint16_t handle; bleResult_t result; bleUuid_t uuid = Uuid16(gBleSig_Humidity_d); /* Get handle of Humidity characteristic */ result = GattDb_FindCharValueHandleInService(serviceHandle, gBleUuidType16_c, &uuid, &handle); if (result != gBleSuccess_c) return result; /* Update characteristic value */ result = GattDb_WriteAttribute(handle, sizeof(uint16_t), (uint8_t*) &humidity); if (result != gBleSuccess_c) return result; Hts_SendHumidityMeasurementNotification(handle); return gBleSuccess_c; }   After save the measurement on the GATT database with GattDb_WriteAttribute function we send the notification. To send the notification, first have to get the CCCD and after check if the notification is active, if is active send the notification.   static void Hts_SendHumidityMeasurementNotification ( uint16_t handle ) { uint16_t hCccd; bool_t isNotificationActive; /* Get handle of CCCD */ if (GattDb_FindCccdHandleForCharValueHandle(handle, &hCccd) != gBleSuccess_c) return; if (gBleSuccess_c == Gap_CheckNotificationStatus (mHums_SubscribedClientId, hCccd, &isNotificationActive) && TRUE == isNotificationActive) { GattServer_SendNotification(mHums_SubscribedClientId, handle); } }   Humidity Sensor Main file There are some modifications that have to be done, to use the new Humidity profile in our sensor example. First, we need to declare the humidity service:   static humsConfig_t humsServiceConfig = {(uint16_t)service_humidity, 0};   Then, we need to add or modify the following functions: BleApp_Start You need to modify this line:   /* Device is connected, send humidity value */ BleApp_SendHumidity();   BleApp_Config You need to start the Humidity Service, and to modify the PrintString line:   humsServiceConfig.initialHumidity = 0; (void)Hums_Start(&humsServiceConfig);     AppPrintString("\r\nHumidity sensor -> Press switch to start advertising.\r\n");   BleApp_ConnectionCallback There are some modifications required in two Connection Events. gConnEvtConnected_c   (void)Hums_Subscribe(peerDeviceId); gConnEvtDisconnected_c   gConnEvtDisconnected_c   (void)Hums_Unsubscribe();   BleApp_GattServerCallback   /* Notify the humidity value when CCCD is written */ BleApp_SendHumidity()   BleApp_SendHumidity And, we need to add this function:   static void BleApp_SendHumidity(void) { (void)TMR_StopTimer(appTimerId); /* Update with initial humidity */ (void)Hums_RecordHumidityMeasurement((uint16_t)service_humidity, (int16_t)(BOARD_GetTemperature())); #if defined(cPWR_UsePowerDownMode) && (cPWR_UsePowerDownMode) /* Start Sleep After Data timer */ (void)TMR_StartLowPowerTimer(appTimerId, gTmrLowPowerSecondTimer_c, TmrSeconds(gGoToSleepAfterDataTime_c), DisconnectTimerCallback, NULL); #endif }   In this example, the Record Humidity uses the BOARD_GetTemperature, to use the example without any external sensor and to be able to see a change in the collector, but, in this section would be a GetHumidity function. Client (Collector)  First, we need to use the Temperature Collector project as a base, to create our Humidity Custom Profile Client (Collector). BLE SIG profiles The same applies for the Client. To know if the Profile or service is already defined in the specification, you have to look for in Bluetooth SIG profiles and check in the ble_sig_defines.h file (${workspace_loc:/${ProjName}/bluetooth/host/interface) if this is already declared in the code. In our case, the service is not declared, but the characteristic of the humidity is declared in the specification. Then, we need to check if the characteristic is already included in ble_sig_defines.h. Since, the characteristic is not included, we need to define it as shown next:   /*! Humidity Charactristic UUID */ #define gBleSig_Humidity_d 0x2A6F   GATT Database The Humidity Collector is going to have the GATT client; this is the device that will receive all information from  the GATT server. Demo provided in this post works like the Temperature Collector. When the Collector enables the notifications from the sensor, received notifications will be printed in the serial terminal. In order to create the demo we need to define or develop a service that has to be the same as in the GATT Server, this is declared in the gatt_uuid128.h.If the new service is not the same, they will never be able to communicate each other. All macros, function or structure in SDK have a common template which helps the application to act accordingly. Hence, we need to define this service in the gatt_uuid128.h as shown next:   /* Humidity */ UUID128(uuid_service_humidity, 0xfe ,0x34 ,0x9b ,0x5f ,0x80 ,0x00 ,0x00 ,0x80 ,0x00 ,0x10 ,0x00 ,0x02 ,0x00 ,0xfa ,0x10 ,0x10)   After that, copy the humidity profile folder from the Sensor project, to the Collector project ${workspace_loc:/${ProjName}/bluetooth/profiles. And also for this project, include the path of the new folder. Project properties>C/C+ Build>Settings>Tool Settings>MCU C Compiler>Includes: Humidity Collector Main file In the Collector source file, we need to do also some modifications, to use the Humidity Profile. First, we need to modify the Custom Information of the Peer device:   humcConfig_t humsClientConfig;   BleApp_StoreServiceHandles   static void BleApp_StoreServiceHandles ( gattService_t *pService ) { uint8_t i,j; if ((pService->uuidType == gBleUuidType128_c) && FLib_MemCmp(pService->uuid.uuid128, uuid_service_humidity, 16)) { /* Found Humidity Service */ mPeerInformation.customInfo.humsClientConfig.hService = pService->startHandle; for (i = 0; i < pService->cNumCharacteristics; i++) { if ((pService->aCharacteristics[i].value.uuidType == gBleUuidType16_c) && (pService->aCharacteristics[i].value.uuid.uuid16 == gBleSig_Humidity_d)) { /* Found Humudity Char */ mPeerInformation.customInfo.humsClientConfig.hHumidity = pService->aCharacteristics[i].value.handle; for (j = 0; j < pService->aCharacteristics[i].cNumDescriptors; j++) { if (pService->aCharacteristics[i].aDescriptors[j].uuidType == gBleUuidType16_c) { switch (pService->aCharacteristics[i].aDescriptors[j].uuid.uuid16) { /* Found Humidity Char Presentation Format Descriptor */ case gBleSig_CharPresFormatDescriptor_d: { mPeerInformation.customInfo.humsClientConfig.hHumDesc = pService->aCharacteristics[i].aDescriptors[j].handle; break; } /* Found Humidity Char CCCD */ case gBleSig_CCCD_d: { mPeerInformation.customInfo.humsClientConfig.hHumCccd = pService->aCharacteristics[i].aDescriptors[j].handle; break; } default: ; /* No action required */ break; } } } } } } }   BleApp_StoreDescValues   if (pDesc->handle == mPeerInformation.customInfo.humsClientConfig.hHumDesc) { /* Store Humidity format*/ FLib_MemCpy(&mPeerInformation.customInfo.humsClientConfig.humFormat, pDesc->paValue, pDesc->valueLength); }   BleApp_PrintHumidity   /*www.bluetooth.com/specifications/assigned-numbers/units */ if (mPeerInformation.customInfo.humsClientConfig.humFormat.unitUuid16 == 0x27ADU) { AppPrintString(" %\r\n"); } else { AppPrintString("\r\n"); }   BleApp_GattNotificationCallback   if (characteristicValueHandle == mPeerInformation.customInfo.humsClientConfig.hHumidity) { BleApp_PrintHumidity(Utils_ExtractTwoByteValue(aValue)); }    CheckScanEvent   foundMatch = MatchDataInAdvElementList(&adElement, &uuid_service_humidity, 16);   BleApp_StateMachineHandler mAppIdle_c   if (mPeerInformation.customInfo.humsClientConfig.hHumidity != gGattDbInvalidHandle_d)   mAppServiceDisc_c   if (mPeerInformation.customInfo.humsClientConfig.hHumDesc != 0U) mpCharProcBuffer->handle = mPeerInformation.customInfo.humsClientConfig.hHumDesc;   mAppReadDescriptor_c   if (mPeerInformation.customInfo.humsClientConfig.hHumCccd != 0U)   BleApp_ConfigureNotifications   mpCharProcBuffer->handle = mPeerInformation.customInfo.humsClientConfig.hHumCccd;   Demonstration Now, after connection, every time that you press the SW3 on KW38 Humidity Sensor is going to send the value to KW38 Humidity Collector.  
查看全文
       The article will describe how to configure A2DP audio application Based On NXP platform and WIFI/BT chipset step by step. Users can easily make her A2DP audio based on NXP WIFI module work normally by following steps in the article. Environment for the validation Hardware Platform        i.MX8MN-EVK Software Kernel version: L5.4.70_2.3.0 rootfs : imx-image-multimedia WiFi module        AW-CM358SM: NXP 88W8987 chipset   For more detailed information, see attachment, please!   NXP CAS-TIC wireless MCU team Weidong Sun    
查看全文
1 Introduction Two development boards transmit control information through ble. One development board connects to paj7620 and provides gesture information through IIC bus. The other development board uses ble and USB HID. Ble is used to receive data, and USB HID is used to simulate keyboard input and control ppt                  Figure  1 2 Preparation We need two development boards qn908x and gesture control device paj7620. We use IAR as development enviroment.The example we use is temperature_sensor, and temperature_ colloctor. The SDK version is 2.2.3   3 Code 3.1  temperature_sensor code We want to implement IIC to read gesture information from paj7620 and send data. The pins used by IIC are PA6 and PA7 Simply encapsulate the IIC reading and writing code in the code to create i2c_ operation.c and i2c_ operation.h. Realize IIC initialization and reading / writing register function in it                        Figure  2                        Figure  3   3.1.1 After having these functions, we begin to write gesture recognition code. First, we add two blank files paj7620.c and paj7620.h into our project.   Select bank register area                               Figure 4   Wake up paj7620 to read device state                    Figure 5   Initialize device                    Figure 6   Gesture test function                                   Figure 7   3.1.2 When you are ready to read the device information, You should initialize IIC and paj7620 in BleApp_Init function                                Figure 8 In principle, we need to create a custom service for the PAJ device, but we replace the temperature data as our gesture control data. If you want to create a custom service, refer to this link custom profile   3.1.3 Create a timer that sends gesture data regularly. In file temerature_sensor.c Define a timer,static tmrTimerID_t dataTimerId; Allocate a timer, dataTimerId = TMR_AllocateTimer(); Define the callback function of this timer                                           Figure 9 Start timer                                    Figure 10 Close the low power mode. #define cPWR_UsePowerDownMode 0 3.2 temperature_collector code The most important thing here is to port USB HID into our project. The USB  example we use is the USB keyboard and mouse. 3.2.1 Add the OSA and USB folder under the example to the project directory, and copy the file to the corresponding folder according to the file structure of the original example.                      Figure 11 3.2.2 Add header file directory after completion                                           Figure 12 At the same time, in this tab, add two macro definitions USB_STACK_FREERTOS_HEAP_SIZE=16384 USB_STACK_FREERTOS   3.2.3 Next, we need to modify the main function in usb example . Open composite.c file.                      Figure 13 It calls the APP_task. So this function also need to be modified.                                   Figure 14 3.2.4Find hid_mouse.c,Comment function USB_DeviceHidMouseAction Find hid_keyboard.h. Define the gesture information.                                  Figure 15 Find hid_keyboard.c. We need to modify the function USB_DeviceHidKeyboardAction as following figure.                                                  Figure 16   Among them, we also need to implement the following function. When the up hand gesture is detected, the previous ppt will be played. The down hand gesture will be the next PPT, the left hand gesture will exit PPT, and the forward hand gesture will play ppt                                                  Figure 17 It also refers to an external variable gesture_from_server. The variable definition is in file temperature_ collocation.c,.     3.2.5 After that, let's go to BleApp_Statemachinehandler function in temperature_colloctor.c. In case mApppRunning_c, we will call usb_main to initialize USB HID                                                  Figure 18 3.2.6 In BleApp_PrintTemperature, we will save the gesture data to gesture_from_server                                                         Figure 19 We finished the all steps.        
查看全文
      The article will describe how to configure Access Point Based On NXP platform and WIFI chipset step by step. Users can easily make her AP based on NXP WIFI module work normally by following steps in the article. 1. Environment for the validation - Hardware Platform     i.MX8MN-EVK - Software    Kernel version: L5.4.70_2.3.0    rootfs : imx-image-multimedia -WiFi module   AW-CM358SM: NXP 88W8987 chipset 2. Diagram for Connections   For More detailed information, See attached document, please!   NXP CAS-TIC Wireless MCU team Weidong sun 04-16-2021  
查看全文
Where can I find the KW20-30-40 radio certification documents?     FRDM-KW40 platforms have passed the CE RED & FCC radio certification (BLE & 15.4).  Find below for information the certification documents and test reports.  For further information on the FRDM board and the product please refer to the corresponding KW40 Product Summary page and FRDM-KW40.
查看全文
KW39_38_37 radio certification information 
查看全文
Introduction   This post explains how to create a BLE GATT database using FSCI commands sent to the BLE Server device. Additionally, this document explains how to set up the fields of each FSCI command used to create the BLE GATT database for the BLE Server.   Main FSCI commands to create the BLE GATT DB in the BLE Server device   The following, are the main commands to create, write and read the GATT DB from the BLE Server perspective. The purpose of this post is to serve as a reference and summary of the most important commands. The full list of commands FSCI commands can be found in the Framework Serial Connectivity Interface (FSCI) for Bluetooth Low Energy Host Stack documentation within your SDK package. GATT-InitRequest This command is used to initialize the GATT database at runtime, and it must be sent before any other command to declare a database in your BLE Server device. GATTServer-RegisterCallback.Request This command installs an application callback for the GATT Server module, enabling the device to respond to the FSCI request from the CPU application through an FSCI indication. GATTDBDynamic-AddPrimaryServiceDeclaration.Request It adds a primary service to the database. It has 3 parameters that should be configured, the desired handle, the UUID type (16 bits, 32 bits, 128 bits), and the UUID value. Usually, the desired handle should be set to zero and the stack will assign the handle of the primary service automatically.   If the GATT application callback was installed through the GATTServer-RegisterCallback.Request command, the GATT Server responds to the GATTDBDynamic-AddPrimaryServiceDeclaration.Request command with a GATTDBDynamic-AddPrimaryServiceDeclaration.Indication that contains the handle assigned to the primary service. The following example shows how to prepare this command to define the battery service in the database. GATTDBDynamic-AddCharacteristicDeclarationAndValue.Request It adds a characteristic and its value to the database. It has 7 parameters that should be configured, the UUID type (16 bits, 32 bits, 128 bits), the UUID value, characteristic properties, the maximum length of the value (only for variable-length values), the initial length of the value, the initial value of the characteristic and value access permissions. The characteristic declared using this command, belongs to the last primary service declared in the database. For values with a fixed length, the maximum length parameter should be set to 0, and the length is obtained from the initial length of the value parameter.   If the GATT application callback was installed, the response of this command is indicated by the GATTDBDynamic-AddCharacteristicDeclarationAndValue.Indication command. The following example shows how to prepare this command to define the battery level characteristic in the database with a fixed length of 1 byte and an initial value of 90%. GATTDBDynamic-AddCharacteristicDescriptor.Request It adds a characteristic descriptor to the database. It has 5 parameters that should be configured, the UUID type (16 bits, 32 bits, 128 bits), UUID value, length of the descriptor value, descriptor’s value, and descriptor access permissions. The descriptor declared using this command, belongs to the last characteristic declared in the database.   If the GATT application callback was installed, the response of this command is indicated by the GATTDBDynamic-AddCharacteristicDescriptor.Indication command. The following example shows how to prepare this command to add the characteristic presentation format descriptor of the battery level characteristic in the database.   GATTDBDynamic-AddCccd.Request It adds a CCDD into the database. This command does not have parameters. The CCCD declared using this command, belongs to the last characteristic declared in the database. The response of this command is indicated by GATTDBDynamic-AddCccd.Indication.   GATTDB-FindServiceHandle.Request This command is used to find the handle of a service previously declared in the database. It has 3 parameters that should be configured, the handle to start the search (should be 1 on the first call), the UUID type of the service to find (16 bits, 32 bits, 128 bits), and the UUID value of the service that you are searching.   If the GATT application callback was installed, the response of this command is indicated by the GATTDB-FindServiceHandle.Indication command, which contains the handle of the found service. The following example shows how to prepare this command to find the handle of the battery service declared in the previous examples. Notice that the result of the search corresponds to the handle returned by the GATTDBDynamic-AddPrimaryServiceDeclaration.Indication as expected.   GATTDB-FindCharValueHandleInService It finds the characteristic´s handle of a given service previously declared in the database. It has 3 parameters that should be configured, the handle of the service that contains the characteristic, the UUID type of the characteristic to find (16 bits, 32 bits, 128 bits), and the UUID value of the characteristic that you are searching for.   If the GATT application callback was installed, the response of this command is indicated by the GATTDB-FindCharValueHandleInService.Indication command, which contains the handle of the found characteristic’s value. The following example shows how to prepare this command to find the handle of the battery level value. Notice that the result of the search corresponds to the handle returned by the GATTDBDynamic-AddCharacteristicDeclarationAndValue.Indication plus one, because the AddCharacteristicDeclarationAndValueIndication command returns the handle of the characteristic and, on the other hand, FindCharValueHandleInService returns the handle of the characteristic’s value. GATTDB-FindDescriptorHandleForcharValueHandle.Request It finds the descriptor´s handle of a given characteristic previously declared in the database. It has 3 parameters that should be configured, the handle of the characteristic’s value that contains the descriptor, the UUID type of the descriptor to find (16 bits, 32 bits, 128 bits), and the UUID value of the descriptor that you are searching.   If the GATT application callback was installed, the response of this command is indicated by the GATTDB-FindDescriptorHandleForCharValueHandle.Indication command, which contains the handle of the found descriptor. The following example shows how to prepare this command to find the handle of the characteristic presentation format descriptor. The result corresponds to the handle returned by the GATTDBDynamic-AddCharacteristicDescriptor.Indication   GATTDB-FindCccdHandleForCharValueHandle.Request It finds the CCCD’s handle of a given characteristic previously declared in the database. It has only one parameter, the handle of the characteristic’s value that contains the CCCD.   If the GATT application callback was installed, the response of this command is indicated by the GATTDB-FindCccdHandleForCharValueHandle.Indication command, which contains the handle of the found CCCD. The following example shows how to prepare this command to find the handle of CCCD. The result corresponds to the handle returned by the GATTDBDynamic-AddCccd.Indication.   GATTDB-WriteAttribute.Request It writes the value of a given attribute from the application level. It has 3 parameters that should be configured, the handle of the attribute that you want to write, the length of the value in bytes, and the new value.   In the following example, we will modify the battery level characteristic’s value from 90% to 80%.   GATTDB-ReadAttribute.Request   It reads the value of a given attribute from the application level. It has 2 parameters that should be configured, the handle of the attribute that you want to read, and the maximum bytes that you want to read. The GATT application callback must be installed, since the response of this command indicated by the GATTDB-ReadAttribute.Indication command contains the value read from the database. In the following example, we will read the battery level characteristic’s value, the result is 80%.      
查看全文
This post covers the below details. Introduction to Framework Serial Communication Interface (FSCI). BLE Server. Useful Commands to create a GATT database. Demonstrate the heart rate sensor profile using the FSCI black box application with Test Tool. Framework Serial Communication Interface The Framework Serial Communication Interface (FSCI) is a software module and a protocol that supports interfacing the Protocol Host Stack (i.e. BLE, Thread, and ZigBee) with a host or a PC tool (Test Tool for Connectivity Products) using a serial communication interface (e.g. UART, USB, SPI, and I2C). The below figure shows interaction between different layers.  Figure 1. System Overview The Host Processor (Application layer and control for Connectivity Stack) The Black Box application (APIs to interact with the Connectivity Stack) The below figure illustrates Interfacing between the host processor and black box application.  Figure 2. Protocol stack separation The Test Tool software for the connectivity products is an example of a host processor that can communicate with FSCI black boxes at various layers. The figure below shows FSCI based application structure.  Figure 3. FSCI based Application Structure The FSCI module executes in the context of the Serial Manager task. For more details regarding FSCI and Serial Manager module refer to the ‘Connectivity Framework Reference Manual.pdf’ document available inside SDK Documentation at location <SDK_Documentation\docs\wireless\Common>. The detailed description of the Bluetooth Low Energy Host Stack serial commands, communication packet structure, and usage of the Framework Serial Communication Interface is provided inside the ‘Bluetooth Low Energy Host Stack FSCI Reference Manual.pdf’ document available inside SDK Documentation at location <SDK_Documentation\docs\wireless\Bluetooth>. The detail about FSCI Host is described here. An example of FSCI based BLE temperature sensor application is described in AN12896. Bluetooth Low Energy Server Bluetooth Low Energy allows exchange of information using the Generic Attribute Profile (GATT), GATT defines below two roles: Server: Device that stores the information. Client: Device that request for information from the server. Going forward, this post describes how to implement a BLE Server using the FSCI black box application with Test Tool. The server device can implement the GATT Database using below two methods. Static database: MACROs are used to add services, characteristics, etc. Dynamic database: APIs are used to add services, characteristics, etc. It is useful when runtime database update is required. This is the approach used by FSCI for the management of GATT databases. The below figure shows an example of database hierarchy.  Figure 4. GATT Database Service: It is a set of information. i.e., sensor location, sensor read value, etc. Bluetooth SIG has defined universally unique identifier (UUID) for various services and characteristics. This UUID will be useful to add services and characteristics to the database. Heart Rate, Battery Information, Device Information are examples of the service. Characteristic and value: It is the actual entity where information and its value are stored when the characteristic and value are added into the database. i.e., Device information service can have characteristics like manufacturer name, model string, Hardware version, etc. Descriptor: It is used to provide additional information regarding the characteristic and its value, e.g. format, scale, unit, etc. Client Characteristic Configuration Descriptor (CCCD): It is a descriptor used by the client device to enable or disable the notifications or indications. When the specific component is added using GATT_DB APIs, the stack will assign a handle to that component to index it in the database. Useful commands to create GATT database FSCI provides a set of commands for the management of the GATT Database. The most used ones are described below. Table 1 Some of the Basic GATT_DB Command Command Description No. of Handle assigned GATTDBDynamic-AddPrimaryServiceDeclaration.Request To add the primary service. 1 GATTDBDynamic-AddCharacteristicDeclarationAndValue.Request To add the characteristic and its value. It will be added as part of previously added service. 2 GATTDBDynamic-AddCharacteristicDescriptor.Request To add the descriptor for the previously added characteristic. 1 GATTDBDynamic-AddCccd.Request To add the CCCD for the previously added characteristic. 1 The attached Test Tool macro file demonstrates steps and setup required to implement a Heart Rate Sensor profile. The steps to execute it are described in the attached lab guide.
查看全文
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).
查看全文