LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: bug(s) in ipvs-0.2.4

To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: bug(s) in ipvs-0.2.4
Cc: Radu-Adrian Feurdean <raf@xxxxxxxx>
From: Wensong Zhang <wensong@xxxxxxxxxxxx>
Date: Thu, 22 Feb 2001 22:33:21 +0800 (CST)
Hello,

Thanks a lot for the report.

Just found another terrible bug introduced since ipvs-0.2.3, I forgot
unregistering the forward_icmp hook in the module exit.
        nf_unregister_hook(&ip_vs_forward_icmp_ops);

Will trace the bug now, and hope that we will release a new version
soon.

Thanks,

Wensong


On Thu, 22 Feb 2001, Julian Anastasov wrote:

>
>       Hello,
>
> On Thu, 22 Feb 2001, Radu-Adrian Feurdean wrote:
>
> >
> > Hi,
> > While trying to implement a load-balancer based on ipvs-0.2.4 I found some
> > bugs in the code. The testing environment used is: kernel 2.4.2-pre[34] for
> > load balancer and NAT as load-balancing method
> >
> > 1. TCP state transition diagrams in ipvs/ip_vs_conn.c have initial states in
> > the wrong order (according to ipvs/ip_vs.h). The problem is that
> > IP_VS_S_SYNACK should be the 5th state in the table and it is the last. I 
> > have
> > observed this because a close request initiated by the client leaves the
> > connection open on the director. Here are the debug messages:
> >
> > IPVS: Schedule fwd:M s:NONE c:172.18.1.62:3206 v:172.18.1.58:21 
> > d:172.18.1.231:21 flg:140 cnt:2
> > IPVS: TCP input  [S...] 172.18.1.231:21->172.18.1.62:3206 state: 
> > NONE->SYN_RECV cnt:2
> > IPVS: TCP input  [..A.] 172.18.1.231:21->172.18.1.62:3206 state: 
> > SYN_RECV->ESTABLISHED cnt:2
> > IPVS: TCP input  [.FA.] 172.18.1.231:21->172.18.1.62:3206 state: 
> > ESTABLISHED->CLOSE_WAIT cnt:2
> > IPVS: TCP output  [..A.] 172.18.1.231:21->172.18.1.62:3206 state: 
> > CLOSE_WAIT->LAST_ACK cnt:2
> > IPVS: TCP output  [.FA.] 172.18.1.231:21->172.18.1.62:3206 state: 
> > LAST_ACK->LISTEN cnt:2
> > IPVS: TCP input  [..A.] 172.18.1.231:21->172.18.1.62:3206 state: 
> > LISTEN->ESTABLISHED cnt:2
> >
> > You can see that the last 2 lines are not exactly a correct behaviour.
> >
> > 2. The ftp module does not work for passive mode (it doesn't work at all but
> > the active mode can be managed using standard masquerading). The FTP 
> > handling
> > code does not properly deal with the new connection (the director doesn't
> > handle it at all).
> >
> > There is an attached patch that solves the two above-mentioned problems. I'm
> > not sure that the second problem is resolved the right way, but at least it
> > works.
>
>       Ignoring the fact your patch is broken the (1) is a _REAL_ bug.
> We must move and insert the SA column before FW. It seems the
> SA value is different from Linux 2.2 but the same transition table is
> used :)
>
>       For (2) we have to analyze where is really the problem. Personally,
> I didn't tried the ftp module from long time ago.
>
>       Thanks for this report.
>
> > Bye
> >
> > Radu-Adrian Feurdean
> > mailto: raf@xxxxxxxx
> > -------------------------------------------------------------------
> > "If the night is silent enough you can hear a Windows NT rebooting"
>
>
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>



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