constant TCP re-transmission with FTP 'put'

[gurner]

Have a strange situation where a user can download from any FTP server, but when they try to upload it used to take ages, now it just fails.

I've tried 'hash' to display progress and it does about 5-10% of a 20K file, for example and then sticks, and eventually disconnects.

I have checked the routers and Proxy and there are no access lists blocking FTP, as you can FTP in and then do Dir, which covers port 21 and 20. although, downloading is fine as well.

and the Proxy is in caching mode only, so is not perfroming and packet filtering

However, running Ethereal reveals shortly after the put command, and a short burst of transfer, Ethereal logs continuous re-transmissions, just like this

-------------------

No. Time Source Destination Protocol Info
25 64.341945 10.10.1.10 xxx.xxx.xxx.xxx FTP-DATA FTP Data: 1460 bytes

Frame 25 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0f:1f:6d:a6:ac, Dst: 00:00:0c:07:ac:01
Internet Protocol, Src Addr: 10.10.1.10 (10.10.1.10), Dst Addr: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: 3538 (3538), Dst Port: ftp-data (20), Seq: 2921, Ack: 1, Len: 1460
FTP Data

No. Time Source Destination Protocol Info
26 70.430357 10.10.1.10 xxx.xxx.xxx.xxx FTP-DATA [TCP Retransmission] FTP Data: 1460 bytes

Frame 26 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0f:1f:6d:a6:ac, Dst: 00:00:0c:07:ac:01
Internet Protocol, Src Addr: 10.10.1.10 (10.10.1.10), Dst Addr: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: 3538 (3538), Dst Port: ftp-data (20), Seq: 1461, Ack: 1, Len: 1460

---------------

anyone got any ideas where to continue?

Cheers

Gurner

http://www.divineparadox.co.uk

 

[bcastner]

http://www.broadbandreports.com/forum/remark,1700907~root=equip,16~mode=flat

 

[gurner]

Makes sense, explains the 1460, when it should be 1452 (or less)

It is a Cisco IOS DSL router if that makes any difference

Cheers

(just waiting on the end user to reboot the box for me now)


Gurner

http://www.divineparadox.co.uk

 

[gurner]

Thanks for your posting, the link hasn't seemed to help yet tho

the MTU is now set to 1492 (1452 MSS) but it still continues to retransmit.

what i neglected to mention however that previously there were a couple of checksum errors, which made the link you posted make total sense.

However, the checksum errors didn't ocurr once after changing the MTU to 1492, but as above the retransmission still occurs constantly till a disconnection by the destination

----------------

No. Time Source Destination Protocol Info
49 123.290329 10.10.11.6 xxx.xxx.xxx.xxx FTP-DATA FTP Data: 1452 bytes

Frame 49 (1506 bytes on wire, 1506 bytes captured)
Ethernet II, Src: 00:a0:cc:22:0f:da, Dst: 00:00:0c:07:ac:01
Internet Protocol, Src Addr: 10.10.11.6 (10.10.11.6), Dst Addr: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: 1161 (1161), Dst Port: ftp-data (20), Seq: 2905, Ack: 1, Len: 1452
FTP Data

No. Time Source Destination Protocol Info
50 129.234272 10.10.11.6 xxx.xxx.xxx.xxx FTP-DATA [TCP Retransmission] FTP Data: 1452 bytes

Frame 50 (1506 bytes on wire, 1506 bytes captured)
Ethernet II, Src: 00:a0:cc:22:0f:da, Dst: 00:00:0c:07:ac:01
Internet Protocol, Src Addr: 10.10.11.6 (10.10.11.6), Dst Addr: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: 1161 (1161), Dst Port: ftp-data (20), Seq: 1453, Ack: 1, Len: 1452

----------

anymore links or ideas? i'm yet to find something that came as close to your link.

Cheers

Gurner

http://www.divineparadox.co.uk

 

[chieftan999]

Have you tried "put" in FTP to a different box to see what the result is?

This sounds more like it is system based than network......

Reamin positive. The affect on those around you will amaze.

 

[gurner]

yeah, same on several FTP servers.

makes sense the recieving box might be requesting a retransmission because of a problem that end, but also doesn't rule out the packets are leaving wrong.

Cheers

Gurner

http://www.divineparadox.co.uk

 

[gurner]

Found the cuplrit, now to figure out why

fortunately there is a failover situation in place where each site within the organisation has an ADSL router and a WAN router.

Using HSRP the WAN router holds the Access-Lists and priority routes traffic over either the WAN or ADSL dependant on its destination.

0.0.0.0 is routed out via ADSL to the t'internet and anything on the internal subnet 10.0.0.0 255.0.0.0 is routed via the WAN to other sites.

Changing the MTU several times made no difference, but i noted it was going out via the ADSL everytime (as it should)

but i added a static route to the WAN router to forward packets destined for the IP of the FTP server via the Frame

did an FTP and it worked everytime, so something about the ADSL router is changing the packets for the worse.

better get onto a cisco thread, ha



Gurner

http://www.divineparadox.co.uk