Hi Forum I have a protocol that I am dissecting and I have been creating and registering each field in a hf_register_info to get the correct labels X00001 and X00002 etc for the fields.
static hf_register_info hf[] = { { &hf_X00001, { "X00001", "FOO.X00001", FT_UINT16, BASE_DEC, NULL, 0x0,NULL, HFILL } }, ... { &hf_X99999, { "X99999", "FOO.X99999", FT_UINT16, BASE_DEC, NULL, 0x0,NULL, HFILL } } } In reality the only item that is changing is the label prefix being showing in the dissection. I don't need to be able to search using F00.X00001. Is there anyway to dynamically create this prefix label to avoid having to create massive hf_register_info records??? Ideally without the need for the hf_register_info record at all. This is becoming a massive list of names and there must be something I am missing. Thanks Stuart asked 10 Dec '12, 03:13 StuieNorris |
2 Answers:
Well, you're going to have to create all those hf entries at some point. You could dynamically generate the table, maybe even combining some static entries with some dynamically-created ones. packet-diameter.c does this for example: there are some static entries for basic stuff and then the rest of the entries come from reading the Diameter XML files; these are combined before registering the whole table. You could also create lots of smaller arrays and register them all in a loop (packet-tpncp.c does this) but I the the first solution would be easier. answered 10 Dec '12, 07:38 JeffMorriss ♦ |
Another possibility: If you really don't need to filter on the specific fields, then I think the following will work.
If you do this, then I think you can generate the label name programattically when doing the proto_tree_add_uint() so that you can use a simple loop to display the data. This approach does allow searching all of the fields. Yet another possibility (less favored): proto_tree_add_text(...); no hf[] entry req'd; cannot be searched. See doc/README.developer .... proto_tree_add_uint(...) ... These routines are used to add items to the protocol tree when the dissector routine wants complete control over how the field and value will be represented on the GUI tree. The argument giving the value is the same as the corresponding proto_tree_add_XXX() function; the rest of the arguments are a "printf"-style format and any arguments for that format. The caller must include the name of the field in the format; it is not added automatically as in the proto_tree_add_XXX() functions. answered 10 Dec '12, 08:22 Bill Meier ♦♦ edited 10 Dec '12, 08:26 |