[luis pena <glyph_dtd@xxxxxxxxx>]

Hasang,

Thank you for your response. It turned out that FTP traffic was still routing through our old Internet connection (at Site B) and our old firewall. The firewall configs were corrupt, and in fact there was no longer remote access to the PIX. I wish I could give more info but I don't have access to the routers or firewalls, they are maintained by a third party. The WAN admin made some changes to the routes to point to Site A and whalah! FTP traffic is back to normal. Thanks again!

Luis

Hansang Bae <hbae@xxxxxxxxxx> wrote:

luis pena wrote:
> Hello all, my first post so forgive me if I omit any info.
>
> I am observing a FTP timeout on our network that I am hoping to pin down
> using Wireshark.
>
> The network is an 18 node Frame Relay WAN. Nodes are connected via
> point-to-point T1 using Cisco 2600s to a central hub (Site A) which
> provides our connection out to the Internet. Our IT Department is
> located in two sites (Site B) and (Site C).
> I first came across this issue when our payroll dept. complained that
> they could not upload a file to the payroll company that cuts our checks
> (oh no not payroll!). I found out that the problem has been occurring
> over the course of a couple weeks. There is no way for me to tell what
> has changed over the last couple weeks!
>
> Using Filezilla in passive mode on Ubuntu Gutsy I am trying to upload a
> 100MB file to a private FTP server on the Internet. I am able to
> recreate the timeout at Site B and Site C. The System Administrator at
> Site A is not experiencing the upload timeout.
>
> There is an ISA proxy server that sits between Site B & C and has been
> configured to allow FTP traffic. To be on the safe side I am bypassing
> proxy altogether. The problem persists when bypassing proxy as well.
> Windows firewalls are disabled via Group Policy. Hmmmm...
> I fired up Wireshark and filtered out the following: FTP & FTP-DATA. The
> FTP-DATA packets are show a lot (about 50%) of retransmission packets.
> FTP shows a packet; the TCP checksum field
> states that the problem may be a TCP checksum offload. If I may assume
> that the problem is at Layer 4 and that there is a TCP segment
> sequencing error originating on our network. What steps have I missed
> and where so I look next in the troubleshooting process?
> Thank you in advance.

OK, you cannot possibly have 50% retransmission. If you do, you have a
MAJOR MAJOR issue. Also, forget the tcp checksum notice for now. It's
almost always caused by TCP checksum being off loaded to the NIC (just
like what it's telling you).

Are you absolutely sure you are not seeing duplicate packets? In other
words, did you span the traffic as it was leaving the server port and
capturing on the router port as well? Take a look at the IP ID field.

Look at the original packet and the "retransmitted" packet. Are the IP
ID's the same? If so, they are just duplicated (not real).

Are you absolutely sure you don't have a duplex mismatch on the router
uplink ports at site B and C?

Do a "sho int fa0/0" or whatever your upling port is. Do you see any
errors on the interface? Or you can do a "sho port count" or "sho int"
on your switch (former for CatOS, latter for IOS based switches).

Also, check your serial interface to make sure you are not taking errors
at site A (hub) or sites B and C.

--

Thanks,
Hansang
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users

---

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.