Transferred 0 bytes is wrong

[tcurdt]

Obviously 4 bytes got transferred - but it gets reported wrong:

$ nc -l -p 4444 127.0.0.1
foo

$ echo "foo" | nc 127.0.0.1 5555

$ tcpproxy -l 5555 -d 127.0.0.1:4444
Listening on 127.0.0.1:5555
New connection from 127.0.0.1:59981
Error writing bytes from remote client 127.0.0.1:59981 to upstream server
Connection reset by peer (os error 54)
Transferred 0 bytes from upstream server to remote client 127.0.0.1:59981

[mqudsi]

I believe the message is correct but perhaps the functionality could use adjustment. It's reporting the number of bytes written from the server (nc on :4444) to the client (nc on :59981), which is zero (the number of bytes sent back).

The message that would have contained the number of bytes copied from the client to the server is not printed; in its place is a message reporting the error that resulted in the termination of the connection.

In this case, we are perhaps being too technical with the definition of "error" here - the client is presumably just terminating the connection without going through the teardown protocol with a TCP FIN and whatnot. We probably should just ignore that error and treat it as a normal connection close.

[mqudsi]

How did you end up in that state? When I do the same (but first nc, then tcp proxy, then nc), the foo is sent and then the "client" nc instance blocks waiting. Pressing ctrl-c in the client nc tty closes the connection cleanly, making tcpproxy report

Listening on 127.0.0.1:5555
New connection from 127.0.0.1:3490
Transferred 4 bytes from remote client 127.0.0.1:3490 to upstream server
Transferred 0 bytes from upstream server to remote client 127.0.0.1:3490

[tcurdt]

Interesting.

Yes, then it sounds like the logging output might be just confusing.

How did you end up in that state? When I do the same (but first nc, then tcp proxy, then nc), the foo is sent and then the "client" nc instance blocks waiting. Pressing ctrl-c in the client nc tty closes the connection cleanly, making tcpproxy report

Not for me.
When I press ctrl-c I get the reported message.
When I send echo "foo" | nc -c 127.0.0.1 5555 I get the same message.

Maybe the host OS makes a difference?
Where are you trying?
I am (still) on macOS 12.6

[mqudsi]

Could be. Apple ships extremely outdated versions of most cli utilities for licensing reasons. (I'm on Linux.)

I patched tcpproxy to ignore ECONNRESET and ECONNABORT in the read loop. Can you try again after installing tcpproxy from git?

cargo install --git https://github.com/mqudsi/tcpproxy.git --branch master

[tcurdt]

Could be. Apple ships extremely outdated versions of most cli utilities for licensing reasons. (I'm on Linux.)

I also tried a recent netcat via homebrew.

Recent master looks better 👍

$ tcpproxy -l 5555 -d 127.0.0.1:4444
Listening on 127.0.0.1:5555
New connection from 127.0.0.1:56001
Transferred 4 bytes from remote client 127.0.0.1:56001 to upstream server
Transferred 0 bytes from upstream server to remote client 127.0.0.1:5600

[mqudsi]

Awesome, thanks for the confirmation and thanks for posting here and helping improve tcpproxy!

I'll publish an update to cargo soon, as there are a few other fixes I've pushed recently.