Re: FtpWebRequest Passive Mode Problem
- From: "Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 5 Nov 2005 08:27:14 -0500
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.
"Martin_Paul" <MartinPaul@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A0E6AA63-EDF2-4480-AA2F-550E914D4F48@xxxxxxxxxxxxxxxx
> 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" wrote:
>
>> 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.
>>
>> "Martin_Paul" <Martin_Paul@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:33C7E6E2-D386-40EB-AF70-D366AC33F050@xxxxxxxxxxxxxxxx
>> > 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
>>
>>
>>
.
- Follow-Ups:
- Re: FtpWebRequest Passive Mode Problem
- From: Martin_Paul
- Re: FtpWebRequest Passive Mode Problem
- Prev by Date: Re: beta2 & final release
- Next by Date: Will Visual Stuido Enrich MSIL coding?
- Previous by thread: beta2 & final release
- Next by thread: Re: FtpWebRequest Passive Mode Problem
- Index(es):
Relevant Pages
|
