1

I send the file with cat file1 | nc ip-address port and receive it with nc -l port > file2 and get the file cut. The size of the received file is 28467200 bytes (approx. 28M) out of approx. 150M. 

uname -a
Linux MyName 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20 09:57:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

On other linux I have (Loki in VirtualBox inside Windows7) this limitation is not available. 

uname -a
Linux Loki-VirtualBox 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I also used other software as a sending side with same result, therefore I blame the receiving part.

In Wireshark I see the (FIN, ACK) flag which makes the connection to close, but I cannot find any reason for it.

What could be a reason for such behavior?

EDIT: In case I use nc -l port > filename I receive 28M of data, but if I use nc -l port > filename < /dev/null, I receive 26K of data (took from this question: Sending file via netcat). Is this behavior somehow related?

avp
  • 111
  • 7
  • How much is missing? From where - start, end, one or more random blocks? – AFH Mar 14 '17 at 11:32
  • I receive always about 28M. The sample files are much bigger, about 150M. I receive only the beginning of the file. – avp Mar 14 '17 at 12:38
  • It looks like a network problem: you should redirect stderr at each end, and see if there is anything in the error logs. Also, try the transfer with both sender and receiver on the local machine, using 127.0.0.1 as the sender IP. By the way, never use cat file | program ... - always use the much more efficient program <file .... – AFH Mar 14 '17 at 13:18
  • Yes, I have already tested the localhost, it makes no difference. Only that PC, only that nc (or system, whatever) have this limitation. For the stderr I did not get the idea. I see nothing in terminal. IMHO the stderr output would appear there, wouldn't it? I mean, the pipe redirects only the stdout, the stderr would be visible. Am I wrong? – avp Mar 14 '17 at 14:56
  • I wasn't sure how you were accessing or monitoring the remote system, so I wasn't sure if you'd see stderr messages. When you say that using localhost makes no difference, do you mean that the same error occurs? On both systems? Have you tried sending a similarly-sized file the other way? – AFH Mar 14 '17 at 16:12
  • By mentioning the localhost I meant that the error happens only on the first PC no matter if the file is sent from outside or locally. It is always cut. The other PC has no such limitation no matter how I send the file there. – avp Mar 15 '17 at 08:52
  • @AFH: gee!.. I tried to wget some huge file (100+M) from my dropbox and it is cut on 28M! So nc seems to be not guilty. OTOH, I have no idea what is limiting the transfer... – avp Mar 15 '17 at 09:04
  • I can't immediately think how it may be relevant, but is the problem system 32-bit? Any file system differences? – AFH Mar 15 '17 at 10:21
  • No, both are 64 bit and ext4. – avp Mar 15 '17 at 10:54
  • I'm out of ideas for the moment: I'll come back if anything else occurs to me. – AFH Mar 15 '17 at 12:52
  • Are you using any iptables rules or similar packet mangling? – Hydranix Mar 15 '17 at 22:24
  • @Hydranix: I did not configure that PC, but the output of the iptables -L -n is empty. How do I check what you mean? – avp Mar 16 '17 at 13:04
  • A better question might be, does this occur only with netcat, or does something like scp or rsync also display the behavior? (the main point being both programs support encrypting the data at the application level thus anything between the sender and receiver cannot see much other than encrypted data) – Hydranix Mar 17 '17 at 08:21
  • @Hydranix: I have checked that wget received the file using https without 28M limit. – avp Mar 21 '17 at 10:14
  • It looks hopeless. Now even nc does show different behaviour. The very same commands. I believe that administrator has changed something. I close the question as it makes no sense anymore. :( – avp Mar 21 '17 at 10:26

1 Answers1

2

You're receiving the file incorrectly.

You should listen for it with

nc -l -p port > file2

And send it with

cat file1 | nc ip port
Hydranix
  • 981
  • 5
  • 11
  • Ah, crap, it's a typo here. I received as you have written. I fix the question not to mislead others though. Thank you anyway. – avp Mar 14 '17 at 12:34