Netcat file transfer problem

1

I have two custom scripts I just wrote to facilitate transferring files between my VPS and my home server. They are both written in bash (short & sweet):

To send:

#!/bin/bash

SENDFILE=$1
PORT=$2
HOST='<my house>'
HOSTIP=`host $HOST | grep "has address" | cut --delimiter=" " -f 4`

echo Transferring file \"$SENDFILE\" to $HOST \($HOSTIP\).

tar -c "$SENDFILE" | pv -c -N tar -i 0.5 | lzma -z -c -6 | pv -c -N lzma -i 0.5 | nc -q 1 $HOSTIP $PORT

echo Done.


To receive:

#!/bin/bash

SERVER='<myserver>'
SERVERIP=`host $SERVER | grep "has address" | cut --delimiter=" " -f 4`
PORT=$1

echo Receiving file from $SERVER \($SERVERIP\) on port $PORT.

nc -l $PORT | pv -c -N netcat -i 0.5 | lzma -d -c | pv -c -N lzma -i 0.5 | tar -xf -

echo Done.

The problem is that, for a very quick second, I see something flash along the lines of "Connection Refused" (before pv overwrites it), and no file is ever transferred. The port is forwarded through my router, and nmap confirms it:

~$ sudo nmap -sU -PN -p55515 -v <my house>

Starting Nmap 5.00 ( http://nmap.org ) at 2010-04-21 18:10 EDT
NSE: Loaded 0 scripts for scanning.
Initiating Parallel DNS resolution of 1 host. at 18:10
Completed Parallel DNS resolution of 1 host. at 18:10, 0.00s elapsed
Initiating UDP Scan at 18:10
Scanning 74.13.25.94 [1 port]
Completed UDP Scan at 18:10, 2.02s elapsed (1 total ports)
Host 74.13.25.94 is up.
Interesting ports on 74.13.25.94:
PORT      STATE         SERVICE
55515/udp open|filtered unknown

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.08 seconds
           Raw packets sent: 2 (56B) | Rcvd: 5 (260B)

Also, running netcat normally doesn't work either:

squircle@summit:~$ netcat <my house> 55515
<my house> [<my IP>] 55515 (?) : Connection refused

Both boxes are Ubuntu Karmic (9.10). The receiver has no firewall, and outbound traffic on that port is allowed on the sender. I have no idea what to troubleshoot next. Any ideas?

P.S.: Feel free to move this to SO/SF if you feel it would fit better there.

squircle

Posted 2010-04-21T22:18:43.057

Reputation: 6 365

Answers

1

HOSTIP=`host $HOST | grep "has address" | cut --delimiter=" " -f 4`
SERVERIP=`host $SERVER | grep "has address" | cut --delimiter=" " -f 4`

I have no idea what you think this accomplishes, but you should remove these lines and just use $HOST and $SERVER directly.

The problem is that, for a very quick second, I see something flash along the lines of "Connection Refused" (before pv overwrites it), and no file is ever transferred. The port is forwarded through my router, and nmap confirms it: ~$ sudo nmap -sU -PN -p55515 -v [...] PORT STATE SERVICE 55515/udp open|filtered unknown

You told it to do a udp scan. Why did you do that? You are not using netcat in udp mode, nor would that even make sense for file transfer.

Also, running netcat normally doesn't work either: squircle@summit:~$ netcat 55515 [] 55515 (?) : Connection refused

You are not forwarding the port correctly.

Anyway, this whole scenario is flawed from the beginning. Just use scp or rsync. If you insist on using lzma, pipe tar+lzma over ssh. Using netcat in this situation buys you absolutely nothing.

user23307

Posted 2010-04-21T22:18:43.057

Reputation: 5 915

Agreed... why make things more complicated than they already are. SCP, rsync or plain 'ole FTP are all better solutions than netcat in this situation. – heavyd – 2010-04-22T00:20:57.350

@justin: Thanks for the feedback; for me, SCP had too much overhead (considering I'm running this on a VPS and the encryption slows down the entire process), and having an FTPD daemon running all the time is a pain (on either machine). – squircle – 2010-04-22T01:49:27.280

@justin: You're correct. My DD-WRT install wasn't forwarding TCP properly and was instead forwarding only UDP. The scripts work now. The host $SERVER | grep "has address" | cut --delimiter=" " -f 4 just retrieves the IP of the host/server (quick & dirty) so netcat doesn't complain about a DNS name mismatch. Thanks for the suggestion. – squircle – 2010-04-22T01:53:19.133

scp may have been slow, but it most definitely had nothing to do with the encryption, and everything to do with the scp protocol being horrible inefficient. Again, netcat is buying you absolutely nothing other than being more complicated and less secure. Just use tar over ssh. – user23307 – 2010-04-22T03:13:10.420