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:
bits description
0-2 frame type (000 Beacon, 001 Data, 010 Ack, 011 MAC command, 100-111 Reserved)
3 security
4 frame pending
5 AR
6 PAN ID Compression
7-9 Reserved
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!
A few days ago I ran a sniffer application using CC1101 transceiver.
The cc110x doesn't support 802.15.4 natively, so I wrote the driver to
"pretend" to be 802.15.4 to the upper layers, so we can re-use 6lowpan
and the rest of the network stack.
On L2, this is a hack. Only one byte (as supported by cc110x) is used as
MAC address and any higher level packets are just sent as plain payload.
It's possible to emulate the 802.15.4 frame format, and can probably
done in a way that the code could be re-used with other transceivers as
well.
But as the cc110x cannot be programmed to use 802.15.4's modulation, it
will never be able to communicate with other 802.15.4 transceivers.
Hi Mateusz,
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.
