0

I've a device capturing traffic with Tcpdump filtering on "upd dst port" then it creates a pcap file to be read in wireshark.

what I obtain from running:

tcpdump udp dst port 5201 -qUns 0 -i wlan0 -w file.pcap

are only ip fragmented frames. (which don't give me actual information about radiotap rate)

while running:

tcpdump udp -qUns 0 -i wlan0 -w file.pcap

gives me the output with udp frames and fragmented frames.

and even more... Why when I filter traffic on wireshark on IP[10]==17 ,(which is the protocol field in IP header), I obtain about 0.3% of total result while if I write simple "udp" in display filter text box I get 16% of the total results and fragmented ip packets hide ? What's the difference ??

Display filter: UDP

Display filter: ip[10]==17

Thanks in advance.

1 Answer 1

1

what I obtain from running:

tcpdump udp dst port 5201 -qUns 0 -i wlan0 -w file.pcap

are only ip fragmented frames.

That's probably because whatever traffic is going to port 5201 consists of UDP packets that are larger than what would fit in a single link-layer packet, so IP has to fragment them.

That filter, unfortunately, will only capture the first fragment, because the OS filtering mechanism that libpcap uses does filtering on a packet-by-packet basis without maintaining any packet history, and either 1) the first fragment of a fragmented UDP packet will contain the full UDP header, and the others will not have any information to identify them as being additional fragments of that fragmented packet (without packet history, the IP identifier doesn't help) or 2) the UDP header itself is fragmented, in which case the filter won't work at all (that will probably never happen in practice, but it's not ruled out by RFC 791). Additional fragments won't be captured, so you won't have the full packet.

(which don't give me actual information about radiotap rate)

If any packet doesn't have information about the radiotap rate, that's a bug in the driver for your adapter; there is nothing about fragmented IP packets that would cause them not to have the rate information while other packets have it.

Why when I filter traffic on wireshark on IP[10]==17 ,(which is the protocol field in IP header), I obtain about 0.3% of total result while if I write simple "udp" in display filter text box I get 16% of the total results and fragmented ip packets hide ?

Because the offsets in expressions such as ip[10] == 17 start at 0, so the first byte would be ip[0], and therefore, as the protocol number is the tenth byte, the right test for UDP packets would be ip[9] == 17, not ip[10] == 17.

4
  • Thanks a lot. But for the radiotap issue, I meant that there is a radiotap header encapsulating the fragmented ip packet, but the problem is that when I try to get the chart from OI statistics I get wrong bits/sec in the case of ip fragmented frames and true values when I have udp full packets. and for the IP field, I tried to use ip[9]==17 and that gave me no results, at least I could get results using ip[10]==17 and those results I got have UDP as a protocol field.
    – Alberto
    Apr 27, 2015 at 23:10
  • "I meant that there is a radiotap header encapsulating the fragmented ip packet" There will be a radiotap header encapsulating every single 802.11 frame that you capture, whether it's a beacon frame, some other management frame, a control frame, a data frame containing a fragmented IP packet, a data frame containing an unfragmented IP packet, a data frame containing an ARP packet, or any other sort of data packets.
    – user164970
    Apr 28, 2015 at 0:51
  • "but the problem is that when I try to get the chart from OI statistics I get wrong bits/sec in the case of ip fragmented frames and true values when I have udp full packets" If by "udp full packets" you mean "UDP packets that aren't fragmented", that's probably because, for fragmented IP packets, you're only capturing the frame containing first fragment, not the rest of the fragments, but, for unfragmented IP packets, you're capturing the entire packet. That has nothing to do with radiotap.
    – user164970
    Apr 28, 2015 at 0:54
  • "I tried to use ip[9]==17 and that gave me no results, at least I could get results using ip[10]==17 and those results I got have UDP as a protocol field" Then you probably have a buggy version of libpcap, as ip[10] refers to the eleventh byte of an IPv4 header, and that's not the protocol field. What does tcpdump -h print?
    – user164970
    Apr 28, 2015 at 1:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .