Resolving Edimax EW-7811Un V2 WiFi Detection on Siemens IOT2050

David Krause16 min read
Industrial NetworkingSiemensTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Resolving Edimax EW-7811Un V2 WiFi Detection on Siemens SIMATIC IOT2050

The Edimax EW-7811Un V2 USB WiFi adapter is widely used as a low-cost wireless companion for industrial edge gateways, but on the Siemens SIMATIC IOT2050 the device is invisible to the networking stack by default. The V1 (RTL8188CUS) is recognised out of the box because the Siemens meta-iot2050 BSP enables CONFIG_RTL8192CU=m in its defconfig. The V2 (RTL8188EU) is not enumerated as a wireless interface because the matching CONFIG_RTL8188EU=m symbol is not set in the IOT2050 kernel configuration, and no out-of-tree recipe is shipped with the BSP. This reference documents the chipset difference, the kernel configuration symbol that must be added, the full Yocto build path, runtime loading, ConnMan and NetworkManager configuration, and the field-proven alternatives if a Yocto rebuild is not possible.

1. Problem Overview and Symptoms

When an Edimax EW-7811Un V2 is plugged into either of the two USB 2.0 Type-A host ports on the SIMATIC IOT2050, the symptoms are:

  • lsusb shows the device as 7392:b811 Edimax Technology Co., Ltd.
  • No wireless interface (wlan0, wlp1s0u1 or similar) is created.
  • ip link lists only lo, eth0 and eth1.
  • rfkill list shows no WiFi radio.
  • journalctl -k contains no probe attempt and no error message for 8188eu.
  • ConnMan and NetworkManager both report no WiFi technology available.

From the kernel's perspective, an unbound USB device is a normal condition, so the IOT2050 does not log an explicit error. The networking stack simply never sees the radio. The fix is to add the missing kernel module to the image. The two practical workarounds are:

  1. Add CONFIG_RTL8188EU=m to iot2050_defconfig_extra.cfg in the meta-iot2050 layer and rebuild the image. This is the supported, production-grade route.
  2. Build the 8188eu module out of tree against the running kernel, copy it onto the IOT2050 and insmod it. This works for a quick field test but is not maintainable across BSP updates.

2. Hardware Identification: Edimax EW-7811Un V1 vs V2

The two revisions are physically identical and ship in similar blister packaging. Confirm the revision before applying any workaround; the wrong chipset driver will claim the wrong hardware and produce no interface.

Edimax EW-7811Un revision comparison
Parameter EW-7811Un (V1) EW-7811Un V2
USB vendor:product ID 0x7392:0x7811 0x7392:0xb811
Realtek chipset RTL8188CUS RTL8188EU
Linux in-tree driver symbol CONFIG_RTL8192CU CONFIG_RTL8188EU
Out-of-tree driver rtl8192cu, included lwfinger/rtl8188eu
Default IOT2050 image support Yes (module is built) No (module not built)
Max PHY rate (2.4 GHz) 150 Mbps (1T1R, 802.11n) 150 Mbps (1T1R, 802.11n)
Connector USB 2.0 Type-A, nano form factor USB 2.0 Type-A, nano form factor
External antenna None None
Edimax SKU label marking EW-7811Un EW-7811Un V2

Confirm the product on the running IOT2050:

lsusb | grep -i 7392

For the V1 the output contains 7392:7811. For the V2 it contains 7392:b811. The product string is also visible:

cat /sys/kernel/debug/usb/devices | grep -A 4 "Vendor=7392 ProdID=b811"

The product string typically reads "Edimax Technology Co., Ltd EW-7811Un V2 802.11n [Realtek RTL8188EUS]". The official Edimax product page is at edimax.com EW-7811Un V2 product page for cross-reference against the printed label and packaging.

3. SIMATIC IOT2050 Platform Architecture

The Siemens SIMATIC IOT2050 is a fanless industrial edge gateway built on the STMicroelectronics STM32MP157A. The platform characteristics that matter for this problem are:

  • SoC: STM32MP157A, dual-core Arm Cortex-A7 @ 650 MHz with one Cortex-M4 companion core.
  • Memory: 1 GB DDR3L (basic variant) or 2 GB (advanced variant).
  • Storage: 4 GB eMMC on the basic variant, higher capacity on the advanced variant, plus an SD card slot.
  • Network: 2× Gigabit Ethernet, 2× USB 2.0 host Type-A, optional RS-232/485 on the advanced variant.
  • USB topology: single USB 2.0 controller exposed through a USB2514 hub. Lower Type-A is 1-1, upper is 1-2.
  • OS layer: OpenSTLinux 4.x repackaged by Siemens as the meta-iot2050 Yocto layer. Supported Yocto releases include Dunfell and Kirkstone.
  • Init: systemd.
  • Default wireless manager: ConnMan (in stock Siemens image); NetworkManager is available as an alternative.

Full operating instructions, hardware manuals and firmware notes for the IOT2050 are published on the Siemens Industry Online Support portal under the SIMATIC IOT2050 product page. The STMicroelectronics platform documentation for the underlying SoC is in the STM32 MPU wiki. The wireless driver question is therefore a Linux kernel configuration problem, and the override file is the cleanest place to add the missing symbol.

4. Root Cause: Missing RTL8188EU Kernel Module

The Linux kernel exposes the RTL8188EU driver under the symbol CONFIG_RTL8188EU in the staging/wireless drivers section. The stock IOT2050 image, generated from the meta-iot2050 BSP, enables CONFIG_RTL8192CU=m (for the V1 dongle) but not CONFIG_RTL8188EU=m. The V1 driver does not claim V2 hardware because the USB product IDs and the chipset register layout are different.

Verify the active kernel configuration in the running image:

zcat /proc/config.gz | grep -E 'RTL81|RTL8192'

If the result does not include CONFIG_RTL8188EU=m, the V2 driver is missing. The expected output for a fixed image contains both:

CONFIG_RTL8188EU=m
CONFIG_RTL8192CU=m
CONFIG_RTL8XXXU=m

CONFIG_RTL8XXXU is the generic in-tree Realtek driver and does not claim the Edimax V2 either, because Edimax devices on the RTL8188EU silicon use vendor-specific firmware load sequencing that the generic driver does not match. The dedicated CONFIG_RTL8188EU module is required.

5. Solution Path A: Adding CONFIG_RTL8188EU to the defconfig_extra

The supported route is to add a single kernel configuration symbol to the override file in the meta-iot2050 layer and rebuild the image. The override file is read on top of the defconfig, so the change is minimal.

5.1. Prepare the build host

Use a Linux build host with the prerequisites documented in the meta-iot2050 README:

  • Ubuntu 20.04 LTS or 22.04 LTS, 64-bit, with at least 8 GB of RAM and 200 GB of free disk space.
  • Python 3.8+ and kas (3.x recommended): pip3 install kas
  • Standard Yocto build dependencies: git, build-essential, chrpath, cpio, diffstat, gawk, liblz4-tool, libsdl1.2-dev, python3-pip, rsync, texinfo, unzip, wget

5.2. Clone the BSP

git clone https://github.com/siemens/meta-iot2050.git cd meta-iot2050 git checkout <branch matching the released image, e.g. kirkstone or dunfell>

Pin the branch to the Yocto release that the deployed IOT2050 is currently running. Mixing a Dunfell image with a Kirkstone kernel config is the most common reason a built module refuses to load at runtime.

5.3. Edit the override file

Open the override file used by the target image recipe. For the standard IOT2050 image it is:

kas-iot2050-base/iot2050_defconfig_extra.cfg

Append the following line:

CONFIG_RTL8188EU=m

5.4. Optional power-save and LED toggles

Some RTL8188EU adapters, including the EW-7811Un V2, drop beacons when power-save is enabled by the AP and the radio is in PS-Poll. If you observe periodic disconnects in the field, also add:

CONFIG_RTL8188EU_POWERSAVE=y CONFIG_RTL8188EU_LED=y

CONFIG_RTL8188EU_LED drives the activity LED; this is a behavioural preference rather than a fix. CONFIG_RTL8188EU_POWERSAVE allows the driver to honour mac80211 power-save transitions.

5.5. Rebuild the image

Use the kas build entry point shipped in the same layer:

kas build kas-iot2050-base.yml

If you target the advanced variant, use kas-iot2050-advanced.yml. The build writes a wic image and a rootfs tarball under:

build/tmp/deploy/images/iot2050/

Typical artifacts are iot2050-image-base-iot2050.wic and iot2050-image-base-iot2050.tar.gz. A full build on a typical workstation takes 90 to 180 minutes; an incremental rebuild after editing only the defconfig takes 5 to 15 minutes.

5.6. Flash the image to the IOT2050

Use the Siemens recommended provisioning flow. Two paths are supported:

  • External boot media: copy the resulting .wic to a USB stick or SD card and follow the procedure in the SIMATIC IOT2050 operating instructions. The boot loader selects the new image on the next reboot if the external media is detected at power-on.
  • Direct eMMC programming: on the advanced variant, use dd or balenaEtcher to write the image to the eMMC. The Siemens IOT2050 commissioning manual documents the exact eMMC device path.

Verify the kernel on the booted image contains the symbol:

zcat /proc/config.gz | grep CONFIG_RTL8188EU

6. Loading and Verifying the Module at Runtime

After booting the new image, the module 8188eu.ko is shipped on the rootfs. Load it manually the first time:

modprobe 8188eu lsmod | grep 8188 ip link

The expected output includes a wireless interface such as wlan0 or wlp1s0u1, named after the USB bus path on the IOT2050.

Confirm the driver bound to the device:

readlink /sys/class/net/wlan0/device/driver

The result should be .../drivers/net/wireless/realtek/rtl8188eu/8188eu.

Confirm the radio is not soft-blocked:

rfkill list

If the device shows "Soft blocked: yes", unblock it with:

rfkill unblock wifi

If the interface still does not appear, collect the relevant subsystem information:

journalctl -k --since "-2 min" | grep -E 'usb|8188|wlan' udevadm monitor --subsystem-match=net --subsystem-match=usb

These two commands expose the kernel's reaction in real time when the V2 is reseated. The udevadm monitor line is particularly useful for catching cold-plug timing issues where the module is not yet in modules.dep.

7. Configuring WiFi with ConnMan

The IOT2050 default image uses ConnMan for connection management. The interface name assigned by ConnMan may not match the kernel name, especially after renaming. Identify the ConnMan technology entry:

connmanctl technologies

The 802.11 WiFi technology lists the Edimax-managed interface. Enable WiFi and scan:

connmanctl enable wifi connmanctl scan wifi connmanctl services

Provision the SSID and credentials. The WiFi service identifier returned by connmanctl services follows the pattern wifi_<hash>_managed_psk:

connmanctl agent on connmanctl connect wifi_<hash>_managed_psk Passphrase? [ssid-password]

Persist the configuration by editing /var/lib/connman/<service>/settings and setting Autoconnect=true and Favorite=true.

8. Configuring WiFi with NetworkManager

If you have switched to NetworkManager in your image (the meta-iot2050 layer provides a recipe for it), the equivalents are:

nmcli radio wifi on nmcli device wifi list nmcli device wifi connect "<SSID>" password "<PSK>"

Verify the link state and signal quality:

iw dev wlan0 link iw wlan0 station dump

A successful link shows "Connected to <SSID> (mac:addr) on channel N" and a tx/rx bitrate in the second command. The signal level appears as signal: -45 [-50] dBm in the station dump output.

9. Setting the Regulatory Domain

Set the regulatory domain to match the deployment region. For the IOT2050 this is required to keep the radio within legal transmit limits and to enable the correct 2.4 GHz channel set:

iw reg set DE

Persisting the regulatory domain across reboots requires crda or wireless-regdb on the rootfs. The meta-iot2050 image provides cfg80211 and a regulatory database by default, so the simpler approach is a one-shot systemd unit:

[Unit]
Description=Set WiFi regulatory domain
After=systemd-modules-load.service

[Service]
Type=oneshot
ExecStart=/sbin/iw reg set DE
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Enable it with systemctl enable wifi-regdom.service.

10. Alternative: Out-of-Tree Driver

If a Yocto rebuild is not possible in the field, the RTL8188EU driver can be compiled against the running kernel and inserted manually. Two practical constraints apply.

10.1. Kernel headers requirement

The IOT2050 stock image, as supplied by Siemens, does not include linux-headers in the rootfs. To build a module you need one of:

  • The matching linux-headers-<version> package from a parallel build host.
  • A copy of the kernel source tree used to build the deployed image.
  • A vmlinux plus System.map extracted from the running system.

Verify whether the headers are present:

ls /lib/modules/$(uname -r)/build

If the path does not exist, headers are absent and the Yocto rebuild path (Section 5) is the cleanest route.

10.2. Out-of-tree build

If you do have the source tree, build the module with:

git clone https://github.com/lwfinger/rtl8188eu.git cd rtl8188eu make cp 8188eu.ko /lib/modules/$(uname -r)/extra/ depmod -a modprobe 8188eu

This driver is the most current line maintained for the RTL8188EU family and supports monitor mode and packet injection, which the in-tree CONFIG_RTL8188EU driver does not. Use it for diagnostics but not for production IOT2050 deployments where regulatory compliance and long-term maintainability matter — the in-tree symbol is what Siemens will support across BSP updates.

10.3. DKMS option

Packaging the out-of-tree driver with DKMS automates rebuild on kernel update. Add a dkms.conf and install via dkms add / dkms install. The IOT2050's small eMMC has limited headroom for this; for production builds prefer the in-tree approach.

11. Troubleshooting Matrix

Edimax EW-7811Un V2 on IOT2050 fault matrix
Symptom Likely cause Diagnostic command Fix
V2 not visible in lsusb USB port not powered, hub current limit, or dead dongle lsusb -v, journalctl -k | grep usb Try the second USB port, test on a PC, replace the dongle
lsusb shows 7392:b811, no wlan0 CONFIG_RTL8188EU not built zcat /proc/config.gz | grep RTL8188EU Rebuild image with the defconfig override as in Section 5
Module loads, no scan results Antenna disconnected, regulatory domain wrong, AP hidden iw dev wlan0 scan, iw reg get Set the correct regdom, verify AP SSID is broadcast
Frequent disconnects every 5 to 10 minutes Power-save mode, USB autosuspend, weak signal iw wlan0 station dump, journalctl -k -u wifi Disable autosuspend: iw dev wlan0 set power_save off
ConnMan reports "no WiFi technology" Interface not renamed properly, missing firmware loader connmanctl technologies, ls -l /sys/class/net Use udev rules to rename, ensure firmware-realtek is in the image
TX rate stuck at 1 Mbps 802.11b rate-set forced by regulatory bug iw wlan0 bitrate Check iw reg get matches deployment region
Modprobe fails: "Exec format error" Module built against mismatched kernel uname -r vs modinfo 8188eu.ko vermagic Rebuild module against the running kernel's source tree
Association succeeds, no IP address DHCP client not running on wlan0 systemctl status systemd-networkd Enable systemd-networkd or NetworkManager for the wireless interface
Captive portal redirect fails ConnMan not aware of connectivity check connmanctl state Run connmanctl config wifi_<hash>_managed_psk ipv4 dhcp

12. Edge Cases and Field-Proven Caveats

Industrial deployments on the IOT2050 introduce a few constraints that are easy to miss in a lab test.

  • USB bus sharing. The IOT2050's USB 2.0 controller is shared with the RS-232/485 lines on the advanced variant through the USB2514 hub. Plug the Edimax V2 into the port closest to the panel mount (port 1, bus 1-1) for best signal integrity and to avoid bus contention with the COM ports during field-bus traffic.
  • USB autosuspend. The RTL8188EU driver is sensitive to USB suspend. If the IOT2050 is configured with aggressive USB autosuspend (default on some power profiles), the radio can drop association every few minutes. Disable USB autosuspend for the radio with: echo 0 > /sys/bus/usb/devices/1-1/power/control Persist this with a systemd unit that uses a udev rule matching the Edimax VID/PID 7392:b811.
  • Predictable naming. The IOT2050's STM32MP157 has only one USB 2.0 controller exposed through a USB2514 hub. The hub port mapping is 1-1 for the lower Type-A port and 1-2 for the upper. Use predictable naming rules so the wlan interface name does not change with hot-plug: SUBSYSTEM=="net", ACTION=="add", ATTRS{idVendor}=="7392", ATTRS{idProduct}=="b811", NAME="wlan0"
  • Metal cabinet attenuation. For wall-mounted cabinets, the IOT2050 antenna cable length matters. The Edimax V2 nano dongle does not provide an external antenna port. If the IOT2050 is mounted in a metal cabinet, expect 15 to 20 dB of additional path loss. Use the V1 (RTL8188CUS) variant with a custom pigtail, or move to a USB radio with an external antenna in this case.
  • Default power-save. The meta-iot2050 Yocto layer does not enable CONFIG_CFG80211_DEFAULT_PS for power-save off by default. Verify on the running system with iw wlan0 get power_save and disable it for industrial SSIDs where roaming is required.
  • Firmware blob. The RTL8188EU driver requires a firmware file rtw88eu_fw.bin for normal operation. The meta-iot2050 firmware package linux-firmware-rtl8188eu provides it. If the module loads but the interface does not scan, check for firmware: failed to load rtw88eu_fw.bin in journalctl -k and add the firmware package to the image.

13. Verification Checklist Before Returning to Service

  1. lsusb | grep 7392:b811 returns the V2 with a product string containing RTL8188.
  2. ip link show wlan0 shows an interface with state UP and a valid MAC address.
  3. iw dev wlan0 link reports the SSID and current bitrate of the industrial AP.
  4. ping -c 4 <gateway> succeeds with no packet loss above 1%.
  5. journalctl -k --since "-5 min" | grep -c "rtl8188eu" returns zero new errors.
  6. connmanctl services or nmcli connection show --active shows the SSID as the active WiFi connection.
  7. Reboot the IOT2050 three times and confirm the WiFi reconnects automatically each time within 30 s.
  8. iw reg get reports the regulatory domain set to the deployment country.
  9. lsmod | grep 8188 shows the 8188eu module loaded automatically at boot, not just manually.

If any step fails, return to the troubleshooting matrix in Section 11 and address the symptom in order.

14. Long-Term Maintainability Considerations

The IOT2050 receives Yocto BSP updates from Siemens at the cadence of the underlying OpenSTLinux release. When a new kernel is deployed, the CONFIG_RTL8188EU=m symbol must still be present in the new defconfig. To keep the workaround maintainable:

  • Fork the meta-iot2050 repository into your own Git server and keep a branch named iio-edimax-v2 with the defconfig change applied. Rebase this branch onto new Siemens releases as they appear.
  • Add the modified iot2050_defconfig_extra.cfg to your CI pipeline so every new build inherits the symbol automatically.
  • Document the change in your IOT2050 fleet configuration management system so the field service team knows the kernel was built with the workaround and that an out-of-tree module is not required.

FAQ

How can I tell whether my Edimax EW-7811Un is V1 or V2?

Run lsusb | grep 7392. The V1 reports 7392:7811 with chipset RTL8188CUS; the V2 reports 7392:b811 with chipset RTL8188EU. The V2 also has "V2" printed on the device label and is the version that is not detected by the IOT2050 default image.

Can I install the RTL8188EU driver on the IOT2050 without rebuilding the Yocto image?

Yes, by compiling the 8188eu module out of tree and inserting it with insmod. The IOT2050 stock image does not include linux-headers, so you need the matching kernel source tree or a headers package from a parallel build. Production deployments should still rebuild the image to ensure the in-tree CONFIG_RTL8188EU=m is registered with depmod and survives a kernel upgrade.

What regulatory domain should I set on the IOT2050 for the Edimax V2?

Set the domain to match the country of installation, for example iw reg set DE for Germany or iw reg set US for the United States. The 2.4 GHz channel set and the maximum allowed EIRP differ by region; using the wrong domain can cause scan failure or FCC/CE non-compliance.

Does the in-tree RTL8188EU driver support monitor mode on the IOT2050?

No. The in-tree CONFIG_RTL8188EU driver supports station and AP modes only. For monitor mode or packet injection, use the out-of-tree lwfinger/rtl8188eu driver. Note that Siemens does not support monitor mode on production IOT2050 images.

Why does the IOT2050 detect the Edimax V1 but not the V2 with the same image?

The V1 uses the RTL8188CUS chipset, which is claimed by the CONFIG_RTL8192CU=m driver enabled in the meta-iot2050 defconfig. The V2 uses the RTL8188EU chipset, which requires the CONFIG_RTL8188EU=m driver. The two Realtek families are not binary-compatible at the mac80211 layer, so separate driver symbols are required in the kernel build.

What is the difference between CONFIG_RTL8188EU and the generic rtl8xxxu driver?

CONFIG_RTL8XXXU is the generic in-tree Realtek driver that supports several RTL8xxx chipsets, but the Edimax EW-7811Un V2 uses vendor-specific firmware load sequencing and USB descriptor quirks that the generic driver does not match. The dedicated CONFIG_RTL8188EU module is the only one that binds to the device reliably on the IOT2050.

Does the workaround also work on the SIMATIC IOT2040?

Yes, the same defconfig override path applies to the IOT2040 because both gateways share the meta-iot2050 layer and the same kernel configuration override file. The IOT2040 ships with a different SoC (TI AM6548), but the RTL8188EU driver is architecture-agnostic and binds to the USB device identically.

Back to blog