A library called libipq is provided for userspace packet handling. There is now documentation for this in the form of man pages. You need to build and install the iptables development components:
make install-devel
then see libipq(3).
You may also be interested in the Perl bindings for libipq, Perlipq at: http://www.intercode.com.au/jmorris/perlipq/. The binding itself is an example of using the library.
Other code examples include:
This means that the kernel-side Netlink socket buffer ran out of space; the userspace application is not able to handle the amount of data being delivered from the kernel.
Is it possible to make those kernel buffers bigger so that I don't run into this problem?
Yes, these are standard Netlink sockets, and you can tune their receive buffer sizes via /proc/sys/net/core, sysctl, or use the SO_RCVBUF socket option on the file descriptor.
You can also try ensuring that your application is reading any received data as quickly as possible. If you don't need the entire packet, try copying less data to userspace (see ipq_set_mode(3)).
The netfilter core-team keeps a TODO list where it lists all the desired changes / new features. You can retrieve this list via anonymous CVS, instructions are on the netfilter Homepage. Alternatively you can also go to http://cvs.netfilter.org/cgi-bin/cvsweb/netfilter/TODO/ using CVSweb.
If you want to publish it, please send it to the netfilter-devel mailinglist. Subscription instructions are at http://lists.netfilter.org/mailman/listinfo/netfilter-devel/.
The correct way of sending a patch is the following :
If you wrote a new extension, or added some new options to an old extension, it's usually a good idea to also update the netfilter-extension-HOWTO to include that new extension/functionality description. Additionally, it will draw more users to your extension, and will allow you to get more feedback in general.
The answer unfortunately is: No.
Now you might think 'but what about libiptc?'. As has been pointed out numerous times on the mailinglist(s), libiptc was _NEVER_ meant to be used as a public interface. We don't guarantee a stable interface, and it is planned to remove it in the next incarnation of linux packet filtering. libiptc is way too low-layer to be used reasonably anyway.
We are well aware that there is a fundamental lack for such an API, and we are working on improving that situation. Until then, it is recommended to either use system() or open a pipe into stdin of iptables-restore. The latter will give you a way better performance.