Bug?
Alexander Demenshin
aldem@aldem.net
Mon, 20 Mar 2000 06:10:18 +0100
Hello,
So... linux-2.3.99-pre2 (as from ftp.kernel.org; not pre2-5),
netfilter-1.0.0alpha (iptables). Netfilter built as modules,
all modules were inserted.
Rules:
iptables -A OUTPUT -t mangle -s 127.1.0.0/24 -j MARK --set 0x1777
iptables -A INPUT -s 127.1.0.0/24 -j QUEUE
(there were other rules but I think they are irrelevant).
Next... One vc:
ping 127.1.1.1
Other vc:
ipq_client
Everything was fine. Then client was interrupted for some time,
restarted again, then again interrupted... but ping was active
all the time.
Next attepmt to run ipq_client (after few minutes) -> kernel panic.
There were some messages in log, like:
Mar 20 05:42:12 nest kernel: ip_queue: error notifying peer 1887, resetting state and flushing queue
Mar 20 05:43:02 nest kernel: ip_queue: error notifying peer 2013, resetting state and flushing queue
Mar 20 05:46:52 nest kernel: ip_queue: error notifying peer 2034, resetting state and flushing queue
Mar 20 05:48:48 nest kernel: ip_queue: error notifying peer 2035, resetting state and flushing queue
That's all. Sorry, no exact OOPS data - no record in logs, only on
console... It was really hard lockup...
Discovery: when rule with QUEUE target is active, packets are queued
(client accepts several of them after starting), but... Is it correct
behavior? If there is no client - should we queue them?
/Al