Re: ip_conntrack_ftp messages

Re: ip_conntrack_ftp messages

[Rusty Russell]

On Monday 24 November 2008 10:43:19 Shane Goulden wrote:
> 2.6.18-92.1.10.el5xen
>
> FTP is working. Is there a way to easily silence the messages?

Not that I am aware of.  Perhaps that printk (still there in latest kernels) 
should be downgraded to a DEBUG?

		if (net_ratelimit())
			printk("conntrack_ftp: partial %s %u+%u\n",
			       search[dir][i].pattern,
			       ntohl(th->seq), datalen);

Cheers,
Rusty.

Re: ip_conntrack_ftp messages

[Patrick McHardy]

Rusty Russell wrote:
> On Monday 24 November 2008 10:43:19 Shane Goulden wrote:
>> 2.6.18-92.1.10.el5xen
>>
>> FTP is working. Is there a way to easily silence the messages?
> 
> Not that I am aware of.  Perhaps that printk (still there in latest kernels) 
> should be downgraded to a DEBUG?
> 
> 		if (net_ratelimit())
> 			printk("conntrack_ftp: partial %s %u+%u\n",
> 			       search[dir][i].pattern,
> 			       ntohl(th->seq), datalen);

Its strange that FTP is apparently working since we drop those packets.
I'm not sure about downgrading that message, its there to inform the
user of an exceptional action (dropping of packets within conntrack).

Shane, how do you trigger those messages?

Re: ip_conntrack_ftp messages

[Phil Oester]

On Mon, Nov 24, 2008 at 01:28:09PM +0100, Patrick McHardy wrote:
> Rusty Russell wrote:
>> On Monday 24 November 2008 10:43:19 Shane Goulden wrote:
>>> 2.6.18-92.1.10.el5xen
>>>
>>> FTP is working. Is there a way to easily silence the messages?
>>
>> Not that I am aware of.  Perhaps that printk (still there in latest 
>> kernels) should be downgraded to a DEBUG?
>>
> Its strange that FTP is apparently working since we drop those packets.
> I'm not sure about downgrading that message, its there to inform the
> user of an exceptional action (dropping of packets within conntrack).
>
> Shane, how do you trigger those messages?

I've seen these messages when something other than FTP is utilizing
port 21.  Perhaps we should have a bit in the conntrack helper which
stops looking on future packets if it doesn't see FTP traffic in the
beginning of the session?

Phil

Re: ip_conntrack_ftp messages

[Patrick McHardy]

Phil Oester wrote:
> On Mon, Nov 24, 2008 at 01:28:09PM +0100, Patrick McHardy wrote:
>> Rusty Russell wrote:
>>> On Monday 24 November 2008 10:43:19 Shane Goulden wrote:
>>>> 2.6.18-92.1.10.el5xen
>>>>
>>>> FTP is working. Is there a way to easily silence the messages?
>>> Not that I am aware of.  Perhaps that printk (still there in latest 
>>> kernels) should be downgraded to a DEBUG?
>>>
>> Its strange that FTP is apparently working since we drop those packets.
>> I'm not sure about downgrading that message, its there to inform the
>> user of an exceptional action (dropping of packets within conntrack).
>>
>> Shane, how do you trigger those messages?
> 
> I've seen these messages when something other than FTP is utilizing
> port 21.  Perhaps we should have a bit in the conntrack helper which
> stops looking on future packets if it doesn't see FTP traffic in the
> beginning of the session?

That would make sense, but I can't see a good way to make this
decision except maybe when we seen non-ascii characters. But
even that will fail with different encodings. Do you have a
good idea?

Re: ip_conntrack_ftp messages

[Jan Engelhardt]

On Monday 2008-11-24 16:32, Patrick McHardy wrote:
>> 
>> I've seen these messages when something other than FTP is utilizing
>> port 21.  Perhaps we should have a bit in the conntrack helper which
>> stops looking on future packets if it doesn't see FTP traffic in the
>> beginning of the session?
>
> That would make sense, but I can't see a good way to make this
> decision except maybe when we seen non-ascii characters. But
> even that will fail with different encodings. Do you have a
> good idea?

Well, each packet (or rather, every new line) should be a "123 " code,
followed by whatever text plus a newline.

Re: ip_conntrack_ftp messages

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2008-11-24 16:32, Patrick McHardy wrote:
>>> I've seen these messages when something other than FTP is utilizing
>>> port 21.  Perhaps we should have a bit in the conntrack helper which
>>> stops looking on future packets if it doesn't see FTP traffic in the
>>> beginning of the session?
>> That would make sense, but I can't see a good way to make this
>> decision except maybe when we seen non-ascii characters. But
>> even that will fail with different encodings. Do you have a
>> good idea?
> 
> Well, each packet (or rather, every new line) should be a "123 " code,
> followed by whatever text plus a newline.

Right, that should work. If someone wants to cook up a patch,
I have no objections :)

Re: ip_conntrack_ftp messages

[Pascal Hambourg]

Hello,

Jan Engelhardt a écrit :
> 
> Well, each packet (or rather, every new line) should be a "123 " code,
> followed by whatever text plus a newline.

Don't you mean "each reply" ? BTW, multi-line replies start with "123-", 
only the last line starts with "123 ".
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ip_conntrack_ftp messages

[Rusty Russell]

On Monday 24 November 2008 22:58:09 Patrick McHardy wrote:
> Rusty Russell wrote:
> > 		if (net_ratelimit())
> > 			printk("conntrack_ftp: partial %s %u+%u\n",
> > 			       search[dir][i].pattern,
> > 			       ntohl(th->seq), datalen);
>
> Its strange that FTP is apparently working since we drop those packets.
> I'm not sure about downgrading that message, its there to inform the
> user of an exceptional action (dropping of packets within conntrack).

Actually, we drop the packets *so* it will work.  The idea is that they'll 
coalesce and send the whole packet next time.

If not, well, they don't get any more packes through, but without connection 
tracking the other connections wouldn't work anyway (if the conntrack is being 
used for NAT or filtering).

IIRC wu-ftpd used to trigger this (multiple write syscalls for the ip address 
and nagle sometimes hit in the middle; go figure).

Cheers,
Rusty.

Re: ip_conntrack_ftp messages

[Patrick McHardy]

Rusty Russell wrote:
> On Monday 24 November 2008 22:58:09 Patrick McHardy wrote:
>> Rusty Russell wrote:
>>> 		if (net_ratelimit())
>>> 			printk("conntrack_ftp: partial %s %u+%u\n",
>>> 			       search[dir][i].pattern,
>>> 			       ntohl(th->seq), datalen);
>> Its strange that FTP is apparently working since we drop those packets.
>> I'm not sure about downgrading that message, its there to inform the
>> user of an exceptional action (dropping of packets within conntrack).
> 
> Actually, we drop the packets *so* it will work.  The idea is that they'll 
> coalesce and send the whole packet next time.

I see. The only case in which I triggered it so far was when sending
incomplete PORT commands using telnet, so I missed this important
fact :)

> If not, well, they don't get any more packes through, but without connection 
> tracking the other connections wouldn't work anyway (if the conntrack is being 
> used for NAT or filtering).
> 
> IIRC wu-ftpd used to trigger this (multiple write syscalls for the ip address 
> and nagle sometimes hit in the middle; go figure).

Thanks for the explanation. I'll queue up a patch for 2.6.29 to change
it to pr_debug().