I have systematically dismantled every single security layer, sandbox, and known driver conflict built into the Linux Mint kernel. The fact that the web flasher can successfully write the firmware, but the web app configuration tool times out on the exact same port five seconds later, points strongly to a bug in how the MeshCore web app handles the Web Serial API handshake with the Heltec v4.
Hardware & OS:
Board: Heltec v4.3 (ESP32-S3)
OS: Linux Mint (Ubuntu/Debian base)
Browser: Native Google Chrome (installed via .deb, explicitly NOT the Flatpak version)
Firmware: MeshCore "USB Companion" (Flashed successfully with 'Erase Flash' checked)
The Issue:
I am trying to configure radio settings via USB on the web app. When I click connect, the Web Serial popup successfully sees the board on /dev/ttyACM0. However, upon selecting it, the web app fails to connect and throws the red "Bluetooth" timeout error (acting as a generic timeout catch-all).
Crucial Detail: The meshcore.io/flasher works perfectly over the exact same USB connection. It successfully puts the board in download mode and writes the firmware. The failure only happens when trying to connect to the configuration app afterward. I have three of these boards, brand new from Heltec direct.
Troubleshooting Steps Already Completed (The OS is fully unlocked):
Permissions: User is in the dialout group (and system was rebooted).
Sandbox Bypass: Removed Flatpak Chromium entirely; running native .deb Google Chrome.
Driver Conflicts: Completely purged brltty (sudo apt remove brltty).
Modem Hijack: Stopped and disabled ModemManager via systemctl.
Udev Rules: Applied and triggered permanent 0666 rules for both ttyACM* and ttyUSB*.
Brute Force: Manually ran sudo chmod 666 /dev/ttyACM0 right before connecting, with the same failure.
Firmware State: Verified the board is flashed with "Companion" firmware, so it is not sleeping/disabling serial like a Repeater node would.
Question for the Devs:
Because the serial connection works perfectly for the bootloader/flasher but fails on the app handshake, is there a known Web Serial API timing/DTR issue with the ESP32-S3 on Linux in the current web app build? Are there any hidden Chrome chrome://flags required for this specific handshake?
I have systematically dismantled every single security layer, sandbox, and known driver conflict built into the Linux Mint kernel. The fact that the web flasher can successfully write the firmware, but the web app configuration tool times out on the exact same port five seconds later, points strongly to a bug in how the MeshCore web app handles the Web Serial API handshake with the Heltec v4.
Hardware & OS:
Board: Heltec v4.3 (ESP32-S3)
OS: Linux Mint (Ubuntu/Debian base)
Browser: Native Google Chrome (installed via .deb, explicitly NOT the Flatpak version)
Firmware: MeshCore "USB Companion" (Flashed successfully with 'Erase Flash' checked)
The Issue:
I am trying to configure radio settings via USB on the web app. When I click connect, the Web Serial popup successfully sees the board on /dev/ttyACM0. However, upon selecting it, the web app fails to connect and throws the red "Bluetooth" timeout error (acting as a generic timeout catch-all).
Crucial Detail: The meshcore.io/flasher works perfectly over the exact same USB connection. It successfully puts the board in download mode and writes the firmware. The failure only happens when trying to connect to the configuration app afterward. I have three of these boards, brand new from Heltec direct.
Troubleshooting Steps Already Completed (The OS is fully unlocked):
Permissions: User is in the dialout group (and system was rebooted).
Sandbox Bypass: Removed Flatpak Chromium entirely; running native .deb Google Chrome.
Driver Conflicts: Completely purged brltty (sudo apt remove brltty).
Modem Hijack: Stopped and disabled ModemManager via systemctl.
Udev Rules: Applied and triggered permanent 0666 rules for both ttyACM* and ttyUSB*.
Brute Force: Manually ran sudo chmod 666 /dev/ttyACM0 right before connecting, with the same failure.
Firmware State: Verified the board is flashed with "Companion" firmware, so it is not sleeping/disabling serial like a Repeater node would.
Question for the Devs:
Because the serial connection works perfectly for the bootloader/flasher but fails on the app handshake, is there a known Web Serial API timing/DTR issue with the ESP32-S3 on Linux in the current web app build? Are there any hidden Chrome chrome://flags required for this specific handshake?