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.
Related
I have few devices connected to wifi router, but pcap_dispatch() always returns 0 for wifi interface while live capturing on Mac OS X. The same code captures response in case of wired interface. Please clarify if I have missed any flag here.
If you are capturing in monitor mode, you will be getting native 802.11 packets, which do not look like Ethernet packets, so filtering similarly to Ethernet will not work.
Furthermore, if you're capturing in monitor mode on a protected network, i.e. a network using WEP or WPA/WPA2, everything past the 802.11 header will be encrypted, and you will not be able to filter on it.
So:
if you're on an unprotected network, try a filter such as
wlan dst 70:73:cb:c1:7c:61 and (arp or (vlan and arp))
if you're on a protected network, try a filter such as wlan dst 70:73:cb:c1:7c:61, and make sure the program that reads the packets either just blindly writes them out to a capture file or is capable of decrypting WEP or WPA/WPA2 packets (the only program I know of that can decrypt them is Wireshark, although some others might be able to do it as well).
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'm trying to connect to the VMWare's pipe; what is in fact simulated serial port where I've redirected debug output from the virtual OS. I used this article to redirect debug output from the virtual OS to the named pipe on my client OS through the VMWare. It works perfectly when I use the WinDbg as decribed in that article but I want to create my own application to catch this debug output - only to catch, nothing else. When I'm only listening from the pipe (that simulated serial port) I'm getting meaningless data.
Is it enough to only read from the remote debugger (redirected to a certain debugport) or should I use some protocol for it (to acknowledge reading or something) ? In other words; may I only listen to the pipe (serial port) without any response to it ?
Thanks for any suggestions
Regards
The data coming out is not meaningless but it has to be parsed based on the particular protocol used. If you are not sending commands but just reading output information it should be enough to just listen (though I do not know off hand if the protocol requires acknowledgement of messages).
However, what you receive will have to be parsed based on the messages you are getting. I've never tried to parse the debug information on my own but this page should give you some information on the protocol.
How can i filter (allow, deny etc) outgoing packets in Windows? I want to search in TCP or UDP packet types to find in the data segment for example this "387602304fd236e048125453b1fa10c980e9dad4fa7f3f5dd2497c2e8b2b" and drop/block/deny the packet, if it matches the search hex string.
I have already tried WIPFW and PKTFILTER but they only serve IP source, dest, port etc filtering. They don't inspect the packet's data.
I think Berkeley Packet Filter doe's that job, but it's for unix...
Here is some to filter packet in windows:
WinDivert Free open source project work on Windows 7, 2008 or upper. network layer.
WinpkFilter 3.0 Commercial, Windows XP and upper. datalink layer
pcausa, Commercial. datalink layer
Windows Filtering Platform Packet Modification Sample
A sample to create callout driver that WinDivert use, you should now to implement kernel driver. network layer.
you can use SmartSniff in windows.
Starting from version 1.10, you can filter unwanted TCP/IP activity during the capture process (Capture Filter), or when displaying the captured TCP/IP data (Display Filter)
You want application level filtering then, (just changing the payload). If you want to be able to drop, I know you can hook into Winsock, which will allow you to capture packets as they go out and set up a filter there. Windows seven also added to their firewall, so you could use that API to grab outbound packets; I'm not sure if it will allow you to specifically alter the payload data, though.
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.