1

I basically want to do what is described in this question but instead of subsequent data coming from stdin, to come from another file.

If I do this:

cat file.txt | netcat 192.168.121.15

netcat (it seems) simply shuts down the connection after transmitting the file. What the above referenced post suggests is this:

cat file.txt - | netcat 192.168.121.15

However, this just keeps the connection open for input from stdin, whereas I want to be able to send a second file after receiving a response about the first file back from the server.

Therefore, I can't just send a bunch of files all at once, and so the answer to this question isn't what I'm looking for either because I can't alter the server to use tar.

Can netcat even do this or is there some other tool I should be using?

user124384
  • 400
  • 1
  • 9
  • 22
  • This sure seems like [an XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) where you've already decided the solution is `netcat`, even though it's not really a file transfer tool. – Andrew Henle Aug 15 '17 at 21:42
  • 1
    I thought we were encouraged to say what we tried (https://mattgemmell.com/what-have-you-tried/) in order to try to solve a problem. – user124384 Aug 15 '17 at 22:01

1 Answers1

2

TL;DR: Yes, but you'll need something smarter than a piped cat

cat simply concatenates all files given to it and dumps them to stdout, - represents stdin so the way your referenced Q/A pair worked was by concatenating stdin to the file.

netcat is a fine tool for what you're trying to do as far as opening up a raw pipe to the other port. I think a better question for you would be, is piped output from cat the right tool? No.

The problem with just using cat ... | netcat ... is that its a one way deal. The output of cat is used as the input to netcat but the output will go to stdout, the pipe is not two way, you need interactivity.

If you want to interactively perform actions based on responses from the server over your netcat pipe there are a whole host of ways to programmatically interact with a pipe.

You could use read for instance, or expect.

If you're willing to expand your tool chest a little bit i suggest using ncat which is a more modern implementation of netcat and has a handy option -e which allows the attaching of a command or script to the netcat pipe. If you cannot get your hands on a netcat with -e you may need to learn a few things about named pipes and I/O Redirection to get the same effect.

I wanted to test some of this stuff before writing this answer, see below for testing/examples

I didn't write a listening server that handled multiple files sent via netcat, I'm just going to assume you have that working, but I can simulate some programmatic interaction from the client side and do the server by hand.

My dummy "client"/"server" interaction here is based on this fun activity of seting up 2 ncat sessions to talk to each other

  1. I wrote this simple interactive script:

    #!/bin/bash
    i=0
    while true; do
      read line
      if [[ $line == "goose" ]]; then
        echo "zoom"
        exit 0
      else
        i=$(expr $i + 1)
        echo "$i ..."
      fi
    done
    
  2. I start my "server" ncat -l -p 1337

  3. I start my "client" controlled by the interactive script ncat localhost 1337 -e ./interact.sh
  4. And I operate the "server" by hand (since ncat doesn't clearly show I vs O I've notated Input with i: and output with o:):

    i:duck
    o:1 ...
    i:duck
    o:2 ...
    i:duck
    o:3 ...
    i:goose
    o:zoom
    
Will Barnwell
  • 4,049
  • 21
  • 34
  • Wow!! Thank you so much!! This isn't working with my actual server for some reason, but it totally works with the testing via ncat so presumably I'm facing some other weird issue. – user124384 Aug 16 '17 at 01:14
  • Using "sleep" instead of "read line" worked. Not sure why it's unable to read a line... – user124384 Aug 16 '17 at 01:37
  • 1
    I noted during testing that read inside a while loop doesn't deal well with no input. This is where expect may come in handy, or as you've found, sleeping and then reading – Will Barnwell Aug 16 '17 at 17:55
  • It should have been getting input, which is why I was confused. – user124384 Aug 16 '17 at 19:17