A few days ago I ran a sniffer application using CC1101 transceiver. Sniffing device is connected via UART<->USB adapter to PC. A python sniffer application redirects the frames to Wireshark (v. 2.0.0).
Sniffer was gathering frames from one node programmed with gnrc-networking example application. This node was sending a frame in every 10 seconds. The problem is that Wireshark did not recognize any 803.15.4 frames. Digging deeper into a 803.15.4 frame, controll part (first octet) look like:
0-2 frame type (000 Beacon, 001 Data, 010 Ack, 011 MAC command, 100-111 Reserved)
4 frame pending
6 PAN ID Compression
10-11 Dest. Addressing Mode (00 PAN and addr. not present, 01 Reserved, 10 Short address, 11 Ext. Address)
12-13 Frame Version (00 IEEE802.15.4-2003 compatible, 01 IEEE802.15.4 compatible)
14-15 Source Addressing Mode (00 PAN and addr. not present, 01 Reserved, 10 Short address, 11 Ext. Address)
The received data has wrong source address mode (picture in attachment). Why is there no compatibility with IEEE802.15.4 standard?
Is there anyone with knowledge concerning sniffing radio packets in RIOT powered mesh using Wireshark? Is there a possibility to recognize 802.15.4 packet types using standard Wireshark dissector?
could you please tell us, which board (and radio) you were using to send out the 802.15.4 frames? Seems to me that you discovered a bug in RIOT, which leads to a faulty address mode configuration somehow… Also would you mind to attach your wireshark dump (as you forgot it in your previous mail…). Thanks!
as Kaspar already pointed out: the cc110x device is not a 802.15.4 device, but has both different physical and link-layer from 802.15.4. However, our sniffer script assumes the connected device is 802.15.4 device, so the PCAP data you are receiving in wireshark are marked as 802.15.4 frames, but they are not. As such the output is broken.