On 7/10/07, Luis EG Ontanon <[EMAIL PROTECTED]> wrote: > A year or more ago I abandoned a way towards (3) (similar to what I > did for radius dictionary) a while ago, due to a personal lack of > diameter use after switching jobs and a stall about how to handle > recursion in attribute_groups. > > I will be able to get back into it in September (I'll be off-contract > and unable to move from Rome). Please remind me then or as an > alternative I could send the work-in-progress for someone else to deal > with it.
I think this would make the Diameter dissector much more useful to users who are trying to understand diameter message flows. My personal use of the dissector is mainly to help verify that our implementation of the various interfaces we support encodes and decodes properly (hence my modifications to find and diagnose undecoded or malformed AVPs)... > BTW In an early MATE prototype (befor having it defining fields for > every user defined element) I used string fields like mate.pdu_avp == > "avp_name=string_repr_of_value", those allow to actually filter. I > thought about this "quick and dirty" solution for radius before > writing its dictionary support. > I wondered if MATE or the LUA support could make this kind of filtering possible, but dynamically creating filters is obviously the right way to do it. _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
