1

As far as I have seen, a socket creates 3 file descriptors in the /proc//fd folder, STDIN, STDOUT and STDERR.

When I input in one socket, it should out the other socket, in a raw-TCP connection, but the thing is, when I echothe STDIN it doesn't output the string.

I attach a photo:

enter image description here

I expect to see the output in the listenning socket, but I don't. Thank you

aDoN
  • 756
  • 5
  • 11
  • 22

1 Answers1

6

Opening a socket opens a socket, which is what you see listed as file descriptor 3 in your output (socket:[5474494]). The other three file descriptors are the standard input, output and error descriptors, which are opened by default for any process. In your case, these point to the terminal where the program is running, which is why “surni” shows up there when you write to the file descriptor.

To write to the socket, you need to use appropriate mechanisms, such as netcat in the other direction:

echo Hello | nc localhost 9999

or, if you’re using Bash:

echo Hello > /dev/tcp/localhost/9999

However it appears you already have a connection established to port 9999 using another netcat, so that won’t actually work in your case. You need to use the established connection...

If you’re expecting a long-running nc to provide a way for other processes to feed into the socket, you need to set that up e.g. using a FIFO:

mkfifo socket-input
nc localhost 9999 < socket-input
echo Hello > socket-input
Stephen Kitt
  • 434,908
  • Hello, good answer, I send data in a TCP socket via /dev/tcp/ but this abstracts the layers I want to interact with which are the file descriptors of a socket.

    Another question, do you know how to bind a process to a socket so that I can send data via the socket? I want to use this since I can't send data to the STDIN of a process (for Linux /proc//fd/ descriptors are just symlinks to a terminal)

     – aDoN Apr 11 '18 at 13:19
  • Why do you want to interact with the file descriptors? Those are effectively meaningless outside their owning process. I explained how to make a socket available externally, see the last part of my answer. – Stephen Kitt Apr 11 '18 at 13:32
  • But once the connection is established, you can't feed into the socket with another process, can you? I don't know exacly what is the difference of what you achieve when creating a file with mkfifo – aDoN Apr 11 '18 at 14:23
  • what you said is a big thing "file descriptors are meaningless outside their owning process" And you seem to be right, but how can you explain this command: strace -p<pid> -s9999 -e write that spy other processes and see the input and output of a process? (nano, vi, python interctive shell...., every process) – aDoN Apr 11 '18 at 14:28
  • strace uses ptrace to spy on other processes, it gets help from the kernel to view things from inside the target process. – Stephen Kitt Apr 11 '18 at 14:44
  • I was thinking it wrong from start. File Descriptor 0 and 1 and the PTS (nothing to do with the socket) File Descriptor 3 is what interests me (the socket itself) but I can't write to it, it says it doesn't exist, but I have achieved it with gdb -p <pid> and then: call write(3,"test",6). Still don't know how to operate with the file descriptor 3 without GDB, maybe it's impossible given sockets theory but it's a step forward – aDoN Apr 12 '18 at 10:49
  • As I’ve said before, file descriptors are meaningless outside their owning process. You can use a debugger to attach to a process and run code inside it, which allows you to use the process’ file descriptors; but that’s not generalisable. Another approach is to pass a file descriptor to another process (see this question), but that also needs cooperation from the owning process. It might help if you take a step back and try to explain what you’re trying to achieve (perhaps in a new question...). – Stephen Kitt Apr 12 '18 at 11:10