Well, I was thinking that too, but I suspect it isn't the case, because I did a simple test. I telneted through my firewall to an ftp server's port 21. I then issued the user and pass commands one character at a time (each character got its own packet, verified via sniffer.)
I don't think that's what his problem is, although I can't say I have any clue as to what *is* the problem. It may be usefull to unload the ip_conntrack_ftp and ip_nat_ftp modules and see if that changes the behavior any, and/or try a straight telnet to port 21 and see if it causes the same problem. -Joe > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ramin Alidousti > Sent: Thursday, April 25, 2002 8:53 PM > To: Dougherty, Joe > Cc: '[EMAIL PROTECTED]' > Subject: Re: mangled ftp packets preventing connection > > > Joe, > > I'm not sure what exactly ftp_conntrack and ftp_nat do internally and > I'm not a kernel hacker to just go ahead and read the code to figure > out about this but it might very well be the case that either of these > modules are scanning through the ftp dialog to gather the necessary > information for further conntrack/nat processing of the ftp session. > As it's very odd that a TCP segment with only 'P' goes through as opposed > to 'PASS...' it can be that the code cannot deal with this partial dialog. > This is just a hunch. Kernel hackers?!? > > Ramin > > On Thu, Apr 25, 2002 at 07:13:24PM -0400, Dougherty, Joe wrote: > >
