i have rule set up to drop udp/tcp packets with matching strings. however, my program which captures packet using libpcap, is still able to see this packet.
Why is this/, what should be the iptable rules to drop packets before it is seen by libpcap?
Is there anyway,perhaps other than iptables rules, to drop this packet before it is seen by libpcap/tcpdump?
Yes, libpcap sees all the packets..
They are being captured before being processed by the netfilter.
Did you try to change the priority of the netfilter hook you use? if you try hooking with the highest priority for incoming packets, it will get the packet before the packet socket kernel code, which is the way libpcap uses to capture packets.
* I assume you are using linux *
EDIT:
Libpcap uses different ways to capture packets - according to the OS. on linux it uses packet socket which is implemented in kernel code using the netfilter framework.
Theres no way for libpcap to see the packets before netfilter, netfilter is a kernel module, and processes all packets before they hit user mode, it can even see the packets before the kernel sees it.
Could you explain further explain ?
Its possible that libpcap is also setting hooks on netfilter that overwrite the one in iptables. The real issue is that looking and what hooks are set on netfilter is far from trivial, and can only be done in kernel mode. Investigate how libpcap gets the packets.
Related
A registered netfilter hook can get the packet from the linux kernel. Here linux kernel gets the packet, looks for registered hooks, and passes the packet to them.
The general flow would be:
1. NIC receives the frame
2. Places it in DMA rx ring
3. Kernel's networking subsystem takes it from the DMA rx ring.
But is there a way to get the packet before it enters into linux networking subsystem (may be a big term, my intention is kernel networking code that takes the packet first). That is, my driver should get the packets before it goes into the linux networking stack.
I am a learner and trying to write a piece of code that does the packet processing in the kernel.
Please correct my understanding if wrong and help me with good pointers to read.
Just modify the network NIC card driver? It is the one who got the ISR first. You should be able to filter it there.
I am using a filter string to catch only the probe-request frames from my wifi router working in monitor/Promisc mode.
the same string i.e. "type mgt subtype probe-req" is working when i am running my code on a laptop but on my linksys WRT54g its giving error that
cannot pcap_compile() function is not working.
To be more explanatory, I am using OpenWRT White Russian 0.9 firmware on my router and its equivalent SDK to build package for it. The program uses Libpcap library to capture raw packets from the network.
So I want to know that is there any change in the string format while working on embedded devices like a router. If yes can you suggest me where I can find the documentation for it.
If no that what's wrong I am doing.
The filter strings that are allowed depend on:
the version of libpcap/WinPcap in use;
the link-layer header type being captured on the device.
That particular filter would be allowed if libpcap 1.0 or later is being used and if the adapter is supplying packets with 802.11 headers. Note that, on most OSes, an 802.11 adapter will supply packets with 802.11 headers only if the adapter is running in monitor mode; otherwise, it'll supply packets with Ethernet headers, and will only supply data frames, not management or control frames.
The program uses Libpcap library to capture raw packets from the network.
Whatever the program is, it should be doing a better job of reporting errors from pcap_compile(). It should include, in the error message, the text returned by pcap_geterr() when pcap_geterr() is handed the pcap_t * that you passed to pcap_compile(); that way, you will know more information about why the error occurred, and therefore will know more information about what you need to do to fix it.
I'm writing an IPsec implementation for a microcontroller and I want to test it using a standard Linux box running Debian Lenny. Both devices should secure the communication between them using IPsec ESP in tunnel mode. The keys are setup manually using setkey. There's no (or at least should be no) user space program involved in processing an IPsec packet. Now I want to see how my created packets are processed by the Linux kernel. To see the raw packets I capture them using tcpdump and analyze them using wireshark.
What's the best way to obtain debug information about IPsec processing?
How can I figure out whether the packet is accepted by the kernel?
How can I view the reason for a packet to be dropped?
You can instrument the XFRM (or perhaps ipv4/esp.c) kernel code to print out debug messages at the right spots.
For example, in net/ipv4/esp.c there exists a function esp_input() which has some error cases, but you'll see most the interesting stuff is in the xfrm/*.c code.
That said, I didn't have a problem interoperating a custom IPSec with Linux. Following the 43xx specs and verifying the packets came out correctly via wireshark seemed to do well. If you're having issues and don't want to instrument the kernel then you can setup iptables rules and count the number of (various type of) packets at each point.
Finally, be sure you've actually added a security policy (SP) as well as a security association (SA) and setup firewall rules properly.
I am looking for UDP debugger tool, for the following requirement
1) netstat -s, shows udpInOverflows=23000 and this counter is increasing continuously.
how can I check udp packets which are thrown because of no buffer space.
2) what are the possible reason for this problem to occur and how to solve it.
3) is there any way to check incoming UDP packet which are received by kernel after all verification like udp socket is open for that port and no check sum error, snoop will not work because it capture direct from network interface.
Regards
Nitin
If you are willing to spend a little time with kernel source you should be able to use dtrace to get at the information you want. For example "dtrace -n 'fbt::udp_input:entry{stack();}' will show you how packets are getting into udp_input (not all that interesting). You should also check the mib::: probes and fbt:ip:ip_drop*:. This is all dependent on the version of Solaris you are using of course.
I want to capture packets whoes has a special target ip, then forward these packets by UDP. Does Ruby can do this ? thanks
Packet, you mean? If you want see packets in userspace, not kernel-level then you can use several ways.
libpcap: libpcap is packet capture library used in tcpdump/wireshark
libipq: iptables packet queueing library. http://rubyipq.rubyforge.org/
for libipq, there is also ruby binding but it doesn't seems to be in activated.
Actually libipq is deprecated by libnetfilter_queue
You can make ruby binding of libnetfilter_queue.