On 9/7/07, Wen Cheng <[EMAIL PROTECTED]> 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) " _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
