mpremote REPL and mount issues with socket:// and RFC2217 connections
Port, board and/or hardware
Any platform - affects mpremote tool when connecting via socket:// or RFC2217
MicroPython version
- mpremote 1.27.0
- Tested against MicroPython unix port 1.27.0 via
- socket://localhost:port
- rfc2217://localhost:2217
Reproduction
1 unable to mount host filesystem over socket connections
- mpremote connect socket://localhost:2218 mount .
AttributeError: 'SerialIntercept' object has no attribute 'in_waiting'
2 Incorrect newline handling in interactive repl over socket
-
Connect to MicroPython Unix port:
mpremote connect socket://localhost:2218 repl -
Type commands and observe output appears like:
>>> print("hello") hello >>>
3 repl over socket://
mpremote connect socket://localhost:2218 repl
REPL may fail to respond or hang
4 repl over rfc2217
mpremote connect rfc2217://localhost:2217 repl
Output may be delayed, laggy, or appear in bursts
pyserial's RFC2217 implementation uses a background thread to process telnet data from the socket into an internal buffer. When mpremote's REPL loop usesselect()on the socket, it signals "ready" when data arrives, butinWaiting()returns 0 because the background thread hasn't processed the data yet.
Race condition sequence:
select()returns because socket has datainWaiting()returns 0 (background thread hasn't processed yet)- REPL loop skips reading
- Next iteration:
select()returns, nowinWaiting() > 0 - Finally reads the data
This causes noticeable lag and stuttering in the REPL.
Expected behaviour
mpremote should work correctly with socket-based connections (socket://, RFC2217), providing:
- Functional mount operations
- Proper newline handling in REPL output
- Responsive REPL without lag or race conditions
Observed behaviour
- Mount operations fail with
AttributeError - REPL output has "staircase" effect (misaligned lines)
- REPL may hang or fail to get input from socket connections
- REPL output is laggy/stuttering with RFC2217 connections
Additional Information
aeb1ce6- Addin_waitingproperty to SerialIntercept class2d46d52- Fix REPL newline handling7f0abfd- Improvewaitchar()wrt socket connections1ff555c- Fix REPL race conditions with RFC2217
Code of Conduct
Yes, I agree
ESP32-S3 `mpremote` sends corrupted fs hook when mounting local directory
Port, board and/or hardware
ESP32-S3 N8R8
MicroPython version
MicroPython 6fee099ca-dirty on 2025-06-25; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3
Compiled using
- IDF 5.4.1
- python 3.13.1
- gcc-15
- macOS Sequoia 15.5
mpremote is used directly from the micropython repository (but the results are same as with latest PyPI version)
Reproduction
- Have a local folder named
local - Run
mpremote mount local
Expected behaviour
Expected to mount local directory on the device and enter the REPL
Observed behaviour
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File ".../micropython/tools/mpremote/mpremote/__main__.py", line 6, in <module>
sys.exit(main.main())
~~~~~~~~~^^
File ".../micropython/tools/mpremote/mpremote/main.py", line 615, in main
handler_func(state, args)
~~~~~~~~~~~~^^^^^^^^^^^^^
File ".../micropython/tools/mpremote/mpremote/commands.py", line 521, in do_mount
state.transport.mount_local(path, unsafe_links=args.unsafe_links)
~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../micropython/tools/mpremote/mpremote/transport_serial.py", line 304, in mount_local
self.exec(fs_hook_code)
~~~~~~~~~^^^^^^^^^^^^^^
File ".../micropython/tools/mpremote/mpremote/transport_serial.py", line 293, in exec
raise TransportExecError(ret, ret_err.decode())
mpremote.transport.TransportExecError: Traceback (most recent call last):
File "<stdin>", line 11
SyntaxError: invalid syntax
Additional Information
After some digging I found a recent thread #17465 which helped to resolve the issue.
After changing the size of a data chunk sent at once over REPL, mounting works as expected:
for i in range(0, len(command_bytes), 32):
self.serial.write(
command_bytes[i : min(i + 32, len(command_bytes))]
)
time.sleep(0.01)
The mpremote mount command works with an earlier build I found on the internet (this one)
So I guess the real problem lies in some build flag.
Code of Conduct
Yes, I agree