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