Wireshark-dev: Re: [Wireshark-dev] query regarding wimax r1 interface code
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. |
- References:
- [Wireshark-dev] query regarding wimax r1 interface code
- From: Amit Paliwal
- [Wireshark-dev] query regarding wimax r1 interface code
- Prev by Date: Re: [Wireshark-dev] --with-net-snmp adds addtional options to CFLAGS: Issue if using --without-net-snmp ??
- Next by Date: [Wireshark-dev] Display Filter Fields typos, missing fields, etc.
- Previous by thread: [Wireshark-dev] query regarding wimax r1 interface code
- Next by thread: [Wireshark-dev] review_for_checkin granted: [Bug 1730] Patches to PANA Protocol Dissector (packet-pana.c)
- Index(es):
- Get Wireshark
- Download
- Code of Conduct