User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/537.75.14 Build Identifier: When issuing a change to the IPTables rules we receive a Kernel Oops if the server has been running for a while (>24hrs). Changes are usually blocking an IP , drop rule or similar. Reproducible: Always Steps to Reproduce: 1. Run IPTables for > 24hrs 2. Change IPTables rule and apply. Looking online the only other example we found was with Dell hardware as well. Perhaps specific to Dell r320 hardware? Actual Results: IPTables continues on but provides Oops message (non-tainted). Expected Results: System should continue running with no Oops
Created attachment 887987 [details] Kernel Oops Trace
kernel.x86_64 0:3.13.10-200.fc20
Does anyone have any ideas on this one?
Maybe this Fedora 18 crash is related? https://retrace.fedoraproject.org/faf/reports/175630/ This issue might be caused by overflowing counters, or perhaps a race condition. It would be nice if this could receive some attention, as we have a router in a redundant configuration, which triggers this problem occasionally. We are now resetting the counters every 24 hours, as a potential workaround, and will report how that goes.
After much testing from our NOC,running this to Zero the counters before IP tables restart. /usr/sbin/iptables -L -Z -v -n and restarting iptables stops kernel panic. OR Alternatively you can add it to the daily CRON. @daily /usr/sbin/iptables -L -Z -v -n
This is not a iptables user land issue. Reassigning to kernel.
looks like this may well be fixed by commit c58dd2dd443c26d856a168db108a0cd11c285bf3. It should apply cleanly to F20. Can you build and test a kernel with that commit applied and see if it fixes your problem? Thanks!
Will give it a shot and report back when tested.
thanks.
ping, any results here?
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
I can confirm this was resolved by commit c58dd2dd443c26d856a168db108a0cd11c285bf3