Try socat open:/dev/tty,raw,echo=0 tcp-connect:localhost:3333 instead.

Thanks for the hint, I will check that out!
But nevertheless, I'm was a bit surprised that the FIFO read enable gets deasserted on unsupported command characters. The consequence is that the FIFO will never ever be read again and the communication gets stuck at that point. Any particular reason to behave like that?

Any particular reason to behave like that?

Robustness against unknown conditions. If I was writing software, I would add an else: assert False branch to make sure that I only accept the input that I definitively understand--since doing otherwise could be hiding a bug! (For example, I could have misunderstood the spec.) In hardware I can't exactly crash the FPGA, so it just infinite loops instead.

All of the existing applets are written like that (where they aren't, they should be) and I expect future applets to be, though this could be improved by adding some sort of signaling for the case where the assertion is hit.

Robustness against unknown conditions. If I was writing software, I would add an else: assert False branch to make sure that I only accept the input that I definitively understand--since doing otherwise could be hiding a bug! (For example, I could have misunderstood the spec.) In hardware I can't exactly crash the FPGA, so it just infinite loops instead.

Well, I guess there are different standpoints here, because I think silently looping without signaling isn't very userfriendly and just looks like another kind of hidden bug from a user perspective...

All of the existing applets are written like that (where they aren't, they should be) and I expect future applets to be, though this could be improved by adding some sort of signaling for the case where the assertion is hit.

... but I will not argue against the design decision, because consistancy is far more important in my opinion.

silently looping without signaling isn't very userfriendly

Indeed. That's why I said that some sort of signaling for this condition should be added. Unfortunately, this is not trivial, and since Glasgow's approach is novel, I considered it more important to get the common case to be robust than to handle the uncommon case of someone extending the openocd protocol itself.