The Rules section defines rules for what is called "autotraversal". Autotraversal is the process of switching from one decoder to the appropriate decoder for the protocol at the next layer. In some cases, one protocol always follows another but, in most cases, data in the current-layer protocol must be used to determine which of several possible protocols comes next. A few examples should make this concept clear.
Here is a fragment from ip.personality relating to IP. IP is an obvious case study since a large number of protocols can be used at the next layer.
The rule is defined by the three items in each entry in the list. List items are separated by commas, and there should be no spaces between list items. The rule is processed until a space, tab, or paragraph character appears. Anything after a space, tab or paragraph is treated as a comment and ignored for autotraversal purposes.
However, the "Port Assignment Display" section is used to display protocol names on the port assignments tabs in the "Set Initial Decoder Parameters" dialog. This entry follows a space or tab character after the rule definition, and must be in the form of:
<this-protocol name><space><dash><space><next-protocol name>.
In the rule definition, the first two items are decoder IDs. In particular, 0x7f000401, as you might guess, is the ID for IP. The other IDs are for protocols that may follow IP. The third number is a key that links the two. Specifically, this key is a value that may be returned by the NextProtocol method in IP. In this case, it is actually the value extracted from the PROT field of the IP header, a code that directly identifies the next protocol. A value of 1 means the next protocol is ICMP and, if you look in the ICMP decoder, you will see that it has an ID of 0x7f000407. Hence, the first rule.
Once a layer in a stack has been decoded, the NEXT_PROTOCOLl method for that layer is invoked. The result, together with the ID of the current protocol, is used to search the rules table for an entry that will determine which decoder to use next. As this implies, a key need be unique only within the set of entries for a particular protocol. You might look at a rule in the following way:
<this-ID>,<next-ID>,<key>
means:
if the ID of the current protocol is <this-ID> and the value returned by its NextProtocol method is <key> then the next protocol is the one with ID <next-ID>
What happens if there is no match in the rules table for a given ID and key combination? This does not necessarily imply that anything is wrong; it just means that there is no decoder for the next protocol. It was noted that over a hundred protocols could follow IP. However, examination of a current ip.personality will reveal far less than one hundred entries - many decoders have not yet been written.
Another example entry from async.personality is:
0x7f000303,0x7f000302,ALWAYS
As you would guess, the keyword ALWAYS means that the protocol with ID 0x7f000302 (which happens to be PPP) always follows Async PPP (ID 0x7f000303).
In many other examples, you will see that the second decoder ID and the key are the same. All the entries for TCP are like this, as in:
0x7f000404,0x7f00040a,0x7f00040a
where the second ID happens to be for NBSS (NetBIOS Session Services). The point is that the key can be anything that happens to be convenient. With TCP, the actual decoder ID serves well since the protocol is determined by looking up a port number, see Port Assignments.