linux netfilter pass the packet content to user space socket app

Question

I want to write a Linux 2.6 netfilter module, which can check the incoming IP packet information, such as dest-ip, source-ip. After that pass these information to user space app which (i.e Socket app) will handle these information as soon as the packet reach the HOOKs.

I want to try two ways:

1 . Inside the netfilter module, make a fifo struct line, every time the packet reach the hook, put the packet information to the fifo. and with the help of /proc/example filesystem . every time the user space app read the /proc/example file , will get a packet information from the fifo head .

I'm a newbie of kernel program, this program crash my kernel several times. -_-! I wonder is this way possible?

2 . Inside the netfilter module, make a char device, the user space app read packet information from this char device. But I still don't know how to make sure to get the packet as soon as possible, is there any way when the packet reach the netfilter hook, kernel will send some signal to info user space app, then the user space app come to pick the packet information?

Thank you very much.

Answer 1

My way of doing this: Create a kernel module to get hooked to your network activity. Then use Netlink which can talk to user space from the kernel to pass the data IPC.

Answer 2

Option 1 is possible and workable what is the problem? But I usually use to communicate between user-space and kernel space using netlink

netlink_kernel_create

netlink_kernel_release

nl_sk = netlink_kernel_create(&init_net, 17, 0, recv_cmd, NULL, THIS_MODULE);

netlink_kernel_release(nl_sk);

netlink_unicast

Answer 3

I'm not sure about the first method, but using the second, your user space app could use a select() call with the char device as the only target - as soon as select() returns, you'll have data to read. Just make sure to read it all, and not just assume one packet's worth of data.

Answer 4

What do you mean by as soon as possible? Do you have some actual hard/soft realtime requirements?

If you select option 2 you should be able to get new data rather quickly by opening the character device non-blocking and select()ing on the read fd. I've done something similar with a kernel level socket, where socket data was presented to a user level process via a character driver. I saw very little latency as long as I serviced the socket in a timely manner. The driver was used in an environment that had some soft realtime requirements and we didn't have any problem meeting those requirements with run-of-the-mill kernel facilities.

Have a look at Linux Device Drivers, 3rd Edition.