On 9/7/07, Wen Cheng <wencheng@xxxxxxxxx> wrote:
> Hi all,
>
> Great job Stephen. I'm a wimax tester, I really like your tool. But I think
> the display pattern of TLVs is not very good from a tester point of view.
> May I help to do some improvment work?
>
This dissector has already been useful to us, thanks again for posting it.
Wen - in case you didn't see them, here as some comments I made in
bugzilla (http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1811)
while the patch was under review. These maybe don't relate to the
display pattern, but are changes I hope to make in the coming weeks.
Regards,
Martin
"Here are a few quick comments:
(1) some of the tlv definitions don't match in all cases what I see in my
example captures (I'm sure these can be resolved as the spec settles down -
I'll ask someone who has been involved with such things to look at this next
week)
(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
(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.
<snip>
(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"
<snip>
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)
"
