Hi List,
I am getting a problem in connection tracking. I have posted a query on netfilter list
also. I am putting the conversation i had it over there. If anybody in the list have
any clues, Plz. Help.
Well the problem is like this :-
I have set up some stateful rules using iptables on Embedix Platform and i can't use
/proc file system over there. So what happens, if i try to ping somebody, i gets the
message :-
ip_conntrack: maximum limit of 1016 entries exceeded.
Further information about the setup, you can see from the following conversation.
Thanks & Regards,
Amit Kumar Gupta.
-----Original Message-----
From: Amit Kumar Gupta
Sent: Fri 1/10/2003 1:58 PM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: Reg iptables Connection tracking
Hi,
One thing which i have noticed during testing is that i have /proc folder and We have
disabled only CONFIG_SYSCTL. It means that /proc file system is there and i gets some
entries also in /proc/net/ip_conntrack file.
Another thing is :-
init_conntrack(const struct ip_conntrack_tuple *tuple,
struct ip_conntrack_protocol *protocol,
struct sk_buff *skb)
{
struct ip_conntrack *conntrack;
struct ip_conntrack_tuple repl_tuple;
size_t hash, repl_hash;
struct ip_conntrack_expect *expected;
int i;
static unsigned int drop_next = 0;
hash = hash_conntrack(tuple);
if (ip_conntrack_max &&
atomic_read(&ip_conntrack_count) >= ip_conntrack_max) {
/* Try dropping from random chain, or else from the
chain about to put into (in case they're trying to
bomb one hash chain). */
if (drop_next >= ip_conntrack_htable_size)
drop_next = 0;
if (!early_drop(&ip_conntrack_hash[drop_next++])
&& !early_drop(&ip_conntrack_hash[hash])) {
if (net_ratelimit())
printk(KERN_WARNING
"ip_conntrack: table full, dropping"
" packet.\n");
return ERR_PTR(-ENOMEM);
}
}
If u will see through this function, ip_conntrack_max will be 1016 and
ip_conntrack_count will be initially lesser than ip_conntrack_max. So it should not go
into this loop each time.
Any suggestions.
Regards,
Amit
-----Original Message-----
From: Joel Newkirk [mailto:[EMAIL PROTECTED]]
Sent: Fri 1/10/2003 12:54 PM
To: Amit Kumar Gupta
Cc:
Subject: Re: Reg iptables Connection tracking
On Friday 10 January 2003 12:37 am, you wrote:
> Hi,
>
> Well, Only 2 machines are attached in the inhome network and the
> fireall I am using is written using iptables rule. Well, the
> interesting point is :- There is no
> /proc/sys/net/ipv4/ip_conntrack_max file . What I mean is the max
> length it takes from this file and this file doesn't exist as I am not
> using /proc file system. (This mean that in the kernel CONFIG_SYSCTL
> option is not set).
>
> Well I am able to see upto this point. I went through the code flow
> also. But I don't know why it prints the message(Even if increasing
> the value from 1016 to 4096 by hardcoding it in the kernel). Another
> issue is I don't know how it is taking 1016. As There is no /proc file
> system, and by default it shoud take 0.
Hmmm. I suspect it is taking a 1024 default then, the actual number of
entries usually seems to be (2^n)-8. The following probably explains
/where/ the value is coming from:
int __init ip_conntrack_init(void)
{
unsigned int i;
int ret;
/* Idea from tcp.c: use 1/16384 of memory. On i386: 32MB
* machine has 256 buckets. >= 1GB machines have 8192 buckets. */
if (hashsize) {
ip_conntrack_htable_size = hashsize;
} else {
ip_conntrack_htable_size
= (((num_physpages << PAGE_SHIFT) / 16384)
/ sizeof(struct list_head));
Not that this helps much. The real problem is WHAT is the conntrack
table filling with. And I suspect it may be nothing, that you have a
problem because it is trying to use /proc/net/conntrack and there IS no
/proc/net/conntrack. The message may be triggering incorrectly,
presuming that since it cannot write another entry to
/proc/net/conntrack that the table is full.
The fact that you only have two machines pretty much eliminates traffic
as a source of legitimately filling it... :^)
I'm out of ideas for the moment, other than the above, that it will need
/proc in order to work. If I think of something else I'll email you
again. Sorry.
j
**************************Disclaimer************************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is
'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying
or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.
***************************************************************************************
