Hi,
Gilbert is most probably right. When browsing really quickly the plugin
code you indicated in your initial post, I cannot find a
proto_tree_add_item(tree, proto_openflow, tvb, 0, -1, ENC_NA) call.
Did you try to modify dissect_openflow() with something like this ?
static gint ett_of = -1;
void
dissect_openflow (tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
proto_item *item = NULL;
proto_tree *of_tree;
if (tvb_length(tvb) < OFP_MIN_PACKET_SIZE) // This isn't openflow
return;
item = proto_tree_add_item(tree, proto_openflow, tvb, 0, -1, ENC_NA);
of_tree = proto_item_add_subtree(item, ett_of);
guint8 version = tvb_get_guint8(tvb, 0);
switch (version)
{
case OFP_100_NS::gVersion:
OFP_100_NS::Context->dissect(tvb, pinfo, of_tree);
break;https://mail.google.com/mail/u/0/?shva=1#inbox/140c5a459a4249c2
case OFP_110_NS::gVersion:
OFP_110_NS::Context->dissect(tvb, pinfo, of_tree);
break;
case OFP_120_NS::gVersion:
OFP_120_NS::Context->dissect(tvb, pinfo, of_tree);
break;
case OFP_130_NS::gVersion:
OFP_130_NS::Context->dissect(tvb, pinfo, of_tree);
break;
default:
return;
}
}
Then in proto_register_protocol(), add something like this:
void proto_register_openflow()
static gint *ett[] = {
&ett_of
};
proto_openflow = proto_register_protocol("OpenFlow Protocol", "OFP",
"of");
proto_register_subtree_array(ett, array_length(ett));
OFP_100_NS::init(proto_openflow);
OFP_110_NS::init(proto_openflow);
OFP_120_NS::init(proto_openflow);
OFP_130_NS::init(proto_openflow);
register_dissector("openflow", dissect_openflow, proto_openflow);
}
Regards,
Pascal.
2013/8/29 DbdM Tbt <[email protected]>
> Good day Gilbert,
>
> Thank you for your reply.
> I would just like to add additional information (forgot to include them
> last night):
> 1. used the latest stable release (1.10.1)
> 2. same behavior observed in windows xp 32bit (vs2010) and centos 6.4
> 32bit/64bit.
> 3. dissector dissects successfully.
> 4. protocol seems to be registered as it can be seen in
> 'Analyze'->'Enabled Protocols'
> 5. filter name shows in the drop down selection in the display filter
> combo box
>
> I also just ran 'tshark -G protocols' and the protocol is indeed known.
> Perhaps it is as you say that the protocol is matching something else.
> Haven't yet tried dftest and will try it as time permits.
>
> Thank you,
> David
>
>
>
> On Thu, Aug 29, 2013 at 5:15 AM, Gilbert Ramirez <[email protected]>wrote:
>
>> The protocol filter name checks for the existence of the protocol entry
>> in the proto_tree data structure hierarchy.
>>
>> This is done with proto_tree_add_item(), as in this example from
>> packet-ip.c :
>>
>> ti = proto_tree_add_item(tree, proto_ip, tvb, offset, hlen, ENC_NA)
>>
>> Could it be that your "proto_ABC" was not added to the tree in this way?
>> Or, maybe the value that was assigned to your protocol via
>> proto_register_protocol() changed during execution?
>>
>> As a test, compile "dftest" and run dftest with your protocol name, and
>> see what the "display filter virtual machine" opcodes will be. Maybe your
>> protocol name is matching something else?
>>
>> Also, you can run: "tshark -G protocols" to see if your protocol really
>> is known.
>>
>> Gilbert
>>
>>
>> On Wed, Aug 28, 2013 at 8:55 AM, DbdM Tbt <[email protected]> wrote:
>>
>>> Good day to all,
>>>
>>> I have been trying to figure out a behavior for a while now where the
>>> 'filter name' (third parameter of proto_register_protocol() function) does
>>> not filter the captured messages.
>>> For a brief background, I am studying/using an existing openflow
>>> dissector:
>>> https://github.com/CPqD/ofdissector
>>>
>>> I have scanned the README.developer and from looking at the ofdissector
>>> code, everything seems to be in order.
>>>
>>> At first I thought that the 'filter name' should be the same as the
>>> first 'prefix' of the display filters registered in hf_register_info
>>> declarations. Meaning if the display filters are like 'abc.yyy.xxx', the
>>> filter name should be 'abc'.
>>> But I think this does not necessarily need to be the case as I tried
>>> changing the prefixes in another of my dissectors and the filter name seems
>>> to work fine.
>>>
>>> Does anyone have any possible leads/reasons/hypothesis as to where
>>> should I be looking to fix this?
>>>
>>> Thank you in advance.
>>>
>>> Best regards,
>>> David
>>>
>>>
>>>
>>> ___________________________________________________________________________
>>> Sent via: Wireshark-dev mailing list <[email protected]>
>>> Archives: http://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>> mailto:[email protected]
>>> ?subject=unsubscribe
>>>
>>
>>
>>
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <[email protected]>
>> Archives: http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:[email protected]
>> ?subject=unsubscribe
>>
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <[email protected]>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:[email protected]
> ?subject=unsubscribe
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
