Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 9464] New: Use contents of K12_REC_STK_FILE records in RF5 files to specify di

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	9464
Summary	Use contents of K12_REC_STK_FILE records in RF5 files to specify dissectors
Classification	Unclassified
Product	Wireshark
Version	SVN
Hardware	All
OS	All
Status	UNCONFIRMED
Severity	Enhancement
Priority	Low
Component	Capture file support (libwiretap)
Assignee	bugzilla-admin@wireshark.org
Reporter	guy@alum.mit.edu

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
Some (but not all!) RF5 files have K12_REC_STK_FILE records that include the
contents of .stk files.

A "stack file", as appears in a K12_REC_STK_FILE record, is a text file (with
CR-LF line endings) with a sequence of lines, each of which begins with a
keyword, and has white-space-separated tokens after that.

They appear to be:

  STKVER, which is followed by a number (presumably a version number for the
stack file format)

  STACK, which is followed by a quoted string ("ProtocolStack" in one file) and
two numbers

  PATH, which is followed by a non-quoted string giving the pathname of the
directory containing the stack file

  HLAYER, which is followed by a quoted string, a path for something (protocol
module?), a keyword ("LOADED", in one file), and a quoted string giving a
description - this is probably a protocollayer of some sort

  LAYER, which has a similar syntax to HLAYER - the first quoted string is a
protocol name

  RELATION, which has a quoted string giving a protocol name, another quoted
string giving a protocol name, and a condition specifier of some sort, which
probably says the second protocol is layered atop the first protocol if the
condition is true.  The first protocol can also be "BASE", which means that the
second protocol is the lowest-level protocol.

  The conditions are:

    CPLX, which may mean "complex" - it has parenthesized expressions including
"&", presumably a boolean AND, with the individual tests being L:expr, where L
is a letter such as "L", "D", or "P", and expr is:

       0x........ for L, where each . is a hex digit or a ?, presumably meaning
"don't care"

       0;0{=,!=}0b........ for D, where . is presumably a bit or a ?

       param=value for P, where param is something such as "src_port" and value
is a value, presumably to test, for example, TCP or UDP ports

    UNCOND, presumably meaning "always"

    PARAM, followed by a parameter name (as with P:) and a value, possibly
followed by LAYPARAM and a hex value

  DECKRNL, followed by a quoted string protocol name, un-quoted "LSBF" or
"MSBF" (Least/Most Significant Byte First?), and an un-quoted string ending
with _DK

  LAYPARAM, followed by a quoted protocol name and a number (-2147221504 in one
file, which is 0x80040000)

  SPC_CONF, folloed by a number, a quoted string with numbers separated by
hyphens, and another number

  CIC_CONF, with a similar syntax to SPC_CONF

  LAYPOS, followed by a protocol name or "BASE" and 3 numbers.

Most of this is probably not useful, but the RELATION lines with "BASE" could
be used to figure out how to start the dissection (if we knew what "L" and "D"
did), and *some* of the others might be useful if they don't match what's
already in various dissector tables (the ones for IP and a higher-level
protocol, for example, aren't very useful, as those are standardized, but the
ones for TCP, UDP, and SCTP ports, and SCTP PPIs, might be useful).

---

      You are receiving this mail because:

• You are watching all bug changes.