Analyzer: a public domain protocol analyzer

Analyzer is a full configurable network analyzer program for Win32 environment. Analyzer is able to capture packets on all platforms (and link-layer technologies) supported by WinPcap.

This program is current being developed at Politecnico di Torino; main contributors include Loris Degioanni, Paolo Politano, Fulvio Risso and Piero Viano and it is released under a BSD-style licence.

This work has been partially sponsored by Microsoft Research.

WARNING: Analyzer is a tool that is still under development. Please be patient when you use it.

 Release 2.1, 15/11/00

[Docs]

[Credits]

[Protocols]

[History]

[Help!!!]


Analyzer documentation

User's manual

  • Graphical User Interface manual: Menus, Dialog Windows, Wizards
  • How To... : tricks and tips of the common tasks in Analyzer

Advanced User's manual

  • Introduction to Analyzer
  • Description of the main components
    • Protocol parsers (PDF, DFF, IFF)
    • Other parsers (LFF, STT, MAC)
    • Query: the Analysis engine
    • Graphical Plug-ins
  • Parsers: syntactic and lexical levels of the grammars used by Analyzer
    • Protocol Definition Format (PDF)
    • Description File Format (DFF), Index File Format (IFF)
    • Log File Format (LFF)
    • Filters and statistics expressions (STT)
    • Macro (MAC)
  • Analyzer Folders organization
  • Configurations files
    • Tables.dat
    • The INI files
      • Analyzer.ini
      • Query.ini
      • Plug-ins INI files: each plug-ins has its own configuration file whose name coincides to the plug-in name. These files contain the settings specific to the plug-ins (such as the font size, ...). They are saved in the folder iniplugin contained in the plug-in folder indicated by Analyzer.ini.
  • How to:
    • Add a new protocol to the supported ones
    • Define a new capture file format

Developer's manual

Miscellaneous

  • The past development process: some words about the Analyzer development in the past and some of the choices that made it working


Graphical User Interface Summary

Graphical User Interface

Please click on the menu voices below to obtain their description.

Most important dialog windows:

  • Begin Capture Dialog Window
  • Advanced Capture Settings Dialog Window
  • Select Filter Dialog Window
  • Statistics / Monitoring Settings Dialog Window
  • Protocol Configuration Dialog Window

Most important wizards:

  • Create Expressions Wizard
  • Capture Filter Wizard

Graphs (the display modes): each plug-in has its own-specific settings. Here there are these options:

  • Bar graph Settings
  • Column Graph Settings
  • Pie Graph Setting
  • Simple Pie Graph Settings
  • Scrolling Line Graph Setting: it represents the last 128 samples which are captured during a real time session (Monitoring or Statistics). This graph can not be used to create tables.
  • Line Graph Settings: it is not available during real time sessions. It can represents table; the table columns are relative to the lines, the table rows define the lines behavior.
File
Open
Close
Save
Save As
Save Index
Print
Print Preview
Page Setup
Printer Setup
Recent File List
Exit
Edit
Undo
Cut
Copy
Paste
Delete
Find
Find Next
Replace
Select
Select All
Remove Selection
Invert Selection
Packets
4 Go to
First
Previous Filtered
Previous
Next
Next Filtered
Last
4 Order By
Number
Time Stamp
Dest. MAC
Src. MAC
Layer 3
Description
First Protocol
Macro
Refresh Index
Capture
New
Begin
Statistics
New Statistics
New Monitor
Stop
Suspend Visualization
Resume Visualization
Display Historical Data
Selected Field Extraction
Mac Statistics
Data
Display Settings
Change Display Mode
Copy Data
Setup
Protocol Def.
Set Default Adapter
Open Capture Copy
Capture Association
4 Font
List Window Font
Tree Window Font
Row Window Font
Printer Font
4 Clipboard
Text
Packet
View
4 ToolBar
Editor
Analyzer
Status Bar
4 Tree View
Expand
Collapse
Protocols
Window
Cascade
Tile
Arrange Icons
Close
Open files list
?
About Analyzer

.

.

.

.

.

.

.

.

.

.

.


How To...

  • Capture packets from the network
  • Open an existing capture file
  • Set a filter for the navigation through the packets list
  • Save the capture document in html format

How to capture packets

Selects Begin from the Capture menu. The Begin Capture Dialog Window will be opened.

Capture starts when pushing on the start button; captured traffics is saved into an ACP file. Then the analysis engine (the query program) opens the ACP file, it creates a text file which represents the capture session; then it passes the text file to the interface which shows the final product.

How to open a capture file

  1. Click on the voice Open in the File menu.
  2. Look for the capture file name; in the folder Samples\Capture there are some examples (folder Samples\Dumpfiles contains some captures saved by other tools like SnifferPro) saved in ACP format. The analysis engine used by Analyzer saves the Capture documents in the ACP format only.

Anyway Analyzer can recognize automatically the other formats of the capture files but on condition that their extensions were defined through the dialog 'Capture definitions and file extensions associations' (menu voice: Setup/Captures/Capture Association). In this dialog the user can define:

  • The name of the format: for instance File NetXRay is the format used by the network analyzer NetXRay in order to save the capture files.
  • The file extension: for instance the NetXRay file have the .cap extension. So Analyzer considers every file with .cap extension as a NetXRay document.
  • The relative LFF file: the configuration file which describes to the Analysis engine the new capture file format.

N.B.: Analyzer can display the capture files created by WinDump and tcpdump, on condition that the capture files have the ACP extension.

Making easy the navigation through the packet list

In order to make easier the navigation through the packets list, shown in the first pane, Analyzer has the functionality of setting a filter; for instance you can set the expression 'IP' as filter, so you can navigate only through the IP packets; anyway the filter expressions can consider a lot of packet characteristics.

The filter is set through the window 'Select Filter dialog Window' (Select voice in the Edit menu): the packets satisfying the expression are also selected; the navigation through the filtered packets is controlled with the buttons [image] [image] .

Saving a capture file in html format

The capture file saved in the html format appears as it appears in the Analyzer interface; click on 'Save as' button and select the html format in the formats list; then try to open the saved file with a browser.

In the folder html there some files (java script and gif) which are used to generate the html output.


Protocols

Protocols recognized by Analyzer

This section lists the protocols which Analyzer recognizes using as configurations files (PDF, DFF, IFF) the distributed ones. The protocols description is done following the hierarchical structure of the ISO-OSI model.

NOTE: protocol fields whose length is unknown have a gray background.

  • Level 2 protocols
    • MAC: 802.3, Ethernet v.2.0
    • Token Ring

    • LLC: (standard), LLC/SNAP

  • NetBEUI

  • TCP/IP Stack: level 3
    • IPv.4, IPv.6
    • ARP

    • ICMP, ICMPv.6

  • TCP/IP Stack: level 4

    • TCP, UDP

  • TCP/IP Stack: routing protocols

    • RIP (Version 1 and 2), IGRP, EIGRP, OSPF, BGP

  • TCP/IP Stack: application level protocols
    • DNS
    • Protocols over UDP (Daytime, Trivial FTP (TFTP), Bootp, RWHO, NFS, NetBIOS, RTP, RTCP)
    • Protocols over TCP (Daytime, FTP, Telnet, SMTP, Gopher, Finger, WWW (http), POP, NNTP, X-Windows, NetBIOS)
  • Novel IPX Stack
    • IPX
    • RIPX
    • SAP
    • SPX
    • NCP
  • Other protocols: there are other supported protocols; however they are not listed here.


Analyzer Help

Help!!! (part 1)

Before starting crying that something is wrong, please read carefully these notes:

1

Supported Platforms All the platform supported by the WinPcap drivers. Basically, Windows 95/98 and NT/2000. Windows ME is not supported.

2

Hardware compatibility Basically, Etherenet is well supported. Token Ring and FDDI should be supported as well; dial-up adapters are usually unsupported. Since this feature depends on the WinPcap library, more details can be found at the WinPcap home page.

3

Problem with selecting interfaces These are not problems of Analyzer. Analyzer uses WinPcap for that. Please refer at the WinPcap home page.

4

Problems with the help. Analyzer uses Microsoft extensions to show HTML helps. If these extensions are not present in the system where Analyzer will be installed (they are available in any system where is present Microsoft Internet Explorer 5.0) you must install them. They are downloadable from the Microsoft web site (click here for more details).

5

Source code download Analyzer is a public-domain software but it is not an open-source tool. Source code can be released only to people who have a *strong* interest in collaborating to our project.

6

Protocol Dissectors We are rewriting the analysis engine. We do not guarantee that the present syntax of DFF, IFF and PDF files will be maintained in the future. In case you want to add a new protocol, please send us:
  • the dissector
  • a capture file in order to test it properly in the future

7

Documentation We are not native speakers. We apologies for the English translation that contains several mistakes.

If you require some more information, please >> follow this link >>.


Credits

In this Section we would thank people who, directly or indirectly, collaborated to the Analyzer project writing part of the source code.

Main contributors:

  • Loris Degioanni, a great contributor particularly on the low-level part of Analyzer (filtering, capturing). The work has been done as part of its graduation thesis at the Politecnico di Torino
  • Paolo Politano, who continued this project. Mainly responsible for bug fixing (release 2.02) and monitoring / new statistical module. The work has been done as part of its graduation thesis at the Politecnico di Torino
  • Piero Viano, who started this project. The work has been done as part of its graduation thesis at the Politecnico di Torino
  • Fulvio Risso, the supervisor, bug-checker, beta tester, programmer....

Part of the old source code has been developed, several years ago, by Gaetano Borgione and Cristian Estan.

Here a list of people who collaborated sending us some material:

  • Schultz, Dale C., D.Schultz@telesat.ca

  • Nelson B. Bolyard, nbolyard@home.com

Special thanks to Microsoft Research, which sponsored this work.

Bibliography

[1] The WinPcap project, Politecnico di Torino. Available at http://netgroup-serv.polito.it/WinPcap.

[2] Bison: GNU Project parser generator; Bison is a parser generator in the style of yacc. It should be upwardly compatible with input files designed for yacc.

[3] Flex: fast lexical analyzer generator; flex is a tool for generating scanners: programs which recognized lexical patterns in text. flex reads the given input files, or its standard input if no file names are given, for a description of a scanner to generate. The description is in the form of pairs of regular expressions and C code, called rules. flex generates as output a C source file, lex.yy.c, which defines a routine yylex(). This file is compiled and linked with the -lfl library to produce an executable. When the executable is run, it analyzes its input for occurrences of the regular expressions. Whenever it finds one, it executes the corresponding C code.

[4] MFC Library Reference

[5] The Protocols.Com web site, a must for anyone that want to decode protocols. Available at http://www.protocols.com


Analyzer History

Downloads Summary

The number of downloads is approximated, due to the fact that several sites around the world are offering this tool. The number of downloads from our server is:

  • Version 2.1 (15 nov 00 - /): not available (check at the counter on the home page)
  • Version 2.02 (29 mar 00 - 14 nov 00): ~120.000
  • Version 2.01b (11 oct 99 - 29 mar 00): ~ 12.000
  • Version 2.01 (31 mar 99 - 10 oct 99): ~5.000

Releases Summary

Version 2.1, 15 nov 00

  • Get rid of older piece of code; started the migration to a new analysis engine based on WinPcap
  • Real-Time monitoring implemented
  • Summary statistics improved
  • Graphical interface improved
  • Support for new dynamic drivers (WinPcap)
  • Code cleaning
  • Bug fixing

Version 2.02, 30 mar 00

  • Updated platform support (along with the new WinPcap release)
  • Exporting HTML files
  • New revisited graphical interface
  • Bug fixing

Version 2.01b, 11 oct 99

  • Minor release
  • Bug fixing
  • a new interface with WinPcap (instead of using WinDump)

Version 2.01, 31 mar 99

  • First version released on the web
  • It included WinDump as the capture tool
  • Quite plenty of bugs


Copyright notice

Copyright

Copyright (c) 1998, 1999, 2000, Politecnico di Torino. All rights reserved.

Redistribution and use in binary forms, with or without modification, are permitted provided that:

  1. distributions including binary code include the above copyright notice and this paragraph in its entirety in the documentation or other materials provided with the distribution
  2. all advertising materials mentioning features or use of this software display the following acknowledgement:
    ``This product includes software developed by the Politecnico di Torino, and its contributors.''

Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.


Configuration files used by Analyzer

The analysis engine (Query program) uses five types of configuration files:

  • Log File Format (LFF): the format of the capture files which are readable by the Analysis engine is settable through the LFF file (Log File Format). This file describes the structure of the formats of the capture files to the analysis engine. So the analysis engine, setting the right LFF file, can read each type of capture file whatever its format may be. For instance Analyzer uses a capture engine which creates capture file with the ACP format; NetXRay uses a capture engine which creates capture files with a 'NetXRay format'. If we want to read a NetXRay capture file with Analyzer we have to describe its format to the analysis engine. This operation is done giving to the analysis engine a LFF file which describes the new format.
  • Protocol Definition Format (PDF): it is possible adding new protocols to the supported ones; this operation is done through the PDF file. This file describes the fields organization of the new protocol and so it makes the Analysis engine able to decode the packets of the new protocol.
  • Definition File Format (DFF), Index File Format (IFF): the definition of the output texts created by the Analysis engine are defined by these files. Then the interface receives these texts and presents them in more friendly way.
  • Statistics (STT): they describe to the analysis engine the statistics which have to be evaluated on a capture file.
  • MACro Files (MAC): they contain an instructions series for the analysis engine.

All the listed files, save the ACP file, are text file so you can edit them through a text editor. Besides all the files, but the STT file, does not need end row types or a particular string organization, so you can page them as you want.

DAT files

Then there is a list of DAT files which are stored in the folder 'Data'; all the following files, but Tables.dat, are directly used by Analyzer interface.

  • Cap_fltr.dat: the filter list which is presented by the dialog used to set the capture filter (select filter dialog). Filter syntax is the one of WinDump (http://netgroup-serv.polito.it/WinDump/).
  • Exts.dat: the LFF files presented by the dialog 'Capture definition and file association' (menu: Setup/Captures/Captures Association).
  • Filters.dat: the filter list presented by the dialog which sets the filter used to select the packets (select filter dialog).
  • metering.dat: the filters list presented by the dialogs 'Monitoring Settings' and 'Statistics Settings'. It is a text file; the syntax:
[filter_group_name] //indicates the folder where the following listed filters are grouped
filter_description,filter_name, //the filter syntax is the one of WinDump
  • Tables.dat: it includes several constants used by the parsers; these include a list of Ethertype, protocol type, and others.

INI files

  • Analyzer.ini: used by the analyzer interface.
  • Query.ini: used by analysis engine.
  • Graphs INI files: used by graphs files.


Folders organization

The Analyzer pack is organized in the following way:

Analyzer.exe |  |  | Main executable file
Query.exe |  |  | Analysis engine executable file; console application
DdReader.exe |  |  | Executable file for parsing DFF, IFF, MAC files
Fdreader.exe |  |  | Executable file for parsing LFF files
PdReader.exe |  |  | the executable file for parsing PDF files
Analyzer.ini |  |  | Analyzer's startup and configuration file
Query.ini |  |  | Query's startup and configuration file
Conf\ |  |  | It contains all the configuration files used by Analyzer in order to work. The files are stored in the following sub-folders:
 | Data\ |  |
 |  | Cap_fltr.dat | Capture filters
 |  | Exts.dat | Association between LFF files and the correspondent file extension
 |  | Filters.dat | Off-line filters
 |  | metering.dat | Metering filters
 |  | Tables.dat | Data used in the printing process
Dumpfiles\ |  |  | It contains LFF files with the definition of some external file format understood by Analyzer.
Html\ |  |  | It contains some files (gif and javascript) that are used to create the HTML output (file - save as)
Objects\ |  |  | It contains the object files (.pdo, .dfo, .ifo, .lfo, .mo) that are used by the analysis engine to read the packets. For example, when the user compile for instance a new LFF file the relative object is saved with the name default.lfo in this folder. This folder must not be modified by the user.
Protocols\ |  |  | It contains the protocol configuration files sources (PDF, DFF, IFF).
Samples\ |  |  | It contains some samples that can be used by Analyzer.
 | Captures |  | Some capture files
 | Dumpfiles |  | Some example of captures made by other software and saved in different formats (not .acp).
 | Macro |  | Some example of macro files.
 | Statistics |  | The statistics files of the list presented by the dialog 'Choose statistics evaluation' (menu Statistics/Evaluate Statistics)
Plugin\ |  |  | It contains all the graphical plug-ins that are used by Analyzer. The plug-ins list presented in the dialog 'Real Time Statistics Settings' is built by listing all the plug-ins saved in this folder. Programmer does not require to recompile Analyzer when adding a new plug-in.


Introduction

Analyzer is a packets capture tool; it captures packets from network and it displays them through a graphical interface. The user can choose the network adapter (used for the capturing and monitoring process), specify an appropriate filter, select, copy and paste packets. Advanced features concern both the possibility to make (and plot) some advanced statistics on the captures packets and to plot statistics in real time (number of packets flowing through the network and so on).

Here it is a snapshot of the Analyzer interface:

The first window shows the packet index: it is the list of the packets belonging to the capture document. The window on the left shows the packet selected in the packet index; this packet is shown through a tree view; by expanding the branch you can see the packet fields. The window on the right shows the hexadecimal ("raw") view of the selected packet.

Analyzer structure overview

Analyzer is made up of several components:

  1. A graphical interface, used for an user-friendly interaction.

  2. A low-level packet capture library, used to capture packets, monitor network traffic. Analyzer uses the WinPcap library for that, a packet capture library developed at Politecnico di Torino; It main goal was to capture packets from the network and to create the capture file. Recently-added extensions include the possibility to set monitoring filters on network traffic (WinPcap statistic mode). We plan to insert these capabilities on off-line captures as well.

  3. A legacy program, Query, that is a remaining of older versions of Analyzer. Query it is a standard console application which receives command lines and produces text lines as output; and it is located into the Analyzer folder; the commands help is available launching the command line 'help'. We hope to be able to replace this program with new ones soon. Query aims at:

    • read capture files created by Analyzer (aka. WinPcap); these files are interpreted by a special code (dynamically created) in order to decode packets, display protocols in the graphical interface. For instance, when the graphical interface asks Query for the packet number 34, then Query looks for the required packet in its packets list and returns the dump of the packet. Then it will interpret the packet and all the protocols contained in there, then the interface will format properly the text output in order to make it looking good. We plan to move this feature out of Query by creating a new external program (much more optimized) that will be able to do this;

    • provide off-line statistics on the capture files .We plan to move this feature in WinPcap soon.

  4. Parsers: they are external programs that take text files as input and they generate "pseudo-code" used to interpret and display packets. For instance, protocol description is given in a special file (a PDF file, Protocol Description Format) that is dynamically recompiled in order to be used by the analysis engine. This "dynamic compiler" is one of the parser used by Analyzer.

  5. Graphical Plug-ins: they are standard Windows DLL that aim at displaying graphics coming from the statistical and monitoring output. This part is completely customizable and the user can add its own graphics without recompiling Analyzer.

A general schema about the interactions among the components of Analyzer is given below:

Query is the Analysis engine, it reads the capture file created by the Capture engine (based on the WinPcap library); Query needs some configuration files (indicated in the figure with their abbreviations which are also their extensions) in order to read the capture file. These files describe: the format of the capture file (LFF - Log File Format), the protocols structure (PDF - Protocol Definition Format), which kind of information have to appear in the index of the first panel in the Analyzer window (IFF - Index File Format), the structure of the packet description which appears in the second panel (the tree view panel) (DFF - Definition File Format). These files are ordinary text file; an advanced user can modify these files in order to add a new protocol to the supported list or to enable a new capture file format recognition created for instance by an other network sniffer. Query does not directly receive the configuration files; it receives their object files created by three parsers which are applications separated from Analyzer. So Query has all the information to read the capture file and to create the output which is composed by text lines; these text lines contain all the information which are shown by the three panes of the graphical interface: the packets index, the packets description and the hexadecimal packets structure. For instance when the user clicks on a packet in the index the graphical interface requires to Query the description of the selected packet and then it uses the text description to update the second and the third panes. The configuration files names used by Query are settable through the graphical interface.

The capture engine is implemented calling the functions defined by the WinPcap library which is included in the interface project. Through these function the interface sets the capture parameters (Adapter, file name where the capture is stored, capture filter, number of packets which have to be captured,...) and launches the capture. The capture file, which is created using the ACP format, is passed to the Analysis engine which reads it.

Besides the interface uses the WinPcap in order to show, in real time, the network traffic situation. Through the interface the user can set which type of traffic has to be monitored, then the choosen parameters are sent to WinPcap through the pcap_xxx functions calls. The results of the network monitoring are directly returned to the interface which shows them through the graphic engine.

The graphic engine is implemented through a group of DLL files - the plug-ins - which are stored in a folder reserved folder. Each plug-in represents a graph (pie, column, line,...); it receives from the interface the data which have to be represented and the 'device context' where the graph has to be drawn.


Other parser in Analyzer (LFF, STT, MAC)

There are other parser used by Analyzer. Most of the way they work are shared with the protocol parsers (interaction with Query and so on). Following there is a brief description of these components.

Definition of the dumpfile format (LFF: Log File Format)

There are several program for network analysis and capture, each one with its proprietary dumpfile. LFF files are used to describe the format of each dumpfile in ordr to allow to import files created with different programs. Even if LFF is a generic description format that can be used to import and export files, Analyzer does not allow exporting files with different formats; only importing is permitted.

Each dumpfile format that has to be interpreted needs its own LFF file that is interpreted by a specified parser in order to create an object (.LFO) file. This object is executed by Query in order to make the read file "compatible" with the Query native format (that is .ACP). This parser is case insensitive.

This parser can be launched either by Analyzer or manually:

fdreader INPUT.LFF OUTPUTFILE.LFO

The LFF file structure is based on the characteristics which are common to each possible format of a capture file:

  • In each format there is an header of the file.
  • Each packet in the file has an header.
  • Each packet in the file has a trailer and, probably, there is a trailer at the end of file.

On the base given by these characteristics here it is the LFF structure which defines the format of the capture file:

  • The capture file header definition.
  • A series of definitions of the types of the elements which belong to the capture file; each definition is composed by:
    • The element header definition.
    • The element trailer definition.
  • The capture file trailer definition.

The definition of the fields in the LFF files follows these rules: a field definition is composed by a name and a type. The name is composed by a letter (or the char '_') followed by less then 50 alphanumerical characters.

The characters can be defined as:

  • BYTE: 8 bit
  • WORD: 16 bit (2 BYTE)
  • DWORD: 32 bit (4 BYTE)

The BYTE and the WORD are interpreted as sign-less integer and their highest values are: 255 and 65535. The DWORD are interpreted as integer with sign on 4 bytes. Their range is (-2147483648 , 2147483647).

The name of the expressions have to be defined in the structure which precedes the expression.

Here it is, as example, the LLF file which defines the ACP format:

1:  HEADER
2:	DWORD Magic
3:	WORD MajorVer
4:	WORD MinorVer
5:	DWORD thiszone
6:	DWORD snaplen
7:	DWORD sigfigs
8:	DWORD caplinktype
9:  ENDHH
10:	MUSTINVERT : (Magic!=0xa1b2c3d4)
11:	LINKTYPE : caplinktype

12: PHEADER
13:	DWORD Secs
14:	DWORD USecs
15:	DWORD PckLen
16:	DWORD TLen
17: ENDPH
18:	PLEN:PckLen
19:	LEN:TLen
20:	TYPE:128
21	CHECK:1
22:	FIRSTPROTOCOL:"MAC"
23:
24: PTRAILER
25: ENDPT

26: TRAILER
27: ENDHT

In the rows (1->10) there is the header file definition. An header file starts with the keyword 'HEADER'. Then there is a series of fields definitions. The fields definition ends with key word 'ENDHH' (look at the row 10, END Header Head).

Then there is the key word 'MUSTINVERT'; if this expression returns a value different from 0 when it is tested then all the integer are read in the opposite direction. For instance the hexadecimal integer 0xa1b2c3d4 becomes 0xd4c3b2a1. In the next row there is the key word 'LINKTYPE followed by the char ':' and by a valid expression. The expression caplinktype indicates the network type from which the packets were captured; the expression returns a value defined link type identifier in the ACP format.

Rows (12->25) define a possible packet type. We can find more then one definition like this in the same file. So the LFF file defines all the elements which belongs a format. For instance in the LOG file there are five elements types.

A packet header starts with the key word 'PHEADER'. Then there is a series of fields definitions. The fields definition ends with the keyword 'ENDPH' (END Packet Head). Then there are some compulsory clauses and some optional clauses. It is very important to respect a particular order in clauses declaration. The obligatory clauses are composed by a key word and by the char ':'; here it is the list of the valid key words (the order in the list is also the order of the declaration):

  • PLEN
  • LEN
  • TYPE
  • CHECK
  • FIRSTPROTOCOL

The first four clauses are followed by a valid expression while the last clause is followed by a string. The clause PLEN (Packet LENgth) indicate the packet length which is present on the disk. LEN (LENgth) indicates the real length of the packet. TYPE returns an integer which indicates the type of the packet. The most important clauses are CHECK and FIRSTPROTOCOL. This last clause allows to establish from which protocol the packet analysis will start. CHECK is used to determine which is the type of the element.

The optional clauses as the obligatory clauses are composed by a key word, by the char ':' and by a valid expression; here it is the list of the optional clauses:

  • SECS
  • USECS
  • WRITTEN
  • DISCARDED

Also these clauses have to be declared in the order specified by the list, but you can introduce in the file the clauses that you want.

SECS allows to set the second number of the timestamp; USECS allows to set the microsecond number of the timestamp. If these clauses are not set the timestamp value is equal to the last set value. WRITTEN allows to set the number of the packets written since the last statistics report. DISCARDED allows to set the number of lost packets since the last notification.

A packet trailer starts with the keyword 'PTRAILER'. Then there is a series of fields definitions. The fields definition ends with the keyword 'ENDPH'.

In the rows 27 - 28 there is the definition of the final string of the file. A final string starts with the keyword 'TRAILER'. Then there is a series of fields definition; this series ends with 'ENDHT'.

You can have more information about LFF format looking at:

  • the grammar page.

Statistics files (STT: STaTistics files)

The statistics files are used by the analysis engine to evaluate statistics on capture files. They usually have the extension STT (STaTistics). They describe the statistics which have to be evaluated.

These files, which are text files, need empty row in order to separate the different sections. STT is case sensitive except for the part involving protocols fields / protocol names.

Here is an exmple of an STT file.

UseSemigraphicCharacters=no
ReportFrameCount=yes
ReportFrameRate=yes
ReportFramePercentage=yes
ReportByteCount=yes
ReportByteRate=yes
ReportBytePercentage=yes
ReportFrameSize=yes
ReportTotals=yes
ReportAverages=yes
ReportMaximums=yes
ReportMinimums=yes
ReportExtremeFramesizes=yes
ReportJustFinal=no

LengthOfInterval= 0 0 5
ExcludedFrames=GetVMVar ("FrameSize")=CantTell
DefaultLengthParameter=GetVMVar ("FrameSize")

GroupName=Broadcast_MAC
OutCap=
Predicate=MAC.DS1==0xFFFF && MAC.DS2==0xFFFF && MAC.DS3==0xFFFF
LengthParameter=GetVMVar ("FrameSize")
(...)

The first section contains a list of keywords which are set with 'yes' or 'no' in order to decide which parameters values have to be reported in the results table. The key words order is fixed and all the key words have to be written. The lines and the blank spaces are ignored; the comment lines start with the char ';' (see the beginning of a STT file). The lines can be at most 120 characters long.

  • UseSemigraphicCharacters: it decides if the table is written using the semi-graphic characters or the ASCII ones.

  • ReportFrameCount: how many frames belongs to the specified group in the specified interval.

  • ReportFrameRate: how many frames per second in the specified interval.

  • ReportFramePercentage: the percentage (calculated on the frames total number) of the frames which belong to the specified group.

  • ReportByteCount: the dimension of the group calculated in bytes.

  • ReportByteRate: bytes per second.

  • ReportBytePercentage: bytes number as percentage.

  • ReportFrameSize: the average of the packets dimension (in the specified group and in the specified interval).

  • ReportAverages: the average values relative to the previous parameters.

  • ReportMaximums: the maximum values relative to the previous parameters.

  • ReportMinimums: the minimum values relative to the previous parameters.

  • ReportJustFinal: only the last three parameters (Averages, Maximums, minimums) are reported.

The next section contains:

  • LengthOfInterval: it sets the updating interval, the selected parameters are calculated on intervals which have this length.

  • ExcludedFrame: this expression defines the frames which are excluded from the evaluation.

  • DefaultLengthParameter: it allows to calculate the frames length.

The next section defines a group, that is basically a filter applied to the input files. User can define several filters (for example "UDP", "TCP") in order to calculate the statistics separately on each subset of the packets. Results will be printed in such a way that these groups can be compared to each others. This sample contains only a group definition but an STT file can contain more then one group.

  • GroupName: the name of the group; it can be at most 15 characters long. It begins with a letter or the char '_' and can contain alphanumerical characters and the chars '_' or ':'.

  • OutCap: (optional) the name of the file where the frames belonging to this group are saved.

  • Predicate: the expression used to decide if a frame belongs to the group

  • LengthParameter: it allows to calculate the frames length.

The expressions are created using the protocols definition saved in the PDF file. The expressions returns a non valid value (a CANTTELL value) if its evaluation is not possible, it returns a zero value (FALSE) if the evaluated packet does not satisfy the expression. A value different from 0 means "TRUE": the packet satisfies the expression. A frame group contains all the packets whose evaluation returned a 'TRUE' value.

The frame size can be calculated using different criteria; for instance the 'LengthParameter' can be set in order to consider only the IP section using the expression 'GetDataLen(IP)'.

The evaluation of percentages requires a total counter which consider the all the frames; if a group is not able to calculate a frame length then a default value is set (DefaultLengthParameter).

For further information look at:

  • Expression description
  • Statistics file grammar

Macro files

These files allows launching by one only command the execution of an analysis engine functions series. The functions series has to be written in the MAC file, then this file has to be compiled (through the dreader parser) in order to create the relative object file (the MO file); then this file is interpreted and executed by the Analysis engine. The MAC file is a normal text file, it does not need end row characters and its parser is not case sensitive. This parser is the same that compiles DFF and IFF files. The packets information contained in their fields are not available from the MAC file because this file is only relative to the Analysis engine management. Besides are not valid the functions calls: GetVmVar, 'CHECK', 'CONV', 'CONV16', 'CONV24', 'CONV32'.

Though the function 'COMMAND' it is possible sending commands to the Analysis engine as if they came from the keyboard; the function syntax is the following one:

COMMAND '(' STRING ')'

'STRING' is common characters string in inverted commas ("command name"); it should represent the name of a valid command. If the string is not recognized as a valid command the function 'COMMAND' returns a value different from 0 (else 0 if it is valid). The macro execution starts from the function 'MACROMAIN', whose prototype is:

DWORD MacroMain ();

This function must be present. It returns a value different from 0 if there are errors during the execution. It can call the other functions of the macro file.

About the file format look at the grammar.


Protocol parsers (PDF, DFF, IFF)

Protocol parsers (PDF, DFF, IFF and others)

Analyzer uses three external parsers that are used to make the protocol parsing/decoding working.

Analyzer executes these parser automatically when

  • user changes the source files (for example the protocol definition, in menu' Setup/Protocol Definition)
  • at launch time (Analyzer controls automatically the coherence of object files with the corresponding source file).

All parsers show an error message is shown if the number of parameters is wrong or it is not possible to open a file; the parser generates no output file and returns a value different from '0' when the parsed file contains some error.

Protocol Definition (PDF: Protocol Definition Format)

PDF file (Protocol Definition Format) defines protocols supported by analysis engine and it is a normal text file. This files is used to:

  • describe the format of each packet (for example: IP has a first field that is 4-bits long called "version", then another 4-bits field called "Header_length", and so on)

  • explain how these protocols have to be demultiplexed (for example: if an IP packet contains code "17" in the "protocol" field, next protocol will be UDP)

This parser is launched by Analyzer when the user either sets or modify this configuration file. This parser can be launched manually as well:

 pdreader FILE.PDF OUTPUT_FILE.PDO

Output file is a "pseudo-code" object file that is used by Query to interpret and decode packets. On other words, Query has a virtual machine in which this object file is executed; Query has to be able to execute these commands and to provide a "friendly" environment for this code.

Protocols will be described in a text file with a particular C-like language (case insensitive), with a small set of data types. Fields definition is given by type + name.

The supported data types are:

BYTE(8) int (0,255)
WORD(16) int (0,65535)
DWORD(32) int (-2147483648,2147483648)

Names format is: a character (or '_') followed by less then 50 alphanumerical types. A field can contain sub fields obtained masking some indicated bits.

field BYTE 01110010
    sub field BIT (2,5) ; this notation means that BIT is given by the
                          bits 2,3,4,5 of BYTE so BIT has the value 1100

A protocol definition starts with the word 'PROTOCOL', followed by a fields series and expressions which ends with 'ENDPR'.

More information about PDF grammar can be found looking at the grammar page.

Display Definition (DFF: Description File Format, IFF: Index File Format)

These files define what has to be displayed on the Analyzer main window: DFF file defines the complete description of the protocol, whereas IFF describes a brief description of the protocol. DFF output (with a proper formatting) can be seen in the Analyzer's second window (the one on the left), while IFF output can be seen in the first window (the one on the top).

There are two different files for the display definition because of the different requirements of them: the top window has limited space so that only the most important information have to be printed (for example IP source and destination address). The left window has more space, so that everything can be printed (for example header length, fragment offset, ...).

This parser can be launched either by Analyzer or manually. In the latter case the syntax is:

ddreader INPUT.xFF OUTPUTFILE.xFP OBJECT.PDO
where the latter if the PDO file previously generated.

xFF parser creates an object file as well: this object file is executed by the analysis engine (Query) and it works after the PDO file finishes its job. In fact the PDO file decodes the packet and set appropriate values for all the protocol fields defined in there. As soon as a protocol has been completely decoded, the analysis engine executes the corresponding DFO and IFO code in order to define how this protocol has to be displayed. Therefore protocols names and protocol fields must have the same name in the PDF, DFF and IFF files and they are mapped by the Query virtual machine in somewhat "global" variables that are created by the PDO and they are accessed by the DFO(IFO as well.

DFF/IFF files share the same parser (case insensitive), therefore they share the same C-like syntax used to define the display definition.

The language has the following characteristics:

  • variables: they are defined by a type and a name, the definitions are done in the function and the types can be:

    • BYTE(8) int (0,255)

    • WORD(16) int (0,65535)

    • DWORD(32) int (-2147483648,2147483648)

    the variables are even initiated at 0. The names are: a letter or the type '_' followed by less then 50 alphanumerical type

  • arrays: they are defined with the word 'ARRAY'; they are a DWORD vector limited to 65535 elements; it is not possible make multidimensional arrays; the array does not immediately occupy the necessary memory to reach the max size, but it grows when the user asks to enter in not yet lodged places. It is convenient to immediately enter in the max array position, so the array doesn't grow in more steps. The array scope is global; it is definable only out of the functions and the access to it is like in C. It is not initiated.

  • functions: they must return a value. Return value will be '0' in absence of an explicit return instruction. A function is defined by a type, a name and a parameters list. The parameters are passed by value and not by reference. There are not pointers so a function cannot delegate an other function to change the value of variable. To do this, you can use array which has global scope. Recursive functions are allowed.

  • structured constructions: the xFF files accept all C constructions except the switch statement. Here it is a constructions description:

    if '(' expression ')' instruction | If expression is different from 0 then instruction is executed
    if '(' expression ')' instruction1 else instruction2 | If expression is different from 0 instruction1 is executed instead instruction2
    do '{' instructions '}' while '(' expression ')' | The instructions are executed. If expression is different from 0 the instructions are executed again.
    while '('expression ')''{'instructions '}' | If expression is different from 0 the instructions are executed, then expression is calculated again.
    for '(' expression1 ';' expression2 ';' expression3 ')' instruction | Expression1 is calculated. If expression2 is true then instruction is executed.Expression3 is calculated. Expression3 is calculated again.

  • instructions:

    • CONTINUE: it resumes the structured construction as in C.
    • BREAK: it breaks the most internal structured construction (doesn't work in if).
    • TITLE '(' string ')': show the string as a title
    • PRINTF '(' string ',' expressions_list ')': print a string using the format options (look at printf() page). The paging command are like those of the function C printf - %d for int, %u for unsignedint,%s for character.
    • PRINTF '(' string ')': print a string like printf do. Paging command are not available.
    • APRINT '(' string ',' name ')': print a vector like a for cycle. It has paging command as printf.
    • CLEAR '(' name ')':cancel a vector. All the elements values will be lost. The vector memory is completely settled free.
    • RETURN expression: goes out from the current function and returns a value.
    • RESETLOG '('expression')', RESETLOG '('expression', 'expression')', RESETLOG '('expression', 'expression', 'expression')' : this instruction can be invoked using three different formats. It is used to modify the bytes intervals which are automatically associated, by Query, to the packets fields. Look at resetlog utilization for further information.

Further information about these are available in the page which describe the class which implement the virtual machine which parses the relative objects files.

You can have more information about DFF and IFF format looking at:

  • the grammar page.


Statistics and filters expressions

The statistics and filters expressions

In the statistics files and in the filters there are expressions which refer to the protocols defined in the PDF file. The expressions return an integer belonging to the range (-2147483648 , 2147483647) or the CANTTELL value when the expression cannot be evaluated. The integers different from 0 indicate a positive expression evaluation, instead 0 value indicates a negative expression evaluation. In the expressions the user can refer to packet information through the GetVmVar() function.

The protocols names are valid expression and their return value can be: 0xFFFFFFFF if the protocol belongs to the packet, 0 if it does not belong and CANTTELL if it is not possible to establish the protocol presence. Here it is an explanation about how the protocol presence is evaluated. The PDF structure is based on a graph structure. So in order to evaluate the presence of the specified protocol the graph defined by the PDF file has to be visited. If the whole packet is visited and the specified protocol is not found the return value is 0; if it not possible to visit the whole packet and the specified protocol is a possible successor to the last visited protocol then the expression returns 'CANTTELL'.

The protocol fields are indicated with the syntax: protocolname.fieldname. If the field search is successful then the expression will assume the field value; if the field is not found then the expression contains a no valid value.

The truth tables of the operators are modified to contain also the CANTTELL value. VALUE(X) represents a valid value for the X variable; FALSE represents 0; TRUE represents 0xFFFFFFFF; CANTTEL represents a non valid value.

AND (&) | VALUE(B) | CANTTELL
VALUE(A) | VALUE(A)&VALUE(B) | CANTTELL
CANTTELL | CANTTELL | CANTTELL

OR (|) | VALUE(B) | CANTTELL
VALUE(A) | VALUE(A)|VALUE(B) | VALUE(A)
CANTTELL | VALUE(B) | CANTTELL

IDENTITY (=) | VALUE(B) | CANTTELL
VALUE(A) | (VALUE(A)==VALUE(B)) ? TRUE : FALSE | FALSE
CANTTELL | FALSE | TRUE

<= | VALUE(B) | CANTTELL
VALUE(A) | (VALUE(A)<=VALUE(B)) ? TRUE : FALSE | FALSE
CANTTELL | FALSE | TRUE

>= | VALUE(B) | CANTTELL
VALUE(A) | (VALUE(A)>=VALUE(B)) ? TRUE : FALSE | FALSE
CANTTELL | FALSE | TRUE

!= | VALUE(B) | CANTTELL
VALUE(A) | (VALUE(A)!=VALUE(B)) ? TRUE : FALSE | TRUE
CANTTELL | TRUE | FALSE

< | VALUE(B) | CANTTELL
VALUE(A) | (VALUE(A)<VALUE(B)) ? TRUE : FALSE | FALSE
CANTTELL | FALSE | FALSE

> | VALUE(B) | CANTTELL
VALUE(A) | (VALUE(A)>VALUE(B)) ? TRUE : FALSE | FALSE
CANTTELL | FALSE | FALSE

NOT (!) | VALUE(A) | CANTTELL
----- | !VALUE(A) | CANTTELL

+ | VALUE(B) | CANTTELL
VALUE(A) | VALUE(A)+VALUE(B) | CANTTELL
CANTTELL | CANTTELL | CANTTELL

- | VALUE(B) | CANTTELL
VALUE(A) | VALUE(A)-VALUE(B) | CANTTELL
CANTTELL | CANTTELL | CANTTELL

* | VALUE(B) | CANTTELL
VALUE(A) | VALUE(A)*VALUE(B) | CANTTELL
CANTTELL | CANTTELL | CANTTELL

<< | VALUE(B) | CANTTELL
VALUE(A) | VALUE(A)<<VALUE(B) | CANTTELL
CANTTELL | CANTTELL | CANTTELL

>> | VALUE(B) | CANTTELL
VALUE(A) | VALUE(A)>>VALUE(B) | CANTTELL
CANTTELL | CANTTELL | CANTTELL

/ | VALUE(B) | FALSE | CANTTELL
VALUE(A) | VALUE(A)/VALUE(B) | CANTTELL | CANTTELL
CANTTELL | CANTTELL | CANTTELL | CANTTELL

In the expression the user can utilize the function 'GetDataLen'. Its syntax is GetDataLen (protocol_name). It returns the number of the bytes seen as data from the specified protocol.

For further information see the grammar section about the expressions used in the filters and in the stt files.


Plug-ins

Analyzer relies on external applications for all graphical-related jobs. So, for example, Analyzer is not able itself for create a pie graph representing the protocol distribution durin a certain time interval. Analyzer is able to calculate the raw data using its built-in monitoring and statistics functions but it is not able to display the result. Analyzer uses a set of external applications that are able to accept raw data (for example a CSV table) and print graphically the result.

These applications are dynamic link libraries (DLL) with Microsoft Foundation Classes (MFC) support. We will call them plug-ins in order to refer to the way in which they are used: they are such as objects which work only if they are plugged-in by the analyzer interface calls. In few words: they receive the data that has to be printed and the device context where the graph has to be drawn. This implementation offers the following advantage: the user can create a new plug-in which draws his prefer graph and, after inserting it in the plug-ins directory, Analyzer will be automatically able to display data according to the new graph. These files have the extension APG (Analyzer PluG-in).


Query: the Analysis engine

The analysis engine, Query.exe, is a standard console application and it can be used "stand-alone". Analyzer uses this program and it redirects its input/output to the graphical interface.

Query provides an environment exploited by all the parsers in order to execute the object code generated by them. It consists basically in a user interface and a virtual machine that hosts the "external" code and executed user command by means of the object files.

Query supports two kinds of commands:

  • off-context commands: they are commands that can be given at any time

  • on-context commands: they are commands that can be given only when there is a capture file open.

Off-context commands

  • logopen FILENAME: Opens file FILENAME and uses it like capture file. Capture format is specified in current LFO file.

  • capopen FILENAME: Opens file FILENAME and uses it like capture file. Capture format is CAP.

  • iniopen FILENAME: Opens file FILENAME and uses it like INI file.

  • lfoopen FILENAME: Opens file FILENAME and uses it like LFO file. This file will be used to read capture files.

  • pfoopen FILENAME: Opens file FILENAME and uses it like PDO file. This file contains protocols definition.

  • dfoopen FILENAME: Opens file FILENAME and uses it like DFO file. This file will be used to print packets analysis.

  • ifoopen FILENAME: Opens file FILENAME and uses it like IFO file. This file will be used to print packets index.

  • macro FILENAME: Executes macro contained in file FILENAME.

  • repopen FILENAME OPTIONS: Opens file FILENAME uses it like textual report. Options are:

    • -d: Adds to report only packet exadecimal dump

    • -p: Adds to report only packet analysis

    • -a: Adds to report packet analysis and exadecimal dump

    • -n: Adds to report only packet number

  • repclose: Closes report file currently open.

  • command STRINGS: Execute command STRINGS usyng system shell.

  • chdir DIRECTORY: Changes current directory to DIRECTORY.

  • maccompile FILENAME1 FILENAME2: Compiles macro file FILENAME1 and creates object file FILENAME2.

  • lffcompile FILENAME1 FILENAME2: Compiles LFF file whoose name is FILENAME1 and creates object file FILENAME2.

  • pdfcompile FILENAME1 FILENAME2: Compiles PDF file whoose name is FILENAME1 and creates object file FILENAME2.

  • ddfcompile FILENAME1 FILENAME2: Compiles DFF file (or IFF file) whose name is FILENAME1 and creates object file FILENAME2.

  • new FILENAME: Creates a new capture whose name is FILENAME.

  • help: Shows this command list.

On-context commands

  • repadd: Adds to report current packet analysis.

  • wcapopen FILENAME: Opens file FILENAME and uses it like binary report.

  • wcapclose: Closes current binary report file.

  • wcapadd: Adds to current binary report file current packet.

  • this: Shows current packet analysis.

  • first: Shows first packet analysis.

  • last: Shows last packet analysis.

  • prev: Shows previous packet analysis.

  • next: Shows next packet analysis.

  • prevf: Shows previous packet analysis which satisfy current filter.

  • nextf: Shows next packet analysis which satisfy current filter.

  • filter STRING: Sets current filter to STRING.

  • jump N1: Shows N1 packet analysis (if available).

  • getpos: Shows current position in capture file.

  • getitemnr: Shows packet number.

  • getprotos [OPTIONS]: Shows supported protocols. If an option is present only protocol names are visualyzed.

  • query [-t] [-o:OUTFILE] FILENAME: Evaluate Statistics contained in file FILENAME and shows results.

  • index [N1 [N2]]: Shows packets index. N1 is the start packet (where index begins). N2 is end packet (where index ends). If N1 and N2 are not present, index will be created on every packet. If N2 is not present, index will be created starting from packet N1.

  • setfirstpr [PROTOCOL]: Sets first protocol for packet analysis to PROTOCOL. If this parameter is not present all protocols are taken into consideration.

  • getlinktype: Shows value of the field 'link type' contained in capture header or defined in current LFF file.

  • delete N1 N2 ...: Deletes packets number N1, N2, ... in current capture.

  • copy \"FILENAME\" N1 N2 ...: Copies packets N1, N2, ... from current capture in file FILENAME.

  • merge FILENAME: Merges packets in current capture with packets in capture file FILENAME.

  • getfltpck: Shows packets satisfying current filter.


Analyzer.ini

Analyzer.ini is a normal Windows .INI file, so it has the following form:

[section]
key=string
...

Here it is the list of the sections and their explanation. All path are relative to the Analyzer's root directory.

[settings] |  |
 | PDF/IFF/DFF | the path of the PDF/IFF/DFF file set during the last Analyzer session
 | PDO/IFO/DFO | path of the correspondent object files; path of the object files cannot be modified through the graphical interface
 | LFO | the LFO file path; it cannot be modified through the graphical interface
 | TmpDat | it is the path of the file TmpDat.dat; it is a temporary file which exists only during the Analyzer execution. During a session it contains the list of all the temporary ACP file which are created. When the session ends this list is used by Analyzer to retrieve the names of all the temporary files which have to be deleted
 | FontList, FontDimList, FontRow, FontDimRow, FontTree, FontDimTree | they contain the names and the dimensions of the Fonts which were set through the menu voices Setup / Font / ... during the last Analyzer session
 | AskCsv | it memorizes which menu voice of the submenu Setup / Statistics Output / (Table, Text, Csv) was selected during the last session.
 | IndexSep | it defines the separator used by the analysis engine to separate the strings which compose the packets index; this separator has to be known by the interface in order to decode the packets index text received by the analysis engine
 | CsvSep | it defines a separator used by the analysis engine to write the statistics output text This separator has to be known by the interface to decode the statistics text.
[PageSetup] |  |
 | Left, Right, Top, Bottom | Parameters used by the 'Page Setup' dialog (File / Page Setup), for the printing process.
[Capture Index] |  | Labels to be printed on top of the columns of the top window (index view)
 | Column_xxx | Legend of the column number xxx
[width_col] |  | Widths of the columns of the packets list
 | width_colxxx | Width of column xxx
[capturesettings] |  | This section contains the capture parameters used during the last capture session; so the Capture settings dialog is initialized using these values.
 | snaplen | Length of the packet that has to be captured (and stored).
 | ncapture | Number of the packets which have to be captured.
 | bufdim | size of the buffer used by the packet driver.
 | promisquous | set to 1 if the driver is in promiscuous mode, 0 otherwise.
 | adapter | name of the last selected adapter
 | filtername | a string containing the last used filter during capturing
[HTML] |  | This section defines the fonts used in the html output of Analyzer.
 | Index_Table_Titles End_Index_Table_Titles | HTML Header / Trailer of the font used for the title of the packet index view
 | Index_Font End_Index_Font | HTML Header / Trailer of the font used into the packet index view
 | Packet_View_Font End_Packet_View_Font | HTML Header / Trailer of the font used into the packet description view
 | Packet_Dump_Font End_Packet_Dump_Font | HTML Header / Trailer of the font used into the packet dump view
[DAT] |  |
 | CapFilters | Path of the file cap_fltr.dat which defines the capture filters
 | Filters | Path of the file filters.dat which defines the filters used to select the packets
 | Exts | Path of the file exts.dat which defines the parameters presented by the dialog 'Capture definition and files extensions associations' (Setup / Capture /Capture Associations).
 | Apps | Path of the file Apps.dat which contains the names and the executable files paths of the external applications presented by the menu Utility
[panes] |  | Sizes of the top and left window
 | pane0 | Height of the top window (index view)
 | pane1 | Length of the left window (packet description view)
[plugin] |  |
 | path | Path of the folder in which graphical DLL libraries (the plug-ins) are stored.


QUERY.INI

This file stores the configuration settings for Query. It is located in the same directory which query.exe belongs to. Paths are relative to the Query.exe folder.

[PRINTF] | It gives the way to extend the print possibilities of the method printf() used in DFF / IFF files; this section declares the associations between new parameters (used in printf) and the proper Section in TABLES.DAT
[Settings] | It gives the way to extend the print possibilities of the method printf() used in DFF / IFF files; this section declares the associations between new parameters (used in printf) and the proper Section in TABLES.DAT
cols | the cols number in the screen (used in console-mode only)
rows | the rows number in the screen (used in console-mode only)
lfoName | lfo file directory
pfoName | pfo file directory
dfoName | dfo file directory
ifoName | ifo file directory
Tables | TABLES.DAT directory
MaxItemSize | the maximum packet size supported by capture file
[Cap]

The ACP capture file format has an header field (called 'Link Type') which defines the network type where the packets were captured from. In the section Cap the user can insert a row composed by an integer associated to a protocol name; the integer refers to the Link Type, the name refers to the protocol from which the analysis has to start. If this association is not present then the analysis starts from the MAC protocol. For instance the distributed INI file has the following values:

[Cap]
1=MAC
11=LLC_ATM


TABLES.DAT

File TABLES.DAT contains tables (each belonging to a particular section) whose rows give the correspondences between textual data and constants. For instance the raw:

0000C0 Western Digital

defines a producer code,

09004E000002 IPX

defines a multicast address used by IPX.

Here it is an abstract from TABLES.DAT:

[VENDOR_CODE:3]
;
00000C Cisco
00000F NeXT
000010 Sytek
00001D Cabletron
000020 DIAB

This file is used by Query when a description file (dff, iff) has a "non standard" printf() directive, i.e. when printf() is invoked with format parameters different from: %d, %D, %u, %U, %c, %x, %X, %o, %O, %b. In this case, Query checks for that "wrong" marker into its configuration file (QUERY.INI) for the same marker. associated to it, there will be a string that will identify the Section (in tables.dat) that has to be used for that printf().

For instance, let's suppose the following line into a .dff file:

printf ("%v", code); /*code=0000C0*/

Looking into query.ini there will be the following line:

v=VENDOR_CODE

Therefore the printf() will look at filr tables.dat, in the "VENDOR_CODE" Section, and will print the string that correspond to the value stored into variable "code". In this example output will be "Western Digital". So if you want to define a new code you have to modify TABLES.DAT and also QUERY.INI if you add a new section.

The file, as said, is organized in sections marked by a title between square brackets. Between the brackets there is also a number which indicates the length of the numeric field. For instance, the OUI part of the MAC address is made fo 3 bytes.

Lines larger than 80 characters are ignored. In the codes blanks are not admitted; a blank has to follow the code.


DFF / IFF files grammar

Syntactic level

Described with YACC format:

   1  type : BYTE
   2       | WORD
   3       | DWORD

   4  name : NAME

   5  number : NUMBER
   6         | C_H_NUM
   7         | C_O_NUM
   8         | LIT_CH

   9  const_str : CONST_STRING

  10  expression : name
  11              | name '[' expression ']'
  12              | ch_funz
  13              | number
  14              | CHECK '(' expression ')'
  15              | CONV '(' expression ')'
  16              | CONV16 '(' expression ')'
  17              | CONV24 '(' expression ')'
  18              | CONV32 '(' expression ')'
  19              | '(' expression ')'
  20              | expression '+' expression
  21              | expression LSHIFT expression
  22              | expression RSHIFT expression
  23              | expression NOT_EQ expression
  24              | expression MIU expression
  25              | expression MAU expression
  26              | expression MIN expression
  27              | expression MAG expression
  28              | expression EQ expression
  29              | expression AND expression
  30              | expression OR expression
  31              | expression '-' expression
  32              | expression '*' expression
  33              | expression '/' expression
  34              | expression '%' expression
  35              | '-' expression
  36              | NOT expression
  37              | assignment
  38              | SIZEOF '(' name ')'
  39              | OFFSETOF '(' name ')'
  40              | GETVMVAR '(' const_str ')'
  41              | COMMAND '(' const_str ')'
  42              | LEN '(' name ')'
  43              | STRLEN '(' name ')'

  44  assignment: name '=' expression
  45               | name '[' expression ']' '=' expression

  46  ch_funz : name '(' l_express ')'
  47          | name '(' ')'

  48  l_express : expression
  49            | l_express ',' expression

  50  program : llines
  51            |

  52  llines : declarations
  53         | c_function
  54         | llines declarations
  55         | llines c_function

  56  declaration : prototype

  57  prototype : type name '(' ')' ';'
  58            | type name '(' l_variables ')' ';'
  59            | ARRAY name ';'

  60  l_variables : type name
  61              | name
  62              | l_variables ',' type name
  63              | l_variables ',' name

  64  def_var : def_v ';'

  65  def_v : type name
  66        | def_v ',' name
  67        | type error

  68  l_instructions : l_instructions instruction
  69                | instruction
  70                | error

  71  instruction: instr ';'
  72             | construction
  73             | def_var
  74             | '{' l_instructions '}'
  75             | '{' '}'

  76  construction : c_do
  77               | c_while
  78               | c_if
  79               | c_for

  80  do : DO

  81  while : WHILE

  82  for : FOR

  83  if : IF

  84  else : ELSE

  86  c_do : do instruction WHILE '(' expression ')' ';'
  87       | do instruction WHILE error

  89  c_while : while '(' expression ')' instruction
  90          | while error

  91  t_if :

  92  c_if : if '(' expression ')' t_if instruction

  94  c_if : if '(' expression ')' t_if instruction else instruction
  95       | if error

  99  c_for : for '(' expression ';' expression ';' expression ')' instruction
 100        | for error

 102  c_function : tipo nome '(' ')' '{' l_instructions '}'

 104  c_function : tipo nome '(' l_variables ')' '{' l_instructions '}'
 105             | tipo nome '(' error ')'

 106  instr  : CONTINUE
 107         | BREAK
 108         | expression
 109         | TITLE '(' cost_str ')'
 110         | TITLE '(' cost_str ',' l_express ')'
 111         | PRINT '(' cost_str ',' l_express ')'
 112         | PRINT '(' cost_str ')'
 113         | APRINT '(' cost_str ',' nome ')'
 114         | CLEAR '(' name ')'
 115         | RETURN expression
 116         | RESETLOG '(' ')'
 117         | RESETLOG '(' expression ',' expression ')'
 118         | RESETLOG '(' expression ',' expression ',' expression ')'
 119         | prototype

Low Precedence
Operators | It is associated with the term on the:
'=' | right
OR | left
AND | left
EQ,NOT_EQ,'<','>',MIU,MAU | left
LSHIFT,RSHIFT | left
'+','-' | left
'*','/','%' | left
NOT,MENO_UNARIO | right
CH_FUNZ | left
High Precedence

Lexical level

LEX format:

SPACE ([\t\r\n ])
SPACES ({SPACE}*)
LETTER ([a-zA-Z])
DIGIT ([0-9])
F_DIGIT ([1-9])
DECIMAL ({DIGIT}*{F_DIGIT}|0)
UNTIL_END ([^\n]*)
R_REM (\/\/)
HEX ((("0x")|("0X"))([a-fA-F]|{DIGIT})+)
OCT (("0")([0-7])+)
INTEGER ({F_DIGIT}{DIGIT}*)
VAR_NAME ((("_")|{LETTER})({LETTER}|{DIGIT}|("_"))*)
CONST_STRING (\"[^\"\n]*\")
CONST_INT_SHORT ({INTEGER}|[0])
QUOTE	\'([^\\']|\\[^'\\]+|\\\\)\'
OP	([-+=*/{}();,:%])|("\[")|("\]")
VAR ({VAR_NAME})
COMMENT ("/*"([^*]*|"*"+[^*/])"*"+\/)
COMMENT_L ("//".*)
%%
\xd	/* Discards LF*/
{COMMENT}	{/* Discards comment */ }
{COMMENTO_L}	{/* Discards comment */ }
do	{return DO; }
if	{return IF; }
else	{return ELSE; }
while	{return WHILE; }
for	{return FOR; }
return	{return RETURN; }
break	{return BREAK; }
continue	{return CONTINUE; }
array	{return ARRAY; }
byte	{return BYTE; }
word	{return WORD; }
dword	{return DWORD; }
sizeof	{return SIZEOF; }
offsetof	{return OFFSETOF; }
getvmvar	{return GETVMVAR; }
printf	{return PRINT; }
aprintf	{return APRINT; }
clear	{return CLEAR; }
arrlen	{return LEN; }
strlen	{return STRLEN; }
resetlog	{CHSAY("RESETLOG");return RESETLOG; }
title	{return TITLE; }
check	{return CHECK; }
conv	{return CONV; }
conv16	{return CONV16; }
conv24	{return CONV24; }
conv32	{return CONV32; }
{CONST_STRING} 	        {return CONST_STRING; }
{CONST_INT_SHORT}	{return NUMBER; }
{HEX}	{return C_H_NUM; }
{OCT}	{return C_O_NUM; }
{QUOTE}	{return LIT_CH; }
"<" {return MIN;}
">" {return MAG;}
AND {return AND;}
"&" {return AND;}
"&&" {return AND;}
OR {return OR;}
"|" {return OR;}
"||" {return OR;}
NOT {return NOT;}
"!" {return NOT;}
"~" {return NOT;}
{OP}	{return *yytext; }
"=="	{return EQ; }
"!="	{return NOT_EQ; }
">="	{return MAU; }
"<="	{return MIU; }
"<<"	{return LSHIFT; }
">>"	{return RSHIFT; }
{VAR}	{return NAME;}
{SPACE}+ {}
. {printf("Scanner error at line %d\n",yylineno);return (SC_ERROR);}
%%

'AND' can be written : 'AND', '&&', '&'

'OR' can be written : 'OR', '||', '|'

'NOT' can be written : 'NOT', '!', '~'

'=' can't be written '=='. In file xFF, double equal means comparison while single equal means assignment.


LFF grammar

LFF files grammar

This page shows the syntactic level and lexical level which the LFF parser uses to analyze LFF files.

Syntactic level

The following grammar is presented in the YACC format. The terminal symbol are written as capital letters, while the not terminal symbol are written as small letters.

   1  file : header packet_formats trailer
   2  hdr_init : HEADER
   3  header : hdr_init structs ENDHH hdefs
   4  trailer : TRAILER structs ENDHT
   6  packet_formats : pheader pdefs psdefs pudefs pwdefs pddefs $$1 ptrailer
   8  packet_formats : packet_formats pheader pdefs psdefs pudefs pwdefs pddefs $$2 ptrailer
   9  pheader : PHEADER structs ENDPH
  10  ptrailer : PTRAILER structs ENDPT
  11  str : str def
  12      | def
  13  structs : str
  14          |
  15  def : BYTE NAME
  16      | WORD NAME
  17      | DWORD NAME
  18  hdefs : hdefs1 hdefs2
  19  hdefs1 : MUSTINVERT ':' expression
  20  hdefs2 : LINKTYPE ':' expression
  21  string : STRING
  22  pdefs : PLEN ':' expression LEN ':' expression TYPE ':' expression CHECK ':' expression FIRSTPROTOCOL ':' stringa
  23  psdefs : SECS ':' expression
  24         |
  25  pudefs : USECS ':' expression
  26         |
  27  pwdefs : WRITTEN ':' expression
  28         |
  29  pddefs : DISCARDED ':' expression
  30         |
  31  expression : NAME
  32              | NUMBER
  33              | NUMBER_H
  34              | '(' expression ')'
  35              | expression '+' expression
  36              | expression MIU expression
  37              | expression MAU expression
  38              | expression '<' expression
  39              | expression '>' expression
  40              | expression NOT_EQ expression
  41              | expression '=' expression
  42              | expression AND expression
  43              | expression OR expression
  44              | expression '-' expression
  45              | expression '*' expression
  46              | expression '/' expression
  47              | expression '%' expression
  48              | '-' expression
  49              | NOT expression

'file' is the beginning symbol.

Here it is the table which shows the priority order of the operators in the expressions:

Low priority
Operators | The operator is associated to the expression on the:
OR | left
AND | left
'=',NOT_EQ,'<','>',MIU,MAU | left
'+','-' | left
'*','/','%' | left
NOT,MENO_UNARIO | right
High priority

The lexical level

Here it is a summary of the scanner which recognize the file tokens. This summary is presented in the LEX format.

SPACE ([\t\r\n ])
SPACES ({SPACE}*)
LETTER ([a-zA-Z])
DIGIT ([0-9])
F_DIGIT ([1-9])
DECIMAL ({DIGIT}*{F_DIGIT}|0)
HEX ((("0x")|("0X"))([a-fA-F]|{DIGIT})+)
INTEGER ({F_DIGIT}{DIGIT}*)
VAR_NAME ((("_")|{LETTER})({LETTER}|{DIGIT}|("_"))*)
COST_INT_CORTO ({INTERO}|[0])
OP	([-+=*/%()<>:])
VAR ({VAR_NAME})
COMMENT ("/*"([^*]*|"*"+[^*/])"*"+\/)
COST_STRING (\"[^\"\n]*\")

%%
BYTE {return BYTE;}
WORD {return WORD;}
DWORD {return DWORD;}
AND {return AND;}
"&" {return AND;}
"&&" {return AND;}
OR {return OR;}
"|" {return OR;}
"||" {return OR;}
NOT {return NOT;}
"!" {return NOT;}
"~" {return NOT;}
TYPE {return TYPE;}
CHECK {return CHECK;}
PLEN {return PLEN;}
L'EN {return L'EN;}
SECS {return SECS;}
USECS {return USECS;}
WRITTEN {return WRITTEN;}
DISCARDED {return DISCARDED;}
FIRSTPROTOCOL {return FIRSTPROTOCOL;}
HEADER {return HEADER;}
TRAILER {return TRAILER;}
PHEADER {return PHEADER;}
PTRAILER {return PTRAILER;}
ENDHH {return ENDHH;}
ENDPH {return ENDPH;}
ENDHT {return ENDHT;}
ENDPT {return ENDPT;}
NOT {return NOT;}
"!=" {return NOT_EQ;}
"<=" {return MIU;}
">=" {return MAU;}
MUSTINVERT {return MUSTINVERT;}
LINKTYPE {return LINKTYPE;}
{HEX} {return NUMBER_H;}
{COST_INT_CORTO} {return NUMBER;}
{COMMENT}	{/*the comments are ignored*/ }
{OP} {return yytext[0];}
{VAR}	{return NAME;}
{COST_STRING}	{return STRING;}
{SPACE}+ {/*the spaces are ignored*/}
. {printf("Scanner error at line %d\n",yylineno);return (-1);}
%%

'AND' can be written : 'AND', '&&', '&'

'OR' can be written : 'OR', '||', '|'

'NOT' can be written : 'NOT', '!', '~'

'=' can be written : '==', '='


MAC grammar

MAC files grammar

Syntactic level

The following grammar is presented in the YACC format. The terminal symbol are written as capital letters, while the not terminal symbol are written as small letters.

   1  type : BYTE
   2       | WORD
   3       | DWORD
   4  name : NAME
   5  number : NUMBER
   6         | C_H_NUM
   7         | C_O_NUM
   8         | LIT_CH
   9  cost_str : COST_STRING
  10  expression : name
  11              | name '[' expression']'
  12              | ch_funz
  13              | number
  19              | '(' expression ')'
  20              | expression '+' expression
  21              | expression LSHIFT expression
  22              | expression RSHIFT expression
  23              | expression NOT_EQ expression
  24              | expression MIU expression
  25              | expression MAU expression
  26              | expression '<' expression
  27              | expression '>' expression
  28              | expression EQ expression
  29              | expression AND expression
  30              | expression OR expression
  31              | expression '-' expression
  32              | expression '*' expression
  33              | expression '/' expression
  34              | expression '%' expression
  35              | '-' expression
  36              | NOT expression
  37              | assignment
  38              | SIZEOF '(' name ')'
  39              | OFFSETOF '(' name ')'
  40              | COMMAND '(' cost_str ')'
  41              | LEN '(' name ')'
  42              | STRLEN '(' name ')'
  43  assignment : name '=' expression
  44               | name '[' expression ']' '=' expression
  45  ch_funz : name '(' l_espress ')'
  46          | name '(' ')'
  47  l_espress : expression
  48            | l_espress ',' expression
  49  programm : llinee
  50            |
  51  llinee : declarations  52         | c_function
  53         | llinee declarations  54         | llinee c_function
  55  declarations : prototype
  56  prototype : type name '(' ')' ';'
  57            | type name '(' l_variables ')' ';'
  58            | ARRAY name ';'
  59  l_variables : type name
  60              | name
  61              | l_variables ',' type name
  62              | l_variables ',' name
  63  def_var : def_v ';'
  64  def_v : type name
  65        | def_v ',' name
  66        | type error
  67  linstructions : linstructions instruction
  68              | instruction
  69              | error
  70  instruction : istruz ';'
  71             | costrutto
  72             | def_var
  73             | '{' linstructions '}'
  74             | '{' '}'
  75  costrutto : c_do
  76            | c_while
  77            | c_if
  78            | c_for
  79  do : DO
  80  while : WHILE
  81  for : FOR
  82  if : IF
  83  else : ELSE
  84  $$1 :
  85  c_do : do instruction WHILE $$1 '(' expression ')' ';'
  86       | do instruction WHILE error
  87  $$2 :
  88  c_while : while '(' expression ')' $$2 instruction
  89          | while error
  90  t_if :
  91  c_if : if '(' expression ')' t_if instruction
  92  $$3 :
  93  c_if : if '(' expression ')' t_if instruction else $$3 instruction
  94       | if error
  95  $$4 :
  96  $$5 :
  97  $$6 :
  98  c_for : for '(' expression ';' $$4 expression ';' $$5 expression ')' $$6 instruction
  99        | for error
 100  $$7 :
 101  c_function : type name '(' ')' $$7 '{' linstructions '}'
 102  $$8 :
 103  c_function : type name '(' l_variables ')' $$8 '{' linstructions '}'
 104             | type name '(' error
 105  istruz : CONTINUE
 106         | BREAK
 107         | expression
 108         | TITLE '(' cost_str ')'
 109         | TITLE '(' cost_str ',' l_espress ')'
 110         | PRINT '(' cost_str ',' l_espress ')'
 111         | PRINT '(' cost_str ')'
 112         | APRINT '(' cost_str ',' name ')'
 113         | CLEAR '(' name ')'
 114         | RETURN expression
 115         | prototype

'file' is the beginning symbol.

Here it is the table which shows the priority order of the operators in the expressions:

Low priority
Operators | The operator is associated to the expression on the:
'=' | right
OR | left
AND | left
EQ,NOT_EQ,'<','>',MIU,MAU | left
LSHIFT,RSHIFT | left
'+','-' | left
'*','/','%' | left
NOT,MENO_UNARIO | right
CH_FUNZ | left
High priority

Il livello lessicale

Here it is a summary of the scanner which recognize the file tokens. This summary is presented in the LEX format.

SPACE ([\t\r\n ])
SPACES ({SPACE}*)
LETTER ([a-zA-Z])
DIGIT ([0-9])
F_DIGIT ([1-9])
DECIMALE ({DIGIT}*{F_DIGIT}|0)
FINO_FINE ([^\n]*)
R_REM (\/\/)
HEX ((("0x")|("0X"))([a-fA-F]|{DIGIT})+)
OCT (("0")([0-7])+)
INTERO ({F_DIGIT}{DIGIT}*)
VAR_NAME ((("_")|{LETTER})({LETTER}|{DIGIT}|("_"))*)
COST_STRINGA (\"[^\"\n]*\")
COST_INT_CORTO ({INTERO}|[0])
QUOTE	\'([^\\']|\\[^'\\]+|\\\\)\'
OP	([-+=*/<>{}();,:%])|("\[")|("\]")
VAR ({VAR_NAME})
COMMENT ("/*"([^*]*|"*"+[^*/])"*"+\/)
COMMENT_L ("//".*)
%%
\xd	/* discard LF*/
{COMMENT}	{ /* discard comments */ }
{COMMENT_L}	{ /* discard comments */ }
do	{return DO; }
if	{return IF; }
else	{return ELSE; }
while	{return WHILE; }
for	{return FOR; }
return	{return RETURN; }
break	{return BREAK; }
continue	{return CONTINUE; }
array	{return ARRAY; }
byte	{return BYTE; }
word	{return WORD; }
dword	{return DWORD; }
sizeof	{return SIZEOF; }
offsetof	{return OFFSETOF; }
printf	{return PRINT; }
aprintf	{return APRINT; }
clear	{return CLEAR; }
arrlen	{return LEN; }
strlen	{return STRLEN; }
title	{return TITLE; }
command {return COMMAND;}
{COST_STRINGA} 	{return COST_STRINGA; }
{COST_INT_CORTO}	{return NUMERO; }
{HEX}	{return C_H_NUM; }
{OCT}	{return C_O_NUM; }
{QUOTE}	{return LIT_CH; }
AND {return AND;}
"&" {return AND;}
"&&" {return AND;}
OR {return OR;}
"|" {return OR;}
"||" {return OR;}
NOT {return NOT;}
"!" {return NOT;}
"~" {return NOT;}
{OP}	{return *yytext; }
"=="	{return EQ; }
"!="	{return NOT_EQ; }
">="	{return MAU; }
"<="	{return MIU; }
"<<"	{return LSHIFT; }
">>"	{return RSHIFT; }
{VAR}	{return NAME;}
{SPACE}+ {}
. {printf("Scanner error at line %d\n",yylineno);}
%%

'AND' can be written : 'AND', '&&', '&'

'OR' can be written : 'OR', '||', '|'

'NOT' can be written : 'NOT', '!', '~'

'=' can be written : '==', '='


PDF file grammar

The pdf file is analyzed following a syntactic level and a lexical level.

The syntactic level

The grammar of this level is presented in the YACC format:

   1  file : protocol_list
   2  protocol_list : pheader ptrailer
   3                | protocol_list pheader ptrailer
   4  pheader : PROTOCOL name structs ENDPR
   5          | PROTOCOL name ENDPR
   6  skip : SKIP ':' expression
   7  ptrailer : skip next_protocol
   8           | next_protocol
   9  next_protocol : ELSE name
  10                | n_protocol ELSE name
  11  n_protocol : CASE expression ':' name
  12             | n_protocol CASE expression ':' name
  13  structs : structs def bit_defs
  14          | def bit_defs
  15  bit_defs : '{' b_defs '}'
  16           |
  17  b_defs : BIT name'(' number ',' number ')'
  18         | b_defs BIT name'(' number ',' number ')'
  19  def : BYTE name
  20      | WORD name
  21      | DWORD name
  22  name: NAME
  23  number : NUMBER
  24         | NUMBER_H
  25  expression : name
  26              | number
  27              | '(' expression ')'
  28              | expression '+' expression
  29              | expression  NOT_EQ expression
  30              | expression  MIU expression
  31              | expression MAU expression
  32              | expression '<' expression
  33              | expression '>' expression
  34              | expression '=' expression
  35              | expression AND expression
  36              | expression OR expression
  37              | expression '-' expression
  38              | expression '*' expression
  39              | expression '/' expression
  40              | expression '%' expression
  41              | '-' expression
  42              | NOT expression

The operators precedence in the expressions::

Low Precedence
Operators | Association
OR | left
AND | left
'=',NOT_EQ,'<','>',MIU,MAU | left
'+','-' | left
'*','/','%' | left
NOT,MENO_UNARIO | right
High Precedence

The lexical level

Here it is how the scanner recognizes the tokens in the file. It is presented in the LEX format:

SPACE ([\t\r\n ])
SPACES ({SPACE}*)
LETTER ([a-zA-Z])
DIGIT ([0-9])
F_DIGIT ([1-9])
DECIMAL ({DIGIT}*{F_DIGIT}|0)
HEX ((("0x")|("0X"))([a-fA-F]|{DIGIT})+)
INTEGER ({F_DIGIT}{DIGIT}*)
VAR_NAME ((("_")|{LETTER})({LETTER}|{DIGIT}|("_"))*)
CONST_INT_SHORT ({INTEGER}|[0])
OP ([-+=*/%():{},])
VAR ({VAR_NAME})
COMMENT (("/*"([^*]*|"*"+[^*/])"*"+\/)|("//".*))
%%
BYTE {return BYTE;}
BIT {return BIT;}
BITS {return BIT;}
WORD {return WORD;}
DWORD {return DWORD;}
AND {return AND;}
"&&" {return AND;}
"&" {return AND;}
OR {return OR;}
"||" {return OR;}
"|" {return OR;}
NOT {return NOT;}
"!" {return NOT;}
"~" {return NOT;}
PROTOCOL {return PROTOCOL;}
ENDPR {return ENDPR;}
NOT {return NOT;}
SKIP {return SKIP;}
CASE {return CASE;}
ELSE {return ELSE;}
"!=" {return NOT_EQ;}
"<=" {return MIU;}
">=" {return MAU;}
{HEX} {return NUMBER_H;}
{CONST_INT_SHORT} {return NUMBER;}
{COMMENT} {/* Discards comments */ }
{OP} {return yytext[0];}
{VAR} {return NAME;}
{SPACE}+ {/*ignores spaces*/}
. {printf("Scanner error at line %d\n",yylineno);return (-1);}
%%
'AND' can be written : 'AND', '&&', '&'
'OR' can be written: 'OR', '||', '|'
'NOT' can be written: 'NOT', '!', '~'
'=' can be written: '==', '='


Statistics files grammar

Filters and Statistics expressions grammar

Here it is the presentation of the syntactic and lexical level used to parse the expression of the filters and of the statistics files.

Syntactic level

The following grammar is presented in the YACC format. The terminal symbol are written as capital letters, while the not terminal symbol are written as small letters.

   1  name : NAME
   2  field : name '.' name
   3  cost_str : COST_STRING
   4  number : NUMBER
   5         | C_H_NUM
   6         | C_O_NUM
   7         | LIT_CH
   8  expression : field
   9              | number
  10              | TOK_TRUE
  11              | TOK_FALSE
  12              | TOK_CANTTELL
  13              | '(' expression ')'
  14              | expression '+' expression
  15              | expression LSHIFT expression
  16              | expression RSHIFT expression
  17              | expression NOT_EQ expression
  18              | expression MIU expression
  19              | expression MAU expression
  20              | expression '<' expression
  21              | expression '>' expression
  22              | expression '=' expression
  23              | expression AND expression
  24              | expression OR expression
  25              | expression '-' expression
  26              | expression '*' expression
  27              | expression '/' expression
  28              | expression '%' expression
  29              | '-' expression
  30              | NOT expression
  31              | SIZEOF '(' field ')'
  32              | name
  33              | GETDATALEN '(' name ')'
  34              | SIZEOF '(' name ')'
  35              | GETVMVAR '(' cost_str ')'

'expression' is the beginning symbol.

Here it is the table which shows the priority order of the operators in the expressions:

Low precedence
Operators | The operator is associated to the expression on the:
OR | left
AND | left
'=',NOT_EQ,'<','>',MIU,MAU | left
LSHIFT,RSHIFT | left
'+','-' | left
'*','/','%' | left
NOT,MENO_UNARIO | right
High precedence

Lexical level

Here it is a summary of the scanner which recognize the file tokens. This summary is presented in the L'EX format.

SPACE ([\t\r\n ])
SPACES ({SPACE}*)
LETTER ([a-zA-Z])
DIGIT ([0-9])
F_DIGIT ([1-9])
DECIMAL ({DIGIT}*{F_DIGIT}|0)
UNTIL_END ([^\n]*)
R_REM (\/\/)
HEX ((("0x")|("0X"))([a-fA-F]|{DIGIT})+)
OCT (("0")([0-7])+)
INTEGER ({F_DIGIT}{DIGIT}*)
VAR_NAME ((("_")|{LETTER})({LETTER}|{DIGIT}|("_"))*)
COST_STRING (\"[^\"\n]*\")
COST_INT_CORTO ({INTERO}|[0])
QUOTE	\'([^\\']|\\[^'\\]+|\\\\)\'
OP	([-+=*/<>(),.%])
VAR ({VAR_NAME})
COMMENT ("/*"([^*]*|"*"+[^*/])"*"+\/)
COMMENT_L ("//".*)
COMMENT_P (";".*)
%%
\xd	/* Discard LF*/
{COMMENT}	{ /* Discard comments */ }
{COMMENT_L}	{ /* Discard comments */ }
{COMMENT_P}	{ /* Discard comments */ }
sizeof	{return SIZEOF; }
offsetof	{return OFFSETOF; }
getvmvar	{return GETVMVAR; }
getdatalen	{return GETDATALEN; }
{COST_INT_CORTO}	{return NUMBER; }
{COST_STRING}	{return COST_STRING; }
{HEX}	{return C_H_NUM; }
{OCT}	{return C_O_NUM; }
{QUOTE}	{return LIT_CH; }
AND {return AND;}
"&" {return AND;}
"&&" {return AND;}
OR {return OR;}
"|" {return OR;}
"||" {return OR;}
NOT {return NOT;}
"!" {return NOT;}
"~" {return NOT;}
TRUE {return TOK_TRUE;}
FALSE {return TOK_FALSE;}
CANTTELL {return TOK_CANTTELL;}
{OP}	{return *yytext; }
"=="	{return '='; }
"!="	{return NOT_EQ; }
">="	{return MAU; }
"<="	{return MIU; }
"<<"	{return LSHIFT; }
">>"	{return RSHIFT; }
{VAR}	{return NAME;}
{SPACE}+ {/*ignore the spaces*/}
. {/*Ignore all the rest*/}
%%

'AND' can be written : 'AND', '&&', '&'

'OR' can be written : 'OR', '||', '|'

'NOT' can be written : 'NOT', '!', '~'

'=' can be written : '==', '='


ACP and LOG format

How defining a new capture file format

We examine one LFF file which define the ACP format.

Characteristics of the ACP file format (for instance this is the native format of WinPcap and libpcap):

  • The structure is enough simple to allow a fast navigation through the file.

  • The capture file contains only the packets captured from the network; the time information are stored in each packet.

  • The file is navigable only in one direction.

  • The exact time, at which the frame arrived, is available.

  • Not damaged frames are readable also in case of corrupted dumpfile.

  • The overhead (the data which are not frames but info used to manage the file) is negligible.

  • It is possible to read file generated by different architectures (big endian or little endian).

At the beginning of the file there is an header. Here it is its format:

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Magic Number
Major Version |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Minor Version
Time Zone
File Length
Future Applications
Link Type

  • Each file starts with a magic number. This number contains the hexadecimal sequence: 0xa1b2c3d4. It is used to understand if the file was generated by a little endian architecture or by a big endian architecture. In the little endian case the bytes sequence is: 0xa1, 0xb2, 0xc3, 0xd4; in the big endian case: 0xd4, 0xc3, 0xb2, 0xa.

  • Then there are two integers on two byte which represent the major and the minor version of the format.

  • An integer on 4 bytes which contains the time zone in relation with Greenwich.

  • An integer on 4 bytes which contains the file length.

  • An integer on 4 bytes reserved for future applications.

  • An integer on 4 bytes describes the link (Ethernet, ...). Complete mapping can be found into bpf.h file, into the WinPcap source pack. Here it it a table which show the values which this number can have and their meanings:

Value | Description
0 | no link-layer encapsulation
1 | Ethernet (10Mb)
2 | Experimental Ethernet (3Mb)
3 | Amateur Radio AX.25
4 | Proteon ProNET Token Ring
5 | Chaos
6 | IEEE 802 Networks
7 | ARCNET
8 | Serial Line IP
9 | Point-to-point Protocol
10 | FDDI
11 | LLC/SNAP encapsulated ATM
12 | Raw IP
13 | BSD/OS Serial Line IP
14 | BSD/OS Point-to-point Protocol

Then there are the packets; each packet has an header which contains the following information:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Packet Length
The packet part length contained in the file
Seconds from the capture beginning
Micro seconds from the capture beginning

  • An integer on 4 bytes for the packet length.

  • An integer on 4 bytes for the length of the packet part contained in the file. In fact can happen that the capture file does not contain the whole packet.

  • An integer on 4 bytes keeps the seconds number passed since the capture beginning until when the packet was captured.

  • An integer on 4 bytes keeps the microseconds number passed since the capture beginning until when the packet was captured.

The file structure shows that there are no info which allow to read the packet in two directions. In fact in the packet header there is not a field with the length of the previous packet frame.


How to add a protocol to the supported ones

This operation is divided in three steps:

  1. Definition of the protocol by modifying the PDF file.
  2. Definition of the protocol fields printed on the screen by modifying the DFF file.
  3. Definition of the protocol printed in the packet index by modifying the IFF file.

More information about PDF, DFF, IFF files can be found into the Protocol definition Section.

This Section will provide an example of the steps needed to add new protocols. We will add three protocols in order to explain these steps:

  • IPX
  • IPv4
  • TCP

We will modify the protocol configuration files (PDF file, DFF file, IFF file) in order to add these protocols. Initial PDF, DFF and IFF files have been kept quite small in order not to increase the difficulties of the task.

All the instructions used in these files are described by their relative grammars.

Instructions devoted to retrieve information about the packet (for example the value of a particular field) are resolved by means of a virtual machine that reads the packet.

Protocol Definition File: default.pdf

The MAC protocol definition is embedded between the key words PROTOCOL and ENDPR; For example, Ethernet v.2.0 header can be written as:

PROTOCOL MAC
WORD DS1 /* DSAP */
WORD DS2
WORD DS3

WORD SS1 /* SSAP */
WORD SS2
WORD SS3

WORD LEN_TYPE /* Data Length or Protocol Type */
ENDPR

MAC protocol is used also to determine which is next protocol. Instructions that allows doing that are case and else. For instance:

case LEN_TYPE<=1500: LLC
else UNSUPPORTED

The, it follow the LLC protocol definition:

PROTOCOL LLC
BYTE DSAP
BYTE SSAP
BYTE CONTROL
ENDPR

Instruction case is not compulsory; vice versa instruction else does:

else UNSUPPORTED

The following rows define a fake protocol called 'Unsupported'; this protocol does not really exist but it is used to exit from the analysis. The instruction skip means "skip the following N bytes, then restart parsing the remaining part of the packet". In order to finish the analysis, 'skip' instruction has to be followed by a very large number (bigger than the biggest packet size of the network) in order to be sure that end of packet has been reached. The instruction 'else' is followed by the name of the same fake protocol.

The keyword virtual prevents the user from using the protocol fields (which do not even exist in this case) in the expressions; virtual protocols cannot be used in DFF and IFF files.

VIRTUAL PROTOCOL UNSUPPORTED
ENDPR
skip: 20000
else UNSUPPORTED

Protocol Description File: default.dff

The file default.dff contains six functions definitions:

  1. PartialFrame(){...}
  2. Main(){...}
  3. DATA(){...}
  4. UNSUPPORTED(){...} //correspondent to unsupported protocols
  5. MAC (){...}        //correspondent to  MAC protocol
  6. LLC (){...}        //correspondent to LLC protocol

The last three functions are relative to the protocols defined in default.pdf; in fact each protocol must have a relative function, declared in PDF file, which is called when its protocol is parsed.

When a packet has to be displayed, function main is called first that prints general information. Detailed information are printed by other functions, whose name coincides with the one defined into the PDF file. For instance, defining a protocol called MAC in default.pdf, we have to define a function MAC in default.dff and default.iff in order to print information about this level. Whem a protocol is located by the PDF definition the correspondant DFF/IFF function is called; if the function does not exist the content of the fields defined in the PDF is displayed. Such a function has the visibility of its own-defined variables and fields defined in the PDF; this functions can read, print and to modify these fields like standard variables.

PartialFrame()

It is invoked by the 'main' function. It prints the available bytes number and the length of the packet read from the disk. Both value are obtained through the call of the function GetVmVar(). printf() behaves like the homonymous C function.

DWORD PartialFrame()
{
    title ("Description");
    printf( "Item type: Partial frame, %u bytes available", GetVMVar ("FrameAvail"));
    printf( "Frame size is %u (%X hex) bytes",GetVMVar ("FrameSize"),GetVMVar ("FrameSize"));

Main()

It prints some general information about the packet; it is similar to the homonymous C function:

DWORD Main()
{
title("General");
    printf("Item number %u, position in logfile %u%%",GetVMVar ("ItemNumber"),GetVMVar ("Position"));
if (GetVmVar("FrameSecs")==0) printf("Timestamp: 00h:00m:00s:%06dus",GetVMVar ("FrameUSecs"));
else
printf( "Timestamp: %02dh:%02dm:%02ds:%06dus",(GetVMVar ("FrameSecs")%86400)/3600+2,
(GetVMVar ("FrameSecs")%3600)/60,GetVMVar ("FrameSecs")%60,GetVMVar ("FrameUSecs"));
PartialFrame();
}

Data()

It prints two values obtained by invoking GetVMVar() function. In this example data() is called as soon as the LLC analysis finishes, because no other protocols are defined after LLC. Whether current packet does not have an LLC level then the analysis goes to the UNSUPPORTED protocol; so function Unsupported is called and the analysis ends without calling the data function.

DWORD DATA()
{
  DWORD s,t;
  s=GetVMVar ("SizeNotInt");
  t=GetVMVar ("FrameSize");
  if (s)
  {
  printf("----- Data ----- [%d-%d]",t-s,t-1);
  printf( "[%u byte(s) of data]",s);
  }
}

Unsupported()

It prints two values obtained invoking GetVmVar:

  • SizeNotInt: the number of bytes (belonging to the packet actually read) not yet interpreted.

  • FrameSize: packet length (actually read) expressed in byte.

DWORD UNSUPPORTED()
{
  DWORD s,t;
  s=GetVMVar ("SizeNotInt");
  t=GetVMVar ("FrameSize");
  if (s)
  {
  printf("----- NOT SUPPORTED ----- [%d-%d]",t-s,t-1);
  printf( "[%u byte(s) of data]",s);
  }
}

MAC()

We notice the instruction 'offset' which returns the offset of the specified field.

DWORD MAC ()
{
    // MAC analysis
    if (LEN_TYPE<=1500) title( "IEEE 802.3 MAC Header");
    else title("Ethernet v.2.0 MAC Header");

    printf( "Destination = %04X%02X-%02X%04X",DS1,DS2>>8,DS2&0xFF,DS3);
    printf( "Source = %04X%02X-%02X%04X", SS1,SS2>>8,SS2&0xFF,SS3);

    if(LEN_TYPE<=1500) {	// IEEE 802.3 format
       DWORD padding;
       printf( "Packet Length = %u bytes",LEN_TYPE);
       padding=GetVMVar ("FrameSize")-(LEN_TYPE+14);
       if(padding!=0)printf("Padding bytes %u (before data)",padding);
    }
    else			// Ethernet format (DIX)
       printf( "Ethertype = %04Xh (%p)",LEN_TYPE,offsetof(LEN_TYPE));
}

LLC()

DWORD LLC ()
{
    //continues analysis of a IEEE 802.3 frame with the LLC level
    title( "LLC Header");
    printf( "DSAP = %02Xh (%l)",DSAP,offsetof(DSAP));
    printf( "SSAP = %02Xh (%l)",SSAP,offsetof(SSAP));
    //analysing control field
    if (CONTROL==0 || CONTROL==1)     //information frame
        printf( "Control = Information frame");
    else if (CONTROL==2)              //supervisory frame
        printf( "Control = Supervisory frame");
    else if (CONTROL==3)              //unnumbered frame
        printf( "Control = Unnumbered frame");
}

Protocol Index File: default.iff

As you can read in Protocol codification in Analyzer this file defines the packets index print; so it is an abstract of the DFF file, in fact it generates the print of the packet information which are considered essential. The language is the same used in DFF file.

DWORD Main()
{
    if (GetVmVar("FrameSecs")==0) printf("00h:00m:00s:%06dus",GetVMVar ("FrameUSecs"));
    else
        printf( "%02dh:%02dm:%02ds:%06dus",(GetVMVar ("FrameSecs")%86400)/3600+2,
               (GetVMVar ("FrameSecs")%3600)/60,GetVMVar ("FrameSecs")%60,GetVMVar ("FrameUSecs"));
}

DWORD MAC () {
    // MAC analysis
    printf( "%04X%02X-%02X%04X", DS1,DS2>>8,DS2&0xFF,DS3);
    printf( "%04X%02X-%02X%04X", SS1,SS2>>8,SS2&0xFF,SS3);
}

To see the output produced by Analyzer using these three files, set them in window protocol definition and open a capture file.

Adding IPX protocol

The following modification have to be implemented:

  1. Definition of the new protocol (field formats)
  2. Definition of the protocol fields print on the screen
  3. Definition of the summary printed by that protocol in the packet index

Protocol definition

We have to modify the default PDF file. Steps are:

  • Add IPX definition to the PDF file
  • Modify preceding protocols in order to recognize IPX
  • Add some code to IPX in order to teach Analyzer to recognize following protocols (like SAP).

Here it is the IPX protocol structure:

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Checksum |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Length
Transport Control |  |  |  |  |  |  |  | Packet Type |  |  |  |  |  |  |  | Dest. Network Address
Dest. Network Address |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Dest. Node Address
Dest. Node Address
Dest. Socket |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Source Network Address
Source Network Address |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Source Node Address
Source Node Address
Source Socket |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ...
Data (0-546 byte)

The inclusion of the IPX protocol is done adding these rows:

PROTOCOL IPX
    WORD Checksum
    WORD PLen
    BYTE TControl
    BYTE PType
    DWORD DNet
    WORD DNode1
    WORD DNode2
    WORD DNode3
    WORD DSocket
    DWORD SNet
    WORD SNode1
    WORD SNode2
    WORD SNode3
    WORD SSocket
ENDPR
    else UNSUPPORTED

The row "else UNSUPPORTED" at the end of IPX means that no further protocols are recognized after IPX. We can notice that in IPX protocol the fields Source Node and Destination node are 6 bytes long; however PDF files allows only 1 or 2 or 4 bytes long fields. The solution is given by breaking these 6 bytes long fields: we can get three 2 bytes long fields (WORD), one 4 bytes long (DWORD) and one 2 bytes long ( WORD). These two solutions are equivalent for the analysis engine.

For instance, if we want to locate all packets with Source Node field = 123456789ABC (hexadecimal value), the discriminative expression will be:

First solution: SNode1=0x1234 && SNode2=0x5678 && SNode3=0x9ABC
Second solution: SNode12=0x12345678 && SNode3=0x9ABC

For integrating completely the IPX protocol we have to modify also definitions of MAC and LLC protocols (we don't consider proprietary solution which insert IPX in 802.3 payload). MAC level indicates an IPX packet whether field LEN_TYPE == 0x8137 or 0x8138. Then we have to add 2 rows in MAC protocol definition before string "else UNSUPPORTED":

PROTOCOL MAC
    WORD DS1 /* DSAP */
    WORD DS2
    WORD DS3

    WORD SS1 /* SSAP */
    WORD SS2
    WORD SS3

    WORD LEN_TYPE /* Data Length or Protocol Type */
ENDPR
    case LEN_TYPE<=1500: LLC
    case LEN_TYPE=0x8137: IPX
    case LEN_TYPE=0x8138: IPX
    else UNSUPPORTED

In the LLC header we have to test the field DSAP; if DSAP is equal to 0xe0, next protocol will be IPX:

PROTOCOL LLC
    BYTE DSAP
    BYTE SSAP
    BYTE CONTROL
ENDPR
    case DSAP=0xe0: IPX
    else UNSUPPORTED

We still do not add CASE instructions in IPX definition because there are not protocols (among the defined ones) which succeed to the IPX protocol.

Protocol print definition

We insert a function (DWORD IPX()) in DFF file in order to show the content of IPX packet. This function is composed by a series of printf() and a single instruction title(). Last instruction is used to print the string and create a new section of the packet in order to keep packet information logically organized.

//IPX packet Interpretation
DWORD IPX ()
{
    title("IPX Header");
    printf( "Checksum 0x%X",Checksum);
    printf( "Packet length %u",PLen);
    printf( "Transport control %u",TControl);
    printf( "Packet type 0x%X (%r)",PType,offsetof(PType));
    printf( "Destination network 0x%08X",DNet);
    printf( "Destination node %04X%02X-%02X%04X (Vendor: %v)",
        DNode1,(DNode2>>8),DNode2&0xff,DNode3,offsetof(DNode1));
    printf( "Destination socket 0x%04X (%n)",DSocket,offsetof(DSocket));
    printf( "Source network 0x%08X",SNet);
    printf( "Source node %04X%02X-%02X%04X (Vendor: %v)",
        SNode1,SNode2>>8,SNode2&0xff,SNode3,Offsetof(SNode1));
    printf( "Source socket 0x%04X (%n)",SSocket,offsetof(SSocket));
}

Index packet print definition

We can take the function added in DFF file, eliminate the unnecessary parts and insert it in IFF file. In fact in the index only the main information are shown. Character ":|:" that is printed at the ed of the function tells Analyzer that next printed information must be inserted in the next column (index view is made up of several columns).

//IPX packet Interpretation
DWORD IPX ()
{
    printf("IPX: ");
    printf( "0x%08X.0x%04X",SNet,SSocket);
    printf("=>");
    printf( "0x%08X.0x%04X :|:",DNet,DSocket);
}

Improving the IPX definition

In the definition we did not consider that the IPX header can be contained in the IEEE 802.3 header. In this solution IPX protocol replace LLC protocol.

We can distinguish if the next protocol is IPX or LLC thanks to these two observations:

  • In IPX header checksum field is never used and its value is 0xFFFF.
  • In LLC header, SSAP and DSAP fields cannot be equal to 0xFF at the same time.

Then we insert a 'virtual' protocol, called LLC_IPX; this virtual protocol is called if the field 'Data Length or Protocol Type' is less than 1500 (i.e. type is 802.3). In this case the next two bytes are stored in the word PCHECK and they are checked to decide if the next protocol is LLC or IPX. The instruction SKIP -2 is inserted in order to go two bytes back in the packet parsing in order to allow these two bytes being reinterpreted by the following protocol definition. The number after SKIP indicates how many bytes are skipped: 'SKIP N' the reading point goes N bytes on, 'SKIP -N' the reading point goes N bytes back.

VIRTUAL PROTOCOL LLC_IPX
    WORD PCHECK
ENDPR
    skip: -2
    case PCHECK=0xFFFF: IPX
    else LLC

We modify also MAC definition:

PROTOCOL MAC
    WORD DS1 /* DSAP */
    WORD DS2
    WORD DS3

    WORD SS1 /* SSAP */
    WORD SS2
    WORD SS3

    WORD LEN_TYPE /* Data Length or Protocol Type */
ENDPR
    case LEN_TYPE<=1500: LLC_IPX
    case LEN_TYPE=0x8137: IPX
    case LEN_TYPE=0x8138: IPX
    else UNSUPPORTED

Final result

Now the IPX protocol definition is completed. You can try to set these three files in Analyzer using the dialog window Analyzer setup (menu Setup / analyzer); the objects files will be named default.pdo/dfo/ifo and they will be stored in folder Objects.

Default.pdf

PROTOCOL MAC
    WORD DS1 /* DSAP */
    WORD DS2
    WORD DS3

    WORD SS1 /* SSAP */
    WORD SS2
    WORD SS3

    WORD LEN_TYPE /* Data Length or Protocol Type */
ENDPR
    case LEN_TYPE<=1500: LLC_IPX
    case LEN_TYPE=0x8137: IPX
    case LEN_TYPE=0x8138: IPX
    else UNSUPPORTED

VIRTUAL PROTOCOL LLC_IPX
    WORD PCHECK
ENDPR
    skip: -2
    case PCHECK=0xFFFF: IPX
    else LLC

PROTOCOL LLC
    BYTE DSAP
    BYTE SSAP
    BYTE CONTROL
ENDPR
    case DSAP=0xe0: IPX
    else UNSUPPORTED

PROTOCOL IPX
    WORD Checksum
    WORD PLen
    BYTE TControl
    BYTE PType
    DWORD DNet
    WORD DNode1
    WORD DNode2
    WORD DNode3
    WORD DSocket
    DWORD SNet
    WORD SNode1
    WORD SNode2
    WORD SNode3
    WORD SSocket
ENDPR
    else UNSUPPORTED

Default.dff

DWORD PartialFrame()
{
    title ("Description");
    printf( "Item type: Partial frame, %u bytes available", GetVMVar ("FrameAvail"));
    printf( "Frame size is %u (%X hex) bytes",GetVMVar ("FrameSize"),
GetVMVar ("FrameSize"));
}

DWORD Main()
{
    title("General");
    printf("Item number %u, position in logfile %u%%",GetVMVar ("ItemNumber"), GetVMVar ("Position"));
    if (GetVmVar("FrameSecs")==0) printf("Timestamp: 00h:00m:00s:%06dus", GetVMVar ("FrameUSecs"));
    else
      printf( "Timestamp: %02dh:%02dm:%02ds:%06dus", (GetVMVar ("FrameSecs")%86400)/3600+2,
        (GetVMVar ("FrameSecs")%3600)/60,GetVMVar ("FrameSecs")%60, GetVMVar ("FrameUSecs"));

    PartialFrame();
}

DWORD DATA()
{
    DWORD s,t;
    s=GetVMVar ("SizeNotInt");
    t=GetVMVar ("FrameSize");
    if (s) {
        printf("----- Data ----- [%d-%d]",t-s,t-1);
        printf( "[%u byte(s) of data]",s);
    }
}

DWORD UNSUPPORTED()
{
    DWORD s,t;
    s=GetVMVar ("SizeNotInt");
    t=GetVMVar ("FrameSize");
    if (s) {
        printf("----- NOT SUPPORTED ----- [%d-%d]",t-s,t-1);
        printf( "[%u byte(s) of data]",s);
    }
}

DWORD MAC ()
{
    // MAC analysis
    if (LEN_TYPE<=1500) title( "IEEE 802.3 MAC Header");
    else title("Ethernet v.2.0 MAC Header");

    printf( "Destination = %04X%02X-%02X%04X",DS1,DS2>>8,DS2&0xFF,DS3);
    printf( "Source = %04X%02X-%02X%04X", SS1,SS2>>8,SS2&0xFF,SS3);

    if(LEN_TYPE<=1500) {	// IEEE 802.3 format
       DWORD padding;
       printf( "Packet Length = %u bytes",LEN_TYPE);
       padding=GetVMVar ("FrameSize")-(LEN_TYPE+14);
       if(padding!=0)printf("Padding bytes %u (before data)",padding);
    }
    else			// Ethernet format (DIX)
       printf( "Ethertype = %04Xh (%p)",LEN_TYPE,offsetof(LEN_TYPE));
}

DWORD LLC_IPX ()
{
    if (PCHECK == 65535) printf("IPX on 802.3");
}

DWORD LLC ()
{
    //continues analysis of a IEEE 802.3 frame with the LLC level
    title( "LLC Header");
    printf( "DSAP = %02Xh (%l)",DSAP,offsetof(DSAP));
    printf( "SSAP = %02Xh (%l)",SSAP,offsetof(SSAP));
    //analysing control field
    if (CONTROL==0 || CONTROL==1)     //information frame
        printf( "Control = Information frame");
    else if (CONTROL==2)              //supervisory frame
        printf( "Control = Supervisory frame");
    else if (CONTROL==3)              //unnumbered frame
        printf( "Control = Unnumbered frame");
}

//IPX packet Interpretation
DWORD IPX ()
{
    title("IPX Header");
    printf( "Checksum 0x%X",Checksum);
    printf( "Packet length %u",PLen);
    printf( "Transport control %u",TControl);
    printf( "Packet type 0x%X (%r)",PType,offsetof(PType));
    printf( "Destination network 0x%08X",DNet);
    printf( "Destination node %04X%02X-%02X%04X (Vendor: %v)",
        DNode1,(DNode2>>8),DNode2&0xff,DNode3,offsetof(DNode1));
    printf( "Destination socket 0x%04X (%n)",DSocket,offsetof(DSocket));
    printf( "Source network 0x%08X",SNet);
    printf( "Source node %04X%02X-%02X%04X (Vendor: %v)",
        SNode1,SNode2>>8,SNode2&0xff,SNode3,Offsetof(SNode1));
    printf( "Source socket 0x%04X (%n)",SSocket,offsetof(SSocket));
}

Default.iff

DWORD Main()
{
   if (GetVmVar("FrameSecs")==0) printf("00h:00m:00s:%06dus",GetVMVar ("FrameUSecs"));
   else
      printf( "%02dh:%02dm:%02ds:%06dus",(GetVMVar ("FrameSecs")%86400)/3600+2,
    (GetVMVar ("FrameSecs")%3600)/60,GetVMVar ("FrameSecs")%60, GetVMVar ("FrameUSecs"));
}

DWORD MAC ()
{
    // MAC analysis
    printf( "%04X%02X-%02X%04X", DS1,DS2>>8,DS2&0xFF,DS3);
    printf( "%04X%02X-%02X%04X", SS1,SS2>>8,SS2&0xFF,SS3);
}

//IPX packet Interpretation
DWORD IPX ()
{
    printf("IPX: ");
    printf( "0x%08X.0x%04X",SNet,SSocket);
    printf("=>");
    printf( "0x%08X.0x%04X :|:",DNet,DSocket);
}

Adding IPv4 protocol

Now we want add the IPv4 protocol. Let's examine the IPv4 header:

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Version |  |  |  | Header len. |  |  |  | Type Of Service |  |  |  |  |  |  |  | Total length
Identification |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Flags |  |  |  | Fragment Offset
Next Protocol |  |  |  |  |  |  |  | Time To Live |  |  |  |  |  |  |  | Header Checksum
Source Address
Destination Address
Option |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Padding

Protocol definition PDF

If the 'Length' field in the MAC protocol is equal to 0x0800 then the next protocol can be IPv4 or IPv6. So we have to add a virtual protocol called IP4_6 that determines the next protocol by reading the field 'Version'.

In the MAC protocol we add a line that manages the call to the virtual protocol:

CASE (LEN_TYPE=2048) : IP4_6

Then we add the virtual protocol:

VIRTUAL PROTOCOL IP4_6
 BYTE VLEN
 {
  BITS VERSION (4,7)
  BITS HLEN (0,3)
 }
ENDPR
 SKIP: (-1)
 CASE (VERSION=4) : IP
 ELSE UNSUPPORTED

The SKIP instruction brings one byte back the point where the parser arrived to read the packet. So the byte containing the fields 'version' and 'header length' will be considered by the next protocol instructions. If we added also IPv6 we had to add the line:

 CASE (VERSION=6) : IP6

The IP protocol definition:

PROTOCOL IP
 BYTE VLEN
 {
  BITS VERSION (4,7)
  BITS HLEN (0,3)
 }
 BYTE TOS
 WORD TLEN
 WORD IDENTIFICATION
 WORD FFO
 {
  BITS FLAGS (12,15)
  BITS FRAGMENTOFFSET (0,11)
 }
 BYTE TTL
 BYTE NEXTPROTOCOL
 WORD HCHECKSUM
 DWORD SADDRESS
 DWORD DADDRESS
ENDPR
 SKIP: ((HLEN*4)-20)
 CASE ((NEXTPROTOCOL=6)&&(FRAGMENTOFFSET=0)) : TCP
 ELSE UNSUPPORTED

The instruction SKIP sets the 'reading sign' after the field 'Option' whose length is expressed by the field 'hlen'.

Protocol print definition DFF

DWORD IP ()
{
    //IP packet Interpretation
    if(Version!=4) return -1;
    title( "IPv4 Header");
    ResetLog(offsetof(vlen),offsetof(vlen)+1,1);
    printf( "Version = %u",Version);
    ResetLog(offsetof(vlen),offsetof(vlen)+1,1);
    printf( "Header length = %u bytes",HLEN);
    printf( "Type of service = %02Xh",TOS);
    ResetLog(offsetof(TOS),offsetof(TOS)+1,1);
    printf( " %3b. .... = priority %u",TOS>>5,TOS>>5);
    ResetLog(offsetof(TOS),offsetof(TOS)+1,1);

    if (TOS&0x10) printf( " ...1 .... = low delay");
    else printf( " ...0 .... = normal delay");
    ResetLog(offsetof(TOS),offsetof(TOS)+1,1);

    if (TOS & 0x08) printf( " .... 1... = high throughput");
    else printf( " .... 0... = normal throughput");
    ResetLog(offsetof(TOS),offsetof(TOS)+1,1);

    if(TOS & 0x04) printf( " .... .1.. = high reliability");
    else printf( " .... .0.. = normal reliability");
    ResetLog(offsetof(TOS),offsetof(TOS)+1,1);

    if(TOS & 0x02) printf( " .... ..1. = low monetary cost");
    else printf( " .... ..0. = normal monetary cost");

    printf( "Total length = %u bytes",TLen);
    printf( "Identification = %u", Identification);
    ResetLog(offsetof(Flags),offsetof(Flags)+1,1);
    printf( "Flags = %01Xh",Flags);
    ResetLog(offsetof(Flags),offsetof(Flags)+1,1);

    if(Flags&0x8) printf( " 1... .... = error: must be 0");
    else printf( " 0... .... = must be 0");
    ResetLog(offsetof(Flags),offsetof(Flags)+1,1);

    if(Flags&0x4) printf( " .1.. .... = do not fragment");
    else printf( " .0.. .... = may fragment");
    ResetLog(offsetof(Flags),offsetof(Flags)+1,1);

    if(Flags&0x2) printf( " ..1. .... = more fragment");
    else printf( " ..0. .... = last fragment");

    printf( "Fragment offset = %u bytes",FragmentOffset*8);
    printf( "Time to live = %u seconds/hops",TTL);
    printf( "Protocol = %u (%i)",NextProtocol,offsetof(NextProtocol));
    printf( "Header chechsum = %04Xh",HCHECKSUM);

    printf( "Source address = [%u.%u.%u.%u]", SAddress>>24&0xFF, SAddress>>16&0xFF,
                        SAddress>>8&0xFF,SAddress&0xFF);
    printf( "Destination address = [%u.%u.%u.%u]", DAddress>>24&0xFF, DAddress>>16&0xFF,
                        DAddress>>8&0xFF,DAddress&0xFF);
    ResetLog();

    if(HLEN>20) printf( "Options = %u bytes",HLEN-20);
    else printf( "No IP options");
}

ResetLog()

This function is used to modify the packet hexdump view (Analyzer's third panel). Each time Analyzer finds a printf() in the DFF file, it supposes that the user wants to print information about the next field defined into the PDF file. It follows that each printf() must coincide with a single field (multiple printf() for a single field lead to a wrong display in the third panel). By the way, Analyzer starts a new line in the packet details each time it finds a new printf().

ResetLog() is a function that can be used to change the way hexdump is highlightened. Function has three different forms:

  • ResetLog (StartOffset,EndOffset): it indicates that following printf() must highlight selected portion of the dumpfile

  • ResetLog (StartOffset,EndOffset,RedColor):same significate as before; when RedColor is positive, the interval is printed with the red color. Such a color means that the selected field is smaller than one byte; whether RedColor=0 Analyzer shows the data with the green color

  • ResetLog():it deletes the intervals set automatically by the analysis engine.

Index packet print definition IFF

DWORD IP ()
{
    //IP packet Interpretation
    if(Version!=4) return -1;
    printf("IP: ");
    printf( "%u.%u.%u.%u", SAddress>>24&0xFF,SAddress>>16&0xFF,
                           SAddress>>8&0xFF,SAddress&0xFF);
    printf("=>");
    printf( "%u.%u.%u.%u", DAddress>>24&0xFF,DAddress>>16&0xFF,
                               DAddress>>8&0xFF,DAddress&0xFF);
    printf( " (%u) :|:", TLen);
}

Adding TCP protocol

TCP header:

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Source Port |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Destination Port
Sequence Number
Acknowledgement Number
Data Offset |  |  |  | Res |  |  |  | Control |  |  |  |  |  |  |  | Window
Checksum |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Urgent Pointer
Options |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Padding

Protocol definition PDF

In the IP definition we have added the line:

CASE ((NEXTPROTOCOL=6)&&(FRAGMENTOFFSET=0)) : TCP

Then we add the TCP protocol definition:

 PROTOCOL TCP
 WORD SPORT
 WORD DPORT
 DWORD SNUMBER
 DWORD ACKNUMBER
 BYTE W1
 {
  BITS RES (0,3)
  BITS DATAOFFSET (4,7)
 }
 BYTE CONTROL
 WORD WINDOW
 WORD CHECKSUM
 WORD URGENTPTR
ENDPR
 SKIP: ((DATAOFFSET*4)-20)
 ELSE DATA

The instruction SKIP sets the reading sign where the next protocols should start. Anyway we do not add any CASE instructions because we do not add protocols that follow TCP. So all the bytes following the TCP header are considered as data. In our definition TCP options are not supported.

Protocol print definition DFF

In the TCP definition function we notice these new instructions:

  • 'check'; it verifies if the byte indicated by the parameter is present in the packet.
  • 'conv16': it returns the two bytes long variable whose offset is indicated by the parameter.
//TCP packet Interpretation
DWORD TCP ()
{
    DWORD headerLength;

    resetlog(offsetof(sport),offsetof(sport)+DataOffset*4);
    printf ("----- TCP Header -----");
    printf( "Source port = %u (%t)",SPort,offsetof(SPort));
    printf( "Destination port = %u (%t)",DPort,offsetof(DPort));
    printf( "Sequence number = %u" ,SNumber);
    printf( "Acknowledgement number = %u" ,AckNumber);
    CHECK(13);
    headerLength=DataOffset*4;
    ResetLog(offsetof(DataOffset),offsetof(DataOffset)+1,1);
    printf( "Header length = %u bytes",headerLength);
    printf( "Flags = %02Xh" ,Control );
    ResetLog(offsetof(Control),offsetof(Control)+1,1);
    if(Control &0x20)
        printf( " ..1. .... = Urgent pointer");
    else
        printf( " ..0. .... = No urgent pointer");
    ResetLog(offsetof(Control),offsetof(Control)+1,1);
    if (Control & 0x10)
        printf( " ...1 .... = Acknowledgement");
    else
        printf( " ...0 .... = No acknowledgement");
    ResetLog(offsetof(Control),offsetof(Control)+1,1);
    if (Control  & 0x08)
        printf( " .... 1... = Push");
    else
        printf( " .... 0... = No push");
    ResetLog(offsetof(Control),offsetof(Control)+1,1);
    if (Control  & 0x04)
        printf( " .... .1.. = Reset");
    else
        printf( " .... .0.. = No reset");
    ResetLog(offsetof(Control),offsetof(Control)+1,1);
    if (Control  & 0x02)
        printf( " .... ..1. = SYN");
    else
        printf( " .... ..0. = No SYN");
    ResetLog(offsetof(Control),offsetof(Control)+1,1);
    if (Control  & 0x01)
        printf( " .... ...1 = FIN");
    else
        printf( " .... ...0 = No FIN");
    printf( "Window = %u",Window);
    printf( "Checksum = %04Xh" ,Checksum);
    printf( "Urgent pointer = %u",UrgentPtr);
    if (headerLength>20)
    {
      DWORD pos,tmp,tmp2;
      tmp2=headerLength-20;
      resetlog(offsetof(UrgentPtr)+2,offsetof(UrgentPtr)+2+tmp2);
      printf( "Options = %u bytes" ,tmp2);
      pos=GetVmVar("SizeInt")+20;
      check(pos);
      tmp=CONV16(pos);
      if (tmp==0x204)
      {
         printf( " Code = %X (MSS)" ,tmp);
         printf( " Required MSS: %u",conv16(pos+1));
         tmp2=tmp2-4;
    }
      if (tmp2>0)
        printf(" Other Options");
    }
    else
      printf( "No TCP options" );
}

Interestingly, DFF file is able to recognize some options, even if the DFF does not support them. This is clearly a dirty way of doing that. However, it works.

Index packet print definition IFF

//TCP packet Interpretation
DWORD TCP ()
{
    printf("TCP: ");

    printf( "Port (%u => %u) ",SPort,Dport);
    printf( "Data (SN %u, ACK %u) ", SNumber,AckNumber);
}


The past development process

This project started making the porting of an existing protocols analyzer (the analysis engine) for the MS-DOS platform towards the Microsoft Windows environment. Main addictions included a graphical interface and the adaptation of the software to the 32 bit memory model. The porting towards the Win32 platform was done in two steps. During the first step the sources were converted from the 16 bit memory model to the 32 bit one. The result was represented by a "console" version, executable from a command-prompt window. This program allowed to evaluate statistics on a capture file and to display packet satisfying a filter through the console. During the second step the graphical interface was developed and some improvements were applied to the application. The graphical interface is independent from the analysis engine; the communication between the two parts is implemented following a client/server scheme. The old analysis engine had a lot of limitations about the definition of the supported protocols so because of this problem a big part of the analysis engine code was rewritten.

The final product was composed by the following modules:

  • The graphical interface which calls the other program modules.
  • The analysis engine which reads the capture file.
    • The configuration files parsers which are used by the analysis engine in order to read the configuration files (containing the supported protocols information).
  • The capture engine which captures the packets from the network and creates the capture file.

The first Analyzer version used the OLE Automation in the communication between the interface and the analysis engine.

Memory models and programming issues

The main peculiarity of the 32 bit memory model is represented by the "integer" data type that is made of 32 bit while in the DOS model it is made of 16 bit. This has some problems when, in the capture files, an integer (represented by 2 bytes) has to be read. In fact a capture file is a 'raw' file, so the access to it is like the access to text files. We will examine an example in order to understand this problem. For instance, we want to understand what happens if the following code fragment is executed in presence of the hexadecimal sequence 'EA-02-A6-03':

#include <stdio.h>
int i,j;
void main()
{
.....
fscanf(input_file,"%d%d",&i,&j);
.....
}

In the 16 bits model we obtain:

i=746 (0x02EA)
j=934 (0x03A6)

N.B. in the x86 architectures the bytes of an integer are stored inverting the bits order while in the Motorola architecture they are stored keeping the original order.

In the 32 bits model the result is:

i=61211370 (0x 02EA03A6)
j=????????? (0x???????? )

Then the solution adopted was represented by looking for all the code fragment like the previous one and by replacing the 'int' variables with 'short' ones (which are integer on two bytes on the Win 32 platforms).

N.B. We did not replaced all the 'int' variables of the code but only the variables which are used in capture file reading process; otherwise the efficiency of the program should have been decreased.

Because of the vision of the integer on 16 bit we had to make another correction to the code. We consider the following code fragment in order to explain this correction:

#include <stdio.h>
int i,j,t;
char c[100]
void main()
{
.....
j=0
fgets(c,100,Log_file);
t=*((int*)c);
j+=sizeof(int);
.....
}

In the DOS environment, at the end of the code execution, the j variable contains the value 2 while in Win32 it contains the value 4. We consider that, for instance, the j variable contains an offset relative to the 'raw' string; then, in Win32, the offset calculated is wrong. Besides the t initialization is wrong because of the previously described motive.

The mistake derives from the fact that the authors, thinking about making a portable code, did not consider that the Log file format is even the same, whatever is the environment; so in j we have to sum the value 2, in fact the integer in the log file are on 2 bytes.

The right code is:

#include <stdio.h>
int i,j,t;
char c[100]
void main()
{
.....
j=0
fgets(c,100,Log_file);
t=*((short*)c);
j+=2;
.....
}

Another problem derives from the fact that the library Turbo Vision, used to build the the previous Analyzer version, is replaced by the MFC (Microsoft Foundation Classes) used to build up Windows applications. MFC is very different from the Borland classes, so it was more easy to extract from Analyzer a version without any graphical objects and to build up, starting from scratch, the graphical interface using the MFC.

Query program

The version without graphical interface and based on a console approach is called "QUERY.EXE". It allows evaluating statistics on a capture file and extracting packets satisfying a filter. The original Analyzer version for MSDOS had only the first functionality.

The graphical interface

Then, after the porting of the console version, the graphical interface was written. Two solutions could be used in order to develop this part:

  1. The API calls offered by Windows. This solution was discarded because the program part was developed in C++; so it seemed disputable writing a program in C++ and its interface in C. Besides this solution does not fit to the Analyzer size.
  2. The utilization of classes which contain the API of Windows and get an easily manageable environment. This solution is offered using the Microsoft Foundation Classes (MFC).

The previous Analyzer version was also a text editor; this feature was kept in the Analyzer release for Windows.

Limits of the first version

The main limit of the first version was represented by the fact that the module that is used to print the protocols fields was implemented in C++; so adding a new supported protocol required rebuilding all the application. The capture files analysis was implemented through some files, called 'Statistics', which contained the definitions of some groups satisfying some conditions. Besides, in order to execute the file analysis, it was necessary creating the files which describe the protocols. These files had the extension PDF (Packet Definition Format) and they were written using a quite difficult language. So, as it is noticeable, there were two program parts which managed the same operation: the protocol definition. This redundancy forced the user to modify two parts (both the program source code and the PDF file) in order to add a new protocol to the supported ones.

The code which reads the capture file and the code which reads the 'Statistics' files were kept; the engine which executes the statistics was completely rewritten. Original parsers using a recursive descent were replaced by bottom-up parsers. The grammars were modified in order to create easily the parsed files.

OLE Automation in the interaction between the graphical interface and the analysis engine.

In the first Analyzer version the interaction between the analysis engine and the graphical interface was implemented through the OLE Automation.

This solution was abandoned because of two reasons. First of all the OLE Automation does not give the possibility to manage, at a low level, the communications between the client and the server. Besides the server had some unpredictable behaviors; for instance, often, a dialog window compared saying that the server was blocked. Then the closing process of the server program was very slow and provoked unpredictable events. For instance in Win95 some 'beep' were generated in some particular occasions.


Begin Capture Dialog Window

Capture filter: it allows the user inserting a run-time filter; syntax is the one of WinDump (http://netgroup-serv.polito.it/WinDump/).

Advanced filter: this button opens the Select Filter Dialog Window; the name of chosen filter appears in the edit box. Only packets satisfying the filter are saved in the capture document.

Overwrite current...: the new capture will overwrite current opened capture document. This control is disabled if there are not any opened documents.

Start: it starts the capture session; a window, which describes the capture status, appears on the screen:

Choose LAN adapter: it opens the dialog to choose the adapter used in the capture session. By default Analyzer opens the default adapters (settable in the Setup menu).

Advanced settings: it opens the Advanced Capture Settings Dialog Window, to select advanced parameters used in the capture session.


Create Capture Filter Dialog Window

With this window you can build a filter used in the capture engine session.

Filters list: the filter which belongs to this list can be a MAC filter or an IP filter. The description specify which is the captured traffic.

MAC/IP folder: you can build a packets filter based on the MAC/IP addresses; the text in the edit box 'Direction' specifies which direction (source to destination, ...) the filter refers to. Remember that a MAC address is composed by six hexadecimal numbers (interval: 00 - FF) and that an IP address is composed by four decimal numbers (interval: 0 - 255)..

Insert: it inserts a new filter in the list (=the filter composed with the selected folder),

Remove: it removes the selected filter from the list.

Update: it replace the selected filter with new one (=the filter composed with the selected folder).

Edit box Direction: it has the following voices:

  • SRC->DST : you have to insert the source address and the destination address.

  • SRC->... : you have to insert only the source address; so the filter includes all the packets which leave the host with specified source address.

  • ...->DST : you have to insert only the destination address; the filter includes all the packets forwarded to the host with the specified destination address.

  • HOST<->... : you have to insert only the host address; the filter includes the packets which leave the specified host and also the packets forwarded to the specified host.

  • HOST1<->HOST2 : you have to specify two addresses which identify host1 and host2 (at the MAC or IP level); the filter includes the packets forwarded (at the MAC or IP level) from host1 to host2 and vice versa.


Advanced Capture Settings Dialog Window

With this window you set some of the parameters used by the capture engine.

Capture buffer size: it sets the size of the capture buffer in the packet capture driver; buffer size is the parameter that influences the number of packets loss during a capture; on the same machine a bigger buffer means lower loss probability. Anyway Analyzer prints a message box when detect losses, therefore we suggest to increase this value only when it is strictly needed.

Number of packets...: capture can either proceed unlimited or can end when the selected number of packets are received.

Set capture in promiscuous mode: make the capture driver able to capture all the traffic transmitted on the network, otherwise only traffic from or to that station can be captured.

Section of the packet...: it sets the parameters which define the number of bytes copied by the system in the packets buffer. The packet capture driver copies only the selected amount of bytes to the buffer and not the whole packet; in this way the processing time, absorbed by the copy task, diminishes. So this parameter is one of the most important when talking about performances.

These parameters are saved in the Analyzer.ini file.


Protocol Configuration Dialog Window

This window is used to set three configuration files: PDF, DFF, IFF. These text files are used to describe the protocol format (PDF) and to customize how Analyzer displays packets (IFF, DFF). Click on the flap related to the file which you want to set.

PDF: PDF (Protocol Definition Format) file defines the protocols supported by the analysis engine; the setting will work when the next capture document will be opened. PDF file is saved as a text file.

DFF: DFF (Description File Format) file defines in which way the protocols will be shown on the screen; the setting will work when the next capture document will be opened.

IFF: IFF (Index File Format) file defines in which way the index, shown in the first window, is created; the setting will work when the next capture document will be opened.

Edit: Opens the selected file so you can modify it.


Select Filter Dialog Window

The 'Select Filter' dialog can be used to define two different types of filters:

  1. if this window is invoked by the buttons sequence Edit\Select... (from the capture menu - a capture document is open) then, through this window, you will choose the expression filter used to make a selection on the current capture document;

  2. if this window is invoked by the button sequence Captures\Begin\Advanced filter then you will choose the expression filter used to determine the packets which will be captured. The selected expression is set as parameter in the capture engine session.

List: the expressions list contains the filters defined in the file:

  • filters.dat if the filter is used to select a packets group.
  • cap_fltr.dat if the filter is used by the capture engine.

If the expression No Filter is selected then all the packets will be selected or all packets will be captured. These two files are stored in the folder indicated by Analyzer.ini.

Name: this edit box contains the selected filter name.

Expression: it contains the expression relative to the selected filter.

OK: set the selected filter; if the user made some changes in the expression list (added or removed something) the system asks if the changes have to be saved.

Define>>: if the window defines a packets selection filter this button opens the Create Expression Wizard; otherwise it opens the Create Capture Filter Dialog Window.

Add: it adds the expression written in the edit boxes to the list.

Remove: it removes the selected expression from the list.

Update: it replaces the selected expression with the text written in the edit boxes.


Statistics / Monitoring Settings Dialog Window

Introduction

  • The Statistics session evaluates the Average, Maximum and Minimum values on the group of data collected since the session beginning.
  • The Monitoring session shows the values/results relative to each updating interval.

Graphs list: it is the list of the graphical plug-ins used by Analyzer interface. Each plug-in draws a particular graph which is described by the 'Description' column.

Graph Settings...: opens the settings dialog of the selected graph. So the graph settings are settable before starting the statistics session.

Show: what is shown by the graph.

  • Packet Length
  • Traffic

Use EWMA function: this check box is available only in the Monitoring session. Checking this voice

the displayed values are evaluated through the statistical function:

new_media_value= (1-w) * old_media_value + w * (new_data)

w=1/16

Statistics on / Monitoring on: the list of the filters which can be selected (multiple selection is available) to define which type of traffic has to be monitored.

Results Update Interval: it sets the time that has to pass between two graph redrawing.

Statistical Data: if the 'Keep statistics data in memory' check box is checked then you can choose if all the data (since the real time session beginning) are stored in memory or only the last XXX samples are.

Extract Data From:

Lan Adapter Selected: you can choose the lan adapter which the data are extracted from.

OK: starts up the session.


Graphs

Common Settings

  • Colors: chooses the color that has to be applied to the selected item (for example the graph background, the column color for the column graph, and so on)
  • Save Settings: it enables saving the current graph settings into the proper .INI file, that is specific to each plug-in (for example column.ini for the "column" graph type)
  • Font: it chooses the font used for the legends

Column Graph Settings

Common Settings

Zoom

  • 'Combo Box': Sets the maximum value of the graph y axis.
  • 'Automatic Scale': if checked the the maximum value of the graph y axis is calculated considering the maximum value which has to be represented.
  • 'Show Percentages': if checked the graph represents the percentage values.

If the columns graph represents a table:

  • If the table has on the rows time intervals then each column is relative to a table column and the represented values are cumulative values (i.e. the sums of the table rows).
  • If the table has on the rows normal labels then columns groups are represented; each column group is relative to table column, each column group has so many columns haw much are the table rows. If the notation (i,j) indicates the generic table element then this element is represented by the i th column inside the group #j.

Pie Graph Settings

Common Settings

Size

  • 'Inclination': to choose the pie inclination from the vertical line.
  • 'Height': pie height expressed as ray percentage.

'Show Value': for instance during the Statistics session the user chooses if the pie represents percentages about averages or maximums or minimums values.

N.B. If the pie graph represents a table:

  • If the table has on the rows time intervals then each slice is relative to a table column and the represented values are cumulative values (i.e. the sums of the table rows).
  • If the table has on the rows normal labels then the user can choose through the combo box 'Show Value' which row has to be represented.

Bar Graph Settings

Common Settings

Zoom

  • 'Combo Box': Sets the maximum value of the graph x axis.
  • 'Automatic Scale': if checked the the maximum value of the graph x axis is calculated considering the maximum value which has to be represented.
  • 'Show Percentages': if checked the graph represents the percentages values.

'Show Value': for instance during the Statistics session the user chooses if the bars represent averages or maximums or minimums values.

N.B. If the bar graph represents a table:

  • If the table has on the rows time intervals then each bar is relative to a table column and the represented values are cumulative values (i.e. the sums of the table rows).
  • If the table has on the rows normal labels then the user can choose through the combo box 'Show Value' which row has to be represented.

Pie Simple Graph Settings

Common Settings

'Show Value': for instance during the Statistics session the user chooses if the pie represents percentages about averages or maximums or minimums values.

N.B. If the pie graph represents a table:

  • If the table has on the rows time intervals then each slice is relative to a table column and the represented values are cumulative values (i.e. the sums of the table rows).
  • If the table has on the rows normal labels then the user can choose through the combo box 'Show Value' which row has to be represented.

Scrolling-Lines Graph Settings

Common Settings

Zoom

  • 'y Max': the first combo box sets the y axis maximum value, the second one the order.
  • 'y min': the first combo box sets the y axis minimum value, the second one the order..
  • 'Automatic Scale': if checked the the maximum value of the graph y axis is calculated considering the maximum value which has to be represented.

'Show Value': for instance during the Statistics session the user chooses if the lines represent averages or maximums or minimums values.

Line Graph Settings

Common Settings

Zoom

  • 'y Max': the first combo box sets the y axis maximum value, the second one the order.
  • 'y min': the first combo box sets the y axis minimum value, the second one the order..
  • 'Automatic Scale': if checked the the maximum value of the graph y axis is calculated considering the maximum value which has to be represented.


Items available through all menus

Menu items

File

Open: it opens the classical window used to select the file that has to be opened. Whereas the "acp" is the native format for Analyzer, it can open other file formats as well.

Close: close the active document.

Save: save the active document.

Save As: save the active document with the selected name. N.B. The saving process do not permit to exploit all the capture format recognized during the opening process. Only accepted format are the acp (the native one), text-only, and html.

Save Index: saves the packets index (first panel) in a text format.

Print: print the active document.

Print Preview: show the print preview.

Page Setup / Printer Setup: these voices open the windows used to set the page which will be printed and to set the printer parameters.

Recent File List: 1 C:\....: the list of the most recent files.

Exit: it exits from Analyzer.

Edit

Undo: it makes void the last command (cut, copy, paste or delete).

Cut: it deletes the selected text and it also copies the selected text on the clipboard. If a capture document is active then it cuts the selected packets from the capture file; these packets are copied to the clipboard. A new copy into the clipboard erases automatically all previous contents.

Copy: it copies the selected text (or the selected packets) in the clipboard.

Paste: it copies the clipboard contents in the current document.

Delete: it deletes the selected text or the selected packets without coping on the clipboard.

Find: it opens the dialog window 'Find' which allows to search the specified text in the current document .

Find Next: it is like the homonymous button in the dialog 'Find'.

Replace: it opens the 'Replace' dialog used to replace a specified text with an other specified text.

Select: it opens the 'Choose Expressions' dialog window that allows you choose an expression that can be as a offline filter; the packets which satisfy the expression will be selected. Unfortunately Analyzer has still two different filter syntax for capturing and offline filtering.

Select All: selects the whole text or all the packets.

Remove Selection: removes the selection from the currently selected packets.

Invert Selection: sets as not selected the currently selected packets and as selected the currently not selected packets.

Packets

Go To: these voices group gives the navigation functionality through the packets list.

  • First: it shows the first packet of the list.

  • Previous Filtered: it shows the previous packet which satisfies the filter.

  • Previous: it shows the previous packet.

  • Next: it shows the next packet

  • Next Filtered: it shows the next packet which satisfies the filter.

  • Last: it shows the last packet of the list.

Order by: you can order the packets of the list by one of this six element.

First Protocol: it opens the windows on the right.

This window shows the list of the protocols supported by Analyzer (the ones defined in the PDF file); Analyzer starts its packet analysis (and display) from the one selected.

For instance, in the following tree view panel the packet analysis considers all the supported protocol:

After selecting "ARP" as the first protocol to be displayed, the packet analysis will start from the ARP protocol and the previous picture becomes:

Macro: opens the dialog used to set a macro (MAC) file.

Refresh Index: it rewrites the packets index without any modification.

Capture

New: opens a void capture file; the three blank window appear; you can copy here the most interesting packets from an other capture files.

Begin: this command opens the Begin Capture Dialog Window, which starts the capture on the local network.

Statistics

New Statistics: opens the Statistics Settings dialog.

New Monitor: opens the Monitoring Settings dialog.

Stop: stops the current real time session.

Suspend Visualization: suspends updating the graph data.

Resume Visualization: resumes updating the graph data. N.B. The capture threads are not stopped so the traffic evaluation goes on.

Display Historical Data: at the end of a real time session shows the history of the collected data.

Selected Field Extraction: it opens the 'Data extraction' dialog. In each tab control folder the user can define a criterion which will be used to extract the data from the packets index (first pane). The extracted data are represented in a table. Each table column is relative to a tab control folder (i.e. each column contains the data extracted using the criterion defined in the relative tab folder).

String before data: defines which string (the token) has to precede the extracted data.

Skip invalid data: if it is checked the data which are found after the selected token and are not of the selected value type (decimal, hexadecimal, octal, binary) are skipped.

Skip rows not containing...: if it is checked the rows which do not contain the token are skipped; else all the rows are considered and the rows which do not contain the token are associated to the default value.

Occurrence number: indicates how many times the token has to be found in each packets index row before starting to look for the data.

Default value: it is the value which is inserted in the table if the token is not found in the row or if there are not valid values after the token.

Combo Box: it sets the type of the found values.

Columns: it opens the dialog used to set from which packets index columns the extraction has to be done.

Add: it adds a new folder to the tab control.

Extract from: it sets if the extraction is done from all the list packets or from the selected ones.

For instance we consider the following row which represents a packets index row:

|1 | 12:03:23.346234 | 08002B-324820 | 08002B-27E21F | IP: 1.2.3.4 => 2.3.4.5 (72) | ICMP: Error= Destination Unreachable IP: 128.2.2.2 |

  1. if the user selects:

    • token: 'IP'

    • occurrence number = 3

    • Skip rows not containing...: checked

    • Skip invalid data: checked

    then this row is not considered in output table.

  2. if Skip rows not containing... is not checked then this row is considered and the default value is inserted in the table.

  3. if occurrence number = 2 then this row is considered and 128 is inserted in the table.

Mac Statistics: it opens (through a preventive selection of the interested adapter) the dialog 'Mac Statistics' which shows the link-layer statistics, obtained by querying directly the network adapter. Currently only Ethernet statistics (collisions, CRC errors, ...) are supported.
NOTE: there are some adapters that do not collect all the statistics; therefore those values cannot be printed.

Data

Display Settings: opens the settings dialog relative to the current graph.

Change Display Mode: it opens the dialog which shows the list of the available data representations.

Copy Data: it copies the table containing the displayed data on the clipboard, so it can be pasted on an 'Excel' page.

Setup

Protocol Def.: it opens the Protocol Configuration Dialog Window dialog window that is used to indicate the PDF, DFF, IFF files used by Analyzer in order to interpret and display packets.

Set Default Adapter: opens the dialog window used to choose the default network adapter; this adapter will be used by default unless the user chooses a new one before launching the process that is going to access the network device.

Open Capture Copy: if checked the interface does not open the selected file; it makes a temporary copy of the selected file, then it opens this copy.

Capture Association: it opens the dialog which shows the LFF files list. All the list data are extracted from the file Exts.dat. The formats described by these list are automatically recognized by Analyzer.

  • Test: it checks the selected file validity.

  • Add: it adds the new defined LFF file in the list.

  • Update: it recompiles the files list.

  • Remove: it removes the selected file.

  • Browse: opens the dialog used to choose a new LFF file.

  • When this window is closed the list is saved in the Exts.dat file.

Font: the user can select the fonts of the three panes. Selected fonts are saved into Analyzer.ini.

Clipboard:

  • Text: if it is checked then the selected packets can be copied on the clipboard using a text format; so they can be pasted on a normal text editor page.
  • Packets: if checked then the selected packets are copied on the clipboard using the 'Analyzer format'; so they can be pasted in an other three panes capture view. For instance the user could collect the most interesting packets in a blank three panes capture view (menu Capture\New).

View

ToolBar:

  • Editor: shows the editor bar when checked.
  • Analyzer: shows the analyzer toolbar when checked.
  • Real Time Session: shows the real time session bar when checked.

Status Bar: shows the status bar when checked.

Tree View: this voice refers to the panel which shows the packet tree view:

  • Expand: makes one level expansion in the tree view.

  • Collapse: makes a one level collapse in the tree view.

Protocols: it shows the list of the protocols supported by Analyzer.


Create Expressions Wizard

With this window you can create an expression which is used as a filter.

This window has four control groups:

  1. The first group is composed by the controls used to insert the values in the expression. Choose the table clicking on the label (Protocols, Variables, Values, Ascii or Hex) then choose the value selecting it, then push the button 'Insert' to insert the value in the expression. If you cannot make the insertion an error message will appear. You can insert both protocol expression and any variables given by the analysis engine in the expression. This variables are taken by the analysis engine through the function GetVmVar() and they give several information about the packet.

  2. The second group inserts the operators in the expression. Click on the button correspondent to the operator which you want insert. There are:
    • the five elementary operators (+, -, *, /, %)
    • The boolean operators: AND &&, OR ||, NOT !.
    • two buttons for the shift operation: shift on the right (>>), shift on the left (<<).
    • Six buttons for the comparison between the variables.
  3. The controls used to navigate in the expression and to build it:
    • Insert: it inserts the selected value.
    • Test: it tests if the expression is correctly written.
    • <-: it moves the insertion point one position on the left.
    • ->: it moves the insertion point one position on the right.
    • <-() , ()->: they allow to exit from the parenthesis.
    • (): it inserts the selected text between two parenthesis.

  4. The window controls (OK, Cancel).


Analyzer Help

Help!!! (part 2)

If you really want some more information, please:

  • think twice before asking stupid questions
  • please read twice this help page first
  • bug report is good; bug fixing is better (oh, yes, you should have source code...)
  • take in mind that this work has been done for free during our spare time, so no guarantee of reply is given
  • if you have still some question, please send an email to analyzer@netgroup-serv.polito.it.


Level 2 protocols

Mac level

Analyzer recognized the typical MAC level of the 802.3 network and the MAC level of the Ethernet II network (which does not need the LLC level).

802.3

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
DSAP
DSAP |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | SSAP
SSAP
LEN |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ...
...
LLC PDU (0 -> 1500 byte)
...
PAD (0 -> 46 byte)
...
FCS

Ethernet v.2.0

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
DSAP
DSAP |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | SSAP
SSAP
TYPE |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ...
...
Data (46 -> 1500 byte)
...
FCS

LLC level

The LLC level is typical of IEEE 802 networks. Here it is also the SNAP version which is used to support the protocol which are not defined by ISO.

LLC (standard)

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
DSAP |  |  |  |  |  |  |  | SSAP |  |  |  |  |  |  |  | CONTROL |  |  |  |  |  |  |  | ...
Data

LLC/SNAP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
DSAP=AAH |  |  |  |  |  |  |  | SSAP=AAH |  |  |  |  |  |  |  | CONTROL=03H |  |  |  |  |  |  |  | OUI
OUI |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Protocol Type
Data


TCP/IP Stack: level 3

IPv.4

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Version |  |  |  | HLen |  |  |  | Service Type |  |  |  |  |  |  |  | Total Length
Identification |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Flags |  |  |  | Fragment Offset
Time To Live |  |  |  |  |  |  |  | Protocol |  |  |  |  |  |  |  | Header Checksum
Source IP Address
Destination IP Address
Options (variable dimension) |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | PAD

IPv.6

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Version |  |  |  | Priority |  |  |  |  |  |  |  | Flow Label
Payload Length |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Next Header |  |  |  |  |  |  |  | Hop Limit
Source Address
Source Address
Source Address
Source Address
Destination Address
Destination Address
Destination Address
Destination Address

ARP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Hardware Type |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Protocol Type
HLEN |  |  |  |  |  |  |  | PLEN |  |  |  |  |  |  |  | Operation
Source HW Address
Source HW Address |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Source IP Address
Source IP Address |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Target HW Address
Target HW Address
Target IP Address

ICMP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Type |  |  |  |  |  |  |  | Code |  |  |  |  |  |  |  | Checksum
Identifier |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Sequence Number
Address Mask

ICMPv.6

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Type |  |  |  |  |  |  |  | Code |  |  |  |  |  |  |  | Checksum
Message Body

The ICMP options supported by Analyzer:

  • Destination Unreachable
  • Packet too big
  • Time exceeded
  • Parameter Problem
  • Echo Request
  • Echo Reply
  • Group Membership Query
  • Group Membership Report
  • Group Membership Termination
  • Router Solicitation
  • Router Advertisement
  • Neighbor Solicitation
  • Neighbor Advertisement
  • Redirect


TCP/IP Stack: level 4

TCP/IP Stack: level 4 protocols

TCP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Source Port |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Destination Port
Sequence Number
Acknowledgement Number
D. Offset |  |  |  | Reserved |  |  |  | Control |  |  |  |  |  |  |  | Window
Checksum |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Urgent Pointer
Options |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Padding

UDP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Source Port |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Destination Port
Message Length |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Checksum


Novell IPX Stack

IPX

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Checksum |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Length
Transport Control |  |  |  |  |  |  |  | Packet Type |  |  |  |  |  |  |  | Dest. Network Address
Dest. Network Address |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Dest. Node Address
Dest. Node Address
Dest. Socket |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Source Network Address
Source Network Address |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Source Node Address
Source Node Address
Source Socket |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ...
Data (0-546 byte)

RIPX

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Operation |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Network Number
Network Number |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Number of Hops
Number of Ticks |  |  |  |  |  |  |  | ...

SAP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Operation |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Service Type
... Server Name (4x12 bytes) ...
Network Address
Node Address
Node Address |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Socket Address
Hops |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ...

SPX

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Connection Control Flag |  |  |  |  |  |  |  | Datastream Type |  |  |  |  |  |  |  | Source Connection ID
Destination Connection ID |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Sequence Number
Acknowledge Number |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | Allocation Number
Data (0-534 byte)

NCP

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Fragger Handle
Maximim Fragment Size
Message Size
Fragment Flag
Internal Verb


TCP/IP Stack: routing protocols

TCP-IP Stack: routing protocols

RIP1

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Command | Version | unused
Address Family Identifier | Route Tag

IP Address
unused
unused
Metric

RIP2

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Command | Version | unused
Address Family Identifier | Route Tag

IP Address
Subnet Mask
Next Hop
Metric

IGRP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Version | Opcode | Edition | Autonomous System
Ninterior | Nsystem
Nexterior | Checksum
Destination | Delay
Delay | Bandwidth
Bandwidth | MTU | Reliability
Load Hop Count ...

EIGRP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Version | Opcode | Checksum | Flags
Sequence | ACK
Autonomous System | TLV

OSPF

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Version No. | Type | Packet Length
Router ID
Area ID
Checksum | AuType
Authentication
Authentication

BGP

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
Authentication
Authentication
Length | Type