All of lore.kernel.org
 help / color / mirror / Atom feed
From: Visham Ramsurrun <vishamr2000@gmail.com>
To: netfilter@lists.netfilter.org
Subject: Re: netfilter Digest, Vol 10, Issue 74
Date: Fri, 27 May 2005 18:31:55 +0400	[thread overview]
Message-ID: <9927912d05052707311500514d@mail.gmail.com> (raw)
In-Reply-To: <42971843.64531163.6abe.2deeSMTPIN_ADDED@mx.gmail.com>

> On Wed, May 25, 2005 at 02:24:17PM +0400, Visham Ramsurrun wrote:
> > What I mean by this is that the when a protocol is unknown to the
> > ip_conntrack module if you don't have or don't want to use helper
> > conntrack modules like that for TCP or FTP), connection tracking
> > adopts a default method for handling these packets. It resembles the
> > handling of UDP packets. When this default behaviour is used, even a
> > packet that is not the SYN packet is considered as NEW. A second
> > packet in the reverse direction (reply packet) will set the connection
> > state to ESTABLISHED.
> 
> if you're asking if there's a way to modify the conntrack code to ignore
> the fact that TCP traffic is TCP traffic, and instead treat it as some
> random, unknown IP protocol; i would imagine you would have to hack the
> crap outta the conntrack code, basically removing
> ip_conntrack_proto_tcp.c from the equation.  i have no clue how you
> would go about doing this.  i also have no idea what your impetus behind
> this desire is; therefore, i can make no suggestion as to whether there
> may be an easier way to accomplish your goal.
> 

What I actually want is that, whether it is TCP traffic or that of any
other protocol, the traffic be treated in the same way. I read in the
Iptables Tutorial that there is a default connection tracking
mechanism. There are specific protocol helper modules for handling
specific protocol traffic (TCP, FTP are some examples). So, for the
traffic of any particular protocol, either you use a a conntrack
helper module (if it exists), or you use the default connection
tracking of ip_conntrack which actually handles traffic from any
protocol in the same way.

Having said that, what I would like to know is whether when this
default behaviour is used,
1) is a packet considered as NEW even it is not the SYN packet.
2) will a second packet in the reverse direction (reply packet) will
set the connection state to ESTABLISHED.

I just don't know how to verify this..that's why I asked you for help
because you have much more experience with iptables and hence, maybe
you have come across this.

Many many thx for the reply...

Best regards,
Visham


       reply	other threads:[~2005-05-27 14:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42971843.64531163.6abe.2deeSMTPIN_ADDED@mx.gmail.com>
2005-05-27 14:31 ` Visham Ramsurrun [this message]
2005-05-27 20:30   ` netfilter Digest, Vol 10, Issue 74 Jason Opperisano

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=9927912d05052707311500514d@mail.gmail.com \
    --to=vishamr2000@gmail.com \
    --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.