LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS-NAT Active FTP issue...

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: LVS-NAT Active FTP issue...
Cc: Horms <horms@xxxxxxxxxxxx>
Cc: Roberto Nibali <ratz@xxxxxx>
From: Mark de Vries <markdv.lvsuser@xxxxxxxxxx>
Date: Tue, 6 Dec 2005 08:12:36 +0100 (CET)
On Mon, 5 Dec 2005, Roberto Nibali wrote:

> > True, the developer documentation is more or less non-existent.
> > That said, the code isn't actually that large or complex,
> > so hopefully it won't take you too long to get your mind around it.
>
> To me the only mind-boggling thing are those interwoven structs, every
> time I get to work on the code again. I happen to think that this level
> of complexity would not be needed (also with regard of lockless data
> structures). If you know a of a tool that reads *.[ch] files on STDIN
> and writes out a nice UML class diagram, I'd be more than eager to know.

Yeah, me too! :)

> > In the case of hacking the ftp helper module,
> > you want to look at ./net/ipv4/ipvs/ip_vs_ftp.c
> > And in particular ip_vs_ftp_in()
> >
> > Actually in the course of looking over this I came up
> > with the following untested patch. The modification should
> > probably be made a run-time option as it uses no CPORT
> > entries as a wildcard, and this is a little bit of overhead
> > that isn't needed for the usual port 20 case.
>
> We could also merge some of the ftp helper modules advances of netfilter
> into the IPVS ftp helper module. They have added some more recognition code.

Nice idea... worth a look at.

> > Signed-Off-By: <horms@xxxxxxxxxxxx>
> >
> > diff --git a/net/ipv4/ipvs/ip_vs_ftp.c b/net/ipv4/ipvs/ip_vs_ftp.c
> > index a19a33c..05f4ba7 100644
> > --- a/net/ipv4/ipvs/ip_vs_ftp.c
> > +++ b/net/ipv4/ipvs/ip_vs_ftp.c
> > @@ -316,14 +316,14 @@ static int ip_vs_ftp_in(struct ip_vs_app
> >               NIPQUAD(to), ntohs(port), NIPQUAD(cp->vaddr), 0);
> >
> >     n_cp = ip_vs_conn_in_get(iph->protocol,
> > -                            to, port,
> > +                            to, 0,
> >                              cp->vaddr, htons(ntohs(cp->vport)-1));
> >     if (!n_cp) {
> >             n_cp = ip_vs_conn_new(IPPROTO_TCP,
> > -                                 to, port,
> > +                                 to, 0,
> >                                   cp->vaddr, htons(ntohs(cp->vport)-1),
> >                                   cp->daddr, htons(ntohs(cp->dport)-1),
> > -                                 0,
> > +                                 IP_VS_CONN_F_NO_CPORT,
> >                                   cp->dest);
>
> Bloody cheater :). So now we don't need to make ftp persistent anymore.
> I'm sure Joe will be happy to scrap a couple of hundreds of his HOWTO
> pages related to FTP ...

Well. I've been thinking about this after a quick run throught the code
(no time yet to realy get into it). I noticed some ftp specific stuff in
ip_vs_core.c:ip_vs_sched_persist. Is that code pre-ftp-helper? If I
understand correctly (which might not be that case) it should not be
required if the helper is loaded and doing it's job of inserting
connection templates for comming data connections. And if that's the case
then I don't see why ftp should be any more/less persistant then any other
service/protocol for correct operation?

Rgds,
Mark.

<Prev in Thread] Current Thread [Next in Thread>