![]() Things like routers and load balancers (especially load balancers) have to maintain session information for the connection. That is they will start a file transfer at a pretty high rate, then if it's going longer, will back it off to a slower sustained rate. What I'm thinking with this one, most Windows network services do automatic throttling. Have you noticed it to be more likely to fail if the file is very large? Or at a specific time of day? I don't know if you have the means to collect those kind of stats, but it might point toward possible problem gear. Plus, since it's working "most" of the time (80% I think you said), then it's most likely NOT a firewall issue. If you're getting the initial connection, negotiating the log in, and starting the transfer, then the ports you need are there. I think looking at firewalls is probably a dead end. Yes, it's a lot of work, but you don't lose servers for days at a time due to something stupid being pushed to them without your knowledge. In my place of work all server patches are researched and vetted before being applied manually to the servers. Well, IMO, on a server you should never have automatic updates turned on. It's a lot to go through because there's a lot of noise, but if it is a server side problem, a lot of times there are Events logged that often lead to a solution.Īnd, Wireshark is a good place to start to gather more data. Or, was something installed on all servers at that time?Īlso, if you can narrow down as close as you can to when it started, the Event logs may hold some hints. The fact that all three started having problems at the same time means you look for them to be patched about the same time. Something like a patch could possibly mess up your FTP config, or a network driver, or who knows what. I would also look at patch and update schedules on the servers. It's the "three different servers at the same time" clue that sticks with me. Especially with them being on two different versions of Windows Server. If all three servers started having problems at the same time, it really does point to outside the servers, to some network infrastructure bringing traffic to them. RE: FTP Issues SamBones (Programmer) 7 Jun 18 14:47 Learning - A never ending quest for knowledge usually attained by being thrown in a situation and told to fix it NOW. Im in the process of wiresharking the incoming connections to see if I can see anything additional. 15:45:05 x.x.x.128 FTP2\CcFirearms x.x.x.22 21 ControlChannelClosed - 0 0 faaf1373-de56-4f7c-ac3d-2f207f057dfe -Īs you can see we have the Passive ports set to 23000 - 26000 as evident in the 25188 port in the middle of the connection. I dont see anything wrong with the transaction. This is supposed to be a time that they had an issue. I tried googling a standard FTP log and had no luck. Ill post a couple connections from a time it supposedly didnt work right and see if anyone sees anything. If someone has a functioning FTP server and would post 30 lines of the log file just to compare to I would be very appreciative so I have something to compare against. Im looking through the logs but am not 100% sure what Im looking for. It will work perfect about 80% of the time and then randomly they will receive a connection timeout and cannot either traverse folders or retrieve files. ![]() The issue is random dropped connection from clients. To my knowledge nothing has changed network wise and about a week ago I made the new FTP 2016 server just to see if it was a config or 2008 version issue and it has the same issue. Two are on 2008 and one on 2016 an they all have the same issue which just cropped up about 4 weeks ago. We are trying to figure out a FTP issue with three of our servers. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |