FtpWebRequest Passive Mode Problem

[Guest]

Hi all,

There appears to be a problem with the .NET 2.0 class FtpWebRequest in the
following circumstance (an example):

1.) FTPD runs on port 21 on ip 192.168.0.2
2.) On issuing PASV command the data connection reply string gives IP !=
192.168.0.2

So, when the data connection IP is different to the control connection IP
the application throws a WebException helpfully informing me that this is the
case.

Is there any way to change this behaviour?

Martin

 

[Kevin Spencer]

I've been using the new FtpWebRequest and FtpWebResponse now for many
months, and I haven't seen this happen. First of all, Passive mode only
tells the server to send the *port* it will reply on, *not* the IP address.
There is no reason why a server would reply on a different IP address. I
suspect something kooky going on with your network. Are you using a Proxy by
any chance?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Guest]

Hi Kevin,

When you send the FTP server the PASV command it will reply as follows
(assuming the command is succesful):

Entering Passive Mode (xxx,xxx,xxx,xxx,yy,yy)

yy,yy is the port on which it is listening and the xxxs all indicate the IP
address in split octet format, so therefore it is entirely possible for the
IP address to be different to the control address. This is how the mechanism
of server-to-server transfer is supported, as shown in RFC 959. This happens
most commonly in 3 different situations:

1.) When using an ftpd behind a NAT
2.) When using an ftpd that employs a distributed architecture
3.) When using an ftpd that employs bouncers to route the traffic differently

In all three of these circumstances I would *expect* a different data
channel address to be sent back. Although I realise that this has been put in
as a security feature, it is not RFC compliant or even remotely useful to
give no way of overriding it.

Any further help would be greatly appreciated and thanks for your time
already!

Martin

 

[Kevin Spencer]

Sorry about the error in my assertion that the port is not necessarily
changed by the server. I haven't been into those RFCs in awhile!

I did suspect a Proxy involved, however, and what you described would be a
NAT/Proxy situation. In your case, it is further complicated by the fact
that apparently both your machine and the FTPD are on the same LAN. I must
confess that I have not had to deal with this situation before; however,
upon some research into the FtpWebRequest class, and further reading of the
RFC and some articles on NAT/Proxy configurations, I believe this can be
accounted for.

Unfortunately, again, I have no means to test this for myself, so I can't
give you an authoritative answer. But my research indicates that you should
investigate the FtpWebRequest.Proxy property, and the IWebProxy interface,
as well as the topic of "Automatic Proxy Detection" in the .Net Framwework
SDK.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Guest]

Hi Kevin,

Thanks again for the reply.

In the situation I am describing it is not a proxy on the client end, but
rather the server's control connection acting as a proxy. In this case this
should be a TRANSPARENT proxy if the FtpWebRequest class followed RFC.

There is a very easy way to show this problem under Windows:

1.) Get an eval copy of Serv-U FTPD
2.) Setup your server so that the domain runs on localhost
3.) Under the Advanced tab of the domain's settings tick "Enable Passive
transfers, use IP:" and put a LAN ip in this box.

What this means is that essentially serv-u listens on 127.0.0.1 but replies
to the PASV command with 192.168.0.2 (or whatever). Now, obviously this
should be fine for the data channel, it is after all the same site, BUT,
connecting with FtpWebRequest will block this behaviour, which is highly
irritating as I have many FTP servers where this type of masking takes place.

As I have found no way of changing this I am resorting to using a raw Socket
with an SslStream (which btw is a fine implementation), but it is a shame
about FtpWebRequest and I have lodged this as a flaw on the Microsoft bug
network.

Thanks again,

Martin

 

[Kevin Spencer]

Are you sure that this isn't somehow related to the fact that both machines
are on the same LAN?

In fact, are you saying that the server and client are on the same machine?

I would have no idea how this would affect the situation.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Guest]

Hi Kevin,

You are over complicating the problem, I was merely offering a way of
showing that the FtpWebRequest class exhibits invalid behaviour to what is
clearly a legitimate server response.

In short: This problem occurs whenever the PASV response IP is different to
the original control connection address. However, under the RFC it is
perfectly acceptable for the server to behave in this way. This occurs in
situations other than a LAN environment, for example when an FTP server has a
control connection bouncer to hide it's external IP but uses the real IP for
PASV responses. It can occur even on the same machine (LAN or otherwise).

A response with a different passive IP is legitimate in the sense that the
RFC states it is so and any decent client for Windows (FlashFXP, WSFTP,
CuteFTP etc.) handle it correctly.

I believe that this is a "By Design" bug where Microsoft have deliberately
chosen to chop and change with the predesigned standards. I sadly therefore
do not think that this issue will be fixed.

Martin

 

[Kevin Spencer]

Well, Martin, I think you're on the right track. My research shows me that
the FtpWebRequest and FtpWebResponse classes are fairly limited in their
functionality. For example, setting the UsePassive property sends a "PASV"
messages to the server, but AFAIK, there is no way to read the response. I
spent some time trying myself, just to make sure.

You can turn network tracing on to see the conversation, but that doesn't
help with the functionality of the app.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.