Wierd File Transfer problem

[sadamsvalley]

I have remote units that transmit data to central hq every week via FTP. It seems that some of our units connect and begin the xmit and then it quits. Can xmit files ok if they are under 1100 bytes, any more and it will create the filename and quit. The only thing common is they all have WinXP Pro but all WXPPro don't have the problem. It tends to be on DSL circuits but happens on some dialup. SBC Yahoo DSL doesn't xmit at all but SBCY dial does??? Things I've tried.
Set up another FTP server on the Internet not behind a firewall--no go
Not use VPN--no go
Set MTU to correct setting--no go
Have them disable DSL and dial directly to my RAS--WORKS

Any ideas???

 

[ReddLefty]

Sounds like a fragmented packet issue. Make sure your firewall and clients accept fragmented packets. There should be options in your firewall/router for this. Unfortunalty, they all vary depending on what you use and it also needs to be verified on the client side sometimes....




"In space, nobody can hear you click..."

 

[sadamsvalley]

Redd,
Where could I look on XP Pro to see if that is the case or change the setting? I have the problem even when I init an FTP to a server not behind a firewall and on our network we have about 200 units that succeed in xmit-ing to us. Makes me think it would be client related but I'd never rule out our fw! Another note... we can attach that file to an e-mail from the client and it will send without fail through SMTP. BTW, thanks for your quick response.

 

[bcastner]

Sounds like an MTU issue, as the dial-up will default to an MTU of 576 or so. See this link for some things to try:

http://www.broadbandreports.com/faq/2470

In particular look at the first article linked at this site.

 

[ReddLefty]

It could be that your port or rule on your firewall (port 21) is not accepting fragemented packets.

Some firewalls can be set per port or per service. It's possible that your Email ports accept fragmented packets, but not your FTP port. This is usually not software, but can be either on your firewall or sometimes on home routers like the Linksys or DLink type routers (Cable-Modem and ADSL routers at home)... or both! hehe.




"In space, nobody can hear you click..."

 

[sadamsvalley]

I don't see anywhere that may be set up. It is not on the PIX firewall. The client has PPPoE adapter, any link there?

 

[ReddLefty]

All firewalls should have somewhere that you can setup the fragmented options... but I don't know where it is on a PIX. There is a forum on PIX I think.. maybe you can ask them on that forum? Maybe you can check on the PPoE adapter in the properties for Fragmented stuff also..unfortunatly, I can only point you in the right direction... the settings all vary depending on the hardware so it make it impossible for me to give you the exact location of the settings.




"In space, nobody can hear you click..."

 

[sadamsvalley]

Whatever it was, installing a SMC7004FW Cable/DSL router worked. The problem as far as I can tell is in XP (client side) and may be even further into the WAN miniport driver. That seems to be the only common item among all of the computers that are doing it. Just to ensure it was not my network I set up a FTP server on a completly different provider so my firewall and net were never touched and the same problem happened. I don't know why the SMC works. All I can think is that it is handling the PPPoE negotiation and communication using a linux kernel instead of the Windows WAN miniport driver. Now the PC sees the Internet as a standard Ethernet connected device with no smoke or mirrors.

 

[bcastner]

Its not a Linux kernel issue. It is that the router will default to an MTU of 1492 outbound on a DSL connection. See this note from broadbandreports.com:

MTU is "Maximum Transmissible Unit" - the maximum size a packet can be in a network.

When a TCP connection is made a SYN/SYN-ACK exchange is the first thing done. The client sends the SYN and the server replies with the SYN-ACK. In these messages the MTUs are included so each can send packets of the right size to the other end. Actually MSS (Maximum Segment Size) is sent but for TCPIP that's a value that excludes TCPIP headers and is always 40 less (MTU=1492 is MSS=1452).

On outbound connections (many routers) will actually change this MSS value on-the-fly to be what the setting is. You could say the router "enforces" the MTU that is set. Even if the PC sends MTU=1500 the router changes it in the SYN packet - this is how the other end *really* sees 1492 (if that is what the router is set to). This is desirable since you can run your LAN at 1500 MTU yet go out to the net at 1492 automatically!

But server connections don't seem to get this help. Not only that, the ISP equipment and/or the DSL modem lets these SYNs come in saying they're 1500 MTU! The router does no alteration (it's INbound not OUTbound). The PC is happy (it's 1500 MTU after all) so these 2 ends try 1500 MTU.... BUT THAT DOESN'T WORK ON PPPoE!

The result is large packets (above 1492 MTU) will not transfer well at all and usually just hangs the TCP stack.

One funny thing you WILL see... small data transfers of, for example, small directories or small html files DO get through OK. This is because the packet size never reaches a fatal value.

**** End Quote


So, set your client to 1492 MTU;
and a hardware router cn help with outbound compliance by trimming the packet length for PPoE.

For VPN you may well have to set a client MTU much lower, values of 1400-1424 are not unusual.

 

[sadamsvalley]

That certainly sounds like the problem. I chased the problem for a month swinging the MTU bat at it. I used the Cisco VPN software utility to set the MTU down to 1300, 1200, 1100, etc. all the way down to 500 and it didn't work. However I didn't dig around in registry to see if there was another adapter or something (like the Miniport driver) that needed to be changed. Next system that does this same thing I'll spend a little time doing that to see if I can find more specifics on where to change and post the information. Thanks bcastner for the helpful information.