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@xxxxxxxxxxxx
Victoria, BC,Canada
Attachment:
pgpbhrRjQ5l5P.pgp
Description: PGP signature
