Open schneider42 opened 8 years ago
You're absolutely correct, this is just briefly mentioned in the specifications ("The protocol may be extended in the future by having extra words after the last RFtap optional field"), but I haven't published the extension specifications yet.
The extension structure is planned to be similar to 802.11 tagged parameters. The intention is to support extra RF parameters such as Channel State Information (CSI) and more.
In the mean time, if you would like to use the dissector name tag, here is the dissector_name tag structure (already supported by Wireshark RFtap dissector). It should be appended to the RFtap header, after all the optional parameters:
struct dissector_tag {
le16 tag_id;
u8 tag_len;
u8 tag_flags;
u8 dissector_name[];
u8 padding_for_u32_alignment[];
} __attribute__((packed));
Here is a complete example to encode dissector name "rds", in pseudo-code:
#define RFTAP_TAG_DISSECTOR_NAME 16
d.tag_id = RFTAP_TAG_DISSECTOR_NAME; // tag ID 16
d.tag_len = 3; // length of string, in bytes (not zero-terminated)
d.tag_flags = 255; // mandatory.
d.dissector_name = {'r', 'd', 's'};
d.padding = {0, };
Resulting in the following byte sequence:
10 00 03 ff 72 64 73 00
I hope this helps
The code has an option to put a dissector name into the RFtap packet: https://github.com/rftap/gr-rftap/blob/master/python/rftap_encap.py#L158
The specification does not mention this option