Ethereal-dev: Re: [Ethereal-dev] More about conversation...
Thank you Guy : - )
One more question: My protocol has a user-defined option which allows it to
switch from
UDP to TCP(the negotitation is carried on UDP). Should I still use
conversations to keep track of this option?
And:
1) How can I make my dissector pay attention to TCP traffic (actually UDP
packets are still used in the protocol, it's not a switch from UDP to TCP.
TCP is used together with UDP)
2) What if I start capturing once the negotation is terminated?
Maybe I'd better write a heuristic similar to that written for UDP traffic.
Then I'd have no
need for conversations, i think, but I'm afraid I'd slow the dissecting
process.
From: Guy Harris <gharris@xxxxxxxxx>
Reply-To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
Subject: Re: [Ethereal-dev] More about conversation...
Date: Tue, 17 Jan 2006 02:04:29 -0800
fabio matturro wrote:
: D Hello.
I've read the chapter on conversations. Still, I've got some doubts.
I know that a conversation is a flow of packets from A to B.
Now, how can I retrieve these packets?
My problems is as follows:
My protocol sends packets that sometimes are correlated. For instance, it
sends packet A (opcode), then packet B (fields). They're NOT fragmented.
What I'd like to do is, if I stumble on packet B(that, containing only
fileds is not very common in my protocol), during a conversation can I
have a look at previous packets till I find packet A so that i can relate
them to each other?
If you see packet B, there is no mechanism to allow you to look backward in
the capture for a "packet A". (Bear in mind that the *exact same dissector
code* is used in Ethereal and Tethereal, and Tethereal can be used in a
live capture, where you don't get to go back and look for a packet.)
However, Tethereal, when it's dissecting packets (rather than just saving
them to a file), dissects every packet in the capture or file, in order,
and Ethereal, when it's reading in a capture file, dissects every packet in
the capture file, in order.
Thus, when you see a "packet A", you can, the first time you dissect it,
save information in a data structure attached to the conversation, and,
when you later see a "packet B", you can use that information to dissect
it.
Note, however, that, in Ethereal, if you've read in the capture, and then
click on "packet B", there's no guarantee that the packet that was most
recently dissected by Ethereal is "packet A".
Therefore. when you dissect "packet B" the first time, you'd need to attach
to the packet the information you need to dissect it.
For the per-conversation data structure, you'd attach the data structure to
the conversation with "conversation_add_proto_data()", using the number you
got back from "proto_register_protocol()" when you registered the protocol.
I.e., for a "packet A", you'd search for a conversation and, if you don't
find one, create one. Then try to get the conversation data for the
conversation you found or created with "conversation_get_proto_data()"
(again, using the number you got back from "proto_register_protocol()")
and, if you don't find any, allocate a conversation data structure and add
it to the conversation. Then set the information in that data structure
(the opcode?).
For a "packet B", try to get the per-packet data for the packet with
"p_get_proto_data()"; again, use the number you got back from
"proto_register_protocol()". If you don't find one, then, if this is the
first time the packet was seen (i.e., if pinfo->fd->flags.visited is
false), then:
Search for a conversation and, if you find it, try to get the conversation
data for the conversation.
If you have the conversation data, allocate a per-packet data structure,
and copy the information needed to dissect the packet from the
per-conversation data structure to the per-packet data structure.
If, after all that, you don't have a per-packet data structure (i.e., if
the packet didn't have any per-packet data, and there either was no
conversation or it didn't have any per-conversation data), there *was* no
"packet A", and you'll have to dissect what part of the packet you can do
without "packet A" - which could be nothing at all.
Otherwise, use the per-packet data structure information.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_________________________________________________________________
Scarica gratuitamente MSN Toolbar! http://toolbar.msn.it/
