I am trying to upload a 12MB .wav file on a Mac running Transmit to a Linux box running Apache and get the following error after uploading just 160KB of the file:
error-135-socket-write-error
Any clues why I may be getting this? I have successfully uploaded much larger files in the past and nothing has changed on the configuration.
The disk was full and this caused the error -135.
Check the File Name are there spaces or symbles in it
Hard to say without knowing which OS is running on the client and the server (i.e. where the error code might come from). The error means that the client couldn't send any more data to the server. This is either because the server stops accepting more bytes (hangup, disk full, quota exceeded) or because the connection times out (but then, I'd expect a "connection reset by peer" error).
Related
Trying to contact vsftpd using lftp with FTPS (FTP over SSL). However I keep getting an error like this:
gnutls_record_recv: A record packet with illegal version was received
What is the solution?
This error is misleading. In reality, any number of server-side errors or problems will yield an error like this, and vsftpd does not do very good logging of errors that occur.
For example, in one case I was able to identify that vsftpd was trying to chroot into a directory that did not exist for the user I was logging in with - once I created the directory the error went away.
In another, a PAM script was misfiring resulting in the same error from lftp.
In other words, the error implies some kind of problem occurred on the server that it was not able to handle gracefully, and it just terminates the connection, resulting in this error. You need to go through the config of vsftpd to figure out what is going on - start by switching stuff off, such as PAM scripts or chroot settings, all the way to the base configuration until you hit the point where it starts working.
The main point though is the error does not have a single, specific cause but obscured what could be any one of a number of vsftpd configuration problems.
When using "revert -a" through P4V it waits for a few minutes and throws this error back at me.
RpcTransport: partial message read
TCP receive failed.
read: socket: WSAECONNRESET
The server status returns fine and there are no locked database files.
I suspect this problem is local to this computer as others don't have the same issue. Issueing the same command through the command prompt just has the command prompt sit there indefinitly.
Other commands such as submit and add will have the visual client sit there indefinitely but does not throw and error.
The files are stored on a local drive. This happens with multiply depots/workstations.
The 'WSAECONNRESET' error is issued by Windows, when a network socket is forcibly closed.
Regular occurrences of this error can indicate network problems.
More information is available here:
http://answers.perforce.com/articles/KB/2968/
Hope this helps,
Jen!
I got the same on windows machine. I guess in my case it was caused by corrupted config settings and because of popup error message I had no chance to set it correctly via GUI.
The command line SET command helped to set port and host name again:
p4 set P4PORT=<portnum>
This command reenables the GUI config dialog
A few years late, but for those still facing this:
I faced this error when fetching files from a large repo. I believe what caused this for me was low internet upload speeds due to which - even though I had high a download speed - the TCP acknowledgment from my computer was not getting sent, causing a connection failure.
Perform an upload speed test to determine if it is very low (in my case it had dropped to less than 0.1 Mbps). Fixing upload speeds is a separate topic, but in case it helps try restarting your router as a first step.
I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes
running on different hosts in an intranet.
Processes communicate with each other using TCP/IP. Different processes can be on the
same host or on different hosts (i.e. the communication can be both within the same
host or between different hosts).
We have currently a bug that appears irregularly. The communication seems to work
for a while, then it stops working. Then it works again for some time.
When the communication does not work, we get an error (apparently while a process
was trying to send data). The call looks like this:
send(socket, (char *) data, (int) data_size, 0);
By inspecting the error code we get from
WSAGetLastError()
we see that it is an error 10054. Here is what I found in the Microsoft documentation
(see here):
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
So, as far as I understand, the connection was interrupted by the receiving process.
In some cases this error is (AFAIK) correct: one process has terminated and
is therefore not reachable. In other cases both the sender and receiver are running
and logging activity, but they cannot communicate due to the above error (the error
is reported in the logs).
My questions.
What does the SO_LINGER option mean?
What is a keep-alive activity and how can it break a connection?
How is it possible to avoid this problem or recover from it?
Regarding the last question. The first solution we tried (actually, it is rather a
workaround) was resending the message when the error occurs. Unfortunately, the
same error occurs over and over again for a while (a few minutes). So this is not
a solution.
At the moment we do not understand if we have a software problem or a configuration
issue: maybe we should check something in the windows registry?
One hypothesis was that the OS runs out of ephemeral ports (in case connections are
closed but ports are not released because of TcpTimedWaitDelay), but by analyzing
this issue we think that there should be plenty of them: the problem occurs even
if messages are not sent too frequently between processes. However, we still are not
100% sure that we can exclude this: can ephemeral ports get lost in some way (???)
Another detail that might help is that sending and receiving occurs in each process
concurrently in separate threads: are there any shared data structures in the
TCP/IP libraries that might get corrupted?
What is also very strange is that the problem occurs irregularly: communication works
OK for a few minutes, then it does not work for a few minutes, then it works again.
Thank you for any ideas and suggestions.
EDIT
Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.
That error means that the connection was closed by the
remote site. So you cannot do anything on your programm except to accept that the connection is broken.
I was facing this problem for some days recently and found out that Adobe Acrobat Reader update was the culprit. As soon as you completely uninstall Adobe from the system everything returns back to normal.
I spent a long time debugging a 10054/10053 error in s3 pre-signed uploads
Turns out that the s3 server will reject pre-signed s3 uploads for the first 15 minutes of it's life.
So - If you're debugging s3 check it's not a new bucket.
If you're debugging something else - this is most likely a problem on the server side not client side.
When trying to receive a (large, approx. 100MB) file using an FTP adapter in BizTalk 2006, we run into the following problem, which causes the file to be processed over and over again.
Retrieving the file succeeds; it is placed into the MessageBox and processed properly
When the FTP adapter issues the DELE statement, it never reaches the FTP server the file is on (we have verified this by taking a look at the FTP server's logs)
there are no signs of timeouts on the FTP server; the FTP server log does not mention a timeout occurring
After the interval time set on the adapter expires, the FTP server will still find the large file that we have already processed in the previous run, because the DELE statement failed
The event log in BizTalk states that ‘The connection to the FTP server was broken prematurely’. That is why we think there is a timeout issue.
We have seen that retrieval of the file takes around 35 minutes. The FTP server timeout is set to 1 hour. no problems there I guess.
Then we found the following article: http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html#FirewallTimeouts. It states that a firewall / routing device might be responsible for the timeouts. The team managing our firewalls and routers told us that there were no timeouts set here.
Which leaves us in the dark on the cause of our problem. Does anyone of you have any suggestions? Or even better, the solution!!
Have you tried the solutions in this article?
I avoid using the FTP adapter. Instead I use a third party utility to retrieve files and move the transferred file to a file adapter receive location. Third party utilities allow you to configure rules, recovery actions etc, freeing BizTalk from having to manage the transfer.
I just want to know how you upload datasets specifying its characeteristics?
E.G. using the command quote site lrecl=500 recfm=fb
Well, the command was accepted when I tried to use it, but the problem is that when I tried to upload the file using the command 'send' ftp hangs up, and definitley closes the session.
This is the sample:http://www.mvsforums.com/helpboards/recent.php?sid=dab6b1f3cda149c7d7db855d90acaab1
ftp> quote site lrecl=500 recfm=fb
200 SITE command was accepted
ftp> send C:\test\test.txt 'ADM.SAMPLE.TEST'
200 Port request OK.
425 Can't open data connection.
ftp>
Any help will be appreciated.
Thanks.
I sometimes get this error because of firewall problems when trying to ftp behind a router. You might try switching to active or passive mode (depending of what you are currently using) to see if this helps.
I have a couple of programs that do this, but without specifying record size. The blocking command should be okay. Are you sure you don't have a permissions issue? Does ADM.SAMPLE.TEST already exist, and is it 500 bytes at least? If not, have them create it for you and see if the ftp works then.
You should be able to specify the data set allocation parameters using the site command.
site u=SYSDA rec=VB lr=6144 blk=0 ucount=2 tr pri=3000 sec=200
That translates to:
unit=SYSDA
record format=variable block
logical record length=6144
block size=0
unit count=2
track (allocation units)
primary space=3000
secondary space=200