I am trying to capture the data packets from dpdk interface.
Using pdump+testpmd, able to capture the data packets.
However, if Wireshark is used with testpmd, the above fails.
Any suggestions highly appreciated. Thanks
Working on Ubuntu v 18+, DPDK v 19+ Wireshark v 3+
The solution is to use the pdump application. As others mentioned, once your DPDK application takes ownership of the network card, the kernel will not see the packets, and tcpdump hooks will not be triggered.
The documentation explains how to i) compile dpdk with support for pdump and pcap ii) enable your primary process - your application - to give packet information to a secondary process - the pdump sample application.
You can then use the generated pcap with wireshark.
As soon as you bind the physical interface from kernel to a DPDK driver (igb_uio, uio_pci_generic, vfio-pci) it becomes removed from kernel netdev for both Physical Function and Virtual Function. These NIC ports are accessible via UIO driver, and application like DPDK which has the PMD can probe and init the devices (with some exceptions).
If you want to use the port with Wireshark, unfortunately you have to bind it back to the kernel. You can also just capture packets to a .pcap file using DPDK and analyse it with Wireshark offline - if that fits your needs.
[EDIT-1] There are 2 ways to capture packets on UIO DPDK bind
make use of rte_pdump_init API in the primary (desired) DPDK application and use DPDK example dpdk-pdump to capture packets for RX or TX for desired queues.
Unbind the device from UIO and bind it back to kernel driver for netdev interface. start the DPDK rte_eal_init with special argument --vdev=net_pcap0,iface=[kernel nic interface instance]
Note: In option 2, one can run Wireshark and capture the packets too. But will lose out on performance and DPDK specific functionality.
Related
i'm trying to do the following:
a) Set Contiki in Promiscuous Mode.
b) Then retrieve all UDP and RPL packets send, not only to current node but also between two other nodes within communication range.
I have the following code:
NETSTACK_RADIO.set_value(RADIO_PARAM_RX_MODE, 0);
simple_udp_register(&unicast_connection, 3001,
NULL, 3000, receiver);
where receiver is an appropriate callback function. I am able to collect UDP packets send to the current node, but still unable to receive packets send between other nodes in my communication range.
Setting the RADIO_PARAM_RX_MODE only controls which packets the radio driver filters out. There are multiple layers in an OS network stack, of which the radio driver is only the first one. The next ones are RDC and MAC, which still filter out packets addressed to other nodes, and there is no API to disable that.
The solution is to either modify the MAC to disable dropping of packets not addressed to the local mode or write your own simple MAC. The latter is what the Sensniff (Contiki packet sniffer) does - see its README and source code. By the way, if you just want to log all received packets, just use Sensniff!
I'm trying to write a simple C code with WinPcap to broadcast a beacon packet and capture it in all nearby WiFi units. The code I'm using is very similar to the ones available at WinPcap[1].
The code runs fine if I create an ad-hoc network connection and join all the computers into it. However, this process of creating and joining to an ad-hoc network is cumbersome. It would be much better if, regardless of what network each computer is in, the beacon packets would be broadcasted and captured once the code is running.
As simple as this problem might sound, after some searching it seems that this is not possible to be done on windows (unless re-writing drivers or maybe the kernel):
Raw WiFi Packets with WinPcap[2]
Sending packets without network connection[3]
Does winpcap/libpcap allow me to send raw wireless packets?[4]
Basically, it would be necessary to use the WiFi in monitor mode, which is not supported in Windows[5]. Therefore, if the computers are not in the same network connection, the packets will be discarded.
1st Issue
I'm still intriguing, beacon and probe request packets are a normal traffic across the network. How they could be being sent and received constantly but the user is not allowed to write a program to do so? How to reconcile that?
2nd Issue
Does anyone has experience with Managed Wifi API[6]? I've heard that it might help.
3rd Issue
Acrylic WiFi[7] claims to have developed a NDIS driver which support monitor mode under Windows. Does anyone has experience with this software? Is it possible to integrate with C codes?
4th Issue
Is it possible to code such Wifi beacon on Linux? and on Android?
www.winpcap.org/docs/docs_412/html/main.html
stackoverflow.com/questions/34454592/raw-wifi-packets-with-winpcap/34461313?noredirect=1#comment56674673_34461313
stackoverflow.com/questions/25631060/sending-packets-without-network-connection-wireless-adapter
stackoverflow.com/questions/7946497/does-winpcap-libpcap-allow-me-to-send-raw-wireless-packets
en.wikipedia.org/wiki/Monitor_mode#Operating_system_support
managedwifi.codeplex.com/
www.acrylicwifi.com/
Couple questions I will try to answer. Mgmt and Ctrl packets are used for running a wifi network and don't contain data, I would not call these normal packets. Windows used to(I think still does) convert data packets into ethernet frames and pass it up the stack. Beacon and Probe Req pkts are not necessary for TCP/IP stack to work, ie. web browsers don't need beacon frames to get your web page. Most OS's need minimal info from mgmt/ctrl pkts to help a user interact with a wifi adapter, most mgmt/ctrl pkts only are useful to the driver(and low level os components) to figure how to interact with the network. This way the wifi adapters look and act like ethernet adapters to high level os components.
Never had any experience with Managed Wifi API or Acrylic, so can't give you any feedback.
Most analyzers that capture and send packets do it in 2-3 separate modes mainly because of hardware. Wifi adapters can be in listen mode(promiscuous mode and/or monitor mode) or adapter mode. To capture network traffic you need to listen and not send, ie. if someone sends a pkt while you are sending you miss that traffic. In order to capture(or send) traffic you will need a custom NDIS driver in windows, on linux many of them already do. Checkout wireshark or tshark, they use winpcap to capture pkts in windows and there are some adapters they recommend to use to capture pkts.
Yes it is possible to send a beacon on linux, ie. Aireplay. I know its possible to capture traffic on Android but you it needs to have rooted or custom firmware, which I would believe also means you can send custom pkts. If you are simply trying to send a pkt it might be easier to capture some traffic in tshark or wireshark and use something like aireplay to resend that traffic. You could also edit the packet with a hex editor to tune it to what you need.
I am new to DPDK, I'm trying to write my own app, which would capture packets at wire rate. Can I use the default kernel space libpcap long with dpdk ring and lcore. Or can I use the librte_pmd_pcap which is part of dpdk package.
Librte_pmd_pcap internally uses kernel space libpcap.
And I don't know how to use librte_pmd_pcap in my own dpdk app.
Can someone help me in using the librte_pmd_pcap in our own dpdk app to capture tcp packets.
*I have tested the testpmd app that comes with the dpdk package, testpmd is working fine. I need your help in writing my own dpdk app. Thanks in advance.
I was able to include the rte_eth_pcap.c to the application code and access the api. And this allowed me to use the -vdev EAL option to my app.
If by "the librte_pmd_pcap" you're referring to this source file, it uses libpcap, which is a user-mode library; it's not part of the kernel. It uses kernel-mode mechanisms on the operating systems (plural) that it supports; it uses BPF on *BSD, OS X, and Solaris 11; it uses PF_PACKET sockets on Linux (unless you're on an ancient Linux, in which case it uses SOCK_PACKET sockets); etc..
You can use libpcap directly, which will use the same kernel mechanism that any other code using libpcap does, including the code I linked to.
I want to parse packets captured by wireshark offline using libpcap. I am capturing packets from a wireless network in monitor mode. I have read that "libpcap" can be used to capture and parse packets captured in the ethernet. Can it be used for wireless networks too? If yes, can anyone suggest me some tutorial? and if No, which library is suitable for it and how to use it?
libpcap, and its Windows port, WinPcap can be used to capture network traffic (in fact, they're what Wireshark uses to capture network traffic), as well as to read a capture file in pcap format (the default format for Wireshark's existing releases) and, in libpcap 1.1 and later, to read some capture files in pcap-ng format (the default format for the current development version of Wireshark; it should write out files that libpcap 1.1 and later can read).
They can handle a number of network types, including Ethernet and Wi-Fi.
They do not, however, support parsing any packet types; that's the job of the code that uses them, whether it's tcpdump/WinDump, Wireshark, or some other application. There's a library called WiFiPcap that is:
A C++ wrapper around libpcap that parses 802.11 frames, and the most common layer 3 (IPv4, IPv6, ARP) and layer 4 protocols (TCP, UDP, ICMP) contained within them. Also works without link-layer headers. Works in Linux and Windows.
(copied from its web page, but edited to fix the protocol layer numbers to match the OSI model).
I have not looked at it, but it might do what you want.
There might also be other libraries that could be used to parse the packets.
To explain what I would like to get, here's an example.
Let's say, we have a PC with one NIC. It has single IP address 172.16.0.1.
Using VLC, we start a udp stream to 172.16.0.1:1234, then launch another copy of VLC and connect to udp://#172.16.0.1:1234. Now we'll see our video streaming.
If you run sniffer, you will see packets from 172.16.0.1:some_random_port to 172.16.0.1:1234 on loopback. There's no trafic on our NIC.
What I want to do is to stream and receive udp in the same computer, like VLC does it. But the main problem is that pcap can only pcap_open() a real device, it can't work with loopback.
Is it possible to solve that problem?
P.S. I'm using Windows and WinPcap, unlike Linux version, it can send packets.
If you just want to send and receive UDP packets, I would suggest just using regular Winsock sockets, just as you'd use regular sockets on UN*X; using WinPcap requires that you re-implement IP and UDP, and won't let you send to another socket on the same machine under Windows (or on at least some versions of UN*X, either).
If you want to watch the traffic you're sending, unfortunately WinPcap won't help, as it relies on packets being sent out and received from NDIS (its driver plugs into NDIS), and that doesn't happen for packets sent from one socket on a machine to another socket on the same machine.
(Note, BTW, that libpcap can send packets on Linux and *BSD and Mac OS X and Solaris and Digital/Tru64 UNIX, for example, and has been able to do so for several years; older versions of libpcap didn't support it, but the versions available for the past few years can. However, as per my first paragraph, it would not make sense to use libpcap to send and receive regular UDP packets on those OSes, just as it makes no sense to use WinPcap for that purpose on Windows.)