[Martin Visser <martinvisser99@xxxxxxxxx>]

Berkay,

Each IP packet has a source and destination IP address. When using
"tshark -z conv,ip" you get output something like as follows

IPv4 Conversations
Filter:<No Filter>
                                               |       <-      | |
  ->      | |     Total     |
                                               | Frames  Bytes | |
Frames  Bytes | | Frames  Bytes |
1.1.1.1         <->  2.2.2.2              9      1746       9
594      18      2340

So .....

9 and 1746 refer to traffic from 2.2.2.2 being sent to 1.1.1.1
9 and 594 refers to traffic from 1.1.1.1 being sent to 2.2.2.2
and 18 & 2340 is simply the sum of the two.

(For "tshark -z conv,tcp" you simply get a conversation per port & IP pair

TCP Conversations
Filter:<No Filter>
                                               |       <-      | |
  ->      | |     Total     |
                                               | Frames  Bytes | |
Frames  Bytes | | Frames  Bytes |
1.1.1.1:60838   <-> 2.2.2.2:ssh          7      1358       7       462
     14      1820

So, I'm not sure what question you need answered. Obviously tshark
must decide to display the conversation as "1.1.1.1:60838   <->
2.2.2.2:ssh"  or   " 2.2.2.2:ssh <->  1.1.1.1:60838". To be honest it
is pretty arbitrary in my opinion, but from what it seems , it is just
based on the first packet seen.

Regards, Martin

MartinVisser99@xxxxxxxxx



On 25 January 2011 14:18, Berkay Celik <argusflow@xxxxxxxxx> wrote:
> Guy, thanks for the answer but i'm not satisfied. When you get the
> conversation list using the tshark, even if there are partial conversations
> (no Syn or 3-way handshake is not observed) commonly tshark gives the
> correct results, i need more detail or reference to delve into this topic
> which i will use for packet analysis in my program...
>
> thanks.
>
>
> On 1/24/2011 10:55 PM, Guy Harris wrote:
>
> On Jan 24, 2011, at 7:31 PM, Berkay Celik wrote:
>
> If there is a syn bit set seen from an endpoint, this is the source.
>
> Presumably you mean "if there is a SYN bit, *and no ACK bit*, seen from an
> endpoint, this is a packet coming from the machine trying to start the TCP
> connection" (i.e., that by "source" you mean the machine that's trying to
> start the connection, and that this applies only to the initial SYN, not the
> the SYN+ACK you get back from the machine to which you're trying to
> connect).
>
> I am curious about if wireshark defines in some other ways
>
> Does Wireshark even define the "source" and "destination" of a TCP
> connection?  A packet trace might not have the three-way handshake, so it
> might not be possible to determine, at the TCP layer, what the source and
> destination of a connection are.
> Wireshark *does* identify the source and destination of a packet at various
> layers, including the IP layer, but those are defined fairly
> straightforwardly by the protocol.
>
> or only the syn bit is enough to identify the source and destination?
>
> *If* you see either the initial SYN or the SYN+ACK, that's sufficient to
> identify the "source" and "destination" of a TCP connection, where "source"
> is "the endpoint that tried to connect" and "destination" is "the endpoint
> to which the connection was attempted".  For other transport layers, there
> might be other definitions, or there might not be any definition of "source"
> and "destination" at the transport layer (consider UDP, for example).
>
> Secondly,
>
> if my traces has are partial conversations, not any syn bit is seen, which
> one is the source and destination? port numbers can be used to determine
> them but what if both port numbers makes sense.
>
> If both port numbers make sense as the "server" port number, then there is
> absolutely no way to determine, at the transport layer, which endpoint is
> the "source" ("client") and which endpoint is the "destination" ("server").
>  That would have to be determined at a higher layer, for example at the
> layer of the protocol running *atop* TCP - a request packet is presumably
> going from "source"/"client" to "destination"/"server", and a response
> packet is presumably going the other way.
> Of course, if a protocol is peer-to-peer, so that *either* side can send a
> request or reply to a request, even that won't work.
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>