0

I asked a similar question on SO, but was directed to post it here. For original context, see this SO post.

In short, I'm trying to extract the source and destination IP addresses of a received packet via npcap. Since I'm capturing packets via my device's Wi-Fi adapter, though, the packets have a MAC header. After some research, the addresses within the header (1 through 4) are MAC addresses, assuming they're there, depending on the TO/FROM DS bits.

I suppose I could use the MAC addresses, instead of the IP addresses, but I am still curious, nonetheless: Is it possible to receive the IP addresses? Someone in the original post mentioned that IP addresses are layer 3 and, as such, are part of the layer 2 payload. I'm not quite sure what this means...I understand that the packet I received is layer 3, because I received a packet over a network, so was the point they were trying to get across is that the "data" portion of the MAC frame contains the layer 2 payload?

Hence, is the "data" portion of the MAC frame the ACTUAL data of the packet itself, or does it describe more data about the header? If the latter, since the data varies in length, how do I know how many bytes to move forward (that is, past the CRC field of a MAC frame), in order to get to the actual packet data itself? Is there some information elsewhere in the MAC header that says explicitly how many bytes the data portion has?

2 Answers 2

2

If the IP address information is anywhere it will be in the data payload of the layer 2 frame but it will almost certainly be encrypted so you can't read it.

Also, your original question indicates you are trying to make a network map but that is not something you can accomplish via WiFi network capture unless you simply want to map locations where you can reach a given access point with your client device.

Creating a viable network map requires administrative access to the wired network and any wireless equipment connected to it. Simply capturing whatever WiFi frames might make it to your device will probably be the equivalent of trying to draw a map of the US interstate highway system by looking out your window to watch cars driving by and noting their model and color.

5
  • I see. To clarify, though, how does one "access" layer 2? I keep seeing MAC header format graphics like this and this. Is the data payload of layer 2 the variable data portion of these graphics? They don't seem to differentiate between the actual header and the packet data itself. Also, the goal is to create a network map, so is there some other tool I could use to do this? I don't mind using APIs, but this is a solo project for a portfolio; is it even possible?
    – Paul
    Commented Jun 15, 2023 at 0:04
  • It would be difficult to map out a network just by sniffing traffic from your wireless interface. You would only be able to capture traffic specifically targeted at your device, or broadcast traffic occurring in the subnet of your device. Commented Jun 15, 2023 at 0:10
  • At the very least, would the map consist of direct connections to my device? It'd be a pretty lame map, sure, but isn't this possible? Also, would these connections just be the direct connections from my device to my local router/switch? (That is, one connection)
    – Paul
    Commented Jun 15, 2023 at 0:14
  • If you were making a network map using only source and destination MAC addresses, then it would be a map showing any connections between your device and other devices in your subnet (but mostly connections to your router's MAC address as your device talks out to the Internet. If you extracted the source and destination IP address from each packet, you could make a more interesting map, but without having a way of determining which subnets remote IPs belong to, "mapping" the network might be challenging. Commented Jun 15, 2023 at 0:37
  • To achieve your goal, you need to capture traffic at the wired network layer via a managed switch. Capturing it on your wifi client device will provide you a very slim collection of data which will be mostly control traffic for your client and traffic you initiate or receive to/from your client device. So you will already know the source/destination IP since you created it. Your map would result to a line between your client and the access point/router you use as gateway and possibly any destinations on the internet you choose. Commented Jun 15, 2023 at 18:18
0

If you're capturing an Ethernet Frame with an IP Packet inside it on a wireless interface (so no VLAN tags present), the breakdown will be as follows:

  • 6 bytes - Destination MAC Address
  • 6 bytes - Source MAC Address
  • 4 Bytes - Type (eg: 0x0800 for IPv4)

The next consecutive bytes will be the IP packet which will look like:

  • 1 byte - Verstion (0100 for IPv4)
  • 1 byte - Header Length (20 bytes)
  • 1 byte - DSCP Field
  • 2 bytes - Total Length
  • 2 bytes - Identification
  • 1 byte - Flags
  • 1 byte - TTL
  • 1 byte - Protocol (eg: UDP or TCP)
  • 2 bytes - Header Checksum
  • 4 bytes - Source IP Address
  • 4 bytes - Destination IP Address

If you want to examine fields and values in more detail, I recommend downloading wireshark (www.wireshark.org) and capturing some live traffic - it's in-built decoders will give you all the information you need on the breakdown of Ethernet frames and IP packets.

6
  • (1/2) Currently, I'm performing a live capture with pcap_loop, using my device's Wi-Fi adapter as the capture handle. You mentioned I could make a more interesting map if I extracted the source and destination IP addresses; this was the original goal of the project. The road bump I ran into was actually extracting those addresses, because I was unsure if they were included in the "data" portion of the MAC header (see hyperlinks in comment under original post), or if I had to jump forward X bytes, but then the issue is getting X.
    – Paul
    Commented Jun 15, 2023 at 1:31
  • (2/2) Then, @FrameHowitzer mentioned that even if I did know X, it'd be encrypted, and it's likely impossible for me to decrypt it. Really, the goal was to capture live traffic for some amount of minutes, extracting the source/destination IP addresses for each packet captured, and sending each address to a python script that would use an external API to map (roughly) the location of that device in relation to mine.
    – Paul
    Commented Jun 15, 2023 at 1:33
  • If your Wifi adapter is associated to the WLAN and capturing, packets will not be encrypted. I'm no C programmer, but looking at the link you are referring to, there is a whole section dedicated to "Interpreting the Packets" which, while specifically focussed on UDP, also prints the source and destination IP addresses. Maybe you could start there Commented Jun 15, 2023 at 1:52
  • The traffic you capture would largely be the traffic sourced from or destined to your own device. No need to examine it since you already know what it is, your device generated most of it. Traffic for other devices on the network will either not be sent to your device or will not be readable by your device since they will be encrypted using unique keys for the other devices. You could try to decrypt it but it is vastly more effective to simply use a managed switch to perform a traffic capture. Commented Jun 15, 2023 at 18:21
  • @FrameHowitzer Maybe there was a misconception? I'm only interested in the traffic for the device that's running the code I wrote (i.e., the packet-capturing device). I'm not interested in any other devices on my network. The issue I was having (in addition to finding where the IP addresses were within a packet received over Wi-Fi) was getting each "hop" that the packet made from its source device to my device. I was planning on using traceroute, or something similar, to get its sort-of "journey." Is this something that's possible?
    – Paul
    Commented Jun 21, 2023 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.