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
>
