Exception when sending "purge" to a remote serial driver

[colin-foster-in-advantage]

When I try to attach to a ShellDriver on a remote serial port, I hit an exception "timeout while waiting for option 'purge'"

The exception comes from this line:

https://github.com/pyserial/pyserial/blame/master/serial/rfc2217.py#L493

I was able to recreate this issue with this code:

from serial.rfc2217 import Serial

def main():
    myConnection = Serial(port="rfc2217://lg-omap:34127", baudrate=115200, timeout=None)


if __name__ == '__main__':
    main()

If I comment out the self.reset_input_buffer() and self.reset_output_buffer() lines, everything works fine and running pytest with "test_shell.py" succeeds.

My exporter is a Raspberry Pi running Ubuntu 24.04 with a USB / Serial adapter.

So my question is: Is there something that might have changed on the exporter side that might cause the purge to timeout? Clearly the pyserial code isn't new, so I suspect the issue is something I've done with my exporter.

Is there any information that I could grab or provide that might shed some light on this?

Also, thank you for providing active support on this project! I look forward to using it much more.

[colin-foster-in-advantage]

I referenced the pyserial source code, but confirm that both my client and exporter have pyserial-labgrid version 3.5.0.1 installed

[Emantor]

Yeah, that does look weird. The fixes in our pyserial branch eliminate a lot of port reconfiguration, to investigate this further I'll need to reread RFC2711.

[jluebbe]

Is there any information that I could grab or provide that might shed some light on this?

You might be able to see some more by looking at the RFC2711 TCP connection with Wireshark. If you can reproduce and compare with the old working behaviour, even better.

Are you using ser2net? Perhaps there is a regression on their side?

[colin-foster-in-advantage]

Is there any information that I could grab or provide that might shed some light on this?

You might be able to see some more by looking at the RFC2711 TCP connection with Wireshark. If you can reproduce and compare with the old working behaviour, even better.

Yes, I have that reproducing here.

The "with purge failing" option looks to start the same as the "purge ignored" example up until 0x49

0x49 sends ff fa 2c 0c 01 ff f0 after which there's a three second timeout before the TCP connection is FIN'd.

When I use the Telnet wirehsark parser, that matches the code in that it is trying to purge RX:

Are you using ser2net? Perhaps there is a regression on their side?

I am. And it was the Ubuntu 24.04 package (v4.6.0-1build2). The commit logs seem to support your theory:

8799160 (HEAD -> master, origin/master, origin/HEAD) dataxfer: Remove some debugging cruft
e5c3dfa Add initial EditorConfig support
978cf04 README.rst: fix typos
aa91a83 Return 0 for the -v option
7c3897a Fix showport and showshortport state reporting
6e8439a (tag: v4.6.1) Move to version 4.6.1
7d389f4 tests: Fix write drain tests
3b763a3 tests: Fix the rfc2217 flush test
1a339fd tests: Fix rfc2217 test to not leave ser2net running after crash
a369585 Add support for the updated gensio modemstate/linestate handling
7439c57 Add an rfc2217 flush test
8d71a1a Fix a problem with rfc2217 flush handling
0da2826 Fix the -C description in the help code
97c90c9 Fix the -C option definition
eef0981 Update iss file version
601c87b (tag: v4.6.0) Move to version 4.6.0

I'm willing to bet if I update to the latest (4.6.1+) this issue will go away. I'm regretting my decision to jump to the early OS.