Re: Linux Socket Filter
On Thu, 21 Dec 2000, Nadav Har'El wrote: also, you wantthe original packets to keep on traveling to their destinatin, or be captured by your software only, and not rich their original destination directly? I want only my program to get these packets (otherwise the kernel will ruin the TCP session I'm trying to make by sending back RST packets). I was thinking of doing this using Linux's firewalling code. don't think - do. it's very easy for a filter as simple as you need. ipchains can redirect packets to go into user mode, using netlink sockets. with a very simple game, you can make the packets get copied into user-space, and yet not travel up the regular TCP stack (using the DROP target with ipchains). using libpcap, you can only read packets - not block the system from processing them. this method works nicely, but not together with masquerading. you'll need to move to kernel 2.4 to be able to mix both options, should you need that option. in any event, there's no need for any kernel code change to get this working - only kernel recompilation to support netlink sockets (and firewalling, ofcourse, but i guess you already have that enabled). -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Linux Socket Filter
I'm trying to program something (on Linux, of course) that will need to capture arbitrary packets coming to the machine (TCP segments, for example). One obvious solution is to use libpcap [1]. However, it apears that libpcap (even the latest version) uses a very inefficient method to capture packets that match some criterion (defined using a BPF program [2, 4]) - it moves all packets to user space, and does the matching there. However, it appears that Linux provides an in-kernel BFP-like feature called "Linux Socket Filter" [3], that is included in modern kernels (e.g., it is included in Redhat 7, but probably in earlier distributions too), which seems perfect for my needs. But searching around, it seems that nobody is actually using it... Does anybody know why? Also why didn't the libpcap people use LSF on Linux, instead of their inefficient user-space solution? Is there something wrong with LSF? I'd love to hear from anybody with any experience in LSF. [1] http://www.tcpdump.org [2] http://www.tcpdump.org/papers/bpf-usenix93.pdf [3] http://www.linuxhq.com/kernel/v2.2/doc/networking/filter.txt.html [4] http://www.neosoft.com/neosoft/man/bpf.4.html Thanks, Nadav. -- Nadav Har'El| Wednesday, Dec 20 2000, 23 Kislev 5761 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |Don't be irreplaceable. If you can't be http://nadav.harel.org.il |replaced, you can't be promoted. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Linux Socket Filter
Nadav Har'El wrote: However, it appears that Linux provides an in-kernel BFP-like feature called "Linux Socket Filter" [3], that is included in modern kernels (e.g., it is included in Redhat 7, but probably in earlier distributions too), which seems perfect for my needs. But searching around, it seems that nobody is actually using it... Does anybody know why? Also why didn't the libpcap people use LSF on Linux, instead of their inefficient user-space solution? Is there something wrong with LSF? I'd love to hear from anybody with any experience in LSF. Although I have never used LSF, I can assume the reasons may be the following: 1) Linux only non portable solution. 2) For most typical networking solutions I can think of you'd prefer to either use raw sockets and do the matching yourself (for a small enough amount of data) or write a kernel module that does all the processing you want done at all (for large amount of data) and LSF falls somewhere in the middle which means most people will go to either extreme. I don't know what is your application and therefor cannot recommend either path, but you might want to consider the previously mentioned options as a replacement along with LSF. Gilad. PS. One more options for the reason avoid LSF is that when spell check this reply using Netscape6 the spellchecker kept suggesting I should replace LSF with either NFS or LSD, both known to cause permanant brain damage to users... ;-)) -- Gilad Ben-Yossef [EMAIL PROTECTED] http://benyossef.com :: +972(54)756701 "Anything that can go wrong, will go wrong, while interrupts are disabled. " -- Murphey's law of kernel programing. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Linux Socket Filter
On Wed, 20 Dec 2000, Nadav Har'El wrote: I'm trying to program something (on Linux, of course) that will need to capture arbitrary packets coming to the machine (TCP segments, for example). One obvious solution is to use libpcap [1]. However, it apears that libpcap (even the latest version) uses a very inefficient method to capture packets that match some criterion (defined using a BPF program [2, 4]) - it moves all packets to user space, and does the matching there. question - what types of packets exactly do you need to capture? is this using a complex filter, or a simple one? also, you want the original packets to keep on traveling to their destinatin, or be captured by your software only, and not rich their original destination directly? -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Linux Socket Filter
On Thu, Dec 21, 2000, guy keren wrote about "Re: Linux Socket Filter": On Wed, 20 Dec 2000, Nadav Har'El wrote: question - what types of packets exactly do you need to capture? is this using a complex filter, or a simple one? I'm trying to do something along the lines of "faking" a TCP session on one port: i.e., sending out faked packets (that's the straightforward part) and then receiving all the TCP segments destined for my port and handling them myself (without the kernel touching these packets and doing its normal processing on them). So it should be a very simple filter, something like giving "dst port 1234" to pcap_compile() and letting it generate a BPF virtual-machine code for me. This is not going to be some sort of industrial-strength my-own-TCP-stack, so I don't really need _all_ the program to run in-kernel: just the filtering part which will hopefully pass to the user-level software only a small fraction of the total traffic on the machine. also, you want the original packets to keep on traveling to their destinatin, or be captured by your software only, and not rich their original destination directly? I want only my program to get these packets (otherwise the kernel will ruin the TCP session I'm trying to make by sending back RST packets). I was thinking of doing this using Linux's firewalling code. By the way, I already started experimenting with these ideas, using LSF and ipchains, and it seems it is beginning to work quite nicely. Unfortunately, I couldn't get Redhat's LSF-patched libpcap (it's the standard libpcap they put in their system) to work (I don't know why - I even checked a libpcap program somebody else wrote, and it doesn't work!), so I had to use LSF ioctls directly, which was actually not that terrible ;) -- Nadav Har'El|Thursday, Dec 21 2000, 24 Kislev 5761 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |A man is incomplete until he is married. http://nadav.harel.org.il |After that, he is finished. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
