ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] Analyzing a "broken" FTP session

From: Alex Lindberg <alindber@xxxxxxxxx>
Date: Fri, 21 Aug 2009 16:48:41 -0700 (PDT)
I have have not followed the entire thread and if I repeat what others have said, I apologize, but  I would check the following:
  1. Verify the speed and duplex settings of all interface.  Connected ports should either be all set to "auto-negotiate" or both set the highest speed and full duplex.  The only exception would be if the connected ports support GigE.  In that case make sure both are set to "auto". 

    If one port is set to "auto" and the other is 100Full, the "auto" port will set up as 100Half.  Thus it will see collisions when there are none.  This can greatly slow any application using that port do to tcp retries or dropped UDP packets.  You can check your PC and Server interface from the command-line/cmd window by with "netstat -i" for linux/unix or "netstat -e" for windows. Also check the interface stats for the router and/or switch ports.  Look for physical layer errors.

  2. Check your queuing configuration and/or policy maps (cisco talk) of your router.  If you are incorrectly placing the FTP traffic in a high proirity queue, there is a chance that you may be filling the queue and causing "tail drop" when the queue overflows. "show policy" will help you determine if you are dropping packets.

  3. Ensure that your server's nic is designed for server use.  They cost a bit more, but do much of their own packet processing and relieve the CPU load on the server.  Well worth the cost.

  4. Look for errors generated by the servers ftp daemon (ftpd).  Some servers are better that others under high load.

Good luck.

Alex Lindberg