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.
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
