My requirement is create to Ethernet-IP-Payload with DPDK Mbuf. DPDK application is running on on virtual machine, the packet generation function invokes the API (attached in second image). I send the packet through DPDK interface and capture on my host system (W10).
Wireshark, can not understand the ethernet protocol as IP.Is there something wrong?
enter image description here
enter image description here
a couple of things you can correct in your DPDK code.
Network packets are big-endian, I assume you are running the Guest OS on x86. If this is true please make sure correct the endianness.
DPDK API rte_pktmbuf_mtod gets you the start of packet. Please fill the ethernet header first, then move 14 bytes ie struct rte_eth_hdr to typecast to IP and fill the data.
in IP field, the checksum filed is set as 0. Please cross-check if you are enabling IP-CHECKSUM offload in port_init.
All fields in IP has to follow BIG endian format too.
There is also a port filed in mbuf. With rte_mbuf_alloc it will be 0, but for sending to another port it should be the right value.
Wireshark observations
Byte 13 and 14 is 0xa50. This looks like your intended payload is overwritten
Byte 1 is 0x45 which clearly shows, you are writing IP header content first instead of ethernet. Please use step 2 from DPDK fixes.
Related
I made a tcpdump and captured packets, the configured MTU is 2140. I am analysing pcap files using Wireshark.
According to the configured MTU the expected maximum size of the packets should be 2154 (2140 bytes +14 ethernet header bytes). But I see packets of size greater than 2154 (ex 9010 bytes), On analyzing I found that these packets are generated on the machine where I made tcpdump (let's say A) and have the destination to another machine (let's say B). I expect a packet to be fragmented before it is sent to another host. I found some explanations online that says tcpdump captures packets before NIC breakdown, though this seems to be a valid explanation but it seems to contradict in my case because on machine A, I received packets of size greater than 2154 from B. Any thoughts, on why machine A is sending and receiving packets greater than configured MTU.
What you are seeing is most likely the result of TCP Segment Reassembly Offloading. This is a feature available on some network cards with matching drivers.
The idea is that the reassembly of many of the TCP segments is handled in the NIC itself. This turns out to be pretty effective in reducing overhead on the CPU/OS side since the network driver need only handle, perhaps, 1 "packet" out of 10, seeing just one large packet, rather than receiving and reassembling all 10.
You can read more about it here.
Updated answer
If your packet is UDP
This behaviour is normal. but there is not much you can do to see the individual packets on the end machines. The UDP packet is broken down into MTU compliant packets and reassembled at the Link layer, usually by specific hardware. This is too low to to be captured by Wireshark/pcap.
If you want to capture the individual broken down packets, you have to do this on an intermediate machine/network card, for example a gateway between the two hosts, because the original UDP packet is not reassembled until it reaches its final destination. Note : this gateway can be virtual.
See notes.shichao.io/tcpv1/ch10
Leaving this here in case someone with the same problem comes...
If your packet is TCP :
It sounds like Wireshark is reassembling packets for you. This is often the default for TCP streams. You can change this by richt-click on a stream -> Protocol Preferences -> Allow subdissectors to reassemble TCP.
Lately I have been trying to analyze wifi traffic over my own test router.
I looked on the wireshark website on how to do this and setup my own testing network.
my network:
-dd-wrt router with WPA2 personal mixed security using tkip+aes.
-kali linux capture machine with wireshark 1.8.5
-android phone for producing traffic
I then put the wireless interface of my kali laptop into monitor mode user airmon-ng
airmon-ng start wlan0
To check if the created monitor interface(mon0) worked I would use airodump-ng.
When I knew that my monitor interface was working, I started up Wireshark.
I selected mon0 as capture interface and pressed options. In Capture options I put the mac adress of my router, which I got through airodump-ng, in the capture filter area.
I then would take care of the packet decryption that would be needed for me to see the actual data. I went to the following webpage:
http://wiki.wireshark.org/HowToDecrypt802.11
I followed the instructions there.(Only the way I need to put in the decryption keys is different than the key#1 system that is described on the page. I get a new window in which I need to select a security method wep,wpa-pwd or wpa-psk and input the key).
I used the wireshark wpa psk generator tool to get the right pre-shared key.
http://www.wireshark.org/tools/wpa-psk.html
Essid: "testnet"
Password: "wachtwoord"
psk: 33fe484e651381b15859e539279f2991c0f5e5e751ef17f82104d4ad528718ca
I put in 2 new keys. One being wpa-pwd with wachtwoord as its value. The second being wpa-psk with the psk mentioned above as its value.
I applied all the settings, and checked the enable decryption checkbox.
So I clicked the start capture button and saw a whole bunch of beacon frames rolling in.
I associated my android phone with the AP so I knew I capture the eapol packets(I checked this using the filter and I had all 4 packets).
After filtering with "data", I saw that I didn't capture any data packets.
I then expected to see the actual traffic, but this was not the case.
airdecap-ng did not see any WPA packets in the capture file.
My only theory left after hours of puzzeling is lack of driver support.
Please tell me what I am doing wrong?
Thank you!
tl;dr:
My computer does not capture 802.11 wpa2 data packets, and I can't figure out why.
Have you checked if you can capture Wifi frames in OPEN/NONE security? If it doesn't work with OPEN/NONE, then you need to fix the setup before being able to capture WPA2/AES traffic.
Steps I used to check Wifi capture setup:
- Configure AP as OPEN/NONE (open authentication, no encryption).
- Add monitor interface:
$ sudo iw phy phy0 interface add moni0 type monitor
$ sudo ifconfig moni0 up
Set channel of properly (same between the AP and the laptop). Avoid popular ch1,6,11 (use channel 7, for example) to reduce the amount of captured traffic.
Some wireless cards do not support monitor mode very well, so it may also be worth to avoid 802.11n, use 802.11b/g only.
Here is a wireshark capture of an ARP request PNG image, I contains the sender MAC inside the ARP packet. The receiving station can derive the MAC from the Ethernet frame. It seems to be redundant. Is there any particular use of separately including the sender MAC address in ARP Request too ?.
The "redundancy" was by design (RFC 826), and can be useful in targeting different layers. In RFC 3927 there's what is known as Gratuitous Address Resolution Protocol (GARP), and in certain circumstances the redundancy, or lack of, plays an important role, especially in troubleshooting and monitoring networking stacks.
Actually it's not rendunancy at all, the MAC (physical, layer 2) and IP (logical, layer 3) addresses are not the same thing. They serve different purposes on different network layers.
On large scale networks it's quite common to observe changes in the MAC/ARP/Source/Dest information, and at times can seem almost incorrect. For example, you might see a host send an ARP request with its own address as the target address. Depending on the exact situation, it might be telling us it's a link up/down event, maybe it's trying update other devices ARP tables, or possibly detecting an ip conflict and moving the ip to another NIC.
I could get into clustering, failovers — the list goes on, although I would end up writing a book trying to explain it all. Hopefully this gives you a bit of insight about the "redundancy" you were questioning. ;-)
More Info:
RFC 826 /
RFC 3927
/ Wireshark Gratuitous ARP
Although often used in conjunction with Ethernet, ARP by itself is an independent protocol. Imagine other link layer protocols that do not expose MAC addresses. ARP would not work in such circumstances if the sender field was not provided.
There is no rule that the ARP protocol field sender mac address to be same as ethernet source mac address. Eg: Its possible in few applications where multiple interfaces of same host are on network, but one only interface sends arp responses for all interfaces.
I have an application that is designed and working that is receiving UDP broadcasts on a port. The application has been working just fine, but I have wanted to compare the packets received by the application with a Wireshark capture. I'm trying to make sure that I'm capturing as many of the packets as possible with minimal data loss.
I initially thought that I'd run Wireshark and compare the raw packets captured against the packets shown in our application. However, when I run Wireshark, the packets are never captured at the IP layer for that port. I see other traffic from the server, but I never see Wireshare packets for this specific port.
The application continues to capture the data just fine. When I look at the IP src/dest fields, the src looks correct, 10.12.10.42, however the destination IP address is 0.0.0.0. I would have expected something like 255.255.255.255 instead for the destination address.
I don't have access to the application that is broadcasting the data, but I did write a quick sample UDP broadcaster and receiver to make sure I my expectations were correct. the sample application worked as expected.
Any ideas on why a UDP broadcast would be received by an application, but not show up in a Wireshark capture? Does Wireshark ignore an address like 0.0.0.0 and not capture it all?
Wireshark only captures Ethernet frames that are going through an interface you are listening on. Thus, packets destined on loopback addresses are not captured. I would check your machine's routing tables to see where packets are actually going.
I am willing to build a prototype of network appliance.
This appliance is suppose to transparently manipulate Ethernet packets. It suppose to have two network interface cards having one card connected to the outside leg (i.e. eth0) and the other to the inside leg (i.e. eth1).
In a typical network layout as in the attached image, it will be placed between the router and the LAN's switch.
My plans are to write a software that hooks at the kernel driver level and do whatever I need to do to incoming and outgoing packets.
For instance, an "outgoing" packet (at eth1) would be manipulated and passed over to the other NIC (eth0) which then should be transported over to the next hope
My questions are:
Is this doable?
Those NIC's will have no IP address, is that should be a problem?
Thanks in advance for your answers.
(And no, there is no such device yet in the market, so please, "why reinvent the wheel" style of answers are irrelevant)
typical network diagram http://img163.imageshack.us/img163/1249/stackpost.png
I'd suggest libipq, which seems to do just what you want:
Netfilter provides a mechanism for passing packets out of the stack for queueing to userspace, then receiving these packets back into the kernel with a verdict specifying what to do with the packets (such as ACCEPT or DROP). These packets may also be modified in userspace prior to reinjection back into the kernel.
Apparently, it can be done.
I am actually trying to build a prototype of it using scapy
as long as the NICs are set to promiscous mode, they catch packets on the network without the need of an IP address set on them. I know it can be done as there are a lot of companies that produce the same type of equipment (I.E: Juniper Networks, Cisco, F5, Fortinet ect.)