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. and then pass these information to user space app. that app (socket app,I think ) 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 do not know how to make sure 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

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 2

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.