Wireshark mailing list archives

Re: Subdissector with multiple selection fields needed?


From: Guy Harris <guy () alum mit edu>
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:
EISS

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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


Current thread: