"Martin_Paul" <Martin_P***@discussions.microsoft.com> wrote in message
news:33C7E6E2-D386-40EB-AF70-D366AC33F050@microsoft.com...
> 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" 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_P***@discussions.microsoft.com> wrote in message
> news:33C7E6E2-D386-40EB-AF70-D366AC33F050@microsoft.com...
> > 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
>
>
>

"Martin_Paul" <MartinP***@discussions.microsoft.com> wrote in message
news:A0E6AA63-EDF2-4480-AA2F-550E914D4F48@microsoft.com...
> 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_P***@discussions.microsoft.com> wrote in message
>> news:33C7E6E2-D386-40EB-AF70-D366AC33F050@microsoft.com...
>> > 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" wrote:

> 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" <MartinP***@discussions.microsoft.com> wrote in message
> news:A0E6AA63-EDF2-4480-AA2F-550E914D4F48@microsoft.com...
> > 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_P***@discussions.microsoft.com> wrote in message
> >> news:33C7E6E2-D386-40EB-AF70-D366AC33F050@microsoft.com...
> >> > 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
> >>
> >>
> >>
>
>
>

"Martin_Paul" <MartinP***@discussions.microsoft.com> wrote in message
news:7D91AD7D-3A56-46C1-8848-AD8103C90A95@microsoft.com...
> 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" wrote:
>
>> 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" <MartinP***@discussions.microsoft.com> wrote in message
>> news:A0E6AA63-EDF2-4480-AA2F-550E914D4F48@microsoft.com...
>> > 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_P***@discussions.microsoft.com> wrote in message
>> >> news:33C7E6E2-D386-40EB-AF70-D366AC33F050@microsoft.com...
>> >> > 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" wrote:

> 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.
>
> "Martin_Paul" <MartinP***@discussions.microsoft.com> wrote in message
> news:7D91AD7D-3A56-46C1-8848-AD8103C90A95@microsoft.com...
> > 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" wrote:
> >
> >> 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" <MartinP***@discussions.microsoft.com> wrote in message
> >> news:A0E6AA63-EDF2-4480-AA2F-550E914D4F48@microsoft.com...
> >> > 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_P***@discussions.microsoft.com> wrote in message
> >> >> news:33C7E6E2-D386-40EB-AF70-D366AC33F050@microsoft.com...
> >> >> > 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
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

"Martin_Paul" <MartinP***@discussions.microsoft.com> wrote in message
news:97405263-ABA2-4CA7-89CE-DF4835BADE83@microsoft.com...
> 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" wrote:
>
>> 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.
>>
>> "Martin_Paul" <MartinP***@discussions.microsoft.com> wrote in message
>> news:7D91AD7D-3A56-46C1-8848-AD8103C90A95@microsoft.com...
>> > 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" wrote:
>> >
>> >> 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" <MartinP***@discussions.microsoft.com> wrote in message
>> >> news:A0E6AA63-EDF2-4480-AA2F-550E914D4F48@microsoft.com...
>> >> > 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_P***@discussions.microsoft.com> wrote in
>> >> >> message
>> >> >> news:33C7E6E2-D386-40EB-AF70-D366AC33F050@microsoft.com...
>> >> >> > 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
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>