Wireshark · Wireshark-dev: Re: [Wireshark-dev] Polling for possible reasons why the 'filter name' does not work

[DbdM Tbt <spin.x2k@xxxxxxxxx>]

Hello Pascal,

You and Gilbert were right in that the proto_xxx was not added to the main tree using the proto_tree_add_item() call.
The existing ofdissector code dissected the message with the openflow subtree being added as a named field instead of the above.

I now learned something new today as I wasn't aware that the proto_tree_add_item() call has a relationship with the 'filter name'.
After tweaking the ofdissector's framework, the 'filter name' works fine now.

Thank you very much for the assistance.

Best regards,
David

On Thu, Aug 29, 2013 at 1:21 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

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 <spin.x2k@xxxxxxxxx>

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 <gram@xxxxxxxxxxxxxxx> 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 <spin.x2k@xxxxxxxxx> 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 <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe