Wireshark · Wireshark-users: Re: [Wireshark-users] FTP Timeout Troubleshooting

[M K <gedropi@xxxxxxxxx>]

The PTR record is the reverse of the A record.  Without it, one can
experience rejection from some sites.  Why don't you do just a capture
with delta time stamping to determine where the holdup takes place.?
Also there are more protocols and layers involved in the logon process
than just DNS.

On 5/17/10, Jonathan S. Abrams <hociman@xxxxxxxxxxx> wrote:
> On 5/9/10 5/9/1011:49 PM, Bill Meier wrote:
>> Jonathan S. Abrams wrote:
>>
>>> Hello,
>>>
>>> I am trying to troubleshoot an issue with connecting to an FTP server,
>>> and have captured some packets that match a theory I have that the issue
>>> is related to a timeout.  I am hoping that someone can either explain to
>>> me what this data means or point me in the right direction towards
>>> interpreting it.
>>>
>>> When I initiated a connection to the FTP server in question, the
>>> following packets caught my attention.
>>>
>>> No.     Time        Source                Destination           Protocol
>>> Info
>>> 23 10.212754  SERVER          ME       TCP      ftp>  49497 [ACK]
>>> Seq=336 Ack=33 Win=524280 Len=0 TSV=113977199 TSER=777016821
>>>
>>> No.     Time        Source                Destination           Protocol
>>> Info
>>>        24 11.057690   SERVER          ME        TCP      57314>  ident
>>> [SYN] Seq=0 Win=65535 Len=0 MSS=1460
>>>
>>> No.     Time        Source                Destination           Protocol
>>> Info
>>>        25 19.073737   SERVER          ME        TCP      57314>  ident
>>> [SYN] Seq=0 Win=65535 Len=0 MSS=1460
>>>
>>> No.     Time        Source                Destination           Protocol
>>> Info
>>>        26 35.105752   SERVER          ME        TCP      57314>  ident
>>> [SYN] Seq=0 Win=65535 Len=0 MSS=1460
>>>
>>> No.     Time        Source                Destination           Protocol
>>> Info
>>>        27 40.232279   SERVER         ME        FTP-DATA FTP Data: 85
>>> bytes
>>>
>>> No.     Time        Source                Destination           Protocol
>>> Info
>>>        28 40.232321  ME        SERVER          TCP      49497>  ftp [ACK]
>>> Seq=33 Ack=421 Win=524280 Len=0 TSV=777017121 TSER=113977499
>>>
>>> Here is why I think it is a timeout issue.  I am using Mac OS X, and
>>> when I use Transmit to connect to this server, it takes about 31 seconds
>>> to connect, but it does connect.  Transmit does not have a timeout
>>> preference that I can find, so as long as I wait patiently, it
>>> connects.  If I use Cyberduck, with its defaults, it will not connect.
>>> If I change the Cyberduck timeout preference to 31 seconds, it does
>>> connect.  If you look at the times on the packets above, you will see
>>> the first packet I pasted here has a time of 10.212754.  The next packet
>>> coming from ME going to the SERVER occurs at 40.232321, which is more
>>> than 30 seconds after the first server packet.  As such, if I don't
>>> adjust Cyberduck's default timeout preference to a higher value,
>>> Cyberduck does not connect.  This packet capture was done using
>>> Cyberduck, with its timeout preference set to 31 seconds, so I was able
>>> to connect successfully.
>>>
>>> Ultimately what I would like to do is get the time between packet 23 and
>>> packet 28 to be less than 30 seconds.  This way nobody will have to
>>> adjust their timeout preference if they are using Cyberduck to connect
>>> to this server.  Does any of the packet data here suggest what I might
>>> be able to do to achieve that?  Any insights are appreciated.
>>>
>> The timeout occurs because the FTP server is sending "IDENT" requests
>> to your system and getting no reply.
>>
>> In the above the server tried 3 times with no response before finally
>> proceeding with the connection.
>>
>> Google something like "FTP Server" "Ident" and you'll find lot's of info.
>>
>> I'm not at all familiar with MAC OS X (and using FTP clients on same); I
>> suspect you may need to somehow have the OS send a "reject" reply when
>> the IDENT request is received (rather than ignoring the request).
>>
> Thank you for the response.  I was able to configure the FTP server to
> not issue IDENT requests by using the information at
> http://www.macosxhints.com/article.php?story=20050223231518462.
>
> I am still having a 30+ second delay between the moment I supply login
> credentials and the moment the directory listing is displayed.  While
> looking for how to turn off IDENT requests, I found a post suggesting
> that the delay could be due to a PTR lookup.  While the server has a PTR
> record, the PTR record is not the same as the A record.  Could that
> contribute to the delay as well?
>
> Thanks for reading!
>
> Jonathan S. Abrams
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>