> I had contemplated that, but... I guess I don't like the concept of
> having "too many" fields, especially when they are basically the same
> thing but just different sizes (because we're supporting multiple
> standards).
Hmm.
I'd assumed that they *weren't* the same thing, in which case you'd
*want* separate fields.
But if they *are* the same thing, with just the size and bit-position
being different, a feature was put in a couple of releases ago, for the
benefit of X.25, which has the same problem - X.25 traffic can either be
"mod 8" or "mod 128", and some of the bitfields in the X.25 header
correspond to different bits for "mod 8" and "mod 128" operation.
What you can do is to have *three* fields, all with the name "mtp3.sls",
with one having the right layout for the ITU style, one having the right
layout for the 5-bit ANSI style, and one having the right layout for the
8-bit ANSI style. (Is this yet another case of "us Yanks vs. the rest
of the world"? Sigh....)
In "proto_register_x25()", for example, we have entries such as
{ &hf_x25_p_s_mod8,
{ "P(S)", "x.25.p_s", FT_UINT8, BASE_HEX, NULL, 0x0E,
"Packet Send Sequence Number", HFILL }},
{ &hf_x25_p_s_mod128,
{ "P(S)", "x.25.p_s", FT_UINT8, BASE_HEX, NULL, 0xFE,
"Packet Send Sequence Number", HFILL }},
and the X.25 dissector puts the field into the protocol tree using
"hf_x25_p_s_mod8" if it's a mod-8 connection and "hf_x25_p_s_mod128" if
it's a mod-128 connection.
You can filter on, say, "x.25.p_s == 3", and it'll correctly match
packets with a P(S) field with a value of 3, regardless of whether the
packet came from a mod-8 connection or a mod-128 connection.
> But, obviously I'm fairly new to Ethereal development, so I don't know
> what the convention is in this type of situation.
The convention is as described above.
