conntrack -E -i not allowed?

conntrack -E -i not allowed?

[Alan Ezust]

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

I'm trying to get conntrack -E to show me events, with conntrack IDs.
At the moment, the ctid is now showing up in the output unless there is an 
[UNREPLIED] part to the line.

$ conntrack -E -i
conntrack v1.00beta2: Illegal option `-i' with this command


   [NEW] udp      17 30 src=10.10.100.100 dst=204.174.64.1 sport=4536 dport=53 
packets=1 bytes=67 [UNREPLIED] src=204.174.64.1 dst=10.10.100.100 sport=53 
dport=4536 packets=0 bytes=0

Is there a trick to getting the ctids to be sent to the output of this?

conntrack -L -i seems to work, showing me the id. Personally, I think 
conntrack should always output the id.



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

Re: conntrack -E -i not allowed?

[Alan Ezust]

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


Conntrack uses the following structures, but there is no documentation about 
what these structures are for, or where they are used:

// nf_conntrack.h (kernel headers)
struct nf_conn - for the *data member, what kind of structures get stored 
there?

nf_conntrack_tuple, nf_conntrack_expect

// nf_conntrack_tuple.h
nf_conntrack_tuple_hash - a linked list of tuples? Where is the code that 
inserts/removes elements from this hash?

nf_conntrack_tuple - this contains the information to distingusih a 
connection - is this the main structure? What is its relationship to the 
nfct_tuple?

// libnetfilter_conntrack.h:31
nfct_handle - /* Harald says: "better for encapsulation" ;) */
This comment is not helpful, just annoying. I'd like to see a proper 
description of this structure and a short line or two summarizing where/why 
it is used. is this for a single connection, or the conntrack system?

nfct_conntrack - seems to be the main structure used by    
    libnfnetlink The array of tuples is used to store table 
    data (?)

Other types i'd like to see proper API docs for:
    nfct_tuple
    nfct_callback 

Anyway, the reason I am delving into this code now is that I am trying patch 
conntrack so that when you do conntrack -E -i, it gives you the ctid in the 
output lines.

I ran conntrack in a debugger and it keeps bringing me into the 
nfnl_parse_attr method via libnetfilter_conntrack.c line 526.

Debugging it, and inspecting the "nfa" structure,
It seems to be an array of struct nfattr objects. 
These nfattr structs have 2 fields, a length and a type.
It describes, I assume, which fields need to be extracted from the tuplehash.

This nfa structure is extracted from the struct nlmsghdr which was passed to 
nfct_conntrack_netlink_handler. So this struct doesn't contain the right 
information in it to tell parse_attr to to put a ctid record into its tb.

All this is called indirectly from nfnl_listen, which gets the nlmsghdr from 
callback_handler, which gets it from nfct_conntrack_netlink_handler. But my 
debugger isn't showing me where that function was called from (perhaps 
because it's coming from the kernel?)

So I think my question is, where is that struct nlmsghdr created that is being 
passed to the nfct_conntrack_netlink_handler, and where would be the right 
place to add an element to it so that there is a ctid. If that was done, 
would that be sufficient to get the ctid into the logline, or is there more 
to it than that?

Gads, tracing through this code gives me a headache.

On Wednesday 01 November 2006 10:43, Alan Ezust wrote:
> I'm trying to get conntrack -E to show me events, with conntrack IDs.
> At the moment, the ctid is not showing up in the output.
>
> $ conntrack -E -i
> conntrack v1.00beta2: Illegal option `-i' with this command
>
>
>    [NEW] udp      17 30 src=10.10.100.100 dst=204.174.64.1 sport=4536
> dport=53 packets=1 bytes=67 [UNREPLIED] src=204.174.64.1 dst=10.10.100.100
> sport=53 dport=4536 packets=0 bytes=0
>
> Is there a trick to getting the ctids to be sent to the output of this?
>
> conntrack -L -i seems to work, showing me the id. Personally, I think
> conntrack should always output the id.

-- 
Alan Ezust            www.presinet.com
Presinet, inc         alan.ezust@presinet.com
           Victoria, BC,Canada

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

Re: conntrack -E -i not allowed?

[Pablo Neira Ayuso]

Alan Ezust wrote:
>> Is there a trick to getting the ctids to be sent to the output of this?

There is not.

>> conntrack -L -i seems to work, showing me the id. Personally, I think
>> conntrack should always output the id.

No, actually we have plans to remove it soon. Why do you need the id?

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: conntrack -E -i not allowed?

[Alan Ezust]

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

We need to be able to determine when we get an UPDATE or a DISCONNECT, which 
connections they correspond to. I assumed that was the purpose of the CT id. 
Why are you removing it? 


On Tuesday 07 November 2006 04:40, Pablo Neira Ayuso wrote:
> Alan Ezust wrote:
> >> Is there a trick to getting the ctids to be sent to the output of this?
>
> There is not.
>
> >> conntrack -L -i seems to work, showing me the id. Personally, I think
> >> conntrack should always output the id.
>
> No, actually we have plans to remove it soon. Why do you need the id?

-- 
Alan Ezust            www.presinet.com
Presinet, inc         alan.ezust@presinet.com
           Victoria, BC,Canada

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

Re: conntrack -E -i not allowed?

[Pablo Neira Ayuso]

Alan Ezust wrote:
> We need to be able to determine when we get an UPDATE or a DISCONNECT, which 
> connections they correspond to. I assumed that was the purpose of the CT id.

The purpose was to uniquely identify a connection but we currenlty 
assume that the tuple {src, portsrc, dst, portdst, l3protonum, protonum} 
is enough.

> Why are you removing it? 

http://lists.netfilter.org/pipermail/netfilter-devel/2005-June/019923.html

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: conntrack -E -i not allowed?

[Alan Ezust]

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


Thanks for the reply. Ok, I can see how I can generate some IDs, but I first 
want to make sure i have all of the information I need.

When I run conntrack, I only see one protocol number. I think it is a layer4 
protocol (tcp vs udp). If I'm not seeing an l3proto in my output, why might 
that be?

udp      17 12 src=10.10.201.2 dst=204.174.64.1 sport=54475 dport=53 
src=204.174.64.1 dst=209.53.156.2 sport=53 dport=54475 use=1 mark=0
tcp      6 420332 ESTABLISHED src=10.10.100.3 dst=10.10.1.22 sport=1356 
dport=5432 src=10.10.1.22 dst=10.10.100.3 sport=5432 dport=1356 [ASSURED] 
use=1 mark=0


On Wednesday 08 November 2006 11:29, Pablo Neira Ayuso wrote:
> Alan Ezust wrote:
> > We need to be able to determine when we get an UPDATE or a DISCONNECT,
> > which connections they correspond to. I assumed that was the purpose of
> > the CT id.
>
> The purpose was to uniquely identify a connection but we currenlty
> assume that the tuple {src, portsrc, dst, portdst, l3protonum, protonum}
> is enough.
>
> > Why are you removing it?
>
> http://lists.netfilter.org/pipermail/netfilter-devel/2005-June/019923.html

-- 
Alan Ezust            www.presinet.com
Presinet, inc         alan.ezust@presinet.com
           Victoria, BC,Canada

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

Re: conntrack -E -i not allowed?

[Pablo Neira Ayuso]

Alan Ezust wrote:
> Thanks for the reply. Ok, I can see how I can generate some IDs, but I first 
> want to make sure i have all of the information I need.
> 
> When I run conntrack, I only see one protocol number. I think it is a layer4 
> protocol (tcp vs udp). If I'm not seeing an l3proto in my output, why might 
> that be?
> 
> udp      17 12 src=10.10.201.2 dst=204.174.64.1 sport=54475 dport=53 
> src=204.174.64.1 dst=209.53.156.2 sport=53 dport=54475 use=1 mark=0
> tcp      6 420332 ESTABLISHED src=10.10.100.3 dst=10.10.1.22 sport=1356 
> dport=5432 src=10.10.1.22 dst=10.10.100.3 sport=5432 dport=1356 [ASSURED] 
> use=1 mark=0

Are you using nf_conntrack? If so, l3protonum is not shown yet but it
would not be hard to cook a patch to show it. I'll introduce this change
in the new libnetfilter_conntrack API.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: conntrack -E -i not allowed?

[Alan Ezust]

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

Yes, I'm using svn checked out versions of your libnfnetlink and 
libnetfilter_conntrack, so let me know when you check in your changes and 
I'll update. Thanks ! --alan



On Thursday 09 November 2006 09:10, Pablo Neira Ayuso wrote:
> Alan Ezust wrote:
> > Thanks for the reply. Ok, I can see how I can generate some IDs, but I
> > first want to make sure i have all of the information I need.
> >
> > When I run conntrack, I only see one protocol number. I think it is a
> > layer4 protocol (tcp vs udp). If I'm not seeing an l3proto in my output,
> > why might that be?
> >
> > udp      17 12 src=10.10.201.2 dst=204.174.64.1 sport=54475 dport=53
> > src=204.174.64.1 dst=209.53.156.2 sport=53 dport=54475 use=1 mark=0
> > tcp      6 420332 ESTABLISHED src=10.10.100.3 dst=10.10.1.22 sport=1356
> > dport=5432 src=10.10.1.22 dst=10.10.100.3 sport=5432 dport=1356 [ASSURED]
> > use=1 mark=0
>
> Are you using nf_conntrack? If so, l3protonum is not shown yet but it
> would not be hard to cook a patch to show it. I'll introduce this change
> in the new libnetfilter_conntrack API.

-- 
Alan Ezust            www.presinet.com
Presinet, inc         alan.ezust@presinet.com
           Victoria, BC,Canada

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