On 03/30/22 22:47, Marco Marinello wrote: The error message says it all; the problem is not uni- vs. bidirectionality, but the fact that /dev/ttyACM0 is a character device, not a block device, and therefore it is not seekable -- it does not provide random access. the "b" in "nbdkit" stands for "block"; seekability is at the core of it. The plugin architecture is documented like this: https://libguestfs.org/nbdkit-plugin.3.html#struct-nbdkit_plugin "All plugins must define and register one struct nbdkit_plugin, which contains the name of the plugin and pointers to callback functions ..." This structure contains "pread" and "pwrite"; https://libguestfs.org/nbdkit-plugin.3.html#pread https://libguestfs.org/nbdkit-plugin.3.html#pwrite they are tightly coupled with offsets. For a character device, "offset" is undefined. Furthermore, character devices do more than just serial I/O; a bunch of ioctl()s apply to them. /dev/ttyACM0 is even a terminal, so tc*() functions (from <termios.h>) apply to it as well. Anyway, the socat(1) manual describes an example that closely matches your use case: socat PTY,link=$HOME/dev/vmodem0,rawer,wait-slave \ EXEC:"ssh modemserver.us.org socat - /dev/ttyS0,nonblock,rawer" generates a pseudo terminal device (PTY) on the client that can be reached under the symbolic link $HOME/dev/vmodem0. An application that expects a serial line or modem can be configured to use $HOME/dev/vmo‐ dem0; its traffic will be directed to a modemserver via ssh where another socat instance links it to /dev/ttyS0. Replace "modemserver.us.org" with the hostname of the rpi, replace "/dev/ttyS0" with "/dev/ttyACM0", and whatever application you ran against "/dev/ttyACM0" directly on the rpi, run it now on the other host against "$HOME/dev/vmodem0". Hope this helps Laszlo