The M2M-TLV and Wimax plugins are poorly documented.
Hopefully this will help:
Wimax is not an ethernet protocol, so it is wrapped in the
"M2M-TLV" protocol for transmission over ethernet. M2M encodes data
into TLVs.
The Wimax MAC assembles PDUs into "bursts" for
transmission. These bursts are carried intact onto the M2M protocol. Since
burst length may exceed ethernet frame length, the TLVs may be fragmented.
M2M TLVs and fragments are entirely separate from Wimax TLVs
and PDU fragmentation. The M2M dissector identifies "wimax pdu burst"
TLVs, reassembles them if fragmented, and passes the entire burst to the Wimax
dissector. Thus the Wimax dissector receives a burst that is identical to what is
passed between the Wimax MAC and PHY.
The Wimax dissector is completely independent of any concept
of Ethernet. It is designed to be called as a secondary dissector from some
other protocol. You could replace M2M with anything.
DISSECTOR REGISTRATION
plugins/m2m/packet-m2m.c : proto_register_protocol()
plugins/m2m/packet-m2m.c : proto_reg_handoff_m2m()
registers M2M as an ethernet protocol
plugins/wimax/packet-wimax.c : proto_register_wimax()
plugins/wimax/wimax_pdu_decoder.c : proto_register_wimax_pdu()
registers the Wimax dissector as a "utility"
protocol
Wimax dissector is only invoked by other dissectors
DECODING
[wireshark]
wireshark grabs an ethernet frame, and sees that an M2M
dissector is registered to handle it
plugins/m2m/packet-m2m.c : dissect_m2m()
separates M2M packet into TLVs, looks for "wimax pdu
burst tlv"
plugins/m2m/packet-m2m.c
: pdu_burst_decoder()
displays tlv info on wireshark tree
reassembles fragmented burst-tlvs
finds wimax dissector and calls it with reassembled
burst-tlv:
wimax_pdu_burst_handle =
find_dissector("wimax_pdu_burst_handler");
call_dissector(wimax_pdu_burst_handle, pdu_tvb, pinfo,
tree);
(invokes dissect_wimax_pdu_decoder())
plugins/wimax/wimax_pdu_decoder.c : dissect_wimax_pdu_decoder()
separates a burst into individual PDUs and/or padding
classifies PDU types as bandwidth req, signaling, or data
sends data PDUs to dissect_mac_header_generic_decoder()
plugins/wimax/mac_hd_generic_decoder.c : dissect_mac_header_generic_decoder()
handles mac pdus: packing, fragmentation, subheaders, CRC
if pdu has payload, classifies pdu as mgmt or data based
on CID value
(mgmt cid range is configurable in GUI as a property of
the wimax dissector)
if pdu is determined to be a mgmt message, passes it to
dissect_mac_mgmt_msg_decoder()
plugins/wimax/mac_mgmt_msg_decoder.c : dissect_mac_mgmt_msg_decoder()
determines mgmt message type and calls appropriate decoder
function
NOTES
With the exceptions of dissect_m2m() and
dissect_wimax_pdu_decoder(), functions are invoked directly, not via
call_dissector().
Originally this was implemented with each management message
being registered as a separate dissector for flexibility, and they communicated
using call_dissector(). We changed this to direct function calls because it
made filtering awkward, as all the filter IDs were scattered around. Treating
Wimax as a single monolithic dissector kept the filter IDs grouped together for
easy reference.
You may see "proto_register_xxx()" functions
scattered throughout the mgmt message decoder files. I'm not sure whether these
are being called/registered or not, but I know they aren't being used. Anyway
it could be confusing.