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
