socat parameter order seems to matter

Question

The man page of socat states that socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them. Based on that, the order of your arguments should not matter and I have often read the same on different sources.

But sometimes I have the feeling that order does indeed matter. For example: On a customers network I have an embedded system that I'm able to access via SSH. That embedded has direct access to a MS SQL database. When I want to debug some thing in the database, I'd like to use Azure Data Studio which runs on a VirtualBox VM on my host (with ip 192.168.100.1). So a simple ssh -L1433:dbserver:1433 won't help. That's where I use socat.

First I use local forward and connect the target port 1433 to my local port 11433 with

ssh my-remote-embedded -N -L11433:dbserver:1433

then I use socat to create a direct connection between port 11433 and 1433 that is bound to 0.0.0.0 so that the port can be accessed in the virtual machine.

If I do this:

socat -v tcp:localhost:11433 tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr

then Azure Data Studio tries to connect to 192.168.100.1:1433 but the connection sort of works, but not really. Azure Data Studio can indeed connect (thanks to -v option I can see on the socat output that bytes are flowing in both directions) and my connection icon turns green but it fails to fetch the list of databases and regular queries also don't work.

However if I swap the order of the socat call to this:

socat -v tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr tcp:localhost:11433

then Azure Data Studio after a restart connects immediately and fetches the list of databases without a problem, my queries work.

And if close Azure Data Studio and restart socat with swapped parameters, then it happens again: the connection barely works.

So it seems that the arguments order for socat does really matter. Am I crazy? What am I missing here?

I'm aware that at https://learn.microsoft.com/en-us/azure-data-studio/download-azure-data-studio?tabs=win-install%2Cwin-user-install%2Credhat-install%2Cwindows-uninstall%2Credhat-uninstall#install-azure-data-studio there is an installation guide for linux. My question is not about that, it's about socat and this is just an example where I can reproduce the behaviour every time.

Answer 1

You note that,

the order of your arguments should not matter and I have often read the same on different sources

Interestingly perhaps, the documentation for socat (man socat) disagrees:

During the open phase, socat opens the first address and afterwards the second address. These steps are usually blocking; thus, especially for complex address types like socks, connection requests or authentication dialogs must be completed before the next step is started.

And it's this that explains at least some of the behaviour you're seeing. Ideally, something should connect to the listening socket before an attempt is made to connect to the remote service. Otherwise, if you connect to the remote service before having a connection request on the local socket, you might get an idle timeout on the remote side.

• Local first, then remote:

  socat -v tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr tcp:localhost:11433  # Yes
  

• Remote first, then local:

  socat -v tcp:localhost:11433 tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr  # No