On Wed, Dec 24, 2008 at 2:48 AM, Yuming fang <[email protected]>wrote:
> > > 2008/12/24 Martin Mathieson <[email protected]> > >> Hi, >> >> I just submitted an LTE MAC dissector. In order to decode MAC frames it >> needs to know at least : >> - the RNTI type associated with the frame >> - direction (uplink or downlink) >> >> These and other fields that can be passed to the dissector are in >> epan/dissectors/packet-mac-lte.h. I've added support for filling in this >> info from the DCT2000 format (see packet-catpault-dct2000.c, >> attach_mac_lte_info()). >> > > > > You mean you add a LTE MAC dissector in wireshark. And you could invoke > this dissector when the wireshark find there is LTE data in DCT2000-format > packets. Actually the packet-catpault-dct2000.c could know the data is LTE > MAC data. Is this right? Where could I find these code? Could you give me a > link? > > > Yes, if the file is dct2000 its explicitly says that the data is LTE MAC data. And it also has the other information (e.g. rnti, direction) that are needed in order tell the MAC dissector how to properly decode the frame. Its more a test log format than a raw capture format. Here is a link to the source file in subversion: http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-catapult-dct2000.c > > >> >> I'd be happy to try to help anyone else who's working with LTE MAC to call >> the dissector from whatever file format or encapsulation they may be using. >> > > > I am adding the LTE MAC code into a TCP(LTEMAC) > dissector(packet_tcp_lte.c). There are mainly three functions in this file. > static int dissect_tcp_lte(tvbuff_t *tvb, packet_info *pinfo, proto_tree > *tree); > void proto_register_tcp_lte(void); > void proto_reg_handoff_tcp_lte(void); > I am adding the LTE code into these functions. Could this solution work? > > If the frames you were capturing had this extra information (rnti, direction, etc) inside the TCP payload before the actual MAC data, then you could write a little dissector to: - read these values - fill in a mac_lte_info struct with what you have - attach that to the frame (using p_add_proto_data) - call the MAC dissector with the remainder of the data (using call_dissector() or call_dissector_only()) If your don't have this minimal information available, it won't be possible. If your format maybe uses different TCP ports for each RNTI, or RTNI type, or channel, you could try using configuration settings to associate TCP ports with those, where you had something like toward the server port was Uplink, the other way was Downlink. Then you could look up the port and direction, fill in the struct and call the MAC dissector. I'd guess you'll have at least some framing in your TCP format, otherwise it'll be tricky to desegment one MAC frame from another (you won't know how much padding might have been added to the end, because you won't know the size of the grant). Hope this helps, Martin > Thank you! > > Best wishes, > Yuming > > > >> >> Regards, >> Martin >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected] >> ?subject=unsubscribe >> > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
