Is it possible to have libpcap remove a packet instead of just sniff it as it passes through? I'm wanting to intercept each packet and encapsulate it into a new packet along with measurement data, but both packets (mine and the original) both reach the destination.
It's not possible. You need to write a driver (for your operating system) to make the networking stack filter out packets.
The only way you could do this is by being the only physical path between the sender and receiver and turning off packet forwarding on the interceptor.
If you're capturing wireless traffic, there's nothing you can do. No software library can remove radio waves from the ambient air.
No, libpcap cannot "remove a packet".
It's not quite clear what you want to achieve, but it looks like you want to receive data, add some additional information to it, and republish it. If you are working with a datagram protocol such as UDP, then you might be able to simply resend your augmented data to a different UDP port.
In response to Ben S, you can't remove packets off the air, but you can stop them reaching their destination - using ARP cache poisoning etc.
As others mentioned, you can not use libpcap. libpcap is a passive listener. If you are on Linux, you can use a netfilter, which hooks into iptables. Here is an example of how to do that.
http://www.linuxjournal.com/article/7184
Related
Assume that I implemented a kernel driver that parses RX packet and decides to pass it to the user space depending on EthType. What are the "official" ways to do that in the Linux kernel?
The only one that comes on my mind is the user application opens a socket to the kernel and listens on it, while the kernel pushes packets satisfying criteria (eg. specific EthType) in to the socket's buffer. I'm certainly not accurate about this, but I hope you get my point :)
Are there any other ways to do this?
Thanks.
You can achieve your goal by using Netfilter framework. Netfilter framework helps intercept a ingrees/egrees packet. The points where packets can be intercepted inside the Kernel/Network stack are called as HOOKS in Netfilter.We can write a kernel module, which can get hooked at any of these HOOKS. The kernel module must have a function defined by us, which can parse the packet and its headers and than take a decision to whether drop a packet, send it to kernel stack, queue it to user space etc.
The packet of our interest can be intercepted at IP_PREROUTING hook and queued by returning NF_QUEUE from our function. The packets will be queued and can be accessed by any application.
Please go through Netfilter documentation.
Regards,
Roy
When the packet arrives on the NIC, these packets are first copied onto the kernel buffers and then copied onto the user space, which are accessed through the socket() followed by read()/write() calls in the user space. You may want to refer to Kernel Network Flow for more details.
Additionally, NIC can directly copy the packets into the DMA bypassing the CPU. Refer to: What happens after a packet is captured?
IS there a way I can in user-space get notification about a packet being dropped at Layer-2 in 802.11.
According to my understanding what happens is, when a packet is sent out on the medium, there are Layer-2 ACKs which are received if it is delivered correctly (if not,it does the retransmission and ultimately drops the packet if not delivered after several retries..)
I want to be able to access this notification (in user-space)and change the behavior of packet transmission.
I want to be able to send the packet to another host from the FIB rather than dropping the packet.
I have read about libpcap libraries and netfilter hooks which allows me to capture packet and inject them back on the networking stack..
But I'm not able to find hooks (if any, for the wireless stack) to help me capture the packet notification in Layer-2.
Please correct me if I'm not understanding something correctly. Also, any heads-up or links to read would be great.
No, you cannot, at least not using the standardised sockets interfaces. 802.11 is a link layer, and the sockets API is strictly link-layer agnostic: unless it's going to work on all link layers, it's not in sockets. There are good reasons for that: the kind of cross-layer interaction that you envision has been tried many times, and it's always turned out more trouble than it's worth.
You didn't give us any details about the application — but the best solution is most probably to change your application-layer protocol to send explicit acknowledgments, and send your data over the fallback route when you fail to receive an ACK.
I'm writing a PMTUD app for both IPv4 and v6. I am doing this on Ubuntu 12.04, but I would like to make it as OS-independent as possible, and that's where I stumbled upon a problem.
IPv6 packets get fragmented by the sender by default, and I do not know how to turn this behaviour off. I found some socket options like IPV6_MTU_DISCOVER and IPV6_DONTFRAG, but I found these under linux/in6.h, which does not help as I'm using the netinet header family and neither of those is under netinet/in.h - although IPV6_MTU_DISCOVER should be there according to this. Am I missing something?
EDIT: Let me clarify a bit then.
I have a socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6) through which I wish to send an ICMPv6 packet of such size that I will receive a reply telling me it's too big, and from that reply I will get the path MTU.
However, to truly get the MTU along the whole path I also have to factor in the outgoing device's MTU.
I am using miredo to tunnel IPv6, which has a set MTU of minimal size, e.g. 1280. Sending a packet bigger that 1280 will result in fragmentation of said packet (this behaviour I observed in Wireshark), but I need the socket to REFUSE to send the packet and inform me about it rather than fragment it.
You do not need to do this yourself. MTU discovery is supposed to happen automatically. As a side effect of this, all devices along the path MUST allow ICMP V6 packets to pass.
IPv6 packets get fragmented by the sender by default
No. TCP packets get fragmented by the sender and intermediate routers by default.
, and I do not know how to turn this behaviour off.
You cannot turn it off. You can certainly try, but the only result will be non-delivery. If a router needs to fragment a packet and you don't permit it, it will drop it instead. However the sending host also needs to fragment, to fit inside the path MTU, and you cannot stop that. If you write the receiver correctly, i.e. in the expectation that it is reading a byte stream rather than discrete messages, it should make no difference to you whether the packets got fragmented in transit or not.
Is there a library out there that will allow me to perform link-layer packet modification for both incoming and outgoing packets?
Basically I want to do some transformations to a packet (for eg. changing IP payload) based on incoming MAC address, IP address, port, etc.
I also want to be able to do the same thing for outgoing packets, i.e., modify packets before they leave the system.
I'm not sure if IPTables can do the kind of packet payload modification that I want to do.
The article linked in the 1st answer allows modification only at network layer, not at link layer.
Solution: WinpkFilter
Windows or linux? for linux there's iptables which has extensive code. As for Windows, here's an article that might help you.
Hope this helps.
I wanted to access the original value from the ethernet, actully by some hardware programming i am sending a value to system via ethernet ,but it's not possible to access what exactly i'm going to send
You could use a packet sniffer like Wireshark, running on either source or destination system. This will let you examine packets as they leave or enter, respectively.
It sounds like what you need is a protocol analyzer. On Windows, look at Microsoft's Network Monitor.