|
Mark de Vries <markdv.lvsuser@xxxxxxxxxx> wrote:
> On Wed, 30 Nov 2005, Horms wrote:
>
>> Mark de Vries <markdv.lvsuser@xxxxxxxxxx> wrote:
>> > On Sun, 27 Nov 2005, Roberto Nibali wrote:
>> >
>> >> >> Is there an indication in RFC959 which states that this "behaviour" is
>> >> >> legal as well for active FTP?
>> >> >
>> >> > no-one requires code to obey standards to sell it ;-(
>> >>
>> >> Well, vsftp is GPL and written by someone I happen to know even :). But
>> >> it must be RFC conformant or else clients would not be able to properly
>> >> interact with the server.
>> >
>> > As far as I understands the RFC leaves no room for a different src port
>> > for the data connection. It's not fixed at 20 but should be 1 below the
>> > controll port. Which is what ip_vs uses literally IIRC.
>>
>> Still, it would be harmless enough to add an option, passed
>> as a module loading parameter to ip_vs_ftp, that allows an
>> alternate port. It would be globabl, and obviously there are
>> cases it wouldn't cover, but it would solve the problem at hand.
>
> No. The point/problem is that the src port is unknown untill the server
> actually connects to the client. The only way to fix this particular issue
> is to create the connectio with an unknown src port (and then later fill
> it in), as is done for the client src port in the passive case.
Thanks for clarifying. I missed that.
>> I guess the remaining question is, should the problem at hand be solved
>> in LVS.
>
> True. That is the question. vsftpd is obviously operating in a non
> rfc-compliant way (configurable) so ipvs is not at fault.
>
> On the other hand I personally have never had any issues connecting to
> servers acting like this. For my experiance it apears that most clients
> don't care from which port the active connection originates from (or even
> the IP) as long as it is to the correct port. And also all firewalls I
> have been behind as a client don't care from which port the connection
> originates from.
>
> So we have servers disregarding strict rfc-compliance. We have firewalls
> not enforcing rfc-compliant behaviour. And we have clients that don't
> require rfc-complient behaviour. The only 'hop' en route that's beeing
> pendantic is ip_vs. Now I'm not saying we should jump of a bridge just
> bacause everybody else is... and I'm sure there are cases where this
> behaviour will break. But if 'they' want to jump of the bridge then who
> are 'we' to stand in their way?
>
> Personally I can't think of a good reason why the fixed ftp-data src port
> should be maintained. The only thing it's good for is predictable holes is
> stateless firewalls...
I'm pretty sure I agree. Care to cook up a patch?
--
Horms
|
