Wireshark-dev: Re: [Wireshark-dev] Subdissector with multiple selection fields needed?
From: Guy Harris <[email protected]>
Date: Mon, 12 Jul 2010 22:19:07 -0700
On Jul 12, 2010, at 7:11 PM, Weston Schmidt wrote:

> I've got a protocol that I'm dissecting that has 3 fields that define which subdissector should be called.  How should I enable the selection in a 'Wireshark' friendly way?

There's no mechanism for using anything other than an up-to-32-bit integer, or a string, to directly select a subdissector.

> 3 Fields I need to merge into 1 for sub-dissector selection purposes:

An "ETV integrated signaling stream", as per CableLabs spec OC-SP-ETV-AM1.0-I04-070921?

If so, then an EISS section contains an application_identifier, which "identifies the application according to DVB-MHP section 10.5".  DVB-MHP is ETSI TS 101 812, which says that an application identifier has:

> org_id (4 bytes)

organisation_id: This 32 bit field is a globally unique value identifying the organisation that is responsible for the application. These values are registered in ETSI TR 101 162 [10]. Values of zero shall not be encoded.

> app_id (2 bytes)

application_id: This 16 bit field uniquely identifies the application function. This is allocated by the organisation registered with the organisation_id who decides the policy for allocation within the organisation. Values of zero shall not be encoded.

> trigger_table_id (2 bytes)

So which field is that?  The ETSI spec doesn't seem to have anything of that sort, and the only 16-bit field in an EISS section, according to the CableLabs spec, is the application_type field.  Is this from some other spec?

At least for the organization ID/application ID pair, that's somewhat similar to an OID and protocol ID in the SNAP protocol, which we handle by having the OID select a dissector table from a table-of-dissector-tables, and using the protocol ID to select a dissector from the dissector table in question.  I don't know whether that would work here or not.

However, I'm not sure how the trigger table ID would fit in there, other than just adding another layer to the tables-of-tables.