Wireshark-dev: Re: [Wireshark-dev] query regarding wimax r1 interface code
From: "Harvey, Michael" <[email protected]>
Date: Wed, 22 Aug 2007 11:20:16 -0700

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.




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






  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





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.