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
>
