From d527b1839c9b1d0db53e4bbc80892d0c1d58a803 Mon Sep 17 00:00:00 2001
From: David Montero Crespo <davidmonterocrespo24@gmail.com>
Date: Mon, 10 Aug 2026 22:34:49 +0200
Subject: [PATCH] fix(micropython): real WiFi driver only where the backend can
 serve it
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Deploy verification of the #262 fix caught a backend split the issue
could not see. The reporter runs the OSS Docker image, where MicroPython
executes under the QEMU worker — there the real driver works and their
fix verification (DHCP on 192.168.4.x, DNS, TCP) holds. But velxio.dev
routes a plain ESP32 MicroPython run to the in-browser esp32js engine,
and the engines' P4 WiFi (which serves Arduino fine) does not yet cover
MicroPython's v1.20 / esp-idf-4.2 vintage esp_wifi blob: handing it the
real module stalls esp_wifi_init with NO output — observed live as four
minutes of dead serial after the raw-REPL paste, strictly worse than the
stub's fake-but-responsive answers.

So the prelude now asks the bridge: an overlay bridge that keeps the
MicroPython run in-browser declares micropythonWifiSupported=false and
keeps the stub; the QEMU path (every OSS install, and ?esp32sim=qemu in
the overlay) gets the real driver + SSID-rewrite proxy. When an engine
gains MicroPython WiFi it flips its declaration and this file needs no
further change.

Property is duck-typed and optional; the plain OSS Esp32Bridge does not
define it, and undefined means supported — OSS behavior is exactly the
reporter's verified environment.
---
 frontend/src/store/useSimulatorStore.ts | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/frontend/src/store/useSimulatorStore.ts b/frontend/src/store/useSimulatorStore.ts
index b84879a2..1f2c9f06 100644
--- a/frontend/src/store/useSimulatorStore.ts
+++ b/frontend/src/store/useSimulatorStore.ts
@@ -1972,10 +1972,23 @@ export const useSimulatorStore = create<SimulatorState>((set, get) => {
             return `with open(${path},'w') as _f:\n    _f.write(${lit})`;
           });
 
-          // Does this run get a real NIC? Must match what startBoard()
-          // will decide, because that is what actually attaches the
-          // device — see sketchUsesWifi().
-          const wifiOn = board.hasWifi ?? sketchUsesWifi(files);
+          // Does this run get a real, WORKING network driver? Two gates:
+          //  - the sketch must want WiFi (must match what startBoard()
+          //    decides, because that is what attaches the NIC device —
+          //    see sketchUsesWifi()), and
+          //  - the backend must be able to serve MicroPython's esp_wifi
+          //    blob. The QEMU worker can (issue #262 was reproduced and
+          //    fixed there). An overlay bridge that routes MicroPython to
+          //    an in-browser engine declares `micropythonWifiSupported =
+          //    false` until the engine models what that blob touches —
+          //    handing it the real driver today stalls esp_wifi_init with
+          //    no output at all, which is strictly worse than the stub.
+          //    Absent property (plain OSS bridge) means supported.
+          const bridgeMpyWifi = (
+            esp32Bridge as { micropythonWifiSupported?: boolean }
+          ).micropythonWifiSupported;
+          const wifiOn =
+            (board.hasWifi ?? sketchUsesWifi(files)) && bridgeMpyWifi !== false;
 
           // WiFi compat shim: replace `network`, `ntptime`, `urequests`
           // with smart stubs BEFORE user main.py imports them.