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
.