ip_queue problem (and ip_conntrack DoS)

[Alexander Demenshin]

On Mon, Jul 10, 2000 at 01:50:22PM +1000, James Morris wrote:

> It seems to work ok here.  Do you still get a lockup if ip_conntrack is
> not loaded (and do you have nat loaded?).

  Yes, unfortunately. More detailed results of investigation...
  
  It lockups when no rules are active and no ip_conntrack/ip_nat loaded, when the following
  is in effect:
  
  	$ iptables -t mangle -A PREROUTING -d 127.1.1.1 -j QUEUE
  	
  	but not if:
  	
  	$ iptables -t mangle -A OUTPUT -d 127.1.1.1 -j QUEUE
  	
  	(at least I cannot reproduce it in this case)
  	
  	It also hangs when the following is in effect:
  	
  	$ iptables -A INPUT -d 127.1.1.1 -j QUEUE
  	
  	(all rules shown above are _only_ rules with QUEUE target)
  	
  Tools used - my demo program as user space handler; ping -f with various packets sizes
  and mentioned early "apache bench".
  
  Sometimes it hangs when I try "ping -f", but it seems that there is no correlation to
  packets size of packet fragmentation; though I can reproduce it more often if MTU for
  "lo" interface is set to 576 and I use packet size 4000.
  
  With "apache bench" results are more stable - it hangs all the time (with ping - sometimes).
  
  I also cannot reproduce the problem when I only DROP packets from userspace (in this case I also
  do not receive any errors during read).
  
  When no QUEUE targets are active, I cannot reproduce problem at all.
  
  I found that SysRq _does_ work, and EIP shows value in section "stext_lock" (arch/i386/boot/head.S),
  where various locking macros place the code.
  
  Unfortunately, there are no kernel messages, regardless of log level on console...

  Again, it is necessary to produce extremely high packet rate to reproduce this problem,
  usually in case of "ping -f" it can take more than 500000 packets till lockup.
  
  I tried to increase queue length to 16384 - no effect, I still sometimes get messages
  "No buffer space" (however far less), and peruodic observation of /proc/net/ip_queue shows
  that queue size (actual) is low enough during the test (below 200).
  
  It is hard to reproduce the problem when I am in COPY_META mode, or when I use lower
  copy_range (below 1024), but in case when I use copy_range > 8192 I get _a lot_
  of "No buffer space" errors _regardless_ of actual packet size, and lockup happens
  early (at least I have this impression).
  
  And finally a little bit more about my system:
  
  	- kernel 2.4.0-test2-ac2 (built with SMP support; with no ac- or other patches)
  	- ip_conntrack built as module (inactive)
  	- ip_nat also built as module (inactive)
  	- ip_queue built as module (active)
  	- _single_ CPU PII-350 with 256M RAM
  	
  During the test there were no other network activity nor other process activity (except
  for usually sleeping getty/inetd etc).
  
> error.  If it's something caused by a userspace coding error (e.g.
> invalid verdict), you'll get an error message back from the module and the
> packet will remain in the queue.

  Seems that my problem has nothing to do with this. BTW, there is no command
  to perform flush on queue from userspace; it will be flushed only when pid
  of requestor will be changed. Also, there is no indication that queue is full;
  nor number of packets dropped due to this (would be useful info).
  
  Additionally, there is no handling of multiple processes connected to netlink_firewall,
  though they all will get all the packets (the problem is that when some of them
  will send verdicts queue will be flushed due to different pids - probably).
  
  That's all. I cannot do more at this point, but seems that it is locking problem,
  and may be outside of ip_queue (probably somewhere in netlink code).
  
  Good luck and happy hunting :)
  
/Al