|
On Thu, 22 Feb 2001, Julian Anastasov wrote:
> Oh, yes. But commenting sSA is not correct. It is valid state
> that can be entered while the defense strategy is ON. Sometimes it
> switches to OFF while the connection is still in sSA, so this is valid
> state. Of course, in your case you never enter sSA :)
So, you mean that it is necessary another sSA at the end (one on the 5th
position and one at the end) ? In the patch it IS present in the 5th position
in the table (moved from last pos to 5th pos).
Please explain a litle more if I'm wrong.
> I'll test it soon. May be the problem is that the data is not
> detected in all cases, not sure. May be the problem is in the "227 ..."
> text. I remember such fixes to go into netfilter. What "227 ..." string
> reports your ftp server for passive mode?
227 Entering Passive Mode (172,18,1,58,8,174).
Debug logs indicate that the ftp module intercepts and processes it, but the
insertion in the NAT rules is somehow wrong. The /proc/net/ip_vs_conn show
that connection in its correct state (NONE or SYN_RCVD), but the connection
isn't forwarded and NATed. Just look at the patch (where ^- is ^+ :)
Here's some debugging from a session that didn't work with passive mode (the
data connection was simply refused)
IPVS: Ftp: loaded support on port[0] = 21
IPVS: got PASV at 12 of 18
IPVS: PASV response (172.18.1.233:2737) -> 172.18.1.62:0 detected
IPVS: new PORT 172.18.1.58:2737
IPVS: warning: packet_xmit is null
Ah, btw, the ftp module in 0.1.2 (ready-for-production version) systematically
causes the director machine to crash when a PORT or PASV response is
encountered.
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
Radu-Adrian Feurdean
mailto: raf@xxxxxxxx
-------------------------------------------------------------------
"If the night is silent enough you can hear a Windows NT rebooting"
|
