The packet parsing is done according to a set of packet entry types. These types can be dynamically defined, and the user can add types to fit his own needs.
To explain what we mean by an entry type, lets take, for example, a TCP packet. It will contain an Ethernet portion: the Ethernet destination address, the Ethernet source address, and a Type field. The type is 0x0800, which means that the packet is an IP packet. Consequently, the IP header follows. The IP header contains a number of fields, and, between them, the 'Protocol' field, which, for TCP, has to be equal with 6, so, the TCP header will follow.
We consider an entry type as portions of the packet header. There is a number of predefined entry types, like Ethernet, IP, TCP, ICMP, UDP, etc. However the user CAN EXTEND THIS SET by adding new types which will reflect his needs.
The entry types are held in the entries.typ file, placed in the Net Analyzer home directory. DO NOT DELETE THIS FILE. It is recommended to have a backup copy of it. If you accidentally loose/modify it, you can always download a copy from http://members.xoom.com/netanalyzer/
The entry types can be edited by using the View/Entries command, from the menu bar, or by pressing the proper button in the toolbar.
Since an entry type represents protocol headers, they are composed by a number of fields. Each field has a type and a number of parameters which depend on its type.
Each entry type may have a set of rules, which will determine the entry type that will follow after the current entry. For example, the IP entry type will have one of the rules as "Protocol = 6 -> TCP", which means that if the Protocol field is equal to 6, than the TCP entry type will follow.
When Net Analyzer does the packet decoding, it starts automatically with the Ethernet data structure. This will extract its fields and place the current decoding pointer after the Ethernet header. Now, if one of the rules placed in the Ethernet entry type is true, the Net Analyzer will try to extract the fields for that entry, and the process will continue until there is no rule satisfied for the last entry type extracted.
Again, the user may extend freely the number of types. This makes Net Analyzer a very extensible tool, useful in the development phase of the protocols, and not only.
Use the View/Entries command from the menu, or the Entries button in toolbar. In the dialog box that will appear the user can add, delete or edit the entry types. Each entry type has associated a name, an icon, a list of fields and a list of rules.
When the user edits or adds a new rule, the entry dialog will appear:
This allows the user to edit any components of the rule. In the image is presented the dialog for the IP entry type.
The user may change the name or the icon of the entry type, add/delete/edit a field or a rule. For adding/editing the rules, the field dialog will appear.
After adding a new entry is important to 'link' it by adding a rule in the entry type that will create your new entry header. For example if you add an entry for an application over the TCP, that runs on port 700, you should add two rules in the TCP entry type: 'Source Port = 700 -> My Entry' and 'Destination Port = 700 -> My Entry'.
Integer types - the
field represents an integer of 8, 16 or 32 bits. Normally, to get the real value of
the field, the program makes the conversion from network byte order to host byte order.
However, the user may skip this, if the configuration string contains the character '@'.
For this type of fields, the configuration string can specify strings that will displayed when the field takes certain values. For example, the Protocol field in the IP header, can have a configuration string like: "1 ICMP, 6 TCP, 17 UDP, 89 OSPF", which means, that if the field has the value of 1, the associated string is ICMP, etc.
"Bits" types - the
field represents a series of bits, not exceeding a length of 8, 16 or 32 bits. The adjacent
bit fields, should be grouped together in order to determine their encapsulation size.
For example if there is a field of 3 bits followed by one of 13 bits, both should be declared as
Bits on 16 bits mask,
NOT as Bits on 8 bits mask and Bits on 16 bits mask.
This type of fields have some more characteristics. The mask is used to obtain the value bits of the field. (In our example would be 1110000000000000 = 0xe000, and 0001111111111111=0x1fff ). The field should contain also the number of bits to shift to obtain the value. (In our example would be 13 and 0 respectively ). It can contain, also, a value to be used to multiply this shifted value in order to obtain the "real" value. This is usually 1, but for fields like the Header Length, in the IP entry type, it should be different.
The configuration string can be used for the flag fields to specify the string values which correspond for each bit in the field. See, for example, the TCP field Flags.
Block Fixed Size - this is useful for
a block of bytes with fixed size. The size is another parameter for this field type.
This type will keep the network byte order.
Block Variable Size - this is used for a block
of bytes which has the length determined by other field in the entry type. The Options
field of an IP packet has the length determined by the Header Length value, from which
we should subtract 20. The last value is the modifier, that is also used to determine the
length of the field being added to the value of the associated field.
IP Address - this represents an
IP address.
Ethernet Address - this represents an
Ethernet address.
String - this represents, a sequence charaters.
This will be NULL terminated, if the Configuration String contains the sequence '\0', or,
otherwise it will be ended by the first character in the Configuration String. If this one is empty,
the string will end at the end of the packet.
The Entry Name should be a valid entry type name. THIS SHOULD BE EXACT THE SAME NAME OF AN EXISTING ENTRY TYPE, else nothing will be created.
The condition is composed from by a set of sub-conditions (sub-rules). The condition is true if all the sub-conditions are true. A sub-condition (sub-rules) is a logical expression between the value of one of the fields from the current entry and a constant value, or the value of another field.
The number of entries to be created can be constant (usually 1), of dynamic, depending on the value of a field in the current entry.