Details of /proc/net/ip_conntrack and /proc/net/nf_conntrack

Question

I'm looking for a detailed documentation about content of files /proc/net/nf_conntrack and/or /proc/net/ip_contrack on Linux systems.

Yes, I know, there are many utilities which can show me the content of these files in human readable format, but... I'd like to do it on a SOHO router, with Tomato USB firmware (by Shibby). The optware AFAIK deprecated and the entware doesn't contain any of these utilities, so I'd like to write a script instead of them, but I didn't find a detailed description of these files :(

Answer 1

The format of a line from /proc/net/ip_conntrack is the same as for /proc/net/nf_conntrack, except the first two columns are missing.

I'll try to summarize the format of the latter file, as I understand it from the net/netfilter/nf_conntrack_standalone.c, net/netfilter/nf_conntrack_acct.c and the net/netfilter/nf_conntrack_proto_*.c kernel source files. The term layer refers to the OSI protocol layer model.

• First column: The network layer protocol name (eg. ipv4).
• Second column: The network layer protocol number.
• Third column: The transmission layer protocol name (eg. tcp).
• Fourth column: The transmission layer protocol number.
• Fifth column: The seconds until the entry is invalidated.
• Sixth column (Not all protocols): The connection state.

All other columns are named (key=value) or represent flags ([UNREPLIED], [ASSURED], ...). A line can contain up to two columns having the same name (eg. src and dst). Then, the first occurrence relates to the request direction and the second occurrence relates to the response direction.

Meaning of the flags:

• [ASSURED]: Traffic has been seen in both (ie. request and response) direction.
• [UNREPLIED]: Traffic has not been seen in response direction yet. In case the connection tracking cache overflows, these connections are dropped first.

Please note that some column names appear only for specific protocols (eg. sport and dport for TCP and UDP, type and code for ICMP). Other column names (eg. mark) appear only if the kernel was built with specific options.

Examples:

• ipv4 2 tcp 6 300 ESTABLISHED src=1.1.1.2 dst=2.2.2.2 sport=2000 dport=80 src=2.2.2.2 dst=1.1.1.1 sport=80 dport=12000 [ASSURED] mark=0 use=2 belongs to an established TCP connection from host 1.1.1.2, port 2000, to host 2.2.2.2, port 80, from which responses are sent to host 1.1.1.1, port 12000, timing out in five minutes. For this connection, packets have been seen in both directions.
• ipv4 2 icmp 1 3 src=1.1.1.2 dst=1.1.1.1 type=8 code=0 id=32354 src=1.1.1.1 dst=1.1.1.2 type=0 code=0 id=32354 mark=0 use=2 belongs to an ICMP echo request packet from host 1.1.1.2 to host 1.1.1.1 with an expected echo reply packet from host 1.1.1.1 to host 1.1.1.2, timing out in three seconds.

The response destination host is not necessarily the same as the request source host, as the request source address may have been masqueraded by the response destination host.

---

Please note that the following information might not be up-to-date!

Fields available for all entries:

• bytes (if accounting is enabled, request and response)
• delta-time (if CONFIG_NF_CONNTRACK_TIMESTAMP is enabled)
• dst (request and response)
• mark (if CONFIG_NF_CONNTRACK_MARK is enabled)
• packets (if accounting is enabled, request and response)
• secctx (if CONFIG_NF_CONNTRACK_SECMARK is enabled)
• src (request and response)
• use
• zone (if CONFIG_NF_CONNTRACK_ZONES is enabled)

Fields available for dccp, sctp, tcp, udp and udplite transmission layer protocols:

• dport (request and response)
• sport (request and response)

Fields available for icmp transmission layer protocol:

• code (request and response)
• id (request and response)
• type (request and response)

Fields available for gre transmission layer protocol:

• dstkey (request and response)
• srckey (request and response)
• stream_timeout
• timeout

Allowed values for the sixth field:

• dccp transmission layer protocol
  • CLOSEREQ
  • CLOSING
  • IGNORE
  • INVALID
  • NONE
  • OPEN
  • PARTOPEN
  • REQUEST
  • RESPOND
  • TIME_WAIT
• sctp transmission layer protocol
  • CLOSED
  • COOKIE_ECHOED
  • COOKIE_WAIT
  • ESTABLISHED
  • NONE
  • SHUTDOWN_ACK_SENT
  • SHUTDOWN_RECD
  • SHUTDOWN_SENT
• tcp transmission layer protocol
  • CLOSE
  • CLOSE_WAIT
  • ESTABLISHED
  • FIN_WAIT
  • LAST_ACK
  • NONE
  • SYN_RECV
  • SYN_SENT
  • SYN_SENT2
  • TIME_WAIT

Answer 2

The file ip_conntrack contains only ipv4 specific conntrack entries whereas nf_conntrack includes both ipv4 and ipv6 protocol conntrack entries.

nf_conntrack file is registered with proc file system using code in
net/netfilter/nf_conntrack_standalone.c
whereas ip_conntrack file is registered with proc file system through the code in
net/netfilter/nf_conntrack_l3proto_ipv4_compat.c