Andrew Schweitzer wrote:
Should I use field arrays? That seems like an awful lot of fields (100 *
about 10) to add to the protocol's field list.
Does each of the 100 packet types have fields that appear in no other
packet type? If so, then, yes, that's a lot of fields, but that's how
we do it in other protocols.
Can you add a field list to a subtree?
What do you mean by "field array" and "field list"? Are we talking
about each packet type having about 10 *different* fields, or 10
instances of the *same* field, e.g. a protocol with a request to get a
list of IP addresses from the other machine and a reply containing the
IP addresses wouldn't have "proto.reply.ip_addr_1",
"proto.reply.ip_addr_2", "proto.reply.ip_addr_3", etc. fields, it'd just
have several instances of "proto.reply.ip_addr".
I see that NBNS defines multiple protocols.
No, NBNS is one protocol, not multiple protocols.
The file named "packet-nbns.c" contains dissectors for multiple
protocols, but that's for historical reasons, as the comment at the
beginning of the file says; one could argue that there should be
"packet-nbns.c" with the NBNS dissector, "packet-nbds.c" with the NBDS
dissector, and "packet-nbss.c" with the NBSS dissector. Those are three
different protocols, even though they're all defined by the same RFCs
(1001 and 1002).
Should I define a different protocol for each message type?
No. You said "*a* proprietary protocol", so it's just one protocol.
That also seems excessive.
Not only would it be excessive, it would be the wrong thing to do.