Martin Mathieson wrote: > This dissector has already been useful to us, thanks again for posting it. > You're welcome. > (2) I'd probably add more expert items to report more things like: > - length fields not being consistent with that implied by type of TLV > - unknown tlv codes >
Yes, that was something I left for future work. To facilitate the addition of expert items, I made all functions accept the packet_info pointer, regardless of whether it used it or not. Regarding unknown/TBD TLVs, there is a preference for enabling debug output that will emit a debug statement to the console when one of these TLVs is encountered. It's a rather convenient way of identifying such TLVs found in captures. > (3) I notice that the field of the tlv parent is wimaxasncp.tlv_type. I'd > rather it were just a byte-string field, e.g. wimaxasncp.tlv, then maybe have > the child nodes be e,g, wimaxasncp.tlv.length, etc. This is probably just a > matter of taste. There are some other little prettifications that I'd want to > make. > Matter of taste? No, not that complicated. This was my first dissector, so I would simply say inexperience (on my part). > (5) Its not possible to set a filter to do a comparison with the value of a > certain tlv, e.g. you can't do 'wimaxasncp.avp.ms_nai == "base_station_w3" > True. It's related to the following point: > Points (1), (3) and (5) remind me strongly of Diameter dissector issues, and I > wonder if this dissector should (eventually) be done in a similar way, i.e. > - read the tlv definitions in from one or more XML files at run-time > - dynamically register filters such as described in (5) > I actually did recommend that the dissector use XML files for TLV definitions when I did my initial analysis. Unfortunately that did not happen in the initial release. -- Steve Croll _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
