[PATCH] flow statistic match

[PATCH] flow statistic match

[Jay Schulist]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 804 bytes --]

Hello Harald,
Here is a new match which adds per tuple packet and byte statistics along
with allowing the user to match on the number of bytes and packets for a
flow.

Iptables userspace patch is against a clean iptables-1.2.7a
Kernel patch is against a clean linux-2.4.19

# cat /proc/net/ip_conntrack
tcp      6 432000 ESTABLISHED src=192.168.1.3 dst=192.168.1.100 sport=22
dport=3368 pkts=39 bytes=4024 src=192.168.1.100 dst=192.168.1.3 sport=3368
dport=22 pkts=47 bytes=3512 use=1

flow v1.2.7a options:
   --lt-packet  num             Match on less than 'num' packet.
   --lt-byte    num             Match on less than 'num' byte.
   --gt-packet num              Match on greater than or equal 'num' packet.
   --gt-byte   num              Match on greater than or equal 'num' byte.

Thanks,
jay-s.

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2189 bytes --]

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 1809 bytes --]

[PATCH] flow statistic match

[Jay Schulist]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 804 bytes --]

Hello Harald,
Here is a new match which adds per tuple packet and byte statistics along
with allowing the user to match on the number of bytes and packets for a
flow.

Iptables userspace patch is against a clean iptables-1.2.7a
Kernel patch is against a clean linux-2.4.19

# cat /proc/net/ip_conntrack
tcp      6 432000 ESTABLISHED src=192.168.1.3 dst=192.168.1.100 sport=22
dport=3368 pkts=39 bytes=4024 src=192.168.1.100 dst=192.168.1.3 sport=3368
dport=22 pkts=47 bytes=3512 use=1

flow v1.2.7a options:
   --lt-packet  num             Match on less than 'num' packet.
   --lt-byte    num             Match on less than 'num' byte.
   --gt-packet num              Match on greater than or equal 'num' packet.
   --gt-byte   num              Match on greater than or equal 'num' byte.

Thanks,
jay-s.

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2189 bytes --]

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 1809 bytes --]

Re: [PATCH] flow statistic match

[Antony Stone]

On Wednesday 18 September 2002 7:44 am, Jay Schulist wrote:

> Hello Harald,
> Here is a new match which adds per tuple packet and byte statistics along
> with allowing the user to match on the number of bytes and packets for a
> flow.
>
> Iptables userspace patch is against a clean iptables-1.2.7a
> Kernel patch is against a clean linux-2.4.19
>
> # cat /proc/net/ip_conntrack
> tcp      6 432000 ESTABLISHED src=192.168.1.3 dst=192.168.1.100 sport=22
> dport=3368 pkts=39 bytes=4024 src=192.168.1.100 dst=192.168.1.3 sport=3368
> dport=22 pkts=47 bytes=3512 use=1
>
> flow v1.2.7a options:
>    --lt-packet  num             Match on less than 'num' packet.
>    --lt-byte    num             Match on less than 'num' byte.
>    --gt-packet num              Match on greater than or equal 'num' packet.
>    --gt-byte   num              Match on greater than or equal 'num' byte.

Consistency with other languages would suggest that --gt- means "greater 
than".   If you want "greater than or equal" use --ge-

Antony.

-- 

You can spend the whole of your life trying to be popular,
but at the end of the day the size of the crowd at your funeral
will be largely dictated by the weather.

 - Frank Skinner

Re: [PATCH] flow statistic match

[Jay Schulist]

On Wed, 18 Sep 2002, Antony Stone wrote:

> > flow v1.2.7a options:
> >    --lt-packet  num             Match on less than 'num' packet.
> >    --lt-byte    num             Match on less than 'num' byte.
> >    --gt-packet num              Match on greater than or equal 'num' packet.
> >    --gt-byte   num              Match on greater than or equal 'num' byte.
>
> Consistency with other languages would suggest that --gt- means "greater
> than".   If you want "greater than or equal" use --ge-
>

We should probably add the syntax --eq- like the ttl match, to make things
even more conistent.

jay-s.

Re: [PATCH] flow statistic match

[Patrick Schaaf]

Jay,

> Here is a new match which adds per tuple packet and byte statistics along
> with allowing the user to match on the number of bytes and packets for a
> flow.

Sorry, but another nitpicking comment from me :-)

Is it neccessary to call this "flow"? All the other matches related
to connection tracking, at least keep some semblance of that name in
their own naming. "flow" stands out as some new kind of connection
tracking concept (being in use in other systems for just that purpose,
e.g. the unidirectional Cisco netflow accounting stuff.)

As a proposal out of the blue, what about calling it "ctvolume", instead?

Would it be possible, in the near future, to use a "ctnetlink" interface
to get at the final counters when a conntrack is destroyed? :-)

best regards
  Patrick

Re: [PATCH] flow statistic match

[Jay Schulist]

On Wed, 18 Sep 2002, Patrick Schaaf wrote:

> Is it neccessary to call this "flow"? All the other matches related
> to connection tracking, at least keep some semblance of that name in
> their own naming. "flow" stands out as some new kind of connection
> tracking concept (being in use in other systems for just that purpose,
> e.g. the unidirectional Cisco netflow accounting stuff.)
> 
> As a proposal out of the blue, what about calling it "ctvolume", instead?
> 

Hello Patrick,
I am not really stuck on a the flow name, it was just what I happened to 
call it, we can definately call it something better.

> Would it be possible, in the near future, to use a "ctnetlink" interface
> to get at the final counters when a conntrack is destroyed? :-)
> 

Yeah, this is already available with the new iptables2/nfnetlink patches I 
will make available in a few days.

J.

Re: [PATCH] flow statistic match

[Jay Schulist]

On Wed, 18 Sep 2002, Patrick Schaaf wrote:

> Is it neccessary to call this "flow"? All the other matches related
> to connection tracking, at least keep some semblance of that name in
> their own naming. "flow" stands out as some new kind of connection
> tracking concept (being in use in other systems for just that purpose,
> e.g. the unidirectional Cisco netflow accounting stuff.)
> 
> As a proposal out of the blue, what about calling it "ctvolume", instead?
> 

Hello Patrick,
I am not really stuck on a the flow name, it was just what I happened to 
call it, we can definately call it something better.

> Would it be possible, in the near future, to use a "ctnetlink" interface
> to get at the final counters when a conntrack is destroyed? :-)
> 

Yeah, this is already available with the new iptables2/nfnetlink patches I 
will make available in a few days.

J.

Re: [PATCH] flow statistic match

[Roberto Nibali]

Hi.

> As a proposal out of the blue, what about calling it "ctvolume", instead?

Why :)

> Would it be possible, in the near future, to use a "ctnetlink" interface
> to get at the final counters when a conntrack is destroyed? :-)

Roman has done something like that already for our company, the patch (not the 
final version, but enough to have a glance at it) can be fetched at:

http://www.drugphish.ch/patches/roman/slog-kernel-2.4.18.diff

Cheers,
Roberto Nibali, ratz

-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: [PATCH] flow statistic match

[Peter Surda]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Tue, Sep 17, 2002 at 11:44:38PM -0700, Jay Schulist wrote:
> Hello Harald,
> Here is a new match which adds per tuple packet and byte statistics along
> with allowing the user to match on the number of bytes and packets for a
> flow.
This is uber-cool. I already see a very nice example of use: I mark the
packets in mangle to achieve different priority later with the prio qdisc.
Currently I mainly use --dport, but with this I can easily mark downloads (and
uploads) lower priority (e.g. >100kiB -> set lower priority, >5MiB -> set yet
lower priority).

I'll follow the development and when it makes into patch-o-matic I'll build a
new kernel and try it out.
 
> Thanks,
Thnx as well :-)

> jay-s.
Bye,

Peter Surda (Shurdeek) <shurdeek@panorama.sth.ac.at>, ICQ 10236103, +436505122023

--
            0 and 1. Now what could be so hard about that?

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]