WF(200) can be used with Linux in WPA3 in both AP (Access Point) and STA (STAtion) modes using Linux standard commands.
This article provides generic (i.e. not specific to WF(M)200) information on the Linux configuration of a WPA3 AP as well as a WPA3 STA. You can set up 2 boards and connect them together over WPA3 Wi-Fi.
In most cases, WF(M)200 will act either as AP or STA, not with both roles simultaneously. For commissioning purposes, it is possible to enable simultaneous AP+STA. Details on this feature are not provided in this article.
The AP wlan interface is selectable in the hostapd command line, as the '-i' (list of interface names to use) field. It can also be hard-coded in the hostapd_WPA3.conf file.
Typical hostapd command line (in the context of our Raspberry Pi demo, user 'pi' (requiring 'sudo'))
sudo killall hostapd
sudo hostapd -i wlan0 hostapd_WPA3.conf
Configuration file: hostapd_WPA3.conf
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Using interface wlan0 with hwaddr 00:0d:6f:73:91:57 and ssid "WPA3_AP"
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED
We recommend not running hostapd in the background when experimenting, to get an immediate display of any message from the application. Run in the background once you have validated your setup (use '-B' for running in background).
hostapd v2.8-devel
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2019, Jouni Malinen <j@w1.fi> and contributors
Checking if hostapd is running, and what the interface and configuration file are
We recommend not running wpa_supplicant in the background when experimenting, to get an immediate display of any message from the application. Run in the background once you have validated your setup (use '-B' for running in background).
wlan0: SME: Trying to authenticate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: SME: Trying to authenticate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: PMKSA-CACHE-ADDED 00:0d:6f:73:91:57 0
wlan0: Trying to associate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: Associated with 00:0d:6f:73:91:57
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: WPA: Key negotiation completed with 00:0d:6f:73:91:57 [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:0d:6f:73:91:57 completed [id=0 id_str=]
STA: Checking wlan0 IP address
ip addr show wlan0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0d:6f:73:8a:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.45.109/24 brd 192.168.45.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80::108f:61b8:531f:3a20/64 scope link
valid_lft forever preferred_lft forever
Check that the IP address is within the range allocated via dnsmasq on the AP
WPA3 configuration fields table
The table below lists side-by-side parameters present in hostapd.conf and wpa_supplicant for a setup where a Linux platform is configured as AP while another Linux platform is configured as a STA associated with the AP.
These parameters correspond to the attached configuration files:
hostapd_WPA3_wlan0.conf
wpa_supplicant_WPA3.conf
Legend
User-modifiable fields
WPA3-forced fields
hostapd/wpa_supplicant configuration fields
hostapd_WPA3.conf
wpa_supplicant_WPA3.conf
comments
interface=wlan0
optional in hostapd config. Can be set via command line '-i' field
# The wpa field is a bit field that can be used to enable WPA/WPA2
# bit0 = WPA (IEEE 802.11i/D3.0)
# bit1 = WPA2 (IEEE 802.11i/RSN) (dot11RSNAEnabled)
# We don't use WPA: bit0 = 0
# WPA2 and WPA3 use RSN: bit1 = 1
# this leads to wpa=2 / proto=RSN
wpa_key_mgmt=SAE
key_mgmt=SAE
SAE = 'Simultaneous Authentication of Equals' for WPA3-Personal
rsn_pairwise=CCMP
pairwise=CCMP
# 2 'pairwise' fields are used for WPA or RSN: wpa_pairwise and rsn_pairwise
# we only use RSN, so only set rsn_pairwise
# the value is a space-separated list of accepted encryption algorithms
# CCMP = AES in Counter mode with CBC-MAC (CCMP-128)
With a CISCO AP AIR-AP1852E-E-K9, firmware 8.10.105.0 configured with WPA3 security and a Raspberry Pi with the SD-card 3.2 with BRD8022/23A with FW3.8.0 and the Driver WFX 2.5.2, you could get this with WPA3 security enabled:
First with a Wi-Fi scan, you should get SAE on the security used by the AP with WPA3:
Then using the wpa_supplicant_WPA3.conf above, we could get the association like below:
pi@rpi-123:~ $ wfx_sta --conf wpa_supplicant_WPA3.conf
Asking dhcpcd to control wlan0
Starting wpa_supplicant
Setting up connection
Waiting for connection Associated
Waiting for DHCP
DHCP lease obtained
Success: wlan0 connected to WPA3_000 with IP X.X.X.X
Then we could get the following status with wpa_cli:
We could check the status indicating key_mgmt=SAE and pmf=1 in bold above because it is associated with an AP using the WPA3 security.
Remarks:
WPA3 security is now mandatory for all Wi-Fi Alliance certified products but it is relatively new and not supported by all Access Point or station already installed or sold in 2020.
Please note WPA3 could be not supported with old wpa_supplicant release. We have tested successfully this with a Linux kernel 4.19.57-v7l+ and the wpa_supplicant release v2.8-devel.
When the host asks the WF200 or WFM200 to limit the Tx power, WF(M)200 adds FRONT_END_LOSS_TX_QDB from the requested value (see UG404 on the PDS file).
Hence:
if FRONT_END_LOSS_TX_QDB is 0, the host controls the power limitation at the output of the RF1 and RF2 pin of WF(M)200
if FRONT_END_LOSS_TX_QDB is set to antenna gain (negative value) and loss on the board or from a FEM (positive value), the host controls the limitation in EIRP
Note that the Linux hosts work with EIRP values. So, if WF(M)200 aims to work with a Linux host, FRONT_END_LOSS_TX_QDB should be set with the antenna gain.
Note also this is only a Tx output limitation and this limitation could be higher than the WF(M)200 Power Amplifier is allowed or able to transmit depending on RF certification constraint and backoff set in the PDS file according to the channel or the PHY rate.
Please find below a short list of things to check when targeting low current consumption when the Wi-Fi power save mode is enabled:
1) The LP_CLK (32.768KHz +/-1000ppm) has to be provided (not useful if you don't care about current consumption).
2) The frequency drift of LP_CLK within 1 second should be lower than +/-100ppm.
3) The WUP signal should be connected between the host and the WF(M)200.
4) The WUP and WIRQ management should be carefully done to optimize the current consumption (see the source code of WFX driver examples provided on Github).
When the host CPU is not sending frame to WF200 then the WUP pin should be low in order the WF200 stops the SPI or SDIO interface power consumption during the associated sleep time period (see AN1219 appendix B).
The SPI or SDIO clock should be stopped when the WUP pin is low.
5) The SPI or SDIO clock should be the highest (respectively 42MHz and 50MHz) to reduce data and management transfer time between the host and the WF(M)200.
6) The resistor pull-up on SDIO interface could increase the current consumption (should be in the host according to the SDIO standard).
7) The WF(M)200 GPIOs usage like FEM or PTA will add additional current consumption on WF(M)200.
8) All pull-up/pull-down resistors on used WF(M)200 GPIOs could impact greatly the average current consumption.
9) Power limitation in Tx or backoff usage could reduce the current consumption in TX (but this also reduces the coverage).
10) VDD_RF, VDD_D, VDD_IO could use 1.8V to reduce power consumption (or 3.3V) but VDD_PA uses only 3.3V nominal (see WF200 or WFM200 datasheet operating conditions).
VDD_IO could be only set to 1.8V If the SPI or SDIO host interface support 1.8V (check also this for other signals like WUP/WIRQ...).
Off course these previous items are some basics and the customer should take care to the host consumption and data traffic usage.
To reduce power consumption, it is recommended to use short high bit rate time slot for transmission or reception and then to be without data traffic during as long time duration as possible.
This points this an existing limitation/issue in the AllWinner SDIO HW/Driver combination related to SDIO IRQ masking.
This leads to 2 consecutive read of CONTROL, followed by 2 consecutive read of QUEUE.
As this (2 consecutive QUEUE read) is not expected by the FW, SDIO data (i.e. CRC) is incorrect, and the communication is stopped.
There are 2 possible error messages, depending on the first CRC location:
If the QUEUE length is short (below 24x bytes), there is only 1 CRC: the final one. The message is then related to a 'sunxi data error'.
If the QUEUE length is long (more than 24x bytes), there are intermediate CRCs. The message is then related to a 'wfx-sdio read error'
At the time of writing, no correction to the AllWinner 'sunxi-mmc' driver has been implemented, so the solution is to detect the double SDIO IRQs with the wfx driver and drop them.
A 'workaround/patch' has been created for this purpose.
Symptoms
The following error messages should make you consider applying the workaround patch if using SDIO with an AllWinner SoC:
sunxi-mmc 1c12000.mmc: data error, sending stop command
wfx-sdio mmc1:0001:1: wfx_data_read: bus communication error: -110
Workaround Patch
This patch suppresses consecutive reads of CONTROL and QUEUE. It can be applied on driver 2.4.
From 61e1e589ce720235ddd0e2d569c5d81fe155ed1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= <jerome.pouiller@silabs.com>
Date: Wed, 22 Apr 2020 10:10:30 +0200
Subject: [PATCH] bh: try to detect duplicated IRQs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bitThe allwinner architecture seems to have some race conditions while
masking the IRQs. So, in some case the IRQ is reported twice to the
driver, then the control register is read twice and data is read twice.Until now, the duplicated access to the control register always happens
before the access to the data (note that it does not prove it will be
always the case). Thus, it is easy to detect that pattern and drop the
faulty access.Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
bh.c | 5 +++++
hwio.c | 7 +++++++
wfx.h | 2 ++
3 files changed, 14 insertions(+)diff --git a/bh.c b/bh.c
index 55724e4295..dd6b4095d3 100644
--- a/bh.c
+++ b/bh.c
@@ -287,6 +287,10 @@ void wfx_bh_request_rx(struct wfx_dev *wdev)
u32 cur, prev;
control_reg_read(wdev, &cur);
+ if (cur == ~0) {
+ dev_warn(wdev->dev, "drop probably duplicated IRQ\n");
+ return;
+ }
prev = atomic_xchg(&wdev->hif.ctrl_reg, cur);
complete(&wdev->hif.ctrl_ready);
queue_work(system_highpri_wq, &wdev->hif.bh);
@@ -324,6 +328,7 @@ void wfx_bh_poll_irq(struct wfx_dev *wdev)
start = ktime_get();
for (;;) {
control_reg_read(wdev, ®);
+ wdev->last_read_reg_is_ctrl = false;
now = ktime_get();
if (reg & 0xFFF)
break;
diff --git a/hwio.c b/hwio.c
index 777217cdf9..ee2fbc112d 100644
--- a/hwio.c
+++ b/hwio.c
@@ -34,6 +34,11 @@ static int read32(struct wfx_dev *wdev, int reg, u32 *val)
*val = ~0; // Never return undefined value
if (!tmp)
return -ENOMEM;
+ if (reg == WFX_REG_CONTROL && wdev->last_read_reg_is_ctrl) {
+ kfree(tmp);
+ return 0;
+ }
+ wdev->last_read_reg_is_ctrl = !!(reg == WFX_REG_CONTROL);
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, tmp,
sizeof(u32));
if (ret >= 0)
@@ -149,6 +154,7 @@ static int indirect_read(struct wfx_dev *wdev, int reg, u32 addr,
goto err;
}
+ wdev->last_read_reg_is_ctrl = false;
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, buf, len);
err:
@@ -235,6 +241,7 @@ int wfx_data_read(struct wfx_dev *wdev, void *buf, size_t len)
WARN((long)buf & 3, "%s: unaligned buffer", __func__);
wdev->hwbus_ops->lock(wdev->hwbus_priv);
+ wdev->last_read_reg_is_ctrl = false;
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv,
WFX_REG_IN_OUT_QUEUE, buf, len);
_trace_io_read(WFX_REG_IN_OUT_QUEUE, buf, len);
diff --git a/wfx.h b/wfx.h
index 3ea3a41216..dbb4870ecc 100644
--- a/wfx.h
+++ b/wfx.h
@@ -101,6 +101,8 @@ struct wfx_dev {
struct hif_rx_stats rx_stats;
struct mutex rx_stats_lock;
+
+ bool last_read_reg_is_ctrl;
};
struct wfx_vif {
--
2.26.1
Please note that Zentri legacy WiFi modules (AMW007/AMW037/AMW006/AMW036/AMW106/AMW136) are pre-certified for IC, FCC, CE, and others. To obtain a copy of the certification report for various modules, please see: https://docs.zentri.com/zentri/docresources
For those interested in redoing the certification test, or interested in a certain RF test, we also provide a tool suite that we use for the full certification of our modules. However it involves reprogramming the modules with dedicated test firmware (please note that when using with AMW007/AMW037/AMW036/AMW006, it is not possible to put the original software back onto the modules).
There is a PDF in the docs directory that will guide you through the various test options.
The software runs on a standard windows 10 machine.
The setup requires an ATG002 (Piranha) board. If not available, you will need to purchase one from your local distributor. Ultimately, you will need to connect the ATG002 to your board. Look at the evaluation board schematics for the required connections. Once that is done, launch the "wl_gui.exe" tool, select the module type and firmware type ("RF") and click program. This will load the dedicated certification test firmware into the module.
After that, the rest of the options are fairly intuitive. We have used this tool with multiple different test houses.
Gecko OS Studio access a few different public domains to perform tasks such as logging in, downloading the SDK and interfacing to DMS. Often, corporate firewalls can block access to these domains. Below is a list of sites that Gecko OS Studio touches. All services use HTTPS on the standard port 443. Typically, issues related to this are solved with the help of the corporate IT department by whitelisting these URLs for the Gecko OS Studio application.
On Linux platforms, devices are physically connected to buses and the device tree needs to reflect this for device to be detected.
It is important to debug device tree issues at startup. To achieve this, a very convenient tool is dtc (aka 'device tree compiler').
Keep in mind that any change to the device tree is only taken into account on the next reboot, so changing the device tree means rebooting!
Installing dtc
Installing dtc on the target machine is convenient, but may not be allowed on the target. We describe below an alternative solution, where dtc is installed on another machine.
apt-get install device-tree-compiler
Retrieving the current device tree rather than looking at the sources
The point with device tree is that looking at the sources (.dts/.dtsi) files you don't really have the view the host has on the final device tree.
To cope with this, we recommend looking at the 'device tree seen by the host', directly from the file system at /sys/firmware/devicetree/base/
This reflects the device tree content after editing/compiling/booting
NB: The 'dts' format allows the resulting file to be edited in a human-readable format. If edited as if it were a C file you can benefit from code folding to get a better view of the contents. With the '--sort' option, comparing device trees is much easier.
Retrieving the device tree without dtc support on your platform
On your platform
Create an archive from your file system's device tree
tar zcf device_tree.tar.gz /sys/firmware/devicetree/base/
Copy this file to a platform supporting dtc
On a platform supporting dtc
decompress the archive
retrieve the device tree using dtc from the new directory (note how the path starts with 'sys' instead of '/sys' here, since the entire content has been extracted locally)
NB: Checking the device tree from the file system rather than from the .dtb file is safer, since it removes the risk of using the wrong file. The file system content is 'what the kernel sees'.
Debugging device tree issues by comparison
Once you have 2 different files before/after adding your device tree you can easily diff them and spot all differences brought in by your .dts/.dtsi source files.
In case of potential device tree issues, make sure all the changes you expect are visible, otherwise you may be facing issues in your .dts/.dtsi source files.
Checking device tree at runtime
$ sudo vcdbg log msg
will allow you to check which device tree file is loaded at boot.
Adding
dtdebug=1
to /boot/config.txt will add more details on the next boot.
The purpose of this guide is to help Gecko OS developers configure Azure Device Service (DPS) and write Gecko OS application to provision WGM160P device(s) into Azure using DPS
Note: Azure DPS is only supported starting from Gecko OS 4.1
1. Introduction
“The IoT Hub Device Provisioning Service is a helper service for IoT Hub that enables zero-touch, just-in-time provisioning to the right IoT hub without requiring human intervention, allowing customers to provision millions of devices in a secure and scalable manner.” – definition by Microsoft
The general overview of the process is defined as the following:
Device manufacturer adds the device registration information to the enrollment list in the Azure portal.
Device contacts the provisioning service endpoint set at the factory. The device passes the identifying information to the provisioning service to prove its identity.
The provisioning service validates the identity of the device by validating the registration ID and key against the enrollment list entry using standard X.509 verification (X.509).
The provisioning service registers the device with an IoT hub and populates the device's desired twin state.
The IoT hub returns device ID information to the provisioning service.
The provisioning service returns the IoT hub connection information to the device. The device can now start sending data directly to the IoT hub.
The device connects to IoT hub.
The device gets the desired state from its device twin in IoT hub.
2. Create and Configure DPS via Azure IoT Portal
2.1. Create an IoT Hub (if you do not have already)
For Provisioning Host, enter the Global device endpoint of your DPS (obtained above)
For ID Scope, enter the ID Scope for your DPS (obtained above)
For Certificate, paste in your generated certificate (e.g., root_private.pem obtained above)
For RSA Private Key, paste in your generated key (e.g., root_cert.pem obtained above)
Click Save
The created connector is linked to your product, and any device activated to this product can communicate with it.
4. Device side: Gecko OS Application
Note: Gecko OS example app source code is released as a part of Gecko OS SDK 4.1.11. Once you have the SDK downloaded, you can find it under: sdk\standard\wgm160p\4.1.11-7064\applications\gecko_os\cloud\dps_demo
Now you have a connector ready and DPS configured in Azure, it is the time to send a provisioning request from the device side to the DMS connector. DMS in turn sends the request to Azure and returns back the device certificate and key. Once device obtains the cert and key pair, it encrypts and stores them securely on the file system then using them for farther communication with Azure IoT Hub. The DPS and DMS connector are done at this stage
Note: This part assumes basic knowledge of development using Gecko OS. For more info, please head to the online doc:
Activate device to the product created above (since, it can use the connector). This is not done automatically in the example app and you need to do that using the standard dms_activate command. More here: https://dms.zentri.com/tutorial/activate-to-product
In Gecko OS, enable the DMS websocket to automatically start when the network is brought up (please see resources\settings.ini file where this setting is already enabled):
set dms.auto_start_enabled 1
Configure the different application custom variables:
dps.connector: DMS connector code (make sure your device is activated)
dps.hostname: Hostname or IP address of the broker/server
dps.port: Port of the provisioning server/broker"
dps.ca_cert: CA cert filename used for TLS verification request
dps.key_filename: Filename used to store the client certificate (if provisioning succeeded)
dps.key_filename: Filename used to store the client key (if provisioning succeeded)
Configure the network credentials: wlan.ssid and wlan.passkey, then save all.
Now, issue the custom command dps_provision
Device establishes a secure websocket connection with DMS using its own device cert.
Device registers for DMS message responses
Once device connects to DMS websocket, app sends a provisioning request in the form:
{
request: 'provision',
code: code
}
DMS gets the request (including the device UUID as an identifier), then talks to Azure to provision the device in IoT Hub
If successful, Azure replies back with the device cert/key pair
DMS responds to the provision request with the device cert/key pair. The response format looks like:
Device retrieves the cert and key, then write them to the file system securely (files defined by dps.key_filename and dps.cert_filename)
Device disconnects
To verify the provisioning process, use the custom command dps_verify. This will use the obtained cert and key files, in addition to the configured CA cert to establish a TLS connection to the host defined by dps.hostname:dps.port
Later, when device wants to communicate with Azure IoT Hub, it establishes TLS connection using the client key and cert. That is done as the following:
set network.tls.client_cert azure_client_cert.pem
set network.tls.client_key azure_client_key.pem
tls_client .azure-devices.net 8883
In this test, we used WGM160P mounted on WSTK, the default evaluation starer kit. For more info, please refer to: WGM160P Wi-Fi Module Starter Kit
The current measurement is averaged over 60 to 100 seconds (captured 1-minute after associating, or not in case of sleep/shutdown)
We use used Cisco Linksys WRT610N access point configured with 100ms beacon interval and default beacon duration
For the WLAN power saving move, we use used Alfa access point configured with beacon interval 102.4ms and 1ms duration (Cisco Linksys WRT610N used for the default, sleep, and shutdown measurements)
The measurements below obtained for the current official release (at the time of writing this article), in addition to the new alpha and beta releases for coming Gecko OS 4.1
To get access to Gecko OS BETA, please issue the command: dfu_update -b 4.1.10 --multi
Note: do not use a “listen interval” higher than 3 to avoid potential issue with some Access Points.
Note: Listen interval higher than 0 uses DTIM skipping and so this could add jitters/delay on the packet arrival time.
Measurements
ON BOOTUP/DEFAULT
get wlan.mac
factory_reset <MAC_ADDRESS>
Gecko OS 4.0.18
Gecko OS 4.1.9 ALPHA
Gecko OS 4.1.10 BETA
16 mA
5.20 mA
5.17 mA (Figure 1)
UART & WLAN POWERSAVE
set wlan.powersave.mode 2
set uart.powersave.mode uart0:1,uart1:1
set system.powersave.wakeup_gpio_mask 0x1000000
set system.powersave.idle_timeout 250
set system.powersave.mode 2
set wlan.ssid LINKSYS
set wlan.passkey password
set broadcast.interval 0
uartu 0
nup
Gecko OS 4.1.10 BETA
Listen Interval 0*
Listen Interval 3*
Listen Interval 5*
DTIM 1 Alfa AP
Beacon duration 1ms
920 µA
632 µA
576 µA
DTIM 3 Alfa AP
Beacon duration 1ms
666 µA
560 µA
550 µA
DTIM 10 Alfa AP
Beacon duration 1ms
558 µA
521 µA
520 µA
* : Listen Interval set the number of DTIM beacon which will be skipped (not Received).
** : ping timeout possible because of delay on the packet arrival time
SLEEP
set uart.powersave.mode uart0:1,uart1:1
set system.powersave.wakeup_gpio_mask 0x1000000
set system.powersave.idle_timeout 250
set system.powersave.mode 2
uartu 0
Gecko OS 4.0.18
Gecko OS 4.1.9 ALPHA
Gecko OS 4.1.10 BETA
N/A
530 µA
530 µA (Figure 5)
SHUTDOWN
set system.shutdown.wakeup_gpio_mask 0x4004000
shutdown
Gecko OS 4.0.18
Gecko OS 4.1.9 ALPHA
Gecko OS 4.1.10 BETA
N/A
990 nA
940 nA (Figure 6)
Figures
Figure 1: ON BOOTUP/DEFAULT (Gecko OS 4.1.10)
Figure 2: UART/WLAN POWERSAVE (Gecko OS 4.1.10 LINKSYS DITM1)
Figure 3: UART/WLAN POWERSAVE (Gecko OS 4.1.10 LINKSYS DITM3)
Figure 4: UART/WLAN POWERSAVE (Gecko OS 4.1.10 LINKSYS DITM10)
Wi-Fi Knowledge Base
WF(M)200 : Linux WPA3 configuration
Linux: Configuring WF(M)200 for WPA3
WF(200) can be used with Linux in WPA3 in both AP (Access Point) and STA (STAtion) modes using Linux standard commands.
This article provides generic (i.e. not specific to WF(M)200) information on the Linux configuration of a WPA3 AP as well as a WPA3 STA. You can set up 2 boards and connect them together over WPA3 Wi-Fi.
Pre-requisites
WPA3 is working as from
Please update to the above minimal versions before using WPA3 with WF(M)200.
AP (Access Point)
The AP uses hostapd, configured via the hostapd_WPA3_wlan0.conf file.
AP: Allocating an IP address to wlan0
sudo dhcpcd --release wlan0 sudo ip addr flush dev wlan0 sudo ip addr add 192.168.45.1/24 dev wlan0AP: Checking wlan0 IP address
ip addr show wlan0AP: DHCP/DNS setup using dnsmasq: allocating an IP address range to wlan0 clients
sudo killall dnsmasq sudo dnsmasq --conf-file=/dev/null --interface=wlan0 --bind-interfaces --except-interface=lo --dhcp-range=192.168.45.100,192.168.45.200AP interface selection
The AP wlan interface is selectable in the hostapd command line, as the '-i' (list of interface names to use) field. It can also be hard-coded in the hostapd_WPA3.conf file.
Typical hostapd command line (in the context of our Raspberry Pi demo, user 'pi' (requiring 'sudo'))
sudo killall hostapdsudo hostapd -i wlan0 hostapd_WPA3.confAP configuration
Refer to the attached hostapd_WPA3.conf file. Refer to https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf for details of hostapd configuration.
AP Checks (on the AP)
Checking hostapd version (tested with v2.8-devel)
hostapd -vChecking if hostapd is running, and what the interface and configuration file are
ps -few | grep hostapdChecking active lines in hostapd configuration (skipping empty lines and comment lines)
cat hostapd_wpa3.conf | grep -v ^$ | grep -v ^#Checking hostapd status
hostapd_cli statusChecking hostapd configuration
hostapd_cli get_configExternal AP checks (from a Linux Wi-Fi STAtion)
wpa_cli scanwpa_cli scan_resultsAP hostapd messages during STA association
STA (STAtion)
The STA uses wpa_supplicant, configured via the wpa_supplicant_WPA3.conf file.
STA interface selection
The STA wlan interface is selected in the wpa_supplicant command line, as the '-i' (= interface name) field
Typical wpa_supplicant command line (in the context of our Raspberry Pi demo, user 'pi')
sudo killall wpa_supplicant sudo wpa_supplicant -i wlan0 -c wpa_supplicant_WPA3.confSTA configuration
Refer to the attached wpa_supplicant_WPA3.conf file. Refer to https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf for details of wpa_supplicant configuration.
STA Checks (on the STA)
Checking wpa_supplicant version (tested with 2.8-devel)
wpa_supplicant -vChecking if wpa_supplicant is running, and what the interface and configuration file are
ps -few | grep wpa_supplicantChecking active lines in wpa_supplicant configuration (skipping empty lines and comment lines)
cat wpa_supplicant_WPA3.conf | grep -v ^$ | grep -v ^#Checking wpa_supplicant status
wpa_cli statusSTA wpa_supplicant messages upon connection
STA: Checking wlan0 IP address
ip addr show wlan0WPA3 configuration fields table
The table below lists side-by-side parameters present in hostapd.conf and wpa_supplicant for a setup where a Linux platform is configured as AP while another Linux platform is configured as a STA associated with the AP.
These parameters correspond to the attached configuration files:
Legend
# bit0 = WPA (IEEE 802.11i/D3.0)
# bit1 = WPA2 (IEEE 802.11i/RSN) (dot11RSNAEnabled)
# We don't use WPA: bit0 = 0
# WPA2 and WPA3 use RSN: bit1 = 1
# this leads to wpa=2 / proto=RSN
# we only use RSN, so only set rsn_pairwise
# the value is a space-separated list of accepted encryption algorithms
# CCMP = AES in Counter mode with CBC-MAC (CCMP-128)
# PMF required: ieee80211w=2
# WPA3-Personal-only mode: ieee80211w=2 / key_mgmt=SAE
# wpa_passphrase is an ASCII passphrase, converted to PSK (Pre-Shared Key)
Double quotes required in wpa_supplicant.conf
WF(M)200 : Linux wpa_supplicant.conf to be associated with a Wi-Fi Access Point in WPA3
In order to use the WPA3 with the WF(M)200 through Linux, you could use the following wpa_supplicant.conf:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="WPA3_000"
psk="xxxxxxxxxxxxx"
key_mgmt= SAE
proto=RSN
pairwise=CCMP
group=CCMP
ieee80211w=2
}
Note ieee80211w could be set to 1 or 2. See the definition of the parameters in the https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf
With a CISCO AP AIR-AP1852E-E-K9, firmware 8.10.105.0 configured with WPA3 security and a Raspberry Pi with the SD-card 3.2 with BRD8022/23A with FW3.8.0 and the Driver WFX 2.5.2, you could get this with WPA3 security enabled:
First with a Wi-Fi scan, you should get SAE on the security used by the AP with WPA3:
pi@rpi-123:~ $ wfx_sta --scan
Starting wpa_supplicant
Scanning access points...
bssid / frequency / signal level / flags / ssid
x:x:x:x:x:x 2462 -43 [WPA2-PSK+SAE-CCMP][ESS] WPA3_000
...
Then using the wpa_supplicant_WPA3.conf above, we could get the association like below:
pi@rpi-123:~ $ wfx_sta --conf wpa_supplicant_WPA3.conf
Asking dhcpcd to control wlan0
Starting wpa_supplicant
Setting up connection
Waiting for connection
Associated
Waiting for DHCP
DHCP lease obtained
Success: wlan0 connected to WPA3_000 with IP X.X.X.X
Then we could get the following status with wpa_cli:
pi@rpi-123:~ $ wpa_cli status
Selected interface 'wlan0'
bssid=xx:xx:xx:xx:xx:xx
freq=2462
ssid=WPA3_000
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=SAE
pmf=1
mgmt_group_cipher=BIP
sae_group=19
wpa_state=COMPLETED
ip_address=X.X.X.X
We could check the status indicating key_mgmt=SAE and pmf=1 in bold above because it is associated with an AP using the WPA3 security.
Remarks:
WF(M)200 : Explanations how the Wi-Fi power limitation from the Host is applied
When the host asks the WF200 or WFM200 to limit the Tx power, WF(M)200 adds FRONT_END_LOSS_TX_QDB from the requested value (see UG404 on the PDS file).
Hence:
if FRONT_END_LOSS_TX_QDB is 0, the host controls the power limitation at the output of the RF1 and RF2 pin of WF(M)200
if FRONT_END_LOSS_TX_QDB is set to antenna gain (negative value) and loss on the board or from a FEM (positive value), the host controls the limitation in EIRP
Note that the Linux hosts work with EIRP values. So, if WF(M)200 aims to work with a Linux host, FRONT_END_LOSS_TX_QDB should be set with the antenna gain.
Note also this is only a Tx output limitation and this limitation could be higher than the WF(M)200 Power Amplifier is allowed or able to transmit depending on RF certification constraint and backoff set in the PDS file according to the channel or the PHY rate.
WF200, WFM200 current consumption : list of things to take care
Please find below a short list of things to check when targeting low current consumption when the Wi-Fi power save mode is enabled:
1) The LP_CLK (32.768KHz +/-1000ppm) has to be provided (not useful if you don't care about current consumption).
2) The frequency drift of LP_CLK within 1 second should be lower than +/-100ppm.
3) The WUP signal should be connected between the host and the WF(M)200.
4) The WUP and WIRQ management should be carefully done to optimize the current consumption (see the source code of WFX driver examples provided on Github).
5) The SPI or SDIO clock should be the highest (respectively 42MHz and 50MHz) to reduce data and management transfer time between the host and the WF(M)200.
6) The resistor pull-up on SDIO interface could increase the current consumption (should be in the host according to the SDIO standard).
7) The WF(M)200 GPIOs usage like FEM or PTA will add additional current consumption on WF(M)200.
8) All pull-up/pull-down resistors on used WF(M)200 GPIOs could impact greatly the average current consumption.
9) Power limitation in Tx or backoff usage could reduce the current consumption in TX (but this also reduces the coverage).
10) VDD_RF, VDD_D, VDD_IO could use 1.8V to reduce power consumption (or 3.3V) but VDD_PA uses only 3.3V nominal (see WF200 or WFM200 datasheet operating conditions).
VDD_IO could be only set to 1.8V If the SPI or SDIO host interface support 1.8V (check also this for other signals like WUP/WIRQ...).
Off course these previous items are some basics and the customer should take care to the host consumption and data traffic usage.
To reduce power consumption, it is recommended to use short high bit rate time slot for transmission or reception and then to be without data traffic during as long time duration as possible.
The AN1219 provides some additional details about this (see https://www.silabs.com/documents/public/application-notes/an1219-power-consumption-wfm200.pdf).
KBA: WF200/WFM200 Linux Driver with AllWinner SoC (SDIO)
WF200/WFM200 Linux Driver with AllWinner SoC (SDIO)
The information in this article is specific to using the wfx driver in SDIO with AllWinner SoCs on Linux.
The allwinner architecture seems to have some race conditions while masking the SDIO IRQs.
In some case the IRQ is reported twice to the wfx driver, then the control register is read twice and data is read twice.
This subject is discussed in this Linux Kernel discussion Thread
This points this an existing limitation/issue in the AllWinner SDIO HW/Driver combination related to SDIO IRQ masking.
This leads to 2 consecutive read of CONTROL, followed by 2 consecutive read of QUEUE.
As this (2 consecutive QUEUE read) is not expected by the FW, SDIO data (i.e. CRC) is incorrect, and the communication is stopped.
There are 2 possible error messages, depending on the first CRC location:
At the time of writing, no correction to the AllWinner 'sunxi-mmc' driver has been implemented, so the solution is to detect the double SDIO IRQs with the wfx driver and drop them.
A 'workaround/patch' has been created for this purpose.
Symptoms
The following error messages should make you consider applying the workaround patch if using SDIO with an AllWinner SoC:
sunxi-mmc 1c12000.mmc: data error, sending stop command
wfx-sdio mmc1:0001:1: wfx_data_read: bus communication error: -110
Workaround Patch
This patch suppresses consecutive reads of CONTROL and QUEUE. It can be applied on driver 2.4.
Zentri Classic/Legacy Module Setup for Certification Testing
Please note that Zentri legacy WiFi modules (AMW007/AMW037/AMW006/AMW036/AMW106/AMW136) are pre-certified for IC, FCC, CE, and others. To obtain a copy of the certification report for various modules, please see: https://docs.zentri.com/zentri/docresources
For those interested in redoing the certification test, or interested in a certain RF test, we also provide a tool suite that we use for the full certification of our modules. However it involves reprogramming the modules with dedicated test firmware (please note that when using with AMW007/AMW037/AMW036/AMW006, it is not possible to put the original software back onto the modules).
You can download the certification test package from: https://resources.zentri.com/documentation/certs/ZentriClassicCertificationTesting.zip
There is a PDF in the docs directory that will guide you through the various test options.
The software runs on a standard windows 10 machine.
The setup requires an ATG002 (Piranha) board. If not available, you will need to purchase one from your local distributor. Ultimately, you will need to connect the ATG002 to your board. Look at the evaluation board schematics for the required connections. Once that is done, launch the "wl_gui.exe" tool, select the module type and firmware type ("RF") and click program. This will load the dedicated certification test firmware into the module.
After that, the rest of the options are fairly intuitive. We have used this tool with multiple different test houses.
Running Gecko OS Studio on a corporate network
Gecko OS Studio access a few different public domains to perform tasks such as logging in, downloading the SDK and interfacing to DMS. Often, corporate firewalls can block access to these domains. Below is a list of sites that Gecko OS Studio touches. All services use HTTPS on the standard port 443. Typically, issues related to this are solved with the help of the corporate IT department by whitelisting these URLs for the Gecko OS Studio application.
KBA: Linux Device Tree Debugging
Device tree debugging
On Linux platforms, devices are physically connected to buses and the device tree needs to reflect this for device to be detected.
It is important to debug device tree issues at startup. To achieve this, a very convenient tool is dtc (aka 'device tree compiler').
Installing dtc
apt-get install device-tree-compilerRetrieving the current device tree rather than looking at the sources
The point with device tree is that looking at the sources (.dts/.dtsi) files you don't really have the view the host has on the final device tree.
To cope with this, we recommend looking at the 'device tree seen by the host', directly from the file system at /sys/firmware/devicetree/base/
Retrieving the device tree using dtc
Retrieving the device tree without dtc support on your platform
Retrieving the device tree from the .dtb (device tree blob) file
As a last resort, get the .dtb file used at boot and decompile it using dtc on a platform supporting it.
Debugging device tree issues by comparison
Once you have 2 different files before/after adding your device tree you can easily diff them and spot all differences brought in by your .dts/.dtsi source files.
In case of potential device tree issues, make sure all the changes you expect are visible, otherwise you may be facing issues in your .dts/.dtsi source files.
Checking device tree at runtime
will allow you to check which device tree file is loaded at boot.
Adding
dtdebug=1
to /boot/config.txt will add more details on the next boot.
Working with Azure DPS in Gecko OS
The purpose of this guide is to help Gecko OS developers configure Azure Device Service (DPS) and write Gecko OS application to provision WGM160P device(s) into Azure using DPS
Note: Azure DPS is only supported starting from Gecko OS 4.1
1. Introduction
“The IoT Hub Device Provisioning Service is a helper service for IoT Hub that enables zero-touch, just-in-time provisioning to the right IoT hub without requiring human intervention, allowing customers to provision millions of devices in a secure and scalable manner.” – definition by Microsoft
The general overview of the process is defined as the following:
Device manufacturer adds the device registration information to the enrollment list in the Azure portal.
Device contacts the provisioning service endpoint set at the factory. The device passes the identifying information to the provisioning service to prove its identity.
The provisioning service validates the identity of the device by validating the registration ID and key against the enrollment list entry using standard X.509 verification (X.509).
The provisioning service registers the device with an IoT hub and populates the device's desired twin state.
The IoT hub returns device ID information to the provisioning service.
The provisioning service returns the IoT hub connection information to the device. The device can now start sending data directly to the IoT hub.
The device connects to IoT hub.
The device gets the desired state from its device twin in IoT hub.
2. Create and Configure DPS via Azure IoT Portal
2.1. Create an IoT Hub (if you do not have already)
Go to your Azure Portal: https://portal.azure.com, and sign in using your Azure account.
Click Create a resource
Click Internet of Things
Click IoT Hub
Fill out the form and click Create
Once created, head to the Overview tab and take a note of the "Hostname". That will be used later in the application (i.e., dps.hostname)
2.2. Create an IoT Hub Device Provisioning Service
Same as before: Azure Portal > Create a resource > Internet of Things
This time choose IoT Hub Device Provisioning Service
Fill out the required fields and click Create
2.3. Link the IoT Hub to your Device Provisioning Service
Click the DPS instance that you created (you can access it from All resources link to the left)
Click Linked IoT hubs
Click Add
Select your IoT hub and Save
2.4. Create a Certificate for your Device Provisioning Service
You need a .pem file that contains an intermediate or root CA X.509 certificate. We use OpenSSL here to create the CA cert:
Generate root key and X509 cert
Note: the validity for this cert is set to 10 years. Change if you want a longer/shorter lifetime
Press enter for default values
Create verification key:
2.5. Upload the Certificate to your Device Provisioning Service
Open your instance of Device Provisioning Service instance
Click Certificates
Click Add.
Give it a name of your choice in the Certificate Name field
Upload your certificate (root_cert.pem) and click Save
2.6. Verify the Certificate
Click the certificate you’ve just created
Click Generate Verification Code. That will generate a 48 characters length code. Take a note of it.
Using the code, create the verification cert:
Press enter to choose default parameters.
For "Common Name", use the verification code obtained above
Create the proof of possession certificate:
This will sign the verification.csr, that has the verification code as the Common Name, with the root private key.
Upload your verification certificate verificationCert.pem as a proof of possession, and click Verify
2.7. Create an Enrollment Group
Open your instance of Device Provisioning Service instance
Click Manage enrollments
Click Enrollment Groups
Click Add
Fill out the form and click Save
2.8. Take a note of your DPS details
Open your instance of Device Provisioning Service instance
Click Overview
Take note of the Global device endpoint and ID Scope. Those parameters will be used in the following steps.
3. Create a DMS Connector
Now you have created and configured your DPS, it is the time to create a “connector” and link it to your DPS instance
Notes:
For more about DMS connectors, please have a look at the tutorial here: https://dms.zentri.com/tutorial/connectors
This step assumes you have already a product created. If not, please follow the tutorial here: https://dms.zentri.com/tutorial/create-product
Go to the DMS: https://dms.zentri.com/
Click Products
Choose your product out of the list
Click Connectors
Click Create Connector
Fill out the form:
For Type, select Provision
For Endpoint, select Azure IoT Hub
For Provisioning Host, enter the Global device endpoint of your DPS (obtained above)
For ID Scope, enter the ID Scope for your DPS (obtained above)
For Certificate, paste in your generated certificate (e.g., root_private.pem obtained above)
For RSA Private Key, paste in your generated key (e.g., root_cert.pem obtained above)
Click Save
The created connector is linked to your product, and any device activated to this product can communicate with it.
4. Device side: Gecko OS Application
Note: Gecko OS example app source code is released as a part of Gecko OS SDK 4.1.11. Once you have the SDK downloaded, you can find it under: sdk\standard\wgm160p\4.1.11-7064\applications\gecko_os\cloud\dps_demo
Now you have a connector ready and DPS configured in Azure, it is the time to send a provisioning request from the device side to the DMS connector. DMS in turn sends the request to Azure and returns back the device certificate and key. Once device obtains the cert and key pair, it encrypts and stores them securely on the file system then using them for farther communication with Azure IoT Hub. The DPS and DMS connector are done at this stage
Note: This part assumes basic knowledge of development using Gecko OS. For more info, please head to the online doc:
https://docs.silabs.com/gecko-os/4/standard/latest/
https://docs.silabs.com/gecko-os/4/standard/latest/cmd/
https://docs.silabs.com/gecko-os/4/standard/latest/sdk/
Activate device to the product created above (since, it can use the connector). This is not done automatically in the example app and you need to do that using the standard dms_activate command. More here: https://dms.zentri.com/tutorial/activate-to-product
In Gecko OS, enable the DMS websocket to automatically start when the network is brought up (please see resources\settings.ini file where this setting is already enabled):
Configure the different application custom variables:
dps.connector: DMS connector code (make sure your device is activated)
dps.hostname: Hostname or IP address of the broker/server
dps.port: Port of the provisioning server/broker"
dps.ca_cert: CA cert filename used for TLS verification request
dps.key_filename: Filename used to store the client certificate (if provisioning succeeded)
dps.key_filename: Filename used to store the client key (if provisioning succeeded)
Configure the network credentials: wlan.ssid and wlan.passkey, then save all.
Now, issue the custom command dps_provision
Device establishes a secure websocket connection with DMS using its own device cert.
Device registers for DMS message responses
Once device connects to DMS websocket, app sends a provisioning request in the form:
{ request: 'provision', code: code }DMS gets the request (including the device UUID as an identifier), then talks to Azure to provision the device in IoT Hub
If successful, Azure replies back with the device cert/key pair
DMS responds to the provision request with the device cert/key pair. The response format looks like:
{ "assignedHub": "my-iot-hub.azure-devices.net", "deviceId": "ffffffffffffffffffffffffffffffffffffffff", "cert": "-----BEGIN CERTIFICATE-----\n<...>\n-----END CERTIFICATE-----", "key": "-----BEGIN RSA PRIVATE KEY-----\n<...>\n-----END RSA PRIVATE KEY-----" }Device retrieves the cert and key, then write them to the file system securely (files defined by dps.key_filename and dps.cert_filename)
Device disconnects
To verify the provisioning process, use the custom command dps_verify. This will use the obtained cert and key files, in addition to the configured CA cert to establish a TLS connection to the host defined by dps.hostname:dps.port
Later, when device wants to communicate with Azure IoT Hub, it establishes TLS connection using the client key and cert. That is done as the following:
For more details about Gecko OS TLS client: https://docs.silabs.com/gecko-os/4/standard/latest/networking-and-security#tls-client
Appendix:
The console log of the example app should look like:
WGM160P Power Consumption using Gecko OS (Setup and Results)
Introduction
In this article, we describe how to configure Gecko OS running on WGM160P to obtain the lowest current results.
If you are interested in WF200/WFM200, please refer to the article: How to do current measurements on WF(M)200
In this test, we used WGM160P mounted on WSTK, the default evaluation starer kit. For more info, please refer to: WGM160P Wi-Fi Module Starter Kit
The current measurement is averaged over 60 to 100 seconds (captured 1-minute after associating, or not in case of sleep/shutdown)
We use used Cisco Linksys WRT610N access point configured with 100ms beacon interval and default beacon duration
For the WLAN power saving move, we use used Alfa access point configured with beacon interval 102.4ms and 1ms duration (Cisco Linksys WRT610N used for the default, sleep, and shutdown measurements)
For more details on how to setup the Energy Profiler to detect WGM160P, please refer to the article: Configure AEM/Energy Profiler to work with WGM160P
The measurements below obtained for the current official release (at the time of writing this article), in addition to the new alpha and beta releases for coming Gecko OS 4.1
To get access to Gecko OS BETA, please issue the command: dfu_update -b 4.1.10 --multi
Note: do not use a “listen interval” higher than 3 to avoid potential issue with some Access Points.
Note: Listen interval higher than 0 uses DTIM skipping and so this could add jitters/delay on the packet arrival time.
Measurements
ON BOOTUP/DEFAULT
get wlan.mac
factory_reset <MAC_ADDRESS>
Gecko OS 4.0.18
Gecko OS 4.1.9 ALPHA
Gecko OS 4.1.10 BETA
16 mA
5.20 mA
5.17 mA (Figure 1)
UART & WLAN POWERSAVE
set wlan.powersave.mode 2
set uart.powersave.mode uart0:1,uart1:1
set system.powersave.wakeup_gpio_mask 0x1000000
set system.powersave.idle_timeout 250
set system.powersave.mode 2
set wlan.ssid LINKSYS
set wlan.passkey password
set broadcast.interval 0
uartu 0
nup
Beacon duration 1ms
Beacon duration 1ms
Beacon duration 1ms
* : Listen Interval set the number of DTIM beacon which will be skipped (not Received).
** : ping timeout possible because of delay on the packet arrival time
SLEEP
set uart.powersave.mode uart0:1,uart1:1
set system.powersave.wakeup_gpio_mask 0x1000000
set system.powersave.idle_timeout 250
set system.powersave.mode 2
uartu 0
Gecko OS 4.0.18
Gecko OS 4.1.9 ALPHA
Gecko OS 4.1.10 BETA
N/A
530 µA
530 µA (Figure 5)
SHUTDOWN
set system.shutdown.wakeup_gpio_mask 0x4004000
shutdown
Gecko OS 4.0.18
Gecko OS 4.1.9 ALPHA
Gecko OS 4.1.10 BETA
N/A
990 nA
940 nA (Figure 6)
Figures
Figure 1: ON BOOTUP/DEFAULT (Gecko OS 4.1.10)
Figure 2: UART/WLAN POWERSAVE (Gecko OS 4.1.10 LINKSYS DITM1)
Figure 3: UART/WLAN POWERSAVE (Gecko OS 4.1.10 LINKSYS DITM3)
Figure 4: UART/WLAN POWERSAVE (Gecko OS 4.1.10 LINKSYS DITM10)
Figure 5: SLEEP (Gecko OS 4.1.10)
Figure 6: SHUTDOWN (Gecko OS 4.1.10)