Bellow some notes for anyone willing to implement the dictionary based
on diameter's:
> > (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.
Just as a note for implementation:
dictionary_load() in packet-diameter.c should be taken out from there
and should be refactored to take a struct* through which it returns
the garrays for hfs, etts, other than the directory and filename and
basic_types[], each type-dissector should be passed the struct used to
build the dictionary and the dictionary data for the specific avp
(type, code, vendor, value_string and type data).
extern int dictionary_load(
struct _build_dict* build;
diam_dictionary_t* dict;
const avp_type_t* types;
const char* dirname,
const char* filename);
each dissector should provide a basic_types[] and the relative
callbacks to populate the hf[] and ett[] other that it's owwn data in
the dictionary.
L.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
