Ethereal-dev: Re: [Ethereal-dev] Support for pure protocol packetswithout underlying protocol
Jeff Morris wrote:
>What he's got now is a PCAP file format where each packet has a "fake
>link" header on it that specifies the lowest-level protocol. This seems
>quite flexible to me--although I suppose that the format of the header
>needs to be stable before the file type is allocated.
>
I have a similar need to get packets of different higher level protocols dissected by Ethereal. In one capture file I want to have packets with several different high level protocols (H.225, H.245, SIP, MTP3, ...), so I have been thinking of using something similar to Navin's "fake link" dissector.
However I also want to have possibilities to store some extra data in some cases - so I have been thinking of having
some kind of Tag/Length/Value scheme for optional data per packet.
The TZSP dissector (packet-tzsp.c) is using some similar scheme with optional data, I think. I haven't checked it in detail yet.
Then there could be Tag:s corresponding to SOURCE_IPv4_ADDRESS, DEST_IPv4_ADDRESS, SOURCE_NAME, DESTINATION_NAME, IP_PROTO, SOURCE_PORT, DEST_PORT, IP_PROTO, COMMENT_STRING, FRAME_IDENTIFICATION and so on.
Depending on what protocol I'm logging data for I can add the relevant data as TLV data when writing the file:
SOURCE_IPv4_ADDRESS, IP_PROTO, SOURCE_PORT and so on for protocols running on IP (if I want to put that data into the file).
SOURCE_NAME and so on for MTP3 etc.
If I want to add some text comments to a certain packet I could use the COMMENT_STRING tag and so on.
>> Note that, of course, there are places where the TCP dissector expects
>> to have an IP address for each packet, and thus expects there to be an
>> IP header; other protocols, such as SCCP, might make similar
>> assumptions. They might have to be modified to handle, for example, the
>> source and destination addresses being AT_NONE rather than, say, AT_IPv4
>> or AT_IPv6.
>
>None of the SS7 dissectors I've written need any info about what was
>above them (AFAIK). I suppose this is because they don't do any
>kind of advanced analysis and/or reassembly?
>
>TCP and other dissectors could be modified on an as-needed (as they are
>added to "fake link") basis.
>
The "fake link" protocol could set the source address and similar if the corresponding Tagged data is available in the header, e.g. set the source address if the SOURCE_IPv4_ADDRESS tagged data is included, and also add it to the proto tree. This also solves the
problem with getting useful information for the source/destination.
>Stupid question: what do the source and destination columns say when
>dissecting things over this fake link layer?
For MTP protocols it could be useful to store the names of the SS7 destination and source in the file etc.
