|
On Thu, 1 Dec 2005, Horms wrote:
> 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?
I'll take a look but I'm not familiar with ip_vs internals so I'd have to
try to get my head around that first. I already inquired about
documentation but aparently there isn't a whole lot (targeted at
developers) so might take some time.
Regards,
Mark
|
