iptable_nat oops

From: Josh Green <hidden>
Date: 2005-03-02 22:26:18

I sent an email a few weeks back about a problem with iptables and NAT.
This problem appears to be related to what order I insert modules, so
its likely a memory location issue.  I've attached a couple of oops
output dumps.  I gave up on trying to get ksymoops to function
completely (no /proc/ksyms on my target and I read something about it
being deprecated??), still I hope these dumps are useful.  I'm not sure
yet whether its a mips specific problem, but I thought maybe I'd see if
anyone else has experienced this.

My target system is an AMD Alchemy db1100, I'm using mips-linux CVS from
a month ago or so (2.6.11 rc2), gcc 3.4.3 and uclibc.
In the problem case I get the following output when trying to modify the
'nat' table with iptables:

# iptables -t nat -F
iptables v1.3.0: can't initialize iptables table `nat': Memory
allocation problem
Perhaps iptables or your kernel needs to be upgraded.

strace output of iptables shows that there is an attempt to mmap over
1.6GB of memory.

old_mmap(NULL, 1651212288, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, 0, 0) = -1 ENOMEM (Cannot allocate memory)


Oops occur as soon as any IP traffic is attempted over the interfaces.
I've attached 2 variations, the first 'nat2_oops.txt' occurred after a
client machine attempted to get a DHCP lease, the second 'nat3_oops.txt'
is when attempting a ping from the target system.  In both cases it
seems ip_nat_rule_find() and ip_nat_fn() are common functions, so I
suspect the nat table hasn't been initialized correctly or something
else is trashing some memory.  Let me know if there is a more
appropriate place for this bug report.
	Josh Green

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help