All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Chandran <vinod_chandran@multitech.co.in>
Cc: netfilter-devel <netfilter-devel@lists.netfilter.org>,
	netfilter@lists.netfilter.org
Subject: Re: Usage of CONNMARK
Date: Mon, 07 Feb 2005 09:46:53 +0530	[thread overview]
Message-ID: <4206EBB5.5090001@multitech.co.in> (raw)
In-Reply-To: Pine.LNX.4.61.0502060136540.22104@filer.marasystems.com

Hi Henrik,

In case of partail request, too I found the packets where not dropping. 
I had checked it by using nf-drill.pl, given in the FTP advisory. Modify 
the script to give a partial PORT command. The packet goes across the 
firewall and reaches the FTP server. I have connected my FTP server to 
DMZ and running the script from the LAN side.
Setting connection mark does work, but for the next packet and not the 
current one.

Thanks and Regards,
Vinod C

Henrik Nordstrom wrote:

> On Sat, 5 Feb 2005, Vinod Chandran wrote:
>
>> Currently, from the FTP helper if DROP is given, the packets are not 
>> getting dropped since the conntrack entry exists and also since from 
>> where the helper routine is called, there is no check for return 
>> value of NF_DROP. Hence when NF_DROP is returned, inside 
>> ip_conntrack_in, I set the conntrack value
>>      ct->mark = 1
>> However this CONNMARK value is getting applicable only from the next 
>> packet ownwards.
>
>
> I do not follow. Conntract helpers can return NF_DROP to drop the 
> packets, and this will cause the packet to be dropped. This is 
> actively used today by the FTP helper when an partial request is 
> received.
>
>> From ip_conntrack_in:
>
>
>         if (ret != NF_DROP && ct->helper) {
>                 ret = ct->helper->help(*pskb, ct, ctinfo);
>     [...]
>
>     return ret;
> }
>
>> If on the other hand, say I try to change the mark value, 
>> (*pskb)->nfmark ( I assume it contains the MARK indicator), and put a 
>> rule in the KEEP_STATE_FORWARD chain to drop packets with the 
>> specific mark value, the kernel is panicing , with a BUG in sched.c. 
>> I also get panic if I call nf_conntrack_put.
>
>
> Setting the nfmark like this (MARK) should work, and should not panic 
> your system.
>
> In addition, setting the connection mark from helpers called in 
> ip_conntrack_in should be available in all iptables chains.
>
>
> All three of your problems makes no sense to me. All should work 
> (return NF_DROP from helpers, setting the connection mark, setting the 
> nfmark).
>
> Regards
> Henrik
>





  reply	other threads:[~2005-02-07  4:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-04  8:13 Usage of CONNMARK Vinod Chandran
2005-02-04 14:17 ` Henrik Nordstrom
2005-02-05  7:36   ` Vinod Chandran
2005-02-06  0:51     ` Henrik Nordstrom
2005-02-06  0:51       ` Henrik Nordstrom
2005-02-07  4:16       ` Vinod Chandran [this message]
2005-02-04 21:35 ` dwhite

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4206EBB5.5090001@multitech.co.in \
    --to=vinod_chandran@multitech.co.in \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.