Reputation:
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.
Upvotes: 2
Views: 3785
Reputation: 1089
Option 1 is possible and workable what is the problem? But I usually use to communicate between user-space
and kernel space
using netlink
nl_sk = netlink_kernel_create(&init_net, 17, 0, recv_cmd, NULL, THIS_MODULE);
netlink_kernel_release(nl_sk);
netlink_unicast
Upvotes: 2
Reputation: 738
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.
Upvotes: 3
Reputation: 4985
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.
Upvotes: 1
Reputation: 16581
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.
Upvotes: 1